And just realized something: by using dependencies as above, we even fix an issue https://issues.apache.org/jira/browse/MCOMPILER-496
Typical problem: a multi reactor build contains an annotation processor, and then that processor needs to be used in subsequent modules. Maven is unaware of maven-compiler-plugin params, so it cannot topo sort the project. BUT, if we start referring to them as project/dependencies/module:annotationProcessor, we make Maven _aware_ of inter module dependencies... T On Sun, Oct 29, 2023 at 12:11 PM Tamás Cservenák <ta...@cservenak.net> wrote: > 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. > > 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 >> > >> > >> >
