You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Obtain dependencies from pom.xml in current directory #449
just need to see how to handle we can have https urls as dependencies - maybe have it that if the file part is pom.xml we treat it as a "import from pom" (no matter where it comes from).
What need to decide is what amount of things to import... basically one of these:
. Adds all dependencies defined in imported POM file included in test scope for resolution
. Adds all dependencies defined in imported POM file included in runtime, test, system, and import scopes for
. Adds all dependencies defined in imported POM file included in runtime, system, import scopes for resolution
. Adds all dependencies defined in imported POM file included in compile, runtime, system, and import scopes for
I would say to include compile runtime, system & import by default seem to make the most sense.
(we might one day at //DEPS@scope or similar in future - for now //DEPS are compile+runtime deps.
one sideffect this will have is we will have to expand the deps from the pom.xml everytime - won't be able to cache as efficiently....probably okey as using pom.xml you are in "explore" mode rather than building an app for speed.
I guess I could introduce (yet-another) cache for this ... for now its just that the caching of deps is listof(gavs)->artifact locations...i'll start with not caching it. can be added/improved transparently.
okey so this is all doable but it kinda breaks an implicit assumption the code base currently has and that is:
one entry in //DEPS = one artifact, with ./pom.xml it is many
that resolution can happen in one go - with ./pom.xml it seems shrinkwrap will need a separate resolution phase for the artifacts in the pom.xml...hopefully i can find a way to avoid that - we really just need the list of GAV's not the resolved artifact before later.
so I could ignore the above and implement it in pretty crude and slow way; but it might just be better to do it right....
Just to add one use case here - when a repo contains both heavy-weight code (e.g. a web server) and light-weight code (various scripts), it's very bad to incur the time cost of mvn exec:java for scripts.
Scripts are usually simple, so duplicating //DEPS is not that big of a deal, but having even a basic support for reading deps from pom.xml would be helpful to keep things DRY.
It doesn't even have to support everything, as worst case one can always drop back to using //DEPS in most cases, though continuing to start up quickly is important.
#2597 has a "build system dependency" feature that for now support pom.xml and build.gradle and build.gradle.kts as a "source" of dependencies - by calling that related build tool.
To me it feels very weird to have a script that depends on maven/gradle files being present and the executables available to be run.
It also completely breaks any possibility of this script running remotely. (You can of course always create a script that doesn't run remotely if you want, but we've always gone the extra mile to make that work as much as possible).
Personally I would much rather see an "import" command or something like that. It could read those files and add the dependencies to the script file you point at. Afterwards the script will be completely independent from the pom/gradle build files (and can again be used remotely).
It also means it could be implemented as a separate script or a plugin instead of needing changes to the JBang core.
To me it feels very weird to have a script that depends on maven/gradle files being present and the executables available to be run.
The usecase here is not standalone scripts - its from within existing project. So you have have the executables available to you.
And yes, this will fail hard if you don't. But thats fine because these scripts are inside this project which you need thebuild tools to do anything anyways.
It also completely breaks any possibility of this script running remotely. (You can of course always create a script that doesn't run remotely if you want, but we've always gone the extra mile to make that work as much as possible).
Correct, that we go as far as we can here -but yes; here that will not be possible.
Personally I would much rather see an "import" command or something like that. It could read those files and add the dependencies to the script file you point at. Afterwards the script will be completely independent from the pom/gradle build files (and can again be used remotely).
sure, but the amount of deps to add is easily humongous and cannot be easily derived in a portable way. getting runtime classpath (as a
complete set) is possbile - but not the "just the first layer of dependencies including include/exclude rules for that specifci build tool"
The usecase is for those with wish to write scripts inside a project - i'm also find in having another way of specifying than the suggested //DEPS and --classpath support. But anything that requires saving a list of deps into the script file will not solve the usecase.
It also means it could be implemented as a separate script or a plugin instead of needing changes to the JBang core.
yes, but it would require running everytime...and diverge and IDE's would need to be told to call it - this approach seems much simpler ?
yes, but it would require running everytime...and diverge and IDE's would need to be told to call it - this approach seems much simpler ?
Why would IDEs need to call it each time, or even any time? It would just be a decision the dev makes at some point, runs it once (or at least once after making any changes to deps) and gets deps added to a script. It doesn't really seem like something that is such an awesome feature that everybody and their grandmother would want to use.
Another option is to simply have a tool that extracts dependencies and not even add them as //DEPS but simply like jbang --deps $EXTRACTED_DEPS. The philosophy of making things that can be put together to make bigger things instead of making everything part of JBang. Building this into JBang to me feels very kitchen sink-y and you know how I feel about that :-)
yes, but it would require running everytime...and diverge and IDE's would need to be told to call it - this approach seems much simpler ?
Why would IDEs need to call it each time, or even any time? It would just be a decision the dev makes at some point, runs it once (or at least once after making any changes to deps) and gets deps added to a script. It doesn't really seem like something that is such an awesome feature that everybody and their grandmother would want to use.
well, no grandmothers will use it if it requires more steps than "update pom.xml, run jbang, have it work" :)
I run scripts constantly from vscode - including update pom.xml / build.gradle and I can just say it is tedious having to keep them in sync.
Another option is to simply have a tool that extracts dependencies and not even add them as //DEPS but simply like jbang --deps $EXTRACTED_DEPS. The philosophy of making things that can be put together to make bigger things instead of making everything part of JBang. Building this into JBang to me feels very kitchen sink-y and you know how I feel about that :-)
There are more to this in the future though - atm. it takes compile-runtime classpath but with things like #2126 and could do things like ^pom.xml{runtime} to pick just runtime or other form of hints.
By having it as a first class citizen you can do jbang --deps build.gradle -i and have a jshell configured by jbang using dependencies from your projects build path with zero generation/setup.
Activity
aalmiray commentedon Oct 16, 2020
It could be a relative path or an absolute path 😏
maxandersen commentedon Oct 16, 2020
just need to see how to handle we can have https urls as dependencies - maybe have it that if the file part is
pom.xmlwe treat it as a "import from pom" (no matter where it comes from).What need to decide is what amount of things to import... basically one of these:
https://github.com/shrinkwrap/resolver/blob/master/maven/api-maven/src/main/java/org/jboss/shrinkwrap/resolver/api/maven/PomEquippedResolveStageBase.java
. Adds all dependencies defined in imported POM file included in test scope for resolution
. Adds all dependencies defined in imported POM file included in runtime, test, system, and import scopes for
. Adds all dependencies defined in imported POM file included in runtime, system, import scopes for resolution
. Adds all dependencies defined in imported POM file included in compile, runtime, system, and import scopes for
I would say to include compile runtime, system & import by default seem to make the most sense.
(we might one day at
//DEPS@scopeor similar in future - for now//DEPSare compile+runtime deps.maxandersen commentedon Oct 16, 2020
one sideffect this will have is we will have to expand the deps from the pom.xml everytime - won't be able to cache as efficiently....probably okey as using pom.xml you are in "explore" mode rather than building an app for speed.
aalmiray commentedon Oct 16, 2020
Why is that? Couldn't you cache url+timestamp or contents (text) so that the poms is not resolved every time?
maxandersen commentedon Oct 16, 2020
I guess I could introduce (yet-another) cache for this ... for now its just that the caching of deps is listof(gavs)->artifact locations...i'll start with not caching it. can be added/improved transparently.
maxandersen commentedon Oct 16, 2020
okey so this is all doable but it kinda breaks an implicit assumption the code base currently has and that is:
./pom.xmlit is many./pom.xmlit seems shrinkwrap will need a separate resolution phase for the artifacts in the pom.xml...hopefully i can find a way to avoid that - we really just need the list of GAV's not the resolved artifact before later.so I could ignore the above and implement it in pretty crude and slow way; but it might just be better to do it right....
still broken pom files support. fixes jbangdev#449
cebaa commentedon Jul 6, 2026
Just to add one use case here - when a repo contains both heavy-weight code (e.g. a web server) and light-weight code (various scripts), it's very bad to incur the time cost of
mvn exec:javafor scripts.Scripts are usually simple, so duplicating
//DEPSis not that big of a deal, but having even a basic support for reading deps frompom.xmlwould be helpful to keep things DRY.It doesn't even have to support everything, as worst case one can always drop back to using
//DEPSin most cases, though continuing to start up quickly is important.maxandersen commentedon Jul 12, 2026
#2597 has a "build system dependency" feature that for now support pom.xml and build.gradle and build.gradle.kts as a "source" of dependencies - by calling that related build tool.
feedback welcome.
quintesse commentedon Jul 13, 2026
To me it feels very weird to have a script that depends on maven/gradle files being present and the executables available to be run.
It also completely breaks any possibility of this script running remotely. (You can of course always create a script that doesn't run remotely if you want, but we've always gone the extra mile to make that work as much as possible).
Personally I would much rather see an "import" command or something like that. It could read those files and add the dependencies to the script file you point at. Afterwards the script will be completely independent from the pom/gradle build files (and can again be used remotely).
It also means it could be implemented as a separate script or a plugin instead of needing changes to the JBang core.
maxandersen commentedon Jul 13, 2026
The usecase here is not standalone scripts - its from within existing project. So you have have the executables available to you.
And yes, this will fail hard if you don't. But thats fine because these scripts are inside this project which you need thebuild tools to do anything anyways.
Correct, that we go as far as we can here -but yes; here that will not be possible.
sure, but the amount of deps to add is easily humongous and cannot be easily derived in a portable way. getting runtime classpath (as a
complete set) is possbile - but not the "just the first layer of dependencies including include/exclude rules for that specifci build tool"
The usecase is for those with wish to write scripts inside a project - i'm also find in having another way of specifying than the suggested //DEPS and --classpath support. But anything that requires saving a list of deps into the script file will not solve the usecase.
yes, but it would require running everytime...and diverge and IDE's would need to be told to call it - this approach seems much simpler ?
quintesse commentedon Jul 13, 2026
Why would IDEs need to call it each time, or even any time? It would just be a decision the dev makes at some point, runs it once (or at least once after making any changes to deps) and gets deps added to a script. It doesn't really seem like something that is such an awesome feature that everybody and their grandmother would want to use.
Another option is to simply have a tool that extracts dependencies and not even add them as
//DEPSbut simply likejbang --deps $EXTRACTED_DEPS. The philosophy of making things that can be put together to make bigger things instead of making everything part of JBang. Building this into JBang to me feels very kitchen sink-y and you know how I feel about that :-)maxandersen commentedon Jul 13, 2026
well, no grandmothers will use it if it requires more steps than "update pom.xml, run jbang, have it work" :)
I run scripts constantly from vscode - including update pom.xml / build.gradle and I can just say it is tedious having to keep them in sync.
There are more to this in the future though - atm. it takes compile-runtime classpath but with things like #2126 and could do things like
^pom.xml{runtime}to pick just runtime or other form of hints.By having it as a first class citizen you can do
jbang --deps build.gradle -iand have a jshell configured by jbang using dependencies from your projects build path with zero generation/setup.I find that idea and usecase compelling.
maxandersen commentedon Jul 17, 2026
i'm more and more convince he utility of this :)
with ^pom.xml or even just pom.xml I can go into existing project and just put xyz.java with:
and just use/extend what is there versus:
no extra step, just do.