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 > > > > > > > > > > > > > > > > > > > >
