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