[VOTE] Release Apache Maven Archetype version 3.3.1

[Slawomir Jaranowski]

Hi,

We solved 13 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317122&version=12355155

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARCHETYPE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-2235/
https://repository.apache.org/content/repositories/maven-2235/org/apache/maven/archetype/maven-archetype/3.3.1/maven-archetype-3.3.1-source-release.zip

Source release checksum(s):
maven-archetype-3.3.1-source-release.zip - SHA-512 :
301623c8edb02866755989d6626c4e9f718ba850ef552b3c739ff22557765245c6016ff6a7802528ffdb762f9cfee096a289b35af6f7e8413ca9ba9c8e07563a

Staging site:
https://maven.apache.org/archetype-archives/archetype-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1

-- 
Sławomir Jaranowski

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

RE: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2

[Robert Scholte]

Inline responses...

-Original Message-
From: Martin Desruisseaux  
Sent: donderdag 24 oktober 2024 12:38
To: dev@maven.apache.org
Subject: Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2

Le 2024-10-24 à 12 h 07, Robert Scholte a écrit :
>
> Can you explain the problem you're trying to solve? In particular I 
> don't understand the need for modular-jar and classpath-jar, as 
> currently both classpath and modulepath are already build up correctly 
> based on the module descriptors.
>
The problem is that they are not always build up correctly. Maven uses 
heuristic rules, and there is currently no easy way a user could change Maven's 
mind when those rules do not match user's intend. Examples:

  * A user may want to put non-modular JAR files on the module path.
This is called automatic modules. I'm aware that there are arguments
about whether this is good practice or not, but the new compiler
plugin is not taking position in that debate. Automatic modules are
officially supported and part of the Java specification, and there
are sometime legitimate reasons to want to use them.

>> What is effectively the difference here? As long as there's no reference 
>> from a module descriptor to a module (either named or automatic) there 
>> should be no difference.
>> It is already possible to refer to automatic modules, including a big 
>> disclaimer in case it is a library (automatic modules are less problematic 
>> for applications)
>> Do you have a minimized project that demonstrates that there are different 
>> results?

  * Maven currently puts everything on the class-path when a project is
non-modular. But a non-modular project may still want to put its
modular dependencies on the module-path. This choice changes the way
that services are loaded for example.

>> Loading services sounds like a runtime issue, not a compile time issue.
>> Do you have a minimized project that demonstrates that there are different 
>> results?

So what Maven is currently doing is not always the right thing to do. It may be 
a reasonable default however. Therefore, the "jar" type will continue to behave 
as today. But the "classpath-jar" and "modular-jar" 
types, or something equivalent, are needed when the Maven's heuristic rules 
don't do what the user wants.

>> I think that the type is abused here. Also, does this mean that other tools 
>> suddenly need to understand this type as well? Or does Maven4 revert it back 
>> to "jar" in the consumer-pom, in which case you will have different behavior 
>> at runtime?
>> In both cases there's an issue. 
>> If there really is an issue, there should be a solution that doesn't impact 
>> any other pom-consumer, it should be scoped to maven-build section.


 Martin



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

RE: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2

[Robert Scholte]

-Original Message-
From: Martin Desruisseaux  
Sent: donderdag 24 oktober 2024 13:38
To: dev@maven.apache.org
Subject: Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2

Le 2024-10-24 à 13 h 17, Robert Scholte a écrit :

(about automatic modules)

> What is effectively the difference here? As long as there's no 
> reference from a module descriptor to a module (either named or
> automatic) there should be no difference.
>
The purpose of automatic modules is to allow them to be referenced from the 
module descriptor. But it doesn't work if the automatic module is not on the 
module path.



> Do you have a minimized project that demonstrates that there are 
> different results?
>
I need to check if there is one specifically for the above (will do that after 
lunch), but some issues are demonstrated there:

https://github.com/Geomatys/MavenModulepathBug

>>What I'm seeing here is: service provides both a module descriptor with the 
>>services, so it can be used on the modulepath
>>At the same time it also provides a META-INF/services to make it compatible 
>>for the classpath as well.
>>This is awesome to make it work for both classpath and modulepath
>>But there's one important thing here: this only makes sense if both are the 
>>same.
>>(I can't think of a reason to do it other like this, other than demonstrating 
>>where the service is coming from)

> I think that the type is abused here. Also, does this mean that other 
> tools suddenly need to understand this type as well? Or does Maven4 
> revert it back to "jar" in the consumer-pom, in which case you will 
> have different behavior at runtime?
> In both cases there's an issue. If there really is an issue, there 
> should be a solution that doesn't impact any other pom-consumer, it 
> should be scoped to maven-build section.
Other tools will need to be updated. This is the updated mentioned in previous 
email concerning the javadoc and surefire plugin. But we don't have much 
choice. I don't see how we could resolve class-path versus module-path issue 
without some new API. Furthermore, this change has been opportunistically 
generalized to other kind of path issue. The type also allow to specify whether 
to put a dependency on the doclet path, taglet path, annotation processor path, 
etc. Thus, providing a unified way to manage various kind of paths instead of 
heterogeneous plugin configurations that mimic the dependencies section.

 Martin

>> Even though Maven introduced the pom.xml, we should really prevent making 
>> behaviour changes for modelVersion 4.0.0 as being uploaded to Maven Central.
>> In this case the type is being abused for deciding where the jars should be 
>> used. If this needs to be explicitly done, it should be some sort of 
>> subscope of compile (which doesn't exist).
>> Don't turn a runtime issue (where the application needs to choose providers 
>> for servers) into a generic compile+runtime issue.
>> Regarding annotations and doclets, these should be dependencies of that 
>> plugin with a scope, as they are not project dependencies. (I think I've 
>> created an issue for it, probably targeted for M5)


-
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: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2

[Tamás Cservenák]

Robert,

you might missed this quite long thread that happened about a year ago:
https://lists.apache.org/thread/x99pj75vfn5p3xtr0mvhgs5s4935j3gn

Just to get into the picture, and not repeat the whole story again :)

Thanks
T

On Thu, Oct 24, 2024 at 1:18 PM Robert Scholte  wrote:
>
> Inline responses...
>
> -Original Message-
> From: Martin Desruisseaux 
> Sent: donderdag 24 oktober 2024 12:38
> To: dev@maven.apache.org
> Subject: Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin 
> beta-2
>
> Le 2024-10-24 à 12 h 07, Robert Scholte a écrit :
> >
> > Can you explain the problem you're trying to solve? In particular I
> > don't understand the need for modular-jar and classpath-jar, as
> > currently both classpath and modulepath are already build up correctly
> > based on the module descriptors.
> >
> The problem is that they are not always build up correctly. Maven uses 
> heuristic rules, and there is currently no easy way a user could change 
> Maven's mind when those rules do not match user's intend. Examples:
>
>   * A user may want to put non-modular JAR files on the module path.
> This is called automatic modules. I'm aware that there are arguments
> about whether this is good practice or not, but the new compiler
> plugin is not taking position in that debate. Automatic modules are
> officially supported and part of the Java specification, and there
> are sometime legitimate reasons to want to use them.
>
> >> What is effectively the difference here? As long as there's no reference 
> >> from a module descriptor to a module (either named or automatic) there 
> >> should be no difference.
> >> It is already possible to refer to automatic modules, including a big 
> >> disclaimer in case it is a library (automatic modules are less problematic 
> >> for applications)
> >> Do you have a minimized project that demonstrates that there are different 
> >> results?
>
>   * Maven currently puts everything on the class-path when a project is
> non-modular. But a non-modular project may still want to put its
> modular dependencies on the module-path. This choice changes the way
> that services are loaded for example.
>
> >> Loading services sounds like a runtime issue, not a compile time issue.
> >> Do you have a minimized project that demonstrates that there are different 
> >> results?
>
> So what Maven is currently doing is not always the right thing to do. It may 
> be a reasonable default however. Therefore, the "jar" type will continue to 
> behave as today. But the "classpath-jar" and "modular-jar"
> types, or something equivalent, are needed when the Maven's heuristic rules 
> don't do what the user wants.
>
> >> I think that the type is abused here. Also, does this mean that other 
> >> tools suddenly need to understand this type as well? Or does Maven4 revert 
> >> it back to "jar" in the consumer-pom, in which case you will have 
> >> different behavior at runtime?
> >> In both cases there's an issue.
> >> If there really is an issue, there should be a solution that doesn't 
> >> impact any other pom-consumer, it should be scoped to maven-build section.
>
>
>  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: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2

[Martin Desruisseaux]

Le 2024-10-24 à 13 h 17, Robert Scholte a écrit :

(about automatic modules)

What is effectively the difference here? As long as there's no 
reference from a module descriptor to a module (either named or 
automatic) there should be no difference.


The purpose of automatic modules is to allow them to be referenced from 
the module descriptor. But it doesn't work if the automatic module is 
not on the module path.



Do you have a minimized project that demonstrates that there are 
different results?


I need to check if there is one specifically for the above (will do that 
after lunch), but some issues are demonstrated there:


https://github.com/Geomatys/MavenModulepathBug


I think that the type is abused here. Also, does this mean that other 
tools suddenly need to understand this type as well? Or does Maven4 
revert it back to "jar" in the consumer-pom, in which case you will 
have different behavior at runtime?
In both cases there's an issue. If there really is an issue, there 
should be a solution that doesn't impact any other pom-consumer, it 
should be scoped to maven-build section.
Other tools will need to be updated. This is the updated mentioned in 
previous email concerning the javadoc and surefire plugin. But we don't 
have much choice. I don't see how we could resolve class-path versus 
module-path issue without some new API. Furthermore, this change has 
been opportunistically generalized to other kind of path issue. The type 
also allow to specify whether to put a dependency on the doclet path, 
taglet path, annotation processor path, etc. Thus, providing a unified 
way to manage various kind of paths instead of heterogeneous plugin 
configurations that mimic the dependencies section.


    Martin



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

RE: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2

[Robert Scholte]

Thanks, that's indeed long.

But seeing the result makes we wonder if the right decision has been made with 
regard to pom consumption. 
To me this looks like this is going to disrupt the java ecosystem.
Just one question: what will happen with Maven3 users (or any other tool) if 
one of their dependencies has this special type?
Not sure why this had to be forced into the current modelVersion 4.0.0 like 
this.

Anyway, I guess the decision has been made.
Robert

-Original Message-
From: Tamás Cservenák  
Sent: donderdag 24 oktober 2024 14:01
To: Maven Developers List 
Subject: Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2

Robert,

you might missed this quite long thread that happened about a year ago:
https://lists.apache.org/thread/x99pj75vfn5p3xtr0mvhgs5s4935j3gn

Just to get into the picture, and not repeat the whole story again :)

Thanks
T

On Thu, Oct 24, 2024 at 1:18 PM Robert Scholte  wrote:
>
> Inline responses...
>
> -Original Message-
> From: Martin Desruisseaux 
> Sent: donderdag 24 oktober 2024 12:38
> To: dev@maven.apache.org
> Subject: Re: [DISCUSS] Merge JPMS work in upcoming 
> maven-compiler-plugin beta-2
>
> Le 2024-10-24 à 12 h 07, Robert Scholte a écrit :
> >
> > Can you explain the problem you're trying to solve? In particular I 
> > don't understand the need for modular-jar and classpath-jar, as 
> > currently both classpath and modulepath are already build up 
> > correctly based on the module descriptors.
> >
> The problem is that they are not always build up correctly. Maven uses 
> heuristic rules, and there is currently no easy way a user could change 
> Maven's mind when those rules do not match user's intend. Examples:
>
>   * A user may want to put non-modular JAR files on the module path.
> This is called automatic modules. I'm aware that there are arguments
> about whether this is good practice or not, but the new compiler
> plugin is not taking position in that debate. Automatic modules are
> officially supported and part of the Java specification, and there
> are sometime legitimate reasons to want to use them.
>
> >> What is effectively the difference here? As long as there's no reference 
> >> from a module descriptor to a module (either named or automatic) there 
> >> should be no difference.
> >> It is already possible to refer to automatic modules, including a 
> >> big disclaimer in case it is a library (automatic modules are less 
> >> problematic for applications) Do you have a minimized project that 
> >> demonstrates that there are different results?
>
>   * Maven currently puts everything on the class-path when a project is
> non-modular. But a non-modular project may still want to put its
> modular dependencies on the module-path. This choice changes the way
> that services are loaded for example.
>
> >> Loading services sounds like a runtime issue, not a compile time issue.
> >> Do you have a minimized project that demonstrates that there are different 
> >> results?
>
> So what Maven is currently doing is not always the right thing to do. It may 
> be a reasonable default however. Therefore, the "jar" type will continue to 
> behave as today. But the "classpath-jar" and "modular-jar"
> types, or something equivalent, are needed when the Maven's heuristic rules 
> don't do what the user wants.
>
> >> I think that the type is abused here. Also, does this mean that other 
> >> tools suddenly need to understand this type as well? Or does Maven4 revert 
> >> it back to "jar" in the consumer-pom, in which case you will have 
> >> different behavior at runtime?
> >> In both cases there's an issue.
> >> If there really is an issue, there should be a solution that doesn't 
> >> impact any other pom-consumer, it should be scoped to maven-build section.
>
>
>  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



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

Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2

[Tamás Cservenák]

We are talking about Maven 4 plugins (the compiler, for example), so
we are talking about model version 4.1.0+ strictly here.
No Maven3 involved (or model version 4.0.0). It is in that long thread
clarified, that due shortcomings of Maven3 internals, it cannot be
done (without breaking all of it).

Thanks
T

On Thu, Oct 24, 2024 at 2:27 PM Robert Scholte  wrote:
>
> Thanks, that's indeed long.
>
> But seeing the result makes we wonder if the right decision has been made 
> with regard to pom consumption.
> To me this looks like this is going to disrupt the java ecosystem.
> Just one question: what will happen with Maven3 users (or any other tool) if 
> one of their dependencies has this special type?
> Not sure why this had to be forced into the current modelVersion 4.0.0 like 
> this.
>
> Anyway, I guess the decision has been made.
> Robert
>
> -Original Message-
> From: Tamás Cservenák 
> Sent: donderdag 24 oktober 2024 14:01
> To: Maven Developers List 
> Subject: Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin 
> beta-2
>
> Robert,
>
> you might missed this quite long thread that happened about a year ago:
> https://lists.apache.org/thread/x99pj75vfn5p3xtr0mvhgs5s4935j3gn
>
> Just to get into the picture, and not repeat the whole story again :)
>
> Thanks
> T
>
> On Thu, Oct 24, 2024 at 1:18 PM Robert Scholte  wrote:
> >
> > Inline responses...
> >
> > -Original Message-
> > From: Martin Desruisseaux 
> > Sent: donderdag 24 oktober 2024 12:38
> > To: dev@maven.apache.org
> > Subject: Re: [DISCUSS] Merge JPMS work in upcoming
> > maven-compiler-plugin beta-2
> >
> > Le 2024-10-24 à 12 h 07, Robert Scholte a écrit :
> > >
> > > Can you explain the problem you're trying to solve? In particular I
> > > don't understand the need for modular-jar and classpath-jar, as
> > > currently both classpath and modulepath are already build up
> > > correctly based on the module descriptors.
> > >
> > The problem is that they are not always build up correctly. Maven uses 
> > heuristic rules, and there is currently no easy way a user could change 
> > Maven's mind when those rules do not match user's intend. Examples:
> >
> >   * A user may want to put non-modular JAR files on the module path.
> > This is called automatic modules. I'm aware that there are arguments
> > about whether this is good practice or not, but the new compiler
> > plugin is not taking position in that debate. Automatic modules are
> > officially supported and part of the Java specification, and there
> > are sometime legitimate reasons to want to use them.
> >
> > >> What is effectively the difference here? As long as there's no reference 
> > >> from a module descriptor to a module (either named or automatic) there 
> > >> should be no difference.
> > >> It is already possible to refer to automatic modules, including a
> > >> big disclaimer in case it is a library (automatic modules are less 
> > >> problematic for applications) Do you have a minimized project that 
> > >> demonstrates that there are different results?
> >
> >   * Maven currently puts everything on the class-path when a project is
> > non-modular. But a non-modular project may still want to put its
> > modular dependencies on the module-path. This choice changes the way
> > that services are loaded for example.
> >
> > >> Loading services sounds like a runtime issue, not a compile time issue.
> > >> Do you have a minimized project that demonstrates that there are 
> > >> different results?
> >
> > So what Maven is currently doing is not always the right thing to do. It 
> > may be a reasonable default however. Therefore, the "jar" type will 
> > continue to behave as today. But the "classpath-jar" and "modular-jar"
> > types, or something equivalent, are needed when the Maven's heuristic rules 
> > don't do what the user wants.
> >
> > >> I think that the type is abused here. Also, does this mean that other 
> > >> tools suddenly need to understand this type as well? Or does Maven4 
> > >> revert it back to "jar" in the consumer-pom, in which case you will have 
> > >> different behavior at runtime?
> > >> In both cases there's an issue.
> > >> If there really is an issue, there should be a solution that doesn't 
> > >> impact any other pom-consumer, it should be scoped to maven-build 
> > >> section.
> >
> >
> >  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
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache

Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2

[Martin Desruisseaux]

Le 2024-10-24 à 14 h 13, Robert Scholte a écrit :

What I'm seeing here is: service provides both a module descriptor 
with the services, so it can be used on the modulepath At the same 
time it also provides a META-INF/services to make it compatible for 
the classpath as well. This is awesome to make it work for both 
classpath and modulepath But there's one important thing here: this 
only makes sense if both are the same. (I can't think of a reason to 
do it other like this, other than demonstrating where the service is 
coming from)
The two approaches (module-info versus META-INF) are not strictly 
equivalent. For example, the static 'provider()' method works only with 
module-info and doesn't work with META-INF. Workarounds are possible, 
but can be tedious especially when the instance returned by 'provider()' 
may implement different interfaces depending on runtime environment. In 
order to avoid above-cited difficulty, or in order to avoid the risk of 
inconsistency between module-info and META-INF (e.g. updating the former 
and forgetting the update the latter), an implementation may decide to 
drop META-INF. This is equivalent to dropping the possibility to run the 
library on the class-path. We may argue about whether this is good 
practice or not, but for the purpose of this discussion, the key point 
is that users can be stuck if they cannot take control on what is on the 
class-path versus module-path.



Even though Maven introduced the pom.xml, we should really prevent 
making behaviour changes for modelVersion 4.0.0 as being uploaded to 
Maven Central.
My understanding is that there is an agreement on that. It has been 
proposed (independently of the JPMS work) to have a decoupling between 
the POM used for building the project, and the POM deployed on Maven 
Central. The former may evolve, but the latter would stay the same. 
Except I guess for the new types, but this evolution doesn't add new XML 
elements in the model.



In this case the type is being abused for deciding where the jars 
should be used. If this needs to be explicitly done, it should be some 
sort of subscope of compile (which doesn't exist).
The location (class-path versus module-path) needs to be the same (at 
least by default) for compiler, javadoc, surefire, exec, etc. So it is a 
wider concept than a compiler scope.



Don't turn a runtime issue (where the application needs to choose 
providers for servers) into a generic compile+runtime issue.
I'm not sure to understand this argument... Class-path versus 
module-path is indeed a compile + runtime + javadoc + other JDK tools issue.



Regarding annotations and doclets, these should be dependencies of 
that plugin with a scope, as they are not project dependencies. (I 
think I've created an issue for it, probably targeted for M5)
This is indeed one possible way to see those dependencies. But that 
would not resolve fully the problem. For example, we would still need to 
distinguish whether a Javadoc plugin dependency shall be put on the 
doclet path or the taglet path. Since we already need to do this kind of 
distinction for class-path versus module-path, the same mechanism can be 
generalized to doclet versus taglet paths, and all other paths.


    Martin



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

Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2

[Martin Desruisseaux]

Le 2024-10-24 à 12 h 07, Robert Scholte a écrit :


Can you explain the problem you're trying to solve? In particular I 
don't understand the need for modular-jar and classpath-jar, as 
currently both classpath and modulepath are already build up correctly 
based on the module descriptors.


The problem is that they are not always build up correctly. Maven uses 
heuristic rules, and there is currently no easy way a user could change 
Maven's mind when those rules do not match user's intend. Examples:


 * A user may want to put non-modular JAR files on the module path.
   This is called automatic modules. I'm aware that there are arguments
   about whether this is good practice or not, but the new compiler
   plugin is not taking position in that debate. Automatic modules are
   officially supported and part of the Java specification, and there
   are sometime legitimate reasons to want to use them.
 * Maven currently puts everything on the class-path when a project is
   non-modular. But a non-modular project may still want to put its
   modular dependencies on the module-path. This choice changes the way
   that services are loaded for example.

So what Maven is currently doing is not always the right thing to do. It 
may be a reasonable default however. Therefore, the "jar" type will 
continue to behave as today. But the "classpath-jar" and "modular-jar" 
types, or something equivalent, are needed when the Maven's heuristic 
rules don't do what the user wants.


    Martin

Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2

[Martin Desruisseaux]

Le 2024-10-24 à 14 h 25, Robert Scholte a écrit :

Just one question: what will happen with Maven3 users (or any other 
tool) if one of their dependencies has this special type?
Rephrasing as "what will happen with a Maven 3 plugin running on Maven 4 
without having been updated to the Maven 4 API?", the Java methods 
which, in Maven 3, were returning the list of all JAR dependencies 
continue to return all JARs in Maven 4, regardless if they are "jar", 
"modular-jar" or "classpath-jar". If those plugins were applying their 
own heuristic rules for deciding what to put on the classpath or 
module-path, it should continue to work, at the risk of being 
inconsistent with user's desire. In order to distinguish between "jar", 
"modular-jar" or "classpath-jar" (otherwise than by invoking 
Artifact.getType() method), the plugin needs to invoke new Maven 4 API.


    Martin



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

Re: [DISCUSS] Enable GitHub issues and GitHub discussions

[Giovanni van der Schelde]

Hi,

+1
Switching from Jira to GitHub brings the benefit of reducing the hurdle for
people to start contributing.
I don't have statistics but I can imagine that quite some people (who would
like to commit) don't even know we are using Jira and the mailing list. And
if they do, it is still an extra complexity to 'just get started'.
I do prefer the more developer friendly/easier way of reading and creating
tickets, and having it closer to the implementation.

0 / -1
While I'm not most familiar with ticket management on bigger open source
projects on GitHub, I can imagine it might be a bit more tricky to relate
issues like you can with tools like Jira.
Features like 'related to', 'duplicate off', 'depends on' are harder to
track. You might need to use the 'Projects' feature for that, but that
seems somewhat limited.
You'd have to scroll through an issue to notice other issues or PR's
reference a specific (especially older) issue you are working on.

Regards,

Giovanni

On Wed, 23 Oct 2024 at 09:37, Mirko Friedenhagen
 wrote:

>
> > Am 22.10.2024 um 16:52 schrieb Guillaume Nodet :
> >
> > I'd like to start discussing opening (and eventually slowly switching)
> from
> > JIRA to GitHub issues.
> >
> > JIRA is a bit of a pain to use, even though we have some automatic links
> > done with PRs and such. Accounts need to be authorized to maintain the
> > number of external accounts low enough within the ASF, whereas this would
> > only require a GitHub account.
> > Release notes can be published on GitHub very easily, so the only thing
> is
> > that we have the whole history and list of opened issues, but I just see
> > new issues being created on GitHub and handling both sources for some
> time,
> > gradually moving to GitHub issues only.
> >
> > I also think we could benefit from GitHub discussions.  Those can be
> backed
> > by the mailing list very easily (just by configuration) and that would be
> > easier to link to issues, PRs and more integrated into GitHub, with
> > markdown support, etc  See
> > https://github.com/apache/opendal/discussions/5211 for example.
> >
> > Thoughts
>
> Hi,
>
> +1 from my side. In the company I work for we use GitLab and JIRA and have
> similar issues. I would gladly drop JIRA there immediately if I could.
> * Using markdown in discussions is much nicer.
> * Notication settings are more powerful.
> * While I understand that some people do not like GitHub’s TOs I think
> that collaboration would be easier with most devs out there.
>
> Mit freundlichen Grüßen
> Mirko Friedenhagen
> —
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Met vriendelijke groet,

Giovanni van der Schelde

Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2

[Martin Desruisseaux]

Le 2024-10-24 à 08 h 20, Guillaume Nodet a écrit :


Is there any technical reason why we could not port those ?

About MCOMPILER-542 (a workaround that modified the module-info.class 
generated by javac versions before Java 22), there is no technical 
reason apart a desire to reduce dependencies and to avoid transforming 
compiler outputs without user's acknowledgement (I was surprised to 
discover that Maven rewrites some class files generated by javac). 
Especially since previously, Maven modified the module-info.class files 
only if reproducible built was enabled. But now that reproducible build 
is enabled by default, Maven will modify the module-info.class 
practically always when compiling with a JDK prior to Java 22. I don't 
know if all users are comfortable with that. If no concern are 
expressed, I can put MCOMPILER-542 back this weekend.


About not trying anymore to be clever regarding -source versus -release 
options, there is good chance that this issue is mot since Maven 4 
requires Java 17 for execution. Therefore, users should not have reason 
to use -source anymore. The concern expressed by Jorge is that asking 
users to add empty  and  elements in the plugin 
configuration compromise usability. I agree, but adding those empty 
elements should be needed only if the user inherited those elements 
(non-empty) from a parent POM, so they need to override them. Whether it 
happens often or not is something that we could discover with the beta.


Generally, the rewritten plugin has a policy of not overwriting Java 
defaults with Maven's own opinion of what the default should have been. 
A goal is to make Maven more easily predictable for peoples who are 
familiar with javac options. But this is part of the things that can be 
revisited according user's feedback.


    Martin

Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2

[Martin Desruisseaux]

Le 2024-10-24 à 07 h 57, Olivier Lamy a écrit :


I wonder if the changes have been ported to surefire and javadoc?

Not yet, but indeed those plugins will also need to be updated. We may 
not be able to update them in same time as the compiler plugin. A 
consequence is that some tasks that should become easier with the new 
compiler plugin (e.g. control on class-path versus module-path) but will 
stay difficult with the surefire and javadoc plugins. However, I don't 
think that they would be more difficult than they currently are.


We could do compiler, surefire, javadoc and jar (that latter may also 
need an update) in parallel. My current way of working is rather to 
focus on one plugin at a time, and to finish the compiler plugin before 
to move on to the next plugin (the next work item is the way to declare 
sources). But this approach may be changed if it appears necessary.


    Martin

RE: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2

[Robert Scholte]

Can you explain the problem you're trying to solve?
In particular I don't understand the need for modular-jar and classpath-jar, as 
currently both classpath and modulepath are already build up correctly based on 
the module descriptors.

Thanks,
Robert

-Original Message-
From: Martin Desruisseaux  
Sent: woensdag 23 oktober 2024 16:40
To: dev@maven.apache.org
Subject: Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2

Le 2024-10-23 à 16 h 22, Ralph Goers a écrit :

> What is the easiest way to determine what has been changed? When I was 
> working on Log4j’s JPMS support Maven’s handling of JPMS frequently 
> caused problems and forced us to do some things I consider kind of ugly.
>
The main changes are described there, especially the 2 first points 
("Incompatible changes" and "Changes in compiler parameters"). The rest can 
easily be ignored:

https://github.com/Geomatys/maven-compiler-plugin/wiki

If accepted, above-cited two points would be ported to the APT format for the 
plugin site.

If anything break e.g. with Log4J, we will either fix the regression or 
document the changes with proposed alternatives. But it implies that there is a 
risk that the compiler plugin 4.0.0-beta-2 breaks some builds and that we need 
a couple of beta releases before to resolve the issues.

 Martin



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

Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2

[Daniel Schmid]

On 24.10.24 11:03, Martin Desruisseaux wrote:
About not trying anymore to be clever regarding -source versus 
-release options, there is good chance that this issue is mot since 
Maven 4 requires Java 17 for execution. Therefore, users should not 
have reason to use -source anymore. The concern expressed by Jorge is 
that asking users to add empty  and  elements in the 
plugin configuration compromise usability. I agree, but adding those 
empty elements should be needed only if the user inherited those 
elements (non-empty) from a parent POM, so they need to override them. 
Whether it happens often or not is something that we could discover 
with the beta.
I think this may still be an issue for people using a toolchain to 
compile it with an older Java version (e.g. people wanting to compile 
something using Java 8). In these cases, --release may not be available 
so they have to use --source and --target.


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

Re: [DISCUSS] Project member emeritus policy change

[Enrico Olivelli]

+0 I agree that it would be a good practice to clean up, but in the end it
is not a big deal to have people listed

Thanks for raising the discussion,  having these conversations about the
community itself is always a great opportunity for the project to grow and
become stronger

Some comments inline below

Il giorno gio 24 ott 2024 alle ore 07:51 Romain Manni-Bucau <
rmannibu...@gmail.com> ha scritto:

> +-0 but maybe start to setup a routine which will generate a "team2.html"
> page with a column "latest contribution" (mail or commit or review?) and
> from there see how it looks like and then spawn again the emeritus topic?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064
> >
>
>
> Le jeu. 24 oct. 2024 à 00:05, Arnaud Héritier  a
> écrit :
>
> > +1
> >
> > On Tue, Oct 22, 2024 at 6:17 PM Tamás Cservenák 
> > wrote:
> >
> > > Howdy,
> > >
> > > I would like to propose a project policy change (followed by
> > > implementation) regarding "emeritus" status of PMCs and members.
> > >
> > > Proposal:
> > > 1) IF a PMC member is inactive for 24 months (did NOT participate in
> > > any VOTE [by casting binding vote] OR did not create any commit that
> > > ended up in the project), he should be automatically moved to
> > > "emeritus PMC" status.
> > > 2) IF a committer is inactive for 24 months (did NOT participate in
> > > any VOTE [by casting vote] OR did not create and/or review any commit
> > > that ended up in the project), he should be automatically moved to
> > > "emeritus committer" status.
> > >
> > > Reasoning:
> > > Currently if interested party checks ASF report about Maven project on
> > >  https://projects.apache.org/committee.html?maven , the presented data
> > > is skewed, if not even false, about "who" (and more importantly "how
> > > many") user is working on a project. This can lead to some unpleasant
> > > misunderstandings as well (from "why is my PR not reviewed yet" to
> > > many others).


Maybe this is not a big deal ?

We must help the contributors to learn how to interact with the
community and especially the mailing list to start a discussion about their
patch.
This is the right way for them to be more involved in the community, and
finally become committers (== "responsible for" for community and the
project)


> Moreover, this same (wrong) number may in fact lessen
> > > potential contributors, make them turn away and choose another, less
> > > supported project to join. Finally, I think we should shrink the
> > > circle of "admin" powered users to those we are almost certain are
> > > around us and involved.


I don't think that this is a real problem. For these reasons:
- releases must be approved by a quorum of PMC members, there is no way
that someone releases something to the public without the consensus of the
community
- we receive notifications for each PR and commit: if someone does any
harm...we will know, and you can always "git revert" or "git push --force"


> Project already has "emeritus" roles for both,
>

As said, I am +0 to this. I have seen in the past in other places that
people explicitly ask to move to Emeritus by themself


My two cents
Enrico


> > > PMCs and committers AFAIK (correct me if I am wrong).
> > >
> > > WDYT?
> > >
> > > Thanks
> > > T
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
> > --
> > Arnaud Héritier
> > Twitter/GitHub/... : aheritier
> >
>