subject:"Maven 5 pom extension for agents"

Ps (seems i lost a paragraph): how does it work in consumer pom, breaks
most consumers which will assume right a single jar cant be found twice in
deps no?

Le sam. 4 nov. 2023 à 14:39, Romain Manni-Bucau  a
écrit :

> I still see it as abusing of extension to create sets.
> Means you can only do it while it is jars - how would it work with .jmod
> for ext?
>
> Now the critical part: how do plugin know about it?
>
> Ie is it better to define a ton of potentially conflicting default names +
> add name config in all plugins or just let plugin configure an artifact
> filter and not change anything to our model keeping type for extensions
> most of the time.
>
> I clearly vote for this last option and -0.1for type usage cause it is
> less intrusive and more generic but if you assume all exts are always jar
> and all plugins get types config, agree it can work even if dirty in terms
> of design IMHO.
>
> Le sam. 4 nov. 2023 à 13:50, Tamás Cservenák  a
> écrit :
>
>> Like this
>> https://gist.github.com/cstamas/dd3795fd47f15a28d48a8c03fa9dd939
>>
>> This is completely legal from mvn pov (no warning, unlike same artifact in
>> two scopes)
>>
>> T
>>
>>
>> On Sat, Nov 4, 2023, 13:48 Romain Manni-Bucau 
>> wrote:
>>
>> > How does an artifact has 2 types (it is the main issue with this
>> design)?
>> >
>> > Le sam. 4 nov. 2023 à 11:05, Tamás Cservenák  a
>> > écrit :
>> >
>> > > So, just for fun, I used MIMA /w local mods (MIMA is vanilla mvn39
>> > models +
>> > > resolver1) to resolve one of my demo modules:
>> > > (neglect the root type of "dinosaur"...Also, this is really
>> simplified,
>> > > _resolving_ this graph would FAIL, as MIMA has no idea what "module"
>> type
>> > > is, as can be seen in GAVs, where extension="module"=type)
>> > > https://gist.github.com/cstamas/79f9a01d661209fe302ba92b0de9ab69
>> > >
>> > > It shows how even pure resolver 1.x behaves, just check the tree for
>> > > "annotation-processor" and "module" types, everything is there.
>> > > Basically, even though resolver1 API is able to express these things,
>> the
>> > > problem is that the Maven3 API is not (ArtifactHandler).
>> > >
>> > > T
>> > >
>> > > On Sat, Nov 4, 2023 at 10:43 AM Tamás Cservenák 
>> > > wrote:
>> > >
>> > > > Well, I have to disagree...
>> > > >
>> > > > Maven Core has no idea what "add to classpath" means, and the flag
>> is
>> > not
>> > > > even used in core. Same would stand for MP etc.
>> > > > Maven Core (simplified: the POM) tells WHAT IT IS only.
>> > > >
>> > > > Maven Plugin is the one who uses the core provided information to
>> > process
>> > > > things. So Plugin should know HOW TO USE IT.
>> > > >
>> > > > This is an important distinction in Maven, as otherwise plugin logic
>> > > would
>> > > > creep into core (like it did with site in Maven2) or other way
>> > around...
>> > > >
>> > > > Basically, IMO types are good as it is, as you describe what it is
>> (or
>> > > > what you think it is), and plugin by using APIs (and yes, maybe some
>> > > > "hints" from config) should be able to deduce how to make use of
>> those
>> > > > things.
>> > > >
>> > > >
>> > > > On Sat, Nov 4, 2023 at 10:35 AM Romain Manni-Bucau <
>> > > rmannibu...@gmail.com>
>> > > > wrote:
>> > > >
>> > > >> Yes, this is the part I find broken in maven design (even mvn3) 1nd
>> > hope
>> > > >> we
>> > > >> stop abusing.
>> > > >> Also note it keeps the flag per maven module whereas we have a need
>> > per
>> > > >> plugin.
>> > > >> So first step is to fix plugin config to get them filters of
>> artifacts
>> > > per
>> > > >> their "paths" and sounds like it will be sufficient, no?
>> > > >> Type would just make some non sufficient (maybe convenient, im not
>> > > >> convinced from my XP but will not fight on this) default and
>> > transitive
>> > > >> issues but sounds like solething to do some years after the plugin
>> > > config
>> > > >> fix.
>> > > >>
>> > > >> Do we want to normalize the way to filter maven module artifacts in
>> > > plugin
>> > > >> configs?
>> > > >>
>> > > >> Le sam. 4 nov. 2023 à 10:25, Tamás Cservenák 
>> a
>> > > >> écrit :
>> > > >>
>> > > >> > So, just to explain w/ code:
>> > > >> > In Maven3 ArtifactHandler (type=id selects a handler) looks like
>> > this:
>> > > >> >
>> > > >> >
>> > > >>
>> > >
>> >
>> https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L55
>> > > >> >
>> > > >> > And you can spot the two boolean "lfags": addedToClasspath (CP)
>> and
>> > > >> > includesDependencies (ID).
>> > > >> >
>> > > >> > Maven4 master corresponding Type looks like this:
>> > > >> >
>> > > >> >
>> > > >>
>> > >
>> >
>> https://github.com/apache/maven/blob/master/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java#L80
>> > > >> >
>> > > >> > Same two boolean flags.
>> > > >> >
>> > > >> > In my PoC PR this is generalized:
>> > > >> >
>> > > >> >
>> > > >>
>> > >
>> >
>> https://github.com/cstamas/maven/blob/module

Re: Maven 5 pom extension for agents

I still see it as abusing of extension to create sets.
Means you can only do it while it is jars - how would it work with .jmod
for ext?

Now the critical part: how do plugin know about it?

Ie is it better to define a ton of potentially conflicting default names +
add name config in all plugins or just let plugin configure an artifact
filter and not change anything to our model keeping type for extensions
most of the time.

I clearly vote for this last option and -0.1for type usage cause it is less
intrusive and more generic but if you assume all exts are always jar and
all plugins get types config, agree it can work even if dirty in terms of
design IMHO.

Le sam. 4 nov. 2023 à 13:50, Tamás Cservenák  a écrit :

> Like this
> https://gist.github.com/cstamas/dd3795fd47f15a28d48a8c03fa9dd939
>
> This is completely legal from mvn pov (no warning, unlike same artifact in
> two scopes)
>
> T
>
>
> On Sat, Nov 4, 2023, 13:48 Romain Manni-Bucau 
> wrote:
>
> > How does an artifact has 2 types (it is the main issue with this design)?
> >
> > Le sam. 4 nov. 2023 à 11:05, Tamás Cservenák  a
> > écrit :
> >
> > > So, just for fun, I used MIMA /w local mods (MIMA is vanilla mvn39
> > models +
> > > resolver1) to resolve one of my demo modules:
> > > (neglect the root type of "dinosaur"...Also, this is really simplified,
> > > _resolving_ this graph would FAIL, as MIMA has no idea what "module"
> type
> > > is, as can be seen in GAVs, where extension="module"=type)
> > > https://gist.github.com/cstamas/79f9a01d661209fe302ba92b0de9ab69
> > >
> > > It shows how even pure resolver 1.x behaves, just check the tree for
> > > "annotation-processor" and "module" types, everything is there.
> > > Basically, even though resolver1 API is able to express these things,
> the
> > > problem is that the Maven3 API is not (ArtifactHandler).
> > >
> > > T
> > >
> > > On Sat, Nov 4, 2023 at 10:43 AM Tamás Cservenák 
> > > wrote:
> > >
> > > > Well, I have to disagree...
> > > >
> > > > Maven Core has no idea what "add to classpath" means, and the flag is
> > not
> > > > even used in core. Same would stand for MP etc.
> > > > Maven Core (simplified: the POM) tells WHAT IT IS only.
> > > >
> > > > Maven Plugin is the one who uses the core provided information to
> > process
> > > > things. So Plugin should know HOW TO USE IT.
> > > >
> > > > This is an important distinction in Maven, as otherwise plugin logic
> > > would
> > > > creep into core (like it did with site in Maven2) or other way
> > around...
> > > >
> > > > Basically, IMO types are good as it is, as you describe what it is
> (or
> > > > what you think it is), and plugin by using APIs (and yes, maybe some
> > > > "hints" from config) should be able to deduce how to make use of
> those
> > > > things.
> > > >
> > > >
> > > > On Sat, Nov 4, 2023 at 10:35 AM Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > >> Yes, this is the part I find broken in maven design (even mvn3) 1nd
> > hope
> > > >> we
> > > >> stop abusing.
> > > >> Also note it keeps the flag per maven module whereas we have a need
> > per
> > > >> plugin.
> > > >> So first step is to fix plugin config to get them filters of
> artifacts
> > > per
> > > >> their "paths" and sounds like it will be sufficient, no?
> > > >> Type would just make some non sufficient (maybe convenient, im not
> > > >> convinced from my XP but will not fight on this) default and
> > transitive
> > > >> issues but sounds like solething to do some years after the plugin
> > > config
> > > >> fix.
> > > >>
> > > >> Do we want to normalize the way to filter maven module artifacts in
> > > plugin
> > > >> configs?
> > > >>
> > > >> Le sam. 4 nov. 2023 à 10:25, Tamás Cservenák 
> a
> > > >> écrit :
> > > >>
> > > >> > So, just to explain w/ code:
> > > >> > In Maven3 ArtifactHandler (type=id selects a handler) looks like
> > this:
> > > >> >
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L55
> > > >> >
> > > >> > And you can spot the two boolean "lfags": addedToClasspath (CP)
> and
> > > >> > includesDependencies (ID).
> > > >> >
> > > >> > Maven4 master corresponding Type looks like this:
> > > >> >
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/maven/blob/master/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java#L80
> > > >> >
> > > >> > Same two boolean flags.
> > > >> >
> > > >> > In my PoC PR this is generalized:
> > > >> >
> > > >> >
> > > >>
> > >
> >
> https://github.com/cstamas/maven/blob/module-experiment/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java
> > > >> >
> > > >> > ===
> > > >> >
> > > >> > In mvn3 realm (mvn3 plugin) here is an example how an artifact
> lands
> > > on
> > > >> CP:
> > > >> > the flag is checked
> > > >> >
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/o

Re: Maven 5 pom extension for agents

2023-11-04 Thread Martin Desruisseaux


Le 2023-11-04 à 14 h 02, Tamás Cservenák a écrit :


What would a dependency type=jar, sources be? That represents two 
different files...


Okay, it makes sense to avoid multi-types then. On a second though, even 
when the file is the same, some types are mutually exclusive (e.g. 
"classpath" and "module").


    Martin



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 5 pom extension for agents

No, imho a dependency cannot have two or more types: we are focused on this
topic (jar vs module) but type is more than that, think sources.

In former case we talk about same file (artifact.jar) but representing
different thing (cp or mp candidate).

What would a dependency type=jar, sources be? That represents two different
files...

On Sat, Nov 4, 2023, 13:59 Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:

> Le 2023-11-04 à 13 h 47, Romain Manni-Bucau a écrit :
>
> > How does an artifact has 2 types (it is the main issue with this
> design)?
>
> I also thought about that. For an initial version, Tamas's proposal
> would work. For a solution that avoid repetition, maybe  should
> allow a comma or space-separated list. This is an open question, but not
> necessarily a blocker since a workaround exists for the meantime.
>
>  Martin
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven 5 pom extension for agents

2023-11-04 Thread Martin Desruisseaux


Le 2023-11-04 à 13 h 47, Romain Manni-Bucau a écrit :

How does an artifact has 2 types (it is the main issue with this design)? 


I also thought about that. For an initial version, Tamas's proposal 
would work. For a solution that avoid repetition, maybe  should 
allow a comma or space-separated list. This is an open question, but not 
necessarily a blocker since a workaround exists for the meantime.


    Martin



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 5 pom extension for agents

Like this
https://gist.github.com/cstamas/dd3795fd47f15a28d48a8c03fa9dd939

This is completely legal from mvn pov (no warning, unlike same artifact in
two scopes)

T


On Sat, Nov 4, 2023, 13:48 Romain Manni-Bucau  wrote:

> How does an artifact has 2 types (it is the main issue with this design)?
>
> Le sam. 4 nov. 2023 à 11:05, Tamás Cservenák  a
> écrit :
>
> > So, just for fun, I used MIMA /w local mods (MIMA is vanilla mvn39
> models +
> > resolver1) to resolve one of my demo modules:
> > (neglect the root type of "dinosaur"...Also, this is really simplified,
> > _resolving_ this graph would FAIL, as MIMA has no idea what "module" type
> > is, as can be seen in GAVs, where extension="module"=type)
> > https://gist.github.com/cstamas/79f9a01d661209fe302ba92b0de9ab69
> >
> > It shows how even pure resolver 1.x behaves, just check the tree for
> > "annotation-processor" and "module" types, everything is there.
> > Basically, even though resolver1 API is able to express these things, the
> > problem is that the Maven3 API is not (ArtifactHandler).
> >
> > T
> >
> > On Sat, Nov 4, 2023 at 10:43 AM Tamás Cservenák 
> > wrote:
> >
> > > Well, I have to disagree...
> > >
> > > Maven Core has no idea what "add to classpath" means, and the flag is
> not
> > > even used in core. Same would stand for MP etc.
> > > Maven Core (simplified: the POM) tells WHAT IT IS only.
> > >
> > > Maven Plugin is the one who uses the core provided information to
> process
> > > things. So Plugin should know HOW TO USE IT.
> > >
> > > This is an important distinction in Maven, as otherwise plugin logic
> > would
> > > creep into core (like it did with site in Maven2) or other way
> around...
> > >
> > > Basically, IMO types are good as it is, as you describe what it is (or
> > > what you think it is), and plugin by using APIs (and yes, maybe some
> > > "hints" from config) should be able to deduce how to make use of those
> > > things.
> > >
> > >
> > > On Sat, Nov 4, 2023 at 10:35 AM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > >> Yes, this is the part I find broken in maven design (even mvn3) 1nd
> hope
> > >> we
> > >> stop abusing.
> > >> Also note it keeps the flag per maven module whereas we have a need
> per
> > >> plugin.
> > >> So first step is to fix plugin config to get them filters of artifacts
> > per
> > >> their "paths" and sounds like it will be sufficient, no?
> > >> Type would just make some non sufficient (maybe convenient, im not
> > >> convinced from my XP but will not fight on this) default and
> transitive
> > >> issues but sounds like solething to do some years after the plugin
> > config
> > >> fix.
> > >>
> > >> Do we want to normalize the way to filter maven module artifacts in
> > plugin
> > >> configs?
> > >>
> > >> Le sam. 4 nov. 2023 à 10:25, Tamás Cservenák  a
> > >> écrit :
> > >>
> > >> > So, just to explain w/ code:
> > >> > In Maven3 ArtifactHandler (type=id selects a handler) looks like
> this:
> > >> >
> > >> >
> > >>
> >
> https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L55
> > >> >
> > >> > And you can spot the two boolean "lfags": addedToClasspath (CP) and
> > >> > includesDependencies (ID).
> > >> >
> > >> > Maven4 master corresponding Type looks like this:
> > >> >
> > >> >
> > >>
> >
> https://github.com/apache/maven/blob/master/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java#L80
> > >> >
> > >> > Same two boolean flags.
> > >> >
> > >> > In my PoC PR this is generalized:
> > >> >
> > >> >
> > >>
> >
> https://github.com/cstamas/maven/blob/module-experiment/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java
> > >> >
> > >> > ===
> > >> >
> > >> > In mvn3 realm (mvn3 plugin) here is an example how an artifact lands
> > on
> > >> CP:
> > >> > the flag is checked
> > >> >
> > >> >
> > >>
> >
> https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/TestClassPath.java#L63
> > >> >
> > >> > And from that point on, starts the "guesswork" (is it a module
> maybe?)
> > >> >
> > >> > A mvn4 plugin could make much fine-grainer checks (CP, MP etc). My
> > idea
> > >> was
> > >> > really just to make things _explicit_.
> > >> >
> > >> > Thanks
> > >> > T
> > >> >
> > >> >
> > >> > On Sat, Nov 4, 2023 at 9:58 AM Tamás Cservenák  >
> > >> > wrote:
> > >> >
> > >> > > Well, even mvn3 works like it today, except it has "fixed set" of
> > >> flags.
> > >> > > All i did is opened up the number of possible flags, added MP
> (next
> > to
> > >> > > existing CP flag from mvn 3). Types were really eztensible in mvn3
> > as
> > >> > well,
> > >> > > but less expressive with fixed set of flags.
> > >> > >
> > >> > > Basically even in mvn3, an artifact lands on CP if it has CP flag
> > >> set...
> > >> > > No radical change in this area.
> > >> > >
> > >> > > T
> > >> > >
> > >> > > On Sat, Nov 4, 2023, 08:49

Re: Maven 5 pom extension for agents

How does an artifact has 2 types (it is the main issue with this design)?

Le sam. 4 nov. 2023 à 11:05, Tamás Cservenák  a écrit :

> So, just for fun, I used MIMA /w local mods (MIMA is vanilla mvn39 models +
> resolver1) to resolve one of my demo modules:
> (neglect the root type of "dinosaur"...Also, this is really simplified,
> _resolving_ this graph would FAIL, as MIMA has no idea what "module" type
> is, as can be seen in GAVs, where extension="module"=type)
> https://gist.github.com/cstamas/79f9a01d661209fe302ba92b0de9ab69
>
> It shows how even pure resolver 1.x behaves, just check the tree for
> "annotation-processor" and "module" types, everything is there.
> Basically, even though resolver1 API is able to express these things, the
> problem is that the Maven3 API is not (ArtifactHandler).
>
> T
>
> On Sat, Nov 4, 2023 at 10:43 AM Tamás Cservenák 
> wrote:
>
> > Well, I have to disagree...
> >
> > Maven Core has no idea what "add to classpath" means, and the flag is not
> > even used in core. Same would stand for MP etc.
> > Maven Core (simplified: the POM) tells WHAT IT IS only.
> >
> > Maven Plugin is the one who uses the core provided information to process
> > things. So Plugin should know HOW TO USE IT.
> >
> > This is an important distinction in Maven, as otherwise plugin logic
> would
> > creep into core (like it did with site in Maven2) or other way around...
> >
> > Basically, IMO types are good as it is, as you describe what it is (or
> > what you think it is), and plugin by using APIs (and yes, maybe some
> > "hints" from config) should be able to deduce how to make use of those
> > things.
> >
> >
> > On Sat, Nov 4, 2023 at 10:35 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> Yes, this is the part I find broken in maven design (even mvn3) 1nd hope
> >> we
> >> stop abusing.
> >> Also note it keeps the flag per maven module whereas we have a need per
> >> plugin.
> >> So first step is to fix plugin config to get them filters of artifacts
> per
> >> their "paths" and sounds like it will be sufficient, no?
> >> Type would just make some non sufficient (maybe convenient, im not
> >> convinced from my XP but will not fight on this) default and transitive
> >> issues but sounds like solething to do some years after the plugin
> config
> >> fix.
> >>
> >> Do we want to normalize the way to filter maven module artifacts in
> plugin
> >> configs?
> >>
> >> Le sam. 4 nov. 2023 à 10:25, Tamás Cservenák  a
> >> écrit :
> >>
> >> > So, just to explain w/ code:
> >> > In Maven3 ArtifactHandler (type=id selects a handler) looks like this:
> >> >
> >> >
> >>
> https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L55
> >> >
> >> > And you can spot the two boolean "lfags": addedToClasspath (CP) and
> >> > includesDependencies (ID).
> >> >
> >> > Maven4 master corresponding Type looks like this:
> >> >
> >> >
> >>
> https://github.com/apache/maven/blob/master/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java#L80
> >> >
> >> > Same two boolean flags.
> >> >
> >> > In my PoC PR this is generalized:
> >> >
> >> >
> >>
> https://github.com/cstamas/maven/blob/module-experiment/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java
> >> >
> >> > ===
> >> >
> >> > In mvn3 realm (mvn3 plugin) here is an example how an artifact lands
> on
> >> CP:
> >> > the flag is checked
> >> >
> >> >
> >>
> https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/TestClassPath.java#L63
> >> >
> >> > And from that point on, starts the "guesswork" (is it a module maybe?)
> >> >
> >> > A mvn4 plugin could make much fine-grainer checks (CP, MP etc). My
> idea
> >> was
> >> > really just to make things _explicit_.
> >> >
> >> > Thanks
> >> > T
> >> >
> >> >
> >> > On Sat, Nov 4, 2023 at 9:58 AM Tamás Cservenák 
> >> > wrote:
> >> >
> >> > > Well, even mvn3 works like it today, except it has "fixed set" of
> >> flags.
> >> > > All i did is opened up the number of possible flags, added MP (next
> to
> >> > > existing CP flag from mvn 3). Types were really eztensible in mvn3
> as
> >> > well,
> >> > > but less expressive with fixed set of flags.
> >> > >
> >> > > Basically even in mvn3, an artifact lands on CP if it has CP flag
> >> set...
> >> > > No radical change in this area.
> >> > >
> >> > > T
> >> > >
> >> > > On Sat, Nov 4, 2023, 08:49 Romain Manni-Bucau <
> rmannibu...@gmail.com>
> >> > > wrote:
> >> > >
> >> > >> Doesnt it mean you dont need type at all.
> >> > >> I understand the idea to add new method in the handler but this is
> >> > really
> >> > >> a
> >> > >> weird design and still blocked by the predefined set so user is
> still
> >> > >> locked by design so not sure how it helps to rely on type.
> >> > >>
> >> > >> Le ven. 3 nov. 2023 à 21:44, Tamás Cservenák 
> a
> >> > >> écrit :
> >> > >>
> >> > >> > Just 5 cents:
> >> > >> >

Re: Maven 5 pom extension for agents

2023-11-04 Thread Martin Desruisseaux


Le 2023-11-03 à 21 h 30, Romain Manni-Bucau a écrit :

The  proposal would put the dependency on whatever path the 
 said it should be. 

Means you create as much type as plugin*pathTypePerPlugin, looks overkill.


The current set of new path types would contain about 6 types (class, 
module, taglet, doclet, agent, annotation-processor). Maybe more types 
would need to be added for new plugins, but I presume we could design a 
mechanism for allowing plugins to extend the set of types.


By comparison, the DependencySet approach can also be seen as an 
overkill, and conflicts with the goal of not forcing users to care about 
class-path / module-path distinction unless they need to. The  
approach has the advantage of being optional.



And just using class/module paths does not work, so ultimately plugins 
will need filters and maybe just rely on scopes+filters 


A filtering-per-plugin is already done by test, 
runtime, etc. Is there a need for another filtering 
mechanism? As far as JPMS is concerned, the current  mechanism 
works unchanged. Other aspects such as --add-exports or --limit-modules 
options can be handled separately as proposed in previous emails. So I 
think we can keep this thread focused on only paths.


Yes, but you just added a jaxws type to maven core - see why this does 
no scale/work?


I'm not familiar with JAXWS. Would it be because it would add a new kind 
of path in addition of class-path and module-path? If yes, then as said 
above, maybe it is possible to design the set of types in an extensible 
way. If JAXWS also adds a need for a new filtering condition, then maybe 
the set of scopes can also be designed as extensible.



I'm not sure if you are talking about the Java compiler's "Module 
Source Hierarchy" here. If yes, this is indeed something that I would 
like, but I'm not trying to push that for Maven
This already works with maven, needs to tune the folder layouts and a 
few plugins - (…snip…) so not sure what misses there.


Maven is missing all the plugins. Many of them would need major work. 
But anyway, this is not the topic of this thread.



Thanks for the configuration tip, but it works by setting the 
--class-path and --module-path options in the  block of 
the exec-maven-plugin. My issue was also execution with surefire, 
javadoc, etc. All plugins need the same configuration. 
It is the same there, nothing relates to depency type (which is my 
point).


I was not clear. The java, javac, javap, jdeps, javadoc and jshell tools 
all have the same class-path and module-path options. Projects typically 
need to set the same paths for all those tools, with variations 
controlled by the  element in dependency declarations. The 
configuration tip in previous email was replacing the Maven classpath 
management by full command-line arguments passed to Java in the 
maven-exec-plugin. That tip would require to repeat the same 
configuration overriding in all plugins (surefire, javadoc, etc.), each 
with their own syntax, and forces all users of the library to do the 
same on their side. Basically, it was transforming Maven into Ant.




Global configuration is also desirable (…snip…).
I see a lot of overlap but no 1-1 cases except on simple projects. 
Compiler != Surefire != Javadoc for ex, this is why type looks very 
limiting until combinable or each plugin has filter capability which 
also mean type is useless. 


The filtering is already done by test, 
runtime, etc. What else do we need? JPMS needs no change 
at all on this aspect. Or are you proposing to adopt DependencySet as a 
replacement for both  and  in general (not only for the 
topic of this thread)?


For trying to get this discussion to converge, can we try to agree on 
the design goals? I see the following ones:


1. Make possible to declare paths globally, for sharing by all plugins.
2. Allow per-plugin filtering. This is already done in Maven 3 by .
3. Allow library developers to specify what should be on the module-path.
4. Free users from bothering about class/module paths when above works.
5. Allow users to override if they need to, similar to overriding versions.
6. Minimize changes compared to current way that Maven work.

The  proposal extends an existing concept rather than introducing 
a new one. Filtering is done by  and needs no change for JPMS. 
The way transitive dependencies are managed, and the way users can 
override, is the same as what Maven does today with dependency versions. 
Type and scope are optional, allowing users to ignore as long as the 
defaults work for them.


In my understanding, DependencySet would be a new concept. It seems to 
be a replacement for both  and , thus introducing a 
significant shift in the way peoples use Maven. It would force users to 
care about class-path versus module-path difference instead of bothering 
only if they need to. It does not allow the class-path / module-path 
preference to be expressed by the library producer instead of the user. 
But of co

Re: Maven 5 pom extension for agents

So, just for fun, I used MIMA /w local mods (MIMA is vanilla mvn39 models +
resolver1) to resolve one of my demo modules:
(neglect the root type of "dinosaur"...Also, this is really simplified,
_resolving_ this graph would FAIL, as MIMA has no idea what "module" type
is, as can be seen in GAVs, where extension="module"=type)
https://gist.github.com/cstamas/79f9a01d661209fe302ba92b0de9ab69

It shows how even pure resolver 1.x behaves, just check the tree for
"annotation-processor" and "module" types, everything is there.
Basically, even though resolver1 API is able to express these things, the
problem is that the Maven3 API is not (ArtifactHandler).

T

On Sat, Nov 4, 2023 at 10:43 AM Tamás Cservenák  wrote:

> Well, I have to disagree...
>
> Maven Core has no idea what "add to classpath" means, and the flag is not
> even used in core. Same would stand for MP etc.
> Maven Core (simplified: the POM) tells WHAT IT IS only.
>
> Maven Plugin is the one who uses the core provided information to process
> things. So Plugin should know HOW TO USE IT.
>
> This is an important distinction in Maven, as otherwise plugin logic would
> creep into core (like it did with site in Maven2) or other way around...
>
> Basically, IMO types are good as it is, as you describe what it is (or
> what you think it is), and plugin by using APIs (and yes, maybe some
> "hints" from config) should be able to deduce how to make use of those
> things.
>
>
> On Sat, Nov 4, 2023 at 10:35 AM Romain Manni-Bucau 
> wrote:
>
>> Yes, this is the part I find broken in maven design (even mvn3) 1nd hope
>> we
>> stop abusing.
>> Also note it keeps the flag per maven module whereas we have a need per
>> plugin.
>> So first step is to fix plugin config to get them filters of artifacts per
>> their "paths" and sounds like it will be sufficient, no?
>> Type would just make some non sufficient (maybe convenient, im not
>> convinced from my XP but will not fight on this) default and transitive
>> issues but sounds like solething to do some years after the plugin config
>> fix.
>>
>> Do we want to normalize the way to filter maven module artifacts in plugin
>> configs?
>>
>> Le sam. 4 nov. 2023 à 10:25, Tamás Cservenák  a
>> écrit :
>>
>> > So, just to explain w/ code:
>> > In Maven3 ArtifactHandler (type=id selects a handler) looks like this:
>> >
>> >
>> https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L55
>> >
>> > And you can spot the two boolean "lfags": addedToClasspath (CP) and
>> > includesDependencies (ID).
>> >
>> > Maven4 master corresponding Type looks like this:
>> >
>> >
>> https://github.com/apache/maven/blob/master/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java#L80
>> >
>> > Same two boolean flags.
>> >
>> > In my PoC PR this is generalized:
>> >
>> >
>> https://github.com/cstamas/maven/blob/module-experiment/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java
>> >
>> > ===
>> >
>> > In mvn3 realm (mvn3 plugin) here is an example how an artifact lands on
>> CP:
>> > the flag is checked
>> >
>> >
>> https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/TestClassPath.java#L63
>> >
>> > And from that point on, starts the "guesswork" (is it a module maybe?)
>> >
>> > A mvn4 plugin could make much fine-grainer checks (CP, MP etc). My idea
>> was
>> > really just to make things _explicit_.
>> >
>> > Thanks
>> > T
>> >
>> >
>> > On Sat, Nov 4, 2023 at 9:58 AM Tamás Cservenák 
>> > wrote:
>> >
>> > > Well, even mvn3 works like it today, except it has "fixed set" of
>> flags.
>> > > All i did is opened up the number of possible flags, added MP (next to
>> > > existing CP flag from mvn 3). Types were really eztensible in mvn3 as
>> > well,
>> > > but less expressive with fixed set of flags.
>> > >
>> > > Basically even in mvn3, an artifact lands on CP if it has CP flag
>> set...
>> > > No radical change in this area.
>> > >
>> > > T
>> > >
>> > > On Sat, Nov 4, 2023, 08:49 Romain Manni-Bucau 
>> > > wrote:
>> > >
>> > >> Doesnt it mean you dont need type at all.
>> > >> I understand the idea to add new method in the handler but this is
>> > really
>> > >> a
>> > >> weird design and still blocked by the predefined set so user is still
>> > >> locked by design so not sure how it helps to rely on type.
>> > >>
>> > >> Le ven. 3 nov. 2023 à 21:44, Tamás Cservenák  a
>> > >> écrit :
>> > >>
>> > >> > Just 5 cents:
>> > >> >
>> > >> > Plugins (as "consumer of dependency") would NOT handle with type
>> > >> > _directlty_, but the _flags_.
>> > >> >
>> > >> > So, if you look at this table (a bit outdated):
>> > >> > https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
>> > >> >
>> > >> > m-compiler-p: handles artifacts flagged with CP, MP, AP
>> > >> > m-javadoc-p: handles artifacts flagged with DOC
>> > >> > and so on (just roughly to explain the idea).
>> > >> >
>> >

Re: Maven 5 pom extension for agents

Well, I have to disagree...

Maven Core has no idea what "add to classpath" means, and the flag is not
even used in core. Same would stand for MP etc.
Maven Core (simplified: the POM) tells WHAT IT IS only.

Maven Plugin is the one who uses the core provided information to process
things. So Plugin should know HOW TO USE IT.

This is an important distinction in Maven, as otherwise plugin logic would
creep into core (like it did with site in Maven2) or other way around...

Basically, IMO types are good as it is, as you describe what it is (or what
you think it is), and plugin by using APIs (and yes, maybe some "hints"
from config) should be able to deduce how to make use of those things.


On Sat, Nov 4, 2023 at 10:35 AM Romain Manni-Bucau 
wrote:

> Yes, this is the part I find broken in maven design (even mvn3) 1nd hope we
> stop abusing.
> Also note it keeps the flag per maven module whereas we have a need per
> plugin.
> So first step is to fix plugin config to get them filters of artifacts per
> their "paths" and sounds like it will be sufficient, no?
> Type would just make some non sufficient (maybe convenient, im not
> convinced from my XP but will not fight on this) default and transitive
> issues but sounds like solething to do some years after the plugin config
> fix.
>
> Do we want to normalize the way to filter maven module artifacts in plugin
> configs?
>
> Le sam. 4 nov. 2023 à 10:25, Tamás Cservenák  a
> écrit :
>
> > So, just to explain w/ code:
> > In Maven3 ArtifactHandler (type=id selects a handler) looks like this:
> >
> >
> https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L55
> >
> > And you can spot the two boolean "lfags": addedToClasspath (CP) and
> > includesDependencies (ID).
> >
> > Maven4 master corresponding Type looks like this:
> >
> >
> https://github.com/apache/maven/blob/master/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java#L80
> >
> > Same two boolean flags.
> >
> > In my PoC PR this is generalized:
> >
> >
> https://github.com/cstamas/maven/blob/module-experiment/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java
> >
> > ===
> >
> > In mvn3 realm (mvn3 plugin) here is an example how an artifact lands on
> CP:
> > the flag is checked
> >
> >
> https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/TestClassPath.java#L63
> >
> > And from that point on, starts the "guesswork" (is it a module maybe?)
> >
> > A mvn4 plugin could make much fine-grainer checks (CP, MP etc). My idea
> was
> > really just to make things _explicit_.
> >
> > Thanks
> > T
> >
> >
> > On Sat, Nov 4, 2023 at 9:58 AM Tamás Cservenák 
> > wrote:
> >
> > > Well, even mvn3 works like it today, except it has "fixed set" of
> flags.
> > > All i did is opened up the number of possible flags, added MP (next to
> > > existing CP flag from mvn 3). Types were really eztensible in mvn3 as
> > well,
> > > but less expressive with fixed set of flags.
> > >
> > > Basically even in mvn3, an artifact lands on CP if it has CP flag
> set...
> > > No radical change in this area.
> > >
> > > T
> > >
> > > On Sat, Nov 4, 2023, 08:49 Romain Manni-Bucau 
> > > wrote:
> > >
> > >> Doesnt it mean you dont need type at all.
> > >> I understand the idea to add new method in the handler but this is
> > really
> > >> a
> > >> weird design and still blocked by the predefined set so user is still
> > >> locked by design so not sure how it helps to rely on type.
> > >>
> > >> Le ven. 3 nov. 2023 à 21:44, Tamás Cservenák  a
> > >> écrit :
> > >>
> > >> > Just 5 cents:
> > >> >
> > >> > Plugins (as "consumer of dependency") would NOT handle with type
> > >> > _directlty_, but the _flags_.
> > >> >
> > >> > So, if you look at this table (a bit outdated):
> > >> > https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
> > >> >
> > >> > m-compiler-p: handles artifacts flagged with CP, MP, AP
> > >> > m-javadoc-p: handles artifacts flagged with DOC
> > >> > and so on (just roughly to explain the idea).
> > >> >
> > >> > And nothing stops you to declare as many types as many needed (to
> > >> describe
> > >> > what you want), the plugins will go for flags only.
> > >> >
> > >> > So in short: plugins will not go for type, the go for flags defined
> by
> > >> > types (and many type can use same flag)
> > >> >
> > >> > T
> > >> >
> > >> >
> > >> >
> > >> > On Fri, Nov 3, 2023 at 9:31 PM Romain Manni-Bucau <
> > >> rmannibu...@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Le ven. 3 nov. 2023 à 20:55, Martin Desruisseaux <
> > >> > > martin.desruisse...@geomatys.com> a écrit :
> > >> > >
> > >> > > > Le 2023-11-03 à 19 h 33, Romain Manni-Bucau a écrit :
> > >> > > >
> > >> > > > >> putting a dependency on the module-path of a non-JPMS
> > application
> > >> > > > >> such as Spring is okay
> > >> > > > >>
> > >> > > > > Is not ok for me and is a big hidden bu

Re: Maven 5 pom extension for agents

Yes, this is the part I find broken in maven design (even mvn3) 1nd hope we
stop abusing.
Also note it keeps the flag per maven module whereas we have a need per
plugin.
So first step is to fix plugin config to get them filters of artifacts per
their "paths" and sounds like it will be sufficient, no?
Type would just make some non sufficient (maybe convenient, im not
convinced from my XP but will not fight on this) default and transitive
issues but sounds like solething to do some years after the plugin config
fix.

Do we want to normalize the way to filter maven module artifacts in plugin
configs?

Le sam. 4 nov. 2023 à 10:25, Tamás Cservenák  a écrit :

> So, just to explain w/ code:
> In Maven3 ArtifactHandler (type=id selects a handler) looks like this:
>
> https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L55
>
> And you can spot the two boolean "lfags": addedToClasspath (CP) and
> includesDependencies (ID).
>
> Maven4 master corresponding Type looks like this:
>
> https://github.com/apache/maven/blob/master/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java#L80
>
> Same two boolean flags.
>
> In my PoC PR this is generalized:
>
> https://github.com/cstamas/maven/blob/module-experiment/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java
>
> ===
>
> In mvn3 realm (mvn3 plugin) here is an example how an artifact lands on CP:
> the flag is checked
>
> https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/TestClassPath.java#L63
>
> And from that point on, starts the "guesswork" (is it a module maybe?)
>
> A mvn4 plugin could make much fine-grainer checks (CP, MP etc). My idea was
> really just to make things _explicit_.
>
> Thanks
> T
>
>
> On Sat, Nov 4, 2023 at 9:58 AM Tamás Cservenák 
> wrote:
>
> > Well, even mvn3 works like it today, except it has "fixed set" of flags.
> > All i did is opened up the number of possible flags, added MP (next to
> > existing CP flag from mvn 3). Types were really eztensible in mvn3 as
> well,
> > but less expressive with fixed set of flags.
> >
> > Basically even in mvn3, an artifact lands on CP if it has CP flag set...
> > No radical change in this area.
> >
> > T
> >
> > On Sat, Nov 4, 2023, 08:49 Romain Manni-Bucau 
> > wrote:
> >
> >> Doesnt it mean you dont need type at all.
> >> I understand the idea to add new method in the handler but this is
> really
> >> a
> >> weird design and still blocked by the predefined set so user is still
> >> locked by design so not sure how it helps to rely on type.
> >>
> >> Le ven. 3 nov. 2023 à 21:44, Tamás Cservenák  a
> >> écrit :
> >>
> >> > Just 5 cents:
> >> >
> >> > Plugins (as "consumer of dependency") would NOT handle with type
> >> > _directlty_, but the _flags_.
> >> >
> >> > So, if you look at this table (a bit outdated):
> >> > https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
> >> >
> >> > m-compiler-p: handles artifacts flagged with CP, MP, AP
> >> > m-javadoc-p: handles artifacts flagged with DOC
> >> > and so on (just roughly to explain the idea).
> >> >
> >> > And nothing stops you to declare as many types as many needed (to
> >> describe
> >> > what you want), the plugins will go for flags only.
> >> >
> >> > So in short: plugins will not go for type, the go for flags defined by
> >> > types (and many type can use same flag)
> >> >
> >> > T
> >> >
> >> >
> >> >
> >> > On Fri, Nov 3, 2023 at 9:31 PM Romain Manni-Bucau <
> >> rmannibu...@gmail.com>
> >> > wrote:
> >> >
> >> > > Le ven. 3 nov. 2023 à 20:55, Martin Desruisseaux <
> >> > > martin.desruisse...@geomatys.com> a écrit :
> >> > >
> >> > > > Le 2023-11-03 à 19 h 33, Romain Manni-Bucau a écrit :
> >> > > >
> >> > > > >> putting a dependency on the module-path of a non-JPMS
> application
> >> > > > >> such as Spring is okay
> >> > > > >>
> >> > > > > Is not ok for me and is a big hidden bug of current guess logic
> >> when
> >> > > > > not disabled IMHO, we should drop all that guess code probably.
> >> > > > >
> >> > > > The current guess code in Maven 3 puts the dependency on the
> >> > class-path,
> >> > > > which in my understanding is the behaviour that you want. The
> 
> >> > > > proposal would put the dependency on whatever path the  said
> >> it
> >> > > > should be. If the user is not okay with that, (s)he can override
> in
> >> the
> >> > > > same way that (s)he can override the version of transitive
> >> > dependencies.
> >> > > >
> >> > >
> >> > > Means you create as much type as plugin*pathTypePerPlugin, looks
> >> > overkill.
> >> > > And just using class/module paths does not work, so ultimately
> plugins
> >> > will
> >> > > need filters and maybe just rely on scopes+filters - still trying to
> >> > find a
> >> > > solution making eveyone happy.
> >> > >
> >> > >
> >> > > > A dependency may be designed for working only on the module path
> >> (it is
> >> >

Re: Maven 5 pom extension for agents

So, just to explain w/ code:
In Maven3 ArtifactHandler (type=id selects a handler) looks like this:
https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L55

And you can spot the two boolean "lfags": addedToClasspath (CP) and
includesDependencies (ID).

Maven4 master corresponding Type looks like this:
https://github.com/apache/maven/blob/master/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java#L80

Same two boolean flags.

In my PoC PR this is generalized:
https://github.com/cstamas/maven/blob/module-experiment/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java

===

In mvn3 realm (mvn3 plugin) here is an example how an artifact lands on CP:
the flag is checked
https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/TestClassPath.java#L63

And from that point on, starts the "guesswork" (is it a module maybe?)

A mvn4 plugin could make much fine-grainer checks (CP, MP etc). My idea was
really just to make things _explicit_.

Thanks
T


On Sat, Nov 4, 2023 at 9:58 AM Tamás Cservenák  wrote:

> Well, even mvn3 works like it today, except it has "fixed set" of flags.
> All i did is opened up the number of possible flags, added MP (next to
> existing CP flag from mvn 3). Types were really eztensible in mvn3 as well,
> but less expressive with fixed set of flags.
>
> Basically even in mvn3, an artifact lands on CP if it has CP flag set...
> No radical change in this area.
>
> T
>
> On Sat, Nov 4, 2023, 08:49 Romain Manni-Bucau 
> wrote:
>
>> Doesnt it mean you dont need type at all.
>> I understand the idea to add new method in the handler but this is really
>> a
>> weird design and still blocked by the predefined set so user is still
>> locked by design so not sure how it helps to rely on type.
>>
>> Le ven. 3 nov. 2023 à 21:44, Tamás Cservenák  a
>> écrit :
>>
>> > Just 5 cents:
>> >
>> > Plugins (as "consumer of dependency") would NOT handle with type
>> > _directlty_, but the _flags_.
>> >
>> > So, if you look at this table (a bit outdated):
>> > https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
>> >
>> > m-compiler-p: handles artifacts flagged with CP, MP, AP
>> > m-javadoc-p: handles artifacts flagged with DOC
>> > and so on (just roughly to explain the idea).
>> >
>> > And nothing stops you to declare as many types as many needed (to
>> describe
>> > what you want), the plugins will go for flags only.
>> >
>> > So in short: plugins will not go for type, the go for flags defined by
>> > types (and many type can use same flag)
>> >
>> > T
>> >
>> >
>> >
>> > On Fri, Nov 3, 2023 at 9:31 PM Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> > wrote:
>> >
>> > > Le ven. 3 nov. 2023 à 20:55, Martin Desruisseaux <
>> > > martin.desruisse...@geomatys.com> a écrit :
>> > >
>> > > > Le 2023-11-03 à 19 h 33, Romain Manni-Bucau a écrit :
>> > > >
>> > > > >> putting a dependency on the module-path of a non-JPMS application
>> > > > >> such as Spring is okay
>> > > > >>
>> > > > > Is not ok for me and is a big hidden bug of current guess logic
>> when
>> > > > > not disabled IMHO, we should drop all that guess code probably.
>> > > > >
>> > > > The current guess code in Maven 3 puts the dependency on the
>> > class-path,
>> > > > which in my understanding is the behaviour that you want. The 
>> > > > proposal would put the dependency on whatever path the  said
>> it
>> > > > should be. If the user is not okay with that, (s)he can override in
>> the
>> > > > same way that (s)he can override the version of transitive
>> > dependencies.
>> > > >
>> > >
>> > > Means you create as much type as plugin*pathTypePerPlugin, looks
>> > overkill.
>> > > And just using class/module paths does not work, so ultimately plugins
>> > will
>> > > need filters and maybe just rely on scopes+filters - still trying to
>> > find a
>> > > solution making eveyone happy.
>> > >
>> > >
>> > > > A dependency may be designed for working only on the module path
>> (it is
>> > > > developer's choice as any other software requirement, such as the
>> > > > minimal Java version), which is why I think that by default,
>> dependency
>> > > > should go where the library producer said that it should go. But
>> again,
>> > > > users can override if they want.
>> > > >
>> > > >
>> > > > > Then question is how do you enable modules but this is not a
>> question
>> > > > > for your maven module but per plugin (jaxws plugin will not use
>> the
>> > > > > same modules than compiler nor javadoc for ex). This is where the
>> > type
>> > > > > proposal is not granular enough to handle advanced cases we are
>> > > > > talking about
>> > > > >
>> > > > Are you referring to the --add-modules or --limit-modules options of
>> > > > Java? If so, I think that they are compatible with the 
>> proposal
>> > > > and can be discussed in a next step. The first step that we are
>> trying
>> >

Re: Maven 5 pom extension for agents

Well, even mvn3 works like it today, except it has "fixed set" of flags.
All i did is opened up the number of possible flags, added MP (next to
existing CP flag from mvn 3). Types were really eztensible in mvn3 as well,
but less expressive with fixed set of flags.

Basically even in mvn3, an artifact lands on CP if it has CP flag set... No
radical change in this area.

T

On Sat, Nov 4, 2023, 08:49 Romain Manni-Bucau  wrote:

> Doesnt it mean you dont need type at all.
> I understand the idea to add new method in the handler but this is really a
> weird design and still blocked by the predefined set so user is still
> locked by design so not sure how it helps to rely on type.
>
> Le ven. 3 nov. 2023 à 21:44, Tamás Cservenák  a
> écrit :
>
> > Just 5 cents:
> >
> > Plugins (as "consumer of dependency") would NOT handle with type
> > _directlty_, but the _flags_.
> >
> > So, if you look at this table (a bit outdated):
> > https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
> >
> > m-compiler-p: handles artifacts flagged with CP, MP, AP
> > m-javadoc-p: handles artifacts flagged with DOC
> > and so on (just roughly to explain the idea).
> >
> > And nothing stops you to declare as many types as many needed (to
> describe
> > what you want), the plugins will go for flags only.
> >
> > So in short: plugins will not go for type, the go for flags defined by
> > types (and many type can use same flag)
> >
> > T
> >
> >
> >
> > On Fri, Nov 3, 2023 at 9:31 PM Romain Manni-Bucau  >
> > wrote:
> >
> > > Le ven. 3 nov. 2023 à 20:55, Martin Desruisseaux <
> > > martin.desruisse...@geomatys.com> a écrit :
> > >
> > > > Le 2023-11-03 à 19 h 33, Romain Manni-Bucau a écrit :
> > > >
> > > > >> putting a dependency on the module-path of a non-JPMS application
> > > > >> such as Spring is okay
> > > > >>
> > > > > Is not ok for me and is a big hidden bug of current guess logic
> when
> > > > > not disabled IMHO, we should drop all that guess code probably.
> > > > >
> > > > The current guess code in Maven 3 puts the dependency on the
> > class-path,
> > > > which in my understanding is the behaviour that you want. The 
> > > > proposal would put the dependency on whatever path the  said it
> > > > should be. If the user is not okay with that, (s)he can override in
> the
> > > > same way that (s)he can override the version of transitive
> > dependencies.
> > > >
> > >
> > > Means you create as much type as plugin*pathTypePerPlugin, looks
> > overkill.
> > > And just using class/module paths does not work, so ultimately plugins
> > will
> > > need filters and maybe just rely on scopes+filters - still trying to
> > find a
> > > solution making eveyone happy.
> > >
> > >
> > > > A dependency may be designed for working only on the module path (it
> is
> > > > developer's choice as any other software requirement, such as the
> > > > minimal Java version), which is why I think that by default,
> dependency
> > > > should go where the library producer said that it should go. But
> again,
> > > > users can override if they want.
> > > >
> > > >
> > > > > Then question is how do you enable modules but this is not a
> question
> > > > > for your maven module but per plugin (jaxws plugin will not use the
> > > > > same modules than compiler nor javadoc for ex). This is where the
> > type
> > > > > proposal is not granular enough to handle advanced cases we are
> > > > > talking about
> > > > >
> > > > Are you referring to the --add-modules or --limit-modules options of
> > > > Java? If so, I think that they are compatible with the 
> proposal
> > > > and can be discussed in a next step. The first step that we are
> trying
> > > > to resolve now is to build the module-path. Next, it is indeed
> possible
> > > > to tell Java to "see" only a subset of the modules available on the
> > > > module-path. I think that this option is more typically used when the
> > > > module-path is a whole directory instead than an enumeration of
> > > > dependencies as Maven does. If users nevertheless want to use the
> > > > --add-modules or --limit-modules options, maybe they could be options
> > of
> > > > the exec plugin. Those options are not paths, only comma-separated
> > lists
> > > > of modules names.
> > > >
> > >
> > > Yes, but you just added a jaxws type to maven core - see why this does
> > not
> > > scale/work?
> > > Just means we cant get external plugins anymore or we will duplicate a
> > lot
> > > deps (same gav different type...please no).
> > >
> > >
> > > >
> > > > > (…snip…) ie put all the code in src/main cause by design it is what
> > > > > you want, a single module where maven creates 2 modules per maven
> > > module
> > > > >
> > > > I'm not sure if you are talking about the Java compiler's "Module
> > Source
> > > > Hierarchy" here. If yes, this is indeed something that I would like,
> > but
> > > > I'm not trying to push that for Maven (I presume that it would be a
> too
> > > > big change). My hope for Maven has smalle

Re: Maven 5 pom extension for agents

Doesnt it mean you dont need type at all.
I understand the idea to add new method in the handler but this is really a
weird design and still blocked by the predefined set so user is still
locked by design so not sure how it helps to rely on type.

Le ven. 3 nov. 2023 à 21:44, Tamás Cservenák  a écrit :

> Just 5 cents:
>
> Plugins (as "consumer of dependency") would NOT handle with type
> _directlty_, but the _flags_.
>
> So, if you look at this table (a bit outdated):
> https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
>
> m-compiler-p: handles artifacts flagged with CP, MP, AP
> m-javadoc-p: handles artifacts flagged with DOC
> and so on (just roughly to explain the idea).
>
> And nothing stops you to declare as many types as many needed (to describe
> what you want), the plugins will go for flags only.
>
> So in short: plugins will not go for type, the go for flags defined by
> types (and many type can use same flag)
>
> T
>
>
>
> On Fri, Nov 3, 2023 at 9:31 PM Romain Manni-Bucau 
> wrote:
>
> > Le ven. 3 nov. 2023 à 20:55, Martin Desruisseaux <
> > martin.desruisse...@geomatys.com> a écrit :
> >
> > > Le 2023-11-03 à 19 h 33, Romain Manni-Bucau a écrit :
> > >
> > > >> putting a dependency on the module-path of a non-JPMS application
> > > >> such as Spring is okay
> > > >>
> > > > Is not ok for me and is a big hidden bug of current guess logic when
> > > > not disabled IMHO, we should drop all that guess code probably.
> > > >
> > > The current guess code in Maven 3 puts the dependency on the
> class-path,
> > > which in my understanding is the behaviour that you want. The 
> > > proposal would put the dependency on whatever path the  said it
> > > should be. If the user is not okay with that, (s)he can override in the
> > > same way that (s)he can override the version of transitive
> dependencies.
> > >
> >
> > Means you create as much type as plugin*pathTypePerPlugin, looks
> overkill.
> > And just using class/module paths does not work, so ultimately plugins
> will
> > need filters and maybe just rely on scopes+filters - still trying to
> find a
> > solution making eveyone happy.
> >
> >
> > > A dependency may be designed for working only on the module path (it is
> > > developer's choice as any other software requirement, such as the
> > > minimal Java version), which is why I think that by default, dependency
> > > should go where the library producer said that it should go. But again,
> > > users can override if they want.
> > >
> > >
> > > > Then question is how do you enable modules but this is not a question
> > > > for your maven module but per plugin (jaxws plugin will not use the
> > > > same modules than compiler nor javadoc for ex). This is where the
> type
> > > > proposal is not granular enough to handle advanced cases we are
> > > > talking about
> > > >
> > > Are you referring to the --add-modules or --limit-modules options of
> > > Java? If so, I think that they are compatible with the  proposal
> > > and can be discussed in a next step. The first step that we are trying
> > > to resolve now is to build the module-path. Next, it is indeed possible
> > > to tell Java to "see" only a subset of the modules available on the
> > > module-path. I think that this option is more typically used when the
> > > module-path is a whole directory instead than an enumeration of
> > > dependencies as Maven does. If users nevertheless want to use the
> > > --add-modules or --limit-modules options, maybe they could be options
> of
> > > the exec plugin. Those options are not paths, only comma-separated
> lists
> > > of modules names.
> > >
> >
> > Yes, but you just added a jaxws type to maven core - see why this does
> not
> > scale/work?
> > Just means we cant get external plugins anymore or we will duplicate a
> lot
> > deps (same gav different type...please no).
> >
> >
> > >
> > > > (…snip…) ie put all the code in src/main cause by design it is what
> > > > you want, a single module where maven creates 2 modules per maven
> > module
> > > >
> > > I'm not sure if you are talking about the Java compiler's "Module
> Source
> > > Hierarchy" here. If yes, this is indeed something that I would like,
> but
> > > I'm not trying to push that for Maven (I presume that it would be a too
> > > big change). My hope for Maven has smaller scope: module-path and
> making
> > > easier to setup the --add-exports and --add-opens options.
> > >
> >
> > This already works with maven, needs to tune the folder layouts and a few
> > plugins - and to be honest I hope it never becomes the default, so not
> sure
> > what misses there.
> >
> >
> > > > Not sure I understand the issue, you highlight a bug in exec maven
> > > > plugin (classpath and module path configuration share a single toggle
> > > > - and toString BTW) but ultimately you misconfigured the plugin too:
> > > >
> > > Thanks for the configuration tip, but it works by setting the
> > > --class-path and --module-path options in the  block of the

Re: Maven 5 pom extension for agents

2023-11-03 Thread Tamás Cservenák

Just 5 cents:

Plugins (as "consumer of dependency") would NOT handle with type
_directlty_, but the _flags_.

So, if you look at this table (a bit outdated):
https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8

m-compiler-p: handles artifacts flagged with CP, MP, AP
m-javadoc-p: handles artifacts flagged with DOC
and so on (just roughly to explain the idea).

And nothing stops you to declare as many types as many needed (to describe
what you want), the plugins will go for flags only.

So in short: plugins will not go for type, the go for flags defined by
types (and many type can use same flag)

T



On Fri, Nov 3, 2023 at 9:31 PM Romain Manni-Bucau 
wrote:

> Le ven. 3 nov. 2023 à 20:55, Martin Desruisseaux <
> martin.desruisse...@geomatys.com> a écrit :
>
> > Le 2023-11-03 à 19 h 33, Romain Manni-Bucau a écrit :
> >
> > >> putting a dependency on the module-path of a non-JPMS application
> > >> such as Spring is okay
> > >>
> > > Is not ok for me and is a big hidden bug of current guess logic when
> > > not disabled IMHO, we should drop all that guess code probably.
> > >
> > The current guess code in Maven 3 puts the dependency on the class-path,
> > which in my understanding is the behaviour that you want. The 
> > proposal would put the dependency on whatever path the  said it
> > should be. If the user is not okay with that, (s)he can override in the
> > same way that (s)he can override the version of transitive dependencies.
> >
>
> Means you create as much type as plugin*pathTypePerPlugin, looks overkill.
> And just using class/module paths does not work, so ultimately plugins will
> need filters and maybe just rely on scopes+filters - still trying to find a
> solution making eveyone happy.
>
>
> > A dependency may be designed for working only on the module path (it is
> > developer's choice as any other software requirement, such as the
> > minimal Java version), which is why I think that by default, dependency
> > should go where the library producer said that it should go. But again,
> > users can override if they want.
> >
> >
> > > Then question is how do you enable modules but this is not a question
> > > for your maven module but per plugin (jaxws plugin will not use the
> > > same modules than compiler nor javadoc for ex). This is where the type
> > > proposal is not granular enough to handle advanced cases we are
> > > talking about
> > >
> > Are you referring to the --add-modules or --limit-modules options of
> > Java? If so, I think that they are compatible with the  proposal
> > and can be discussed in a next step. The first step that we are trying
> > to resolve now is to build the module-path. Next, it is indeed possible
> > to tell Java to "see" only a subset of the modules available on the
> > module-path. I think that this option is more typically used when the
> > module-path is a whole directory instead than an enumeration of
> > dependencies as Maven does. If users nevertheless want to use the
> > --add-modules or --limit-modules options, maybe they could be options of
> > the exec plugin. Those options are not paths, only comma-separated lists
> > of modules names.
> >
>
> Yes, but you just added a jaxws type to maven core - see why this does not
> scale/work?
> Just means we cant get external plugins anymore or we will duplicate a lot
> deps (same gav different type...please no).
>
>
> >
> > > (…snip…) ie put all the code in src/main cause by design it is what
> > > you want, a single module where maven creates 2 modules per maven
> module
> > >
> > I'm not sure if you are talking about the Java compiler's "Module Source
> > Hierarchy" here. If yes, this is indeed something that I would like, but
> > I'm not trying to push that for Maven (I presume that it would be a too
> > big change). My hope for Maven has smaller scope: module-path and making
> > easier to setup the --add-exports and --add-opens options.
> >
>
> This already works with maven, needs to tune the folder layouts and a few
> plugins - and to be honest I hope it never becomes the default, so not sure
> what misses there.
>
>
> > > Not sure I understand the issue, you highlight a bug in exec maven
> > > plugin (classpath and module path configuration share a single toggle
> > > - and toString BTW) but ultimately you misconfigured the plugin too:
> > >
> > Thanks for the configuration tip, but it works by setting the
> > --class-path and --module-path options in the  block of the
> > exec-maven-plugin. My issue was also execution with surefire, javadoc,
> > etc. All plugins need the same configuration.
> >
>
> It is the same there, nothing relates to depency type (which is my point).
>
>
> >
> > > it is really about getting split paths more easily than getting a
> > > global for the maven module configuration which will prevent you to
> > > configure accurately each plugin which is actually required for these
> > > advanced JPMS cases (jaxws is really a hurting case).
> > >
> > Global configuration is

Re: Maven 5 pom extension for agents

2023-11-03 Thread Romain Manni-Bucau

Le ven. 3 nov. 2023 à 20:55, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2023-11-03 à 19 h 33, Romain Manni-Bucau a écrit :
>
> >> putting a dependency on the module-path of a non-JPMS application
> >> such as Spring is okay
> >>
> > Is not ok for me and is a big hidden bug of current guess logic when
> > not disabled IMHO, we should drop all that guess code probably.
> >
> The current guess code in Maven 3 puts the dependency on the class-path,
> which in my understanding is the behaviour that you want. The 
> proposal would put the dependency on whatever path the  said it
> should be. If the user is not okay with that, (s)he can override in the
> same way that (s)he can override the version of transitive dependencies.
>

Means you create as much type as plugin*pathTypePerPlugin, looks overkill.
And just using class/module paths does not work, so ultimately plugins will
need filters and maybe just rely on scopes+filters - still trying to find a
solution making eveyone happy.


> A dependency may be designed for working only on the module path (it is
> developer's choice as any other software requirement, such as the
> minimal Java version), which is why I think that by default, dependency
> should go where the library producer said that it should go. But again,
> users can override if they want.
>
>
> > Then question is how do you enable modules but this is not a question
> > for your maven module but per plugin (jaxws plugin will not use the
> > same modules than compiler nor javadoc for ex). This is where the type
> > proposal is not granular enough to handle advanced cases we are
> > talking about
> >
> Are you referring to the --add-modules or --limit-modules options of
> Java? If so, I think that they are compatible with the  proposal
> and can be discussed in a next step. The first step that we are trying
> to resolve now is to build the module-path. Next, it is indeed possible
> to tell Java to "see" only a subset of the modules available on the
> module-path. I think that this option is more typically used when the
> module-path is a whole directory instead than an enumeration of
> dependencies as Maven does. If users nevertheless want to use the
> --add-modules or --limit-modules options, maybe they could be options of
> the exec plugin. Those options are not paths, only comma-separated lists
> of modules names.
>

Yes, but you just added a jaxws type to maven core - see why this does not
scale/work?
Just means we cant get external plugins anymore or we will duplicate a lot
deps (same gav different type...please no).


>
> > (…snip…) ie put all the code in src/main cause by design it is what
> > you want, a single module where maven creates 2 modules per maven module
> >
> I'm not sure if you are talking about the Java compiler's "Module Source
> Hierarchy" here. If yes, this is indeed something that I would like, but
> I'm not trying to push that for Maven (I presume that it would be a too
> big change). My hope for Maven has smaller scope: module-path and making
> easier to setup the --add-exports and --add-opens options.
>

This already works with maven, needs to tune the folder layouts and a few
plugins - and to be honest I hope it never becomes the default, so not sure
what misses there.


> > Not sure I understand the issue, you highlight a bug in exec maven
> > plugin (classpath and module path configuration share a single toggle
> > - and toString BTW) but ultimately you misconfigured the plugin too:
> >
> Thanks for the configuration tip, but it works by setting the
> --class-path and --module-path options in the  block of the
> exec-maven-plugin. My issue was also execution with surefire, javadoc,
> etc. All plugins need the same configuration.
>

It is the same there, nothing relates to depency type (which is my point).


>
> > it is really about getting split paths more easily than getting a
> > global for the maven module configuration which will prevent you to
> > configure accurately each plugin which is actually required for these
> > advanced JPMS cases (jaxws is really a hurting case).
> >
> Global configuration is also desirable. Per-plugin tuning may also be
> desirable, but there is good chances that they would be modifications of
> the global configuration instead of something independent (providing
> that the global configuration has the  proposal).
>

I see a lot of overlap but no 1-1 cases except on simple projects.
Compiler != Surefire != Javadoc for ex, this is why type looks very
limiting until combinable or each plugin has filter capability which also
mean type is useless.


>
> > Agree, default should stay classpath and module path shouldn't be
> > enabled until requested, creates too much weird behaviors IMHO.
> >
> Weird behaviour happens when the library is not on the path it was
> designed for. Weird behaviour if we put a designed-for-class-path
> dependency on the module-path, and potentially broken behaviour if we
> put a designed-fo

Re: Maven 5 pom extension for agents

2023-11-03 Thread Martin Desruisseaux


Le 2023-11-03 à 19 h 33, Romain Manni-Bucau a écrit :

putting a dependency on the module-path of a non-JPMS application 
such as Spring is okay


Is not ok for me and is a big hidden bug of current guess logic when 
not disabled IMHO, we should drop all that guess code probably.


The current guess code in Maven 3 puts the dependency on the class-path, 
which in my understanding is the behaviour that you want. The  
proposal would put the dependency on whatever path the  said it 
should be. If the user is not okay with that, (s)he can override in the 
same way that (s)he can override the version of transitive dependencies.


A dependency may be designed for working only on the module path (it is 
developer's choice as any other software requirement, such as the 
minimal Java version), which is why I think that by default, dependency 
should go where the library producer said that it should go. But again, 
users can override if they want.



Then question is how do you enable modules but this is not a question 
for your maven module but per plugin (jaxws plugin will not use the 
same modules than compiler nor javadoc for ex). This is where the type 
proposal is not granular enough to handle advanced cases we are 
talking about


Are you referring to the --add-modules or --limit-modules options of 
Java? If so, I think that they are compatible with the  proposal 
and can be discussed in a next step. The first step that we are trying 
to resolve now is to build the module-path. Next, it is indeed possible 
to tell Java to "see" only a subset of the modules available on the 
module-path. I think that this option is more typically used when the 
module-path is a whole directory instead than an enumeration of 
dependencies as Maven does. If users nevertheless want to use the 
--add-modules or --limit-modules options, maybe they could be options of 
the exec plugin. Those options are not paths, only comma-separated lists 
of modules names.



(…snip…) ie put all the code in src/main cause by design it is what 
you want, a single module where maven creates 2 modules per maven module


I'm not sure if you are talking about the Java compiler's "Module Source 
Hierarchy" here. If yes, this is indeed something that I would like, but 
I'm not trying to push that for Maven (I presume that it would be a too 
big change). My hope for Maven has smaller scope: module-path and making 
easier to setup the --add-exports and --add-opens options.


Not sure I understand the issue, you highlight a bug in exec maven 
plugin (classpath and module path configuration share a single toggle 
- and toString BTW) but ultimately you misconfigured the plugin too:


Thanks for the configuration tip, but it works by setting the 
--class-path and --module-path options in the  block of the 
exec-maven-plugin. My issue was also execution with surefire, javadoc, 
etc. All plugins need the same configuration.



it is really about getting split paths more easily than getting a 
global for the maven module configuration which will prevent you to 
configure accurately each plugin which is actually required for these 
advanced JPMS cases (jaxws is really a hurting case).


Global configuration is also desirable. Per-plugin tuning may also be 
desirable, but there is good chances that they would be modifications of 
the global configuration instead of something independent (providing 
that the global configuration has the  proposal).



Agree, default should stay classpath and module path shouldn't be 
enabled until requested, creates too much weird behaviors IMHO.


Weird behaviour happens when the library is not on the path it was 
designed for. Weird behaviour if we put a designed-for-class-path 
dependency on the module-path, and potentially broken behaviour if we 
put a designed-for-module-path dependency on the class-path. The reason 
why we do not observe the latter often is because library producers are 
aware that the Java world is still a lot class-path centric, and 
provides workaround in their library for making execution on class-path 
possible.


    Martin

Re: Maven 5 pom extension for agents

2023-11-03 Thread Romain Manni-Bucau

Le ven. 3 nov. 2023 à 17:50, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2023-11-03 à 16 h 45, Romain Manni-Bucau a écrit :
> >
> > The detail point you forget is that since this is a partial solution
> > either nobody cares of it today and it will not be adopted more than
> > today (more later on that) or it will break in the future
> >
> Is the proposal only partial because it does not address the
> --add-exports, --add-opens, etc. options? If yes, I think we can handle
> the latter in an orthogonal way (a proposal was posted in a previous
> email). If no, what is the hole, if we accept that the change is not for
> Maven 3, that transitive dependencies would work like today, that
> putting a dependency on the module-path of a non-JPMS application such
> as Spring is okay, and if the latter is not okay user would have control?
>
>
No no, orthogonal likely not but we can postpone it for sure.

> that
putting a dependency on the module-path of a non-JPMS application such
as Spring is okay

Is not ok for me and is a big hidden bug of current guess logic when not
disabled IMHO, we should drop all that guess code probably.
Then question is how do you enable modules but this is not a question for
your maven module but per plugin (jaxws plugin will not use the same
modules than compiler nor javadoc for ex).
This is where the type proposal is not granular enough to handle advanced
cases we are talking about - others not caring at all about the diff.


>
> > The thing is that projects also use modules (check out helidon,
> > junit5, https://github.com/sormuras/testing-in-the-modular-world for
> > trivial examples).
> >
> It is true that JPMS is possible for *some* Maven projects in current
> situation. But not for all of them. In a previous email, I provided a
> link to a small executable Maven and Gradle project demonstrating a case
> where it does not work, unless we apply some workarounds. I mentioned in
> previous emails that those workarounds are sometime easy, but may also
> be difficult to apply. Those difficulties can be reduced by making
> possible to override the current Maven's heuristic rules, which is
> currently not possible as far as I can see.
>

+1 to do that, it is required in plugins anyway whatever we do to
dependency model and, thinking out loud, can be sufficient for these cases
too, no?


>
> The above "testing-in-the-modular-world" link shows another aspect of
> the problem. For making possible to run JUnit, that project duplicates
> the `src/main/java/module-info.java` file into `src/test/java/` with the
> addition of "exports" statements that are wanted only at test time. Such
> duplication is easy when the `module-info` is small. But it become an
> inconsistency risk when the `module-info` is complex with lot of service
> providers, exports/opens statements, etc. This situation can be improved
> with the  element that I proposed in a previous email. This
> is another topic for another thread, but the point is that there is room
> for improvements and there are proposals on the table that may well work.
>

Hmm, makes years now but thought it was possible to complement it rather
than just override but ultimately this is a setup issue where you would
rather use the nested test classes model you drop at packaging time, ie put
all the code in src/main cause by design it is what you want, a single
module where maven creates 2 modules per maven module, don't think we need
to hack anything there, here again we should just align on java for these
rare cases.


>
>
> > This is why originally I said this is likely not trying to solve any
> > real issue which will end up in plugin configuration more than in the
> > core pom.
> >
> Why the  proposal would not resolve any real issue? I provided a
> executable example of the module-path issue:
>
> https://github.com/Geomatys/MavenModulepathBug


Not sure I understand the issue, you highlight a bug in exec maven plugin
(classpath and module path configuration share a single toggle - and
toString BTW) but ultimately you misconfigured the plugin too:


  org.codehaus.mojo
  exec-maven-plugin
  3.1.0
  
${exec.mainClass}
java
false

  --module-path
  
${project.groupId}:service
  
  --class-path
  
${project.groupId}:${project.artifactId}
  
  --add-modules
  ALL-MODULE-PATH
  ${exec.mainClass}

  



should make it work, you can say you don't want to explicitly list all
paths but dependency plugin also enables to filter artifacts so looks like
it is really about getting split paths more easily than getting a global
for the maven module configuration which will prevent you to configure
accurately each plugin which is actually required for these advanced JPMS
cases (jaxws is really a hurting case).


>
>
> With Tamas's proposal, I could add module in the pom.xml
> file of the "client" module and the problem demonstrated by this test
> case would be solved

Re: Maven 5 pom extension for agents

2023-11-03 Thread Martin Desruisseaux


Le 2023-11-03 à 16 h 45, Romain Manni-Bucau a écrit :


The detail point you forget is that since this is a partial solution 
either nobody cares of it today and it will not be adopted more than 
today (more later on that) or it will break in the future


Is the proposal only partial because it does not address the 
--add-exports, --add-opens, etc. options? If yes, I think we can handle 
the latter in an orthogonal way (a proposal was posted in a previous 
email). If no, what is the hole, if we accept that the change is not for 
Maven 3, that transitive dependencies would work like today, that 
putting a dependency on the module-path of a non-JPMS application such 
as Spring is okay, and if the latter is not okay user would have control?



The thing is that projects also use modules (check out helidon, 
junit5, https://github.com/sormuras/testing-in-the-modular-world for 
trivial examples).


It is true that JPMS is possible for *some* Maven projects in current 
situation. But not for all of them. In a previous email, I provided a 
link to a small executable Maven and Gradle project demonstrating a case 
where it does not work, unless we apply some workarounds. I mentioned in 
previous emails that those workarounds are sometime easy, but may also 
be difficult to apply. Those difficulties can be reduced by making 
possible to override the current Maven's heuristic rules, which is 
currently not possible as far as I can see.


The above "testing-in-the-modular-world" link shows another aspect of 
the problem. For making possible to run JUnit, that project duplicates 
the `src/main/java/module-info.java` file into `src/test/java/` with the 
addition of "exports" statements that are wanted only at test time. Such 
duplication is easy when the `module-info` is small. But it become an 
inconsistency risk when the `module-info` is complex with lot of service 
providers, exports/opens statements, etc. This situation can be improved 
with the  element that I proposed in a previous email. This 
is another topic for another thread, but the point is that there is room 
for improvements and there are proposals on the table that may well work.



This is why originally I said this is likely not trying to solve any 
real issue which will end up in plugin configuration more than in the 
core pom.


Why the  proposal would not resolve any real issue? I provided a 
executable example of the module-path issue:


   https://github.com/Geomatys/MavenModulepathBug

With Tamas's proposal, I could add module in the pom.xml 
file of the "client" module and the problem demonstrated by this test 
case would be solved.



What would be nice and smooth is a hybrid between type and scope - but 
once again I strongly think type should stick to "how to read/map an 
artifact"


Ah, if the debate is about whether  is the right element where to 
specify the type of path, I leave that to you Maven experts. This 
question may join Henning's email on October 30 about the semantic of 
scope, type, classifier, variant, etc. being a bit mixed. The only thing 
is that I believe it should be some element inside , and 
should be optional for allowing users to care about class-path versus 
module-path only when necessary.


    Martin

Re: Maven 5 pom extension for agents

2023-11-03 Thread Tamás Cservenák

Howdy,

That said no issue, I will step down from this thread as you request, goal
> was just to try to not push in a way which will likely not solve the
> original issue and was hurting users by some projects having adopted this
> solution (bundle).


No, I did NOT ask you to "step down from this thread".
I asked you to clarify, elaborate and ideally show code use cases in your
responses.

Thanks
T

On Fri, Nov 3, 2023 at 4:45 PM Romain Manni-Bucau 
wrote:

> Le ven. 3 nov. 2023 à 16:17, Tamás Cservenák  a
> écrit :
>
> > Howdy,
> >
> > @Romain, it seems it is not only me alone having difficulties to
> understand
> > your responses, that are almost always rejecting the idea.
> >
> > I asked you to create a counter example (not "recipe" in prose), you did
> > not. When I joined this thread, I said clearly "this is hardly gonna
> happen
> > in Maven 3 lifespan" (as Maven3 internals are incapable of this) but you
> > bring in your "prose use cases" with Maven 3.x. All this just bloats the
> > thread, blurs it, creates noise, and produces the wrong perception in
> users
> > who are skimming this thread, and is maybe even causing people to abstain
> > from throwing in new ideas...
> >
>
> The detail point you forget is that since this is a partial solution either
> nobody cares of it today and it will not be adopted more than today (more
> later on that) or it will break in the future - I don't think we will want
> to drag this kind of hack for years, most people hope type handler does not
> bring logic - so maven 3 or maven 5 will break this. Maven 3 is just
> obvious and a case we must manage until maven 4 is out - we didn't decide
> yet if it is next year or in 5 years.
>
>
> >
> > So, Romain, I'd kindly ask you to cover your prose with code examples
> > instead, provide us actual and concrete use cases in code, stay on topic,
> > and please remain open for new ideas (I know or can imagine you may do
> > things differently today, but please, then showcase those "better
> > solutions" instead, so pointers to code please with explanation why are
> > those "better").
> >
>
> The thing is that projects also use modules (check out helidon, junit5,
> https://github.com/sormuras/testing-in-the-modular-world for trivial
> examples).
> None had issues with current logic for build but advanced cases need a fine
> control, not just the step you want to bring assuming it helps.
> See it as it is:
>
> * you don't really care, you want to deliver modules -> we do it, nothing
> special
> * you want to deliver modules with a fine control of the build "runtime" ->
> we are quite randomy there so we need to let the user toggle the exact
> command, it is possible but requires a lot of work...likely as much as
> defining configurations/types
>
> This is why originally I said this is likely not trying to solve any real
> issue which will end up in plugin configuration more than in the core pom.
>
> Also bring back the several 7-10 years old threads which request to make
> maven more flexible in its dependency management, we will not solve that.
> Javaagent, JPMS are just low hanging fruits but you have the same issues
> for frontend builds, webjars, and so on.
> I don't see us adding all that in maven core (it is where it must belong in
> your proposal to work).
>
> What would be nice and smooth is a hybrid between type and scope - but once
> again I strongly think type should stick to "how to read/map an artifact",
> one obvious example of that is the method isAddedToClasspath, it just means
> you will need to add one method per type you add, does not scale in terms
> of design nor enable to write extensions properly.
>
> The rational about the scope need is to add or not the artifact depending
> its type - think annotation processors, it wouldnt be shocking to not add
> them to the runtime until request.
> This is why I spoke of composition:
>
> * annotprocbuild=lombok,mapstruct-processor
> * annotprocrun=openjpa
> * realcompile=annotprocrun,compile
>
> and you pass realcompile as set identifier to compiler plugin, war plugin
> etc for example.
>
> But I'm happy with any solution not making maven with additional concept
> which are not design to scale in time.
>
> So my 2cts are that if you want to try an use case we don't handle you can
> likely try to solve it with type handle, promote it in an extension, see if
> it gets adoption and its pitfalls but in terms of design it is really not
> matching IMHO, it is more a hack in terms of concept.
>
> That said no issue, I will step down from this thread as you request, goal
> was just to try to not push in a way which will likely not solve the
> original issue and was hurting users by some projects having adopted this
> solution (bundle).
>
>
> >
> >
> > Thanks
> > T
> >
> >
> > On Thu, Nov 2, 2023 at 9:51 PM Martin Desruisseaux <
> > martin.desruisse...@geomatys.com> wrote:
> >
> > > Le 2023-11-02 à 20 h 07, Romain Manni-Bucau a écrit :
> > >
> > > > as of today libs can't igno

Re: Maven 5 pom extension for agents

2023-11-03 Thread Romain Manni-Bucau

Le ven. 3 nov. 2023 à 16:17, Tamás Cservenák  a écrit :

> Howdy,
>
> @Romain, it seems it is not only me alone having difficulties to understand
> your responses, that are almost always rejecting the idea.
>
> I asked you to create a counter example (not "recipe" in prose), you did
> not. When I joined this thread, I said clearly "this is hardly gonna happen
> in Maven 3 lifespan" (as Maven3 internals are incapable of this) but you
> bring in your "prose use cases" with Maven 3.x. All this just bloats the
> thread, blurs it, creates noise, and produces the wrong perception in users
> who are skimming this thread, and is maybe even causing people to abstain
> from throwing in new ideas...
>

The detail point you forget is that since this is a partial solution either
nobody cares of it today and it will not be adopted more than today (more
later on that) or it will break in the future - I don't think we will want
to drag this kind of hack for years, most people hope type handler does not
bring logic - so maven 3 or maven 5 will break this. Maven 3 is just
obvious and a case we must manage until maven 4 is out - we didn't decide
yet if it is next year or in 5 years.

>
> So, Romain, I'd kindly ask you to cover your prose with code examples
> instead, provide us actual and concrete use cases in code, stay on topic,
> and please remain open for new ideas (I know or can imagine you may do
> things differently today, but please, then showcase those "better
> solutions" instead, so pointers to code please with explanation why are
> those "better").
>

The thing is that projects also use modules (check out helidon, junit5,
https://github.com/sormuras/testing-in-the-modular-world for trivial
examples).
None had issues with current logic for build but advanced cases need a fine
control, not just the step you want to bring assuming it helps.
See it as it is:

* you don't really care, you want to deliver modules -> we do it, nothing
special
* you want to deliver modules with a fine control of the build "runtime" ->
we are quite randomy there so we need to let the user toggle the exact
command, it is possible but requires a lot of work...likely as much as
defining configurations/types

This is why originally I said this is likely not trying to solve any real
issue which will end up in plugin configuration more than in the core pom.

Also bring back the several 7-10 years old threads which request to make
maven more flexible in its dependency management, we will not solve that.
Javaagent, JPMS are just low hanging fruits but you have the same issues
for frontend builds, webjars, and so on.
I don't see us adding all that in maven core (it is where it must belong in
your proposal to work).

What would be nice and smooth is a hybrid between type and scope - but once
again I strongly think type should stick to "how to read/map an artifact",
one obvious example of that is the method isAddedToClasspath, it just means
you will need to add one method per type you add, does not scale in terms
of design nor enable to write extensions properly.

The rational about the scope need is to add or not the artifact depending
its type - think annotation processors, it wouldnt be shocking to not add
them to the runtime until request.
This is why I spoke of composition:

* annotprocbuild=lombok,mapstruct-processor
* annotprocrun=openjpa
* realcompile=annotprocrun,compile

and you pass realcompile as set identifier to compiler plugin, war plugin
etc for example.

But I'm happy with any solution not making maven with additional concept
which are not design to scale in time.

So my 2cts are that if you want to try an use case we don't handle you can
likely try to solve it with type handle, promote it in an extension, see if
it gets adoption and its pitfalls but in terms of design it is really not
matching IMHO, it is more a hack in terms of concept.

That said no issue, I will step down from this thread as you request, goal
was just to try to not push in a way which will likely not solve the
original issue and was hurting users by some projects having adopted this
solution (bundle).

>
>
> Thanks
> T
>
>
> On Thu, Nov 2, 2023 at 9:51 PM Martin Desruisseaux <
> martin.desruisse...@geomatys.com> wrote:
>
> > Le 2023-11-02 à 20 h 07, Romain Manni-Bucau a écrit :
> >
> > > as of today libs can't ignore classpath cause it stays the majority of
> > > consumers so it is "as if" in this thread IMHO.
> > >
> > Maven can't ignore classpath. But for artifact producers, it is up to
> > them to decide. They may target a niche market. Or the library may be
> > internal to a company. Or it may be a plugin for a JPMS application.
> >
> >
> > > if you take the most common packaging which is the fatjar (agree it is
> > > wrong for JPMS unrelated reason but still) it does not support a
> > > single module.
> > >
> > Indeed, fatjar is problematic for JPMS. But the proposal does not block
> > users from making fatjar anyway if all JPMS modules are
> > classpath-

Re: Maven 5 pom extension for agents

2023-11-03 Thread Tamás Cservenák

Howdy,

@Romain, it seems it is not only me alone having difficulties to understand
your responses, that are almost always rejecting the idea.

I asked you to create a counter example (not "recipe" in prose), you did
not. When I joined this thread, I said clearly "this is hardly gonna happen
in Maven 3 lifespan" (as Maven3 internals are incapable of this) but you
bring in your "prose use cases" with Maven 3.x. All this just bloats the
thread, blurs it, creates noise, and produces the wrong perception in users
who are skimming this thread, and is maybe even causing people to abstain
from throwing in new ideas...

So, Romain, I'd kindly ask you to cover your prose with code examples
instead, provide us actual and concrete use cases in code, stay on topic,
and please remain open for new ideas (I know or can imagine you may do
things differently today, but please, then showcase those "better
solutions" instead, so pointers to code please with explanation why are
those "better").


Thanks
T


On Thu, Nov 2, 2023 at 9:51 PM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:

> Le 2023-11-02 à 20 h 07, Romain Manni-Bucau a écrit :
>
> > as of today libs can't ignore classpath cause it stays the majority of
> > consumers so it is "as if" in this thread IMHO.
> >
> Maven can't ignore classpath. But for artifact producers, it is up to
> them to decide. They may target a niche market. Or the library may be
> internal to a company. Or it may be a plugin for a JPMS application.
>
>
> > if you take the most common packaging which is the fatjar (agree it is
> > wrong for JPMS unrelated reason but still) it does not support a
> > single module.
> >
> Indeed, fatjar is problematic for JPMS. But the proposal does not block
> users from making fatjar anyway if all JPMS modules are
> classpath-compatible with the workarounds that I mentioned in my
> previous email. Only if some JPMS dependencies are not
> classpath-compatible, the user is blocked from making a fatjar. Whether
> the dependency is classpath-compatible or not is up to the library
> producer to decide, it is not our role to force them (see above point).
>
>
> >> Actually I think that keeping JPMS dependencies on the module-path is
> >> what should be done. If a user is nevertheless facing issues, giving
> >> him control is the whole point of the proposal.
> >>
> > Wait, this is what we have today then so we are good.
> >
> No, this is not what we have today. Current Maven behaviour is the
> opposite (put JPMS dependencies on the class-path if the consumer is not
> JPMS) with no way for the users to specify their needs.
>
>
> > But yes, one of both scenario is broken if you test it cause you
> > inherit a context whereas you can be consummed in two contexts so one
> > is always wrong until you redo the work...exactly as today so no gain
> > there.
> >
> I have difficulty to understand. I see no broken scenario if the library
> is designed for running on the module-path, and Maven indeed put the
> dependency on the module-path even for non-JPMS consumers. So what is
> broken exactly? Do the two contexts are "separated JAR files" versus
> "fatjar"? If yes, indeed as said above creating a fatjar may or may not
> work. But should we block JPMS because of fatjar?
>
>
> > Similarly your statement is right, "a dep on the module-path can be a
> > problem" is true as well so my opinion is we should respect the user
> > runtime (if not using jpms then don't set module-path).
>
> We can keep the debate about what should be the default location of a
> dependency for later. The key point is that we need user's control.
> Currently, users have no control.
>
>
> > Agree about having an uniform solution and this is why I mention that
> > using type is just about trying to fit the set notion in the current
> > model but without embracing the design which makes it solving the
> > issue (assinging a set per "path" need).
> >
> Both the Set proposal and the  proposal would work. I have not yet
> seen an argument against the  proposal that I could understand. On
> the other side, I see three arguments in favour of :
>
>   * It does not introduce new elements in the POM model, it only extends
> the use of an existing element.
>   * It does not force users to care about class-path/module-path
> distinction when the default behaviour works for them. By contrast,
> the Set approach forces all users to care about that distinction,
> even when not necessary.
>   * It keeps the "dependency set" concept available for business logic,
> without forcing users to mix their business logic with
> class-path/module-path concerns.
>
> Martin
>
>

Re: Maven 5 pom extension for agents


Le 2023-11-02 à 20 h 07, Romain Manni-Bucau a écrit :

as of today libs can't ignore classpath cause it stays the majority of 
consumers so it is "as if" in this thread IMHO.


Maven can't ignore classpath. But for artifact producers, it is up to 
them to decide. They may target a niche market. Or the library may be 
internal to a company. Or it may be a plugin for a JPMS application.



if you take the most common packaging which is the fatjar (agree it is 
wrong for JPMS unrelated reason but still) it does not support a 
single module.


Indeed, fatjar is problematic for JPMS. But the proposal does not block 
users from making fatjar anyway if all JPMS modules are 
classpath-compatible with the workarounds that I mentioned in my 
previous email. Only if some JPMS dependencies are not 
classpath-compatible, the user is blocked from making a fatjar. Whether 
the dependency is classpath-compatible or not is up to the library 
producer to decide, it is not our role to force them (see above point).



Actually I think that keeping JPMS dependencies on the module-path is 
what should be done. If a user is nevertheless facing issues, giving 
him control is the whole point of the proposal.



Wait, this is what we have today then so we are good.

No, this is not what we have today. Current Maven behaviour is the 
opposite (put JPMS dependencies on the class-path if the consumer is not 
JPMS) with no way for the users to specify their needs.



But yes, one of both scenario is broken if you test it cause you 
inherit a context whereas you can be consummed in two contexts so one 
is always wrong until you redo the work...exactly as today so no gain 
there.


I have difficulty to understand. I see no broken scenario if the library 
is designed for running on the module-path, and Maven indeed put the 
dependency on the module-path even for non-JPMS consumers. So what is 
broken exactly? Do the two contexts are "separated JAR files" versus 
"fatjar"? If yes, indeed as said above creating a fatjar may or may not 
work. But should we block JPMS because of fatjar?



Similarly your statement is right, "a dep on the module-path can be a 
problem" is true as well so my opinion is we should respect the user 
runtime (if not using jpms then don't set module-path).


We can keep the debate about what should be the default location of a 
dependency for later. The key point is that we need user's control. 
Currently, users have no control.



Agree about having an uniform solution and this is why I mention that 
using type is just about trying to fit the set notion in the current 
model but without embracing the design which makes it solving the 
issue (assinging a set per "path" need).


Both the Set proposal and the  proposal would work. I have not yet 
seen an argument against the  proposal that I could understand. On 
the other side, I see three arguments in favour of :


 * It does not introduce new elements in the POM model, it only extends
   the use of an existing element.
 * It does not force users to care about class-path/module-path
   distinction when the default behaviour works for them. By contrast,
   the Set approach forces all users to care about that distinction,
   even when not necessary.
 * It keeps the "dependency set" concept available for business logic,
   without forcing users to mix their business logic with
   class-path/module-path concerns.

Martin

Re: Maven 5 pom extension for agents

Le jeu. 2 nov. 2023 à 19:49, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2023-11-02 à 17 h 35, Romain Manni-Bucau a écrit :
>
> > Now, do the same example but with app in a classpath centric build
> > (spring boot, EE, ...) which consumes lib1 as a classpath jar even if
> > it is a module in its original pom (perfectly valid).
> >
> Consuming lib1 on the classpath is *not* perfectly valid. It depends on
> the library. For being valid, the library must have applied some
> workarounds such as duplicating module-info into META-INF/services. If
> the library hasn't applied those workarounds, consuming the library on
> the classpath will break it.


> The workaround doing duplication in META-INF is not too difficult (but
> not always easy neither). However, some other workarounds are more
> difficult. For example, loading new JAR files at runtime is done in a
> very different way (ClassLoader versus ModuleLayer). A library producer
> may choose to not support execution on the classpath anymore, e.g. in
> order to avoid maintaining two different JAR loading systems. They may
> lost some users, but it is not up to us to decide for them.
>

Agree but as of today libs can't ignore classpath cause it stays the
majority of consumers so it is "as if" in this thread IMHO.


>
> Regarding Spring Boot, the idea that a non-JPMS application must have
> everything on the classpath is a common misconception. A non-JPMS
> application can still have dependencies on the module-path. Some peoples
> seem to be doing exactly that with Spring Boot [1]. I also demonstrated
> that 4 months ago with a Maven and Gradle project [2] for explaining the
> issue with current heuristic rules.
>
> [1]
> https://stackoverflow.com/questions/74214182/how-to-get-spring-boot-project-work-with-jpms
> [2]https://github.com/Geomatys/MavenModulepathBug


Also agree but if you take the most common packaging which is the fatjar
(agree it is wrong for JPMS unrelated reason but still) it does not support
a single module.
Same for war packaging and saw almost nobody using the plain classpath
packaging in real life (which would be the most valid one).

So agree about the language shortcut but here again it is the world we are
in today and probably tomorrow.

Side note: I'm far to speak about what we can do, we can implementing lib
versioning on top of module layers but "nobody" does/uses it seriously
today for ex. So it is really about maven spirit which is about "works for
most" and refining this "most" and AFAIK it is not JPMS.


>
>
>
> > You can make one of both cases working but not both with your
> > proposal. Indeed last one will be broken even if it is the most common
> > one (so we break maven philosophy - and user interaction IMHO).
> >
> I still do not see where is the conflict. Both scenarios should work,
> including the last one even if the dependency is put on the module-path
> of a classpath-centric environment. Actually I think that keeping JPMS
> dependencies on the module-path is what should be done. If a user is
> nevertheless facing issues, giving him control is the whole point of the
> proposal.
>

Wait, this is what we have today then so we are good.
But yes, one of both scenario is broken if you test it cause you inherit a
context whereas you can be consummed in two contexts so one is always wrong
until you redo the work...exactly as today so no gain there.


>
>
> > By design there is no way to make it work smoothly at artifact level.
> >
> Is this statement based on the idea that a classpath-centric application
> would need to move module-path dependencies to the class-path? If yes, I
> tried to explain above that this is a misconception (executable proof of
> concept provided). If no, can you explain where is the problem, keeping
> in mind that a dependency on the module-path is not necessarily a
> problem even for a classpath-centric application?
>

Similarly your statement is right, "a dep on the module-path can be a
problem" is true as well so my opinion is we should respect the user
runtime (if not using jpms then don't set module-path).


>
>
> > Until JPMS reach 40% of projects I guess we should be able to leave
> > with it and it avoids to introduce any new concept or mess up what
> > type is for end users
> >
> This is not a fair criterion if Maven is making JPMS adoption so hard
> (chicken-and-egg problem). Also, this thread initially started as an
> issue about agents. JPMS has been added to this discussion because the
> issue is basically the same: controlling the path. Tamas's proposal is
> trying to address not only JPMS, but also agent, doclet, taglet,
> annotation processor and possibly yet more tools to appear in the
> future, at all once with one uniform mechanism.
>

Maven does not, JPMS setup is documented since java 9 and we got no real
complains AFAIK (agree it comes from time to time but it is quite rare in
practise compared to the user base IMHO).

Agree about having an uniform sol

Re: Maven 5 pom extension for agents

Le 2023-11-02 à 17 h 35, Romain Manni-Bucau a écrit :

Now, do the same example but with app in a classpath centric build
(spring boot, EE, ...) which consumes lib1 as a classpath jar even if
it is a module in its original pom (perfectly valid).

Consuming lib1 on the classpath is *not* perfectly valid. It depends on
the library. For being valid, the library must have applied some
workarounds such as duplicating module-info into META-INF/services. If
the library hasn't applied those workarounds, consuming the library on
the classpath will break it.

The workaround doing duplication in META-INF is not too difficult (but
not always easy neither). However, some other workarounds are more
difficult. For example, loading new JAR files at runtime is done in a
very different way (ClassLoader versus ModuleLayer). A library producer
may choose to not support execution on the classpath anymore, e.g. in
order to avoid maintaining two different JAR loading systems. They may
lost some users, but it is not up to us to decide for them.

Regarding Spring Boot, the idea that a non-JPMS application must have
everything on the classpath is a common misconception. A non-JPMS
application can still have dependencies on the module-path. Some peoples
seem to be doing exactly that with Spring Boot [1]. I also demonstrated
that 4 months ago with a Maven and Gradle project [2] for explaining the
issue with current heuristic rules.

[1]https://stackoverflow.com/questions/74214182/how-to-get-spring-boot-project-work-with-jpms
[2]https://github.com/Geomatys/MavenModulepathBug

You can make one of both cases working but not both with your
proposal. Indeed last one will be broken even if it is the most common
one (so we break maven philosophy - and user interaction IMHO).

I still do not see where is the conflict. Both scenarios should work,
including the last one even if the dependency is put on the module-path
of a classpath-centric environment. Actually I think that keeping JPMS
dependencies on the module-path is what should be done. If a user is
nevertheless facing issues, giving him control is the whole point of the
proposal.

By design there is no way to make it work smoothly at artifact level.

Is this statement based on the idea that a classpath-centric application
would need to move module-path dependencies to the class-path? If yes, I
tried to explain above that this is a misconception (executable proof of
concept provided). If no, can you explain where is the problem, keeping
in mind that a dependency on the module-path is not necessarily a
problem even for a classpath-centric application?

Until JPMS reach 40% of projects I guess we should be able to leave
with it and it avoids to introduce any new concept or mess up what
type is for end users

This is not a fair criterion if Maven is making JPMS adoption so hard
(chicken-and-egg problem). Also, this thread initially started as an
issue about agents. JPMS has been added to this discussion because the
issue is basically the same: controlling the path. Tamas's proposal is
trying to address not only JPMS, but also agent, doclet, taglet,
annotation processor and possibly yet more tools to appear in the
future, at all once with one uniform mechanism.

Martin

Re: Maven 5 pom extension for agents

Le jeu. 2 nov. 2023 à 17:24, Tamás Cservenák  a écrit :

> Romain,
>
> Could you draft an example project that proves or at least showcases your
> points?
> It's probably me, but I don't get your responses :(
>
> WTH is "lifecycle of your project graph"?
>
> But really, could you draft an example project that showcases your points?
>

Just the one I mentionned earlier:

1. create three projects: lib and app
2. write lib as a module reactor (ensure it has some transitive dep, maybe
lib-common with type=module too) and app as maven projects are today (all
is jar) - indeed app consumes lib as a module so it has a module-info which
references lib module-info meta like SPI and packages
3. make lib move to your proposal and moving from 1.0.0 to 1.0.1 (no real
code change), check app has no change in terms of dispatching to module
path/classpath

Now, do the same example but with app in a classpath centric build (spring
boot, EE, ...) which consumes lib1 as a classpath jar even if it is a
module in its original pom (perfectly valid).

You can make one of both cases working but not both with your proposal.
Indeed last one will be broken even if it is the most common one (so we
break maven philosophy - and user interaction IMHO).

By design there is no way to make it work smoothly at artifact level.
We can, indeed, do yet another guess algorithm which would be so clever
than we would start again this thread in a few months but as mentionned we
have all we need to make it work today and setup is not that huge but
requires dependency plugin.
You want all the classpath on module path? dump the classpath with
dependency plugin in a maven property and forward it to module path in the
3-4 plugins, be it.

Until JPMS reach 40% of projects I guess we should be able to leave with it
and it avoids to introduce any new concept or mess up what type is for end
users (even if you are technically 100% right, type stays the extensions
for users and it is easier to make it aligned most of the time for us than
putting unread doc everywhere IMHO).

Hope it helps.

>
> T
>
> On Thu, Nov 2, 2023 at 2:08 PM Romain Manni-Bucau 
> wrote:
>
> > Le jeu. 2 nov. 2023 à 13:59, Tamás Cservenák  a
> > écrit :
> >
> > > Howdy,
> > >
> > > "not upgrading maven" can simply be extrapolated to "not upgrading
> java",
> > > so what are we talking about at all here? Imposing illogical
> requirements
> > > really does not make sense.
> >
> >
> > (today) I'm writing app A, and I'm depending on helidon. I'm using java
> 17
> > and maven 3.9 (last stables when project was setup).
> >
> > Tomorrow helidon switched to type=module cause it fits better their
> build.
> >
> > I'm expecting my app A to still work at helidon new release, just edit
> >  and be itbut boom, it just breaks cause module is
> an
> > unknown type without a handler.
> >
> >
> > > The whole point of mvn4 is to allow progress at
> > > the same time not excluding the mvn3 universe (consumer POM).
> > >
> >
> > Progress on the *build*, not much on consuming side cause it can only
> work
> > for a version then and we are doomed.
> >
> >
> > > "transitivity is broken" again, it ends where you declare it as
> explained
> > > above, so am really unsure where we miss each other.
> > >
> >
> > No no, think lifecycle of your project graph, this becomes insane to do
> > that at that level in real life so really hope we avoid it.
> >
> >
> > >
> > > Could you draft an example project that proves your points?
> > >
> > > Thanks
> > > T
> > >
> > > On Thu, Nov 2, 2023 at 1:52 PM Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > > wrote:
> > >
> > > > Just as a reminder:
> > > >
> > > > * type=module breaks downstream consumers not upgrading maven
> > > > * transitivity is broken since everything ends in modulepath whereas
> in
> > > > most cases you want it in the classpath
> > > >
> > > > So really we should move forward on something else than artifact
> > > definition
> > > > as the sole solution if we want to support jpms as a first citizen
> > (once
> > > > again no issue for me to not do, my current main issue is to
> introduce
> > > > something making builds more complex and not solving end users
> issue).
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le jeu. 2 nov. 2023 à 13:25, Tamás Cservenák  a
> > > > écrit :
> > > >
> > > > > Just to chime in to Martin thoughts:
> > > > >
> > > > > - yes, the default "type" is still "jar" (so if you omit type,
> "jar"
> > is
> > > > > applied as today)
> > > > > - transitivity: yes, as I show above, project-impl [type=module]
> > > depends
> > >

Re: Maven 5 pom extension for agents

Romain,

Could you draft an example project that proves or at least showcases your
points?
It's probably me, but I don't get your responses :(

WTH is "lifecycle of your project graph"?

But really, could you draft an example project that showcases your points?

T

On Thu, Nov 2, 2023 at 2:08 PM Romain Manni-Bucau 
wrote:

> Le jeu. 2 nov. 2023 à 13:59, Tamás Cservenák  a
> écrit :
>
> > Howdy,
> >
> > "not upgrading maven" can simply be extrapolated to "not upgrading java",
> > so what are we talking about at all here? Imposing illogical requirements
> > really does not make sense.
>
>
> (today) I'm writing app A, and I'm depending on helidon. I'm using java 17
> and maven 3.9 (last stables when project was setup).
>
> Tomorrow helidon switched to type=module cause it fits better their build.
>
> I'm expecting my app A to still work at helidon new release, just edit
>  and be itbut boom, it just breaks cause module is an
> unknown type without a handler.
>
>
> > The whole point of mvn4 is to allow progress at
> > the same time not excluding the mvn3 universe (consumer POM).
> >
>
> Progress on the *build*, not much on consuming side cause it can only work
> for a version then and we are doomed.
>
>
> > "transitivity is broken" again, it ends where you declare it as explained
> > above, so am really unsure where we miss each other.
> >
>
> No no, think lifecycle of your project graph, this becomes insane to do
> that at that level in real life so really hope we avoid it.
>
>
> >
> > Could you draft an example project that proves your points?
> >
> > Thanks
> > T
> >
> > On Thu, Nov 2, 2023 at 1:52 PM Romain Manni-Bucau  >
> > wrote:
> >
> > > Just as a reminder:
> > >
> > > * type=module breaks downstream consumers not upgrading maven
> > > * transitivity is broken since everything ends in modulepath whereas in
> > > most cases you want it in the classpath
> > >
> > > So really we should move forward on something else than artifact
> > definition
> > > as the sole solution if we want to support jpms as a first citizen
> (once
> > > again no issue for me to not do, my current main issue is to introduce
> > > something making builds more complex and not solving end users issue).
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le jeu. 2 nov. 2023 à 13:25, Tamás Cservenák  a
> > > écrit :
> > >
> > > > Just to chime in to Martin thoughts:
> > > >
> > > > - yes, the default "type" is still "jar" (so if you omit type, "jar"
> is
> > > > applied as today)
> > > > - transitivity: yes, as I show above, project-impl [type=module]
> > depends
> > > on
> > > > project-api [type=module] so the whole tree lands on "modulepath".
> > > > - override: exactly as Martin says, if you want to override and have
> > > > project-api on classpath, just override it
> > > > - I wanted to expand the "status" plugin to show more info, but hit
> > some
> > > > issues with mvn4 API current state, so I am looking into that
> first...
> > > >
> > > > On Thu, Nov 2, 2023 at 1:20 PM Martin Desruisseaux <
> > > > martin.desruisse...@geomatys.com> wrote:
> > > >
> > > > > Le 2023-11-02 à 12 h 53, Romain Manni-Bucau a écrit :
> > > > >
> > > > > > You would also note that using "type" *forces* users to care
> about
> > > > > > this separation too in an unexpected way.
> > > > > >
> > > > > Type is an optional element. The use of module is a
> > > > > workaround for the heuristic rules sometime doing the wrong choice.
> > But
> > > > >  could continue to be optional if users have control over
> those
> > > > > rules (that would be a separated thread), with  used only
> when
> > > > > fine-grained control is desired.
> > > > >
> > > > >
> > > > > > I import helidon (which is fully jpms friendly) so I get
> > > > > > helidon-server on the module-path but helidon-common on the
> > > classpath?
> > > > > > (indeed keep in mind if you fix this you will get the opposite
> case
> > > > > > blowing up).
> > > > > >
> > > > > Whether to put helidon-common on module-path would be determined by
> > the
> > > > >  declaration in the helidon.pom file. That file already
> > > > > needs to be read anyway for finding the helidon-common transitive
> > > > > dependency. Users can override if desired by adding their own
> > > > >  declaration in their project, in the same way as we
> can
> > > > > override dependency versions today.
> > > > >
> > > > >
> > > > > > Also keep in mind the pom modification is *not* an option as
> > > commented
> > > > > > and would mean the consumer depends on the consumed artifact
> which,
> > > we
> > > > > > saw it, is not the case at all with java modules
>

Re: Maven 5 pom extension for agents

Le jeu. 2 nov. 2023 à 13:59, Tamás Cservenák  a écrit :

> Howdy,
>
> "not upgrading maven" can simply be extrapolated to "not upgrading java",
> so what are we talking about at all here? Imposing illogical requirements
> really does not make sense.


(today) I'm writing app A, and I'm depending on helidon. I'm using java 17
and maven 3.9 (last stables when project was setup).

Tomorrow helidon switched to type=module cause it fits better their build.

I'm expecting my app A to still work at helidon new release, just edit
 and be itbut boom, it just breaks cause module is an
unknown type without a handler.


> The whole point of mvn4 is to allow progress at
> the same time not excluding the mvn3 universe (consumer POM).
>

Progress on the *build*, not much on consuming side cause it can only work
for a version then and we are doomed.


> "transitivity is broken" again, it ends where you declare it as explained
> above, so am really unsure where we miss each other.
>

No no, think lifecycle of your project graph, this becomes insane to do
that at that level in real life so really hope we avoid it.


>
> Could you draft an example project that proves your points?
>
> Thanks
> T
>
> On Thu, Nov 2, 2023 at 1:52 PM Romain Manni-Bucau 
> wrote:
>
> > Just as a reminder:
> >
> > * type=module breaks downstream consumers not upgrading maven
> > * transitivity is broken since everything ends in modulepath whereas in
> > most cases you want it in the classpath
> >
> > So really we should move forward on something else than artifact
> definition
> > as the sole solution if we want to support jpms as a first citizen (once
> > again no issue for me to not do, my current main issue is to introduce
> > something making builds more complex and not solving end users issue).
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le jeu. 2 nov. 2023 à 13:25, Tamás Cservenák  a
> > écrit :
> >
> > > Just to chime in to Martin thoughts:
> > >
> > > - yes, the default "type" is still "jar" (so if you omit type, "jar" is
> > > applied as today)
> > > - transitivity: yes, as I show above, project-impl [type=module]
> depends
> > on
> > > project-api [type=module] so the whole tree lands on "modulepath".
> > > - override: exactly as Martin says, if you want to override and have
> > > project-api on classpath, just override it
> > > - I wanted to expand the "status" plugin to show more info, but hit
> some
> > > issues with mvn4 API current state, so I am looking into that first...
> > >
> > > On Thu, Nov 2, 2023 at 1:20 PM Martin Desruisseaux <
> > > martin.desruisse...@geomatys.com> wrote:
> > >
> > > > Le 2023-11-02 à 12 h 53, Romain Manni-Bucau a écrit :
> > > >
> > > > > You would also note that using "type" *forces* users to care about
> > > > > this separation too in an unexpected way.
> > > > >
> > > > Type is an optional element. The use of module is a
> > > > workaround for the heuristic rules sometime doing the wrong choice.
> But
> > > >  could continue to be optional if users have control over those
> > > > rules (that would be a separated thread), with  used only when
> > > > fine-grained control is desired.
> > > >
> > > >
> > > > > I import helidon (which is fully jpms friendly) so I get
> > > > > helidon-server on the module-path but helidon-common on the
> > classpath?
> > > > > (indeed keep in mind if you fix this you will get the opposite case
> > > > > blowing up).
> > > > >
> > > > Whether to put helidon-common on module-path would be determined by
> the
> > > >  declaration in the helidon.pom file. That file already
> > > > needs to be read anyway for finding the helidon-common transitive
> > > > dependency. Users can override if desired by adding their own
> > > >  declaration in their project, in the same way as we can
> > > > override dependency versions today.
> > > >
> > > >
> > > > > Also keep in mind the pom modification is *not* an option as
> > commented
> > > > > and would mean the consumer depends on the consumed artifact which,
> > we
> > > > > saw it, is not the case at all with java modules
> > > > >
> > > > I do not understand this part. Consumer already depends on consumed
> > > > artifact, since it determines transitive dependencies. The use of
> JPMS
> > > > changes nothing here.
> > > >
> > > >
> > > > > 90% will want modules on classpath
> > > > >
> > > > I think it is more "90% does not care as long as it works". If a
> > library
> > > > has been designed in such a way that it needs to be on the module
> path
> > > > for working properly, I think that most users would be happy to let
> > > > Maven do the right thing according the metadata found in POM f

Re: Maven 5 pom extension for agents

Howdy,

"not upgrading maven" can simply be extrapolated to "not upgrading java",
so what are we talking about at all here? Imposing illogical requirements
really does not make sense. The whole point of mvn4 is to allow progress at
the same time not excluding the mvn3 universe (consumer POM).
"transitivity is broken" again, it ends where you declare it as explained
above, so am really unsure where we miss each other.

Could you draft an example project that proves your points?

Thanks
T

On Thu, Nov 2, 2023 at 1:52 PM Romain Manni-Bucau 
wrote:

> Just as a reminder:
>
> * type=module breaks downstream consumers not upgrading maven
> * transitivity is broken since everything ends in modulepath whereas in
> most cases you want it in the classpath
>
> So really we should move forward on something else than artifact definition
> as the sole solution if we want to support jpms as a first citizen (once
> again no issue for me to not do, my current main issue is to introduce
> something making builds more complex and not solving end users issue).
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le jeu. 2 nov. 2023 à 13:25, Tamás Cservenák  a
> écrit :
>
> > Just to chime in to Martin thoughts:
> >
> > - yes, the default "type" is still "jar" (so if you omit type, "jar" is
> > applied as today)
> > - transitivity: yes, as I show above, project-impl [type=module] depends
> on
> > project-api [type=module] so the whole tree lands on "modulepath".
> > - override: exactly as Martin says, if you want to override and have
> > project-api on classpath, just override it
> > - I wanted to expand the "status" plugin to show more info, but hit some
> > issues with mvn4 API current state, so I am looking into that first...
> >
> > On Thu, Nov 2, 2023 at 1:20 PM Martin Desruisseaux <
> > martin.desruisse...@geomatys.com> wrote:
> >
> > > Le 2023-11-02 à 12 h 53, Romain Manni-Bucau a écrit :
> > >
> > > > You would also note that using "type" *forces* users to care about
> > > > this separation too in an unexpected way.
> > > >
> > > Type is an optional element. The use of module is a
> > > workaround for the heuristic rules sometime doing the wrong choice. But
> > >  could continue to be optional if users have control over those
> > > rules (that would be a separated thread), with  used only when
> > > fine-grained control is desired.
> > >
> > >
> > > > I import helidon (which is fully jpms friendly) so I get
> > > > helidon-server on the module-path but helidon-common on the
> classpath?
> > > > (indeed keep in mind if you fix this you will get the opposite case
> > > > blowing up).
> > > >
> > > Whether to put helidon-common on module-path would be determined by the
> > >  declaration in the helidon.pom file. That file already
> > > needs to be read anyway for finding the helidon-common transitive
> > > dependency. Users can override if desired by adding their own
> > >  declaration in their project, in the same way as we can
> > > override dependency versions today.
> > >
> > >
> > > > Also keep in mind the pom modification is *not* an option as
> commented
> > > > and would mean the consumer depends on the consumed artifact which,
> we
> > > > saw it, is not the case at all with java modules
> > > >
> > > I do not understand this part. Consumer already depends on consumed
> > > artifact, since it determines transitive dependencies. The use of JPMS
> > > changes nothing here.
> > >
> > >
> > > > 90% will want modules on classpath
> > > >
> > > I think it is more "90% does not care as long as it works". If a
> library
> > > has been designed in such a way that it needs to be on the module path
> > > for working properly, I think that most users would be happy to let
> > > Maven do the right thing according the metadata found in POM files, and
> > > be explicit with  only if they need to.
> > >
> > >
> > > > So at the end we are exactly in the current (doing no change at all)
> > > > situation where you need to tune all your stack to be stable,
> reliable
> > > > and properly handled.
> > > >
> > > No, the current situation is that we cannot tune the classpath and
> > > module-path. There is no way I could see to override the decision taken
> > > by the current heuristic rules.
> > >
> > >  Martin
> > >
> > >
> >
>

Re: Maven 5 pom extension for agents

Just as a reminder:

* type=module breaks downstream consumers not upgrading maven
* transitivity is broken since everything ends in modulepath whereas in
most cases you want it in the classpath

So really we should move forward on something else than artifact definition
as the sole solution if we want to support jpms as a first citizen (once
again no issue for me to not do, my current main issue is to introduce
something making builds more complex and not solving end users issue).

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 2 nov. 2023 à 13:25, Tamás Cservenák  a écrit :

> Just to chime in to Martin thoughts:
>
> - yes, the default "type" is still "jar" (so if you omit type, "jar" is
> applied as today)
> - transitivity: yes, as I show above, project-impl [type=module] depends on
> project-api [type=module] so the whole tree lands on "modulepath".
> - override: exactly as Martin says, if you want to override and have
> project-api on classpath, just override it
> - I wanted to expand the "status" plugin to show more info, but hit some
> issues with mvn4 API current state, so I am looking into that first...
>
> On Thu, Nov 2, 2023 at 1:20 PM Martin Desruisseaux <
> martin.desruisse...@geomatys.com> wrote:
>
> > Le 2023-11-02 à 12 h 53, Romain Manni-Bucau a écrit :
> >
> > > You would also note that using "type" *forces* users to care about
> > > this separation too in an unexpected way.
> > >
> > Type is an optional element. The use of module is a
> > workaround for the heuristic rules sometime doing the wrong choice. But
> >  could continue to be optional if users have control over those
> > rules (that would be a separated thread), with  used only when
> > fine-grained control is desired.
> >
> >
> > > I import helidon (which is fully jpms friendly) so I get
> > > helidon-server on the module-path but helidon-common on the classpath?
> > > (indeed keep in mind if you fix this you will get the opposite case
> > > blowing up).
> > >
> > Whether to put helidon-common on module-path would be determined by the
> >  declaration in the helidon.pom file. That file already
> > needs to be read anyway for finding the helidon-common transitive
> > dependency. Users can override if desired by adding their own
> >  declaration in their project, in the same way as we can
> > override dependency versions today.
> >
> >
> > > Also keep in mind the pom modification is *not* an option as commented
> > > and would mean the consumer depends on the consumed artifact which, we
> > > saw it, is not the case at all with java modules
> > >
> > I do not understand this part. Consumer already depends on consumed
> > artifact, since it determines transitive dependencies. The use of JPMS
> > changes nothing here.
> >
> >
> > > 90% will want modules on classpath
> > >
> > I think it is more "90% does not care as long as it works". If a library
> > has been designed in such a way that it needs to be on the module path
> > for working properly, I think that most users would be happy to let
> > Maven do the right thing according the metadata found in POM files, and
> > be explicit with  only if they need to.
> >
> >
> > > So at the end we are exactly in the current (doing no change at all)
> > > situation where you need to tune all your stack to be stable, reliable
> > > and properly handled.
> > >
> > No, the current situation is that we cannot tune the classpath and
> > module-path. There is no way I could see to override the decision taken
> > by the current heuristic rules.
> >
> >  Martin
> >
> >
>

Re: Maven 5 pom extension for agents

Just to chime in to Martin thoughts:

- yes, the default "type" is still "jar" (so if you omit type, "jar" is
applied as today)
- transitivity: yes, as I show above, project-impl [type=module] depends on
project-api [type=module] so the whole tree lands on "modulepath".
- override: exactly as Martin says, if you want to override and have
project-api on classpath, just override it
- I wanted to expand the "status" plugin to show more info, but hit some
issues with mvn4 API current state, so I am looking into that first...

On Thu, Nov 2, 2023 at 1:20 PM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:

> Le 2023-11-02 à 12 h 53, Romain Manni-Bucau a écrit :
>
> > You would also note that using "type" *forces* users to care about
> > this separation too in an unexpected way.
> >
> Type is an optional element. The use of module is a
> workaround for the heuristic rules sometime doing the wrong choice. But
>  could continue to be optional if users have control over those
> rules (that would be a separated thread), with  used only when
> fine-grained control is desired.
>
>
> > I import helidon (which is fully jpms friendly) so I get
> > helidon-server on the module-path but helidon-common on the classpath?
> > (indeed keep in mind if you fix this you will get the opposite case
> > blowing up).
> >
> Whether to put helidon-common on module-path would be determined by the
>  declaration in the helidon.pom file. That file already
> needs to be read anyway for finding the helidon-common transitive
> dependency. Users can override if desired by adding their own
>  declaration in their project, in the same way as we can
> override dependency versions today.
>
>
> > Also keep in mind the pom modification is *not* an option as commented
> > and would mean the consumer depends on the consumed artifact which, we
> > saw it, is not the case at all with java modules
> >
> I do not understand this part. Consumer already depends on consumed
> artifact, since it determines transitive dependencies. The use of JPMS
> changes nothing here.
>
>
> > 90% will want modules on classpath
> >
> I think it is more "90% does not care as long as it works". If a library
> has been designed in such a way that it needs to be on the module path
> for working properly, I think that most users would be happy to let
> Maven do the right thing according the metadata found in POM files, and
> be explicit with  only if they need to.
>
>
> > So at the end we are exactly in the current (doing no change at all)
> > situation where you need to tune all your stack to be stable, reliable
> > and properly handled.
> >
> No, the current situation is that we cannot tune the classpath and
> module-path. There is no way I could see to override the decision taken
> by the current heuristic rules.
>
>  Martin
>
>

Re: Maven 5 pom extension for agents


Le 2023-11-02 à 12 h 53, Romain Manni-Bucau a écrit :

You would also note that using "type" *forces* users to care about 
this separation too in an unexpected way.


Type is an optional element. The use of module is a 
workaround for the heuristic rules sometime doing the wrong choice. But 
 could continue to be optional if users have control over those 
rules (that would be a separated thread), with  used only when 
fine-grained control is desired.



I import helidon (which is fully jpms friendly) so I get 
helidon-server on the module-path but helidon-common on the classpath? 
(indeed keep in mind if you fix this you will get the opposite case 
blowing up).


Whether to put helidon-common on module-path would be determined by the 
 declaration in the helidon.pom file. That file already 
needs to be read anyway for finding the helidon-common transitive 
dependency. Users can override if desired by adding their own 
 declaration in their project, in the same way as we can 
override dependency versions today.



Also keep in mind the pom modification is *not* an option as commented 
and would mean the consumer depends on the consumed artifact which, we 
saw it, is not the case at all with java modules


I do not understand this part. Consumer already depends on consumed 
artifact, since it determines transitive dependencies. The use of JPMS 
changes nothing here.




90% will want modules on classpath

I think it is more "90% does not care as long as it works". If a library 
has been designed in such a way that it needs to be on the module path 
for working properly, I think that most users would be happy to let 
Maven do the right thing according the metadata found in POM files, and 
be explicit with  only if they need to.



So at the end we are exactly in the current (doing no change at all) 
situation where you need to tune all your stack to be stable, reliable 
and properly handled.


No, the current situation is that we cannot tune the classpath and 
module-path. There is no way I could see to override the decision taken 
by the current heuristic rules.


    Martin

Re: Maven 5 pom extension for agents

Le jeu. 2 nov. 2023 à 12:37, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2023-11-02 à 11 h 21, Romain Manni-Bucau a écrit :
>
> > you are right they are orthogonal in terms of design but as soon as
> > you get the set notion you don't need the others and I prefer to not
> > multiply the way to do which is always confusing.
> >
> It is not necessarily a multiplication of ways of doing. Many users
> would not need Set at all. For advanced users who need Set, if we
> discourage the use of Set as a way to separate class-path from
> module-path, it would make easier to use Set for other purposes. For
> example, if a user needs different dependency sets for different
> profiles, he can focus only on his core business (the profiles). If Set
> was used for separating class-path from module-path, the user would need
> to care about both his core business and this separation in same time,
> probably using Set composition, leading to more complex and difficult to
> maintain graph of sets.
>

Not really, set still have defaults but enable a smooth customization
whereas the artifact usage does require something else anyway.
My fear is that not starting by using sets you will keep working around all
issues and make user life as hard as today.


>
> Furthermore, the set proposal does not work for the case where the
> class-path versus module-path choice could be made automatically, not
> based on the existing heuristic rules but instead based on user's choice
> of a default policy (what to do when a dependency has no 
> element). It could also be explicit instruction from the dependency
> producer (e.g. via  element). The class-path / module-path
> dispatching would become a detail that most users can ignore, but with
> the possibility to control it when needed. The Set proposal is
> incompatible with this convenience. It *forces* users to care about
> class-path / module-path separation, even when we could free users from
> this concern.
>

As mentionned, it just works as smooth as type usage due to the set
convention we'll get.
You would also note that using "type" *forces* users to care about this
separation too in an unexpected way.


>
> Keeping Set and JPMS as orthogonal issues would both keep automation
> possible (with rules under user's control), and make easier to use Set
> for core business logic by reducing the complexity of Set graphs.
>

I don't grok this one, set has no more complexity than having dependencies
and most builds require this customization (it is worse using jpms from my
experience, the "smooth" builds are only PoC or demos).


>
>
> > Since the dependency option does not work generally speaking, I'm
> > clearly on the other side
> >
> I still do not understand what is the issue with dependency. Transitive
> dependencies would be managed in the same way as today. It may require a
> modification of the POM model for additional metadata, but this is
> indeed what we are proposing. Even the need for POM modification is
> unsure if the existing  element is used.
>

Same way as today: I import helidon (which is fully jpms friendly) so I get
helidon-server on the module-path but helidon-common on the classpath?
(indeed keep in mind if you fix this you will get the opposite case blowing
up).
Also keep in mind the pom modification is *not* an option as commented and
would mean the consumer depends on the consumed artifact which, we saw it,
is not the case at all with java modules (90% will want modules on
classpath but the source build would use type=module).
So at the end we are exactly in the current (doing no change at all)
situation where you need to tune all your stack to be stable, reliable and
properly handled.


>
>
> > *if we think JPMS needs any more advanced support than today* which is
> > still something I'm not sure.
> >
> The current support is a blocker for non-simple projects. Not improving
> that support would be equivalent to deciding for users, at their place,
> that they do not need JPMS.
>

Yes and no but ultimately it is by JPMS design IMHO, not due to the build
tool so I still think maven can say we don't do anything more than helping
to link gav to physical location more closely.


>
>  Martin
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven 5 pom extension for agents


Le 2023-11-02 à 11 h 21, Romain Manni-Bucau a écrit :

you are right they are orthogonal in terms of design but as soon as 
you get the set notion you don't need the others and I prefer to not 
multiply the way to do which is always confusing.


It is not necessarily a multiplication of ways of doing. Many users 
would not need Set at all. For advanced users who need Set, if we 
discourage the use of Set as a way to separate class-path from 
module-path, it would make easier to use Set for other purposes. For 
example, if a user needs different dependency sets for different 
profiles, he can focus only on his core business (the profiles). If Set 
was used for separating class-path from module-path, the user would need 
to care about both his core business and this separation in same time, 
probably using Set composition, leading to more complex and difficult to 
maintain graph of sets.


Furthermore, the set proposal does not work for the case where the 
class-path versus module-path choice could be made automatically, not 
based on the existing heuristic rules but instead based on user's choice 
of a default policy (what to do when a dependency has no  
element). It could also be explicit instruction from the dependency 
producer (e.g. via  element). The class-path / module-path 
dispatching would become a detail that most users can ignore, but with 
the possibility to control it when needed. The Set proposal is 
incompatible with this convenience. It *forces* users to care about 
class-path / module-path separation, even when we could free users from 
this concern.


Keeping Set and JPMS as orthogonal issues would both keep automation 
possible (with rules under user's control), and make easier to use Set 
for core business logic by reducing the complexity of Set graphs.



Since the dependency option does not work generally speaking, I'm 
clearly on the other side


I still do not understand what is the issue with dependency. Transitive 
dependencies would be managed in the same way as today. It may require a 
modification of the POM model for additional metadata, but this is 
indeed what we are proposing. Even the need for POM modification is 
unsure if the existing  element is used.



*if we think JPMS needs any more advanced support than today* which is 
still something I'm not sure.


The current support is a blocker for non-simple projects. Not improving 
that support would be equivalent to deciding for users, at their place, 
that they do not need JPMS.


    Martin



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 5 pom extension for agents

@Tamas: when you import a type=module dependency, how do I get its module
transitive deps or how do I not get it when it is imported as a jar?
type=module => transitive modules=module so means you assume the original
pom is deployed on central (this is really an assumption even with maven
where it is not always right) and if type=jar transitive module become jar?
Isn't it a mess which partially work only as explained before?
I clearly prefer the explicit option we already have today or we would get
with composed sets rather than new "guess" rules we already failed to
implement.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 2 nov. 2023 à 11:21, Tamás Cservenák  a écrit :

> Howdy,
>
> Unsure about your remark "you are still not solving the transitivity":
>
> As consume-module in Maven debug outputs this (but, debug shows only scope
> not type, as before whole universe was "jar"):
>
> [DEBUG] org.cstamas.maven.jpms.modular:consume-module:jar:1.0.0-SNAPSHOT
> [DEBUG]info.picocli:picocli:jar:4.7.5:compile
> [DEBUG]info.picocli:picocli-codegen:jar:4.7.5:compile
> [DEBUG]
>  org.cstamas.maven.jpms.modular:project-impl:jar:1.0.0-SNAPSHOT:compile
> [DEBUG]
> org.cstamas.maven.jpms.modular:project-api:jar:1.0.0-SNAPSHOT:compile
> [DEBUG]org.junit.jupiter:junit-jupiter-api:jar:5.10.0:test
> [DEBUG]   org.opentest4j:opentest4j:jar:1.3.0:test
> [DEBUG]   org.junit.platform:junit-platform-commons:jar:1.10.0:test
> (version managed from 1.10.0)
> [DEBUG]   org.apiguardian:apiguardian-api:jar:1.1.2:test
>
> And yes, project-impl and project-api ARE "module"s
>
> On Thu, Nov 2, 2023 at 8:25 AM Romain Manni-Bucau 
> wrote:
>
> > Hi Tamas,
> >
> > You table shows exactly my point: you need to be able to compose
> > dependencies sets  (potentially named from user space)  and you can *not*
> > define types - or any similar solution - and let plugins get their config
> > from there.
> >
> > If you don't you are not better than today and assume that in a maven
> > module you always use a jar at the same location.
> >
> > A trivial example is that if you build a jar with javadoc and a generator
> > tool. The generator tool (which forks) which bounds on generate-resources
> > likely wants lib L as a module because it has a SPI in module-info and
> not
> > META-INF (thanks java) but the war needs to take into account the
> > type=module (because it must ignore modules by design since it only
> handles
> > classpath as of today) but if you do you broke your build exactly as
> today
> > with the guess logic.
> >
> > Your proposal is similar to what was done for OSGi bundles but had
> several
> > side effects I prefer we don't enter in and ultimately if you want to go
> > that path it can belong to a github extension easily.
> >
> > Last and likely very important: you are still not solving the
> transitivity
> > so we are back to the original point, either you code without any
> > dependency in your reactor or you are still at the first mail of that
> > thread.
> >
> > I'm not sure why you absolutely want to solve it at type level but it
> > really can't by design due to the transitivity and control we must give
> per
> > plugin not artiact IMHO.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le jeu. 2 nov. 2023 à 00:32, Tamás Cservenák  a
> > écrit :
> >
> > > consumer POM _especially_ remains outside of project limits (again, is
> > > "just outside of" but not "inside" of a reactor), so unsure what should
> > > that solve...
> > >
> > > the "fat" thing gives you exactly this ability, so unsure what the
> > problem
> > > here is?
> > >
> > > T
> > >
> > > On Tue, Oct 31, 2023 at 8:05 AM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Le mar. 31 oct. 2023 à 00:22, Tamás Cservenák 
> a
> > > > écrit :
> > > >
> > > > > Oh, and just as "dependency reduced pom", the flatten does not work
> > > > within
> > > > > the reactor _either_.
> > > > >
> > > >
> > > > This part should be solved with consumer pom but within the reactor
> you
> > > > should get the same behavior in terms of dep with flattening
> anything.
> > > > Stays the multiartifacts issue where we still have a single pom but
> > that
> > > > is  a maven module design issue.
> > > >
> > > > But yes, relocation and uber jar have the issue they are not well
> > > resolved
> > > > today and this

Re: Maven 5 pom extension for agents

@Martin: you are right they are orthogonal in terms of design but as soon
as you get the set notion you don't need the others and I prefer to not
multiply the way to do which is always confusing. Since the dependency
option does not work generally speaking, I'm clearly on the other side *if
we think JPMS needs any more advanced support than today* which is still
something I'm not sure.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 2 nov. 2023 à 11:04, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2023-11-02 à 10 h 49, Romain Manni-Bucau a écrit :
>
> > this assumes all plugins + runtimes will use the exact same option
> > whereas this is generally not true so must be configured per mojo when
> > forking and in jvm.config when not forking so I don't see any work
> > done at dependency/artifact level working on jvm ecosystem.
> >
> It can be combined with your Set proposal. I'm starting to see the Set
> more like an orthogonal aspect rather than a competing proposal. The
> proposed module and  elements would apply to
> the default Set. For the common case where the same options are applied
> to all plugins, that would be sufficient. If different options need to
> be applied to some plugins, then Set could be defined with different
>  and  values.
>
>  Martin
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven 5 pom extension for agents

Howdy,

Unsure about your remark "you are still not solving the transitivity":

As consume-module in Maven debug outputs this (but, debug shows only scope
not type, as before whole universe was "jar"):

[DEBUG] org.cstamas.maven.jpms.modular:consume-module:jar:1.0.0-SNAPSHOT
[DEBUG]info.picocli:picocli:jar:4.7.5:compile
[DEBUG]info.picocli:picocli-codegen:jar:4.7.5:compile
[DEBUG]
 org.cstamas.maven.jpms.modular:project-impl:jar:1.0.0-SNAPSHOT:compile
[DEBUG]
org.cstamas.maven.jpms.modular:project-api:jar:1.0.0-SNAPSHOT:compile
[DEBUG]org.junit.jupiter:junit-jupiter-api:jar:5.10.0:test
[DEBUG]   org.opentest4j:opentest4j:jar:1.3.0:test
[DEBUG]   org.junit.platform:junit-platform-commons:jar:1.10.0:test
(version managed from 1.10.0)
[DEBUG]   org.apiguardian:apiguardian-api:jar:1.1.2:test

And yes, project-impl and project-api ARE "module"s

On Thu, Nov 2, 2023 at 8:25 AM Romain Manni-Bucau 
wrote:

> Hi Tamas,
>
> You table shows exactly my point: you need to be able to compose
> dependencies sets  (potentially named from user space)  and you can *not*
> define types - or any similar solution - and let plugins get their config
> from there.
>
> If you don't you are not better than today and assume that in a maven
> module you always use a jar at the same location.
>
> A trivial example is that if you build a jar with javadoc and a generator
> tool. The generator tool (which forks) which bounds on generate-resources
> likely wants lib L as a module because it has a SPI in module-info and not
> META-INF (thanks java) but the war needs to take into account the
> type=module (because it must ignore modules by design since it only handles
> classpath as of today) but if you do you broke your build exactly as today
> with the guess logic.
>
> Your proposal is similar to what was done for OSGi bundles but had several
> side effects I prefer we don't enter in and ultimately if you want to go
> that path it can belong to a github extension easily.
>
> Last and likely very important: you are still not solving the transitivity
> so we are back to the original point, either you code without any
> dependency in your reactor or you are still at the first mail of that
> thread.
>
> I'm not sure why you absolutely want to solve it at type level but it
> really can't by design due to the transitivity and control we must give per
> plugin not artiact IMHO.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le jeu. 2 nov. 2023 à 00:32, Tamás Cservenák  a
> écrit :
>
> > consumer POM _especially_ remains outside of project limits (again, is
> > "just outside of" but not "inside" of a reactor), so unsure what should
> > that solve...
> >
> > the "fat" thing gives you exactly this ability, so unsure what the
> problem
> > here is?
> >
> > T
> >
> > On Tue, Oct 31, 2023 at 8:05 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Le mar. 31 oct. 2023 à 00:22, Tamás Cservenák  a
> > > écrit :
> > >
> > > > Oh, and just as "dependency reduced pom", the flatten does not work
> > > within
> > > > the reactor _either_.
> > > >
> > >
> > > This part should be solved with consumer pom but within the reactor you
> > > should get the same behavior in terms of dep with flattening anything.
> > > Stays the multiartifacts issue where we still have a single pom but
> that
> > > is  a maven module design issue.
> > >
> > > But yes, relocation and uber jar have the issue they are not well
> > resolved
> > > today and this is a reactor thing since a single artifact thing, agree.
> > >
> > >
> > >
> > > > In fact, the existence of a flatten plugin per se is an IMHO sign
> that
> > > > "something is wrong" here.
> > > >
> > >
> > >
> > > We solved the pipeline for it so guess we passed it.
> > > Flatten is more about cutting transitive visitor which is insanely slow
> > > with resolver today.
> > >
> > >
> > > > Thanks
> > > > T
> > > >
> > > > On Tue, Oct 31, 2023 at 12:08 AM Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Hmm, new types are not a real option for that, it is fully the
> > > lifecycle
> > > > > (plugin chain thesz days since lifecycles are never rich enough and
> > it
> > > > > depends too much on projects.
> > > > >
> > > > > Your fatjar example is not a type but the flatten plugin presence
> and
> > > it
> > > > is
> > > > > really not a type cause it implies a specific pom resolution which
> is
> > > out
> > > > > of the artifact (type) handling scope.
> > > > > IMHO we must not break that rule and not abuse of the resolver, it
> is
> > > > > already overcomplex for its roleand once again does not help
> with
> > > > jpms
> > > > >

Re: Maven 5 pom extension for agents


Le 2023-11-02 à 10 h 49, Romain Manni-Bucau a écrit :

this assumes all plugins + runtimes will use the exact same option 
whereas this is generally not true so must be configured per mojo when 
forking and in jvm.config when not forking so I don't see any work 
done at dependency/artifact level working on jvm ecosystem.


It can be combined with your Set proposal. I'm starting to see the Set 
more like an orthogonal aspect rather than a competing proposal. The 
proposed module and  elements would apply to 
the default Set. For the common case where the same options are applied 
to all plugins, that would be sufficient. If different options need to 
be applied to some plugins, then Set could be defined with different 
 and  values.


    Martin




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 5 pom extension for agents

Hi Martin,

this assumes all plugins + runtimes will use the exact same option whereas
this is generally not true so must be configured per mojo when forking and
in jvm.config when not forking so I don't see any work done at
dependency/artifact level working on jvm ecosystem.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 2 nov. 2023 à 10:47, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2023-10-29 à 21 h 36, Romain Manni-Bucau a écrit :
>
> > Was referencing the options using module names, if you drop the dep or
> > reference a package not supported by the module we should be able to
> fail.
> >
> I do not want to distract this thread from the core issue (control on
> class-path versus module-path), but I believe that above concern can be
> avoided. Lets take --add-exports as an example. The syntax of the option
> passed to javac is:
>
> --add-exports source/package=target
>
> Where /source/ and /target/ are module names. For example if a project
> is a module named "my.project" and that module is using the "org.junit"
> module as a dependency, we may want to add the following option:
>
> --add-exports my.project/my.internal.package=org.junit
>
> It is possible to design the Maven POM in such a way that those modules
> are inferred from the context. The POM could look like this (simplified):
>
> my-project
> 
>
> 
>
>  junit
>  
>  test
>  
>
>  my.internal.package
>  
>
>  
>
> 
>
> Above would mean: if the JUnit dependency is added on the module-path
> (which happens only during tests), then automatically generate
> --add-exports options with:
>
>   * The enclosing project ("my.project") as the source module.
>   * The enclosing dependency ("org.junit") as the target module.
>   * The specified  elements as the packages to exports.
>
> A similar approach can be applied to other options. That way, module
> names do not appear anywhere and the inconsistency risk does not exist.
> This proposal does not cover all cases, but would provide a safe and
> easy way for probably the majority of cases. If a user needs to specify
> different modules than the ones inferred from the context (s)he can
> still add the --add-exports option manually on the command-line.
>
>  Martin
>
>

Re: Maven 5 pom extension for agents


Le 2023-10-29 à 21 h 36, Romain Manni-Bucau a écrit :

Was referencing the options using module names, if you drop the dep or 
reference a package not supported by the module we should be able to fail.


I do not want to distract this thread from the core issue (control on 
class-path versus module-path), but I believe that above concern can be 
avoided. Lets take --add-exports as an example. The syntax of the option 
passed to javac is:


   --add-exports source/package=target

Where /source/ and /target/ are module names. For example if a project 
is a module named "my.project" and that module is using the "org.junit" 
module as a dependency, we may want to add the following option:


   --add-exports my.project/my.internal.package=org.junit

It is possible to design the Maven POM in such a way that those modules 
are inferred from the context. The POM could look like this (simplified):


   my-project
   

   
  
junit

test

  
my.internal.package

  

  
   

Above would mean: if the JUnit dependency is added on the module-path 
(which happens only during tests), then automatically generate 
--add-exports options with:


 * The enclosing project ("my.project") as the source module.
 * The enclosing dependency ("org.junit") as the target module.
 * The specified  elements as the packages to exports.

A similar approach can be applied to other options. That way, module 
names do not appear anywhere and the inconsistency risk does not exist. 
This proposal does not cover all cases, but would provide a safe and 
easy way for probably the majority of cases. If a user needs to specify 
different modules than the ones inferred from the context (s)he can 
still add the --add-exports option manually on the command-line.


    Martin

Re: Maven 5 pom extension for agents

Hi Tamas,

You table shows exactly my point: you need to be able to compose
dependencies sets  (potentially named from user space)  and you can *not*
define types - or any similar solution - and let plugins get their config
from there.

If you don't you are not better than today and assume that in a maven
module you always use a jar at the same location.

A trivial example is that if you build a jar with javadoc and a generator
tool. The generator tool (which forks) which bounds on generate-resources
likely wants lib L as a module because it has a SPI in module-info and not
META-INF (thanks java) but the war needs to take into account the
type=module (because it must ignore modules by design since it only handles
classpath as of today) but if you do you broke your build exactly as today
with the guess logic.

Your proposal is similar to what was done for OSGi bundles but had several
side effects I prefer we don't enter in and ultimately if you want to go
that path it can belong to a github extension easily.

Last and likely very important: you are still not solving the transitivity
so we are back to the original point, either you code without any
dependency in your reactor or you are still at the first mail of that
thread.

I'm not sure why you absolutely want to solve it at type level but it
really can't by design due to the transitivity and control we must give per
plugin not artiact IMHO.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 2 nov. 2023 à 00:32, Tamás Cservenák  a écrit :

> consumer POM _especially_ remains outside of project limits (again, is
> "just outside of" but not "inside" of a reactor), so unsure what should
> that solve...
>
> the "fat" thing gives you exactly this ability, so unsure what the problem
> here is?
>
> T
>
> On Tue, Oct 31, 2023 at 8:05 AM Romain Manni-Bucau 
> wrote:
>
> > Le mar. 31 oct. 2023 à 00:22, Tamás Cservenák  a
> > écrit :
> >
> > > Oh, and just as "dependency reduced pom", the flatten does not work
> > within
> > > the reactor _either_.
> > >
> >
> > This part should be solved with consumer pom but within the reactor you
> > should get the same behavior in terms of dep with flattening anything.
> > Stays the multiartifacts issue where we still have a single pom but that
> > is  a maven module design issue.
> >
> > But yes, relocation and uber jar have the issue they are not well
> resolved
> > today and this is a reactor thing since a single artifact thing, agree.
> >
> >
> >
> > > In fact, the existence of a flatten plugin per se is an IMHO sign that
> > > "something is wrong" here.
> > >
> >
> >
> > We solved the pipeline for it so guess we passed it.
> > Flatten is more about cutting transitive visitor which is insanely slow
> > with resolver today.
> >
> >
> > > Thanks
> > > T
> > >
> > > On Tue, Oct 31, 2023 at 12:08 AM Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hmm, new types are not a real option for that, it is fully the
> > lifecycle
> > > > (plugin chain thesz days since lifecycles are never rich enough and
> it
> > > > depends too much on projects.
> > > >
> > > > Your fatjar example is not a type but the flatten plugin presence and
> > it
> > > is
> > > > really not a type cause it implies a specific pom resolution which is
> > out
> > > > of the artifact (type) handling scope.
> > > > IMHO we must not break that rule and not abuse of the resolver, it is
> > > > already overcomplex for its roleand once again does not help with
> > > jpms
> > > > or plugin config set outside very few plugin scope.
> > > >
> > > > If you use types for this fatjar dep handling you also require
> > downstream
> > > > projects to consume all their upstream chain plugins and handlers
> which
> > > is
> > > > not doable in real life so sticking to the fair minimum is wishable
> > > (agree
> > > > we wrongly added types as workarounds).
> > > >
> > > >
> > > > Le lun. 30 oct. 2023 à 22:00, Tamás Cservenák 
> a
> > > > écrit :
> > > >
> > > > > ... makes resolver STOP _whatever_ the referenced POM list as
> > > > dependencies
> > > > > (basically does not matter, the node once collected will NOT dive
> > into
> > > > > getting possible children).
> > > > >
> > > > > T
> > > > >
> > > > > On Mon, Oct 30, 2023 at 9:58 PM Tamás Cservenák <
> ta...@cservenak.net
> > >
> > > > > wrote:
> > > > >
> > > > > > The fat* mechanism is already present even in maven 3.9, but not
> so
> > > > > > visible:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L51
> > > > > >
> > > > > > Is "fat" when this method returns

Re: Maven 5 pom extension for agents

2023-11-01 Thread Tamás Cservenák

consumer POM _especially_ remains outside of project limits (again, is
"just outside of" but not "inside" of a reactor), so unsure what should
that solve...

the "fat" thing gives you exactly this ability, so unsure what the problem
here is?

T

On Tue, Oct 31, 2023 at 8:05 AM Romain Manni-Bucau 
wrote:

> Le mar. 31 oct. 2023 à 00:22, Tamás Cservenák  a
> écrit :
>
> > Oh, and just as "dependency reduced pom", the flatten does not work
> within
> > the reactor _either_.
> >
>
> This part should be solved with consumer pom but within the reactor you
> should get the same behavior in terms of dep with flattening anything.
> Stays the multiartifacts issue where we still have a single pom but that
> is  a maven module design issue.
>
> But yes, relocation and uber jar have the issue they are not well resolved
> today and this is a reactor thing since a single artifact thing, agree.
>
>
>
> > In fact, the existence of a flatten plugin per se is an IMHO sign that
> > "something is wrong" here.
> >
>
>
> We solved the pipeline for it so guess we passed it.
> Flatten is more about cutting transitive visitor which is insanely slow
> with resolver today.
>
>
> > Thanks
> > T
> >
> > On Tue, Oct 31, 2023 at 12:08 AM Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > wrote:
> >
> > > Hmm, new types are not a real option for that, it is fully the
> lifecycle
> > > (plugin chain thesz days since lifecycles are never rich enough and it
> > > depends too much on projects.
> > >
> > > Your fatjar example is not a type but the flatten plugin presence and
> it
> > is
> > > really not a type cause it implies a specific pom resolution which is
> out
> > > of the artifact (type) handling scope.
> > > IMHO we must not break that rule and not abuse of the resolver, it is
> > > already overcomplex for its roleand once again does not help with
> > jpms
> > > or plugin config set outside very few plugin scope.
> > >
> > > If you use types for this fatjar dep handling you also require
> downstream
> > > projects to consume all their upstream chain plugins and handlers which
> > is
> > > not doable in real life so sticking to the fair minimum is wishable
> > (agree
> > > we wrongly added types as workarounds).
> > >
> > >
> > > Le lun. 30 oct. 2023 à 22:00, Tamás Cservenák  a
> > > écrit :
> > >
> > > > ... makes resolver STOP _whatever_ the referenced POM list as
> > > dependencies
> > > > (basically does not matter, the node once collected will NOT dive
> into
> > > > getting possible children).
> > > >
> > > > T
> > > >
> > > > On Mon, Oct 30, 2023 at 9:58 PM Tamás Cservenák  >
> > > > wrote:
> > > >
> > > > > The fat* mechanism is already present even in maven 3.9, but not so
> > > > > visible:
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L51
> > > > >
> > > > > Is "fat" when this method returns true.
> > > > >
> > > > > Moreover, the new type would give you (as a consumer) more control,
> > it
> > > > > allows you to NOT depend on upstream publisher (is he rewriting
> POM?
> > > Does
> > > > > he do a good job rewriting it? etc). If you declare your dependency
> > as
> > > > > "fatjar" and not just "jar", or "fatmodule" not just "module", it
> > makes
> > > > > resolver STOP.
> > > > >
> > > > > Thanks
> > > > > T
> > > > >
> > > > > On Mon, Oct 30, 2023 at 9:53 PM Tamás Cservenák <
> ta...@cservenak.net
> > >
> > > > > wrote:
> > > > >
> > > > >> Howdy,
> > > > >>
> > > > >> The fat* is needed to STOP resolver resolving further external
> > > > >> dependencies (or in-reactor ones), it gives you more control to
> > > > _express_
> > > > >> this case to Maven.
> > > > >>
> > > > >> Typical case:
> > > > >> - you have in reactor "uber" JAR built (with replace POM set)
> > > > >> - hence, you deploy the rewritten POM, so for consumers you are OK
> > > > >> - BUT _within reactor_ Maven will NOT (and cannot) be aware of
> > > > >> _rewritten_ module, so you need to "exclude all" in subsequent
> > modules
> > > > >> depending on uber module:
> > > > >>
> > > > >> https://github.com/maveniverse/mima/blob/main/cli/pom.xml#L83-L94
> > > > >> So, this one would need to be type="fatjar" and result would be
> same
> > > but
> > > > >> more expressive:
> > > > >>
> > > > >> Basically these just extend the "vocabulary" to express what it
> is.
> > > > >>
> > > > >> T
> > > > >>
> > > > >> On Mon, Oct 30, 2023 at 9:35 PM Henning Schmiedehausen <
> > > > >> henn...@schmiedehausen.org> wrote:
> > > > >>
> > > > >>> I don't understand fatjar and fatmodule. Why would we need that?
> > How
> > > > >>> would
> > > > >>> maven treat this different from a regular jar / module ?
> > > > >>>
> > > > >>> -h
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On Sun, Oct 29, 2023 at 8:10 AM Tamás Cservenák <
> > ta...@cservenak.net
> > > >
> > > > >>> wrote:
> > > > >>>
> > > > >>> > Howdy,
> > > > >>> >
> > > > >>> > The cur

Re: Maven 5 pom extension for agents

2023-11-01 Thread Tamás Cservenák

Here is where I am currently:
https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support

T

On Tue, Oct 31, 2023 at 12:21 AM Tamás Cservenák 
wrote:

> Oh, and just as "dependency reduced pom", the flatten does not work within
> the reactor _either_.
>
> In fact, the existence of a flatten plugin per se is an IMHO sign that
> "something is wrong" here.
>
> Thanks
> T
>
> On Tue, Oct 31, 2023 at 12:08 AM Romain Manni-Bucau 
> wrote:
>
>> Hmm, new types are not a real option for that, it is fully the lifecycle
>> (plugin chain thesz days since lifecycles are never rich enough and it
>> depends too much on projects.
>>
>> Your fatjar example is not a type but the flatten plugin presence and it
>> is
>> really not a type cause it implies a specific pom resolution which is out
>> of the artifact (type) handling scope.
>> IMHO we must not break that rule and not abuse of the resolver, it is
>> already overcomplex for its roleand once again does not help with jpms
>> or plugin config set outside very few plugin scope.
>>
>> If you use types for this fatjar dep handling you also require downstream
>> projects to consume all their upstream chain plugins and handlers which is
>> not doable in real life so sticking to the fair minimum is wishable (agree
>> we wrongly added types as workarounds).
>>
>>
>> Le lun. 30 oct. 2023 à 22:00, Tamás Cservenák  a
>> écrit :
>>
>> > ... makes resolver STOP _whatever_ the referenced POM list as
>> dependencies
>> > (basically does not matter, the node once collected will NOT dive into
>> > getting possible children).
>> >
>> > T
>> >
>> > On Mon, Oct 30, 2023 at 9:58 PM Tamás Cservenák 
>> > wrote:
>> >
>> > > The fat* mechanism is already present even in maven 3.9, but not so
>> > > visible:
>> > >
>> > >
>> >
>> https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L51
>> > >
>> > > Is "fat" when this method returns true.
>> > >
>> > > Moreover, the new type would give you (as a consumer) more control, it
>> > > allows you to NOT depend on upstream publisher (is he rewriting POM?
>> Does
>> > > he do a good job rewriting it? etc). If you declare your dependency as
>> > > "fatjar" and not just "jar", or "fatmodule" not just "module", it
>> makes
>> > > resolver STOP.
>> > >
>> > > Thanks
>> > > T
>> > >
>> > > On Mon, Oct 30, 2023 at 9:53 PM Tamás Cservenák 
>> > > wrote:
>> > >
>> > >> Howdy,
>> > >>
>> > >> The fat* is needed to STOP resolver resolving further external
>> > >> dependencies (or in-reactor ones), it gives you more control to
>> > _express_
>> > >> this case to Maven.
>> > >>
>> > >> Typical case:
>> > >> - you have in reactor "uber" JAR built (with replace POM set)
>> > >> - hence, you deploy the rewritten POM, so for consumers you are OK
>> > >> - BUT _within reactor_ Maven will NOT (and cannot) be aware of
>> > >> _rewritten_ module, so you need to "exclude all" in subsequent
>> modules
>> > >> depending on uber module:
>> > >>
>> > >> https://github.com/maveniverse/mima/blob/main/cli/pom.xml#L83-L94
>> > >> So, this one would need to be type="fatjar" and result would be same
>> but
>> > >> more expressive:
>> > >>
>> > >> Basically these just extend the "vocabulary" to express what it is.
>> > >>
>> > >> T
>> > >>
>> > >> On Mon, Oct 30, 2023 at 9:35 PM Henning Schmiedehausen <
>> > >> henn...@schmiedehausen.org> wrote:
>> > >>
>> > >>> I don't understand fatjar and fatmodule. Why would we need that? How
>> > >>> would
>> > >>> maven treat this different from a regular jar / module ?
>> > >>>
>> > >>> -h
>> > >>>
>> > >>>
>> > >>>
>> > >>> On Sun, Oct 29, 2023 at 8:10 AM Tamás Cservenák <
>> ta...@cservenak.net>
>> > >>> wrote:
>> > >>>
>> > >>> > Howdy,
>> > >>> >
>> > >>> > The current draft of types we want to introduce (and  packaging):
>> > >>> > https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
>> > >>> >
>> > >>> > ===
>> > >>> >
>> > >>> > Romain, I don't understand your "This is wrong, downstream is
>> either
>> > >>> module
>> > >>> > or jar", as it was actually you and your example that mentioned
>> "once
>> > >>> put
>> > >>> > it here, once put it there". Nothing is lost IMHO, just like in
>> case
>> > of
>> > >>> > "takari-jar" nothing is lost.
>> > >>> >
>> > >>> > Or if we misunderstood each other: by "downstream" I mean "down
>> the
>> > >>> road,
>> > >>> > when a project being built, is about to be consumed as
>> dependency".
>> > >>> >
>> > >>> > And the point is, that exactly due
>> ArtifactHandler/ArtifactType/Type
>> > >>> (in
>> > >>> > mvn4), Maven "sees" it as "jar" or "module" or whatever, but for
>> > >>> resolver,
>> > >>> > those two are _same thing_. It is _same file_. And this is the
>> crux,
>> > >>> as for
>> > >>> > the resolver, it is really about getting that one file, while the
>> > type
>> > >>> (for
>> > >>> > Maven) tells HOW to make use of it. So for resolving, there is no
>> any
>> > >>> kind
>

Re: Maven 5 pom extension for agents

2023-10-31 Thread Romain Manni-Bucau

Le mar. 31 oct. 2023 à 00:22, Tamás Cservenák  a
écrit :

> Oh, and just as "dependency reduced pom", the flatten does not work within
> the reactor _either_.
>

This part should be solved with consumer pom but within the reactor you
should get the same behavior in terms of dep with flattening anything.
Stays the multiartifacts issue where we still have a single pom but that
is  a maven module design issue.

But yes, relocation and uber jar have the issue they are not well resolved
today and this is a reactor thing since a single artifact thing, agree.



> In fact, the existence of a flatten plugin per se is an IMHO sign that
> "something is wrong" here.
>


We solved the pipeline for it so guess we passed it.
Flatten is more about cutting transitive visitor which is insanely slow
with resolver today.


> Thanks
> T
>
> On Tue, Oct 31, 2023 at 12:08 AM Romain Manni-Bucau  >
> wrote:
>
> > Hmm, new types are not a real option for that, it is fully the lifecycle
> > (plugin chain thesz days since lifecycles are never rich enough and it
> > depends too much on projects.
> >
> > Your fatjar example is not a type but the flatten plugin presence and it
> is
> > really not a type cause it implies a specific pom resolution which is out
> > of the artifact (type) handling scope.
> > IMHO we must not break that rule and not abuse of the resolver, it is
> > already overcomplex for its roleand once again does not help with
> jpms
> > or plugin config set outside very few plugin scope.
> >
> > If you use types for this fatjar dep handling you also require downstream
> > projects to consume all their upstream chain plugins and handlers which
> is
> > not doable in real life so sticking to the fair minimum is wishable
> (agree
> > we wrongly added types as workarounds).
> >
> >
> > Le lun. 30 oct. 2023 à 22:00, Tamás Cservenák  a
> > écrit :
> >
> > > ... makes resolver STOP _whatever_ the referenced POM list as
> > dependencies
> > > (basically does not matter, the node once collected will NOT dive into
> > > getting possible children).
> > >
> > > T
> > >
> > > On Mon, Oct 30, 2023 at 9:58 PM Tamás Cservenák 
> > > wrote:
> > >
> > > > The fat* mechanism is already present even in maven 3.9, but not so
> > > > visible:
> > > >
> > > >
> > >
> >
> https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L51
> > > >
> > > > Is "fat" when this method returns true.
> > > >
> > > > Moreover, the new type would give you (as a consumer) more control,
> it
> > > > allows you to NOT depend on upstream publisher (is he rewriting POM?
> > Does
> > > > he do a good job rewriting it? etc). If you declare your dependency
> as
> > > > "fatjar" and not just "jar", or "fatmodule" not just "module", it
> makes
> > > > resolver STOP.
> > > >
> > > > Thanks
> > > > T
> > > >
> > > > On Mon, Oct 30, 2023 at 9:53 PM Tamás Cservenák  >
> > > > wrote:
> > > >
> > > >> Howdy,
> > > >>
> > > >> The fat* is needed to STOP resolver resolving further external
> > > >> dependencies (or in-reactor ones), it gives you more control to
> > > _express_
> > > >> this case to Maven.
> > > >>
> > > >> Typical case:
> > > >> - you have in reactor "uber" JAR built (with replace POM set)
> > > >> - hence, you deploy the rewritten POM, so for consumers you are OK
> > > >> - BUT _within reactor_ Maven will NOT (and cannot) be aware of
> > > >> _rewritten_ module, so you need to "exclude all" in subsequent
> modules
> > > >> depending on uber module:
> > > >>
> > > >> https://github.com/maveniverse/mima/blob/main/cli/pom.xml#L83-L94
> > > >> So, this one would need to be type="fatjar" and result would be same
> > but
> > > >> more expressive:
> > > >>
> > > >> Basically these just extend the "vocabulary" to express what it is.
> > > >>
> > > >> T
> > > >>
> > > >> On Mon, Oct 30, 2023 at 9:35 PM Henning Schmiedehausen <
> > > >> henn...@schmiedehausen.org> wrote:
> > > >>
> > > >>> I don't understand fatjar and fatmodule. Why would we need that?
> How
> > > >>> would
> > > >>> maven treat this different from a regular jar / module ?
> > > >>>
> > > >>> -h
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Sun, Oct 29, 2023 at 8:10 AM Tamás Cservenák <
> ta...@cservenak.net
> > >
> > > >>> wrote:
> > > >>>
> > > >>> > Howdy,
> > > >>> >
> > > >>> > The current draft of types we want to introduce (and  packaging):
> > > >>> > https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
> > > >>> >
> > > >>> > ===
> > > >>> >
> > > >>> > Romain, I don't understand your "This is wrong, downstream is
> > either
> > > >>> module
> > > >>> > or jar", as it was actually you and your example that mentioned
> > "once
> > > >>> put
> > > >>> > it here, once put it there". Nothing is lost IMHO, just like in
> > case
> > > of
> > > >>> > "takari-jar" nothing is lost.
> > > >>> >
> > > >>> > Or if we misunderstood each other: by "downstream" I mean "down
> the
> > > >>> road,
> > > >>> > when a proje

Re: Maven 5 pom extension for agents

Oh, and just as "dependency reduced pom", the flatten does not work within
the reactor _either_.

In fact, the existence of a flatten plugin per se is an IMHO sign that
"something is wrong" here.

Thanks
T

On Tue, Oct 31, 2023 at 12:08 AM Romain Manni-Bucau 
wrote:

> Hmm, new types are not a real option for that, it is fully the lifecycle
> (plugin chain thesz days since lifecycles are never rich enough and it
> depends too much on projects.
>
> Your fatjar example is not a type but the flatten plugin presence and it is
> really not a type cause it implies a specific pom resolution which is out
> of the artifact (type) handling scope.
> IMHO we must not break that rule and not abuse of the resolver, it is
> already overcomplex for its roleand once again does not help with jpms
> or plugin config set outside very few plugin scope.
>
> If you use types for this fatjar dep handling you also require downstream
> projects to consume all their upstream chain plugins and handlers which is
> not doable in real life so sticking to the fair minimum is wishable (agree
> we wrongly added types as workarounds).
>
>
> Le lun. 30 oct. 2023 à 22:00, Tamás Cservenák  a
> écrit :
>
> > ... makes resolver STOP _whatever_ the referenced POM list as
> dependencies
> > (basically does not matter, the node once collected will NOT dive into
> > getting possible children).
> >
> > T
> >
> > On Mon, Oct 30, 2023 at 9:58 PM Tamás Cservenák 
> > wrote:
> >
> > > The fat* mechanism is already present even in maven 3.9, but not so
> > > visible:
> > >
> > >
> >
> https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L51
> > >
> > > Is "fat" when this method returns true.
> > >
> > > Moreover, the new type would give you (as a consumer) more control, it
> > > allows you to NOT depend on upstream publisher (is he rewriting POM?
> Does
> > > he do a good job rewriting it? etc). If you declare your dependency as
> > > "fatjar" and not just "jar", or "fatmodule" not just "module", it makes
> > > resolver STOP.
> > >
> > > Thanks
> > > T
> > >
> > > On Mon, Oct 30, 2023 at 9:53 PM Tamás Cservenák 
> > > wrote:
> > >
> > >> Howdy,
> > >>
> > >> The fat* is needed to STOP resolver resolving further external
> > >> dependencies (or in-reactor ones), it gives you more control to
> > _express_
> > >> this case to Maven.
> > >>
> > >> Typical case:
> > >> - you have in reactor "uber" JAR built (with replace POM set)
> > >> - hence, you deploy the rewritten POM, so for consumers you are OK
> > >> - BUT _within reactor_ Maven will NOT (and cannot) be aware of
> > >> _rewritten_ module, so you need to "exclude all" in subsequent modules
> > >> depending on uber module:
> > >>
> > >> https://github.com/maveniverse/mima/blob/main/cli/pom.xml#L83-L94
> > >> So, this one would need to be type="fatjar" and result would be same
> but
> > >> more expressive:
> > >>
> > >> Basically these just extend the "vocabulary" to express what it is.
> > >>
> > >> T
> > >>
> > >> On Mon, Oct 30, 2023 at 9:35 PM Henning Schmiedehausen <
> > >> henn...@schmiedehausen.org> wrote:
> > >>
> > >>> I don't understand fatjar and fatmodule. Why would we need that? How
> > >>> would
> > >>> maven treat this different from a regular jar / module ?
> > >>>
> > >>> -h
> > >>>
> > >>>
> > >>>
> > >>> On Sun, Oct 29, 2023 at 8:10 AM Tamás Cservenák  >
> > >>> wrote:
> > >>>
> > >>> > Howdy,
> > >>> >
> > >>> > The current draft of types we want to introduce (and  packaging):
> > >>> > https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
> > >>> >
> > >>> > ===
> > >>> >
> > >>> > Romain, I don't understand your "This is wrong, downstream is
> either
> > >>> module
> > >>> > or jar", as it was actually you and your example that mentioned
> "once
> > >>> put
> > >>> > it here, once put it there". Nothing is lost IMHO, just like in
> case
> > of
> > >>> > "takari-jar" nothing is lost.
> > >>> >
> > >>> > Or if we misunderstood each other: by "downstream" I mean "down the
> > >>> road,
> > >>> > when a project being built, is about to be consumed as dependency".
> > >>> >
> > >>> > And the point is, that exactly due
> ArtifactHandler/ArtifactType/Type
> > >>> (in
> > >>> > mvn4), Maven "sees" it as "jar" or "module" or whatever, but for
> > >>> resolver,
> > >>> > those two are _same thing_. It is _same file_. And this is the
> crux,
> > >>> as for
> > >>> > the resolver, it is really about getting that one file, while the
> > type
> > >>> (for
> > >>> > Maven) tells HOW to make use of it. So for resolving, there is no
> any
> > >>> kind
> > >>> > of "lost" information, again, the very same way it works for
> > >>> "takari-jar".
> > >>> >
> > >>> > T
> > >>> >
> > >>> > On Sun, Oct 29, 2023 at 3:52 PM Romain Manni-Bucau <
> > >>> rmannibu...@gmail.com>
> > >>> > wrote:
> > >>> >
> > >>> > > Le dim. 29 oct. 2023 à 15:29, Tamás Cservenák <
> ta...@cservenak.net
> > >
> > >>> a
> > >>> > > écrit

Re: Maven 5 pom extension for agents

Romain, the "fat" flag was always present, since Maven 3.0 (with
introduction of resolver).
Really, nothing new here. Even you already use it (without knowing).

Resolver is (and was) abused currently (see my other mail), this is more to
unleash its potential instead.

T

On Tue, Oct 31, 2023 at 12:08 AM Romain Manni-Bucau 
wrote:

> Hmm, new types are not a real option for that, it is fully the lifecycle
> (plugin chain thesz days since lifecycles are never rich enough and it
> depends too much on projects.
>
> Your fatjar example is not a type but the flatten plugin presence and it is
> really not a type cause it implies a specific pom resolution which is out
> of the artifact (type) handling scope.
> IMHO we must not break that rule and not abuse of the resolver, it is
> already overcomplex for its roleand once again does not help with jpms
> or plugin config set outside very few plugin scope.
>
> If you use types for this fatjar dep handling you also require downstream
> projects to consume all their upstream chain plugins and handlers which is
> not doable in real life so sticking to the fair minimum is wishable (agree
> we wrongly added types as workarounds).
>
>
> Le lun. 30 oct. 2023 à 22:00, Tamás Cservenák  a
> écrit :
>
> > ... makes resolver STOP _whatever_ the referenced POM list as
> dependencies
> > (basically does not matter, the node once collected will NOT dive into
> > getting possible children).
> >
> > T
> >
> > On Mon, Oct 30, 2023 at 9:58 PM Tamás Cservenák 
> > wrote:
> >
> > > The fat* mechanism is already present even in maven 3.9, but not so
> > > visible:
> > >
> > >
> >
> https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L51
> > >
> > > Is "fat" when this method returns true.
> > >
> > > Moreover, the new type would give you (as a consumer) more control, it
> > > allows you to NOT depend on upstream publisher (is he rewriting POM?
> Does
> > > he do a good job rewriting it? etc). If you declare your dependency as
> > > "fatjar" and not just "jar", or "fatmodule" not just "module", it makes
> > > resolver STOP.
> > >
> > > Thanks
> > > T
> > >
> > > On Mon, Oct 30, 2023 at 9:53 PM Tamás Cservenák 
> > > wrote:
> > >
> > >> Howdy,
> > >>
> > >> The fat* is needed to STOP resolver resolving further external
> > >> dependencies (or in-reactor ones), it gives you more control to
> > _express_
> > >> this case to Maven.
> > >>
> > >> Typical case:
> > >> - you have in reactor "uber" JAR built (with replace POM set)
> > >> - hence, you deploy the rewritten POM, so for consumers you are OK
> > >> - BUT _within reactor_ Maven will NOT (and cannot) be aware of
> > >> _rewritten_ module, so you need to "exclude all" in subsequent modules
> > >> depending on uber module:
> > >>
> > >> https://github.com/maveniverse/mima/blob/main/cli/pom.xml#L83-L94
> > >> So, this one would need to be type="fatjar" and result would be same
> but
> > >> more expressive:
> > >>
> > >> Basically these just extend the "vocabulary" to express what it is.
> > >>
> > >> T
> > >>
> > >> On Mon, Oct 30, 2023 at 9:35 PM Henning Schmiedehausen <
> > >> henn...@schmiedehausen.org> wrote:
> > >>
> > >>> I don't understand fatjar and fatmodule. Why would we need that? How
> > >>> would
> > >>> maven treat this different from a regular jar / module ?
> > >>>
> > >>> -h
> > >>>
> > >>>
> > >>>
> > >>> On Sun, Oct 29, 2023 at 8:10 AM Tamás Cservenák  >
> > >>> wrote:
> > >>>
> > >>> > Howdy,
> > >>> >
> > >>> > The current draft of types we want to introduce (and  packaging):
> > >>> > https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
> > >>> >
> > >>> > ===
> > >>> >
> > >>> > Romain, I don't understand your "This is wrong, downstream is
> either
> > >>> module
> > >>> > or jar", as it was actually you and your example that mentioned
> "once
> > >>> put
> > >>> > it here, once put it there". Nothing is lost IMHO, just like in
> case
> > of
> > >>> > "takari-jar" nothing is lost.
> > >>> >
> > >>> > Or if we misunderstood each other: by "downstream" I mean "down the
> > >>> road,
> > >>> > when a project being built, is about to be consumed as dependency".
> > >>> >
> > >>> > And the point is, that exactly due
> ArtifactHandler/ArtifactType/Type
> > >>> (in
> > >>> > mvn4), Maven "sees" it as "jar" or "module" or whatever, but for
> > >>> resolver,
> > >>> > those two are _same thing_. It is _same file_. And this is the
> crux,
> > >>> as for
> > >>> > the resolver, it is really about getting that one file, while the
> > type
> > >>> (for
> > >>> > Maven) tells HOW to make use of it. So for resolving, there is no
> any
> > >>> kind
> > >>> > of "lost" information, again, the very same way it works for
> > >>> "takari-jar".
> > >>> >
> > >>> > T
> > >>> >
> > >>> > On Sun, Oct 29, 2023 at 3:52 PM Romain Manni-Bucau <
> > >>> rmannibu...@gmail.com>
> > >>> > wrote:
> > >>> >
> > >>> > > Le dim. 29 oct. 2023 à 15:29, Tamás C

Re: Maven 5 pom extension for agents

2023-10-30 Thread Romain Manni-Bucau

Hmm, new types are not a real option for that, it is fully the lifecycle
(plugin chain thesz days since lifecycles are never rich enough and it
depends too much on projects.

Your fatjar example is not a type but the flatten plugin presence and it is
really not a type cause it implies a specific pom resolution which is out
of the artifact (type) handling scope.
IMHO we must not break that rule and not abuse of the resolver, it is
already overcomplex for its roleand once again does not help with jpms
or plugin config set outside very few plugin scope.

If you use types for this fatjar dep handling you also require downstream
projects to consume all their upstream chain plugins and handlers which is
not doable in real life so sticking to the fair minimum is wishable (agree
we wrongly added types as workarounds).


Le lun. 30 oct. 2023 à 22:00, Tamás Cservenák  a
écrit :

> ... makes resolver STOP _whatever_ the referenced POM list as dependencies
> (basically does not matter, the node once collected will NOT dive into
> getting possible children).
>
> T
>
> On Mon, Oct 30, 2023 at 9:58 PM Tamás Cservenák 
> wrote:
>
> > The fat* mechanism is already present even in maven 3.9, but not so
> > visible:
> >
> >
> https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L51
> >
> > Is "fat" when this method returns true.
> >
> > Moreover, the new type would give you (as a consumer) more control, it
> > allows you to NOT depend on upstream publisher (is he rewriting POM? Does
> > he do a good job rewriting it? etc). If you declare your dependency as
> > "fatjar" and not just "jar", or "fatmodule" not just "module", it makes
> > resolver STOP.
> >
> > Thanks
> > T
> >
> > On Mon, Oct 30, 2023 at 9:53 PM Tamás Cservenák 
> > wrote:
> >
> >> Howdy,
> >>
> >> The fat* is needed to STOP resolver resolving further external
> >> dependencies (or in-reactor ones), it gives you more control to
> _express_
> >> this case to Maven.
> >>
> >> Typical case:
> >> - you have in reactor "uber" JAR built (with replace POM set)
> >> - hence, you deploy the rewritten POM, so for consumers you are OK
> >> - BUT _within reactor_ Maven will NOT (and cannot) be aware of
> >> _rewritten_ module, so you need to "exclude all" in subsequent modules
> >> depending on uber module:
> >>
> >> https://github.com/maveniverse/mima/blob/main/cli/pom.xml#L83-L94
> >> So, this one would need to be type="fatjar" and result would be same but
> >> more expressive:
> >>
> >> Basically these just extend the "vocabulary" to express what it is.
> >>
> >> T
> >>
> >> On Mon, Oct 30, 2023 at 9:35 PM Henning Schmiedehausen <
> >> henn...@schmiedehausen.org> wrote:
> >>
> >>> I don't understand fatjar and fatmodule. Why would we need that? How
> >>> would
> >>> maven treat this different from a regular jar / module ?
> >>>
> >>> -h
> >>>
> >>>
> >>>
> >>> On Sun, Oct 29, 2023 at 8:10 AM Tamás Cservenák 
> >>> wrote:
> >>>
> >>> > Howdy,
> >>> >
> >>> > The current draft of types we want to introduce (and  packaging):
> >>> > https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
> >>> >
> >>> > ===
> >>> >
> >>> > Romain, I don't understand your "This is wrong, downstream is either
> >>> module
> >>> > or jar", as it was actually you and your example that mentioned "once
> >>> put
> >>> > it here, once put it there". Nothing is lost IMHO, just like in case
> of
> >>> > "takari-jar" nothing is lost.
> >>> >
> >>> > Or if we misunderstood each other: by "downstream" I mean "down the
> >>> road,
> >>> > when a project being built, is about to be consumed as dependency".
> >>> >
> >>> > And the point is, that exactly due ArtifactHandler/ArtifactType/Type
> >>> (in
> >>> > mvn4), Maven "sees" it as "jar" or "module" or whatever, but for
> >>> resolver,
> >>> > those two are _same thing_. It is _same file_. And this is the crux,
> >>> as for
> >>> > the resolver, it is really about getting that one file, while the
> type
> >>> (for
> >>> > Maven) tells HOW to make use of it. So for resolving, there is no any
> >>> kind
> >>> > of "lost" information, again, the very same way it works for
> >>> "takari-jar".
> >>> >
> >>> > T
> >>> >
> >>> > On Sun, Oct 29, 2023 at 3:52 PM Romain Manni-Bucau <
> >>> rmannibu...@gmail.com>
> >>> > wrote:
> >>> >
> >>> > > Le dim. 29 oct. 2023 à 15:29, Tamás Cservenák  >
> >>> a
> >>> > > écrit :
> >>> > >
> >>> > > > Howdy,
> >>> > > >
> >>> > > > So to return to the "root" idea (of Maven), Maven is
> "declarative",
> >>> > where
> >>> > > > users should declare what they want, it should most certainly not
> >>> > "guess"
> >>> > > > what user intent is. As long as we have "magical implicit
> >>> guesswork"
> >>> > > (like
> >>> > > > that in javadoc) present in process, it is bad, as that means we
> >>> do not
> >>> > > > allow our users to express their goal.
> >>> > > >
> >>> > >
> >>> > > Yes and i liked that but we broke it with forcing plugin

Re: Maven 5 pom extension for agents

... makes resolver STOP _whatever_ the referenced POM list as dependencies
(basically does not matter, the node once collected will NOT dive into
getting possible children).

T

On Mon, Oct 30, 2023 at 9:58 PM Tamás Cservenák  wrote:

> The fat* mechanism is already present even in maven 3.9, but not so
> visible:
>
> https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L51
>
> Is "fat" when this method returns true.
>
> Moreover, the new type would give you (as a consumer) more control, it
> allows you to NOT depend on upstream publisher (is he rewriting POM? Does
> he do a good job rewriting it? etc). If you declare your dependency as
> "fatjar" and not just "jar", or "fatmodule" not just "module", it makes
> resolver STOP.
>
> Thanks
> T
>
> On Mon, Oct 30, 2023 at 9:53 PM Tamás Cservenák 
> wrote:
>
>> Howdy,
>>
>> The fat* is needed to STOP resolver resolving further external
>> dependencies (or in-reactor ones), it gives you more control to _express_
>> this case to Maven.
>>
>> Typical case:
>> - you have in reactor "uber" JAR built (with replace POM set)
>> - hence, you deploy the rewritten POM, so for consumers you are OK
>> - BUT _within reactor_ Maven will NOT (and cannot) be aware of
>> _rewritten_ module, so you need to "exclude all" in subsequent modules
>> depending on uber module:
>>
>> https://github.com/maveniverse/mima/blob/main/cli/pom.xml#L83-L94
>> So, this one would need to be type="fatjar" and result would be same but
>> more expressive:
>>
>> Basically these just extend the "vocabulary" to express what it is.
>>
>> T
>>
>> On Mon, Oct 30, 2023 at 9:35 PM Henning Schmiedehausen <
>> henn...@schmiedehausen.org> wrote:
>>
>>> I don't understand fatjar and fatmodule. Why would we need that? How
>>> would
>>> maven treat this different from a regular jar / module ?
>>>
>>> -h
>>>
>>>
>>>
>>> On Sun, Oct 29, 2023 at 8:10 AM Tamás Cservenák 
>>> wrote:
>>>
>>> > Howdy,
>>> >
>>> > The current draft of types we want to introduce (and  packaging):
>>> > https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
>>> >
>>> > ===
>>> >
>>> > Romain, I don't understand your "This is wrong, downstream is either
>>> module
>>> > or jar", as it was actually you and your example that mentioned "once
>>> put
>>> > it here, once put it there". Nothing is lost IMHO, just like in case of
>>> > "takari-jar" nothing is lost.
>>> >
>>> > Or if we misunderstood each other: by "downstream" I mean "down the
>>> road,
>>> > when a project being built, is about to be consumed as dependency".
>>> >
>>> > And the point is, that exactly due ArtifactHandler/ArtifactType/Type
>>> (in
>>> > mvn4), Maven "sees" it as "jar" or "module" or whatever, but for
>>> resolver,
>>> > those two are _same thing_. It is _same file_. And this is the crux,
>>> as for
>>> > the resolver, it is really about getting that one file, while the type
>>> (for
>>> > Maven) tells HOW to make use of it. So for resolving, there is no any
>>> kind
>>> > of "lost" information, again, the very same way it works for
>>> "takari-jar".
>>> >
>>> > T
>>> >
>>> > On Sun, Oct 29, 2023 at 3:52 PM Romain Manni-Bucau <
>>> rmannibu...@gmail.com>
>>> > wrote:
>>> >
>>> > > Le dim. 29 oct. 2023 à 15:29, Tamás Cservenák 
>>> a
>>> > > écrit :
>>> > >
>>> > > > Howdy,
>>> > > >
>>> > > > So to return to the "root" idea (of Maven), Maven is "declarative",
>>> > where
>>> > > > users should declare what they want, it should most certainly not
>>> > "guess"
>>> > > > what user intent is. As long as we have "magical implicit
>>> guesswork"
>>> > > (like
>>> > > > that in javadoc) present in process, it is bad, as that means we
>>> do not
>>> > > > allow our users to express their goal.
>>> > > >
>>> > >
>>> > > Yes and i liked that but we broke it with forcing plugin version
>>> locking
>>> > > (for good) so we can need to revise our root too to match current
>>> world
>>> > > which is no more unique, makes years we ignore that fact but it
>>> already
>>> > > blows up.
>>> > >
>>> > > So my 2cts are  we cant by design here, we tried hard and failed, not
>>> > > technically but by design.
>>> > >
>>> > >
>>> > >
>>> > > > Originally Mojos were envisioned to be simple, focused, doing one
>>> thing
>>> > > and
>>> > > > doing it well (a la UNIX tools). Some plugins went in the total
>>> > opposite
>>> > > > direction, as they became Godzilla plugins (with unmaintainable
>>> complex
>>> > > and
>>> > > > large amounts of "logic" -- guess logic and bloated codebase)
>>> targeting
>>> > > to
>>> > > > solve "everything". This also resulted in our users assuming "every
>>> > > problem
>>> > > > should have a corresponding Mojo" (this also steered toward
>>> bloated,
>>> > over
>>> > > > complex Mojos), where many many other aspects and capabilities of
>>> Maven
>>> > > > were totally neglected, like lifecycle, custom packaging and so on.
>>> > > >
>>> > > > In short, Romain, yes, toda

Re: Maven 5 pom extension for agents

The fat* mechanism is already present even in maven 3.9, but not so visible:
https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L51

Is "fat" when this method returns true.

Moreover, the new type would give you (as a consumer) more control, it
allows you to NOT depend on upstream publisher (is he rewriting POM? Does
he do a good job rewriting it? etc). If you declare your dependency as
"fatjar" and not just "jar", or "fatmodule" not just "module", it makes
resolver STOP.

Thanks
T

On Mon, Oct 30, 2023 at 9:53 PM Tamás Cservenák  wrote:

> Howdy,
>
> The fat* is needed to STOP resolver resolving further external
> dependencies (or in-reactor ones), it gives you more control to _express_
> this case to Maven.
>
> Typical case:
> - you have in reactor "uber" JAR built (with replace POM set)
> - hence, you deploy the rewritten POM, so for consumers you are OK
> - BUT _within reactor_ Maven will NOT (and cannot) be aware of _rewritten_
> module, so you need to "exclude all" in subsequent modules depending on
> uber module:
>
> https://github.com/maveniverse/mima/blob/main/cli/pom.xml#L83-L94
> So, this one would need to be type="fatjar" and result would be same but
> more expressive:
>
> Basically these just extend the "vocabulary" to express what it is.
>
> T
>
> On Mon, Oct 30, 2023 at 9:35 PM Henning Schmiedehausen <
> henn...@schmiedehausen.org> wrote:
>
>> I don't understand fatjar and fatmodule. Why would we need that? How would
>> maven treat this different from a regular jar / module ?
>>
>> -h
>>
>>
>>
>> On Sun, Oct 29, 2023 at 8:10 AM Tamás Cservenák 
>> wrote:
>>
>> > Howdy,
>> >
>> > The current draft of types we want to introduce (and  packaging):
>> > https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
>> >
>> > ===
>> >
>> > Romain, I don't understand your "This is wrong, downstream is either
>> module
>> > or jar", as it was actually you and your example that mentioned "once
>> put
>> > it here, once put it there". Nothing is lost IMHO, just like in case of
>> > "takari-jar" nothing is lost.
>> >
>> > Or if we misunderstood each other: by "downstream" I mean "down the
>> road,
>> > when a project being built, is about to be consumed as dependency".
>> >
>> > And the point is, that exactly due ArtifactHandler/ArtifactType/Type (in
>> > mvn4), Maven "sees" it as "jar" or "module" or whatever, but for
>> resolver,
>> > those two are _same thing_. It is _same file_. And this is the crux, as
>> for
>> > the resolver, it is really about getting that one file, while the type
>> (for
>> > Maven) tells HOW to make use of it. So for resolving, there is no any
>> kind
>> > of "lost" information, again, the very same way it works for
>> "takari-jar".
>> >
>> > T
>> >
>> > On Sun, Oct 29, 2023 at 3:52 PM Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> > wrote:
>> >
>> > > Le dim. 29 oct. 2023 à 15:29, Tamás Cservenák  a
>> > > écrit :
>> > >
>> > > > Howdy,
>> > > >
>> > > > So to return to the "root" idea (of Maven), Maven is "declarative",
>> > where
>> > > > users should declare what they want, it should most certainly not
>> > "guess"
>> > > > what user intent is. As long as we have "magical implicit guesswork"
>> > > (like
>> > > > that in javadoc) present in process, it is bad, as that means we do
>> not
>> > > > allow our users to express their goal.
>> > > >
>> > >
>> > > Yes and i liked that but we broke it with forcing plugin version
>> locking
>> > > (for good) so we can need to revise our root too to match current
>> world
>> > > which is no more unique, makes years we ignore that fact but it
>> already
>> > > blows up.
>> > >
>> > > So my 2cts are  we cant by design here, we tried hard and failed, not
>> > > technically but by design.
>> > >
>> > >
>> > >
>> > > > Originally Mojos were envisioned to be simple, focused, doing one
>> thing
>> > > and
>> > > > doing it well (a la UNIX tools). Some plugins went in the total
>> > opposite
>> > > > direction, as they became Godzilla plugins (with unmaintainable
>> complex
>> > > and
>> > > > large amounts of "logic" -- guess logic and bloated codebase)
>> targeting
>> > > to
>> > > > solve "everything". This also resulted in our users assuming "every
>> > > problem
>> > > > should have a corresponding Mojo" (this also steered toward bloated,
>> > over
>> > > > complex Mojos), where many many other aspects and capabilities of
>> Maven
>> > > > were totally neglected, like lifecycle, custom packaging and so on.
>> > > >
>> > > > In short, Romain, yes, today, you CAN build all sort of things in
>> > "smart
>> > > > way", just like cooking a soup: get a good base (packaging), add a
>> > little
>> > > > bit of this (mojo A) and a little bit of that (mojo B) and voila,
>> you
>> > > will
>> > > > end up with a "soup". And it works, yes, but this "smart" way has
>> many
>> > > > pitfalls along the way, with most problematic of not being explicit.
>> > But
>> >

Re: Maven 5 pom extension for agents

Howdy,

The fat* is needed to STOP resolver resolving further external dependencies
(or in-reactor ones), it gives you more control to _express_ this case to
Maven.

Typical case:
- you have in reactor "uber" JAR built (with replace POM set)
- hence, you deploy the rewritten POM, so for consumers you are OK
- BUT _within reactor_ Maven will NOT (and cannot) be aware of _rewritten_
module, so you need to "exclude all" in subsequent modules depending on
uber module:

https://github.com/maveniverse/mima/blob/main/cli/pom.xml#L83-L94
So, this one would need to be type="fatjar" and result would be same but
more expressive:

Basically these just extend the "vocabulary" to express what it is.

T

On Mon, Oct 30, 2023 at 9:35 PM Henning Schmiedehausen <
henn...@schmiedehausen.org> wrote:

> I don't understand fatjar and fatmodule. Why would we need that? How would
> maven treat this different from a regular jar / module ?
>
> -h
>
>
>
> On Sun, Oct 29, 2023 at 8:10 AM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > The current draft of types we want to introduce (and  packaging):
> > https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
> >
> > ===
> >
> > Romain, I don't understand your "This is wrong, downstream is either
> module
> > or jar", as it was actually you and your example that mentioned "once put
> > it here, once put it there". Nothing is lost IMHO, just like in case of
> > "takari-jar" nothing is lost.
> >
> > Or if we misunderstood each other: by "downstream" I mean "down the road,
> > when a project being built, is about to be consumed as dependency".
> >
> > And the point is, that exactly due ArtifactHandler/ArtifactType/Type (in
> > mvn4), Maven "sees" it as "jar" or "module" or whatever, but for
> resolver,
> > those two are _same thing_. It is _same file_. And this is the crux, as
> for
> > the resolver, it is really about getting that one file, while the type
> (for
> > Maven) tells HOW to make use of it. So for resolving, there is no any
> kind
> > of "lost" information, again, the very same way it works for
> "takari-jar".
> >
> > T
> >
> > On Sun, Oct 29, 2023 at 3:52 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Le dim. 29 oct. 2023 à 15:29, Tamás Cservenák  a
> > > écrit :
> > >
> > > > Howdy,
> > > >
> > > > So to return to the "root" idea (of Maven), Maven is "declarative",
> > where
> > > > users should declare what they want, it should most certainly not
> > "guess"
> > > > what user intent is. As long as we have "magical implicit guesswork"
> > > (like
> > > > that in javadoc) present in process, it is bad, as that means we do
> not
> > > > allow our users to express their goal.
> > > >
> > >
> > > Yes and i liked that but we broke it with forcing plugin version
> locking
> > > (for good) so we can need to revise our root too to match current world
> > > which is no more unique, makes years we ignore that fact but it already
> > > blows up.
> > >
> > > So my 2cts are  we cant by design here, we tried hard and failed, not
> > > technically but by design.
> > >
> > >
> > >
> > > > Originally Mojos were envisioned to be simple, focused, doing one
> thing
> > > and
> > > > doing it well (a la UNIX tools). Some plugins went in the total
> > opposite
> > > > direction, as they became Godzilla plugins (with unmaintainable
> complex
> > > and
> > > > large amounts of "logic" -- guess logic and bloated codebase)
> targeting
> > > to
> > > > solve "everything". This also resulted in our users assuming "every
> > > problem
> > > > should have a corresponding Mojo" (this also steered toward bloated,
> > over
> > > > complex Mojos), where many many other aspects and capabilities of
> Maven
> > > > were totally neglected, like lifecycle, custom packaging and so on.
> > > >
> > > > In short, Romain, yes, today, you CAN build all sort of things in
> > "smart
> > > > way", just like cooking a soup: get a good base (packaging), add a
> > little
> > > > bit of this (mojo A) and a little bit of that (mojo B) and voila, you
> > > will
> > > > end up with a "soup". And it works, yes, but this "smart" way has
> many
> > > > pitfalls along the way, with most problematic of not being explicit.
> > But
> > > by
> > > > doing that, your build becomes Ant-ish (imperative-ish), and you are
> > > > sliding off the declarative path.
> > > >
> > >
> > > For cases needing it and all the mentionned ones are (and will) NOT
> (be)
> > > mainstream.
> > > So all good IMHO.
> > >
> > >
> > > > Also, you ARE aware that if you build a project w/ packaging=module
> > (that
> > > > as output has an artifact with extension jar), you DON'T HAVE TO
> > address
> > > it
> > > > downstream (when you depend on it) as "module", right? This is the
> > actual
> > > > reason why I brought up Takari Lifecycle, as there you are building
> > > > projects with packaging=takari-jar, but when you consume those, you
> > refer
> > > > to them as type=jar, and not as type=takari-jar, right?
> > > >
> > >
> >

Re: Maven 5 pom extension for agents

2023-10-30 Thread Henning Schmiedehausen

I don't understand fatjar and fatmodule. Why would we need that? How would
maven treat this different from a regular jar / module ?

-h



On Sun, Oct 29, 2023 at 8:10 AM Tamás Cservenák  wrote:

> Howdy,
>
> The current draft of types we want to introduce (and  packaging):
> https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
>
> ===
>
> Romain, I don't understand your "This is wrong, downstream is either module
> or jar", as it was actually you and your example that mentioned "once put
> it here, once put it there". Nothing is lost IMHO, just like in case of
> "takari-jar" nothing is lost.
>
> Or if we misunderstood each other: by "downstream" I mean "down the road,
> when a project being built, is about to be consumed as dependency".
>
> And the point is, that exactly due ArtifactHandler/ArtifactType/Type (in
> mvn4), Maven "sees" it as "jar" or "module" or whatever, but for resolver,
> those two are _same thing_. It is _same file_. And this is the crux, as for
> the resolver, it is really about getting that one file, while the type (for
> Maven) tells HOW to make use of it. So for resolving, there is no any kind
> of "lost" information, again, the very same way it works for "takari-jar".
>
> T
>
> On Sun, Oct 29, 2023 at 3:52 PM Romain Manni-Bucau 
> wrote:
>
> > Le dim. 29 oct. 2023 à 15:29, Tamás Cservenák  a
> > écrit :
> >
> > > Howdy,
> > >
> > > So to return to the "root" idea (of Maven), Maven is "declarative",
> where
> > > users should declare what they want, it should most certainly not
> "guess"
> > > what user intent is. As long as we have "magical implicit guesswork"
> > (like
> > > that in javadoc) present in process, it is bad, as that means we do not
> > > allow our users to express their goal.
> > >
> >
> > Yes and i liked that but we broke it with forcing plugin version locking
> > (for good) so we can need to revise our root too to match current world
> > which is no more unique, makes years we ignore that fact but it already
> > blows up.
> >
> > So my 2cts are  we cant by design here, we tried hard and failed, not
> > technically but by design.
> >
> >
> >
> > > Originally Mojos were envisioned to be simple, focused, doing one thing
> > and
> > > doing it well (a la UNIX tools). Some plugins went in the total
> opposite
> > > direction, as they became Godzilla plugins (with unmaintainable complex
> > and
> > > large amounts of "logic" -- guess logic and bloated codebase) targeting
> > to
> > > solve "everything". This also resulted in our users assuming "every
> > problem
> > > should have a corresponding Mojo" (this also steered toward bloated,
> over
> > > complex Mojos), where many many other aspects and capabilities of Maven
> > > were totally neglected, like lifecycle, custom packaging and so on.
> > >
> > > In short, Romain, yes, today, you CAN build all sort of things in
> "smart
> > > way", just like cooking a soup: get a good base (packaging), add a
> little
> > > bit of this (mojo A) and a little bit of that (mojo B) and voila, you
> > will
> > > end up with a "soup". And it works, yes, but this "smart" way has many
> > > pitfalls along the way, with most problematic of not being explicit.
> But
> > by
> > > doing that, your build becomes Ant-ish (imperative-ish), and you are
> > > sliding off the declarative path.
> > >
> >
> > For cases needing it and all the mentionned ones are (and will) NOT (be)
> > mainstream.
> > So all good IMHO.
> >
> >
> > > Also, you ARE aware that if you build a project w/ packaging=module
> (that
> > > as output has an artifact with extension jar), you DON'T HAVE TO
> address
> > it
> > > downstream (when you depend on it) as "module", right? This is the
> actual
> > > reason why I brought up Takari Lifecycle, as there you are building
> > > projects with packaging=takari-jar, but when you consume those, you
> refer
> > > to them as type=jar, and not as type=takari-jar, right?
> > >
> >
> > This is wrong, downstream is either module or jar, here you loose if it
> is
> > a module transitively and module assume all transitive deps are which is
> > very often wrong so it does not work downstream.
> >
> >
> > > So, I have a feeling that you bring bold conclusions (like "Your
> solution
> > > is valid technically but does not solve the original issue"), you do
> not
> > > really understand what I am trying to say here.
> > >
> >
> > Hooe you are true but trust me i went where you are and my conclusion is
> it
> > cant be done right for enough projects to be worth it.
> >
> >
> > > Also, "this" certainly does NOT "work well today" (even in this thread
> > poor
> > > tooling mentioned), but true, you can hack-around it, or alike, but
> none
> > of
> > > current solutions are explicit, declarative and naturally expressed in
> > > Maven (but are bolted on).
> > >
> > > Finally, having anything "on top" of resolver is not gonna help
> anything,
> > > as Resolver is really about Artifacts only (Everything is an Artifact!)
> > and
> > > it i

Re: Maven 5 pom extension for agents

2023-10-30 Thread Henning Schmiedehausen

If the current standard type would be "dependency", this would work IMHO.
It is not. It is "jar". This is perceived as "packaging", not a specific
semantic type that represents "dependency").

A bom is "type == pom, scope == import" which is a special case. If this
were "type == bom, scope == import" and maps onto "pom file" (extension ==
pom), this would make sense. It does not.

In the same vein, the type == "test-jar" should not be that. It should be
"tests" (because test-jar implies the packaging already). And it is unclear
to me what we should do if a type is given (e.g. "jar" which implies
dependency) but then a classifier ("tests"). All the semantics here are
muddled up.

All the "type / classifier" -> "extension" translation is ad hoc, there are
no defined rules anywhere. I think we could create this (for maven 4? maven
5?) but we can not retcon this for Maven 3 where type is a mixture between
"purpose" (dependency) and "packaging" (jar).

A dependency IMHO consists of

* gav -> coordinates of the artifact
* scope -> scope in which the artifact is valid

* "packaging" -> defines how the artifact is packaged if it is possible to
have multiple styles. At the minimum, we need to support "jar" and "file".
The default packaging may be controlled by the type but can be overridden.
I don't like "extension" because it implies that the collection of bytes on
disk has a specific name.

* "type" -> semantic type of the artifact. Default should be "dependency"

* "variant" to select a specific variant of an artifact. E.g. "x86_64" or
"arm64" for native artifacts.

"classifier" I think is the main problem.  Today it serves double-duty as
"variant" but also affects the final name of the file on disk.  Changing
the classifier actually affects the type, which it should not. But on the
other hand, setting the type should affect the final name on disk as well.
(e.g. type == "test-jar" would turn the name into
"artifact-version-tests.packaging-specific-extension"

It would be nice to fix all of this, but then again, what we have today is
so deeply entrenched in 20+ years of maven ecosystem, that I am not sure
that it can be done without breaking compatibility.

-h

On Sat, Oct 28, 2023 at 3:27 PM Tamás Cservenák  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 
> 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  element inside ? 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  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
> >>
> >>
>

Re: Maven 5 pom extension for agents

2023-10-30 Thread Romain Manni-Bucau

the thing is modules are one example but you also have several plugin
related dependencies (living doc one is a common example I hit and I
workaround with provided or test but this is wrong, another one can be a
generator plugin, but most common ones are assembler plugins where sets
enable to toggle features  etc...).

It would be neat for example to use in jib sets = layers just by references
and link it to the compiler plugin saying compileDeps=dep1+dep2+set1+set2
to give a concrete example.

Indeed we would end up with convention (compiler depset is used by default,
module depset is used for modulepath, patch is used for patch-module for ex
etc).
But the mecanism is to think about set of dependencies and
compose/reference that instead of being rigid with ~one (two with tests).

Indeed you can argue that plugins can take a few  blocks and
do it themselves, this is true and I would agree if the conclusion is the
same for the modules, ie put the conf in compiler, javadoc, ... plugins.

If not it just means we need reusable dependencies set we can compose in
plugins.

It would inherit from the dependency global management (not speaking of the
block, more the technical parts) and avoids the interproject issues.

I'm not really sure if we have another option until we do something really
ad-hoc for modules which means we don't solve the issue and will need
something specific for everything.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book

Le lun. 30 oct. 2023 à 21:15, Henning Schmiedehausen <
henn...@schmiedehausen.org> a écrit :

> Modules are just regular dependencies that need to end up on the module
> path instead of the classpath. Creating a new section in the pom (with all
> its pains, because it would not just be "modules" but also
> "moduleManagement", akin to "dependencyManagement") is IMHO a really bad
> idea. Also, "module" is already taken. ;-)
>
> -h
>
>
>
> On Sat, Oct 28, 2023 at 1:55 PM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > I still see these just as new dependency types: "module", "agent",
> > "doclet", and so on.
> >
> > Also, for "other end" (producing) we'd need new packaging as well:
> "module"
> > at least for example.
> >
> > ArtifactHandler would need to be extended as well, or better, complete
> > adopt Resolver ArtifactType instead (of limited Maven ArtifactHandler):
> >
> >
> https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/artifact/ArtifactType.java
> >
> > And plugins should just do what given Artifact's ArtifactType says, no
> > more, no less.
> > No heuristic, no "guesswork", or anything like that, just keep the simple
> > stupid.
> >
> > Thanks
> > T
> >
> >
> > On Tue, Oct 24, 2023 at 7:42 AM Thomas Reinhardt 
> > wrote:
> >
> > >
> > > On 20/10/2023 20:43, Romain Manni-Bucau wrote:
> > > > Can be the way to define the lookup, an heuristic will never work by
> > > > design...that said, on my side, not sure JPMS will be widely adopted
> > > > anytime soon so can be a false problem.
> > > This is a chicken and egg problem. My company would love to use JPMS
> > > more. But right now it is basically unusable for us and part of it is
> > > lacking maven support. The next big maven release should definitely
> > > improve the support. One big problem is testing (and all the
> > > implications with different classpaths etc) but that deserves its own
> > > discussion I think.
> > >
> > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > > >
> > > >
> > > > Le ven. 20 oct. 2023 à 20:24, Henning Schmiedehausen <
> > > > henn...@schmiedehausen.org> a écrit :
> > > >
> > > >> I think we will need to start rethinking dependencies more. A
> similar
> > > >> problem exists with modules; the current heuristics to decide
> whether
> > a
> > > >> dependency goes on module path or classpath will start to become
> > > painful in
> > > >> the very near future.
> > > >>
> > > >> -h
> > > >>
> > > >>
> > > >> On Tue, Oct 17, 2023 at 10:05 PM Benjamin Marwell <
> > bmarw...@apache.org>
> > > >> wrote:
> > > >>
> > > >>> If you can still use it twice, works for me, too.
> > > >>>
> > > >>> Either way, you'd need it both as a dependency and as an agent.
> > > >>>
> > > >>> Another requirement Romain mentioned is the order of agent loading.
> > > >> Mockito
> > > >>> wants to be first, and ot

Re: Maven 5 pom extension for agents

2023-10-30 Thread Henning Schmiedehausen

Modules are just regular dependencies that need to end up on the module
path instead of the classpath. Creating a new section in the pom (with all
its pains, because it would not just be "modules" but also
"moduleManagement", akin to "dependencyManagement") is IMHO a really bad
idea. Also, "module" is already taken. ;-)

-h



On Sat, Oct 28, 2023 at 1:55 PM Tamás Cservenák  wrote:

> Howdy,
>
> I still see these just as new dependency types: "module", "agent",
> "doclet", and so on.
>
> Also, for "other end" (producing) we'd need new packaging as well: "module"
> at least for example.
>
> ArtifactHandler would need to be extended as well, or better, complete
> adopt Resolver ArtifactType instead (of limited Maven ArtifactHandler):
>
> https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/artifact/ArtifactType.java
>
> And plugins should just do what given Artifact's ArtifactType says, no
> more, no less.
> No heuristic, no "guesswork", or anything like that, just keep the simple
> stupid.
>
> Thanks
> T
>
>
> On Tue, Oct 24, 2023 at 7:42 AM Thomas Reinhardt 
> wrote:
>
> >
> > On 20/10/2023 20:43, Romain Manni-Bucau wrote:
> > > Can be the way to define the lookup, an heuristic will never work by
> > > design...that said, on my side, not sure JPMS will be widely adopted
> > > anytime soon so can be a false problem.
> > This is a chicken and egg problem. My company would love to use JPMS
> > more. But right now it is basically unusable for us and part of it is
> > lacking maven support. The next big maven release should definitely
> > improve the support. One big problem is testing (and all the
> > implications with different classpaths etc) but that deserves its own
> > discussion I think.
> >
> >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le ven. 20 oct. 2023 à 20:24, Henning Schmiedehausen <
> > > henn...@schmiedehausen.org> a écrit :
> > >
> > >> I think we will need to start rethinking dependencies more. A similar
> > >> problem exists with modules; the current heuristics to decide whether
> a
> > >> dependency goes on module path or classpath will start to become
> > painful in
> > >> the very near future.
> > >>
> > >> -h
> > >>
> > >>
> > >> On Tue, Oct 17, 2023 at 10:05 PM Benjamin Marwell <
> bmarw...@apache.org>
> > >> wrote:
> > >>
> > >>> If you can still use it twice, works for me, too.
> > >>>
> > >>> Either way, you'd need it both as a dependency and as an agent.
> > >>>
> > >>> Another requirement Romain mentioned is the order of agent loading.
> > >> Mockito
> > >>> wants to be first, and others can come later.
> > >>>
> > >>> - Ben
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Wed, 18 Oct 2023, 00:11 Tamás Cservenák, 
> > wrote:
> > >>>
> >  What about type=java-agent? Basically a new ArtifactHandler?
> > 
> >  See https://maven.apache.org/repositories/artifacts.html
> > 
> >  T
> > 
> >  On Tue, Oct 17, 2023, 23:54 Benjamin Marwell 
> > >>> wrote:
> > 
> > > Hey all,
> > >
> > > In a mockito issue, JDK maintainers suggested to differentiate
> > >> between
> > > agents and normal dependencies. Starting with JDK 21 already, this
> > >>> makes
> >  a
> > > lot of sense: dynamic loading of agents will be a no-go.
> > >
> > > One suggestion was:
> > >
> > > 
> > >  
> > >  ...
> > >  
> > >  
> > >  
> > >  ...
> > >  
> > >  
> > > 
> > >
> > > Not sure if this is the best way, but this is something similar
> might
> > >>> be
> > > needed.
> > > Currently, the only way to handle agents is to add them manually to
> > >> the
> > > surefire argLine. To make things worse, a deoendency goal is needed
> > >>> until
> > > Romains PR is merged:
> > > https://github.com/apache/maven/pull/1281
> > >
> > > Another issue is that a parent pom might not be able to easily
> define
> >  this
> > > option. There were some concerns that part of the configuration
> > >> needed
> > >>> to
> > > be repeated in every module.
> > >
> > > So, I wrote Maven 5.
> > > Maven 4 is the stepping stone to the build/consumer pom. But this
> is
> > >> an
> > > extension. Not really a breaking change in terms of parsing, but in
> > >>> terms
> > > of building a project. Thus, it should go onto the roadmap.
> > >
> > > ... unless you want to keep the current status quo, which is also
> an
> > > option. But before making an argument here, I'd recommend reading
> the
> > > l

Re: Maven 5 pom extension for agents

Le dim. 29 oct. 2023 à 21:32, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2023-10-29 à 21 h 25, Romain Manni-Bucau a écrit :
>
> > Then you are back to the dependency set solution which is not the type
> > solution and in this option the type is fully useless.
> >
> Maybe we would need a wiki page explaining how the DependencySet
> approach would apply to JPMS. At this time, the relationship to the
> --add-exports option is obscure to me.
>

Was referencing the options using module names, if you drop the dep or
reference a package not supported by the module we should be able to fail.
But you are right it belongs to the shared part of maven handling jvm
options (likely the same handling the dependency resolution for the
parameters from the dependency set reference I spoke about for ex).


>
>
> >> Why would we need to declare all transitive dependencies? The
> >> module element in the pom.xml of each dependency would
> >> apply.
> >>
> > Cause your transitive deps are then jars, not modules (that said the
> > opposite is wrong too for most libs)
> >
> When Maven downloads a JAR file, it also downloads its POM file. In my
> understanding this is how Maven get information about transitive
> dependencies. It seems to me that Maven gets type information of
> transitive dependencies that way too, isn't it?
>

It downloads pom in version 4.0.0 without the guarantee of the handing of
this meta, we can make it downloading more recent pom with the new meta but
no guarantee in the future so you kind of lock your maven version with the
pom (from experience it is not good for dev to restrict it too much even if
I know some people like to lock it).


>
>  Martin
>
>

Re: Maven 5 pom extension for agents


Le 2023-10-29 à 21 h 25, Romain Manni-Bucau a écrit :

Then you are back to the dependency set solution which is not the type 
solution and in this option the type is fully useless.


Maybe we would need a wiki page explaining how the DependencySet 
approach would apply to JPMS. At this time, the relationship to the 
--add-exports option is obscure to me.



Why would we need to declare all transitive dependencies? The 
module element in the pom.xml of each dependency would 
apply.


Cause your transitive deps are then jars, not modules (that said the 
opposite is wrong too for most libs)


When Maven downloads a JAR file, it also downloads its POM file. In my 
understanding this is how Maven get information about transitive 
dependencies. It seems to me that Maven gets type information of 
transitive dependencies that way too, isn't it?


    Martin

Re: Maven 5 pom extension for agents

Le dim. 29 oct. 2023 à 21:21, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2023-10-29 à 20 h 58, Romain Manni-Bucau a écrit :
> >
> > Is it really different since part of options are related so either we
> > align on the jvm making using maven location mapping easier or we
> > fully integrate but means we must detect errors in options which is
> > for me a hard task
> >
> Why do we need to detect errors in options, isn't the Java error message
> sufficient? The Java error messages are already quite informative
> regarding those options (after we learned the philosophy).
>

Well not really, some libraires complain about it. After it depends which
cases but several can be cryptic after some refactoring.


>
> Those options indeed apply only for module. But the way I
> envision that would be a separated block in  for saying "if
> this dependency is added on the module-path, then add those
> --add-exports options". It would be used mostly for the JUnit or TestNG
> dependency. In this proposal, this element would be independent to
> , except that it would be ignored (or raise an error) if the type
> is JAR.
>

Then you are back to the dependency set solution which is not the type
solution and in this option the type is fully useless.


>
>
> > side note: please think about transitivity, here with the proposal you
> > must define *all* your transitive deps in your consumer pom.
> > Completely changes the maven philosophy.
> >
> Why would we need to declare all transitive dependencies? The
> module element in the pom.xml of each dependency would apply.
>

Cause your transitive deps are then jars, not modules (that said the
opposite is wrong too for most libs)


>
>  Martin
>
>

Re: Maven 5 pom extension for agents


Le 2023-10-29 à 20 h 58, Romain Manni-Bucau a écrit :


Is it really different since part of options are related so either we 
align on the jvm making using maven location mapping easier or we 
fully integrate but means we must detect errors in options which is 
for me a hard task


Why do we need to detect errors in options, isn't the Java error message 
sufficient? The Java error messages are already quite informative 
regarding those options (after we learned the philosophy).


Those options indeed apply only for module. But the way I 
envision that would be a separated block in  for saying "if 
this dependency is added on the module-path, then add those 
--add-exports options". It would be used mostly for the JUnit or TestNG 
dependency. In this proposal, this element would be independent to 
, except that it would be ignored (or raise an error) if the type 
is JAR.



side note: please think about transitivity, here with the proposal you 
must define *all* your transitive deps in your consumer pom. 
Completely changes the maven philosophy.


Why would we need to declare all transitive dependencies? The 
module element in the pom.xml of each dependency would apply.


    Martin

Re: Maven 5 pom extension for agents

Le dim. 29 oct. 2023 à 21:11, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2023-10-29 à 18 h 05, Romain Manni-Bucau a écrit :
> >
> > *type* is not a good solution for jpms, only dependency can help
> >
> Since we are talking about specifying the type of dependencies, I do not
> understand well what would not work exactly?
>

Previous examples show that:

1. type depends the context (=plugin, even in a single module)
2. lack of transitiveness support (keep in mind module will be lost most of
the time as of today and there is no guarantee if we dont loose it that
maven will support it later, ie it is lost for consumers)


>
> One thing that we may need is a way for a dependency to said "unless the
> user specifies otherwise in the  element, put me by default on the
> module-path". Is it related to the objection?
>

This is ok but actually iso with what we have today "put it on classpath
until requested otherwise".


>
>
> > But once again, how much project would we cover, in years EE and
> > Spring didnt embrace jpms and even if some minor integration can be
> > hoped it will not become mainsteam anytime soon (...snip...)
> >
> Not all applications depend on Spring or EE. For non-Spring
> applications, as said previously in this thread, this is a
> chicken-and-egg issue. There are companies that would love to use JPMS
> (e.g. for reducing the "classpath hell" issue) but are blocked by
> limitations of tools. Another argument is that JPMS improves security by
> providing stronger encapsulation (only exported packages can be used,
> and reflection is constrained). Security is a hot topic for governments
> in those time, maybe we should not neglect features that can help us.
> No-one is forced to use JPMS, but for those who want, it should not be
> as hard as it is today. My expectation is that once JPMS become well
> supported by tools like Maven, we will see a great increase in its usage.
>

I understand and I saw the chicken egg point but I don't think it is.

As a matter of fact it does work today and very few people are embracing
jpms (more than naming for downstream consumers), using ir or even willing
to use it.
Maven is all about conventions so mainstream and mainstream is not and will
probably never be JPMS (keep in mind it was designed for the jdk very few
for end users, which also explains why very few major frameworks integrated
it).

So yes, we want to support it and the good news is we do.

It is more than fine to do an extension on github which helps but the type
solution does not work well from what I tested some years ago as soon as
you have more than one project or build project modules separately (not
using the root reactor).


>
>  Martin
>
>

Re: Maven 5 pom extension for agents


Le 2023-10-29 à 18 h 05, Romain Manni-Bucau a écrit :


*type* is not a good solution for jpms, only dependency can help

Since we are talking about specifying the type of dependencies, I do not 
understand well what would not work exactly?


One thing that we may need is a way for a dependency to said "unless the 
user specifies otherwise in the  element, put me by default on the 
module-path". Is it related to the objection?



But once again, how much project would we cover, in years EE and 
Spring didnt embrace jpms and even if some minor integration can be 
hoped it will not become mainsteam anytime soon (...snip...)


Not all applications depend on Spring or EE. For non-Spring 
applications, as said previously in this thread, this is a 
chicken-and-egg issue. There are companies that would love to use JPMS 
(e.g. for reducing the "classpath hell" issue) but are blocked by 
limitations of tools. Another argument is that JPMS improves security by 
providing stronger encapsulation (only exported packages can be used, 
and reflection is constrained). Security is a hot topic for governments 
in those time, maybe we should not neglect features that can help us. 
No-one is forced to use JPMS, but for those who want, it should not be 
as hard as it is today. My expectation is that once JPMS become well 
supported by tools like Maven, we will see a great increase in its usage.


    Martin

Re: Maven 5 pom extension for agents

Le dim. 29 oct. 2023 à 20:49, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2023-10-29 à 16 h 10, Tamás Cservenák a écrit :
>
> > The current draft of types we want to introduce (and packaging):
> > https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
> >
> Thanks! I fully support this proposal, as I believe it can resolve the
> most blocking issue in using JPMS with Maven.
>
> This is not the only issue, we would also need some support for
> --add-reads, --add-exports and --add-opens options. But maybe we can
> discuss that on a separated wiki page. The most important issue is
> control on class-path versus module-path, and above proposal seems to
> address it well. Thanks again!
>

Is it really different since part of options are related so either we align
on the jvm making using maven location mapping easier or we fully integrate
but means we must detect errors in options which is for me a hard task (=
gain will be low).
So don't think it is a different thread, it is the same for me.

side note: please think about transitivity, here with the proposal you must
define *all* your transitive deps in your consumer pom.
Completely changes the maven philosophy.


>
>  Martin
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven 5 pom extension for agents


Le 2023-10-29 à 16 h 54, Tamás Cservenák a écrit :


History shows that having lengthy ML discussions usually dies off into 
silence. I think we could use Google Meet, where the 60min limit is 
actually even welcome, to not get into marathon meetings and stay 
focused (or continue on the next session).


If such meetings are organized, you can count me it at least for the 
JPMS part.


    Martin

Re: Maven 5 pom extension for agents


Le 2023-10-29 à 16 h 10, Tamás Cservenák a écrit :

The current draft of types we want to introduce (and packaging): 
https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8


Thanks! I fully support this proposal, as I believe it can resolve the 
most blocking issue in using JPMS with Maven.


This is not the only issue, we would also need some support for 
--add-reads, --add-exports and --add-opens options. But maybe we can 
discuss that on a separated wiki page. The most important issue is 
control on class-path versus module-path, and above proposal seems to 
address it well. Thanks again!


    Martin



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 5 pom extension for agents


Le 2023-10-29 à 00 h 21, Tamás Cservenák a écrit :


Unsure from where you get that, but is wrong conclusion.

Declaring a dependency with test-jar causes Maven to 
download a different JAR file. So I assumed that it was a general 
behaviour. However looking at the link you provided [1], it seems to be 
because this particular type causes the addition of an implicit 
tests. Thanks for correcting me.


So it seems that the  element proposal could be retrofitted in 
, as you suggest.


    Martin

[1]https://maven.apache.org/repositories/artifacts.html#but-where-do-i-set-artifact-extension

Re: Maven 5 pom extension for agents

Le dim. 29 oct. 2023 à 16:10, Tamás Cservenák  a
écrit :

> Howdy,
>
> The current draft of types we want to introduce (and  packaging):
> https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
>
> ===
>
> Romain, I don't understand your "This is wrong, downstream is either module
> or jar", as it was actually you and your example that mentioned "once put
> it here, once put it there". Nothing is lost IMHO, just like in case of
> "takari-jar" nothing is lost.
>

Yes and no, issue is jpms is transitive as jar type is in your design (it
must be for your design to help otherwise the first jpms dep (module) will
be treated as a plain jar which is not the intent, the good thing is that
if it is treated as a module, it will also not be the intent most of the
time...so it can only be explicit by design except for final apps (leaves
projects) which is very few in practise).

>
> Or if we misunderstood each other: by "downstream" I mean "down the road,
> when a project being built, is about to be consumed as dependency".
>
> And the point is, that exactly due ArtifactHandler/ArtifactType/Type (in
> mvn4), Maven "sees" it as "jar" or "module" or whatever, but for resolver,
> those two are _same thing_. It is _same file_. And this is the crux, as for
> the resolver, it is really about getting that one file, while the type (for
> Maven) tells HOW to make use of it. So for resolving, there is no any kind
> of "lost" information, again, the very same way it works for "takari-jar".
>

Type is a thing, the way the type is handled in a build is part of the
issue but jpms is transitive (think jlink, it is all or nothing but in most
build modules are just set in the classpath).
*type* is not a good solution for jpms, only dependency can help (this is
doable in an extension quite easily).

But once again, how much project would we cover, in years EE and Spring
didnt embrace jpms and even if some minor integration can be hoped it will
not become mainsteam anytime soon so do we work on something with value for
users or for a few users which would fall in the exception part of our
convention over config.

Ultimately all the issues come from the intent from maven to be too clever
in plugins, if you become explicit, a bit like exec plugin supports
, we could support a filter by groupId for
ex or patterns... then you have no more issue and can customize both
command as java expects without trying to be more clever than you can by
design.

For java related plugin I think we should rather enable java with easiness
rather than trying to hide java which always lead to issues and generally
fail, see how recent version support became, --add-open, --add-modules etc
are all explicit, all the mess we did didn't prevent it and often blocked
user (jpms).

So my point is fix plugin config, not invent a new concept which covers 10%
of the need.

>
> T
>
> On Sun, Oct 29, 2023 at 3:52 PM Romain Manni-Bucau 
> wrote:
>
> > Le dim. 29 oct. 2023 à 15:29, Tamás Cservenák  a
> > écrit :
> >
> > > Howdy,
> > >
> > > So to return to the "root" idea (of Maven), Maven is "declarative",
> where
> > > users should declare what they want, it should most certainly not
> "guess"
> > > what user intent is. As long as we have "magical implicit guesswork"
> > (like
> > > that in javadoc) present in process, it is bad, as that means we do not
> > > allow our users to express their goal.
> > >
> >
> > Yes and i liked that but we broke it with forcing plugin version locking
> > (for good) so we can need to revise our root too to match current world
> > which is no more unique, makes years we ignore that fact but it already
> > blows up.
> >
> > So my 2cts are  we cant by design here, we tried hard and failed, not
> > technically but by design.
> >
> >
> >
> > > Originally Mojos were envisioned to be simple, focused, doing one thing
> > and
> > > doing it well (a la UNIX tools). Some plugins went in the total
> opposite
> > > direction, as they became Godzilla plugins (with unmaintainable complex
> > and
> > > large amounts of "logic" -- guess logic and bloated codebase) targeting
> > to
> > > solve "everything". This also resulted in our users assuming "every
> > problem
> > > should have a corresponding Mojo" (this also steered toward bloated,
> over
> > > complex Mojos), where many many other aspects and capabilities of Maven
> > > were totally neglected, like lifecycle, custom packaging and so on.
> > >
> > > In short, Romain, yes, today, you CAN build all sort of things in
> "smart
> > > way", just like cooking a soup: get a good base (packaging), add a
> little
> > > bit of this (mojo A) and a little bit of that (mojo B) and voila, you
> > will
> > > end up with a "soup". And it works, yes, but this "smart" way has many
> > > pitfalls along the way, with most problematic of not being explicit.
> But
> > by
> > > doing that, your build becomes Ant-ish (imperative-ish), and you are
> > > sliding off the declarative path.
> > >
> >
> > For cases n

Re: Maven 5 pom extension for agents

...and one more thing:
Sorry for bombing this thread, and I see we have clear counter-points for
each other, so here is a proposal: long time ago there was an institution
of "Maven Hangouts", where regular (or irregular) face2face meetings were
held between not only Maven devs, but any interested parties (to hear about
latest Maven developments). So, let's revive this custom, and for the first
session let me prepare a demo of my idea, show it, and Romain and others
can see what I mean, but also can ask or show counter examples and so on.
If something crops out that needs more time, we can continue on to the next
session, and so on...  Of course, if anyone is willing to show how "jpms
dev is done today" is welcome as well!

History shows that having lengthy ML discussions usually dies off into
silence.

I think we could use Google Meet, where the 60min limit is actually even
welcome, to not get into marathon meetings and stay focused (or continue on
the next session).

WDYT?



On Sun, Oct 29, 2023 at 4:31 PM Tamás Cservenák  wrote:

> ===
>
> Digression: I _think_ we have a misconception present, so excuse me for
> this digression, but I have to write it down here, just to make things
> clear.
> Is basically represented by this issue
> https://issues.apache.org/jira/browse/MNG-7373
>
> tl;dr: It is common misconception, that Maven works like this:
> - in POM you declare dependencies
> - Maven, when invoked, resolves them by getting the POM
> - with POM, it reads the packaging out of it, and "decides" what to do
> more (ie. get the JAR)
>
> This is NOT how Maven works nor has ever worked like it.
>
> For Maven what matters is how you DECLARE your dependency, that is the
> instruction it follows. The remote POM may even have packaging=kangaroo, it
> will NOT bother with it. All that matters is how you declare the kangaroo
> packaged artifact, if you do it as type=jar, it will go for JAR.
>
> (Reason is trivial: you can produce JAR artifacts in a million ways, using
> packaging "jar" that is built into Maven core, but also using "takari-jar",
> or "bundle", or some in-house packaging "super-jar" or "my-super-duper-jar"
> or whatever. Naturally, to consume these types, Maven would need to know
> about these types, hence, it would need extensions for it to be installed.
> In short: to make Maven work like in common misconception imagined, it
> would need to have ALL the extensions for ALL the packaging types out
> there, that produce files with extension "jar").
>
> In short packaging != type.
>
> On Sun, Oct 29, 2023 at 4:10 PM Tamás Cservenák 
> wrote:
>
>> Howdy,
>>
>> The current draft of types we want to introduce (and  packaging):
>> https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
>>
>> ===
>>
>> Romain, I don't understand your "This is wrong, downstream is either
>> module or jar", as it was actually you and your example that mentioned
>> "once put it here, once put it there". Nothing is lost IMHO, just like in
>> case of "takari-jar" nothing is lost.
>>
>> Or if we misunderstood each other: by "downstream" I mean "down the road,
>> when a project being built, is about to be consumed as dependency".
>>
>> And the point is, that exactly due ArtifactHandler/ArtifactType/Type (in
>> mvn4), Maven "sees" it as "jar" or "module" or whatever, but for resolver,
>> those two are _same thing_. It is _same file_. And this is the crux, as for
>> the resolver, it is really about getting that one file, while the type (for
>> Maven) tells HOW to make use of it. So for resolving, there is no any kind
>> of "lost" information, again, the very same way it works for "takari-jar".
>>
>> T
>>
>> On Sun, Oct 29, 2023 at 3:52 PM Romain Manni-Bucau 
>> wrote:
>>
>>> Le dim. 29 oct. 2023 à 15:29, Tamás Cservenák  a
>>> écrit :
>>>
>>> > Howdy,
>>> >
>>> > So to return to the "root" idea (of Maven), Maven is "declarative",
>>> where
>>> > users should declare what they want, it should most certainly not
>>> "guess"
>>> > what user intent is. As long as we have "magical implicit guesswork"
>>> (like
>>> > that in javadoc) present in process, it is bad, as that means we do not
>>> > allow our users to express their goal.
>>> >
>>>
>>> Yes and i liked that but we broke it with forcing plugin version locking
>>> (for good) so we can need to revise our root too to match current world
>>> which is no more unique, makes years we ignore that fact but it already
>>> blows up.
>>>
>>> So my 2cts are  we cant by design here, we tried hard and failed, not
>>> technically but by design.
>>>
>>>
>>>
>>> > Originally Mojos were envisioned to be simple, focused, doing one
>>> thing and
>>> > doing it well (a la UNIX tools). Some plugins went in the total
>>> opposite
>>> > direction, as they became Godzilla plugins (with unmaintainable
>>> complex and
>>> > large amounts of "logic" -- guess logic and bloated codebase)
>>> targeting to
>>> > solve "everything". This also resulted in our users assuming "every
>>> problem
>>> > sho

Re: Maven 5 pom extension for agents

===

Digression: I _think_ we have a misconception present, so excuse me for
this digression, but I have to write it down here, just to make things
clear.
Is basically represented by this issue
https://issues.apache.org/jira/browse/MNG-7373

tl;dr: It is common misconception, that Maven works like this:
- in POM you declare dependencies
- Maven, when invoked, resolves them by getting the POM
- with POM, it reads the packaging out of it, and "decides" what to do more
(ie. get the JAR)

This is NOT how Maven works nor has ever worked like it.

For Maven what matters is how you DECLARE your dependency, that is the
instruction it follows. The remote POM may even have packaging=kangaroo, it
will NOT bother with it. All that matters is how you declare the kangaroo
packaged artifact, if you do it as type=jar, it will go for JAR.

(Reason is trivial: you can produce JAR artifacts in a million ways, using
packaging "jar" that is built into Maven core, but also using "takari-jar",
or "bundle", or some in-house packaging "super-jar" or "my-super-duper-jar"
or whatever. Naturally, to consume these types, Maven would need to know
about these types, hence, it would need extensions for it to be installed.
In short: to make Maven work like in common misconception imagined, it
would need to have ALL the extensions for ALL the packaging types out
there, that produce files with extension "jar").

In short packaging != type.

On Sun, Oct 29, 2023 at 4:10 PM Tamás Cservenák  wrote:

> Howdy,
>
> The current draft of types we want to introduce (and  packaging):
> https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
>
> ===
>
> Romain, I don't understand your "This is wrong, downstream is either
> module or jar", as it was actually you and your example that mentioned
> "once put it here, once put it there". Nothing is lost IMHO, just like in
> case of "takari-jar" nothing is lost.
>
> Or if we misunderstood each other: by "downstream" I mean "down the road,
> when a project being built, is about to be consumed as dependency".
>
> And the point is, that exactly due ArtifactHandler/ArtifactType/Type (in
> mvn4), Maven "sees" it as "jar" or "module" or whatever, but for resolver,
> those two are _same thing_. It is _same file_. And this is the crux, as for
> the resolver, it is really about getting that one file, while the type (for
> Maven) tells HOW to make use of it. So for resolving, there is no any kind
> of "lost" information, again, the very same way it works for "takari-jar".
>
> T
>
> On Sun, Oct 29, 2023 at 3:52 PM Romain Manni-Bucau 
> wrote:
>
>> Le dim. 29 oct. 2023 à 15:29, Tamás Cservenák  a
>> écrit :
>>
>> > Howdy,
>> >
>> > So to return to the "root" idea (of Maven), Maven is "declarative",
>> where
>> > users should declare what they want, it should most certainly not
>> "guess"
>> > what user intent is. As long as we have "magical implicit guesswork"
>> (like
>> > that in javadoc) present in process, it is bad, as that means we do not
>> > allow our users to express their goal.
>> >
>>
>> Yes and i liked that but we broke it with forcing plugin version locking
>> (for good) so we can need to revise our root too to match current world
>> which is no more unique, makes years we ignore that fact but it already
>> blows up.
>>
>> So my 2cts are  we cant by design here, we tried hard and failed, not
>> technically but by design.
>>
>>
>>
>> > Originally Mojos were envisioned to be simple, focused, doing one thing
>> and
>> > doing it well (a la UNIX tools). Some plugins went in the total opposite
>> > direction, as they became Godzilla plugins (with unmaintainable complex
>> and
>> > large amounts of "logic" -- guess logic and bloated codebase) targeting
>> to
>> > solve "everything". This also resulted in our users assuming "every
>> problem
>> > should have a corresponding Mojo" (this also steered toward bloated,
>> over
>> > complex Mojos), where many many other aspects and capabilities of Maven
>> > were totally neglected, like lifecycle, custom packaging and so on.
>> >
>> > In short, Romain, yes, today, you CAN build all sort of things in "smart
>> > way", just like cooking a soup: get a good base (packaging), add a
>> little
>> > bit of this (mojo A) and a little bit of that (mojo B) and voila, you
>> will
>> > end up with a "soup". And it works, yes, but this "smart" way has many
>> > pitfalls along the way, with most problematic of not being explicit.
>> But by
>> > doing that, your build becomes Ant-ish (imperative-ish), and you are
>> > sliding off the declarative path.
>> >
>>
>> For cases needing it and all the mentionned ones are (and will) NOT (be)
>> mainstream.
>> So all good IMHO.
>>
>>
>> > Also, you ARE aware that if you build a project w/ packaging=module
>> (that
>> > as output has an artifact with extension jar), you DON'T HAVE TO
>> address it
>> > downstream (when you depend on it) as "module", right? This is the
>> actual
>> > reason why I brought up Takari Lifecycle, as there yo

Re: Maven 5 pom extension for agents

Howdy,

The current draft of types we want to introduce (and  packaging):
https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8

===

Romain, I don't understand your "This is wrong, downstream is either module
or jar", as it was actually you and your example that mentioned "once put
it here, once put it there". Nothing is lost IMHO, just like in case of
"takari-jar" nothing is lost.

Or if we misunderstood each other: by "downstream" I mean "down the road,
when a project being built, is about to be consumed as dependency".

And the point is, that exactly due ArtifactHandler/ArtifactType/Type (in
mvn4), Maven "sees" it as "jar" or "module" or whatever, but for resolver,
those two are _same thing_. It is _same file_. And this is the crux, as for
the resolver, it is really about getting that one file, while the type (for
Maven) tells HOW to make use of it. So for resolving, there is no any kind
of "lost" information, again, the very same way it works for "takari-jar".

T

On Sun, Oct 29, 2023 at 3:52 PM Romain Manni-Bucau 
wrote:

> Le dim. 29 oct. 2023 à 15:29, Tamás Cservenák  a
> écrit :
>
> > Howdy,
> >
> > So to return to the "root" idea (of Maven), Maven is "declarative", where
> > users should declare what they want, it should most certainly not "guess"
> > what user intent is. As long as we have "magical implicit guesswork"
> (like
> > that in javadoc) present in process, it is bad, as that means we do not
> > allow our users to express their goal.
> >
>
> Yes and i liked that but we broke it with forcing plugin version locking
> (for good) so we can need to revise our root too to match current world
> which is no more unique, makes years we ignore that fact but it already
> blows up.
>
> So my 2cts are  we cant by design here, we tried hard and failed, not
> technically but by design.
>
>
>
> > Originally Mojos were envisioned to be simple, focused, doing one thing
> and
> > doing it well (a la UNIX tools). Some plugins went in the total opposite
> > direction, as they became Godzilla plugins (with unmaintainable complex
> and
> > large amounts of "logic" -- guess logic and bloated codebase) targeting
> to
> > solve "everything". This also resulted in our users assuming "every
> problem
> > should have a corresponding Mojo" (this also steered toward bloated, over
> > complex Mojos), where many many other aspects and capabilities of Maven
> > were totally neglected, like lifecycle, custom packaging and so on.
> >
> > In short, Romain, yes, today, you CAN build all sort of things in "smart
> > way", just like cooking a soup: get a good base (packaging), add a little
> > bit of this (mojo A) and a little bit of that (mojo B) and voila, you
> will
> > end up with a "soup". And it works, yes, but this "smart" way has many
> > pitfalls along the way, with most problematic of not being explicit. But
> by
> > doing that, your build becomes Ant-ish (imperative-ish), and you are
> > sliding off the declarative path.
> >
>
> For cases needing it and all the mentionned ones are (and will) NOT (be)
> mainstream.
> So all good IMHO.
>
>
> > Also, you ARE aware that if you build a project w/ packaging=module (that
> > as output has an artifact with extension jar), you DON'T HAVE TO address
> it
> > downstream (when you depend on it) as "module", right? This is the actual
> > reason why I brought up Takari Lifecycle, as there you are building
> > projects with packaging=takari-jar, but when you consume those, you refer
> > to them as type=jar, and not as type=takari-jar, right?
> >
>
> This is wrong, downstream is either module or jar, here you loose if it is
> a module transitively and module assume all transitive deps are which is
> very often wrong so it does not work downstream.
>
>
> > So, I have a feeling that you bring bold conclusions (like "Your solution
> > is valid technically but does not solve the original issue"), you do not
> > really understand what I am trying to say here.
> >
>
> Hooe you are true but trust me i went where you are and my conclusion is it
> cant be done right for enough projects to be worth it.
>
>
> > Also, "this" certainly does NOT "work well today" (even in this thread
> poor
> > tooling mentioned), but true, you can hack-around it, or alike, but none
> of
> > current solutions are explicit, declarative and naturally expressed in
> > Maven (but are bolted on).
> >
> > Finally, having anything "on top" of resolver is not gonna help anything,
> > as Resolver is really about Artifacts only (Everything is an Artifact!)
> and
> > it is Maven on top of Resolver that should interpret these artifacts
> based
> > on user posed instructions (declarations). Resolver is really just about
> > "getting" and "putting" artifacts, not USING them.
> >
>
> It foes cause it is not aboug resolver but enabling user to express path
> with maven abstraction, not resolution itself.
>
> Java is about paths, maven coordinates, we miss a link on user land to make
> it smooth.
>
>
> > Thanks
> > T

Re: Maven 5 pom extension for agents

Le dim. 29 oct. 2023 à 15:29, Tamás Cservenák  a
écrit :

> Howdy,
>
> So to return to the "root" idea (of Maven), Maven is "declarative", where
> users should declare what they want, it should most certainly not "guess"
> what user intent is. As long as we have "magical implicit guesswork" (like
> that in javadoc) present in process, it is bad, as that means we do not
> allow our users to express their goal.
>

Yes and i liked that but we broke it with forcing plugin version locking
(for good) so we can need to revise our root too to match current world
which is no more unique, makes years we ignore that fact but it already
blows up.

So my 2cts are  we cant by design here, we tried hard and failed, not
technically but by design.



> Originally Mojos were envisioned to be simple, focused, doing one thing and
> doing it well (a la UNIX tools). Some plugins went in the total opposite
> direction, as they became Godzilla plugins (with unmaintainable complex and
> large amounts of "logic" -- guess logic and bloated codebase) targeting to
> solve "everything". This also resulted in our users assuming "every problem
> should have a corresponding Mojo" (this also steered toward bloated, over
> complex Mojos), where many many other aspects and capabilities of Maven
> were totally neglected, like lifecycle, custom packaging and so on.
>
> In short, Romain, yes, today, you CAN build all sort of things in "smart
> way", just like cooking a soup: get a good base (packaging), add a little
> bit of this (mojo A) and a little bit of that (mojo B) and voila, you will
> end up with a "soup". And it works, yes, but this "smart" way has many
> pitfalls along the way, with most problematic of not being explicit. But by
> doing that, your build becomes Ant-ish (imperative-ish), and you are
> sliding off the declarative path.
>

For cases needing it and all the mentionned ones are (and will) NOT (be)
mainstream.
So all good IMHO.


> Also, you ARE aware that if you build a project w/ packaging=module (that
> as output has an artifact with extension jar), you DON'T HAVE TO address it
> downstream (when you depend on it) as "module", right? This is the actual
> reason why I brought up Takari Lifecycle, as there you are building
> projects with packaging=takari-jar, but when you consume those, you refer
> to them as type=jar, and not as type=takari-jar, right?
>

This is wrong, downstream is either module or jar, here you loose if it is
a module transitively and module assume all transitive deps are which is
very often wrong so it does not work downstream.


> So, I have a feeling that you bring bold conclusions (like "Your solution
> is valid technically but does not solve the original issue"), you do not
> really understand what I am trying to say here.
>

Hooe you are true but trust me i went where you are and my conclusion is it
cant be done right for enough projects to be worth it.


> Also, "this" certainly does NOT "work well today" (even in this thread poor
> tooling mentioned), but true, you can hack-around it, or alike, but none of
> current solutions are explicit, declarative and naturally expressed in
> Maven (but are bolted on).
>
> Finally, having anything "on top" of resolver is not gonna help anything,
> as Resolver is really about Artifacts only (Everything is an Artifact!) and
> it is Maven on top of Resolver that should interpret these artifacts based
> on user posed instructions (declarations). Resolver is really just about
> "getting" and "putting" artifacts, not USING them.
>

It foes cause it is not aboug resolver but enabling user to express path
with maven abstraction, not resolution itself.

Java is about paths, maven coordinates, we miss a link on user land to make
it smooth.


> Thanks
> T
>
>
> On Sun, Oct 29, 2023 at 2:56 PM Tamás Cservenák 
> wrote:
>
> > 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  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/r

Re: Maven 5 pom extension for agents

Howdy,

So to return to the "root" idea (of Maven), Maven is "declarative", where
users should declare what they want, it should most certainly not "guess"
what user intent is. As long as we have "magical implicit guesswork" (like
that in javadoc) present in process, it is bad, as that means we do not
allow our users to express their goal.

Originally Mojos were envisioned to be simple, focused, doing one thing and
doing it well (a la UNIX tools). Some plugins went in the total opposite
direction, as they became Godzilla plugins (with unmaintainable complex and
large amounts of "logic" -- guess logic and bloated codebase) targeting to
solve "everything". This also resulted in our users assuming "every problem
should have a corresponding Mojo" (this also steered toward bloated, over
complex Mojos), where many many other aspects and capabilities of Maven
were totally neglected, like lifecycle, custom packaging and so on.

In short, Romain, yes, today, you CAN build all sort of things in "smart
way", just like cooking a soup: get a good base (packaging), add a little
bit of this (mojo A) and a little bit of that (mojo B) and voila, you will
end up with a "soup". And it works, yes, but this "smart" way has many
pitfalls along the way, with most problematic of not being explicit. But by
doing that, your build becomes Ant-ish (imperative-ish), and you are
sliding off the declarative path.

Also, you ARE aware that if you build a project w/ packaging=module (that
as output has an artifact with extension jar), you DON'T HAVE TO address it
downstream (when you depend on it) as "module", right? This is the actual
reason why I brought up Takari Lifecycle, as there you are building
projects with packaging=takari-jar, but when you consume those, you refer
to them as type=jar, and not as type=takari-jar, right?

So, I have a feeling that you bring bold conclusions (like "Your solution
is valid technically but does not solve the original issue"), you do not
really understand what I am trying to say here.

Also, "this" certainly does NOT "work well today" (even in this thread poor
tooling mentioned), but true, you can hack-around it, or alike, but none of
current solutions are explicit, declarative and naturally expressed in
Maven (but are bolted on).

Finally, having anything "on top" of resolver is not gonna help anything,
as Resolver is really about Artifacts only (Everything is an Artifact!) and
it is Maven on top of Resolver that should interpret these artifacts based
on user posed instructions (declarations). Resolver is really just about
"getting" and "putting" artifacts, not USING them.

Thanks
T

On Sun, Oct 29, 2023 at 2:56 PM Tamás Cservenák  wrote:

> 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 
> wrote:
>
>> Le dim. 29 oct. 2023 à 12:44, Tamás Cservenák  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 pa

Re: Maven 5 pom extension for agents

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

> Le dim. 29 oct. 2023 à 12:44, Tamás Cservenák  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  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
> > > oneand 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 lo

Re: Maven 5 pom extension for agents

Le dim. 29 oct. 2023 à 12:44, Tamás Cservenák  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  >
> wrote:
>
> > Le dim. 29 oct. 2023 à 12:12, Tamás Cservenák  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
> > oneand 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",
> > > > >

Re: Maven 5 pom extension for agents

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

Re: Maven 5 pom extension for agents

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?).

T

On Sun, Oct 29, 2023 at 12:37 PM Romain Manni-Bucau 
wrote:

> Le dim. 29 oct. 2023 à 12:12, Tamás Cservenák  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
> oneand 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 
> 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 w

Re: Maven 5 pom extension for agents

Le dim. 29 oct. 2023 à 12:12, Tamás Cservenák  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
oneand 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 
> 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  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 retu

Re: Maven 5 pom extension for agents

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

Re: Maven 5 pom extension for agents

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  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 
> > 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 
> >> 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 
> >>> 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  >
>  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  element inside ?
> >> 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  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
> >>
> >>
> >>
> >>
>

Re: Maven 5 pom extension for agents

2023-10-28 Thread Christoph Läubrich


> 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 
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 
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 
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 
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  element inside ?
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  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

Re: Maven 5 pom extension for agents

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 
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 
> 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 
>> 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 
>>> 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  element inside ?
> 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  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
>
>

Re: Maven 5 pom extension for agents

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 
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 
> 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 
>> 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  element inside ? 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  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

Re: Maven 5 pom extension for agents

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 
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 
> 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  element inside ? 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  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
>>>
>>>

Re: Maven 5 pom extension for agents

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 
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  element inside ? 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  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
>>
>>

Re: Maven 5 pom extension for agents

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  element inside ? 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  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
>
>

Re: Maven 5 pom extension for agents

2023-10-28 Thread Martin Desruisseaux


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  element inside ? 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  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

Re: Maven 5 pom extension for agents