[jira] [Created] (MRESOLVER-299) Make native transport pick up HTTP headers as Wagon

[Tamas Cservenak (Jira)]

Tamas Cservenak created MRESOLVER-299:
-

 Summary: Make native transport pick up HTTP headers as Wagon
 Key: MRESOLVER-299
 URL: https://issues.apache.org/jira/browse/MRESOLVER-299
 Project: Maven Resolver
  Issue Type: Improvement
  Components: Resolver
Reporter: Tamas Cservenak
 Fix For: 1.9.3


This would be "one step back" (use of Plexus XML) as currently Maven offers no 
other way to set custom HTTP Headers, while it may be important to some users 
(to differentiate requests).

Hint: example code doing it is here

https://github.com/takari/aether-connector-okhttp/blob/master/src/main/java/io/takari/aether/connector/AetherRepositoryConnector.java#L207-L240



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [maven-integration-testing] cstamas commented on pull request #215: [MNG-7608] Make ITs aware of transport change

[GitBox]

cstamas commented on PR #215:
URL: 
https://github.com/apache/maven-integration-testing/pull/215#issuecomment-1334853295

   Superseded by https://github.com/apache/maven-integration-testing/pull/216


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MNG-7608) Make Resolver native transport the default in Maven4

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642326#comment-17642326
 ] 

ASF GitHub Bot commented on MNG-7608:
-

cstamas opened a new pull request, #892:
URL: https://github.com/apache/maven/pull/892

   This immediately cuts in "half" the count of HTTP requests against Maven 
Central or any major MRM.
   
   Altering the meaning of "default": is now same as "auto", but still leaving 
it in place for future, as "default" at some point may again become something 
different than "native".
   
   ---
   
   https://issues.apache.org/jira/browse/MNG-7608




> Make Resolver native transport the default in Maven4
> 
>
> Key: MNG-7608
> URL: https://issues.apache.org/jira/browse/MNG-7608
> Project: Maven
>  Issue Type: Improvement
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate, 4.0.0
>
>
> The ancient Wagon should be phased out, and "native" resolver transport 
> should be the default in Maven4. This in start halves the HTTP request count 
> toward Maven Central and any major MRM.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MNG-7608) Make Resolver native transport the default in Maven4

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642328#comment-17642328
 ] 

ASF GitHub Bot commented on MNG-7608:
-

cstamas closed pull request #885: [MNG-7608] Make native resolver transport the 
m4 default.
URL: https://github.com/apache/maven/pull/885




> Make Resolver native transport the default in Maven4
> 
>
> Key: MNG-7608
> URL: https://issues.apache.org/jira/browse/MNG-7608
> Project: Maven
>  Issue Type: Improvement
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate, 4.0.0
>
>
> The ancient Wagon should be phased out, and "native" resolver transport 
> should be the default in Maven4. This in start halves the HTTP request count 
> toward Maven Central and any major MRM.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MNG-7608) Make Resolver native transport the default in Maven4

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642327#comment-17642327
 ] 

ASF GitHub Bot commented on MNG-7608:
-

cstamas commented on PR #885:
URL: https://github.com/apache/maven/pull/885#issuecomment-1334853097

   Superseded by https://github.com/apache/maven/pull/892




> Make Resolver native transport the default in Maven4
> 
>
> Key: MNG-7608
> URL: https://issues.apache.org/jira/browse/MNG-7608
> Project: Maven
>  Issue Type: Improvement
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate, 4.0.0
>
>
> The ancient Wagon should be phased out, and "native" resolver transport 
> should be the default in Maven4. This in start halves the HTTP request count 
> toward Maven Central and any major MRM.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [maven-integration-testing] cstamas closed pull request #215: [MNG-7608] Make ITs aware of transport change

[GitBox]

cstamas closed pull request #215: [MNG-7608] Make ITs aware of transport change
URL: https://github.com/apache/maven-integration-testing/pull/215


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] cstamas closed pull request #885: [MNG-7608] Make native resolver transport the m4 default.

[GitBox]

cstamas closed pull request #885: [MNG-7608] Make native resolver transport the 
m4 default.
URL: https://github.com/apache/maven/pull/885


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] cstamas commented on pull request #885: [MNG-7608] Make native resolver transport the m4 default.

[GitBox]

cstamas commented on PR #885:
URL: https://github.com/apache/maven/pull/885#issuecomment-1334853097

   Superseded by https://github.com/apache/maven/pull/892


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] cstamas opened a new pull request, #892: [MNG-7608] Make native transport the default

[GitBox]

cstamas opened a new pull request, #892:
URL: https://github.com/apache/maven/pull/892

   This immediately cuts in "half" the count of HTTP requests against Maven 
Central or any major MRM.
   
   Altering the meaning of "default": is now same as "auto", but still leaving 
it in place for future, as "default" at some point may again become something 
different than "native".
   
   ---
   
   https://issues.apache.org/jira/browse/MNG-7608


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-integration-testing] cstamas opened a new pull request, #216: MNG-7608] Make native transport the default

[GitBox]

cstamas opened a new pull request, #216:
URL: https://github.com/apache/maven-integration-testing/pull/216

   Make ITs not blindly expect Wagon as transport, but be aware of change.
   
   ---
   
   https://issues.apache.org/jira/browse/MNG-7608


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-script-interpreter] olamy merged pull request #85: ci builds both with jdk 19

[GitBox]

olamy merged PR #85:
URL: https://github.com/apache/maven-script-interpreter/pull/85


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-script-interpreter] olamy opened a new pull request, #85: ci builds both with jdk 19

[GitBox]

olamy opened a new pull request, #85:
URL: https://github.com/apache/maven-script-interpreter/pull/85

   Signed-off-by: Olivier Lamy 
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Assigned] (MINVOKER-312) Upgrade Groovy to 4.x

[Olivier Lamy (Jira)]

 [ 
https://issues.apache.org/jira/browse/MINVOKER-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy reassigned MINVOKER-312:
-

Assignee: Olivier Lamy

> Upgrade Groovy to 4.x
> -
>
> Key: MINVOKER-312
> URL: https://issues.apache.org/jira/browse/MINVOKER-312
> Project: Maven Invoker Plugin
>  Issue Type: Dependency upgrade
>Reporter: Slawomir Jaranowski
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.4.0
>
>
> Groovy 3.x does not support JDK 19 - GROOVY-10782
> We need Groovy 4.x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [maven-invoker-plugin] olamy opened a new pull request, #154: change to groovy to groupId org.apache.groovy and bump version

[GitBox]

olamy opened a new pull request, #154:
URL: https://github.com/apache/maven-invoker-plugin/pull/154

   Signed-off-by: Olivier Lamy 
   
   Following this checklist to help us incorporate your 
   contribution quickly and easily:
   
- [ ] Make sure there is a [JIRA 
issue](https://issues.apache.org/jira/browse/MINVOKER) filed 
  for the change (usually before you start working on it).  Trivial 
changes like typos do not 
  require a JIRA issue.  Your pull request should address just this 
issue, without 
  pulling in other changes.
- [ ] Each commit in the pull request should have a meaningful subject line 
and body.
- [ ] Format the pull request title like `[MINVOKER-XXX] - Fixes bug in 
ApproximateQuantiles`,
  where you replace `MINVOKER-XXX` with the appropriate JIRA issue. 
Best practice
  is to use the JIRA issue title in the pull request title and in the 
first line of the 
  commit message.
- [ ] Write a pull request description that is detailed enough to 
understand what the pull request does, how, and why.
- [ ] Run `mvn clean verify` to make sure basic checks pass. A more 
thorough check will 
  be performed on your pull request automatically.
- [ ] You have run the integration tests successfully (`mvn -Prun-its clean 
verify`).
   
   If your pull request is about ~20 lines of code you don't need to sign an
   [Individual Contributor License 
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
   please ask on the developers list.
   
   To make clear that you license your contribution under 
   the [Apache License Version 2.0, January 
2004](http://www.apache.org/licenses/LICENSE-2.0)
   you have to acknowledge this by using the following check-box.
   
- [ ] I hereby declare this contribution to be licenced under the [Apache 
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   
- [ ] In any other case, please file an [Apache Individual Contributor 
License Agreement](https://www.apache.org/licenses/icla.pdf).
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-enforcer] fdfea commented on pull request #136: [MENFORCER-411] DependencyConvergence takes include/exclude parameters to filter errors

[GitBox]

fdfea commented on PR #136:
URL: https://github.com/apache/maven-enforcer/pull/136#issuecomment-1334697686

   @slawekjaranowski Updated


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-script-interpreter] olamy commented on pull request #83: Bump maven-shared-components from 37 to 38

[GitBox]

olamy commented on PR #83:
URL: 
https://github.com/apache/maven-script-interpreter/pull/83#issuecomment-1334671669

   If it's only the site report who really cares as long as the build pass...


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Updated] (MDEP-840) Unused declared dependencies found but dependency is used?

[Joe Barnett (Jira)]

 [ 
https://issues.apache.org/jira/browse/MDEP-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joe Barnett updated MDEP-840:
-
Description: 
We have a class here: 
[https://github.com/trib3/leakycauldron/blob/main/testing/src/main/kotlin/com/trib3/testing/server/ResourceTestBase.kt]

 

that imports io.dropwizard.auth.AuthValueFactoryProvider from 
io.dropwizard:dropwizard-auth, and the pom declares that dependency directly.

 

Starting with maven-dependency-plugin 3.4.0, we now get this error when running 
the analyze-only goal:
{code:java}
[ERROR] Unused declared dependencies found:
[ERROR]    io.dropwizard:dropwizard-auth:jar:2.1.4:compile{code}
 

removing the declared dependency results in the code failing to compile since 
dropwizard-auth is no longer on the classpath.  This worked in 3.3.0.

  was:
We have a class here: 
[https://github.com/trib3/leakycauldron/blob/main/testing/src/main/kotlin/com/trib3/testing/server/ResourceTestBase.kt]

 

that imports io.dropwizard.auth.AuthValueFactoryProvider from 
io.dropwizard:dropwizard-auth, and the pom imports that dependency directly.

 

Starting with maven-dependency-plugin 3.4.0, we now get this error when running 
the analyze-only goal:
{code:java}
[ERROR] Unused declared dependencies found:
[ERROR]    io.dropwizard:dropwizard-auth:jar:2.1.4:compile{code}
 

removing the declared dependency results in the code failing to compile since 
dropwizard-auth is no longer on the classpath.  This worked in 3.3.0.


> Unused declared dependencies found but dependency is used? 
> ---
>
> Key: MDEP-840
> URL: https://issues.apache.org/jira/browse/MDEP-840
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: analyze-only
>Affects Versions: 3.4.0
>Reporter: Joe Barnett
>Priority: Major
>
> We have a class here: 
> [https://github.com/trib3/leakycauldron/blob/main/testing/src/main/kotlin/com/trib3/testing/server/ResourceTestBase.kt]
>  
> that imports io.dropwizard.auth.AuthValueFactoryProvider from 
> io.dropwizard:dropwizard-auth, and the pom declares that dependency directly.
>  
> Starting with maven-dependency-plugin 3.4.0, we now get this error when 
> running the analyze-only goal:
> {code:java}
> [ERROR] Unused declared dependencies found:
> [ERROR]    io.dropwizard:dropwizard-auth:jar:2.1.4:compile{code}
>  
> removing the declared dependency results in the code failing to compile since 
> dropwizard-auth is no longer on the classpath.  This worked in 3.3.0.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MDEP-840) Unused declared dependencies found but dependency is used?

[Joe Barnett (Jira)]

Joe Barnett created MDEP-840:


 Summary: Unused declared dependencies found but dependency is 
used? 
 Key: MDEP-840
 URL: https://issues.apache.org/jira/browse/MDEP-840
 Project: Maven Dependency Plugin
  Issue Type: Bug
  Components: analyze-only
Affects Versions: 3.4.0
Reporter: Joe Barnett


We have a class here: 
[https://github.com/trib3/leakycauldron/blob/main/testing/src/main/kotlin/com/trib3/testing/server/ResourceTestBase.kt]

 

that imports io.dropwizard.auth.AuthValueFactoryProvider from 
io.dropwizard:dropwizard-auth, and the pom imports that dependency directly.

 

Starting with maven-dependency-plugin 3.4.0, we now get this error when running 
the analyze-only goal:
{code:java}
[ERROR] Unused declared dependencies found:
[ERROR]    io.dropwizard:dropwizard-auth:jar:2.1.4:compile{code}
 

removing the declared dependency results in the code failing to compile since 
dropwizard-auth is no longer on the classpath.  This worked in 3.3.0.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [maven] slawekjaranowski opened a new pull request, #891: Mng 7613

[GitBox]

slawekjaranowski opened a new pull request, #891:
URL: https://github.com/apache/maven/pull/891

   Following this checklist to help us incorporate your
   contribution quickly and easily:
   
- [x] Make sure there is a [JIRA 
issue](https://issues.apache.org/jira/browse/MNG) filed
  for the change (usually before you start working on it).  Trivial 
changes like typos do not
  require a JIRA issue. Your pull request should address just this 
issue, without
  pulling in other changes.
- [x] Each commit in the pull request should have a meaningful subject line 
and body.
- [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you 
replace `MNG-XXX`
  and `SUMMARY` with the appropriate JIRA issue. Best practice is to 
use the JIRA issue
  title in the pull request title and in the first line of the commit 
message.
- [ ] Write a pull request description that is detailed enough to 
understand what the pull request does, how, and why.
- [x] Run `mvn clean verify` to make sure basic checks pass. A more 
thorough check will
  be performed on your pull request automatically.
- [x] You have run the [Core IT][core-its] successfully.
   
   If your pull request is about ~20 lines of code you don't need to sign an
   [Individual Contributor License 
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
   please ask on the developers list.
   
   To make clear that you license your contribution under
   the [Apache License Version 2.0, January 
2004](http://www.apache.org/licenses/LICENSE-2.0)
   you have to acknowledge this by using the following check-box.
   
- [x] I hereby declare this contribution to be licenced under the [Apache 
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   
- [x] In any other case, please file an [Apache Individual Contributor 
License Agreement](https://www.apache.org/licenses/icla.pdf).
   
   [core-its]: https://maven.apache.org/core-its/core-it-suite/
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Created] (MNG-7613) Upgrade Apache Maven parent POM to version 38

[Slawomir Jaranowski (Jira)]

Slawomir Jaranowski created MNG-7613:


 Summary: Upgrade Apache Maven parent POM to version 38
 Key: MNG-7613
 URL: https://issues.apache.org/jira/browse/MNG-7613
 Project: Maven
  Issue Type: Dependency upgrade
Reporter: Slawomir Jaranowski
Assignee: Slawomir Jaranowski
 Fix For: 3.9.0






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [maven-invoker-plugin] dependabot[bot] merged pull request #149: Bump plexus-utils from 3.4.2 to 3.5.0

[GitBox]

dependabot[bot] merged PR #149:
URL: https://github.com/apache/maven-invoker-plugin/pull/149


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-invoker-plugin] dependabot[bot] merged pull request #150: Bump mockito-core from 4.6.1 to 4.9.0

[GitBox]

dependabot[bot] merged PR #150:
URL: https://github.com/apache/maven-invoker-plugin/pull/150


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Updated] (MPOM-371) Fix checkstyle configuration

[Slawomir Jaranowski (Jira)]

 [ 
https://issues.apache.org/jira/browse/MPOM-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Slawomir Jaranowski updated MPOM-371:
-
Description: 
We have new checkstyle configuration in shared-resource but old one is used.

 Old configuration cause that checkstyle report contains many errors.

  was:We have new checkstyle configuration in shared-resource but old one is 
used.


> Fix checkstyle configuration
> 
>
> Key: MPOM-371
> URL: https://issues.apache.org/jira/browse/MPOM-371
> Project: Maven POMs
>  Issue Type: Bug
>  Components: maven
>Affects Versions: MAVEN-38
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Critical
> Fix For: MAVEN-39
>
>
> We have new checkstyle configuration in shared-resource but old one is used.
>  Old configuration cause that checkstyle report contains many errors.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [maven-script-interpreter] slawekjaranowski commented on pull request #83: Bump maven-shared-components from 37 to 38

[GitBox]

slawekjaranowski commented on PR #83:
URL: 
https://github.com/apache/maven-script-interpreter/pull/83#issuecomment-1334515384

   Please check output of checkstyle report in site 
   https://issues.apache.org/jira/browse/MPOM-371


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-script-interpreter] olamy merged pull request #83: Bump maven-shared-components from 37 to 38

[GitBox]

olamy merged PR #83:
URL: https://github.com/apache/maven-script-interpreter/pull/83


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MNG-7612) Chained Local Repository

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642190#comment-17642190
 ] 

ASF GitHub Bot commented on MNG-7612:
-

slawekjaranowski closed pull request #889: [MNG-7612] Chained LRM
URL: https://github.com/apache/maven/pull/889




> Chained Local Repository 
> -
>
> Key: MNG-7612
> URL: https://issues.apache.org/jira/browse/MNG-7612
> Project: Maven
>  Issue Type: New Feature
>  Components: Artifacts and Repositories
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> New feature: Chained Local Repository Manager (CLRM).
> This new feature is not something one would use in production, is more 
> targeted to Integration Test isolation.
> User story: ITs usually are run as part of Maven build – lets call it "outer 
> build" – that may build among other things, plugins and some artifacts needed 
> for the ITs. The ITs itself – let's call them "inner build" – should run in 
> isolated environment.
> Problem: the "outer build" is usually affected by user environment 
> (settings.xml, use of MRM, and may use user own local repository unless 
> alternate specified) but also we do not want user MRM to be altered by IT 
> runs. The "inner build" on the other hand, may fail if use same LRM as "outer 
> build", as they are isolated, so they do not use settings.xml from the outer 
> build, may not use MRM and same remote repository IDs, and all these may lead 
> to mysterious "artifact not found" problems. Typically,  outer build may use 
> MRM that defines mirrorOf with ID "my-mrm", while inner would use defaults, 
> where only remote repository is "central": this leads that user LRM gets 
> populated with artifacts available from "my-mrm" remote repository, while 
> inner build would know only about "central" remote repository. Enhanced LRM 
> (default since Maven 3.0) would refuse to serve up these artifacts.
> Solution is CLRM: with CLRM user is able to specify isolated LRM for ITs, 
> while still making artifacts from outer LRM "visible" (discoverable) for the 
> IT build. Inner build uses isolated LRM solely, but for resolution purposes 
> still is able to resolve from outer LRM, where outer build might deployed 
> artifacts, plugins used by IT inner build.
> Technical remark: CLRM defines "head" LRM, and list of LRM as "tail". Almost 
> all methods are delegated toward "head", except for find methods (metadata 
> and artifact), exposing tail LRM contents for artifact resolution. Also, CLRM 
> is *able* to enforce artifact availability (as explained above), but in most 
> cases (at least in IT user story), one would want to inhibit this.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MNG-7612) Chained Local Repository

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642189#comment-17642189
 ] 

ASF GitHub Bot commented on MNG-7612:
-

slawekjaranowski commented on PR #889:
URL: https://github.com/apache/maven/pull/889#issuecomment-1334502021

   suppressed by #890




> Chained Local Repository 
> -
>
> Key: MNG-7612
> URL: https://issues.apache.org/jira/browse/MNG-7612
> Project: Maven
>  Issue Type: New Feature
>  Components: Artifacts and Repositories
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> New feature: Chained Local Repository Manager (CLRM).
> This new feature is not something one would use in production, is more 
> targeted to Integration Test isolation.
> User story: ITs usually are run as part of Maven build – lets call it "outer 
> build" – that may build among other things, plugins and some artifacts needed 
> for the ITs. The ITs itself – let's call them "inner build" – should run in 
> isolated environment.
> Problem: the "outer build" is usually affected by user environment 
> (settings.xml, use of MRM, and may use user own local repository unless 
> alternate specified) but also we do not want user MRM to be altered by IT 
> runs. The "inner build" on the other hand, may fail if use same LRM as "outer 
> build", as they are isolated, so they do not use settings.xml from the outer 
> build, may not use MRM and same remote repository IDs, and all these may lead 
> to mysterious "artifact not found" problems. Typically,  outer build may use 
> MRM that defines mirrorOf with ID "my-mrm", while inner would use defaults, 
> where only remote repository is "central": this leads that user LRM gets 
> populated with artifacts available from "my-mrm" remote repository, while 
> inner build would know only about "central" remote repository. Enhanced LRM 
> (default since Maven 3.0) would refuse to serve up these artifacts.
> Solution is CLRM: with CLRM user is able to specify isolated LRM for ITs, 
> while still making artifacts from outer LRM "visible" (discoverable) for the 
> IT build. Inner build uses isolated LRM solely, but for resolution purposes 
> still is able to resolve from outer LRM, where outer build might deployed 
> artifacts, plugins used by IT inner build.
> Technical remark: CLRM defines "head" LRM, and list of LRM as "tail". Almost 
> all methods are delegated toward "head", except for find methods (metadata 
> and artifact), exposing tail LRM contents for artifact resolution. Also, CLRM 
> is *able* to enforce artifact availability (as explained above), but in most 
> cases (at least in IT user story), one would want to inhibit this.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MNG-7612) Chained Local Repository

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642188#comment-17642188
 ] 

ASF GitHub Bot commented on MNG-7612:
-

slawekjaranowski opened a new pull request, #890:
URL: https://github.com/apache/maven/pull/890

   Adds new feature: Chained Local Repository Manager.
   
   ---
   
   https://issues.apache.org/jira/browse/MNG-7612
   
   Following this checklist to help us incorporate your
   contribution quickly and easily:
   
- [x] Make sure there is a [JIRA 
issue](https://issues.apache.org/jira/browse/MNG) filed
  for the change (usually before you start working on it).  Trivial 
changes like typos do not
  require a JIRA issue. Your pull request should address just this 
issue, without
  pulling in other changes.
- [x] Each commit in the pull request should have a meaningful subject line 
and body.
- [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you 
replace `MNG-XXX`
  and `SUMMARY` with the appropriate JIRA issue. Best practice is to 
use the JIRA issue
  title in the pull request title and in the first line of the commit 
message.
- [x] Write a pull request description that is detailed enough to 
understand what the pull request does, how, and why.
- [x] Run `mvn clean verify` to make sure basic checks pass. A more 
thorough check will
  be performed on your pull request automatically.
- [x] You have run the [Core IT][core-its] successfully.
   
   If your pull request is about ~20 lines of code you don't need to sign an
   [Individual Contributor License 
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
   please ask on the developers list.
   
   To make clear that you license your contribution under
   the [Apache License Version 2.0, January 
2004](http://www.apache.org/licenses/LICENSE-2.0)
   you have to acknowledge this by using the following check-box.
   
- [x] I hereby declare this contribution to be licenced under the [Apache 
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   
- [x] In any other case, please file an [Apache Individual Contributor 
License Agreement](https://www.apache.org/licenses/icla.pdf).
   
   [core-its]: https://maven.apache.org/core-its/core-it-suite/
   




> Chained Local Repository 
> -
>
> Key: MNG-7612
> URL: https://issues.apache.org/jira/browse/MNG-7612
> Project: Maven
>  Issue Type: New Feature
>  Components: Artifacts and Repositories
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> New feature: Chained Local Repository Manager (CLRM).
> This new feature is not something one would use in production, is more 
> targeted to Integration Test isolation.
> User story: ITs usually are run as part of Maven build – lets call it "outer 
> build" – that may build among other things, plugins and some artifacts needed 
> for the ITs. The ITs itself – let's call them "inner build" – should run in 
> isolated environment.
> Problem: the "outer build" is usually affected by user environment 
> (settings.xml, use of MRM, and may use user own local repository unless 
> alternate specified) but also we do not want user MRM to be altered by IT 
> runs. The "inner build" on the other hand, may fail if use same LRM as "outer 
> build", as they are isolated, so they do not use settings.xml from the outer 
> build, may not use MRM and same remote repository IDs, and all these may lead 
> to mysterious "artifact not found" problems. Typically,  outer build may use 
> MRM that defines mirrorOf with ID "my-mrm", while inner would use defaults, 
> where only remote repository is "central": this leads that user LRM gets 
> populated with artifacts available from "my-mrm" remote repository, while 
> inner build would know only about "central" remote repository. Enhanced LRM 
> (default since Maven 3.0) would refuse to serve up these artifacts.
> Solution is CLRM: with CLRM user is able to specify isolated LRM for ITs, 
> while still making artifacts from outer LRM "visible" (discoverable) for the 
> IT build. Inner build uses isolated LRM solely, but for resolution purposes 
> still is able to resolve from outer LRM, where outer build might deployed 
> artifacts, plugins used by IT inner build.
> Technical remark: CLRM defines "head" LRM, and list of LRM as "tail". Almost 
> all methods are delegated toward "head", except for find methods (metadata 
> and artifact), exposing tail LRM contents for artifact resolution. Also, CLRM 
> is *able* to enforce artifact availability (as explained above), but in most 
> cases (at least in IT user story), one would want to inhibit this.



--
This message was sent by 

[GitHub] [maven] slawekjaranowski closed pull request #889: [MNG-7612] Chained LRM

[GitBox]

slawekjaranowski closed pull request #889: [MNG-7612] Chained LRM
URL: https://github.com/apache/maven/pull/889


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] slawekjaranowski commented on pull request #889: [MNG-7612] Chained LRM

[GitBox]

slawekjaranowski commented on PR #889:
URL: https://github.com/apache/maven/pull/889#issuecomment-1334502021

   suppressed by #890


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] slawekjaranowski opened a new pull request, #890: [MNG-7612] Chained LRM

[GitBox]

slawekjaranowski opened a new pull request, #890:
URL: https://github.com/apache/maven/pull/890

   Adds new feature: Chained Local Repository Manager.
   
   ---
   
   https://issues.apache.org/jira/browse/MNG-7612
   
   Following this checklist to help us incorporate your
   contribution quickly and easily:
   
- [x] Make sure there is a [JIRA 
issue](https://issues.apache.org/jira/browse/MNG) filed
  for the change (usually before you start working on it).  Trivial 
changes like typos do not
  require a JIRA issue. Your pull request should address just this 
issue, without
  pulling in other changes.
- [x] Each commit in the pull request should have a meaningful subject line 
and body.
- [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you 
replace `MNG-XXX`
  and `SUMMARY` with the appropriate JIRA issue. Best practice is to 
use the JIRA issue
  title in the pull request title and in the first line of the commit 
message.
- [x] Write a pull request description that is detailed enough to 
understand what the pull request does, how, and why.
- [x] Run `mvn clean verify` to make sure basic checks pass. A more 
thorough check will
  be performed on your pull request automatically.
- [x] You have run the [Core IT][core-its] successfully.
   
   If your pull request is about ~20 lines of code you don't need to sign an
   [Individual Contributor License 
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
   please ask on the developers list.
   
   To make clear that you license your contribution under
   the [Apache License Version 2.0, January 
2004](http://www.apache.org/licenses/LICENSE-2.0)
   you have to acknowledge this by using the following check-box.
   
- [x] I hereby declare this contribution to be licenced under the [Apache 
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   
- [x] In any other case, please file an [Apache Individual Contributor 
License Agreement](https://www.apache.org/licenses/icla.pdf).
   
   [core-its]: https://maven.apache.org/core-its/core-it-suite/
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MNG-7596) Upgrade to plexus-utils 3.5.0

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642181#comment-17642181
 ] 

Hudson commented on MNG-7596:
-

Build succeeded in Jenkins: Maven » Maven TLP » maven » master #142

See 
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/142/

> Upgrade to plexus-utils 3.5.0
> -
>
> Key: MNG-7596
> URL: https://issues.apache.org/jira/browse/MNG-7596
> Project: Maven
>  Issue Type: Dependency upgrade
>Reporter: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-3
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MNG-6609) Profile activation by packaging

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642180#comment-17642180
 ] 

Hudson commented on MNG-6609:
-

Build succeeded in Jenkins: Maven » Maven TLP » maven » master #141

See 
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/141/

> Profile activation by packaging 
> 
>
> Key: MNG-6609
> URL: https://issues.apache.org/jira/browse/MNG-6609
> Project: Maven
>  Issue Type: Improvement
>  Components: Profiles
>Affects Versions: 3.6.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> Due to the lack of mixins, it is common that modules which use different 
> packagings share the same parent pom. As those often use different 
> dependencies/plugins, it would be nice to have profiles which are activated 
> based on the packaging of a module. That is currently not possible.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MNG-7611) java.lang.IllegalStateException: Required Java version 1.8 is not met by current version: 17.0.5

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642179#comment-17642179
 ] 

Hudson commented on MNG-7611:
-

Build succeeded in Jenkins: Maven » Maven TLP » maven » master #141

See 
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/141/

> java.lang.IllegalStateException: Required Java version 1.8 is not met by 
> current version: 17.0.5
> 
>
> Key: MNG-7611
> URL: https://issues.apache.org/jira/browse/MNG-7611
> Project: Maven
>  Issue Type: Task
>Reporter: Guillaume Nodet
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 4.0.0-alpha-3
>
>
> {code:java}
> Caused by: java.lang.IllegalStateException: Required Java version 1.8 is not 
> met by current version: 17.0.5
>at 
> org.apache.maven.plugin.internal.MavenPluginJavaPrerequisiteChecker.accept(MavenPluginJavaPrerequisiteChecker.java:38)
>at 
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.lambda$checkPrerequisites$1(DefaultMavenPluginManager.java:289)
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [maven-script-interpreter] olamy merged pull request #84: Add release drafter

[GitBox]

olamy merged PR #84:
URL: https://github.com/apache/maven-script-interpreter/pull/84


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-script-interpreter] olamy opened a new pull request, #84: Add release drafter

[GitBox]

olamy opened a new pull request, #84:
URL: https://github.com/apache/maven-script-interpreter/pull/84

   Signed-off-by: Olivier Lamy 
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-project-info-reports-plugin] michael-o closed pull request #39: Preparation for Doxia 2.0.0

[GitBox]

michael-o closed pull request #39: Preparation for Doxia 2.0.0
URL: https://github.com/apache/maven-project-info-reports-plugin/pull/39


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-project-info-reports-plugin] michael-o commented on pull request #39: Preparation for Doxia 2.0.0

[GitBox]

michael-o commented on PR #39:
URL: 
https://github.com/apache/maven-project-info-reports-plugin/pull/39#issuecomment-1334449756

   Superseded by #43.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-project-info-reports-plugin] michael-o opened a new pull request, #43: Prepare for Doxia 2.0.0

[GitBox]

michael-o opened a new pull request, #43:
URL: https://github.com/apache/maven-project-info-reports-plugin/pull/43

   Following this checklist to help us incorporate your 
   contribution quickly and easily:
   
- [ ] Make sure there is a [JIRA 
issue](https://issues.apache.org/jira/browse/MPIR) filed 
  for the change (usually before you start working on it).  Trivial 
changes like typos do not 
  require a JIRA issue.  Your pull request should address just this 
issue, without 
  pulling in other changes.
- [ ] Each commit in the pull request should have a meaningful subject line 
and body.
- [ ] Format the pull request title like `[MPIR-XXX] - Fixes bug in 
ApproximateQuantiles`,
  where you replace `MPIR-XXX` with the appropriate JIRA issue. Best 
practice
  is to use the JIRA issue title in the pull request title and in the 
first line of the 
  commit message.
- [ ] Write a pull request description that is detailed enough to 
understand what the pull request does, how, and why.
- [ ] Run `mvn clean verify` to make sure basic checks pass. A more 
thorough check will 
  be performed on your pull request automatically.
- [ ] You have run the integration tests successfully (`mvn -Prun-its clean 
verify`).
   
   If your pull request is about ~20 lines of code you don't need to sign an
   [Individual Contributor License 
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
   please ask on the developers list.
   
   To make clear that you license your contribution under 
   the [Apache License Version 2.0, January 
2004](http://www.apache.org/licenses/LICENSE-2.0)
   you have to acknowledge this by using the following check-box.
   
- [ ] I hereby declare this contribution to be licenced under the [Apache 
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   
- [ ] In any other case, please file an [Apache Individual Contributor 
License Agreement](https://www.apache.org/licenses/icla.pdf).
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MNG-7596) Upgrade to plexus-utils 3.5.0

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642169#comment-17642169
 ] 

ASF GitHub Bot commented on MNG-7596:
-

gnodet merged PR #866:
URL: https://github.com/apache/maven/pull/866




> Upgrade to plexus-utils 3.5.0
> -
>
> Key: MNG-7596
> URL: https://issues.apache.org/jira/browse/MNG-7596
> Project: Maven
>  Issue Type: Dependency upgrade
>Reporter: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-3
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [maven] gnodet merged pull request #866: [MNG-7596] Upgrade to plexus 3.5.0

[GitBox]

gnodet merged PR #866:
URL: https://github.com/apache/maven/pull/866


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MNG-7611) java.lang.IllegalStateException: Required Java version 1.8 is not met by current version: 17.0.5

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642164#comment-17642164
 ] 

ASF GitHub Bot commented on MNG-7611:
-

kwin merged PR #888:
URL: https://github.com/apache/maven/pull/888




> java.lang.IllegalStateException: Required Java version 1.8 is not met by 
> current version: 17.0.5
> 
>
> Key: MNG-7611
> URL: https://issues.apache.org/jira/browse/MNG-7611
> Project: Maven
>  Issue Type: Task
>Reporter: Guillaume Nodet
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 4.0.0-alpha-3
>
>
> {code:java}
> Caused by: java.lang.IllegalStateException: Required Java version 1.8 is not 
> met by current version: 17.0.5
>at 
> org.apache.maven.plugin.internal.MavenPluginJavaPrerequisiteChecker.accept(MavenPluginJavaPrerequisiteChecker.java:38)
>at 
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.lambda$checkPrerequisites$1(DefaultMavenPluginManager.java:289)
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [maven] kwin merged pull request #888: [MNG-7611] Change semantics of plugin descriptor's "requiredJavaVersion"

[GitBox]

kwin merged PR #888:
URL: https://github.com/apache/maven/pull/888


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-site-plugin] dependabot[bot] commented on pull request #114: Bump maven-reporting-api from 4.0.0-M2 to 4.0.0-M3

[GitBox]

dependabot[bot] commented on PR #114:
URL: 
https://github.com/apache/maven-site-plugin/pull/114#issuecomment-1334429704

   OK, I won't notify you again about this release, but will get in touch when 
a new version is available. If you'd rather skip all updates until the next 
major or minor version, let me know by commenting `@dependabot ignore this 
major version` or `@dependabot ignore this minor version`. You can also ignore 
all major, minor, or patch releases for a dependency by adding an [`ignore` 
condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore)
 with the desired `update_types` to your config file.
   
   If you change your mind, just re-open this PR and I'll resolve any conflicts 
on it.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-site-plugin] michael-o closed pull request #114: Bump maven-reporting-api from 4.0.0-M2 to 4.0.0-M3

[GitBox]

michael-o closed pull request #114: Bump maven-reporting-api from 4.0.0-M2 to 
4.0.0-M3
URL: https://github.com/apache/maven-site-plugin/pull/114


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-site-plugin] michael-o commented on pull request #114: Bump maven-reporting-api from 4.0.0-M2 to 4.0.0-M3

[GitBox]

michael-o commented on PR #114:
URL: 
https://github.com/apache/maven-site-plugin/pull/114#issuecomment-1334429664

   Superseded.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-site-plugin] dependabot[bot] commented on pull request #106: Bump plexus-utils from 3.4.2 to 3.5.0

[GitBox]

dependabot[bot] commented on PR #106:
URL: 
https://github.com/apache/maven-site-plugin/pull/106#issuecomment-1334429594

   OK, I won't notify you again about this release, but will get in touch when 
a new version is available. If you'd rather skip all updates until the next 
major or minor version, let me know by commenting `@dependabot ignore this 
major version` or `@dependabot ignore this minor version`. You can also ignore 
all major, minor, or patch releases for a dependency by adding an [`ignore` 
condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore)
 with the desired `update_types` to your config file.
   
   If you change your mind, just re-open this PR and I'll resolve any conflicts 
on it.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-site-plugin] michael-o commented on pull request #106: Bump plexus-utils from 3.4.2 to 3.5.0

[GitBox]

michael-o commented on PR #106:
URL: 
https://github.com/apache/maven-site-plugin/pull/106#issuecomment-1334429553

   Superseded.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-site-plugin] michael-o closed pull request #106: Bump plexus-utils from 3.4.2 to 3.5.0

[GitBox]

michael-o closed pull request #106: Bump plexus-utils from 3.4.2 to 3.5.0
URL: https://github.com/apache/maven-site-plugin/pull/106


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-site-plugin] dependabot[bot] commented on pull request #108: Bump plexus-archiver from 4.4.0 to 4.6.0

[GitBox]

dependabot[bot] commented on PR #108:
URL: 
https://github.com/apache/maven-site-plugin/pull/108#issuecomment-1334429514

   OK, I won't notify you again about this release, but will get in touch when 
a new version is available. If you'd rather skip all updates until the next 
major or minor version, let me know by commenting `@dependabot ignore this 
major version` or `@dependabot ignore this minor version`. You can also ignore 
all major, minor, or patch releases for a dependency by adding an [`ignore` 
condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore)
 with the desired `update_types` to your config file.
   
   If you change your mind, just re-open this PR and I'll resolve any conflicts 
on it.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-site-plugin] michael-o commented on pull request #108: Bump plexus-archiver from 4.4.0 to 4.6.0

[GitBox]

michael-o commented on PR #108:
URL: 
https://github.com/apache/maven-site-plugin/pull/108#issuecomment-1334429493

   Superseded.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-site-plugin] michael-o closed pull request #108: Bump plexus-archiver from 4.4.0 to 4.6.0

[GitBox]

michael-o closed pull request #108: Bump plexus-archiver from 4.4.0 to 4.6.0
URL: https://github.com/apache/maven-site-plugin/pull/108


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] slawekjaranowski closed pull request #875: Chained LRM

[GitBox]

slawekjaranowski closed pull request #875: Chained LRM
URL: https://github.com/apache/maven/pull/875


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] slawekjaranowski commented on pull request #875: Chained LRM

[GitBox]

slawekjaranowski commented on PR #875:
URL: https://github.com/apache/maven/pull/875#issuecomment-1334429080

   Suppressed by: #889


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MNG-7612) Chained Local Repository

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642160#comment-17642160
 ] 

ASF GitHub Bot commented on MNG-7612:
-

slawekjaranowski opened a new pull request, #889:
URL: https://github.com/apache/maven/pull/889

   Adds new feature: Chained Local Repository Manager.
   
   ---
   
   https://issues.apache.org/jira/browse/MNG-7612
   
   Following this checklist to help us incorporate your
   contribution quickly and easily:
   
- [ ] Make sure there is a [JIRA 
issue](https://issues.apache.org/jira/browse/MNG) filed
  for the change (usually before you start working on it).  Trivial 
changes like typos do not
  require a JIRA issue. Your pull request should address just this 
issue, without
  pulling in other changes.
- [ ] Each commit in the pull request should have a meaningful subject line 
and body.
- [ ] Format the pull request title like `[MNG-XXX] SUMMARY`, where you 
replace `MNG-XXX`
  and `SUMMARY` with the appropriate JIRA issue. Best practice is to 
use the JIRA issue
  title in the pull request title and in the first line of the commit 
message.
- [ ] Write a pull request description that is detailed enough to 
understand what the pull request does, how, and why.
- [ ] Run `mvn clean verify` to make sure basic checks pass. A more 
thorough check will
  be performed on your pull request automatically.
- [ ] You have run the [Core IT][core-its] successfully.
   
   If your pull request is about ~20 lines of code you don't need to sign an
   [Individual Contributor License 
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
   please ask on the developers list.
   
   To make clear that you license your contribution under
   the [Apache License Version 2.0, January 
2004](http://www.apache.org/licenses/LICENSE-2.0)
   you have to acknowledge this by using the following check-box.
   
- [ ] I hereby declare this contribution to be licenced under the [Apache 
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   
- [ ] In any other case, please file an [Apache Individual Contributor 
License Agreement](https://www.apache.org/licenses/icla.pdf).
   
   [core-its]: https://maven.apache.org/core-its/core-it-suite/
   




> Chained Local Repository 
> -
>
> Key: MNG-7612
> URL: https://issues.apache.org/jira/browse/MNG-7612
> Project: Maven
>  Issue Type: New Feature
>  Components: Artifacts and Repositories
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> New feature: Chained Local Repository Manager (CLRM).
> This new feature is not something one would use in production, is more 
> targeted to Integration Test isolation.
> User story: ITs usually are run as part of Maven build – lets call it "outer 
> build" – that may build among other things, plugins and some artifacts needed 
> for the ITs. The ITs itself – let's call them "inner build" – should run in 
> isolated environment.
> Problem: the "outer build" is usually affected by user environment 
> (settings.xml, use of MRM, and may use user own local repository unless 
> alternate specified) but also we do not want user MRM to be altered by IT 
> runs. The "inner build" on the other hand, may fail if use same LRM as "outer 
> build", as they are isolated, so they do not use settings.xml from the outer 
> build, may not use MRM and same remote repository IDs, and all these may lead 
> to mysterious "artifact not found" problems. Typically,  outer build may use 
> MRM that defines mirrorOf with ID "my-mrm", while inner would use defaults, 
> where only remote repository is "central": this leads that user LRM gets 
> populated with artifacts available from "my-mrm" remote repository, while 
> inner build would know only about "central" remote repository. Enhanced LRM 
> (default since Maven 3.0) would refuse to serve up these artifacts.
> Solution is CLRM: with CLRM user is able to specify isolated LRM for ITs, 
> while still making artifacts from outer LRM "visible" (discoverable) for the 
> IT build. Inner build uses isolated LRM solely, but for resolution purposes 
> still is able to resolve from outer LRM, where outer build might deployed 
> artifacts, plugins used by IT inner build.
> Technical remark: CLRM defines "head" LRM, and list of LRM as "tail". Almost 
> all methods are delegated toward "head", except for find methods (metadata 
> and artifact), exposing tail LRM contents for artifact resolution. Also, CLRM 
> is *able* to enforce artifact availability (as explained above), but in most 
> cases (at least in IT user story), one would want to inhibit this.



--
This message was sent by 

[GitHub] [maven] slawekjaranowski opened a new pull request, #889: [MNG-7612] Chained LRM

[GitBox]

slawekjaranowski opened a new pull request, #889:
URL: https://github.com/apache/maven/pull/889

   Adds new feature: Chained Local Repository Manager.
   
   ---
   
   https://issues.apache.org/jira/browse/MNG-7612
   
   Following this checklist to help us incorporate your
   contribution quickly and easily:
   
- [ ] Make sure there is a [JIRA 
issue](https://issues.apache.org/jira/browse/MNG) filed
  for the change (usually before you start working on it).  Trivial 
changes like typos do not
  require a JIRA issue. Your pull request should address just this 
issue, without
  pulling in other changes.
- [ ] Each commit in the pull request should have a meaningful subject line 
and body.
- [ ] Format the pull request title like `[MNG-XXX] SUMMARY`, where you 
replace `MNG-XXX`
  and `SUMMARY` with the appropriate JIRA issue. Best practice is to 
use the JIRA issue
  title in the pull request title and in the first line of the commit 
message.
- [ ] Write a pull request description that is detailed enough to 
understand what the pull request does, how, and why.
- [ ] Run `mvn clean verify` to make sure basic checks pass. A more 
thorough check will
  be performed on your pull request automatically.
- [ ] You have run the [Core IT][core-its] successfully.
   
   If your pull request is about ~20 lines of code you don't need to sign an
   [Individual Contributor License 
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
   please ask on the developers list.
   
   To make clear that you license your contribution under
   the [Apache License Version 2.0, January 
2004](http://www.apache.org/licenses/LICENSE-2.0)
   you have to acknowledge this by using the following check-box.
   
- [ ] I hereby declare this contribution to be licenced under the [Apache 
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   
- [ ] In any other case, please file an [Apache Individual Contributor 
License Agreement](https://www.apache.org/licenses/icla.pdf).
   
   [core-its]: https://maven.apache.org/core-its/core-it-suite/
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MNG-7611) java.lang.IllegalStateException: Required Java version 1.8 is not met by current version: 17.0.5

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642157#comment-17642157
 ] 

ASF GitHub Bot commented on MNG-7611:
-

michael-o commented on code in PR #888:
URL: https://github.com/apache/maven/pull/888#discussion_r1037533787


##
maven-core/src/main/java/org/apache/maven/plugin/internal/MavenPluginJavaPrerequisiteChecker.java:
##
@@ -18,26 +18,57 @@
  */
 package org.apache.maven.plugin.internal;
 
+import javax.inject.Inject;
 import javax.inject.Named;
 import javax.inject.Singleton;
-import org.apache.maven.model.profile.activation.JdkVersionProfileActivator;
 import org.apache.maven.plugin.MavenPluginPrerequisitesChecker;
 import org.apache.maven.plugin.descriptor.PluginDescriptor;
 import org.codehaus.plexus.util.StringUtils;
+import org.eclipse.aether.version.InvalidVersionSpecificationException;
+import org.eclipse.aether.version.Version;
+import org.eclipse.aether.version.VersionConstraint;
+import org.eclipse.aether.version.VersionScheme;
 
 @Named
 @Singleton
 public class MavenPluginJavaPrerequisiteChecker implements 
MavenPluginPrerequisitesChecker {
 
+private final VersionScheme versionScheme;
+
+@Inject
+public MavenPluginJavaPrerequisiteChecker(final VersionScheme 
versionScheme) {
+this.versionScheme = versionScheme;
+}
+
 @Override
 public void accept(PluginDescriptor pluginDescriptor) {
 String requiredJavaVersion = pluginDescriptor.getRequiredJavaVersion();
 if (StringUtils.isNotBlank(requiredJavaVersion)) {
 String currentJavaVersion = System.getProperty("java.version");
-if 
(!JdkVersionProfileActivator.isJavaVersionCompatible(requiredJavaVersion, 
currentJavaVersion)) {
+if (!matchesVersion(requiredJavaVersion, currentJavaVersion)) {
 throw new IllegalStateException("Required Java version " + 
requiredJavaVersion
 + " is not met by current version: " + 
currentJavaVersion);
 }
 }
 }
+
+boolean matchesVersion(String requiredVersion, String currentVersion) {
+VersionConstraint constraint;
+try {
+constraint = versionScheme.parseVersionConstraint(requiredVersion);
+} catch (InvalidVersionSpecificationException e) {
+throw new IllegalArgumentException(
+"Invalid requiredJavaVersion given in plugin descriptor: " 
+ e.getMessage(), e);
+}
+Version current;
+try {
+current = versionScheme.parseVersion(currentVersion);
+} catch (InvalidVersionSpecificationException e) {
+throw new IllegalStateException("Could not parse current Java 
version: " + e.getMessage(), e);

Review Comment:
   When you look at our codebase and stack traces you will see duplicate 
messages all over. It is a pain to filter out the relevant information.





> java.lang.IllegalStateException: Required Java version 1.8 is not met by 
> current version: 17.0.5
> 
>
> Key: MNG-7611
> URL: https://issues.apache.org/jira/browse/MNG-7611
> Project: Maven
>  Issue Type: Task
>Reporter: Guillaume Nodet
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 4.0.0-alpha-3
>
>
> {code:java}
> Caused by: java.lang.IllegalStateException: Required Java version 1.8 is not 
> met by current version: 17.0.5
>at 
> org.apache.maven.plugin.internal.MavenPluginJavaPrerequisiteChecker.accept(MavenPluginJavaPrerequisiteChecker.java:38)
>at 
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.lambda$checkPrerequisites$1(DefaultMavenPluginManager.java:289)
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [maven] michael-o commented on a diff in pull request #888: [MNG-7611] Change semantics of plugin descriptor's "requiredJavaVersion"

[GitBox]

michael-o commented on code in PR #888:
URL: https://github.com/apache/maven/pull/888#discussion_r1037533787


##
maven-core/src/main/java/org/apache/maven/plugin/internal/MavenPluginJavaPrerequisiteChecker.java:
##
@@ -18,26 +18,57 @@
  */
 package org.apache.maven.plugin.internal;
 
+import javax.inject.Inject;
 import javax.inject.Named;
 import javax.inject.Singleton;
-import org.apache.maven.model.profile.activation.JdkVersionProfileActivator;
 import org.apache.maven.plugin.MavenPluginPrerequisitesChecker;
 import org.apache.maven.plugin.descriptor.PluginDescriptor;
 import org.codehaus.plexus.util.StringUtils;
+import org.eclipse.aether.version.InvalidVersionSpecificationException;
+import org.eclipse.aether.version.Version;
+import org.eclipse.aether.version.VersionConstraint;
+import org.eclipse.aether.version.VersionScheme;
 
 @Named
 @Singleton
 public class MavenPluginJavaPrerequisiteChecker implements 
MavenPluginPrerequisitesChecker {
 
+private final VersionScheme versionScheme;
+
+@Inject
+public MavenPluginJavaPrerequisiteChecker(final VersionScheme 
versionScheme) {
+this.versionScheme = versionScheme;
+}
+
 @Override
 public void accept(PluginDescriptor pluginDescriptor) {
 String requiredJavaVersion = pluginDescriptor.getRequiredJavaVersion();
 if (StringUtils.isNotBlank(requiredJavaVersion)) {
 String currentJavaVersion = System.getProperty("java.version");
-if 
(!JdkVersionProfileActivator.isJavaVersionCompatible(requiredJavaVersion, 
currentJavaVersion)) {
+if (!matchesVersion(requiredJavaVersion, currentJavaVersion)) {
 throw new IllegalStateException("Required Java version " + 
requiredJavaVersion
 + " is not met by current version: " + 
currentJavaVersion);
 }
 }
 }
+
+boolean matchesVersion(String requiredVersion, String currentVersion) {
+VersionConstraint constraint;
+try {
+constraint = versionScheme.parseVersionConstraint(requiredVersion);
+} catch (InvalidVersionSpecificationException e) {
+throw new IllegalArgumentException(
+"Invalid requiredJavaVersion given in plugin descriptor: " 
+ e.getMessage(), e);
+}
+Version current;
+try {
+current = versionScheme.parseVersion(currentVersion);
+} catch (InvalidVersionSpecificationException e) {
+throw new IllegalStateException("Could not parse current Java 
version: " + e.getMessage(), e);

Review Comment:
   When you look at our codebase and stack traces you will see duplicate 
messages all over. It is a pain to filter out the relevant information.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MNG-7611) java.lang.IllegalStateException: Required Java version 1.8 is not met by current version: 17.0.5

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642154#comment-17642154
 ] 

ASF GitHub Bot commented on MNG-7611:
-

gnodet commented on code in PR #888:
URL: https://github.com/apache/maven/pull/888#discussion_r1037528525


##
maven-core/src/main/java/org/apache/maven/plugin/internal/MavenPluginJavaPrerequisiteChecker.java:
##
@@ -18,26 +18,57 @@
  */
 package org.apache.maven.plugin.internal;
 
+import javax.inject.Inject;
 import javax.inject.Named;
 import javax.inject.Singleton;
-import org.apache.maven.model.profile.activation.JdkVersionProfileActivator;
 import org.apache.maven.plugin.MavenPluginPrerequisitesChecker;
 import org.apache.maven.plugin.descriptor.PluginDescriptor;
 import org.codehaus.plexus.util.StringUtils;
+import org.eclipse.aether.version.InvalidVersionSpecificationException;
+import org.eclipse.aether.version.Version;
+import org.eclipse.aether.version.VersionConstraint;
+import org.eclipse.aether.version.VersionScheme;
 
 @Named
 @Singleton
 public class MavenPluginJavaPrerequisiteChecker implements 
MavenPluginPrerequisitesChecker {
 
+private final VersionScheme versionScheme;
+
+@Inject
+public MavenPluginJavaPrerequisiteChecker(final VersionScheme 
versionScheme) {
+this.versionScheme = versionScheme;
+}
+
 @Override
 public void accept(PluginDescriptor pluginDescriptor) {
 String requiredJavaVersion = pluginDescriptor.getRequiredJavaVersion();
 if (StringUtils.isNotBlank(requiredJavaVersion)) {
 String currentJavaVersion = System.getProperty("java.version");
-if 
(!JdkVersionProfileActivator.isJavaVersionCompatible(requiredJavaVersion, 
currentJavaVersion)) {
+if (!matchesVersion(requiredJavaVersion, currentJavaVersion)) {
 throw new IllegalStateException("Required Java version " + 
requiredJavaVersion
 + " is not met by current version: " + 
currentJavaVersion);
 }
 }
 }
+
+boolean matchesVersion(String requiredVersion, String currentVersion) {
+VersionConstraint constraint;
+try {
+constraint = versionScheme.parseVersionConstraint(requiredVersion);
+} catch (InvalidVersionSpecificationException e) {
+throw new IllegalArgumentException(
+"Invalid requiredJavaVersion given in plugin descriptor: " 
+ e.getMessage(), e);
+}
+Version current;
+try {
+current = versionScheme.parseVersion(currentVersion);
+} catch (InvalidVersionSpecificationException e) {
+throw new IllegalStateException("Could not parse current Java 
version: " + e.getMessage(), e);

Review Comment:
   Why not ? For the record, I would argue that gives a hint to the cause 
without having to read the full stack trace. Maybe even `("xxx" + e, e)` can be 
useful some time...



##
maven-core/src/main/java/org/apache/maven/plugin/internal/MavenPluginJavaPrerequisiteChecker.java:
##
@@ -18,26 +18,57 @@
  */
 package org.apache.maven.plugin.internal;
 
+import javax.inject.Inject;
 import javax.inject.Named;
 import javax.inject.Singleton;
-import org.apache.maven.model.profile.activation.JdkVersionProfileActivator;
 import org.apache.maven.plugin.MavenPluginPrerequisitesChecker;
 import org.apache.maven.plugin.descriptor.PluginDescriptor;
 import org.codehaus.plexus.util.StringUtils;
+import org.eclipse.aether.version.InvalidVersionSpecificationException;
+import org.eclipse.aether.version.Version;
+import org.eclipse.aether.version.VersionConstraint;
+import org.eclipse.aether.version.VersionScheme;
 
 @Named
 @Singleton
 public class MavenPluginJavaPrerequisiteChecker implements 
MavenPluginPrerequisitesChecker {
 
+private final VersionScheme versionScheme;
+
+@Inject
+public MavenPluginJavaPrerequisiteChecker(final VersionScheme 
versionScheme) {
+this.versionScheme = versionScheme;
+}
+
 @Override
 public void accept(PluginDescriptor pluginDescriptor) {
 String requiredJavaVersion = pluginDescriptor.getRequiredJavaVersion();
 if (StringUtils.isNotBlank(requiredJavaVersion)) {
 String currentJavaVersion = System.getProperty("java.version");
-if 
(!JdkVersionProfileActivator.isJavaVersionCompatible(requiredJavaVersion, 
currentJavaVersion)) {
+if (!matchesVersion(requiredJavaVersion, currentJavaVersion)) {
 throw new IllegalStateException("Required Java version " + 
requiredJavaVersion
 + " is not met by current version: " + 
currentJavaVersion);
 }
 }
 }
+
+boolean matchesVersion(String requiredVersion, String currentVersion) {
+VersionConstraint constraint;
+try {
+constraint = 

[GitHub] [maven] gnodet commented on a diff in pull request #888: [MNG-7611] Change semantics of plugin descriptor's "requiredJavaVersion"

[GitBox]

gnodet commented on code in PR #888:
URL: https://github.com/apache/maven/pull/888#discussion_r1037528525


##
maven-core/src/main/java/org/apache/maven/plugin/internal/MavenPluginJavaPrerequisiteChecker.java:
##
@@ -18,26 +18,57 @@
  */
 package org.apache.maven.plugin.internal;
 
+import javax.inject.Inject;
 import javax.inject.Named;
 import javax.inject.Singleton;
-import org.apache.maven.model.profile.activation.JdkVersionProfileActivator;
 import org.apache.maven.plugin.MavenPluginPrerequisitesChecker;
 import org.apache.maven.plugin.descriptor.PluginDescriptor;
 import org.codehaus.plexus.util.StringUtils;
+import org.eclipse.aether.version.InvalidVersionSpecificationException;
+import org.eclipse.aether.version.Version;
+import org.eclipse.aether.version.VersionConstraint;
+import org.eclipse.aether.version.VersionScheme;
 
 @Named
 @Singleton
 public class MavenPluginJavaPrerequisiteChecker implements 
MavenPluginPrerequisitesChecker {
 
+private final VersionScheme versionScheme;
+
+@Inject
+public MavenPluginJavaPrerequisiteChecker(final VersionScheme 
versionScheme) {
+this.versionScheme = versionScheme;
+}
+
 @Override
 public void accept(PluginDescriptor pluginDescriptor) {
 String requiredJavaVersion = pluginDescriptor.getRequiredJavaVersion();
 if (StringUtils.isNotBlank(requiredJavaVersion)) {
 String currentJavaVersion = System.getProperty("java.version");
-if 
(!JdkVersionProfileActivator.isJavaVersionCompatible(requiredJavaVersion, 
currentJavaVersion)) {
+if (!matchesVersion(requiredJavaVersion, currentJavaVersion)) {
 throw new IllegalStateException("Required Java version " + 
requiredJavaVersion
 + " is not met by current version: " + 
currentJavaVersion);
 }
 }
 }
+
+boolean matchesVersion(String requiredVersion, String currentVersion) {
+VersionConstraint constraint;
+try {
+constraint = versionScheme.parseVersionConstraint(requiredVersion);
+} catch (InvalidVersionSpecificationException e) {
+throw new IllegalArgumentException(
+"Invalid requiredJavaVersion given in plugin descriptor: " 
+ e.getMessage(), e);
+}
+Version current;
+try {
+current = versionScheme.parseVersion(currentVersion);
+} catch (InvalidVersionSpecificationException e) {
+throw new IllegalStateException("Could not parse current Java 
version: " + e.getMessage(), e);

Review Comment:
   Why not ? For the record, I would argue that gives a hint to the cause 
without having to read the full stack trace. Maybe even `("xxx" + e, e)` can be 
useful some time...



##
maven-core/src/main/java/org/apache/maven/plugin/internal/MavenPluginJavaPrerequisiteChecker.java:
##
@@ -18,26 +18,57 @@
  */
 package org.apache.maven.plugin.internal;
 
+import javax.inject.Inject;
 import javax.inject.Named;
 import javax.inject.Singleton;
-import org.apache.maven.model.profile.activation.JdkVersionProfileActivator;
 import org.apache.maven.plugin.MavenPluginPrerequisitesChecker;
 import org.apache.maven.plugin.descriptor.PluginDescriptor;
 import org.codehaus.plexus.util.StringUtils;
+import org.eclipse.aether.version.InvalidVersionSpecificationException;
+import org.eclipse.aether.version.Version;
+import org.eclipse.aether.version.VersionConstraint;
+import org.eclipse.aether.version.VersionScheme;
 
 @Named
 @Singleton
 public class MavenPluginJavaPrerequisiteChecker implements 
MavenPluginPrerequisitesChecker {
 
+private final VersionScheme versionScheme;
+
+@Inject
+public MavenPluginJavaPrerequisiteChecker(final VersionScheme 
versionScheme) {
+this.versionScheme = versionScheme;
+}
+
 @Override
 public void accept(PluginDescriptor pluginDescriptor) {
 String requiredJavaVersion = pluginDescriptor.getRequiredJavaVersion();
 if (StringUtils.isNotBlank(requiredJavaVersion)) {
 String currentJavaVersion = System.getProperty("java.version");
-if 
(!JdkVersionProfileActivator.isJavaVersionCompatible(requiredJavaVersion, 
currentJavaVersion)) {
+if (!matchesVersion(requiredJavaVersion, currentJavaVersion)) {
 throw new IllegalStateException("Required Java version " + 
requiredJavaVersion
 + " is not met by current version: " + 
currentJavaVersion);
 }
 }
 }
+
+boolean matchesVersion(String requiredVersion, String currentVersion) {
+VersionConstraint constraint;
+try {
+constraint = versionScheme.parseVersionConstraint(requiredVersion);
+} catch (InvalidVersionSpecificationException e) {
+throw new IllegalArgumentException(
+"Invalid requiredJavaVersion given in plugin descriptor: " 
+ e.getMessage(), e);
+

[jira] [Closed] (MNG-7097) Plugin Dependency Resolution: don't download Maven-provided artifacts

[Tamas Cservenak (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tamas Cservenak closed MNG-7097.

Resolution: Won't Fix

Fixed by MPLUGIN-372 that actually solves very much the problem.

> Plugin Dependency Resolution: don't download Maven-provided artifacts
> -
>
> Key: MNG-7097
> URL: https://issues.apache.org/jira/browse/MNG-7097
> Project: Maven
>  Issue Type: Task
>  Components: Performance, Plugins and Lifecycle
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Current Maven behavior for resolving plugin dependencies is to download full 
> transitive graph of plugin dependency, but for executing plugin it filters 
> out core artifacts from graph (excludes them).
> This results in unnecessary downloads of core artifacts, multiplied by 
> multiple versions used by different plugins, and local repository end up 
> having artifacts that may even surprise users.
> Most notable examples: maven-core (user: "Why did Maven download maven-core-X 
> when I use maven-Y?"), plexus-container-default (user: "Why does Maven 
> download 10+ versions of this legacy artifact (adv user: when 
> sisu-inject-plexus shim is used instead)?"), multiple versions of 
> plexus-utils etc...
> We need to investigate what exactly happens with downloaded, but unused core 
> artifacts (if they are completely excluded based on GAV, we are safest), and 
> simply exclude them even from resolution/collection, as they are really not 
> needed.
> This will not "improve build speed", but does lessen "bandwidth", as 
> experiments shows that cutting plugin dependencies for core artifacts for 
> Maven project itself makes about 1k less remote requests (artifact and 
> artifact checksum downloads).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MNG-7097) Plugin Dependency Resolution: don't download Maven-provided artifacts

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642148#comment-17642148
 ] 

ASF GitHub Bot commented on MNG-7097:
-

cstamas closed pull request #450: [MNG-7097] Plugin Dependency Resolution 
Improvement
URL: https://github.com/apache/maven/pull/450




> Plugin Dependency Resolution: don't download Maven-provided artifacts
> -
>
> Key: MNG-7097
> URL: https://issues.apache.org/jira/browse/MNG-7097
> Project: Maven
>  Issue Type: Task
>  Components: Performance, Plugins and Lifecycle
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Current Maven behavior for resolving plugin dependencies is to download full 
> transitive graph of plugin dependency, but for executing plugin it filters 
> out core artifacts from graph (excludes them).
> This results in unnecessary downloads of core artifacts, multiplied by 
> multiple versions used by different plugins, and local repository end up 
> having artifacts that may even surprise users.
> Most notable examples: maven-core (user: "Why did Maven download maven-core-X 
> when I use maven-Y?"), plexus-container-default (user: "Why does Maven 
> download 10+ versions of this legacy artifact (adv user: when 
> sisu-inject-plexus shim is used instead)?"), multiple versions of 
> plexus-utils etc...
> We need to investigate what exactly happens with downloaded, but unused core 
> artifacts (if they are completely excluded based on GAV, we are safest), and 
> simply exclude them even from resolution/collection, as they are really not 
> needed.
> This will not "improve build speed", but does lessen "bandwidth", as 
> experiments shows that cutting plugin dependencies for core artifacts for 
> Maven project itself makes about 1k less remote requests (artifact and 
> artifact checksum downloads).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MNG-7097) Plugin Dependency Resolution: don't download Maven-provided artifacts

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642147#comment-17642147
 ] 

ASF GitHub Bot commented on MNG-7097:
-

cstamas commented on PR #450:
URL: https://github.com/apache/maven/pull/450#issuecomment-1334328876

   Closing as https://issues.apache.org/jira/browse/MPLUGIN-372 solves all this.




> Plugin Dependency Resolution: don't download Maven-provided artifacts
> -
>
> Key: MNG-7097
> URL: https://issues.apache.org/jira/browse/MNG-7097
> Project: Maven
>  Issue Type: Task
>  Components: Performance, Plugins and Lifecycle
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Current Maven behavior for resolving plugin dependencies is to download full 
> transitive graph of plugin dependency, but for executing plugin it filters 
> out core artifacts from graph (excludes them).
> This results in unnecessary downloads of core artifacts, multiplied by 
> multiple versions used by different plugins, and local repository end up 
> having artifacts that may even surprise users.
> Most notable examples: maven-core (user: "Why did Maven download maven-core-X 
> when I use maven-Y?"), plexus-container-default (user: "Why does Maven 
> download 10+ versions of this legacy artifact (adv user: when 
> sisu-inject-plexus shim is used instead)?"), multiple versions of 
> plexus-utils etc...
> We need to investigate what exactly happens with downloaded, but unused core 
> artifacts (if they are completely excluded based on GAV, we are safest), and 
> simply exclude them even from resolution/collection, as they are really not 
> needed.
> This will not "improve build speed", but does lessen "bandwidth", as 
> experiments shows that cutting plugin dependencies for core artifacts for 
> Maven project itself makes about 1k less remote requests (artifact and 
> artifact checksum downloads).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [maven] cstamas closed pull request #450: [MNG-7097] Plugin Dependency Resolution Improvement

[GitBox]

cstamas closed pull request #450: [MNG-7097] Plugin Dependency Resolution 
Improvement
URL: https://github.com/apache/maven/pull/450


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] cstamas commented on pull request #450: [MNG-7097] Plugin Dependency Resolution Improvement

[GitBox]

cstamas commented on PR #450:
URL: https://github.com/apache/maven/pull/450#issuecomment-1334328876

   Closing as https://issues.apache.org/jira/browse/MPLUGIN-372 solves all this.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Updated] (MSHARED-1170) Upgrade Parent to 38

[Slawomir Jaranowski (Jira)]

 [ 
https://issues.apache.org/jira/browse/MSHARED-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Slawomir Jaranowski updated MSHARED-1170:
-
Fix Version/s: maven-shared-resources-6

> Upgrade Parent to 38
> 
>
> Key: MSHARED-1170
> URL: https://issues.apache.org/jira/browse/MSHARED-1170
> Project: Maven Shared Components
>  Issue Type: Dependency upgrade
>  Components: maven-shared-resources
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: maven-shared-resources-6
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MSHARED-1171) New IntelliJ code style formatter

[Slawomir Jaranowski (Jira)]

Slawomir Jaranowski created MSHARED-1171:


 Summary: New IntelliJ code style formatter
 Key: MSHARED-1171
 URL: https://issues.apache.org/jira/browse/MSHARED-1171
 Project: Maven Shared Components
  Issue Type: New Feature
  Components: maven-shared-resources
Reporter: Slawomir Jaranowski
Assignee: Slawomir Jaranowski
 Fix For: maven-shared-resources-6


Parent pom 38 introduce new code style, so add also new formatter for IDE.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (MNG-7612) Chained Local Repository

[Tamas Cservenak (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-7612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tamas Cservenak updated MNG-7612:
-
Description: 
New feature: Chained Local Repository Manager (CLRM).

This new feature is not something one would use in production, is more targeted 
to Integration Test isolation.

User story: ITs usually are run as part of Maven build – lets call it "outer 
build" – that may build among other things, plugins and some artifacts needed 
for the ITs. The ITs itself – let's call them "inner build" – should run in 
isolated environment.

Problem: the "outer build" is usually affected by user environment 
(settings.xml, use of MRM, and may use user own local repository unless 
alternate specified) but also we do not want user MRM to be altered by IT runs. 
The "inner build" on the other hand, may fail if use same LRM as "outer build", 
as they are isolated, so they do not use settings.xml from the outer build, may 
not use MRM and same remote repository IDs, and all these may lead to 
mysterious "artifact not found" problems. Typically,  outer build may use MRM 
that defines mirrorOf with ID "my-mrm", while inner would use defaults, where 
only remote repository is "central": this leads that user LRM gets populated 
with artifacts available from "my-mrm" remote repository, while inner build 
would know only about "central" remote repository. Enhanced LRM (default since 
Maven 3.0) would refuse to serve up these artifacts.

Solution is CLRM: with CLRM user is able to specify isolated LRM for ITs, while 
still making artifacts from outer LRM "visible" (discoverable) for the IT 
build. Inner build uses isolated LRM solely, but for resolution purposes still 
is able to resolve from outer LRM, where outer build might deployed artifacts, 
plugins used by IT inner build.

Technical remark: CLRM defines "head" LRM, and list of LRM as "tail". Almost 
all methods are delegated toward "head", except for find methods (metadata and 
artifact), exposing tail LRM contents for artifact resolution. Also, CLRM is 
*able* to enforce artifact availability (as explained above), but in most cases 
(at least in IT user story), one would want to inhibit this.

  was:
New feature: Chained Local Repository Manager (CLRM).

This new feature is not something one would use in production, is more targeted 
to Integration Test isolation.

User story: ITs usually are run as part of Maven build – lets call it "outer 
build" – that may build among other things, plugins and some artifacts needed 
for the ITs. The ITs itself – let's call them "inner build" – should run in 
isolated environment.

Problem: the "outer build" is usually affected by user environment 
(settings.xml, use of MRM, and may use user own local repository unless 
alternate specified) but also we do not want user MRM to be altered by IT runs. 
The "inner build" on the other hand, my fail if use same LRM as "outer build", 
as they are isolated, so they do not use settings.xml from the outer build, may 
not use MRM and same remote repository IDs, and all these may lead to 
mysterious "artifact not found" problems. Typically,  outer build may use MRM 
that defines mirrorOf with ID "my-mrm", while inner would use defaults, where 
only remote repository is "central": this leads that user LRM gets populated 
with artifacts available from "my-mrm" remote repository, while inner build 
would know only about "central" remote repository. Enhanced LRM (default since 
Maven 3.0) would refuse to serve up these artifacts.

Solution is CLRM: with CLRM user is able to specify isolated LRM for ITs, while 
still making artifacts from outer LRM "visible" (discoverable) for the IT 
build. Inner build uses isolated LRM solely, but for resolution purposes still 
is able to resolve from outer LRM, where outer build might deployed artifacts, 
plugins used by IT inner build.

Technical remark: CLRM defines "head" LRM, and list of LRM as "tail". Almost 
all methods are delegated toward "head", except for find methods (metadata and 
artifact), exposing tail LRM contents for artifact resolution. Also, CLRM is 
*able* to enforce artifact availability (as explained above), but in most cases 
(at least in IT user story), one would want to inhibit this.


> Chained Local Repository 
> -
>
> Key: MNG-7612
> URL: https://issues.apache.org/jira/browse/MNG-7612
> Project: Maven
>  Issue Type: New Feature
>  Components: Artifacts and Repositories
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> New feature: Chained Local Repository Manager (CLRM).
> This new feature is not something one would use in production, is more 
> targeted to Integration Test isolation.
> User story: ITs usually are run as part of Maven 

[jira] [Created] (MSHARED-1170) Upgrade Parent to 38

[Slawomir Jaranowski (Jira)]

Slawomir Jaranowski created MSHARED-1170:


 Summary: Upgrade Parent to 38
 Key: MSHARED-1170
 URL: https://issues.apache.org/jira/browse/MSHARED-1170
 Project: Maven Shared Components
  Issue Type: Dependency upgrade
  Components: maven-shared-resources
Reporter: Slawomir Jaranowski
Assignee: Slawomir Jaranowski






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (MNG-7612) Chained Local Repository

[Tamas Cservenak (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-7612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tamas Cservenak updated MNG-7612:
-
Description: 
New feature: Chained Local Repository Manager (CLRM).

This new feature is not something one would use in production, is more targeted 
to Integration Test isolation.

User story: ITs usually are run as part of Maven build – lets call it "outer 
build" – that may build among other things, plugins and some artifacts needed 
for the ITs. The ITs itself – let's call them "inner build" – should run in 
isolated environment.

Problem: the "outer build" is usually affected by user environment 
(settings.xml, use of MRM, and may use user own local repository unless 
alternate specified) but also we do not want user MRM to be altered by IT runs. 
The "inner build" on the other hand, my fail if use same LRM as "outer build", 
as they are isolated, so they do not use settings.xml from the outer build, may 
not use MRM and same remote repository IDs, and all these may lead to 
mysterious "artifact not found" problems. Typically,  outer build may use MRM 
that defines mirrorOf with ID "my-mrm", while inner would use defaults, where 
only remote repository is "central": this leads that user LRM gets populated 
with artifacts available from "my-mrm" remote repository, while inner build 
would know only about "central" remote repository. Enhanced LRM (default since 
Maven 3.0) would refuse to serve up these artifacts.

Solution is CLRM: with CLRM user is able to specify isolated LRM for ITs, while 
still making artifacts from outer LRM "visible" (discoverable) for the IT 
build. Inner build uses isolated LRM solely, but for resolution purposes still 
is able to resolve from outer LRM, where outer build might deployed artifacts, 
plugins used by IT inner build.

Technical remark: CLRM defines "head" LRM, and list of LRM as "tail". Almost 
all methods are delegated toward "head", except for find methods (metadata and 
artifact), exposing tail LRM contents for artifact resolution. Also, CLRM is 
*able* to enforce artifact availability (as explained above), but in most cases 
(at least in IT user story), one would want to inhibit this.

  was:
New feature: Chained Local Repository Manager (CLRM).

This new feature is not something one would use in production, is more targeted 
to Integration Test isolation.

User story: ITs usually are run as part of Maven build – lets call it "outer 
build" – that may build among other things, plugins and some artifacts needed 
for the ITs. The ITs itself – let's call them "inner build" – should run in 
isolated environment.

Problem: the "outer build" is usually affected by user environment 
(settings.xml, use of MRM, and may use user own local repository unless 
alternate specified) but also we do not want user MRM to be altered by IT runs. 
The "inner build" on the other hand, my fail if use same LRM as "outer build", 
as they are isolated, so they do not use settings.xml from the outer build, may 
not use MRM and same remote repository IDs, and all these may lead to 
mysterious "artifact not found" problems. Typically,  outer build may use MRM 
that defines mirrorOf with ID "my-mrm", while inner would use defaults, where 
only remote repository is "central": this leads that user LRM gets populated 
with artifacts available from "my-mrm" remote repository, while inner build 
would know only about "central" remote repository. Enhanced LRM (default since 
Maven 3.0) would refuse to serve up these artifacts.

Solution is CLRM: with CLRM user is able to specify isolated LRM for ITs, while 
still making artifacts from outer LRM "visible" (discoverable) for the IT 
build. Inner build uses isolated LRM solely, but for resolution purposes still 
is able to resolve from outer LRM, where outer build might deployed artifacts, 
plugins used by IT inner build.

 


> Chained Local Repository 
> -
>
> Key: MNG-7612
> URL: https://issues.apache.org/jira/browse/MNG-7612
> Project: Maven
>  Issue Type: New Feature
>  Components: Artifacts and Repositories
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> New feature: Chained Local Repository Manager (CLRM).
> This new feature is not something one would use in production, is more 
> targeted to Integration Test isolation.
> User story: ITs usually are run as part of Maven build – lets call it "outer 
> build" – that may build among other things, plugins and some artifacts needed 
> for the ITs. The ITs itself – let's call them "inner build" – should run in 
> isolated environment.
> Problem: the "outer build" is usually affected by user environment 
> (settings.xml, use of MRM, and may use user own local repository unless 
> alternate 

[jira] [Updated] (MNG-7612) Chained Local Repository

[Tamas Cservenak (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-7612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tamas Cservenak updated MNG-7612:
-
Description: 
New feature: Chained Local Repository Manager (CLRM).

This new feature is not something one would use in production, is more targeted 
to Integration Test isolation.

User story: ITs usually are run as part of Maven build – lets call it "outer 
build" – that may build among other things, plugins and some artifacts needed 
for the ITs. The ITs itself – let's call them "inner build" – should run in 
isolated environment.

Problem: the "outer build" is usually affected by user environment 
(settings.xml, use of MRM, and may use user own local repository unless 
alternate specified) but also we do not want user MRM to be altered by IT runs. 
The "inner build" on the other hand, my fail if use same LRM as "outer build", 
as they are isolated, so they do not use settings.xml from the outer build, may 
not use MRM and same remote repository IDs, and all these may lead to 
mysterious "artifact not found" problems. Typically,  outer build may use MRM 
that defines mirrorOf with ID "my-mrm", while inner would use defaults, where 
only remote repository is "central": this leads that user LRM gets populated 
with artifacts available from "my-mrm" remote repository, while inner build 
would know only about "central" remote repository. Enhanced LRM (default since 
Maven 3.0) would refuse to serve up these artifacts.

Solution is CLRM: with CLRM user is able to specify isolated LRM for ITs, while 
still making artifacts from outer LRM "visible" (discoverable) for the IT 
build. Inner build uses isolated LRM solely, but for resolution purposes still 
is able to resolve from outer LRM, where outer build might deployed artifacts, 
plugins used by IT inner build.

 

  was:
New feature: Chained Local Repository Manager (CLRM).

This new feature is not something one would use in production, is more targeted 
to Integration Test isolation.

User story: ITs usually are run as part of Maven build – lets call it "outer 
build" – that may build among other things, plugins and some artifacts needed 
for the ITs. The ITs itself – let's call them "inner build" – should run in 
isolated environment.

Problem: the "outer build" is usually affected by user environment 
(settings.xml, use of MRM, and may use user own local repository unless 
alternate specified) but also we do not want user MRM to be altered by IT runs. 
The "inner build" on the other hand, my fail if use same LRM as "outer build", 
as they are isolated, so they do not use settings.xml from the outer build, may 
not use MRM and same remote repository IDs, and all these may lead to 
mysterious "artifact not found" problems. Typically,  outer build may use MRM 
that defines mirrorOf with ID "my-mrm", while inner would use defaults, where 
only remote repository is "central": this leads that user LRM gets populated 
with artifacts available from "my-mrm" remote repository, while inner build 
would know only about "central" remote repository. Enhanced LRM would refuse to 
serve up these artifacts.

Solution is CLRM: with CLRM user is able to specify isolated LRM for ITs, while 
still making artifacts from outer LRM "visible" (discoverable) for the IT 
build. Inner build uses isolated LRM solely, but for resolution purposes still 
is able to resolve from outer LRM, where outer build might deployed artifacts, 
plugins used by IT inner build.

 


> Chained Local Repository 
> -
>
> Key: MNG-7612
> URL: https://issues.apache.org/jira/browse/MNG-7612
> Project: Maven
>  Issue Type: New Feature
>  Components: Artifacts and Repositories
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> New feature: Chained Local Repository Manager (CLRM).
> This new feature is not something one would use in production, is more 
> targeted to Integration Test isolation.
> User story: ITs usually are run as part of Maven build – lets call it "outer 
> build" – that may build among other things, plugins and some artifacts needed 
> for the ITs. The ITs itself – let's call them "inner build" – should run in 
> isolated environment.
> Problem: the "outer build" is usually affected by user environment 
> (settings.xml, use of MRM, and may use user own local repository unless 
> alternate specified) but also we do not want user MRM to be altered by IT 
> runs. The "inner build" on the other hand, my fail if use same LRM as "outer 
> build", as they are isolated, so they do not use settings.xml from the outer 
> build, may not use MRM and same remote repository IDs, and all these may lead 
> to mysterious "artifact not found" problems. Typically,  outer build may use 
> MRM that defines 

[jira] [Updated] (MNG-7612) Chained Local Repository

[Tamas Cservenak (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-7612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tamas Cservenak updated MNG-7612:
-
Description: 
New feature: Chained Local Repository Manager (CLRM).

This new feature is not something one would use in production, is more targeted 
to Integration Test isolation.

User story: ITs usually are run as part of Maven build – lets call it "outer 
build" – that may build among other things, plugins and some artifacts needed 
for the ITs. The ITs itself – let's call them "inner build" – should run in 
isolated environment.

Problem: the "outer build" is usually affected by user environment 
(settings.xml, use of MRM, and may use user own local repository unless 
alternate specified) but also we do not want user MRM to be altered by IT runs. 
The "inner build" on the other hand, my fail if use same LRM as "outer build", 
as they are isolated, so they do not use settings.xml from the outer build, may 
not use MRM and same remote repository IDs, and all these may lead to 
mysterious "artifact not found" problems. Typically,  outer build may use MRM 
that defines mirrorOf with ID "my-mrm", while inner would use defaults, where 
only remote repository is "central": this leads that user LRM gets populated 
with artifacts available from "my-mrm" remote repository, while inner build 
would know only about "central" remote repository. Enhanced LRM would refuse to 
serve up these artifacts.

Solution is CLRM: with CLRM user is able to specify isolated LRM for ITs, while 
still making artifacts from outer LRM "visible" (discoverable) for the IT 
build. Inner build uses isolated LRM solely, but for resolution purposes still 
is able to resolve from outer LRM, where outer build might deployed artifacts, 
plugins used by IT inner build.

 

> Chained Local Repository 
> -
>
> Key: MNG-7612
> URL: https://issues.apache.org/jira/browse/MNG-7612
> Project: Maven
>  Issue Type: New Feature
>  Components: Artifacts and Repositories
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> New feature: Chained Local Repository Manager (CLRM).
> This new feature is not something one would use in production, is more 
> targeted to Integration Test isolation.
> User story: ITs usually are run as part of Maven build – lets call it "outer 
> build" – that may build among other things, plugins and some artifacts needed 
> for the ITs. The ITs itself – let's call them "inner build" – should run in 
> isolated environment.
> Problem: the "outer build" is usually affected by user environment 
> (settings.xml, use of MRM, and may use user own local repository unless 
> alternate specified) but also we do not want user MRM to be altered by IT 
> runs. The "inner build" on the other hand, my fail if use same LRM as "outer 
> build", as they are isolated, so they do not use settings.xml from the outer 
> build, may not use MRM and same remote repository IDs, and all these may lead 
> to mysterious "artifact not found" problems. Typically,  outer build may use 
> MRM that defines mirrorOf with ID "my-mrm", while inner would use defaults, 
> where only remote repository is "central": this leads that user LRM gets 
> populated with artifacts available from "my-mrm" remote repository, while 
> inner build would know only about "central" remote repository. Enhanced LRM 
> would refuse to serve up these artifacts.
> Solution is CLRM: with CLRM user is able to specify isolated LRM for ITs, 
> while still making artifacts from outer LRM "visible" (discoverable) for the 
> IT build. Inner build uses isolated LRM solely, but for resolution purposes 
> still is able to resolve from outer LRM, where outer build might deployed 
> artifacts, plugins used by IT inner build.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Maven build hanging -- how to collect diagnostics?

[Tamás Cservenák]

Please use the Maven User list, this list (issues) is for automated JIRA
emails and is probably filtered/archived by many of us.

Also, please specify Maven version, Java version (that Maven uses).

https://maven.apache.org/mailing-lists.html

Thanks
T

On Thu, Dec 1, 2022 at 4:50 PM John Lilley
 wrote:

> Greetings,
>
>
>
> I have a maven build for a somewhat complex tree of projects, where I find
> that a multi-thread build will hang unless “clean” is done first.  A
> single-thread build is fine.  The hang seems to occur at one of the
> “Installing…” messages, but of course being multi-threaded it is unclear
> whether that is the proximal cause.  Oddly, when it hangs, maven continues
> to consume a full CPU core, which indicates some sort of live-lock
> situation.  This is on Windows 10.
>
>
>
> At this point, I have two questions:
>
>- Does someone recognize this as a known issue?
>- If not, please help me collect diagnostics so that I could submit a
>useful bug report.  Can I enable verbose debug logging?  When it hangs,
>would a jstack dump be helpful?
>
>
>
> Thanks
>
> John
>
>
>
> [image: rg] 
>
> John Lilley
>
> Data Management Chief Architect, Redpoint Global Inc.
>
> 888 Worcester Street, Suite 200 Wellesley, MA 02482
>
> *M: *+1 7209385761 <+1%207209385761> | john.lil...@redpointglobal.com
>
> PLEASE NOTE: This e-mail from Redpoint Global Inc. (“Redpoint”) is
> confidential and is intended solely for the use of the individual(s) to
> whom it is addressed. If you believe you received this e-mail in error,
> please notify the sender immediately, delete the e-mail from your computer
> and do not copy, print or disclose it to anyone else. If you properly
> received this e-mail as a customer, partner or vendor of Redpoint, you
> should maintain its contents in confidence subject to the terms and
> conditions of your agreement(s) with Redpoint.
>

[jira] [Created] (MNG-7612) Chained Local Repository

[Slawomir Jaranowski (Jira)]

Slawomir Jaranowski created MNG-7612:


 Summary: Chained Local Repository 
 Key: MNG-7612
 URL: https://issues.apache.org/jira/browse/MNG-7612
 Project: Maven
  Issue Type: New Feature
  Components: Artifacts and Repositories
Reporter: Slawomir Jaranowski
Assignee: Slawomir Jaranowski
 Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Maven build hanging -- how to collect diagnostics?

[John Lilley]

Greetings,

I have a maven build for a somewhat complex tree of projects, where I find that 
a multi-thread build will hang unless “clean” is done first.  A single-thread 
build is fine.  The hang seems to occur at one of the “Installing…” messages, 
but of course being multi-threaded it is unclear whether that is the proximal 
cause.  Oddly, when it hangs, maven continues to consume a full CPU core, which 
indicates some sort of live-lock situation.  This is on Windows 10.

At this point, I have two questions:

  *   Does someone recognize this as a known issue?
  *   If not, please help me collect diagnostics so that I could submit a 
useful bug report.  Can I enable verbose debug logging?  When it hangs, would a 
jstack dump be helpful?

Thanks
John



[rg] 

John Lilley

Data Management Chief Architect, Redpoint Global Inc.

888 Worcester Street, Suite 200 Wellesley, MA 02482

M: +1 7209385761 | 
john.lil...@redpointglobal.com

PLEASE NOTE: This e-mail from Redpoint Global Inc. (“Redpoint”) is confidential 
and is intended solely for the use of the individual(s) to whom it is 
addressed. If you believe you received this e-mail in error, please notify the 
sender immediately, delete the e-mail from your computer and do not copy, print 
or disclose it to anyone else. If you properly received this e-mail as a 
customer, partner or vendor of Redpoint, you should maintain its contents in 
confidence subject to the terms and conditions of your agreement(s) with 
Redpoint.

[jira] [Commented] (MNG-6609) Profile activation by packaging

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641913#comment-17641913
 ] 

Hudson commented on MNG-6609:
-

Build succeeded in Jenkins: Maven » Maven TLP » maven » master #140

See 
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/140/

> Profile activation by packaging 
> 
>
> Key: MNG-6609
> URL: https://issues.apache.org/jira/browse/MNG-6609
> Project: Maven
>  Issue Type: Improvement
>  Components: Profiles
>Affects Versions: 3.6.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> Due to the lack of mixins, it is common that modules which use different 
> packagings share the same parent pom. As those often use different 
> dependencies/plugins, it would be nice to have profiles which are activated 
> based on the packaging of a module. That is currently not possible.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MNG-7606) Maven 3.9.0-SNAPSHOT cannot build Maven 4.0.0-SNAPSHOT

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641914#comment-17641914
 ] 

Hudson commented on MNG-7606:
-

Build succeeded in Jenkins: Maven » Maven TLP » maven » master #140

See 
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/140/

> Maven 3.9.0-SNAPSHOT cannot build Maven 4.0.0-SNAPSHOT
> --
>
> Key: MNG-7606
> URL: https://issues.apache.org/jira/browse/MNG-7606
> Project: Maven
>  Issue Type: Bug
>Reporter: Tamas Cservenak
>Assignee: Konrad Windszus
>Priority: Blocker
> Fix For: 3.9.0
>
>
> How to reproduce: build maven-3.9.x branch 
> (e921f1564ef9460ca58745eb52e3967dbbd0b9e7) then checkout master branch 
> (c6ecff9923088d854d4621e17d602f1c70dda806) and try to build it with built 
> 3.9.0-SNAPSHOT: it fails.
> Error is:
> {noformat}
> [cstamas@blondie maven (master)]$ mvn -V clean install
> Apache Maven 3.9.0-SNAPSHOT (e921f1564ef9460ca58745eb52e3967dbbd0b9e7)
> Maven home: /home/cstamas/.sdkman/candidates/maven/3.9.0-SNAPSHOT
> Java version: 17.0.5, vendor: Eclipse Adoptium, runtime: 
> /home/cstamas/.sdkman/candidates/java/17.0.5-tem
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "6.0.9-300.fc37.x86_64", arch: "amd64", family: 
> "unix"
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'dependencies.dependency.version' for 
> org.junit.jupiter:junit-jupiter-engine:jar is missing. @ line 485, column 17
>  @ 
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]   
> [ERROR]   The project org.apache.maven:maven:4.0.0-alpha-3-SNAPSHOT 
> (/home/cstamas/Worx/apache-maven/maven/pom.xml) has 1 error
> [ERROR]     'dependencies.dependency.version' for 
> org.junit.jupiter:junit-jupiter-engine:jar is missing. @ line 485, column 17
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [cstamas@blondie maven (master)]$  {noformat}
> Maven 3.8.6 and 4.0.0-alpha-3-SNAPSHOT builds master just fine.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MNG-7607) Add Transport to new Immutable API

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641912#comment-17641912
 ] 

Hudson commented on MNG-7607:
-

Build succeeded in Jenkins: Maven » Maven TLP » maven » master #140

See 
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/140/

> Add Transport to new Immutable API
> --
>
> Key: MNG-7607
> URL: https://issues.apache.org/jira/browse/MNG-7607
> Project: Maven
>  Issue Type: New Feature
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate, 4.0.0
>
>
> Introduce simple API to GET/PUT resources. Keep it intentionally simple, that 
> still covers quite broad range of use cases. If plugin/extension needs a bit 
> advanced features (like conditional GETs or whatnot), they should roll their 
> own.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [maven-plugin-tools] dependabot[bot] opened a new pull request, #185: Bump httpcore from 4.4.15 to 4.4.16

[GitBox]

dependabot[bot] opened a new pull request, #185:
URL: https://github.com/apache/maven-plugin-tools/pull/185

   Bumps httpcore from 4.4.15 to 4.4.16.
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=org.apache.httpcomponents:httpcore=maven=4.4.15=4.4.16)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   
   Dependabot commands and options
   
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot merge` will merge this PR after your CI passes on it
   - `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
   - `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
   - `@dependabot reopen` will reopen this PR if it is closed
   - `@dependabot close` will close this PR and stop Dependabot recreating it. 
You can achieve the same result by closing it manually
   - `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MNG-7607) Add Transport to new Immutable API

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641896#comment-17641896
 ] 

ASF GitHub Bot commented on MNG-7607:
-

cstamas merged PR #884:
URL: https://github.com/apache/maven/pull/884




> Add Transport to new Immutable API
> --
>
> Key: MNG-7607
> URL: https://issues.apache.org/jira/browse/MNG-7607
> Project: Maven
>  Issue Type: New Feature
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate, 4.0.0
>
>
> Introduce simple API to GET/PUT resources. Keep it intentionally simple, that 
> still covers quite broad range of use cases. If plugin/extension needs a bit 
> advanced features (like conditional GETs or whatnot), they should roll their 
> own.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (MNG-7607) Add Transport to new Immutable API

[Tamas Cservenak (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-7607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tamas Cservenak closed MNG-7607.

Resolution: Fixed

> Add Transport to new Immutable API
> --
>
> Key: MNG-7607
> URL: https://issues.apache.org/jira/browse/MNG-7607
> Project: Maven
>  Issue Type: New Feature
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate, 4.0.0
>
>
> Introduce simple API to GET/PUT resources. Keep it intentionally simple, that 
> still covers quite broad range of use cases. If plugin/extension needs a bit 
> advanced features (like conditional GETs or whatnot), they should roll their 
> own.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (MNG-7607) Add Transport to new Immutable API

[Tamas Cservenak (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-7607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tamas Cservenak reassigned MNG-7607:


Assignee: Tamas Cservenak

> Add Transport to new Immutable API
> --
>
> Key: MNG-7607
> URL: https://issues.apache.org/jira/browse/MNG-7607
> Project: Maven
>  Issue Type: New Feature
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate, 4.0.0
>
>
> Introduce simple API to GET/PUT resources. Keep it intentionally simple, that 
> still covers quite broad range of use cases. If plugin/extension needs a bit 
> advanced features (like conditional GETs or whatnot), they should roll their 
> own.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [maven] cstamas merged pull request #884: [MNG-7607] Add M4 Transport API

[GitBox]

cstamas merged PR #884:
URL: https://github.com/apache/maven/pull/884


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Updated] (MNG-7587) Update sisu to a version supporting at least Java 17

[Tamas Cservenak (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-7587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tamas Cservenak updated MNG-7587:
-
Fix Version/s: 4.0.x-candidate
   (was: 3.9.0-candidate)

> Update sisu to a version supporting at least Java 17
> 
>
> Key: MNG-7587
> URL: https://issues.apache.org/jira/browse/MNG-7587
> Project: Maven
>  Issue Type: Improvement
>  Components: Core
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> Version 0.3.5 (inherited from 
> https://github.com/apache/maven-parent/blob/aff1eef5409009ca7f9d5f196233b2a575aba775/pom.xml#L934)
>  in both Maven 4 and 3.9 of {{sisu.inject}} ships with ASM 5.0.2 (relaxed in 
> https://github.com/eclipse/sisu.inject/commit/5e34add4790384dc764f77c9e31761cbc6e479aa
>  to support up to Java 14).
> Given that Java 19 is the most recent one today Maven needs a newer version 
> of {{sisu.inject}} to fully support newer Java bytecode than for Java 14. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (MNG-7473) Backport Maven BOM to Maven 3.9.x

[Tamas Cservenak (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-7473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tamas Cservenak closed MNG-7473.

Resolution: Won't Fix

Backed out from it, it makes no sense to do it "as is".

> Backport Maven BOM to Maven 3.9.x
> -
>
> Key: MNG-7473
> URL: https://issues.apache.org/jira/browse/MNG-7473
> Project: Maven
>  Issue Type: Task
>  Components: POM
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.0-candidate
>
>
> It will ease lives of plugin developers a lot.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MNG-7473) Backport Maven BOM to Maven 3.9.x

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641883#comment-17641883
 ] 

ASF GitHub Bot commented on MNG-7473:
-

cstamas closed pull request #859: [3.9.x] [MNG-7473] Backport Maven BOM to 3.9.0
URL: https://github.com/apache/maven/pull/859




> Backport Maven BOM to Maven 3.9.x
> -
>
> Key: MNG-7473
> URL: https://issues.apache.org/jira/browse/MNG-7473
> Project: Maven
>  Issue Type: Task
>  Components: POM
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.0-candidate
>
>
> It will ease lives of plugin developers a lot.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MNG-7473) Backport Maven BOM to Maven 3.9.x

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641882#comment-17641882
 ] 

ASF GitHub Bot commented on MNG-7473:
-

cstamas commented on PR #859:
URL: https://github.com/apache/maven/pull/859#issuecomment-1333697430

   Am backing out from backporting BOM, it makes no sense as is IMHO




> Backport Maven BOM to Maven 3.9.x
> -
>
> Key: MNG-7473
> URL: https://issues.apache.org/jira/browse/MNG-7473
> Project: Maven
>  Issue Type: Task
>  Components: POM
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.0-candidate
>
>
> It will ease lives of plugin developers a lot.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [maven] cstamas closed pull request #859: [3.9.x] [MNG-7473] Backport Maven BOM to 3.9.0

[GitBox]

cstamas closed pull request #859: [3.9.x] [MNG-7473] Backport Maven BOM to 3.9.0
URL: https://github.com/apache/maven/pull/859


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] cstamas commented on pull request #859: [3.9.x] [MNG-7473] Backport Maven BOM to 3.9.0

[GitBox]

cstamas commented on PR #859:
URL: https://github.com/apache/maven/pull/859#issuecomment-1333697430

   Am backing out from backporting BOM, it makes no sense as is IMHO


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Closed] (MNG-7606) Maven 3.9.0-SNAPSHOT cannot build Maven 4.0.0-SNAPSHOT

[Tamas Cservenak (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-7606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tamas Cservenak closed MNG-7606.

Resolution: Fixed

> Maven 3.9.0-SNAPSHOT cannot build Maven 4.0.0-SNAPSHOT
> --
>
> Key: MNG-7606
> URL: https://issues.apache.org/jira/browse/MNG-7606
> Project: Maven
>  Issue Type: Bug
>Reporter: Tamas Cservenak
>Assignee: Konrad Windszus
>Priority: Blocker
> Fix For: 3.9.0
>
>
> How to reproduce: build maven-3.9.x branch 
> (e921f1564ef9460ca58745eb52e3967dbbd0b9e7) then checkout master branch 
> (c6ecff9923088d854d4621e17d602f1c70dda806) and try to build it with built 
> 3.9.0-SNAPSHOT: it fails.
> Error is:
> {noformat}
> [cstamas@blondie maven (master)]$ mvn -V clean install
> Apache Maven 3.9.0-SNAPSHOT (e921f1564ef9460ca58745eb52e3967dbbd0b9e7)
> Maven home: /home/cstamas/.sdkman/candidates/maven/3.9.0-SNAPSHOT
> Java version: 17.0.5, vendor: Eclipse Adoptium, runtime: 
> /home/cstamas/.sdkman/candidates/java/17.0.5-tem
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "6.0.9-300.fc37.x86_64", arch: "amd64", family: 
> "unix"
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'dependencies.dependency.version' for 
> org.junit.jupiter:junit-jupiter-engine:jar is missing. @ line 485, column 17
>  @ 
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]   
> [ERROR]   The project org.apache.maven:maven:4.0.0-alpha-3-SNAPSHOT 
> (/home/cstamas/Worx/apache-maven/maven/pom.xml) has 1 error
> [ERROR]     'dependencies.dependency.version' for 
> org.junit.jupiter:junit-jupiter-engine:jar is missing. @ line 485, column 17
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [cstamas@blondie maven (master)]$  {noformat}
> Maven 3.8.6 and 4.0.0-alpha-3-SNAPSHOT builds master just fine.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MNG-7606) Maven 3.9.0-SNAPSHOT cannot build Maven 4.0.0-SNAPSHOT

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641879#comment-17641879
 ] 

Hudson commented on MNG-7606:
-

Build succeeded in Jenkins: Maven » Maven TLP » maven » maven-3.9.x #91

See 
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.9.x/91/

> Maven 3.9.0-SNAPSHOT cannot build Maven 4.0.0-SNAPSHOT
> --
>
> Key: MNG-7606
> URL: https://issues.apache.org/jira/browse/MNG-7606
> Project: Maven
>  Issue Type: Bug
>Reporter: Tamas Cservenak
>Assignee: Konrad Windszus
>Priority: Blocker
> Fix For: 3.9.0
>
>
> How to reproduce: build maven-3.9.x branch 
> (e921f1564ef9460ca58745eb52e3967dbbd0b9e7) then checkout master branch 
> (c6ecff9923088d854d4621e17d602f1c70dda806) and try to build it with built 
> 3.9.0-SNAPSHOT: it fails.
> Error is:
> {noformat}
> [cstamas@blondie maven (master)]$ mvn -V clean install
> Apache Maven 3.9.0-SNAPSHOT (e921f1564ef9460ca58745eb52e3967dbbd0b9e7)
> Maven home: /home/cstamas/.sdkman/candidates/maven/3.9.0-SNAPSHOT
> Java version: 17.0.5, vendor: Eclipse Adoptium, runtime: 
> /home/cstamas/.sdkman/candidates/java/17.0.5-tem
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "6.0.9-300.fc37.x86_64", arch: "amd64", family: 
> "unix"
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'dependencies.dependency.version' for 
> org.junit.jupiter:junit-jupiter-engine:jar is missing. @ line 485, column 17
>  @ 
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]   
> [ERROR]   The project org.apache.maven:maven:4.0.0-alpha-3-SNAPSHOT 
> (/home/cstamas/Worx/apache-maven/maven/pom.xml) has 1 error
> [ERROR]     'dependencies.dependency.version' for 
> org.junit.jupiter:junit-jupiter-engine:jar is missing. @ line 485, column 17
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [cstamas@blondie maven (master)]$  {noformat}
> Maven 3.8.6 and 4.0.0-alpha-3-SNAPSHOT builds master just fine.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MNG-6609) Profile activation by packaging

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641878#comment-17641878
 ] 

Hudson commented on MNG-6609:
-

Build succeeded in Jenkins: Maven » Maven TLP » maven » maven-3.9.x #91

See 
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.9.x/91/

> Profile activation by packaging 
> 
>
> Key: MNG-6609
> URL: https://issues.apache.org/jira/browse/MNG-6609
> Project: Maven
>  Issue Type: Improvement
>  Components: Profiles
>Affects Versions: 3.6.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> Due to the lack of mixins, it is common that modules which use different 
> packagings share the same parent pom. As those often use different 
> dependencies/plugins, it would be nice to have profiles which are activated 
> based on the packaging of a module. That is currently not possible.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MNGSITE-502) Document activation based on packaging

[Konrad Windszus (Jira)]

Konrad Windszus created MNGSITE-502:
---

 Summary: Document activation based on packaging
 Key: MNGSITE-502
 URL: https://issues.apache.org/jira/browse/MNGSITE-502
 Project: Maven Project Web Site
  Issue Type: Improvement
Reporter: Konrad Windszus
Assignee: Konrad Windszus


https://issues.apache.org/jira/browse/MNG-6609 introduced profile activation 
based on packaging. This requires updates of both 
 * [https://maven.apache.org/pom.html#Activation] and
 * 
[https://maven.apache.org/guides/introduction/introduction-to-profiles.html#details-on-profile-activation]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (MNG-6609) Profile activation by packaging

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-6609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus resolved MNG-6609.
--
Resolution: Fixed

> Profile activation by packaging 
> 
>
> Key: MNG-6609
> URL: https://issues.apache.org/jira/browse/MNG-6609
> Project: Maven
>  Issue Type: Improvement
>  Components: Profiles
>Affects Versions: 3.6.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> Due to the lack of mixins, it is common that modules which use different 
> packagings share the same parent pom. As those often use different 
> dependencies/plugins, it would be nice to have profiles which are activated 
> based on the packaging of a module. That is currently not possible.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (MPOM-372) Automatically format source files during Eclipse incremental build

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/MPOM-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated MPOM-372:
-
Description: Each source file should be auto-formatted after an incremental 
build is triggered in Eclipse. This requires an update to a newer 
{{spotless-maven-plugin}} which has 
[https://github.com/diffplug/spotless/issues/1413] integrated and a conditional 
profile (just active when running in Eclipse) which executes {{spotless:apply}} 
 (was: Each source file should be auto-formatted after an incremental build is 
triggered in Eclipse. This requires an update to a newer 
{{spotless-maven-plugin}} which has 
[https://github.com/diffplug/spotless/issues/1413] integrated and a conditional 
profile (just active when running in Eclipse) which executes {{spotless-apply}})

> Automatically format source files during Eclipse incremental build
> --
>
> Key: MPOM-372
> URL: https://issues.apache.org/jira/browse/MPOM-372
> Project: Maven POMs
>  Issue Type: Improvement
>  Components: maven
>Affects Versions: MAVEN-38
>Reporter: Konrad Windszus
>Priority: Major
>
> Each source file should be auto-formatted after an incremental build is 
> triggered in Eclipse. This requires an update to a newer 
> {{spotless-maven-plugin}} which has 
> [https://github.com/diffplug/spotless/issues/1413] integrated and a 
> conditional profile (just active when running in Eclipse) which executes 
> {{spotless:apply}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MPOM-372) Automatically format source files during Eclipse incremental build

[Konrad Windszus (Jira)]

Konrad Windszus created MPOM-372:


 Summary: Automatically format source files during Eclipse 
incremental build
 Key: MPOM-372
 URL: https://issues.apache.org/jira/browse/MPOM-372
 Project: Maven POMs
  Issue Type: Improvement
  Components: maven
Affects Versions: MAVEN-38
Reporter: Konrad Windszus


Each source file should be auto-formatted after an incremental build is 
triggered in Eclipse. This requires an update to a newer 
{{spotless-maven-plugin}} which has 
[https://github.com/diffplug/spotless/issues/1413] integrated and a conditional 
profile (just active when running in Eclipse) which executes {{spotless-apply}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MNG-6609) Profile activation by packaging

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641859#comment-17641859
 ] 

ASF GitHub Bot commented on MNG-6609:
-

cstamas merged PR #883:
URL: https://github.com/apache/maven/pull/883




> Profile activation by packaging 
> 
>
> Key: MNG-6609
> URL: https://issues.apache.org/jira/browse/MNG-6609
> Project: Maven
>  Issue Type: Improvement
>  Components: Profiles
>Affects Versions: 3.6.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> Due to the lack of mixins, it is common that modules which use different 
> packagings share the same parent pom. As those often use different 
> dependencies/plugins, it would be nice to have profiles which are activated 
> based on the packaging of a module. That is currently not possible.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [maven] cstamas merged pull request #883: [MNG-6609] Profile activation based on packaging

[GitBox]

cstamas merged PR #883:
URL: https://github.com/apache/maven/pull/883


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-integration-testing] cstamas merged pull request #214: [MNG-7606] add IT

[GitBox]

cstamas merged PR #214:
URL: https://github.com/apache/maven-integration-testing/pull/214


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MNG-7606) Maven 3.9.0-SNAPSHOT cannot build Maven 4.0.0-SNAPSHOT

[Tamas Cservenak (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641841#comment-17641841
 ] 

Tamas Cservenak commented on MNG-7606:
--

IT added as [https://github.com/apache/maven-integration-testing/pull/214]

Reverted change redone as https://github.com/apache/maven/pull/883

> Maven 3.9.0-SNAPSHOT cannot build Maven 4.0.0-SNAPSHOT
> --
>
> Key: MNG-7606
> URL: https://issues.apache.org/jira/browse/MNG-7606
> Project: Maven
>  Issue Type: Bug
>Reporter: Tamas Cservenak
>Assignee: Konrad Windszus
>Priority: Blocker
> Fix For: 3.9.0
>
>
> How to reproduce: build maven-3.9.x branch 
> (e921f1564ef9460ca58745eb52e3967dbbd0b9e7) then checkout master branch 
> (c6ecff9923088d854d4621e17d602f1c70dda806) and try to build it with built 
> 3.9.0-SNAPSHOT: it fails.
> Error is:
> {noformat}
> [cstamas@blondie maven (master)]$ mvn -V clean install
> Apache Maven 3.9.0-SNAPSHOT (e921f1564ef9460ca58745eb52e3967dbbd0b9e7)
> Maven home: /home/cstamas/.sdkman/candidates/maven/3.9.0-SNAPSHOT
> Java version: 17.0.5, vendor: Eclipse Adoptium, runtime: 
> /home/cstamas/.sdkman/candidates/java/17.0.5-tem
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "6.0.9-300.fc37.x86_64", arch: "amd64", family: 
> "unix"
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'dependencies.dependency.version' for 
> org.junit.jupiter:junit-jupiter-engine:jar is missing. @ line 485, column 17
>  @ 
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]   
> [ERROR]   The project org.apache.maven:maven:4.0.0-alpha-3-SNAPSHOT 
> (/home/cstamas/Worx/apache-maven/maven/pom.xml) has 1 error
> [ERROR]     'dependencies.dependency.version' for 
> org.junit.jupiter:junit-jupiter-engine:jar is missing. @ line 485, column 17
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [cstamas@blondie maven (master)]$  {noformat}
> Maven 3.8.6 and 4.0.0-alpha-3-SNAPSHOT builds master just fine.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)