search

nanosai / modrun

A Java application launcher and class loader which can load and run classes directly from Maven repositories and resolve dependencies at runtime.
Apache License 2.0
97 stars 12 forks source link

Snapshot Support #2

Open gtnarg opened 7 years ago

gtnarg commented 7 years ago

Do you plan on supporting the resolution of Snapshots (i.e. get the latest version from the repository if it is newer than what you have locally)?

I noticed that when it is resolving dependencies it ignores "test" scoped dependencies. Shouldn't this also be the case for "provided"?

Thanks

jjenkov commented 7 years ago

Hi Gnartg,

The "provided" dependencies should not be ignored, as ModRun is not building a JAR file, but running a JAR file. ModRun has to look for all dependencies needed at runtime, and "provided" dependencies are also needed at runtime. They are just assumed to be "provided".

Snapshots - we might, in the future. If enough people ask for it. That might be useful during development. But - one step at a time. First we focus on running Java apps in test and production environments. Then we will focus on running Java apps during dev (with stuff like SNAPSHOT versions etc).

gtnarg commented 7 years ago

My usecase was to use this as a classloader for a jar and if a particular dependency is already on my classpath (i.e. provided) then it can be ignored. Perhaps I am not aligned with the purpose of the library.

Could this be configurable?

jjenkov commented 7 years ago

It could probably be configurable in the future. It is not right now. ModRun first checks if a dependency is available in the Maven repository you have pointed ModRun to. If not, it will check transitive dependencies, and finally it will check the root class loader.

I guess a dependency marked as "provided" could be interpreted as being available from the root class loader ... ?