Romain, it's probably me, but I have no faintest idea what you are trying to say...
What do you mean by "standalone"? What is the wrong packaging? Why will I lose the ability to specify where it goes? Also, as I said before, if you list project/deps gav:jar AND gav:module, you would be putting _one same JAR_ on both paths (would you really want that?) Also, here we are speaking about _dependencies_ but you suddenly switch to building a project? But one thing for sure: we need _less_ "guess logic" and not _more of it_. I think we are not talking about the same thing(s) here, but again, it's just maybe me. T On Sun, Oct 29, 2023 at 1:32 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Le dim. 29 oct. 2023 à 12:44, Tamás Cservenák <ta...@cservenak.net> a > écrit : > > > Can you provide a real example? As I don't quite understand, so you would > > have a dependency (a fat spring boot jar), that is a "module dep is a > > module in compile/some tests but not at runtime (spring boot fatjar)". So > > all this within one maven module (compile/test/runtime?). > > > > > You have an app (src/main/java), all the chain down the line uses modules > cause compiler is standalone, surefire (junit-launcher) is standalone, > javadoc etc...and the packaging phase (jar/war/fatjar/...) is not > standalone. > Then using module will make your build pass but your IT (if you have else > your runtime) will not use that kind of construction/runtime. > the issue is as soon as you mark them modules then it must be module for > all plugins and therefore you will get a wrong packaging (think bnd for ex) > or said otherwise you loose the consumption ability the JVM has providing > both classpath and module path for the same jar (jlink requires deps to be > modules but these modules can be used in the classpath most of the time, in > particular in tests where it helps in several scenarii like mocking). > > These are all valid features we don't want to break in maven. > > The consuming side is problematic since you restart from scratch, all the > jpms meta are to throw away cause we don't want to break the model on one > side and on another side it depends the consumer the way you consume it and > dispatch the dependency on the classpath or module path. > > Your solution is valid technically but does not solve the original issue, > it just moves it elsewhere IMHO. > > This already works well today at the cost of being explicit in the plugins > configs and with your proposal it will still work at the same cost (maybe > reversed). > > So ultimately I don't think it is a dep meta we need but more a wrapper on > top of the resolver (the guess logic we have in plexus for ex) which should > be easier to configure, maybe globally for the project and ultimately per > plugin (think "configuration" in gradle world of maven depencies set in our > world)....or we just don't do anything and ease the dependency referencing > (gav->path) to ease this explicit configuration - a bit like including > dependencies:properties in core by default. > > > > > > > > T > > > > On Sun, Oct 29, 2023 at 12:37 PM Romain Manni-Bucau < > rmannibu...@gmail.com > > > > > wrote: > > > > > Le dim. 29 oct. 2023 à 12:12, Tamás Cservenák <ta...@cservenak.net> a > > > écrit : > > > > > > > Given that jar (spring boot fatjar) is once this once that, you refer > > to > > > it > > > > in deps as needed: > > > > in one module is fat:jar in other is fat:module, as needed. > > > > > > > > You are the one explicitly telling what you want. > > > > > > > > > > In my example (and spring boot is not the only one, wars are another > > common > > > one, or any java command more generally) the two modules are a single > > > one....and no doing two module would be worse than what we have today. > > > > > > > > > > Thanks > > > > T > > > > > > > > On Sun, Oct 29, 2023 at 8:42 AM Romain Manni-Bucau < > > > rmannibu...@gmail.com> > > > > wrote: > > > > > > > > > Interesting but common case: a module dep is a module in > compile/some > > > > tests > > > > > but not at runtime (spring boot fatjar). > > > > > Back to explicit config in plugins and drop new module type? > > > > > > > > > > Le dim. 29 oct. 2023 à 07:46, Christoph Läubrich < > > m...@laeubi-soft.de> > > > a > > > > > écrit : > > > > > > > > > > > > where properties are totally extensible, > > > > > > > > > > > > And if now I could supply additional properties from the > xml-model > > > ... > > > > > > > > > > > > Am 29.10.23 um 00:40 schrieb Tamás Cservenák: > > > > > > > And finally this is hardly gonna happen in Maven 3 lifespan, as > > > sadly > > > > > > > ArtifactHandler of it is quite limited: has only one flag: > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L55 > > > > > > > > > > > > > > Sadly, Maven4 Type continued on this path, but luckily we are > in > > > > alpha, > > > > > > and > > > > > > > will propose a PR to type that currently looks like this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/maven/blob/master/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java#L80 > > > > > > > > > > > > > > And would rework it to be more (if not same as) the resolver > > > > > > ArtifactType: > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/artifact/ArtifactType.java#L63 > > > > > > > > > > > > > > where properties are totally extensible, for example "add to > > > > classpath" > > > > > > is > > > > > > > really just one flag (added by ArifactType): > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/artifact/ArtifactProperties.java#L58 > > > > > > > > > > > > > > So, ArtifactProperties could be extended with > > > > "constitutesModulePath", > > > > > > > "agent" and so on... To make this really extensible. > > > > > > > > > > > > > > In maven3 the ArtifactHandler this makes it impossible. There > is > > > > still > > > > > > hope > > > > > > > in Maven 4 > > > > > > > > > > > > > > Thanks > > > > > > > T > > > > > > > > > > > > > > > > > > > > > On Sun, Oct 29, 2023 at 12:32 AM Tamás Cservenák < > > > > ta...@cservenak.net> > > > > > > > wrote: > > > > > > > > > > > > > >> This would also mean, that if you have a dependency that is > > > already > > > > > JPMS > > > > > > >> modularized (is java9+ and has module-info), then: > > > > > > >> > > > > > > >> a) if you declare it as type="jar" it means you want to put it > > on > > > > > > >> classpath (use it as "plain old jar") > > > > > > >> b) if you declare it as type="module" it means you want it on > > > > > modulepath > > > > > > >> etc > > > > > > >> > > > > > > >> On Sun, Oct 29, 2023 at 12:30 AM Tamás Cservenák < > > > > ta...@cservenak.net > > > > > > > > > > > > >> wrote: > > > > > > >> > > > > > > >>> Of course, the logic HOW and WHAT to make with these would be > > > > needed > > > > > to > > > > > > >>> be added to javadoc, compiler and all the plugins that need > to > > > > > > distinguish. > > > > > > >>> But this would stop any need for any heuristic, guesswork, > > > > > smart-ness, > > > > > > >>> etc... > > > > > > >>> > > > > > > >>> OTOH, if we introduce new packaging lifecycle "module" (so a > > > > project > > > > > > that > > > > > > >>> builds module would do project/packaging=module), it could > > nicely > > > > > > enforce > > > > > > >>> things like: > > > > > > >>> - prevent non allowed packages > > > > > > >>> - enforce presence of module-info.class (maybe some light > > > > > verification) > > > > > > >>> - ensure project is Java9+ etc > > > > > > >>> > > > > > > >>> Most of this was somewhat done in Takari Lifecycle (also with > > > > custom > > > > > > >>> packaging like "takari-jar" was). > > > > > > >>> > > > > > > >>> > > > > > > >>> T > > > > > > >>> > > > > > > >>> On Sun, Oct 29, 2023 at 12:26 AM Tamás Cservenák < > > > > > ta...@cservenak.net> > > > > > > >>> wrote: > > > > > > >>> > > > > > > >>>> So, basically this is what am proposing: > > > > > > >>>> > > > https://gist.github.com/cstamas/76f262538b5a11f6ee23d6d8c86f10ec > > > > > > >>>> > > > > > > >>>> Basically, Maven core (and hence plugins) could distinguish > > > among > > > > > > >>>> different "types" of dependencies (while would all still be > > > plain > > > > > > JARs). > > > > > > >>>> So "jar" would be put on classpath, "module" on module path, > > > > "agent" > > > > > > >>>> would got special treatment and so on. > > > > > > >>>> > > > > > > >>>> Point is to _differentiate_. > > > > > > >>>> > > > > > > >>>> T > > > > > > >>>> > > > > > > >>>> On Sun, Oct 29, 2023 at 12:21 AM Tamás Cservenák < > > > > > ta...@cservenak.net > > > > > > > > > > > > > >>>> wrote: > > > > > > >>>> > > > > > > >>>>> Unsure from where you get that, but is wrong conclusion. > > > > > > >>>>> > > > > > > >>>>> You can have dep1:jar, dep2:module, dep3:agent and all 3 > MAY > > > > > > >>>>> (ArtifactHandler dependent, assuming "jar", "module" and > > > "agent" > > > > > > artifact > > > > > > >>>>> handlers all return extension=jar) refer to the same JAR > file > > > in > > > > > > your local > > > > > > >>>>> repository. > > > > > > >>>>> > > > > > > >>>>> Type merely adds "semantics" WHAT is it about, HOW to make > > use > > > of > > > > > it. > > > > > > >>>>> Please see > > > > > > >>>>> > > > > > > > > > > > > > > > > > > > > > https://maven.apache.org/repositories/artifacts.html#but-where-do-i-set-artifact-extension > > > > > > >>>>> > > > > > > >>>>> Thanks > > > > > > >>>>> T > > > > > > >>>>> > > > > > > >>>>> On Sun, Oct 29, 2023 at 12:17 AM Martin Desruisseaux < > > > > > > >>>>> martin.desruisse...@geomatys.com> wrote: > > > > > > >>>>> > > > > > > >>>>>> Le 2023-10-28 à 22 h 54, Tamás Cservenák a écrit : > > > > > > >>>>>> > > > > > > >>>>>>> I still see these just as new dependency types: "module", > > > > > "agent", > > > > > > >>>>>>> "doclet", and so on. > > > > > > >>>>>>> > > > > > > >>>>>> Does "dependency type" means the <type> element inside > > > > > <dependency>? > > > > > > >>>>>> If > > > > > > >>>>>> yes, then specifying a different type causes Maven to > > > download a > > > > > > >>>>>> different JAR, without changing the kind of path (class > path > > > > > versus > > > > > > >>>>>> module path) where the JAR is put. The proposed <usage> > > > element > > > > > (or > > > > > > >>>>>> whatever equivalent alternatives) has the opposite > semantic: > > > it > > > > > does > > > > > > >>>>>> not > > > > > > >>>>>> change the JAR to download, but put it on a different kind > > of > > > > > path. > > > > > > >>>>>> > > > > > > >>>>>> Martin > > > > > > >>>>>> > > > > > > >>>>>> > > > > > > >>>>>> > > > > > > >>>>>> > > > > > > > > --------------------------------------------------------------------- > > > > > > >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > > >>>>>> For additional commands, e-mail: > dev-h...@maven.apache.org > > > > > > >>>>>> > > > > > > >>>>>> > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > >
