Re: Toolchains and Maven Enforcer

[Guillaume Nodet]

Le mar. 4 févr. 2025 à 09:05, Thomas Reinhardt  a
écrit :

>
> Interesting, I was not aware of the new discovery mechanism.
>
> Unfortunately the most interesting goal "select-jdk-toolchain" is not
> marked threadsafe. Was that a conscious decision or just easier to
> implement?
>

I think it's an oversight, I don't really see why it would not be thread
safe.


> Also I am missing a parameter to provide a search path. Might come in
> handy in CI environments like Jenkins.
>

Yes, that would be a good addition.  The discovery mechanism uses hard
coded heuristics and improvements would be welcomed.  Or customization...



> Any opinions on the above two points? Otherwise I would just open issues
> for those.
>
>
> -Thomas
>
>
> On 03/02/2025 08:05, Guillaume Nodet wrote:
> > The toolchains discovery has been released a few months ago:
> >
> >
> https://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/jdk-discovery.html
> > This is also usable in Maven 3.x.
> >
> > I think that should cover your use case.
> > The enforcer check does not really need to be performed because the
> > toolchain selection
> > will ensure that the selected toolchain matches the input range.
> >
> > Le lun. 3 févr. 2025 à 07:12, Mikko Johannes Koivunalho <
> > mikko.koivuna...@iki.fi> a écrit :
> >
> >> Hi,
> >>
> >> I am forwarding this message to Maven Developer List.
> >>
> >> Before getting to any development, I'd like to know more about planned
> >> Maven4 improvements in the area of toolchains.
> >>
> >> Thank you.
> >>
> >>
> >> Sincerely,
> >> Mikko Koivunalho
> >>
> >> On 02/02/2025 19:28, Tamás Cservenák wrote:
> >>> Howdy,
> >>>
> >>> TBH, I never understood why toolchains are not ALWAYS used
> >>> with one (always) available toolchain, the Java that runs Maven
> >>> itself, so this would be your fallback.
> >>>
> >>> Re enforcer, yes, probably we need new rules that would behave
> >>> as you describe.
> >>>
> >>> Hence, yes, this would be a good direction.
> >>>
> >>> OTOH, for Maven4 we do have some improvements in this area,
> >>> like auto discovery, so any contribution is welcome!
> >>>
> >>> Thanks
> >>> T
> >>>
> >>> On Sun, Feb 2, 2025 at 6:35 PM Mikko Johannes Koivunalho
> >>>  wrote:
>  Hi,
> 
>  I work with many Maven projects which require building with different
>  JDKs: Java 8, Java 11, Java 17, and so on. I have all these installed
>  side by side in my build machine.
> 
>  Maven Toolchains plugin is very helpful because it prevents me from
>  being forced to reconfigure environment variable JAVA_HOME when I move
>  between Maven projects.
> 
>  However, for those who only use one of those projects, configuring the
>  toolchains and JDKs is too complicated. They have their Java already
>  configured to use the correct JDK.
> 
>  It would be convenient if Maven Toolchains plugin had a fallback mode:
>  when the file .m2/toolchains.xml is not present, i.e. the toolchains
> are
>  not configured, Maven Toolchains plugin would simply fall back to use
>  the same Java as Maven itself uses.
> 
>  Maven Toolchains plugin could have a setting to allow the fallback. By
>  default, the fallback would not be allowed. This is the behavior now.
> 
> 
>  Even when using toolchains, I am also using Maven Enforcer rule
>  RequireJavaVersion to limit the range of usable Java versions. This
> rule
>  only tracks the version of the Java runtime Maven itself is using so
> it
>  is not compatible with Maven Toolschains.
> 
>  To work with Maven Toolchains plugin and remain backwards compatible,
>  Maven Enforcer would need a new rule, maybe
>  "RequireJDKVersion", "RequireToolchainJavaVersion" or
>  "RequireJavaCompilerVersion". It would also have to work with the
>  fallback mode as described above.
> 
> 
>  Would the above be the right direction to develop Maven Toolchains?
>  Thanks for all comments.
> 
> 
>  Sincerely,
>  Mikko Koivunalho
> 
> 
>  -
>  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>  For additional commands, e-mail: users-h...@maven.apache.org
> 
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: users-h...@maven.apache.org
> >>>
> >>>
> >> --
> >> Mikko Koivunalho
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 

Re: [VOTE] Release Maven Resolver Ant Tasks 1.5.2

[Arnaud Héritier]

+1

Arnaud Héritier
Twitter/GitHub/ASF... : aheritier


On Tue, Feb 4, 2025 at 22:00 Sylwester Lachiewicz 
wrote:

> +1
>
> wt., 4 lut 2025, 21:49 użytkownik Olivier Lamy  napisał:
>
> > +1
> > On Mon, 3 Feb 2025 at 1:22 am, Tamás Cservenák 
> > wrote:
> >
> > > Howdy,
> > >
> > > We solved 5 issues:
> > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628&version=12354742
> > >
> > > There is one issue in JIRA:
> > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20%22Ant%20Tasks%22
> > >
> > > Staging repository:
> > > https://repository.apache.org/content/repositories/maven-2263/
> > >
> > > Source release SHA512:
> > >
> > >
> >
> 033c4966c110083419209b1b46805c8eb8dcfd33369862edb7c74a75c4f382fd8a5756e0eaf215964c68d6fed9248ce046aad86f27cf0098b95ffb316a89aa85
> > >
> > > Staging site:
> > > https://maven.apache.org/resolver-archives/resolver-LATEST/
> > >
> > > Guide to testing staged releases:
> > >
> https://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for 72 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>

Re: Github issue migration problem

[Benjamin Marwell]

We are on contact with GitHub support. Please refrain from manually closing
them for now.

Before that, some were not displayed, were in status pending, which
effectively made them missing.

I'll keep you posted.



On Tue, 4 Feb 2025, 23:44 Elliotte Rusty Harold,  wrote:

> If you look at https://github.com/apache/maven-jlink-plugin/issues
> you'll notice that all the issues from the Jira have been copied into
> github multiple times.
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Github issue migration problem

[Slawomir Jaranowski]

I'm still not convitient if we really need copy all issues from jira
to github - as I wrote many times

- jira will be exist with us
- I don't believe that users before creating new issue look for old -
if yes they have a link to old issues
- many issues should be triaged again - it is manually work

On Tue, 4 Feb 2025 at 23:42, Elliotte Rusty Harold  wrote:
>
> If you look at https://github.com/apache/maven-jlink-plugin/issues
> you'll notice that all the issues from the Jira have been copied into
> github multiple times.
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Sławomir Jaranowski

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

Re: Github issue migration problem

[Guillaume Nodet]

Le mer. 5 févr. 2025 à 07:36, Slawomir Jaranowski 
a écrit :

> I'm still not convitient if we really need copy all issues from jira
> to github - as I wrote many times
>
> - jira will be exist with us
> - I don't believe that users before creating new issue look for old -
> if yes they have a link to old issues
> - many issues should be triaged again - it is manually work
>

Agreed.


>
> On Tue, 4 Feb 2025 at 23:42, Elliotte Rusty Harold 
> wrote:
> >
> > If you look at https://github.com/apache/maven-jlink-plugin/issues
> > you'll notice that all the issues from the Jira have been copied into
> > github multiple times.
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> --
> Sławomir Jaranowski
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 

Guillaume Nodet

Re: Github issue migration problem

[Herve Boutemy]

if we don't copy, we can't search in one place: I'm often searching in issues 
to get why we did something in the past (that years later looks strange, but 
history helps understand)

I'd love to let some time to try before admitting we can't keep it simple in 
one single place once migrated

Regards,

Hervé

On 2025/02/05 06:35:42 Slawomir Jaranowski wrote:
> I'm still not convitient if we really need copy all issues from jira
> to github - as I wrote many times
> 
> - jira will be exist with us
> - I don't believe that users before creating new issue look for old -
> if yes they have a link to old issues
> - many issues should be triaged again - it is manually work
> 
> On Tue, 4 Feb 2025 at 23:42, Elliotte Rusty Harold  wrote:
> >
> > If you look at https://github.com/apache/maven-jlink-plugin/issues
> > you'll notice that all the issues from the Jira have been copied into
> > github multiple times.
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> 
> 
> -- 
> Sławomir Jaranowski
> 
> -
> 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

Amendment proposal to

[Martin Desruisseaux]

Hello all

Maven 4 introduced some new types of JAR, including:

 * jar (same as Maven 3)
 * modular-jar
 * classpath-jar
 * processor
 * classpath-processor
 * modular-processor

It has been pointed out (in a discussion elsewhere about JPMS) that 
declaring that a JAR is for use by the annotation processor (or doclet, 
taglet, etc.) is closer to the definition of a scope. It think that it 
is a good point. Should we remove the types listed below and replace 
them by the following (type, scope) pairs?


processor replaced by:

   jar
   processor

classpath-processor replaced by:

   classpath-jar
   processor

modular-processor replaced by:

   modular-jar
   processor

Same for doclet, taglet, etc. Therefore, "classpath-jar" and 
"modular-jar" would be the only new types relative to JPMS, and new 
scopes "processor", "doclet" and "taglet" would be added in addition of 
"main" and "test". It would reduce the total number of types/scopes (no 
need to repeat "processor" for each variant of classpath versus 
module-path) and could be related to the new  element recently 
added to the Maven 4. It could also, in a future evolution, fit nicely 
with the closely-related  element of the recently added  
element (the latter would be a separated discussion).


    Martin

Re: Amendment proposal to

[Romain Manni-Bucau]

Hi Martin,

there are still processors which are runtime jars, would you make them
declared twice and deduplicated by maven for relevant phases/scopes?

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



Le mar. 4 févr. 2025 à 14:58, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Hello all
>
> Maven 4 introduced some new types of JAR, including:
>
>   * jar (same as Maven 3)
>   * modular-jar
>   * classpath-jar
>   * processor
>   * classpath-processor
>   * modular-processor
>
> It has been pointed out (in a discussion elsewhere about JPMS) that
> declaring that a JAR is for use by the annotation processor (or doclet,
> taglet, etc.) is closer to the definition of a scope. It think that it
> is a good point. Should we remove the types listed below and replace
> them by the following (type, scope) pairs?
>
> processor replaced by:
>
> jar
> processor
>
> classpath-processor replaced by:
>
> classpath-jar
> processor
>
> modular-processor replaced by:
>
> modular-jar
> processor
>
> Same for doclet, taglet, etc. Therefore, "classpath-jar" and
> "modular-jar" would be the only new types relative to JPMS, and new
> scopes "processor", "doclet" and "taglet" would be added in addition of
> "main" and "test". It would reduce the total number of types/scopes (no
> need to repeat "processor" for each variant of classpath versus
> module-path) and could be related to the new  element recently
> added to the Maven 4. It could also, in a future evolution, fit nicely
> with the closely-related  element of the recently added 
> element (the latter would be a separated discussion).
>
>  Martin
>
>

Re: Amendment proposal to

[Martin Desruisseaux]

Le 2025-02-04 à 16 h 27, Romain Manni-Bucau a écrit :


there are still processors which are runtime jars, would you make them 
declared twice and deduplicated by maven for relevant phases/scopes?


The same JAR file which would need to be both on the class-path and on 
the annotation processor path? Yes, they would need to be declared twice 
with different scope. But I think that it is not different than the 
current situation with processor.


    Martin



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

Re: Toolchains and Maven Enforcer

[Thomas Reinhardt]

Interesting, I was not aware of the new discovery mechanism.

Unfortunately the most interesting goal "select-jdk-toolchain" is not 
marked threadsafe. Was that a conscious decision or just easier to 
implement?


Also I am missing a parameter to provide a search path. Might come in 
handy in CI environments like Jenkins.


Any opinions on the above two points? Otherwise I would just open issues 
for those.



-Thomas


On 03/02/2025 08:05, Guillaume Nodet wrote:

The toolchains discovery has been released a few months ago:

https://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/jdk-discovery.html
This is also usable in Maven 3.x.

I think that should cover your use case.
The enforcer check does not really need to be performed because the
toolchain selection
will ensure that the selected toolchain matches the input range.

Le lun. 3 févr. 2025 à 07:12, Mikko Johannes Koivunalho <
mikko.koivuna...@iki.fi> a écrit :


Hi,

I am forwarding this message to Maven Developer List.

Before getting to any development, I'd like to know more about planned
Maven4 improvements in the area of toolchains.

Thank you.


Sincerely,
Mikko Koivunalho

On 02/02/2025 19:28, Tamás Cservenák wrote:

Howdy,

TBH, I never understood why toolchains are not ALWAYS used
with one (always) available toolchain, the Java that runs Maven
itself, so this would be your fallback.

Re enforcer, yes, probably we need new rules that would behave
as you describe.

Hence, yes, this would be a good direction.

OTOH, for Maven4 we do have some improvements in this area,
like auto discovery, so any contribution is welcome!

Thanks
T

On Sun, Feb 2, 2025 at 6:35 PM Mikko Johannes Koivunalho
 wrote:

Hi,

I work with many Maven projects which require building with different
JDKs: Java 8, Java 11, Java 17, and so on. I have all these installed
side by side in my build machine.

Maven Toolchains plugin is very helpful because it prevents me from
being forced to reconfigure environment variable JAVA_HOME when I move
between Maven projects.

However, for those who only use one of those projects, configuring the
toolchains and JDKs is too complicated. They have their Java already
configured to use the correct JDK.

It would be convenient if Maven Toolchains plugin had a fallback mode:
when the file .m2/toolchains.xml is not present, i.e. the toolchains are
not configured, Maven Toolchains plugin would simply fall back to use
the same Java as Maven itself uses.

Maven Toolchains plugin could have a setting to allow the fallback. By
default, the fallback would not be allowed. This is the behavior now.


Even when using toolchains, I am also using Maven Enforcer rule
RequireJavaVersion to limit the range of usable Java versions. This rule
only tracks the version of the Java runtime Maven itself is using so it
is not compatible with Maven Toolschains.

To work with Maven Toolchains plugin and remain backwards compatible,
Maven Enforcer would need a new rule, maybe
"RequireJDKVersion", "RequireToolchainJavaVersion" or
"RequireJavaCompilerVersion". It would also have to work with the
fallback mode as described above.


Would the above be the right direction to develop Maven Toolchains?
Thanks for all comments.


Sincerely,
Mikko Koivunalho


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


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



--
Mikko Koivunalho


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







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

Re: [VOTE] Release Maven Resolver Ant Tasks 1.5.2

[Tamás Cservenák]

+1

On Sun, Feb 2, 2025 at 4:22 PM Tamás Cservenák  wrote:
>
> Howdy,
>
> We solved 5 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628&version=12354742
>
> There is one issue in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20%22Ant%20Tasks%22
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-2263/
>
> Source release SHA512:
> 033c4966c110083419209b1b46805c8eb8dcfd33369862edb7c74a75c4f382fd8a5756e0eaf215964c68d6fed9248ce046aad86f27cf0098b95ffb316a89aa85
>
> Staging site:
> https://maven.apache.org/resolver-archives/resolver-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1

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

Re: [VOTE] Release Maven Resolver Ant Tasks 1.5.2

[Slawomir Jaranowski]

+1

On Sun, 2 Feb 2025 at 16:22, Tamás Cservenák  wrote:
>
> Howdy,
>
> We solved 5 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628&version=12354742
>
> There is one issue in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20%22Ant%20Tasks%22
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-2263/
>
> Source release SHA512:
> 033c4966c110083419209b1b46805c8eb8dcfd33369862edb7c74a75c4f382fd8a5756e0eaf215964c68d6fed9248ce046aad86f27cf0098b95ffb316a89aa85
>
> Staging site:
> https://maven.apache.org/resolver-archives/resolver-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Sławomir Jaranowski

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

Re: Amendment proposal to

[Romain Manni-Bucau]

Hmm, ok, just means we should maybe rush in supporting type or scope sets
in plugins instead of having so much hardcoded defaults cause these are
common cases (similarly having an artifact available for some compiling
execution, some build plugin but nothing else).

Thanks for confirming.

Le mar. 4 févr. 2025 à 17:54, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Le 2025-02-04 à 16 h 27, Romain Manni-Bucau a écrit :
> >
> > there are still processors which are runtime jars, would you make them
> > declared twice and deduplicated by maven for relevant phases/scopes?
> >
> The same JAR file which would need to be both on the class-path and on
> the annotation processor path? Yes, they would need to be declared twice
> with different scope. But I think that it is not different than the
> current situation with processor.
>
>  Martin
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Github issue migration problem

[Elliotte Rusty Harold]

If you look at https://github.com/apache/maven-jlink-plugin/issues
you'll notice that all the issues from the Jira have been copied into
github multiple times.

-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Maven plugins: compiler, install, deploy - GitHub Issues

[Slawomir Jaranowski]

Hi,

I will be working on compiler, install, deploy plugins to prepare and
switch to GitHub issues ...

First I will fix release-drafter configuration such we maintain two version
 - master for Maven 4.x
 - branch for Maven 3.x

Probably I need disable jenkins on master due to missing Maven beta,
rc installation on jenkins

Finally I will prepare PR which enable GitHub issues

Will be appreciated if someone else look at PR and result, if no I
will simply merge as technical tasks

-- 
Sławomir Jaranowski

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

Re: [VOTE] Release Maven Resolver Ant Tasks 1.5.2

[Olivier Lamy]

+1
On Mon, 3 Feb 2025 at 1:22 am, Tamás Cservenák  wrote:

> Howdy,
>
> We solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628&version=12354742
>
> There is one issue in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20%22Ant%20Tasks%22
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-2263/
>
> Source release SHA512:
>
> 033c4966c110083419209b1b46805c8eb8dcfd33369862edb7c74a75c4f382fd8a5756e0eaf215964c68d6fed9248ce046aad86f27cf0098b95ffb316a89aa85
>
> Staging site:
> https://maven.apache.org/resolver-archives/resolver-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Resolver Ant Tasks 1.5.2

[Sylwester Lachiewicz]

+1

wt., 4 lut 2025, 21:49 użytkownik Olivier Lamy  napisał:

> +1
> On Mon, 3 Feb 2025 at 1:22 am, Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > We solved 5 issues:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628&version=12354742
> >
> > There is one issue in JIRA:
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20%22Ant%20Tasks%22
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/maven-2263/
> >
> > Source release SHA512:
> >
> >
> 033c4966c110083419209b1b46805c8eb8dcfd33369862edb7c74a75c4f382fd8a5756e0eaf215964c68d6fed9248ce046aad86f27cf0098b95ffb316a89aa85
> >
> > Staging site:
> > https://maven.apache.org/resolver-archives/resolver-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Toolchains and Maven Enforcer

[Romain Manni-Bucau]

Hi,

The discovery uses JAVA_xx_HOME environment variables which is often the
way CI are setting up the paths - ack not on jenkins if not done manually
but it is not a bad practise.
I assume adding a property to configure yet another search path (
https://github.com/apache/maven-toolchains-plugin/blob/master/src/main/java/org/apache/maven/plugins/toolchain/jdk/ToolchainDiscoverer.java#L421)
is doable but I'm not sure it would enable any real use case except manual
setups.
On jenkins the common practise for JDK installers is to write the toolchain
and provide it to jobs for a working out of the box experience so maybe
your setup is not complete on this part?

About thread safety it is mainly about writing the toolchain discovery
result xml file so the easiest is to run it alone with a profile of your
project then ignore it totally for the actual build.
It is rather a good practise since the discovery is not free when you have
a lot of jdk installed (multi vendors+versions validation for ex).
Here again we can likely make it pomless to ease CI integration if it would
help or lock a sibling file but your use case is already covered IMHO.

So while I think both requests can be done it ca be worth investing a few
minutes tuning the jenkins usage to see if normalizing the setup will not
give more benefit than updating tools - not everything uses toolchain and
several external plugins still need explicit binary path so having the
JAVA_xx_HOME variables defaulting to JAVA_HOME in the pom is always a
better practise IMHO.

Hope it makes sense

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



Le mar. 4 févr. 2025 à 09:05, Thomas Reinhardt  a
écrit :

>
> Interesting, I was not aware of the new discovery mechanism.
>
> Unfortunately the most interesting goal "select-jdk-toolchain" is not
> marked threadsafe. Was that a conscious decision or just easier to
> implement?
>
> Also I am missing a parameter to provide a search path. Might come in
> handy in CI environments like Jenkins.
>
> Any opinions on the above two points? Otherwise I would just open issues
> for those.
>
>
> -Thomas
>
>
> On 03/02/2025 08:05, Guillaume Nodet wrote:
> > The toolchains discovery has been released a few months ago:
> >
> >
> https://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/jdk-discovery.html
> > This is also usable in Maven 3.x.
> >
> > I think that should cover your use case.
> > The enforcer check does not really need to be performed because the
> > toolchain selection
> > will ensure that the selected toolchain matches the input range.
> >
> > Le lun. 3 févr. 2025 à 07:12, Mikko Johannes Koivunalho <
> > mikko.koivuna...@iki.fi> a écrit :
> >
> >> Hi,
> >>
> >> I am forwarding this message to Maven Developer List.
> >>
> >> Before getting to any development, I'd like to know more about planned
> >> Maven4 improvements in the area of toolchains.
> >>
> >> Thank you.
> >>
> >>
> >> Sincerely,
> >> Mikko Koivunalho
> >>
> >> On 02/02/2025 19:28, Tamás Cservenák wrote:
> >>> Howdy,
> >>>
> >>> TBH, I never understood why toolchains are not ALWAYS used
> >>> with one (always) available toolchain, the Java that runs Maven
> >>> itself, so this would be your fallback.
> >>>
> >>> Re enforcer, yes, probably we need new rules that would behave
> >>> as you describe.
> >>>
> >>> Hence, yes, this would be a good direction.
> >>>
> >>> OTOH, for Maven4 we do have some improvements in this area,
> >>> like auto discovery, so any contribution is welcome!
> >>>
> >>> Thanks
> >>> T
> >>>
> >>> On Sun, Feb 2, 2025 at 6:35 PM Mikko Johannes Koivunalho
> >>>  wrote:
>  Hi,
> 
>  I work with many Maven projects which require building with different
>  JDKs: Java 8, Java 11, Java 17, and so on. I have all these installed
>  side by side in my build machine.
> 
>  Maven Toolchains plugin is very helpful because it prevents me from
>  being forced to reconfigure environment variable JAVA_HOME when I move
>  between Maven projects.
> 
>  However, for those who only use one of those projects, configuring the
>  toolchains and JDKs is too complicated. They have their Java already
>  configured to use the correct JDK.
> 
>  It would be convenient if Maven Toolchains plugin had a fallback mode:
>  when the file .m2/toolchains.xml is not present, i.e. the toolchains
> are
>  not configured, Maven Toolchains plugin would simply fall back to use
>  the same Java as Maven itself uses.
> 
>  Maven Toolchains plugin could have a setting to allow the fallback. By
>  default, the fallback would not be allowed. This is the behavior now.