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