[jira] [Commented] (MNG-5781) resolution of nested import scoped dependencies causes maven to reach out to external central repo
[
https://issues.apache.org/jira/browse/MNG-5781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300990#comment-17300990
]
Michael Osipov commented on MNG-5781:
-
Either way, can you confirm that both issues are describing the same problem?
> resolution of nested import scoped dependencies causes maven to reach out to
> external central repo
> --
>
> Key: MNG-5781
> URL: https://issues.apache.org/jira/browse/MNG-5781
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build, Dependencies
>Affects Versions: 3.2.5
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T09:29:23-08:00)
> Maven home: /usr/local/maven-3.2.5
> Java version: 1.7.0_76, vendor: Oracle Corporation
> Java home: /usr/local/jdk1.7.0_76-server-jre/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-504.3.3.el6.centos.plus.x86_64", arch:
> "amd64", family: "unix"
>Reporter: Ravi Sanwal
>Priority: Major
> Fix For: 4.0.x-candidate
>
> Attachments: MNG-5781-Maven360.txt, first.pom.xml,
> global_settings.xml, last.pom.xml, second.pom.xml
>
>
> When a project uses a dependency that has as import scoped dependency, which
> in turn also has another import scoped dependency (nested imported scoped
> dependencies), resolution of the last level of dependency makes maven to
> reach our to the external central repository
> ([https://repo.maven.apache.org/maven2/])
> Steps to reproduce:
> Use the attached global settings file.
> It has an internal repository declared as a replacement to 'central', you can
> point to one of your own internal repo.(not the local)
> Build the attached file first.pom.xml:
> {code:java}
> mvn -gs global_settings.xml install -f first.pom.xml{code}
> Build the attached file second.pom.xml:
> {code:java}
> mvn install -f second.pom.xml{code}
> Then, delete _org.aspectj:aspectjtools from local repo (rm
> ~/.m2/repository/org/aspectj_/aspectjtools), we want to download this from
> our internal central repository alias repository.
> Build the attached file last.pom.xml:
> {code:java}
> mvn -gs global_settings.xml dependency:copy-dependencies -f last.pom.xml{code}
> (copy dependencies because this is a pom project, alternatively change
> last.pom.xml to a jar project and do mvn -gs global_settings.xml install -
> same thing)
> You'll see that org.aspectj:aspectjtools is being downloaded from central
> ([https://repo.maven.apache.org/maven2/]) effectively rendering hosting our
> own repositories useless.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7114) Publish XSDs as artifact to Central
[
https://issues.apache.org/jira/browse/MNG-7114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300987#comment-17300987
]
Michael Osipov commented on MNG-7114:
-
I wonder whether those projects could use MASSEMBLY to create a ZIP file with
classifier {{schemas}} and attach them to the reactor?!
> Publish XSDs as artifact to Central
> ---
>
> Key: MNG-7114
> URL: https://issues.apache.org/jira/browse/MNG-7114
> Project: Maven
> Issue Type: Improvement
>Reporter: Andreas Sewe
>Priority: Minor
>
> At the moment, a number of XML Schema files for descriptor-like file formats
> like archetype or assembly descriptors are only available at
> [https://maven.apache.org/xsd/].
> This makes them hard to consume, for example, by the {{xml:validate}} goal,
> which is IMHO quite well suited for sanity-checking your descriptor files
> before packaging and subsequently releasing them.
> Would it be possible to release the XSDs under {{org.apache.maven:maven-xsd}}
> or a similar coordinate?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7110) Different behavior of extensions
[ https://issues.apache.org/jira/browse/MNG-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300984#comment-17300984 ] Hudson commented on MNG-7110: - Build failed in Jenkins: Maven » Maven TLP » maven » maven-3.6.x #6 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.6.x/6/ > Different behavior of extensions > > > Key: MNG-7110 > URL: https://issues.apache.org/jira/browse/MNG-7110 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.x-candidate >Reporter: Mirko Friedenhagen >Assignee: Robert Scholte >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > * In my POM I configured the net.rumati.maven.plugins:velocity-maven-plugin > which should render a HTML file. > * The parent of the project has a global extension in the build section. > * The jar of the extension does include a velocity which is picked up quite > fine by the velocity-maven-plugin from > the classpath by 3.6.3 but when using 4.0.0 I now need to add the extension > jar as a dependency to the plugin. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7051) Optionally skip non-existing profiles
[
https://issues.apache.org/jira/browse/MNG-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300983#comment-17300983
]
Hudson commented on MNG-7051:
-
Build failed in Jenkins: Maven » Maven TLP » maven » maven-3.6.x #6
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.6.x/6/
> Optionally skip non-existing profiles
> -
>
> Key: MNG-7051
> URL: https://issues.apache.org/jira/browse/MNG-7051
> Project: Maven
> Issue Type: Sub-task
> Components: Profiles
>Reporter: Maarten Mulders
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> For Maven 4, the behaviour of the {{-P}} command line option will change:
> * {{-P apache-release}} will activate the *apache-release* profile. If such
> a profile cannot be found, the build will break.
> * {{-P ?apache-release}} will activate the *apache-release* profile. If such
> a profile cannot be found, the build will continue but log a warning.
> {color:#ff}
> Note that this breaks the current behaviour of Maven 3 in two ways:
> {color}
> # {{-P apache-release}} will currently log a warning and not break the build.
> That behaviour can be restored by adding the {{?}}.
> # A profile that has an identifier that not valid (i.e., contains anything
> else than {{a}} - {{z}}, {{A}} to {{Z}}, {{0}} - {{9}}, {{-}}, {{_}} or
> {{.}}) will break the build.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7046) Revert MNG-5639 and make repo config static only
[ https://issues.apache.org/jira/browse/MNG-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300985#comment-17300985 ] Hudson commented on MNG-7046: - Build failed in Jenkins: Maven » Maven TLP » maven » maven-3.6.x #6 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.6.x/6/ > Revert MNG-5639 and make repo config static only > > > Key: MNG-7046 > URL: https://issues.apache.org/jira/browse/MNG-7046 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories, Dependencies >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.x-candidate > > > As discussed in MNG-5639 repositories should always be known upfront, they > have to be static to avoid chicken and egg situations, a project should not > influence settings. It should be the way around. > In subsequent ticket it will be verified that repo configuration does not > contain any expression: > https://github.com/apache/maven/commit/d411c3fa98832e7d86d901fe86ff63ba907cf868#commitcomment-44782281. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
[
https://issues.apache.org/jira/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300986#comment-17300986
]
Hudson commented on MNG-5639:
-
Build failed in Jenkins: Maven » Maven TLP » maven » maven-3.6.x #6
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.6.x/6/
> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> --
>
> Key: MNG-5639
> URL: https://issues.apache.org/jira/browse/MNG-5639
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.2.1
>Reporter: Mark Ingram
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.2.2
>
> Attachments: pom.xml
>
>
> Running mvn help:effective-pom on the attached POM:
> {noformat}[ERROR] The project
> com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
> (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not transfer artifact
> org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to
> spring-milestones (${spring.url}): No connector available to access
> repository spring-milestones (${spring.url}) of type default using the
> available factories WagonRepositoryConnectorFactory @ line 20, column 25 ->
> Help 2]{noformat}
> mvn help:effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution, the full project POM
> model has successfully been resolved. So the correct value for the property
> is known and could in theory be substituted into the repository URL before
> the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it
> includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the
> actual use case - several development streams are setup with individual
> sandboxed Nexus repository holding specific version of several shared
> components. The repository configuration uses the pattern
> $\{nexus.baseurl}/content/groups/$\{stream.name} with the properties set in
> settings.xml file.
> One workaround would be to create profiles for every work stream that
> explicitly list the full repository URL, even then the above feature would be
> nice to allow the $\{nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5781) resolution of nested import scoped dependencies causes maven to reach out to external central repo
[
https://issues.apache.org/jira/browse/MNG-5781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300981#comment-17300981
]
Ravi Sanwal commented on MNG-5781:
--
Thanks Michael. I hope you meant the other way around. The other ticket being
duplicate of this.
> resolution of nested import scoped dependencies causes maven to reach out to
> external central repo
> --
>
> Key: MNG-5781
> URL: https://issues.apache.org/jira/browse/MNG-5781
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build, Dependencies
>Affects Versions: 3.2.5
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T09:29:23-08:00)
> Maven home: /usr/local/maven-3.2.5
> Java version: 1.7.0_76, vendor: Oracle Corporation
> Java home: /usr/local/jdk1.7.0_76-server-jre/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-504.3.3.el6.centos.plus.x86_64", arch:
> "amd64", family: "unix"
>Reporter: Ravi Sanwal
>Priority: Major
> Fix For: 4.0.x-candidate
>
> Attachments: MNG-5781-Maven360.txt, first.pom.xml,
> global_settings.xml, last.pom.xml, second.pom.xml
>
>
> When a project uses a dependency that has as import scoped dependency, which
> in turn also has another import scoped dependency (nested imported scoped
> dependencies), resolution of the last level of dependency makes maven to
> reach our to the external central repository
> ([https://repo.maven.apache.org/maven2/])
> Steps to reproduce:
> Use the attached global settings file.
> It has an internal repository declared as a replacement to 'central', you can
> point to one of your own internal repo.(not the local)
> Build the attached file first.pom.xml:
> {code:java}
> mvn -gs global_settings.xml install -f first.pom.xml{code}
> Build the attached file second.pom.xml:
> {code:java}
> mvn install -f second.pom.xml{code}
> Then, delete _org.aspectj:aspectjtools from local repo (rm
> ~/.m2/repository/org/aspectj_/aspectjtools), we want to download this from
> our internal central repository alias repository.
> Build the attached file last.pom.xml:
> {code:java}
> mvn -gs global_settings.xml dependency:copy-dependencies -f last.pom.xml{code}
> (copy dependencies because this is a pom project, alternatively change
> last.pom.xml to a jar project and do mvn -gs global_settings.xml install -
> same thing)
> You'll see that org.aspectj:aspectjtools is being downloaded from central
> ([https://repo.maven.apache.org/maven2/]) effectively rendering hosting our
> own repositories useless.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6399) Lift JDK minimum to JDK 8
[ https://issues.apache.org/jira/browse/MNG-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300979#comment-17300979 ] Hudson commented on MNG-6399: - Build succeeded in Jenkins: Maven » Maven TLP » maven » master #119 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/119/ > Lift JDK minimum to JDK 8 > - > > Key: MNG-6399 > URL: https://issues.apache.org/jira/browse/MNG-6399 > Project: Maven > Issue Type: Task >Affects Versions: 3.6.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 4.0.0, 4.0.0-alpha-1 > > > I would like to lift the minimum of Maven Core to JDK 8 (I think it's time).. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-5552) Classified artifacts are missing from ${project.artifactMap}
[
https://issues.apache.org/jira/browse/MNG-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5552:
Fix Version/s: (was: 4.x / Backlog)
4.0.x-candidate
> Classified artifacts are missing from ${project.artifactMap}
>
>
> Key: MNG-5552
> URL: https://issues.apache.org/jira/browse/MNG-5552
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Igor Fedorenko
>Priority: Major
> Labels: needs-attention
> Fix For: 4.0.x-candidate
>
>
> Classified artifacts are missing from {{$\{project.artifactMap}}}, so I can't
> inject them all in my plugins or use
> {{$\{project.artifactMap(group:artifact:classifier)}}} to pick individual
> dependencies.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-compiler-plugin] mthmulders merged pull request #42: Grammar on 'Compiling Sources Using A Different JDK' page
mthmulders merged pull request #42: URL: https://github.com/apache/maven-compiler-plugin/pull/42 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-compiler-plugin] mthmulders commented on pull request #42: Grammar on 'Compiling Sources Using A Different JDK' page
mthmulders commented on pull request #42: URL: https://github.com/apache/maven-compiler-plugin/pull/42#issuecomment-798775494 Thank you! 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-compiler-plugin] mthmulders opened a new pull request #42: Grammar on 'Compiling Sources Using A Different JDK' page
mthmulders opened a new pull request #42: URL: https://github.com/apache/maven-compiler-plugin/pull/42 @elharo You're a native speaker, could you please verify? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-6012) Missing profile is only notified at the end of a run
[ https://issues.apache.org/jira/browse/MNG-6012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders closed MNG-6012. Assignee: Maarten Mulders > Missing profile is only notified at the end of a run > > > Key: MNG-6012 > URL: https://issues.apache.org/jira/browse/MNG-6012 > Project: Maven > Issue Type: New Feature >Affects Versions: 3.3.9 >Reporter: Sebb >Assignee: Maarten Mulders >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > A missing profile is only notified at the end of a run. > Since this may mean that the run is useless, it would be helpful if: > 1) It was also noted near the start, so the user could cancel the run. > It's still helpful at the end, as it saves scrolling back to see if there was > a problem. > 2) There were an option to fail a run if a profile is not found. This option > should be settable in a POM and in settings.xml -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MNG-6012) Missing profile is only notified at the end of a run
[ https://issues.apache.org/jira/browse/MNG-6012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders resolved MNG-6012. -- Fix Version/s: (was: 4.0.x-candidate) (was: needing-scrub-3.4.0-fallout) 4.0.0-alpha-1 4.0.0 Resolution: Fixed > Missing profile is only notified at the end of a run > > > Key: MNG-6012 > URL: https://issues.apache.org/jira/browse/MNG-6012 > Project: Maven > Issue Type: New Feature >Affects Versions: 3.3.9 >Reporter: Sebb >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > A missing profile is only notified at the end of a run. > Since this may mean that the run is useless, it would be helpful if: > 1) It was also noted near the start, so the user could cancel the run. > It's still helpful at the end, as it saves scrolling back to see if there was > a problem. > 2) There were an option to fail a run if a profile is not found. This option > should be settable in a POM and in settings.xml -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6012) Missing profile is only notified at the end of a run
[
https://issues.apache.org/jira/browse/MNG-6012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300959#comment-17300959
]
Maarten Mulders commented on MNG-6012:
--
{quote}[~mthmulders], I consider this resolved. WDYT?
{quote}
Yep, agreed, [~michael-o].
> Missing profile is only notified at the end of a run
>
>
> Key: MNG-6012
> URL: https://issues.apache.org/jira/browse/MNG-6012
> Project: Maven
> Issue Type: New Feature
>Affects Versions: 3.3.9
>Reporter: Sebb
>Priority: Major
> Fix For: 4.0.x-candidate, needing-scrub-3.4.0-fallout
>
>
> A missing profile is only notified at the end of a run.
> Since this may mean that the run is useless, it would be helpful if:
> 1) It was also noted near the start, so the user could cancel the run.
> It's still helpful at the end, as it saves scrolling back to see if there was
> a problem.
> 2) There were an option to fail a run if a profile is not found. This option
> should be settable in a POM and in settings.xml
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] michael-o commented on pull request #448: [MNG-7102] The child modules of excluded projects are now excluded
michael-o commented on pull request #448: URL: https://github.com/apache/maven/pull/448#issuecomment-798762538 I agree with @rfscholte that order should not matter because this would make it much more complex. According to his explanation exclusion should win? If so, I am fine with that. We do the same for resource matching, exclusion wins. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (MNG-6075) Increase the model validation level to the next minor level version
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MNG-6075: --- Assignee: Michael Osipov > Increase the model validation level to the next minor level version > --- > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Critical > Fix For: 4.0.x-candidate > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] MartinKanters commented on pull request #448: [MNG-7102] The child modules of excluded projects are now excluded
MartinKanters commented on pull request #448: URL: https://github.com/apache/maven/pull/448#issuecomment-798743205 I interpreted @michael-o 's suggestion as that the more specific project would win. But anyway, I guess if selection then exclusion is a hard rule, then that makes sense as well. It's easier to explain to people as well. So, are you on board with this, @michael-o ? Then we'll go ahead and rework this PR. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-5781) resolution of nested import scoped dependencies causes maven to reach out to external central repo
[
https://issues.apache.org/jira/browse/MNG-5781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300955#comment-17300955
]
Michael Osipov commented on MNG-5781:
-
This is basically a duplicate of MNG-6772 depicting the same problem.
> resolution of nested import scoped dependencies causes maven to reach out to
> external central repo
> --
>
> Key: MNG-5781
> URL: https://issues.apache.org/jira/browse/MNG-5781
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build, Dependencies
>Affects Versions: 3.2.5
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T09:29:23-08:00)
> Maven home: /usr/local/maven-3.2.5
> Java version: 1.7.0_76, vendor: Oracle Corporation
> Java home: /usr/local/jdk1.7.0_76-server-jre/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-504.3.3.el6.centos.plus.x86_64", arch:
> "amd64", family: "unix"
>Reporter: Ravi Sanwal
>Priority: Major
> Fix For: 4.0.x-candidate
>
> Attachments: MNG-5781-Maven360.txt, first.pom.xml,
> global_settings.xml, last.pom.xml, second.pom.xml
>
>
> When a project uses a dependency that has as import scoped dependency, which
> in turn also has another import scoped dependency (nested imported scoped
> dependencies), resolution of the last level of dependency makes maven to
> reach our to the external central repository
> ([https://repo.maven.apache.org/maven2/])
> Steps to reproduce:
> Use the attached global settings file.
> It has an internal repository declared as a replacement to 'central', you can
> point to one of your own internal repo.(not the local)
> Build the attached file first.pom.xml:
> {code:java}
> mvn -gs global_settings.xml install -f first.pom.xml{code}
> Build the attached file second.pom.xml:
> {code:java}
> mvn install -f second.pom.xml{code}
> Then, delete _org.aspectj:aspectjtools from local repo (rm
> ~/.m2/repository/org/aspectj_/aspectjtools), we want to download this from
> our internal central repository alias repository.
> Build the attached file last.pom.xml:
> {code:java}
> mvn -gs global_settings.xml dependency:copy-dependencies -f last.pom.xml{code}
> (copy dependencies because this is a pom project, alternatively change
> last.pom.xml to a jar project and do mvn -gs global_settings.xml install -
> same thing)
> You'll see that org.aspectj:aspectjtools is being downloaded from central
> ([https://repo.maven.apache.org/maven2/]) effectively rendering hosting our
> own repositories useless.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6012) Missing profile is only notified at the end of a run
[ https://issues.apache.org/jira/browse/MNG-6012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300956#comment-17300956 ] Michael Osipov commented on MNG-6012: - [~mthmulders], I consider this resolved. WDYT? > Missing profile is only notified at the end of a run > > > Key: MNG-6012 > URL: https://issues.apache.org/jira/browse/MNG-6012 > Project: Maven > Issue Type: New Feature >Affects Versions: 3.3.9 >Reporter: Sebb >Priority: Major > Fix For: 4.0.x-candidate, needing-scrub-3.4.0-fallout > > > A missing profile is only notified at the end of a run. > Since this may mean that the run is useless, it would be helpful if: > 1) It was also noted near the start, so the user could cancel the run. > It's still helpful at the end, as it saves scrolling back to see if there was > a problem. > 2) There were an option to fail a run if a profile is not found. This option > should be settable in a POM and in settings.xml -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6075) Increase the model validation level to the next minor level version
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6075: Summary: Increase the model validation level to the next minor level version (was: Increase the model validation level to the next minor level version.) > Increase the model validation level to the next minor level version > --- > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Priority: Critical > Fix For: 4.0.x-candidate > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-4347) import-scoped dependencies of direct dependencies are not resolved using profile modifications from settings.xml
[ https://issues.apache.org/jira/browse/MNG-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300944#comment-17300944 ] Michael Osipov commented on MNG-4347: - I believe this is related to MNG-6772 and may be resolved when MNG-4645 is completed. > import-scoped dependencies of direct dependencies are not resolved using > profile modifications from settings.xml > > > Key: MNG-4347 > URL: https://issues.apache.org/jira/browse/MNG-4347 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies, General, > Profiles, Settings >Affects Versions: 2.2.1 >Reporter: John Dennis Casey >Priority: Critical > Fix For: 2.2.2, 4.0.x-candidate > > > Given: > * project A lists project B as a dependency > * project B lists project C as an import-scoped entry in dependencyManagement > * project B's dependency version for project C is a SNAPSHOT > * the user's settings.xml file modifies the definition of the central > repository to enable searching for SNAPSHOT artifacts. > When project A's dependency POMs are retrieved as part of collecting the > transitive dependency closure for A, B's project instance is built. During > this process, the POM for project C should be retrieved from central > (according to the modifications in settings.xml). However, the profile > information from the settings.xml is never applied to project B's POM, and > never modifies the central repository definition found there. Since the > default definition for the repository 'central' from the super POM has > snapshots disabled, project C's POM cannot be found, and the build fails. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
[
https://issues.apache.org/jira/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300929#comment-17300929
]
Hudson commented on MNG-5639:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » master #118
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/118/
> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> --
>
> Key: MNG-5639
> URL: https://issues.apache.org/jira/browse/MNG-5639
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.2.1
>Reporter: Mark Ingram
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.2.2
>
> Attachments: pom.xml
>
>
> Running mvn help:effective-pom on the attached POM:
> {noformat}[ERROR] The project
> com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
> (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not transfer artifact
> org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to
> spring-milestones (${spring.url}): No connector available to access
> repository spring-milestones (${spring.url}) of type default using the
> available factories WagonRepositoryConnectorFactory @ line 20, column 25 ->
> Help 2]{noformat}
> mvn help:effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution, the full project POM
> model has successfully been resolved. So the correct value for the property
> is known and could in theory be substituted into the repository URL before
> the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it
> includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the
> actual use case - several development streams are setup with individual
> sandboxed Nexus repository holding specific version of several shared
> components. The repository configuration uses the pattern
> $\{nexus.baseurl}/content/groups/$\{stream.name} with the properties set in
> settings.xml file.
> One workaround would be to create profiles for every work stream that
> explicitly list the full repository URL, even then the above feature would be
> nice to allow the $\{nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7046) Revert MNG-5639 and make repo config static only
[ https://issues.apache.org/jira/browse/MNG-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300928#comment-17300928 ] Hudson commented on MNG-7046: - Build succeeded in Jenkins: Maven » Maven TLP » maven » master #118 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/118/ > Revert MNG-5639 and make repo config static only > > > Key: MNG-7046 > URL: https://issues.apache.org/jira/browse/MNG-7046 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories, Dependencies >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.x-candidate > > > As discussed in MNG-5639 repositories should always be known upfront, they > have to be static to avoid chicken and egg situations, a project should not > influence settings. It should be the way around. > In subsequent ticket it will be verified that repo configuration does not > contain any expression: > https://github.com/apache/maven/commit/d411c3fa98832e7d86d901fe86ff63ba907cf868#commitcomment-44782281. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300924#comment-17300924
]
Michael Osipov commented on MNG-6772:
-
An update on the matter: We (me, [~rfscholte], [~hboutemy]) are discussing a
common understanding of this issue and its implications. It is likely that
several issues were conflated here and we could come up with a different view
on this issue.
> Super POM overwrites remapped central repository in nested import POMs
> --
>
> Key: MNG-6772
> URL: https://issues.apache.org/jira/browse/MNG-6772
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, POM
>Affects Versions: 3.6.2
>Reporter: Eddie Wiegers
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} which is meant to
> specifically override the entry in the Super POM. This is specifically what
> [JFrog Artifactory
> recommends|https://www.jfrog.com/confluence/display/RTF/Maven+Repository#MavenRepository-ManuallyOverridingtheBuilt-inRepositories]
> doing, and seems valid in situations where the _real_ Maven Central may be
> unreachable.
>
> The override takes precedence almost all of the time. However, there is at
> least one scenario where this is not the case, and that is when importing a
> POM that in turn imports another POM.
>
> Digging into the code, it appears the reason this happens is because the
> {{DefaultModelBuilder}} overwrites repositories after interpolation is
> complete:
> [https://github.com/apache/maven/blob/53f04f03e3e58c75dcc791d557758357a6ec7983/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L411]
>
> From what I can tell, this is done with the intention of overwriting
> repositories that were added to the local resolver prior to interpolation
> with the interpolated version. Due to the way the {{DefaultModelResolver}}
> works, an unintended side effect is that the {{central}} repository from the
> Super POM is added once after each interpolation. The first time the
> repository is added, it is added to the {{repositoryIds}} but doesn't
> actually remove the original repository. The second time it is added is when
> the original repository will be replaced. Currently, the repositoryIds are
> preserved in the {{ModelResolver}} when resolving import POMs, leading to the
> behavior I am seeing where the second nested import POM ends up being where
> the failure occurs.
>
> I am planning on submitting a PR to clone the {{ModelResolver}} in a way that
> resets the repositoryIds prior to import POMs being resolved, since they are
> separate artifact builds. That seems like the most consistent fix to me that
> covers cases outside of the the Super POM's {{central}} definition.
>
> *Workarounds*:
> The current workaround is to use a repository ID other than {{central}} for
> my Artifactory repository, which isn't ideal since it leaves the potential
> for long timeouts to occur on the real {{central}} when an artifact can't be
> resolved from my Artifactory repository.
>
> Mirrors are not an ideal workaround since getting them in place on all
> possible build environments isn't trivial.
>
> When looking at the code I noticed
> {{RepositorySystemSession#isIgnoreArtifactDescriptorRepositories()}} being
> checked in various places, which seems like it would also act as a potential
> workaround, but I don't see a way to enable this value via MavenCLI or
> properties of any kind. It seems like this value aligns well with what
> Artifactory is already trying to enforce, so it would make sense to enable
> this in projects that intend to exclusively use Artifactory. Is there a
> supported way to set this value outside of constructing a Maven build in code?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-7094) Assure in an IT that reactor repository definitions are not used when Model Builder downloads dependencies with scope import
[ https://issues.apache.org/jira/browse/MNG-7094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7094: Description: Based on several discussions (MNG-6772, MNG-6397) the topic of repo scoping causes a lot of confusion. Create an IT which shows that repositories defined in a reactor are never available (inject) to download imported dependency BOMs. Thus all repos are properly scoped. was: Based on several discussions (MNG-6772, MNG-6397) the topic of repo scoping causes a lot of confusion. Create an IT which shows that repositories defined in a reactor are never available (leak) to download imported dependency BOMs. Thus all repos are properly scoped. > Assure in an IT that reactor repository definitions are not used when Model > Builder downloads dependencies with scope import > > > Key: MNG-7094 > URL: https://issues.apache.org/jira/browse/MNG-7094 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories, Dependencies, Design, > Patterns Best Practices, Integration Tests >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Priority: Major > Fix For: 4.0.x-candidate > > > Based on several discussions (MNG-6772, MNG-6397) the topic of repo scoping > causes a lot of confusion. > Create an IT which shows that repositories defined in a reactor are never > available (inject) to download imported dependency BOMs. Thus all repos are > properly scoped. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-7059) Add profile-free repository support in Maven Settings model
[ https://issues.apache.org/jira/browse/MNG-7059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7059: Fix Version/s: 4.0.x-candidate > Add profile-free repository support in Maven Settings model > --- > > Key: MNG-7059 > URL: https://issues.apache.org/jira/browse/MNG-7059 > Project: Maven > Issue Type: New Feature > Components: Settings >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Priority: Major > Fix For: 4.0.x-candidate > > > With MNG-4645 = the move of Maven Central repository definition out of [Super > POM|https://maven.apache.org/ref/3.6.3/maven-model-builder/super-pom.html] > into global settings, [current settings > model|https://maven.apache.org/ref/3.6.3/maven-settings/settings.html] forces > to use a profile, although central repository should be always there w/o a > profile. > Settings Model version 1.2.0 shall have native support for repositories w/o > the need to use profiles. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (MNG-7046) Revert MNG-5639 and make repo config static only
[ https://issues.apache.org/jira/browse/MNG-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reopened MNG-7046: - The fix will be reverted because it is incomplete. It causes issues with MNG-6772_2 branch. Also this revert did not take MNG-5663 into account. > Revert MNG-5639 and make repo config static only > > > Key: MNG-7046 > URL: https://issues.apache.org/jira/browse/MNG-7046 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories, Dependencies >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > As discussed in MNG-5639 repositories should always be known upfront, they > have to be static to avoid chicken and egg situations, a project should not > influence settings. It should be the way around. > In subsequent ticket it will be verified that repo configuration does not > contain any expression: > https://github.com/apache/maven/commit/d411c3fa98832e7d86d901fe86ff63ba907cf868#commitcomment-44782281. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-7046) Revert MNG-5639 and make repo config static only
[ https://issues.apache.org/jira/browse/MNG-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7046: Fix Version/s: (was: 4.0.0-alpha-1) (was: 4.0.0) 4.0.x-candidate > Revert MNG-5639 and make repo config static only > > > Key: MNG-7046 > URL: https://issues.apache.org/jira/browse/MNG-7046 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories, Dependencies >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.x-candidate > > > As discussed in MNG-5639 repositories should always be known upfront, they > have to be static to avoid chicken and egg situations, a project should not > influence settings. It should be the way around. > In subsequent ticket it will be verified that repo configuration does not > contain any expression: > https://github.com/apache/maven/commit/d411c3fa98832e7d86d901fe86ff63ba907cf868#commitcomment-44782281. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7110) Different behavior of extensions
[ https://issues.apache.org/jira/browse/MNG-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300866#comment-17300866 ] Hudson commented on MNG-7110: - Build unstable in Jenkins: Maven » Maven TLP » maven » MRESOLVER-157 #7 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MRESOLVER-157/7/ > Different behavior of extensions > > > Key: MNG-7110 > URL: https://issues.apache.org/jira/browse/MNG-7110 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.x-candidate >Reporter: Mirko Friedenhagen >Assignee: Robert Scholte >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > * In my POM I configured the net.rumati.maven.plugins:velocity-maven-plugin > which should render a HTML file. > * The parent of the project has a global extension in the build section. > * The jar of the extension does include a velocity which is picked up quite > fine by the velocity-maven-plugin from > the classpath by 3.6.3 but when using 4.0.0 I now need to add the extension > jar as a dependency to the plugin. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7051) Optionally skip non-existing profiles
[
https://issues.apache.org/jira/browse/MNG-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300865#comment-17300865
]
Hudson commented on MNG-7051:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MRESOLVER-157 #7
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MRESOLVER-157/7/
> Optionally skip non-existing profiles
> -
>
> Key: MNG-7051
> URL: https://issues.apache.org/jira/browse/MNG-7051
> Project: Maven
> Issue Type: Sub-task
> Components: Profiles
>Reporter: Maarten Mulders
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> For Maven 4, the behaviour of the {{-P}} command line option will change:
> * {{-P apache-release}} will activate the *apache-release* profile. If such
> a profile cannot be found, the build will break.
> * {{-P ?apache-release}} will activate the *apache-release* profile. If such
> a profile cannot be found, the build will continue but log a warning.
> {color:#ff}
> Note that this breaks the current behaviour of Maven 3 in two ways:
> {color}
> # {{-P apache-release}} will currently log a warning and not break the build.
> That behaviour can be restored by adding the {{?}}.
> # A profile that has an identifier that not valid (i.e., contains anything
> else than {{a}} - {{z}}, {{A}} to {{Z}}, {{0}} - {{9}}, {{-}}, {{_}} or
> {{.}}) will break the build.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MNG-7087) Maven 4 can't build itself with Java 11
[
https://issues.apache.org/jira/browse/MNG-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders reassigned MNG-7087:
Assignee: Robert Scholte
> Maven 4 can't build itself with Java 11
> ---
>
> Key: MNG-7087
> URL: https://issues.apache.org/jira/browse/MNG-7087
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1
> Environment: Apache Maven 4.0.0-alpha-1-SNAPSHOT
> (bb916d0784c7631866167928e4d0615df3317567)
> Java version: 11.0.10, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
>Reporter: Maarten Mulders
>Assignee: Robert Scholte
>Priority: Blocker
> Fix For: 4.0.0, 4.0.0-alpha-1
>
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> It's not possible to build Maven HEAD (I've tested with rev. bb916d0) using a
> recent Maven 4 snapshot. Even {{mvn validate}} doesn't succeed:
> {code}
> [INFO] Scanning for projects...
> ERROR: ''
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must
> be unique: org.junit.jupiter:junit-jupiter-params:jar -> version
> ${junitVersion} vs 5.7.0 @ line 77, column 17
> [FATAL] input contained no data @
> @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project
> (/Users/maarten/Code/open-source/maven/maven/maven-model-builder/pom.xml) has
> 1 error
> [ERROR] input contained no data
> [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
> {code}
> I've done `git bisect` (first time, I hope I did it correctly):
> {code}
> 9f88494b6064ad45ea2e2e1e3478afc7af0bc065 is the first bad commit
> Author: rfscholte
> Date: Mon Dec 21 22:23:43 2020 +0100
> [MNG-6957] Versionless reactor dependencies/parent should work even if
> modules are aggregated in reverse order
>
> This closes #391
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-7087) Maven 4 can't build itself with Java 11
[
https://issues.apache.org/jira/browse/MNG-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders closed MNG-7087.
> Maven 4 can't build itself with Java 11
> ---
>
> Key: MNG-7087
> URL: https://issues.apache.org/jira/browse/MNG-7087
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1
> Environment: Apache Maven 4.0.0-alpha-1-SNAPSHOT
> (bb916d0784c7631866167928e4d0615df3317567)
> Java version: 11.0.10, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
>Reporter: Maarten Mulders
>Assignee: Robert Scholte
>Priority: Blocker
> Fix For: 4.0.0, 4.0.0-alpha-1
>
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> It's not possible to build Maven HEAD (I've tested with rev. bb916d0) using a
> recent Maven 4 snapshot. Even {{mvn validate}} doesn't succeed:
> {code}
> [INFO] Scanning for projects...
> ERROR: ''
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must
> be unique: org.junit.jupiter:junit-jupiter-params:jar -> version
> ${junitVersion} vs 5.7.0 @ line 77, column 17
> [FATAL] input contained no data @
> @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project
> (/Users/maarten/Code/open-source/maven/maven/maven-model-builder/pom.xml) has
> 1 error
> [ERROR] input contained no data
> [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
> {code}
> I've done `git bisect` (first time, I hope I did it correctly):
> {code}
> 9f88494b6064ad45ea2e2e1e3478afc7af0bc065 is the first bad commit
> Author: rfscholte
> Date: Mon Dec 21 22:23:43 2020 +0100
> [MNG-6957] Versionless reactor dependencies/parent should work even if
> modules are aggregated in reverse order
>
> This closes #391
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MNG-7087) Maven 4 can't build itself with Java 11
[
https://issues.apache.org/jira/browse/MNG-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders resolved MNG-7087.
--
Fix Version/s: (was: 4.0.x-candidate)
4.0.0-alpha-1
4.0.0
Resolution: Fixed
> Maven 4 can't build itself with Java 11
> ---
>
> Key: MNG-7087
> URL: https://issues.apache.org/jira/browse/MNG-7087
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1
> Environment: Apache Maven 4.0.0-alpha-1-SNAPSHOT
> (bb916d0784c7631866167928e4d0615df3317567)
> Java version: 11.0.10, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
>Reporter: Maarten Mulders
>Priority: Blocker
> Fix For: 4.0.0, 4.0.0-alpha-1
>
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> It's not possible to build Maven HEAD (I've tested with rev. bb916d0) using a
> recent Maven 4 snapshot. Even {{mvn validate}} doesn't succeed:
> {code}
> [INFO] Scanning for projects...
> ERROR: ''
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must
> be unique: org.junit.jupiter:junit-jupiter-params:jar -> version
> ${junitVersion} vs 5.7.0 @ line 77, column 17
> [FATAL] input contained no data @
> @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project
> (/Users/maarten/Code/open-source/maven/maven/maven-model-builder/pom.xml) has
> 1 error
> [ERROR] input contained no data
> [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
> {code}
> I've done `git bisect` (first time, I hope I did it correctly):
> {code}
> 9f88494b6064ad45ea2e2e1e3478afc7af0bc065 is the first bad commit
> Author: rfscholte
> Date: Mon Dec 21 22:23:43 2020 +0100
> [MNG-6957] Versionless reactor dependencies/parent should work even if
> modules are aggregated in reverse order
>
> This closes #391
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7087) Maven 4 can't build itself with Java 11
[
https://issues.apache.org/jira/browse/MNG-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300822#comment-17300822
]
Maarten Mulders commented on MNG-7087:
--
Can confirm the issue is fixed with
{code:java}
Apache Maven 4.0.0-alpha-1-SNAPSHOT (9e19b57c720d226b0b30992535819f700a665d14)
Maven home: /usr/local/Cellar/maven-snapshot/4.0.0-alpha-1-SNAPSHOT_117/libexec
Java version: 11.0.10, vendor: AdoptOpenJDK, runtime:
/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "10.15.7", arch: "x86_64", family: "mac" {code}
> Maven 4 can't build itself with Java 11
> ---
>
> Key: MNG-7087
> URL: https://issues.apache.org/jira/browse/MNG-7087
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1
> Environment: Apache Maven 4.0.0-alpha-1-SNAPSHOT
> (bb916d0784c7631866167928e4d0615df3317567)
> Java version: 11.0.10, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
>Reporter: Maarten Mulders
>Priority: Blocker
> Fix For: 4.0.x-candidate
>
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> It's not possible to build Maven HEAD (I've tested with rev. bb916d0) using a
> recent Maven 4 snapshot. Even {{mvn validate}} doesn't succeed:
> {code}
> [INFO] Scanning for projects...
> ERROR: ''
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must
> be unique: org.junit.jupiter:junit-jupiter-params:jar -> version
> ${junitVersion} vs 5.7.0 @ line 77, column 17
> [FATAL] input contained no data @
> @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project
> (/Users/maarten/Code/open-source/maven/maven/maven-model-builder/pom.xml) has
> 1 error
> [ERROR] input contained no data
> [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
> {code}
> I've done `git bisect` (first time, I hope I did it correctly):
> {code}
> 9f88494b6064ad45ea2e2e1e3478afc7af0bc065 is the first bad commit
> Author: rfscholte
> Date: Mon Dec 21 22:23:43 2020 +0100
> [MNG-6957] Versionless reactor dependencies/parent should work even if
> modules are aggregated in reverse order
>
> This closes #391
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7087) Maven 4 can't build itself with Java 11
[
https://issues.apache.org/jira/browse/MNG-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300807#comment-17300807
]
Robert Scholte commented on MNG-7087:
-
I've merged MNG-7111, now I cannot reproduce this issue anymore. Please confirm
> Maven 4 can't build itself with Java 11
> ---
>
> Key: MNG-7087
> URL: https://issues.apache.org/jira/browse/MNG-7087
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1
> Environment: Apache Maven 4.0.0-alpha-1-SNAPSHOT
> (bb916d0784c7631866167928e4d0615df3317567)
> Java version: 11.0.10, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
>Reporter: Maarten Mulders
>Priority: Blocker
> Fix For: 4.0.x-candidate
>
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> It's not possible to build Maven HEAD (I've tested with rev. bb916d0) using a
> recent Maven 4 snapshot. Even {{mvn validate}} doesn't succeed:
> {code}
> [INFO] Scanning for projects...
> ERROR: ''
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must
> be unique: org.junit.jupiter:junit-jupiter-params:jar -> version
> ${junitVersion} vs 5.7.0 @ line 77, column 17
> [FATAL] input contained no data @
> @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project
> (/Users/maarten/Code/open-source/maven/maven/maven-model-builder/pom.xml) has
> 1 error
> [ERROR] input contained no data
> [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
> {code}
> I've done `git bisect` (first time, I hope I did it correctly):
> {code}
> 9f88494b6064ad45ea2e2e1e3478afc7af0bc065 is the first bad commit
> Author: rfscholte
> Date: Mon Dec 21 22:23:43 2020 +0100
> [MNG-6957] Versionless reactor dependencies/parent should work even if
> modules are aggregated in reverse order
>
> This closes #391
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7111) Deadlock when reading pom
[
https://issues.apache.org/jira/browse/MNG-7111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300804#comment-17300804
]
Hudson commented on MNG-7111:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » master #117
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/117/
> Deadlock when reading pom
> -
>
> Key: MNG-7111
> URL: https://issues.apache.org/jira/browse/MNG-7111
> Project: Maven
> Issue Type: Task
>Reporter: Guillaume Nodet
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> I'm running into the following deadlock while building Apache Camel with the
> current master:
> {code}
> "TransformThread-16@4333" daemon prio=5 tid=0x20 nid=NA waiting
> java.lang.Thread.State: WAITING
>blocks TransformThread-17@4342
> at java.lang.Object.wait(Object.java:-1)
> at java.io.PipedInputStream.read(PipedInputStream.java:326)
> at java.io.PipedInputStream.read(PipedInputStream.java:377)
> at java.io.FilterInputStream.read(FilterInputStream.java:133)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:252)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:271)
> - locked <0x1163> (a java.io.BufferedInputStream)
> at
> org.codehaus.plexus.util.xml.XmlReader.getBOMEncoding(XmlReader.java:620)
> at
> org.codehaus.plexus.util.xml.XmlReader.doRawStream(XmlReader.java:440)
> at org.codehaus.plexus.util.xml.XmlReader.(XmlReader.java:178)
> at org.codehaus.plexus.util.xml.XmlReader.(XmlReader.java:145)
> at
> org.codehaus.plexus.util.xml.XmlStreamReader.(XmlStreamReader.java:84)
> at
> org.codehaus.plexus.util.ReaderFactory.newXmlReader(ReaderFactory.java:109)
> at
> org.apache.maven.model.io.DefaultModelReader.read(DefaultModelReader.java:116)
> at
> org.apache.maven.model.io.DefaultModelReader.read(DefaultModelReader.java:90)
> at
> org.apache.maven.model.building.DefaultModelProcessor.read(DefaultModelProcessor.java:97)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readRawModel(DefaultModelBuilder.java:736)
> at
> org.apache.maven.model.building.DefaultModelBuilder.access$200(DefaultModelBuilder.java:99)
> at
> org.apache.maven.model.building.DefaultModelBuilder$DefaultTransformerContextBuilder$1.findRawModel(DefaultModelBuilder.java:1588)
> at
> org.apache.maven.model.building.DefaultModelBuilder$DefaultTransformerContextBuilder$1.lambda$getRawModel$1(DefaultModelBuilder.java:1570)
> at
> org.apache.maven.model.building.DefaultModelBuilder$DefaultTransformerContextBuilder$1$$Lambda$129.1344264523.apply(Unknown
> Source:-1)
> at
> java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1705)
> - locked <0x115e> (a
> java.util.concurrent.ConcurrentHashMap$ReservationNode)
> at
> org.apache.maven.model.building.DefaultModelBuilder$DefaultTransformerContextBuilder$1.getRawModel(DefaultModelBuilder.java:1569)
> at
> org.apache.maven.model.building.DefaultBuildPomXMLFilterFactory.lambda$getDependencyKeyToVersionMapper$3(DefaultBuildPomXMLFilterFactory.java:67)
> at
> org.apache.maven.model.building.DefaultBuildPomXMLFilterFactory$$Lambda$87.1867108691.apply(Unknown
> Source:-1)
> at
> org.apache.maven.xml.sax.filter.ReactorDependencyXMLFilter.getVersion(ReactorDependencyXMLFilter.java:156)
> at
> org.apache.maven.xml.sax.filter.ReactorDependencyXMLFilter.endElement(ReactorDependencyXMLFilter.java:112)
> at
> org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:570)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:610)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1718)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2883)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:534)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:888)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:824)
> at
>
[GitHub] [maven] rfscholte closed pull request #442: [MNG-7111] Fix maven parallel builds
rfscholte closed pull request #442: URL: https://github.com/apache/maven/pull/442 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] rfscholte commented on pull request #442: [MNG-7111] Fix maven parallel builds
rfscholte commented on pull request #442: URL: https://github.com/apache/maven/pull/442#issuecomment-798157524 Merged with https://github.com/apache/maven/commit/9e19b57c720d226b0b30992535819f700a665d14 Thanks for this PR! 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-7111) Deadlock when reading pom
[
https://issues.apache.org/jira/browse/MNG-7111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-7111.
---
Fix Version/s: 4.0.0-alpha-1
4.0.0
Assignee: Robert Scholte
Resolution: Fixed
Fix in
[9e19b57c720d226b0b30992535819f700a665d14|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=9e19b57c720d226b0b30992535819f700a665d14]
> Deadlock when reading pom
> -
>
> Key: MNG-7111
> URL: https://issues.apache.org/jira/browse/MNG-7111
> Project: Maven
> Issue Type: Task
>Reporter: Guillaume Nodet
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> I'm running into the following deadlock while building Apache Camel with the
> current master:
> {code}
> "TransformThread-16@4333" daemon prio=5 tid=0x20 nid=NA waiting
> java.lang.Thread.State: WAITING
>blocks TransformThread-17@4342
> at java.lang.Object.wait(Object.java:-1)
> at java.io.PipedInputStream.read(PipedInputStream.java:326)
> at java.io.PipedInputStream.read(PipedInputStream.java:377)
> at java.io.FilterInputStream.read(FilterInputStream.java:133)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:252)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:271)
> - locked <0x1163> (a java.io.BufferedInputStream)
> at
> org.codehaus.plexus.util.xml.XmlReader.getBOMEncoding(XmlReader.java:620)
> at
> org.codehaus.plexus.util.xml.XmlReader.doRawStream(XmlReader.java:440)
> at org.codehaus.plexus.util.xml.XmlReader.(XmlReader.java:178)
> at org.codehaus.plexus.util.xml.XmlReader.(XmlReader.java:145)
> at
> org.codehaus.plexus.util.xml.XmlStreamReader.(XmlStreamReader.java:84)
> at
> org.codehaus.plexus.util.ReaderFactory.newXmlReader(ReaderFactory.java:109)
> at
> org.apache.maven.model.io.DefaultModelReader.read(DefaultModelReader.java:116)
> at
> org.apache.maven.model.io.DefaultModelReader.read(DefaultModelReader.java:90)
> at
> org.apache.maven.model.building.DefaultModelProcessor.read(DefaultModelProcessor.java:97)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readRawModel(DefaultModelBuilder.java:736)
> at
> org.apache.maven.model.building.DefaultModelBuilder.access$200(DefaultModelBuilder.java:99)
> at
> org.apache.maven.model.building.DefaultModelBuilder$DefaultTransformerContextBuilder$1.findRawModel(DefaultModelBuilder.java:1588)
> at
> org.apache.maven.model.building.DefaultModelBuilder$DefaultTransformerContextBuilder$1.lambda$getRawModel$1(DefaultModelBuilder.java:1570)
> at
> org.apache.maven.model.building.DefaultModelBuilder$DefaultTransformerContextBuilder$1$$Lambda$129.1344264523.apply(Unknown
> Source:-1)
> at
> java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1705)
> - locked <0x115e> (a
> java.util.concurrent.ConcurrentHashMap$ReservationNode)
> at
> org.apache.maven.model.building.DefaultModelBuilder$DefaultTransformerContextBuilder$1.getRawModel(DefaultModelBuilder.java:1569)
> at
> org.apache.maven.model.building.DefaultBuildPomXMLFilterFactory.lambda$getDependencyKeyToVersionMapper$3(DefaultBuildPomXMLFilterFactory.java:67)
> at
> org.apache.maven.model.building.DefaultBuildPomXMLFilterFactory$$Lambda$87.1867108691.apply(Unknown
> Source:-1)
> at
> org.apache.maven.xml.sax.filter.ReactorDependencyXMLFilter.getVersion(ReactorDependencyXMLFilter.java:156)
> at
> org.apache.maven.xml.sax.filter.ReactorDependencyXMLFilter.endElement(ReactorDependencyXMLFilter.java:112)
> at
> org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:570)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:610)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1718)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2883)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:534)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:888)
> at
>
[GitHub] [maven-surefire] rmannibucau commented on a change in pull request #340: [SUREFIRE-1892] ensure systemPropertyVariables values are stringified
rmannibucau commented on a change in pull request #340:
URL: https://github.com/apache/maven-surefire/pull/340#discussion_r593720594
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -3623,9 +3623,20 @@ public void setSystemProperties( Properties
systemProperties )
}
@SuppressWarnings( "UnusedDeclaration" )
-public void setSystemPropertyVariables( Map
systemPropertyVariables )
+public void setSystemPropertyVariables( Map
systemPropertyVariables )
{
-this.systemPropertyVariables = systemPropertyVariables;
+if (systemPropertyVariables != null)
+{
+this.systemPropertyVariables = new HashMap<>();
+for ( final Map.Entry entry :
systemPropertyVariables.entrySet() )
+{
+this.systemPropertyVariables.put( entry.getKey(),
String.valueOf( entry.getValue() ) );
Review comment:
About java 8: it is maven 4 time since it is already set to 8 but not
v3, agree.
About why setter is saner than any other "flow" method: because class is
public+abstract and getter as well so it is part of the contract of the class
to convert it in the setter - as you said on slack - and not later on in the
flow which can be missed by the contract. So we actually don't have much
choice. We can create an utility but as mentionned I think it is worse than
duplicating the inline test IMHO so think we are good.
Now if you want to fix it differently I'll not fight while it behaves the
same.
side note: i'll not get time this week end/start of next week to modify this
PR and can be slow to answer.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #340: [SUREFIRE-1892] ensure systemPropertyVariables values are stringified
Tibor17 commented on a change in pull request #340:
URL: https://github.com/apache/maven-surefire/pull/340#discussion_r593718690
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -3623,9 +3623,20 @@ public void setSystemProperties( Properties
systemProperties )
}
@SuppressWarnings( "UnusedDeclaration" )
-public void setSystemPropertyVariables( Map
systemPropertyVariables )
+public void setSystemPropertyVariables( Map
systemPropertyVariables )
{
-this.systemPropertyVariables = systemPropertyVariables;
+if (systemPropertyVariables != null)
+{
+this.systemPropertyVariables = new HashMap<>();
+for ( final Map.Entry entry :
systemPropertyVariables.entrySet() )
+{
+this.systemPropertyVariables.put( entry.getKey(),
String.valueOf( entry.getValue() ) );
Review comment:
I don't know what you mean since we said many things.
j8 is in the project due to the JUnit5 but the compiler has target j7, and
all the [core plugins](https://maven.apache.org/plugins/) are at j7. We all
know that there will be one day when Maven and the core plugins will be
alligned with the same java version.
IMO the refactiring where you **reuse and safely move** an important method
[copyProperties](https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/SurefireProperties.java#L168)
to your place where you need to have the fix can be freely done as a good fix.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #340: [SUREFIRE-1892] ensure systemPropertyVariables values are stringified
Tibor17 commented on a change in pull request #340:
URL: https://github.com/apache/maven-surefire/pull/340#discussion_r593718690
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -3623,9 +3623,20 @@ public void setSystemProperties( Properties
systemProperties )
}
@SuppressWarnings( "UnusedDeclaration" )
-public void setSystemPropertyVariables( Map
systemPropertyVariables )
+public void setSystemPropertyVariables( Map
systemPropertyVariables )
{
-this.systemPropertyVariables = systemPropertyVariables;
+if (systemPropertyVariables != null)
+{
+this.systemPropertyVariables = new HashMap<>();
+for ( final Map.Entry entry :
systemPropertyVariables.entrySet() )
+{
+this.systemPropertyVariables.put( entry.getKey(),
String.valueOf( entry.getValue() ) );
Review comment:
I don't know what you mean since we said many things.
j8 is in the project due to the JUnit5 but the compiler ha target j7, and
all the [core plugins](https://maven.apache.org/plugins/) are at j7. We all
know that there will be one day when Maven and the core plugins will be
alligned with the same java version.
IMO the refactiring where you **reuse and safely move** an important method
[copyProperties](https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/SurefireProperties.java#L168)
to your place where you need to have the fix can be freely done as a good fix.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
