[jira] [Comment Edited] (MNG-6054) Remove super POM plugin management section
[ https://issues.apache.org/jira/browse/MNG-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315083#comment-16315083 ] Hervé Boutemy edited comment on MNG-6054 at 1/7/18 7:25 AM: continued thinking: perhaps the behaviour on WARN when plugin version not locked should be changed a little bit on CLI invocation, just add an INFO message "using version XXX", since CLI is by definition not reproducible (and ideally, could even propose to choose from a list) on plugin bound to a build phase, the current WARN is the good behaviour: it's not reproducible when it should no idea if the CLI invocation feature would be easy or hard to implement... was (Author: hboutemy): continued thinking: perhaps the behaviour on WARN when plugin version not locked should be changed a little bit on CLI invocation, just add an INFO message "using version XXX", since CLI is by definition not reproducible (and ideally, could even propose to choose from a list) on plugin bound to a build phase, the current WARN is the good behaviour: it's not reproducible when it should > Remove super POM plugin management section > -- > > Key: MNG-6054 > URL: https://issues.apache.org/jira/browse/MNG-6054 > Project: Maven > Issue Type: Task >Affects Versions: 3.3.9 >Reporter: Christian Schulte >Priority: Trivial > Fix For: needing-scrub-3.4.0-fallout > > > The super POM contains various plugins in the plugin management not part of > any default lifecycle. These should be removed from the super POM. > see http://maven.apache.org/ref/3.5.2/maven-model-builder/super-pom.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6054) Remove super POM plugin management section
[ https://issues.apache.org/jira/browse/MNG-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315083#comment-16315083 ] Hervé Boutemy commented on MNG-6054: continued thinking: perhaps the behaviour on WARN when plugin version not locked should be changed a little bit on CLI invocation, just add an INFO message "using version XXX", since CLI is by definition not reproducible (and ideally, could even propose to choose from a list) on plugin bound to a build phase, the current WARN is the good behaviour: it's not reproducible when it should > Remove super POM plugin management section > -- > > Key: MNG-6054 > URL: https://issues.apache.org/jira/browse/MNG-6054 > Project: Maven > Issue Type: Task >Affects Versions: 3.3.9 >Reporter: Christian Schulte >Priority: Trivial > Fix For: needing-scrub-3.4.0-fallout > > > The super POM contains various plugins in the plugin management not part of > any default lifecycle. These should be removed from the super POM. > see http://maven.apache.org/ref/3.5.2/maven-model-builder/super-pom.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6335) Update test framework Mockito from 1.10 to 2.12
[ https://issues.apache.org/jira/browse/MNG-6335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MNG-6335: --- Fix Version/s: 3.5.3-candidate > Update test framework Mockito from 1.10 to 2.12 > --- > > Key: MNG-6335 > URL: https://issues.apache.org/jira/browse/MNG-6335 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 3.5.2 >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.5.3-candidate > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6335) Update test framework Mockito from 1.10 to 2.12
[ https://issues.apache.org/jira/browse/MNG-6335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MNG-6335: --- Affects Version/s: 3.5.2 > Update test framework Mockito from 1.10 to 2.12 > --- > > Key: MNG-6335 > URL: https://issues.apache.org/jira/browse/MNG-6335 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 3.5.2 >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.5.3-candidate > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6054) Remove super POM plugin management section
[ https://issues.apache.org/jira/browse/MNG-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315076#comment-16315076 ] Hervé Boutemy commented on MNG-6054: after linking to a few Jira issues that help remember how we get there (MNG-3395, MNG-4453) I also verified the list of non-lifecycle bound plugins defined in Maven parent POM: - maven-antrun-plugin - maven-assembly-plugin - maven-dependency-plugin - maven-release-plugin AFAIK, antrun and assembly don't make sense as direct goal invocation: removing default version in Super POM could be better than providing one version (and discussing if we should update it from Maven core version to Maven core version or not) For dependency and release, direct goal invocation make sense: re-thinking at it, I'm not sure this fact changes the evaluation on "should we provide a default version" analyzing: providing a default version in Super POM permits to avoid a WARN message when user did not configure his choice of plugin version (since the Super POM de-facto provided a plugin version). It gives a better user experience for newbies or lazy situations, but it does not help people make their choice: relying on a default version defined by Maven core is risky for stability over time. On these 4 plugins, I would perhaps only keep dependency since it's often used as CLI, and the risk on stability seems quite low. But for the 3 others, ensuring stability seems a higher priority: removing them would be finally an improvement, even if it starts by hurting people used to rely on the long habit of getting a default version. And for sure, while at it, removing the 4th one... I'm torn. But really, permitting "mvn dependency:analyze" without getting a WARN (given it's not so often that you use dependency plugin in the build) is a useful UX > Remove super POM plugin management section > -- > > Key: MNG-6054 > URL: https://issues.apache.org/jira/browse/MNG-6054 > Project: Maven > Issue Type: Task >Affects Versions: 3.3.9 >Reporter: Christian Schulte >Priority: Trivial > Fix For: needing-scrub-3.4.0-fallout > > > The super POM contains various plugins in the plugin management not part of > any default lifecycle. These should be removed from the super POM. > see http://maven.apache.org/ref/3.5.2/maven-model-builder/super-pom.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MNG-6054) Remove super POM plugin management section
[ https://issues.apache.org/jira/browse/MNG-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315074#comment-16315074 ] Hervé Boutemy edited comment on MNG-6054 at 1/7/18 6:44 AM: I'm not sure this is a good idea: AFAIK, these plugins are plugins that are usually invoked as direct goal from CLI (or at least some of these plugins) Then providing default versions makes as much sense as providing default versions for build lifecycle plugins (ie. it can be discussed, since users should explicitely choose their version through pluginManagement) was (Author: hboutemy): I'm not sure this is a good idea: AFAIK, these plugins are plugins that are usually invoked as direct goal from CLI Then providing default versions makes s much sense as providing default versions for build lifecycle plugins (ie. it can be discussed, since users should explicitely choose their version through pluginManagement) > Remove super POM plugin management section > -- > > Key: MNG-6054 > URL: https://issues.apache.org/jira/browse/MNG-6054 > Project: Maven > Issue Type: Task >Affects Versions: 3.3.9 >Reporter: Christian Schulte >Priority: Trivial > Fix For: needing-scrub-3.4.0-fallout > > > The super POM contains various plugins in the plugin management not part of > any default lifecycle. These should be removed from the super POM. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6054) Remove super POM plugin management section
[ https://issues.apache.org/jira/browse/MNG-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MNG-6054: --- Description: The super POM contains various plugins in the plugin management not part of any default lifecycle. These should be removed from the super POM. see http://maven.apache.org/ref/3.5.2/maven-model-builder/super-pom.html was: The super POM contains various plugins in the plugin management not part of any default lifecycle. These should be removed from the super POM. > Remove super POM plugin management section > -- > > Key: MNG-6054 > URL: https://issues.apache.org/jira/browse/MNG-6054 > Project: Maven > Issue Type: Task >Affects Versions: 3.3.9 >Reporter: Christian Schulte >Priority: Trivial > Fix For: needing-scrub-3.4.0-fallout > > > The super POM contains various plugins in the plugin management not part of > any default lifecycle. These should be removed from the super POM. > see http://maven.apache.org/ref/3.5.2/maven-model-builder/super-pom.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6054) Remove super POM plugin management section
[ https://issues.apache.org/jira/browse/MNG-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315074#comment-16315074 ] Hervé Boutemy commented on MNG-6054: I'm not sure this is a good idea: AFAIK, these plugins are plugins that are usually invoked as direct goal from CLI Then providing default versions makes s much sense as providing default versions for build lifecycle plugins (ie. it can be discussed, since users should explicitely choose their version through pluginManagement) > Remove super POM plugin management section > -- > > Key: MNG-6054 > URL: https://issues.apache.org/jira/browse/MNG-6054 > Project: Maven > Issue Type: Task >Affects Versions: 3.3.9 >Reporter: Christian Schulte >Priority: Trivial > Fix For: needing-scrub-3.4.0-fallout > > > The super POM contains various plugins in the plugin management not part of > any default lifecycle. These should be removed from the super POM. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-5968) plugin version updates in Maven core build
[
https://issues.apache.org/jira/browse/MNG-5968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315072#comment-16315072
]
ASF GitHub Bot commented on MNG-5968:
-
Github user hboutemy commented on the issue:
https://github.com/apache/maven/pull/151
other topics:
- MNG-5968 is closed
- MNG-5968 is not about default plugins versions, but about Maven core build
if you rework this PR to focus on MNG-5992, ie providing a more secure
maven-release-plugin by default in Super POM, I would push this one
If you want to update other plugins, please consider other PRs with other
Jira issues, since I will challenge the change seriously :)
> plugin version updates in Maven core build
> --
>
> Key: MNG-5968
> URL: https://issues.apache.org/jira/browse/MNG-5968
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.3.9
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.5.0-alpha-1, 3.5.0
>
>
> upgrade some plugins in Maven core build (pom.xml), just because newest are
> expected to be better (no known bug):
> ||groupId||artifactId||previous version||target version||
> |{{org.codehaus.mojo}}|{{buildnumber-maven-plugincol}}|1.2|1.4|
> |{{org.codehaus.mojo}}|{{animal-sniffer-maven-plugin}}|1.14|1.15|
> |{{org.apache.maven.plugins}}|{{maven-doap-plugin}}|1.1|1.2|
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-5968) plugin version updates in Maven core build
[
https://issues.apache.org/jira/browse/MNG-5968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315068#comment-16315068
]
ASF GitHub Bot commented on MNG-5968:
-
Github user hboutemy commented on the issue:
https://github.com/apache/maven/pull/151
I'm not a fan of default plugins updates in core:
- depending on default versions is a bad practice, we expect users to
explicitely choose their version through pluginManagement (and we display a big
WARNING in case they don't do it)
- it changes behaviour when switching from one mvn version to the other
then IMHO changing default plugins version should really be driven by key
issues that we really want to avoid for untrained people (who don't know the
requirement to define their choice): for example MNG-5992 would such an
exception (default security is more important than helping people know that
they need to choose their plugins versions by letting old plugins versions by
default)
> plugin version updates in Maven core build
> --
>
> Key: MNG-5968
> URL: https://issues.apache.org/jira/browse/MNG-5968
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.3.9
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.5.0-alpha-1, 3.5.0
>
>
> upgrade some plugins in Maven core build (pom.xml), just because newest are
> expected to be better (no known bug):
> ||groupId||artifactId||previous version||target version||
> |{{org.codehaus.mojo}}|{{buildnumber-maven-plugincol}}|1.2|1.4|
> |{{org.codehaus.mojo}}|{{animal-sniffer-maven-plugin}}|1.14|1.15|
> |{{org.apache.maven.plugins}}|{{maven-doap-plugin}}|1.1|1.2|
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-5968) plugin version updates in Maven core build
[
https://issues.apache.org/jira/browse/MNG-5968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315025#comment-16315025
]
ASF GitHub Bot commented on MNG-5968:
-
Github user slachiewicz commented on the issue:
https://github.com/apache/maven/pull/151
I found this changes in abdoned 3.4 line. Should also fix MNG-5992
> plugin version updates in Maven core build
> --
>
> Key: MNG-5968
> URL: https://issues.apache.org/jira/browse/MNG-5968
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.3.9
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.5.0-alpha-1, 3.5.0
>
>
> upgrade some plugins in Maven core build (pom.xml), just because newest are
> expected to be better (no known bug):
> ||groupId||artifactId||previous version||target version||
> |{{org.codehaus.mojo}}|{{buildnumber-maven-plugincol}}|1.2|1.4|
> |{{org.codehaus.mojo}}|{{animal-sniffer-maven-plugin}}|1.14|1.15|
> |{{org.apache.maven.plugins}}|{{maven-doap-plugin}}|1.1|1.2|
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-5968) plugin version updates in Maven core build
[
https://issues.apache.org/jira/browse/MNG-5968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315023#comment-16315023
]
ASF GitHub Bot commented on MNG-5968:
-
GitHub user slachiewicz opened a pull request:
https://github.com/apache/maven/pull/151
[MNG-5968] Default plugin version updates
o Updated default plugin versions to latest release version to bring in the
latest fixes (and issues to report).
o Updated to correct the 'ear' packaging bindings.
o Downgraded the 'maven-plugin-plugin' from 3.4 to 3.3 due to MPLUGIN-296.
o Updated to 'maven-site-plugin' 3.7
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/slachiewicz/maven fix/MNG-5968
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/maven/pull/151.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #151
commit 235ed356c43802b6a0e96a982a95efe9313d
Author: Sylwester Lachiewicz
Date: 2018-01-07T01:10:35Z
[MNG-5968] Default plugin version updates.
o Updated default plugin versions to latest release version to bring in the
latest fixes (and issues to report).
o Updated to correct the 'ear' packaging bindings.
o Downgraded the 'maven-plugin-plugin' from 3.4 to 3.3 due to MPLUGIN-296.
o Updated to 'maven-site-plugin' 3.7
> plugin version updates in Maven core build
> --
>
> Key: MNG-5968
> URL: https://issues.apache.org/jira/browse/MNG-5968
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.3.9
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.5.0-alpha-1, 3.5.0
>
>
> upgrade some plugins in Maven core build (pom.xml), just because newest are
> expected to be better (no known bug):
> ||groupId||artifactId||previous version||target version||
> |{{org.codehaus.mojo}}|{{buildnumber-maven-plugincol}}|1.2|1.4|
> |{{org.codehaus.mojo}}|{{animal-sniffer-maven-plugin}}|1.14|1.15|
> |{{org.apache.maven.plugins}}|{{maven-doap-plugin}}|1.1|1.2|
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6335) Update test framework Mockito from 1.10 to 2.12
[ https://issues.apache.org/jira/browse/MNG-6335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315014#comment-16315014 ] ASF GitHub Bot commented on MNG-6335: - GitHub user slachiewicz opened a pull request: https://github.com/apache/maven/pull/150 [ MNG-6335] Update Mockito to 2.12.0 Also change scope to test You can merge this pull request into a Git repository by running: $ git pull https://github.com/slachiewicz/maven feature/mockito Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven/pull/150.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #150 commit 47a88e22df7a08d3e56e3a110f4b473e38787604 Author: Sylwester Lachiewicz Date: 2018-01-07T00:17:32Z [ MNG-6335]Update Mockito to 2.12.0 Also change scope to test > Update test framework Mockito from 1.10 to 2.12 > --- > > Key: MNG-6335 > URL: https://issues.apache.org/jira/browse/MNG-6335 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MNG-6335) Update test framework Mockito from 1.10 to 2.12
Sylwester Lachiewicz created MNG-6335: - Summary: Update test framework Mockito from 1.10 to 2.12 Key: MNG-6335 URL: https://issues.apache.org/jira/browse/MNG-6335 Project: Maven Issue Type: Dependency upgrade Reporter: Sylwester Lachiewicz Priority: Minor -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6071) GetResource ('/) returns 'null' if build is started with -f
[
https://issues.apache.org/jira/browse/MNG-6071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-6071:
-
Fix Version/s: waiting-for-feedback
> GetResource ('/) returns 'null' if build is started with -f
> ---
>
> Key: MNG-6071
> URL: https://issues.apache.org/jira/browse/MNG-6071
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.1, 3.3.1, 3.3.9
> Environment: Windows 10 x64
> Tested in cmd.exe, git bash.
>Reporter: Alexander Bender
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I set up a very simple test maven project with only a dependency to testNG.
> {code}
> public class TestTest {
> @Test
> public void test() {
> System.out.println(getClass().getResource("/"));
> {code}
> Depending on how I build this, the call either returns null or the expected
> directory. How is that?
> {code}
> // Prints: file:/C:/workspace/test/testproject/target/test-classes/
> mvn clean test -Dtest=TestTest -f pom.xml
> // Prints: file:/C:/workspace/test/testproject/target/test-classes/
> mvn clean test -Dtest=TestTest -f testproject/pom.xml
> // Prints: null
> mvn clean test -Dtest=TestTest -f ./pom.xml
> // Prints: null
> mvn clean test -Dtest=TestTest -f ./testproject/pom.xml
> {code}
> Note that the second call includes "./" after -f.
> I actually want to find out the /target folder regardless of scenario (testNG
> in IntelliJ, Maven, Jenkins Buid, ...). So far, this way has proven the most
> reliable.
> {code}
> System.out.println(getClass().getResource("./"));
> {code}
> This seems to reliably point to
> file:/C:/workspace/test/testproject/target/test-classes/com/testproject/test.
> Would this be safer to use?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6313) Update dependences and default plugins to latest version
[ https://issues.apache.org/jira/browse/MNG-6313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314977#comment-16314977 ] Sylwester Lachiewicz commented on MNG-6313: --- I meant the process of compiling maven itself. In Maven's pom.xml there is reference to parent-pom version 27 and latest is 30. So even maven-clean inside project is outdated :) If we updating Maven's dependences after half year - i would not expect that others would use latest version. Maybe Maven IT infra and Jenkins jobs can help with testing latest snapshot versions of Maven? > Update dependences and default plugins to latest version > > > Key: MNG-6313 > URL: https://issues.apache.org/jira/browse/MNG-6313 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Minor > > Still on Java 7 > default-bindings.xml > maven-install-plugin 2.4 -> 2.5.2 (2014) > maven-deploy-plugin 2.7 -> 2.8.2 (2014) > *maven-resources-plugin* 2.6 -> 3.0.2 (2016) > maven-compiler-plugin 3.1 -> 3.7 (?) (2017) > maven-surefire-plugin 2.12.4 -> 2.20.1 (?) (2017) > *maven-jar-plugin* 2.4 -> 3.0.2 (2017) > *maven-war-plugin* 2.2 -> 3.2 (2017) > Update > parent-pom 27 -> 30 to aligh with other maven projects > maven-shared-utils to 3.1 -> 3.2 > commons-lang 3.5 -> 3.6 > guice 4.0 -> 4.1 (?) > commons-io -> 2.6 > logback-classic 1.2.1 -> 1.2.3 > Plugins - internal use (maybe some update to parent-pom) > maven-release-plugin 2.5.3 > maven-surefire-plugin 2.20.1 (more colors) ;-) > maven-bundle-plugin 2.5.4 > maven-site-plugin 3.6 > apache-rat-plugin 0.12 > findbugs-maven-plugin 3.0.5 > maven-assembly-plugin 3.0 -> 3.1 > maven-jxr-plugin 2.5 > maven-jar-plugin 3.0.2 > maven-compiler-plugin 3.7 > animal-sniffer-maven-plugin 1.15 -> 1.16 > Will be good to know which plugins must be migrated to 3.x line > i.e. add link to maven webpage for dev to > [Wiki|https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MNG-6308) display packaging & groupId:artifactId when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy closed MNG-6308.
--
Resolution: Fixed
Fix Version/s: 3.5.3
done in
https://git-wip-us.apache.org/repos/asf?p=maven.git&a=commit&h=98d2e197d111d4863d1e420a9f9c1548690bc7e1
https://git-wip-us.apache.org/repos/asf?p=maven.git&a=commit&h=c2e3b3e301a96e36670206db0c215f3026937d33
https://git-wip-us.apache.org/repos/asf?p=maven.git&a=commit&h=58cf490c696cebfb0cc3dce31fed68658b16626f
> display packaging & groupId:artifactId when building a module
> -
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
> Fix For: 3.5.3
>
>
> Packaging is a key information, since it defines what bindings will be: it is
> short and should be visible in the build log
> proposal:
> {code}[INFO]
>
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] --- pom
> --{code}
> final choice:
> {code}[INFO] ---< org.apache.maven:apache-maven
> >
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] [ pom
> ]-{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6237) Property value during the same build should not change
[
https://issues.apache.org/jira/browse/MNG-6237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-6237:
-
Fix Version/s: waiting-for-feedback
> Property value during the same build should not change
> --
>
> Key: MNG-6237
> URL: https://issues.apache.org/jira/browse/MNG-6237
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.3
>Reporter: Zoltan Haindrich
> Fix For: waiting-for-feedback
>
>
> I've encountered this problem in HIVE-14289.
> But now I know more...and I think I probably understand what's going on.
> Long story short, I would like to override some project property to use a
> different version of a dependency...however using
> {code}
> mvn install -Dhadoop.version=2.8.0
> {code}
> is not enough...that's what I've found out in that ticket.
> The problem is:
> * root project defines a property {{junit.version}}
> * there is a lib project which pulls in a dependency with that property
> * there is an app module which tries to use the lib in some way
> in this setup even thru the developer would like to override the version of
> {{junit.version}}, he can't really do it; because maven references to it
> anyway.
> I've created a samle project in which the root project contains a malformed
> version number; and in case it tries to use it, will end up with an artifact
> resolution error.
> I'm not sure if the problem is within maven or in some of its plugins...
> sample project:
> https://github.com/kgyrtkirk/mng-6237
> sample output:
> https://api.travis-ci.org/jobs/234037973/log.txt?deansi=true
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6253) Replace CI friendly variables in pom.xml when installing/deploying
[
https://issues.apache.org/jira/browse/MNG-6253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-6253:
-
Fix Version/s: waiting-for-feedback
> Replace CI friendly variables in pom.xml when installing/deploying
> --
>
> Key: MNG-6253
> URL: https://issues.apache.org/jira/browse/MNG-6253
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Christoph Amshoff
> Fix For: waiting-for-feedback
>
>
> When using variables in pom.xml to get CI friendly version
> (https://maven.apache.org/maven-ci-friendly.html), these will not be replaced
> in installed or deployed pom files, which makes them unusable for other
> builds.
> Karl Heinz Marbaise suggested to use the flatten-maven-plugin to do the
> property replacement
> (http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/),
> and this was also suggested as a workaround in other tickets (MDEPLOY-223
> got closed with "Not A Problem" solution).
> That indeed works, but flatten-maven-plugin has to be manually configured in
> the base POM, and additionally it changes the pom files in many other areas
> which you would not want.
> I honestly think that property replacement for the three allowed properties
> ({{$\{revision\}}}, {{$\{sha1\}}}, {{$\{changelist\}}}) should be done by
> Maven internally without having the user configure other plugins. The feature
> is just not correctly working without, so closing such issues with "Not A
> Problem" is too little.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6255) Maven script cannot parse jvm.config with CRLF
[
https://issues.apache.org/jira/browse/MNG-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-6255:
-
Fix Version/s: 3.5.3-candidate
> Maven script cannot parse jvm.config with CRLF
> --
>
> Key: MNG-6255
> URL: https://issues.apache.org/jira/browse/MNG-6255
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 7 with MINGW64 environment via Git for Windows
> 0.1.1 including GNU coreutils and bash 4.4.12
>Reporter: Andrew Kennedy
> Fix For: 3.5.3-candidate
>
>
> A project with a {{.mvn/jvm.config}} file that has *CRLF* line endings will
> not parse it correctly. The script uses the {{tr}} command to change *LF* to
> space, but this leaves *CR* behind. For example, with the {{jvm.config}} file
> containing the text {{-Xmx1024m -Xms512m}} followed by *CRLF*, the following
> error message is printed:
> {code}
> $ mvn install
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Invalid initial heap size: -Xms512m
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6256) Maven script can break if "-f" path contains special characters
[
https://issues.apache.org/jira/browse/MNG-6256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-6256:
-
Fix Version/s: 3.5.3-candidate
> Maven script can break if "-f" path contains special characters
>
>
> Key: MNG-6256
> URL: https://issues.apache.org/jira/browse/MNG-6256
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 10 with PowerShell
>Reporter: Christoph Etzel
> Fix For: 3.5.3-candidate
>
>
> Executing maven on Windows using the {{\-f}} or {{--file}} parameter to
> specify an alternate POM file can break the script if the path contains
> special characters.
> It was originally discovered on a Windows Jenkins instance with working
> directory located under C:\Program Files (x86)\Jenkins..
> Example:
> {code:java}mvn -f "folderWithClosing)Bracket/pomFolder"{code}
> Command line output: {{"Bracket/pomFolder" kann syntaktisch an dieser Stelle
> nicht verarbeitet werden.}}
> Just for fun: Starting calc from maven script using {{\-f}}
> {code:java}mvn -f " ' & start calc"{code}
> Command line output: {{POM file '}} and a new calculator process
> The bug was introduced with commit
> https://github.com/apache/maven/commit/f8ab2a650f32d5d87126d341d9bbfccbf99fd0ca
> for issue MNG-5889.
> Workaround: Use maven 3.3.9 or below
> Possible fix: Escape {{%FILE_ARG%}} and {{%POM_DIR%}} with {{"}} in {{echo}}
> commands in {{maven.cmd}} (line 120 and 129).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MNG-6272) How to create deployment file(war/ear/zip) using pom without libraries
[ https://issues.apache.org/jira/browse/MNG-6272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MNG-6272. Resolution: Not A Problem If you have questions concerning the usage of maven please use the users mailing list. > How to create deployment file(war/ear/zip) using pom without libraries > -- > > Key: MNG-6272 > URL: https://issues.apache.org/jira/browse/MNG-6272 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: waiting-for-feedback > Environment: Development >Reporter: Vijay > Labels: build > Fix For: waiting-for-feedback > > Original Estimate: 2m > Remaining Estimate: 2m > > Hi > In my case i have multiple projects referring the same jar file > For an example my application name is app1,app2,app3 and these 3 application > used db,mq jars > while running the mvn package command the all the 3 application having the > db,mq jars > Here while running the maven package i have to create the deployment > file(war/ear/zip) without libraries > How can i achieve this in maven -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6279) -pl at *end* of command line should raise a warning
[
https://issues.apache.org/jira/browse/MNG-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314965#comment-16314965
]
Karl Heinz Marbaise commented on MNG-6279:
--
Have you checked that with most recent version of Maven (3.5.2)?
> -pl at *end* of command line should raise a warning
>
>
> Key: MNG-6279
> URL: https://issues.apache.org/jira/browse/MNG-6279
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.0.5
> Environment: Ubuntu 14.04.3 LTS
>Reporter: Chris Hennick
>
> I recently tried to run tests on only one specific module using this shell
> script:
> {code:sh}
> #!/bin/sh
> mvn jacoco:prepare-agent -pl betterrandom &&\
> mvn test -pl betterrandom &&\
> mvn jacoco:report -pl betterrandom &&\
> if [ "$TRAVIS" = "true" ]; then
> mvn coveralls:report -pl betterrandom
> fi
> {code}
> It took me a long time to find out that the -pl option needed to
> come *before* the goals it was to apply to. Since -pl with no goals
> after it can't have any effect, it's almost certainly a sign that the
> command-line parameters are out of order. And since this is such an easy
> mistake to make when one's new to multi-module Maven projects, the invocation
> should raise a warning along the lines of "-pl in this position has
> no effect. To filter a goal to a specific module, it must come *before* that
> goal on the command line. Did you mean mvn -pl ?"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (SUREFIRE-1457) trimStackTrace should be disabled by default
[
https://issues.apache.org/jira/browse/SUREFIRE-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1457.
--
Resolution: Won't Fix
Assignee: Tibor Digana
> trimStackTrace should be disabled by default
>
>
> Key: SUREFIRE-1457
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1457
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 2.21.2
>Reporter: Réda Housni Alaoui
>Assignee: Tibor Digana
>Priority: Critical
>
> We are using Jenkins at work.
> Each time we had test failures, stack trace were incomplete and therefore
> totally useless.
> I just discovered {{trimStackTrace}} option.
> IMO, the fact that this option is currently enabled by default is a total non
> sense.
> Now we have to change the pom.xml of every projects of the company to have a
> correct default.
> IMO, and I think I am not the only one here, trimStackTrace should be
> disabled by default.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1457) trimStackTrace should be disabled by default
[
https://issues.apache.org/jira/browse/SUREFIRE-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314962#comment-16314962
]
Tibor Digana commented on SUREFIRE-1457:
[~reda-alaoui]
Sorry but breaking backwards compatibility cannot be made after years.
You have to get experiences with Maven. When you are going to use a new Maven
plugin, you have to read documentation and a list of plugin goals and their
configuration parameters.
> trimStackTrace should be disabled by default
>
>
> Key: SUREFIRE-1457
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1457
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 2.21.2
>Reporter: Réda Housni Alaoui
>Priority: Critical
>
> We are using Jenkins at work.
> Each time we had test failures, stack trace were incomplete and therefore
> totally useless.
> I just discovered {{trimStackTrace}} option.
> IMO, the fact that this option is currently enabled by default is a total non
> sense.
> Now we have to change the pom.xml of every projects of the company to have a
> correct default.
> IMO, and I think I am not the only one here, trimStackTrace should be
> disabled by default.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6313) Update dependences and default plugins to latest version
[ https://issues.apache.org/jira/browse/MNG-6313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314959#comment-16314959 ] Karl Heinz Marbaise commented on MNG-6313: -- Hi, maybe I misunderstand a thing but can you give an example ? > Update dependences and default plugins to latest version > > > Key: MNG-6313 > URL: https://issues.apache.org/jira/browse/MNG-6313 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Minor > > Still on Java 7 > default-bindings.xml > maven-install-plugin 2.4 -> 2.5.2 (2014) > maven-deploy-plugin 2.7 -> 2.8.2 (2014) > *maven-resources-plugin* 2.6 -> 3.0.2 (2016) > maven-compiler-plugin 3.1 -> 3.7 (?) (2017) > maven-surefire-plugin 2.12.4 -> 2.20.1 (?) (2017) > *maven-jar-plugin* 2.4 -> 3.0.2 (2017) > *maven-war-plugin* 2.2 -> 3.2 (2017) > Update > parent-pom 27 -> 30 to aligh with other maven projects > maven-shared-utils to 3.1 -> 3.2 > commons-lang 3.5 -> 3.6 > guice 4.0 -> 4.1 (?) > commons-io -> 2.6 > logback-classic 1.2.1 -> 1.2.3 > Plugins - internal use (maybe some update to parent-pom) > maven-release-plugin 2.5.3 > maven-surefire-plugin 2.20.1 (more colors) ;-) > maven-bundle-plugin 2.5.4 > maven-site-plugin 3.6 > apache-rat-plugin 0.12 > findbugs-maven-plugin 3.0.5 > maven-assembly-plugin 3.0 -> 3.1 > maven-jxr-plugin 2.5 > maven-jar-plugin 3.0.2 > maven-compiler-plugin 3.7 > animal-sniffer-maven-plugin 1.15 -> 1.16 > Will be good to know which plugins must be migrated to 3.x line > i.e. add link to maven webpage for dev to > [Wiki|https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Issue Comment Deleted] (MNG-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNG-6311: - Comment: was deleted (was: I'm out of the office until 15 January 2018. For anything urgent please contact Jayson Elliott PLEASE CONSIDER THE ENVIRONMENT BEFORE PRINTING THIS EMAIL If you receive this message by mistake, please notify the sender at IAG New Zealand Limited immediately and destroy the message. This message and any attachments may be confidential or privileged. You may be liable if you use or retain this information without IAG NZ's permission. Any information that does not relate to IAG NZ's official business is not given or endorsed by IAG NZ. Thank you. ) > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher > Labels: performance > Attachments: modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SUREFIRE-1458) When multiple surefire providers are available through the maven plugin dependency test are executed N times
[ https://issues.apache.org/jira/browse/SUREFIRE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1458: --- Fix Version/s: Backlog > When multiple surefire providers are available through the maven plugin > dependency test are executed N times > > > Key: SUREFIRE-1458 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1458 > Project: Maven Surefire > Issue Type: New Feature >Reporter: Romain Manni-Bucau > Fix For: Backlog > > > In a parent surefire-junit47 is enforced and if I add in a child another > provider (junit5) then tests are executed twice -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (SUREFIRE-1458) When multiple surefire providers are available through the maven plugin dependency test are executed N times
[
https://issues.apache.org/jira/browse/SUREFIRE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314953#comment-16314953
]
Tibor Digana edited comment on SUREFIRE-1458 at 1/6/18 10:15 PM:
-
[~romain.manni-bucau]
Dependencies are merged by Maven and not by Surefire.
The only trick I am facing is to add a new config parameter {{providers}} as a
filter of dependencies:
{noformat}
*:surefire-junit*,*:surefire-testng
{noformat}
or
{noformat}
*:*junit5*
{noformat}
was (Author: tibor17):
[~romain.manni-bucau]
Dependencies are merged by Maven and not by Surefire.
The only trick I am facing is to add a new config parameter {{providers}} as a
filter of dependencies:
{noformat}
*:*surefire-junit*,*:surefire-testng
{noformat}
or
{noformat}
*:*junit5*
{noformat}
> When multiple surefire providers are available through the maven plugin
> dependency test are executed N times
>
>
> Key: SUREFIRE-1458
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1458
> Project: Maven Surefire
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>
> In a parent surefire-junit47 is enforced and if I add in a child another
> provider (junit5) then tests are executed twice
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6290) java.security.InvalidAlgorithmParameterException with java 9
[
https://issues.apache.org/jira/browse/MNG-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-6290:
-
Fix Version/s: waiting-for-feedback
> java.security.InvalidAlgorithmParameterException with java 9
>
>
> Key: MNG-6290
> URL: https://issues.apache.org/jira/browse/MNG-6290
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.5.0
> Environment: Ubuntu
>Reporter: Greg Wilkins
> Fix For: waiting-for-feedback
>
>
> Using
> {{
> openjdk version "9"
> OpenJDK Runtime Environment (build 9+181)
> OpenJDK 64-Bit Server VM (build 9+181, mixed mode)
> }}
> with some missing dependencies results in
> {{
> [ERROR] Plugin org.apache.maven.plugins:maven-failsafe-plugin:2.20.1 or one
> of its dependencies could not be resolved: Failed to read artifact descriptor
> for org.apache.maven.plugins:maven-failsafe-plugin:jar:2.20.1: Could not
> transfer artifact org.apache.maven.plugins:maven-failsafe-plugin:pom:2.20.1
> from/to central (https://repo.maven.apache.org/maven2):
> java.lang.RuntimeException: Unexpected error:
> java.security.InvalidAlgorithmParameterException: the trustAnchors parameter
> must be non-empty -> [Help 1]
> [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/PluginResolutionException
> }}
> switching back to java 8 allows the dependencies to be resolved and then mvn
> appears to work fine in java 9.
> removing the dependency makes the failure re-occur. In my case the missing
> dependency is {{
> org/apache/maven/plugins/maven-failsafe-plugin/2.20.1/maven-failsafe-plugin-2.20.1.jar}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6290) java.security.InvalidAlgorithmParameterException with java 9
[
https://issues.apache.org/jira/browse/MNG-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314956#comment-16314956
]
Karl Heinz Marbaise commented on MNG-6290:
--
Does this problem exist with final 9.0 and 9.0.1 build of JDK 9?
> java.security.InvalidAlgorithmParameterException with java 9
>
>
> Key: MNG-6290
> URL: https://issues.apache.org/jira/browse/MNG-6290
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.5.0
> Environment: Ubuntu
>Reporter: Greg Wilkins
> Fix For: waiting-for-feedback
>
>
> Using
> {{
> openjdk version "9"
> OpenJDK Runtime Environment (build 9+181)
> OpenJDK 64-Bit Server VM (build 9+181, mixed mode)
> }}
> with some missing dependencies results in
> {{
> [ERROR] Plugin org.apache.maven.plugins:maven-failsafe-plugin:2.20.1 or one
> of its dependencies could not be resolved: Failed to read artifact descriptor
> for org.apache.maven.plugins:maven-failsafe-plugin:jar:2.20.1: Could not
> transfer artifact org.apache.maven.plugins:maven-failsafe-plugin:pom:2.20.1
> from/to central (https://repo.maven.apache.org/maven2):
> java.lang.RuntimeException: Unexpected error:
> java.security.InvalidAlgorithmParameterException: the trustAnchors parameter
> must be non-empty -> [Help 1]
> [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/PluginResolutionException
> }}
> switching back to java 8 allows the dependencies to be resolved and then mvn
> appears to work fine in java 9.
> removing the dependency makes the failure re-occur. In my case the missing
> dependency is {{
> org/apache/maven/plugins/maven-failsafe-plugin/2.20.1/maven-failsafe-plugin-2.20.1.jar}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6289) The ability to add a new phase to default lifecycle
[ https://issues.apache.org/jira/browse/MNG-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNG-6289: - Fix Version/s: waiting-for-feedback > The ability to add a new phase to default lifecycle > --- > > Key: MNG-6289 > URL: https://issues.apache.org/jira/browse/MNG-6289 > Project: Maven > Issue Type: Improvement > Components: core >Affects Versions: 3.5.0 >Reporter: Rami Ojares > Fix For: waiting-for-feedback > > > At the moment there is no way to add a phase to the default lifecycle. > The best one can do is to create a new lifecycle with one or more phases. > Then a phase can be bound to a goal. > And in the Mojo that implements the goal one can fork the default lifecycle's > phase say install or deploy. > But the default lifecycle is always executed forked. > This means that the information that the package phase adds to the maven > project for example about the attached artifacts is lost because it is > executed forked. > The simplest way to remedy this situation would be to add possibility in the > @Execute annotation to run a phase not-forked. > Eg. @Execute (phase = LifecyclePhase.INSTALL, forked = false) > This way I could create a new lifecycle but run the default lifecycle first > as a requirement within the same MavenProject. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6292) Add to the settings.xml file
[ https://issues.apache.org/jira/browse/MNG-6292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNG-6292: - Fix Version/s: waiting-for-feedback > Add to the settings.xml file > - > > Key: MNG-6292 > URL: https://issues.apache.org/jira/browse/MNG-6292 > Project: Maven > Issue Type: Improvement > Components: Deployment >Affects Versions: 3.5.0 >Reporter: zosrothko > Fix For: waiting-for-feedback > > > Hi > Currently, the element can be specified only in a > pom. It would be interesting also to factorize this element into a > settings.xml file. This would avoid to repeat this element when one manages > many independent Maven projects. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (SUREFIRE-1458) When multiple surefire providers are available through the maven plugin dependency test are executed N times
[
https://issues.apache.org/jira/browse/SUREFIRE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314953#comment-16314953
]
Tibor Digana edited comment on SUREFIRE-1458 at 1/6/18 10:14 PM:
-
[~romain.manni-bucau]
Dependencies are merged by Maven and not by Surefire.
The only trick I am facing is to add a new config parameter {{providers}} as a
filter of dependencies:
{noformat}
*:*surefire-junit*,*:surefire-testng
{noformat}
or
{noformat}
*:*junit5*
{noformat}
was (Author: tibor17):
[~romain.manni-bucau]
Dependencies are merged by Maven and not by Surefire.
The only trick I am facing is to add a new config parameter {{providers}} as a
filter of dependencies:
*:*surefire-junit*,*:surefire-testng
or
*:*junit5*
> When multiple surefire providers are available through the maven plugin
> dependency test are executed N times
>
>
> Key: SUREFIRE-1458
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1458
> Project: Maven Surefire
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>
> In a parent surefire-junit47 is enforced and if I add in a child another
> provider (junit5) then tests are executed twice
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (SUREFIRE-1458) When multiple surefire providers are available through the maven plugin dependency test are executed N times
[
https://issues.apache.org/jira/browse/SUREFIRE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314953#comment-16314953
]
Tibor Digana edited comment on SUREFIRE-1458 at 1/6/18 10:13 PM:
-
[~romain.manni-bucau]
Dependencies are merged by Maven and not by Surefire.
The only trick I am facing is to add a new config parameter {{providers}} as a
filter of dependencies:
*:*surefire-junit*,*:surefire-testng
or
*:*junit5*
was (Author: tibor17):
[~romain.manni-bucau]
Dependencies are merged by Maven and not by Surefire.
The only trick I am facing is to add a new config parameter {{providers}} as a
filter of dependencies:
{{*:*surefire-junit* ,*:surefire-testng}}
or
{{*:*junit5*}}
> When multiple surefire providers are available through the maven plugin
> dependency test are executed N times
>
>
> Key: SUREFIRE-1458
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1458
> Project: Maven Surefire
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>
> In a parent surefire-junit47 is enforced and if I add in a child another
> provider (junit5) then tests are executed twice
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (SUREFIRE-1458) When multiple surefire providers are available through the maven plugin dependency test are executed N times
[
https://issues.apache.org/jira/browse/SUREFIRE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314953#comment-16314953
]
Tibor Digana edited comment on SUREFIRE-1458 at 1/6/18 10:13 PM:
-
[~romain.manni-bucau]
Dependencies are merged by Maven and not by Surefire.
The only trick I am facing is to add a new config parameter {{providers}} as a
filter of dependencies:
{{*:*surefire-junit* ,*:surefire-testng}}
or
{{*:*junit5*}}
was (Author: tibor17):
[~romain.manni-bucau]
Dependencies are merged by Maven and not by Surefire.
The only trick I am facing is to add a new config parameter {{providers}} as a
filter of dependencies:
{{*:*surefire-junit**,*:surefire-testng}}
or
{{*:*junit5*}}
> When multiple surefire providers are available through the maven plugin
> dependency test are executed N times
>
>
> Key: SUREFIRE-1458
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1458
> Project: Maven Surefire
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>
> In a parent surefire-junit47 is enforced and if I add in a child another
> provider (junit5) then tests are executed twice
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (SUREFIRE-1458) When multiple surefire providers are available through the maven plugin dependency test are executed N times
[
https://issues.apache.org/jira/browse/SUREFIRE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314953#comment-16314953
]
Tibor Digana edited comment on SUREFIRE-1458 at 1/6/18 10:12 PM:
-
[~romain.manni-bucau]
Dependencies are merged by Maven and not by Surefire.
The only trick I am facing is to add a new config parameter {{providers}} as a
filter of dependencies:
{{*:*surefire-junit**,*:surefire-testng}}
or
{{*:*junit5*}}
was (Author: tibor17):
[~romain.manni-bucau]
Dependencies are merged by Maven and not by Surefire.
The only trick I am facing is to add a new config parameter {{providers}} as a
filter of dependencies:
{{*:*surefire-junit*,*:surefire-testng}}
or
{{*:*junit5*}}
> When multiple surefire providers are available through the maven plugin
> dependency test are executed N times
>
>
> Key: SUREFIRE-1458
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1458
> Project: Maven Surefire
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>
> In a parent surefire-junit47 is enforced and if I add in a child another
> provider (junit5) then tests are executed twice
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1458) When multiple surefire providers are available through the maven plugin dependency test are executed N times
[
https://issues.apache.org/jira/browse/SUREFIRE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314953#comment-16314953
]
Tibor Digana commented on SUREFIRE-1458:
[~romain.manni-bucau]
Dependencies are merged by Maven and not by Surefire.
The only trick I am facing is to add a new config parameter {{providers}} as a
filter of dependencies:
{{*:*surefire-junit*,*:surefire-testng}}
or
{{*:*junit5*}}
> When multiple surefire providers are available through the maven plugin
> dependency test are executed N times
>
>
> Key: SUREFIRE-1458
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1458
> Project: Maven Surefire
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>
> In a parent surefire-junit47 is enforced and if I add in a child another
> provider (junit5) then tests are executed twice
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (MNG-6298) 3.5.2: ClassNotFoundException: javax.annotation.security.RolesAllowed
[
https://issues.apache.org/jira/browse/MNG-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reassigned MNG-6298:
Assignee: Karl Heinz Marbaise
> 3.5.2: ClassNotFoundException: javax.annotation.security.RolesAllowed
> -
>
> Key: MNG-6298
> URL: https://issues.apache.org/jira/browse/MNG-6298
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.5.2
> Environment: Mac OS X 10.12.6, Ubuntu 15.10 64 bit, and Windows is
> presumed.
>Reporter: Ryan Heaton
>Assignee: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 3.5.3-candidate
>
>
> Maven 3.5.2 appears to have introduces some kind of a class loading error,
> manifesting itself like this:
> {noformat}
> Caused by: java.lang.ClassNotFoundException:
> javax.annotation.security.RolesAllowed
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 184 more
> {noformat}
> Previous versions of Maven do not manifest this.
> To reproduce this:
> * Clone [the Enunciate sample
> project|https://github.com/stoicflame/enunciate-sample].
> * Build the project (mvn clean package) with 3.5.0 and note the success.
> * Build the project with 3.5.2 and note the failure.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6299) Allow plugins to contribute resolved dependencies
[
https://issues.apache.org/jira/browse/MNG-6299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314951#comment-16314951
]
Karl Heinz Marbaise commented on MNG-6299:
--
Can you give a more practical example of the problem ?
> Allow plugins to contribute resolved dependencies
> -
>
> Key: MNG-6299
> URL: https://issues.apache.org/jira/browse/MNG-6299
> Project: Maven
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>Priority: Minor
>
> Today maven uses resolvedArtifacts as the base for the "available" artifacts
> for plugins.
> It would be very fancy and smooth to be able to enrich this list in a plugin
> for next plugins.
> Today the workaround using gmavenplus-plugin is to use reflection to modify
> this list but this is not satisfying.
> For info is here the kind of code which is usable:
> {code}
> def addArtifact = { project, art ->
> def f = project.class.getDeclaredField('resolvedArtifacts')
> if (!f.accessible) {
> f.accessible = true
> }
> f.get(pj).add(art)
> }
> {code}
> The high level goal is to be able, for a particular project, to resolve in a
> custom manner some artifacts and attach them to the project without having to
> develop a custom repository layout or maven extension (outside the final
> project).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6307) Metadata download hangs for repository with cache lifetime
[ https://issues.apache.org/jira/browse/MNG-6307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314950#comment-16314950 ] Karl Heinz Marbaise commented on MNG-6307: -- Can you please give more details? Otherwise its impossible to say something nor to find the problem.. > Metadata download hangs for repository with cache lifetime > -- > > Key: MNG-6307 > URL: https://issues.apache.org/jira/browse/MNG-6307 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.2 > Environment: Jenkins and Docker, Openjdk 8 u 131 >Reporter: Michael McCallum > > When downloading metadata concurrently and the repository have a interval:X > and the metadata is beyond X then 3.5.2 appears to spawn a thread to > concurrently download the metadata but failed to figure out when its actually > downloaded. > Running the same build again just works. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6310) settings.xml allow proxy activation by expression
[
https://issues.apache.org/jira/browse/MNG-6310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314948#comment-16314948
]
Karl Heinz Marbaise commented on MNG-6310:
--
Are you using a repository manager ? Why do you need to many activations ? Can
you give a more detailed example of that?
> settings.xml allow proxy activation by expression
> -
>
> Key: MNG-6310
> URL: https://issues.apache.org/jira/browse/MNG-6310
> Project: Maven
> Issue Type: New Feature
> Components: Bootstrap & Build
>Affects Versions: 3.5.2
>Reporter: Brett Randall
>Priority: Minor
>
> Currently it appears that {{settings.xml}} proxies can only be activated via
> a boolean {{active}} element, which does not appear to be evaluated, so you
> cannot use a property (e.g. set by a profile), nor a system or environment
> property.
> This comes up a lot on discussions from developers trying to automate whether
> Maven's proxies are enabled or not, based on a system or environment property
> etc.
> Possible solutions:
> * Change the model for (generate) {{Proxy.active}} allowing an expression to
> then be evaluated.
> * Copy {{profiles}} approach and add an {{>}} element, but this
> requires a settings schema rev.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314947#comment-16314947 ] David Churcher commented on MNG-6311: - I'm out of the office until 15 January 2018. For anything urgent please contact Jayson Elliott PLEASE CONSIDER THE ENVIRONMENT BEFORE PRINTING THIS EMAIL If you receive this message by mistake, please notify the sender at IAG New Zealand Limited immediately and destroy the message. This message and any attachments may be confidential or privileged. You may be liable if you use or retain this information without IAG NZ's permission. Any information that does not relate to IAG NZ's official business is not given or endorsed by IAG NZ. Thank you. > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher > Labels: performance > Attachments: modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MNG-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314946#comment-16314946 ] Karl Heinz Marbaise edited comment on MNG-6311 at 1/6/18 10:06 PM: --- Can you give more details about the project ? Maybe an example setup how the project looks like so we might create a script generate a larger test project to see and measure things ? BTW. How much memory have you given? Are you running inside Jenkins / Pipeline ? was (Author: khmarbaise): Can you give more details about the project ? Maybe an example setup how the project looks like so we might create a script generate a larger test project to see and measure things ? > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher > Labels: performance > Attachments: modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314946#comment-16314946 ] Karl Heinz Marbaise commented on MNG-6311: -- Can you give more details about the project ? Maybe an example setup how the project looks like so we might create a script generate a larger test project to see and measure things ? > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher > Labels: performance > Attachments: modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6313) Update dependences and default plugins to latest version
[ https://issues.apache.org/jira/browse/MNG-6313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314943#comment-16314943 ] Sylwester Lachiewicz commented on MNG-6313: --- Is there any reason why Maven is not using latest parent-pom dependences and latest 3.x plugins like Wagon? > Update dependences and default plugins to latest version > > > Key: MNG-6313 > URL: https://issues.apache.org/jira/browse/MNG-6313 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Minor > > Still on Java 7 > default-bindings.xml > maven-install-plugin 2.4 -> 2.5.2 (2014) > maven-deploy-plugin 2.7 -> 2.8.2 (2014) > *maven-resources-plugin* 2.6 -> 3.0.2 (2016) > maven-compiler-plugin 3.1 -> 3.7 (?) (2017) > maven-surefire-plugin 2.12.4 -> 2.20.1 (?) (2017) > *maven-jar-plugin* 2.4 -> 3.0.2 (2017) > *maven-war-plugin* 2.2 -> 3.2 (2017) > Update > parent-pom 27 -> 30 to aligh with other maven projects > maven-shared-utils to 3.1 -> 3.2 > commons-lang 3.5 -> 3.6 > guice 4.0 -> 4.1 (?) > commons-io -> 2.6 > logback-classic 1.2.1 -> 1.2.3 > Plugins - internal use (maybe some update to parent-pom) > maven-release-plugin 2.5.3 > maven-surefire-plugin 2.20.1 (more colors) ;-) > maven-bundle-plugin 2.5.4 > maven-site-plugin 3.6 > apache-rat-plugin 0.12 > findbugs-maven-plugin 3.0.5 > maven-assembly-plugin 3.0 -> 3.1 > maven-jxr-plugin 2.5 > maven-jar-plugin 3.0.2 > maven-compiler-plugin 3.7 > animal-sniffer-maven-plugin 1.15 -> 1.16 > Will be good to know which plugins must be migrated to 3.x line > i.e. add link to maven webpage for dev to > [Wiki|https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6312) Update Maven Wagon dependency
[ https://issues.apache.org/jira/browse/MNG-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNG-6312: - Affects Version/s: 3.5.0 > Update Maven Wagon dependency > - > > Key: MNG-6312 > URL: https://issues.apache.org/jira/browse/MNG-6312 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 3.5.0 >Reporter: Sylwester Lachiewicz > Fix For: 3.5.3 > > > Based on OWASP report - update Maven Wagon from 2.12 to 3.0.0 to fix known > vulnerability in shaded jsoup > wagon-http-2.12-shaded.jar\META-INF/maven/org.jsoup/jsoup/pom.xml > (cpe:/a:jsoup:jsoup:1.7.2, org.jsoup:jsoup:1.7.2) : CVE-2015-6748 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MNG-6312) Update Maven Wagon dependency
[ https://issues.apache.org/jira/browse/MNG-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise reassigned MNG-6312: Assignee: Karl Heinz Marbaise > Update Maven Wagon dependency > - > > Key: MNG-6312 > URL: https://issues.apache.org/jira/browse/MNG-6312 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 3.5.0 >Reporter: Sylwester Lachiewicz >Assignee: Karl Heinz Marbaise > Fix For: 3.5.3 > > > Based on OWASP report - update Maven Wagon from 2.12 to 3.0.0 to fix known > vulnerability in shaded jsoup > wagon-http-2.12-shaded.jar\META-INF/maven/org.jsoup/jsoup/pom.xml > (cpe:/a:jsoup:jsoup:1.7.2, org.jsoup:jsoup:1.7.2) : CVE-2015-6748 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6312) Update Maven Wagon dependency
[ https://issues.apache.org/jira/browse/MNG-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNG-6312: - Fix Version/s: 3.5.3 > Update Maven Wagon dependency > - > > Key: MNG-6312 > URL: https://issues.apache.org/jira/browse/MNG-6312 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 3.5.0 >Reporter: Sylwester Lachiewicz > Fix For: 3.5.3 > > > Based on OWASP report - update Maven Wagon from 2.12 to 3.0.0 to fix known > vulnerability in shaded jsoup > wagon-http-2.12-shaded.jar\META-INF/maven/org.jsoup/jsoup/pom.xml > (cpe:/a:jsoup:jsoup:1.7.2, org.jsoup:jsoup:1.7.2) : CVE-2015-6748 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6308) display packaging & groupId:artifactId when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314940#comment-16314940
]
Hudson commented on MNG-6308:
-
Build succeeded in Jenkins: maven-3.x-jenkinsfile » master #155
See https://builds.apache.org/job/maven-3.x-jenkinsfile/job/master/155/
> display packaging & groupId:artifactId when building a module
> -
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is
> short and should be visible in the build log
> proposal:
> {code}[INFO]
>
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] --- pom
> --{code}
> final choice:
> {code}[INFO] ---< org.apache.maven:apache-maven
> >
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] [ pom
> ]-{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6308) display packaging & groupId:artifactId when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314941#comment-16314941
]
Hudson commented on MNG-6308:
-
Build succeeded in Jenkins: Maven TLP (wip) » maven » master #26
See https://builds.apache.org/job/maven-wip/job/maven/job/master/26/
> display packaging & groupId:artifactId when building a module
> -
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is
> short and should be visible in the build log
> proposal:
> {code}[INFO]
>
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] --- pom
> --{code}
> final choice:
> {code}[INFO] ---< org.apache.maven:apache-maven
> >
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] [ pom
> ]-{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6313) Update dependences and default plugins to latest version
[ https://issues.apache.org/jira/browse/MNG-6313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314938#comment-16314938 ] Karl Heinz Marbaise commented on MNG-6313: -- To know which plugins should be migrated to 3.x you can take a look here: https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/dist-tool-prerequisites.html The updates for other plugins are done via the parents see https://issues.apache.org/jira/projects/MPOM When to update: There is a thread on the dev list. As far as i can remember we would to have the plugins running in the wild for at least six month before we update the parent poms.. > Update dependences and default plugins to latest version > > > Key: MNG-6313 > URL: https://issues.apache.org/jira/browse/MNG-6313 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Minor > > Still on Java 7 > default-bindings.xml > maven-install-plugin 2.4 -> 2.5.2 (2014) > maven-deploy-plugin 2.7 -> 2.8.2 (2014) > *maven-resources-plugin* 2.6 -> 3.0.2 (2016) > maven-compiler-plugin 3.1 -> 3.7 (?) (2017) > maven-surefire-plugin 2.12.4 -> 2.20.1 (?) (2017) > *maven-jar-plugin* 2.4 -> 3.0.2 (2017) > *maven-war-plugin* 2.2 -> 3.2 (2017) > Update > parent-pom 27 -> 30 to aligh with other maven projects > maven-shared-utils to 3.1 -> 3.2 > commons-lang 3.5 -> 3.6 > guice 4.0 -> 4.1 (?) > commons-io -> 2.6 > logback-classic 1.2.1 -> 1.2.3 > Plugins - internal use (maybe some update to parent-pom) > maven-release-plugin 2.5.3 > maven-surefire-plugin 2.20.1 (more colors) ;-) > maven-bundle-plugin 2.5.4 > maven-site-plugin 3.6 > apache-rat-plugin 0.12 > findbugs-maven-plugin 3.0.5 > maven-assembly-plugin 3.0 -> 3.1 > maven-jxr-plugin 2.5 > maven-jar-plugin 3.0.2 > maven-compiler-plugin 3.7 > animal-sniffer-maven-plugin 1.15 -> 1.16 > Will be good to know which plugins must be migrated to 3.x line > i.e. add link to maven webpage for dev to > [Wiki|https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6315) NPE in MultiThreadedBuilder
[
https://issues.apache.org/jira/browse/MNG-6315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314932#comment-16314932
]
Karl Heinz Marbaise commented on MNG-6315:
--
First are you using the most recent version of Maven 3.5.2 ? Furthermore are
you using the most recent version of versions-maven-plugin (2.5) ? Can you add
a log output which shows the problem.. ?
Apart from that the [documentation of versions-maven-plugin
states|http://www.mojohaus.org/versions-maven-plugin/usage.html] explicitly
{{..you need to run these goals separately from any other goals or life-cycle
phases.}}.
> NPE in MultiThreadedBuilder
> ---
>
> Key: MNG-6315
> URL: https://issues.apache.org/jira/browse/MNG-6315
> Project: Maven
> Issue Type: Bug
> Components: core
>Reporter: David Hoover
>
> This smells similar to MNG-6170
> To reproduce, clone https://github.com/prestodb/presto (I've tested, in
> particular, at c0186a71815be31bac80253827e62c16fd04069f) and try to 'mvn -X
> -e versions:set versions:commit -DnewVersion=asdf'
> That NPEs on
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L200
> (projectBuild.getProject() has already been called up at
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L129
> so presumably it's that lifecycleModuleBuilder is null?)
> Running as two separate actions ("mvn versions:set" and then "mvn
> versions:commit") works for me, but not when combined.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6321) tag result in propertityPlaceHolder replace error
[
https://issues.apache.org/jira/browse/MNG-6321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314925#comment-16314925
]
Karl Heinz Marbaise commented on MNG-6321:
--
First please do not use system Scope dependencies in your application
furthermore please try to make a repeatable example and format your description
correctly cause it's hard to read.
> tag result in propertityPlaceHolder replace error
>
>
> Key: MNG-6321
> URL: https://issues.apache.org/jira/browse/MNG-6321
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.9
> Environment: spring 4.2.0.RELEASE,maven 3.3.9,mac os x 10.11,
> jdk1.8,
>Reporter: yongma
> Labels: maven
> Attachments: ApplicationContext-mvc.xml, ApplicationContext.xml
>
>
> 4.0.0
> FH
> data-center-outchannel
> war
> 0.0.2
> FHM Maven Webapp
> {color:red}http://maven.apache.org{color}
>
>
> UTF-8
> 1.1
> 4.0.4.RELEASE
>
> 5.1.34
> 7.0.61
> 5.1.30
>
> 1.3.4-SNAPSHOT
> true
>
> src/main/resources/autogen/generatorConfig.xml
>
>
> ${project.build.directory}/generated-sources/mybatis-generator
>
> 2.5.3
> 2.2.2
> 0.5
> 3.4.6
>
> 2.0.0
>
>
>
> dev
>
> dev
>
>
>
> product
>
> product
>
>
>
>
>
>
> org.springframework
> spring-aop
> ${spring.version}
>
>
> org.springframework
> spring-aspects
> ${spring.version}
>
>
> org.springframework
> spring-beans
> ${spring.version}
>
>
> org.springframework
> spring-context
> ${spring.version}
>
>
> org.springframework
> spring-context-support
> ${spring.version}
>
>
> org.springframework
> spring-core
> ${spring.version}
>
>
> org.springframework
> spring-dao
> 2.0.8
>
>
> org.springframework
> spring-expression
> ${spring.version}
>
>
> org.springframework
> spring-jdbc
> ${spring.version}
>
>
> org.springframework
> spring-mock
> 2.0.8
>
>
> org.springframework
> spring-orm
> ${spring.version}
>
>
> org.springframework
> spring-test
> ${spring.version}
>
>
> org.springframework
> spring-tx
> ${spring.version}
>
>
> org.springframework
> spring-web
> ${spring.version}
>
>
> org.springframework
> spring-test
> ${spring.version}
>
>
> org.springframework
> spring-webmvc
> ${spring.version}
>
>
>
> com.alibaba
> dubbo
> ${dubbo.version}
>
>
> org.springframework
> spring
>
>
>
>
>
> com.treefinance.commonservice
> guid-service-facade
> ${uid-worker.version}
>
>
>
[jira] [Commented] (MNG-6308) display packaging & groupId:artifactId when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314924#comment-16314924
]
Hudson commented on MNG-6308:
-
Build succeeded in Jenkins: Maven TLP (wip) » maven »
MNG-6308_display_packaging #14
See
https://builds.apache.org/job/maven-wip/job/maven/job/MNG-6308_display_packaging/14/
> display packaging & groupId:artifactId when building a module
> -
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is
> short and should be visible in the build log
> proposal:
> {code}[INFO]
>
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] --- pom
> --{code}
> final choice:
> {code}[INFO] ---< org.apache.maven:apache-maven
> >
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] [ pom
> ]-{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6305) Validation of CI friendly version incorrect
[
https://issues.apache.org/jira/browse/MNG-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314923#comment-16314923
]
Hudson commented on MNG-6305:
-
Build succeeded in Jenkins: Maven TLP (wip) » maven »
MNG-6308_display_packaging #14
See
https://builds.apache.org/job/maven-wip/job/maven/job/MNG-6308_display_packaging/14/
> Validation of CI friendly version incorrect
> ---
>
> Key: MNG-6305
> URL: https://issues.apache.org/jira/browse/MNG-6305
> Project: Maven
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.5.2
>Reporter: Robert Scholte
>Assignee: Karl Heinz Marbaise
> Fix For: 3.5.3
>
>
> The version may contain some special expression, which are considered as a
> constant.
> However, the following version is treated as valid too:
> {code:xml}
> ${sha1}${var}
> {code}
> The validator should check every expression and verify they're all constants.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6330) [regression] Parents relativePath not verified anymore
[
https://issues.apache.org/jira/browse/MNG-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314922#comment-16314922
]
Hudson commented on MNG-6330:
-
Build succeeded in Jenkins: Maven TLP (wip) » maven »
MNG-6308_display_packaging #14
See
https://builds.apache.org/job/maven-wip/job/maven/job/MNG-6308_display_packaging/14/
> [regression] Parents relativePath not verified anymore
> --
>
> Key: MNG-6330
> URL: https://issues.apache.org/jira/browse/MNG-6330
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build, Inheritance and Interpolation,
> Reactor and workspace
>Affects Versions: 3.5.0, 3.5.2
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Critical
> Fix For: 3.5.3
>
>
> Since Maven 3.0 the relative path of a parent was always verified, an invalid
> value or missing caches parent made the project fail.
> This stopped after 3.5.0, and after a bisect I discovered the behavior
> changed with:
> {noformat}
> cfb075ac706b25df630f3671f61f8d8313e0f138 is the first bad commit
> commit cfb075ac706b25df630f3671f61f8d8313e0f138
> Author: Karl Heinz Marbaise
> Date: Tue May 31 21:39:31 2016 +0200
> [MNG-6030] ReactorModelCache do not used effectively after maven version
> 3.0.5 which cause a large memory footprint
> o Reintroduced ReactorModelCache reduces the memory footprint.
> {noformat}
> It looks like the caching introduced an unwanted behavior of Maven. We must
> decide if we want the relative path to be strict again.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6300) Multi module release creates empty directories in war file instead of jars
[
https://issues.apache.org/jira/browse/MNG-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314921#comment-16314921
]
Hudson commented on MNG-6300:
-
Build succeeded in Jenkins: Maven TLP (wip) » maven »
MNG-6308_display_packaging #14
See
https://builds.apache.org/job/maven-wip/job/maven/job/MNG-6308_display_packaging/14/
> Multi module release creates empty directories in war file instead of jars
> --
>
> Key: MNG-6300
> URL: https://issues.apache.org/jira/browse/MNG-6300
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2
> Environment: Linux, Oracle java 1.8.0_152
>Reporter: Andreas Kurth
>Assignee: Robert Scholte
>Priority: Critical
> Fix For: 3.5.3
>
> Attachments: build.log, mm.zip
>
>
> After updating to maven 3.5.2 we encounter the following reproducible bug
> with multi module builds.
> If one of the modules is a war module and depends on another module, the
> dependency module will not be included as a jar file in WEB-INF/lib of the
> war file, but as an empty directory instead. Non module dependencies will be
> included correctly.
> This bug does occur when the following conditions are met:
> - running release:prepare/release:perform
> - element is present, so that release goals
> are "deploy site-deploy"
> - element contains javadoc-maven-plugin
> Please note that when running "mvn install" or "mvn deploy" the resulting war
> file is ok, while "mvn release:perform" creates corrupt files as described.
> Also, if javadoc-maven-plugin is not present in block, the war
> file is fine, too.
> I have no idea whether this bug is maven core or rather release-plugin or
> even javadoc-plugin related, so I file it here. I prepared a minimal self
> contained example and attach it as mm.zip. To run the example, the following
> steps are needed:
> {code}
> cd /tmp
> unzip /path/to/mm.zip
> cd mm
> git init
> git add pom.xml mm-lib mm-war .gitignore
> git commit
> mvn release:prepare
> mvn release:perform
> {code}
> After building the resulting corrupt war file can be found here:
> repo/com/example/mm/mm-war/1.0.0/mm-war-1.0.0.war
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6326) Build continues when core extensions aren't found
[
https://issues.apache.org/jira/browse/MNG-6326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314919#comment-16314919
]
Karl Heinz Marbaise commented on MNG-6326:
--
First there are big differences between build extensions which are defined in
the pom file and those are defined in {{.mvn/extensions.xml}}...Can you give an
example for this ? Maybe we have to think about failing the build if it's not
found ?
> Build continues when core extensions aren't found
> -
>
> Key: MNG-6326
> URL: https://issues.apache.org/jira/browse/MNG-6326
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build
>Affects Versions: 3.5.2
>Reporter: Matt Biggs
>Priority: Critical
>
> If you define a core extension in *.mvn/extensions.xml* which then can't be
> retrieved/found the build issues a warning and then continues leading to
> unexpected behaviour depending on the functionality provided by the
> extension.
> If the extension is defined in the pom and not found the build fails. I would
> have expected it to fail when not found in the external extensions.xml file
> too as it's quite easy to miss the fact it failed to retrieve it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6330) [regression] Parents relativePath not verified anymore
[
https://issues.apache.org/jira/browse/MNG-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314918#comment-16314918
]
Hudson commented on MNG-6330:
-
Build succeeded in Jenkins: maven-3.x-jenkinsfile » MNG-6308_display_packaging
#11
See
https://builds.apache.org/job/maven-3.x-jenkinsfile/job/MNG-6308_display_packaging/11/
> [regression] Parents relativePath not verified anymore
> --
>
> Key: MNG-6330
> URL: https://issues.apache.org/jira/browse/MNG-6330
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build, Inheritance and Interpolation,
> Reactor and workspace
>Affects Versions: 3.5.0, 3.5.2
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Critical
> Fix For: 3.5.3
>
>
> Since Maven 3.0 the relative path of a parent was always verified, an invalid
> value or missing caches parent made the project fail.
> This stopped after 3.5.0, and after a bisect I discovered the behavior
> changed with:
> {noformat}
> cfb075ac706b25df630f3671f61f8d8313e0f138 is the first bad commit
> commit cfb075ac706b25df630f3671f61f8d8313e0f138
> Author: Karl Heinz Marbaise
> Date: Tue May 31 21:39:31 2016 +0200
> [MNG-6030] ReactorModelCache do not used effectively after maven version
> 3.0.5 which cause a large memory footprint
> o Reintroduced ReactorModelCache reduces the memory footprint.
> {noformat}
> It looks like the caching introduced an unwanted behavior of Maven. We must
> decide if we want the relative path to be strict again.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6327) Add ability to easily retrieve core extensions from alternative pluginRepository
[
https://issues.apache.org/jira/browse/MNG-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314916#comment-16314916
]
Karl Heinz Marbaise commented on MNG-6327:
--
Maybe I misunderstand a thing here but if you configure your setup to use a
repository manager in your {{settings.xml}} there is no need for a profile ?
Apart from that extensions will be resolve from the repositories like plugins /
dependencies...?
The problem you mentions to read the pom is really a *chicken and egg* cause
at the time of reading the {{.mvn/extensions.xml}} the pom's have not been read
cause by using extensions you can influence that.. and going to the path
reading the pom and using things like pluginRepositories from there that would
break things like takari etc.
> Add ability to easily retrieve core extensions from alternative
> pluginRepository
>
>
> Key: MNG-6327
> URL: https://issues.apache.org/jira/browse/MNG-6327
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build
>Affects Versions: 3.5.2
>Reporter: Matt Biggs
>Priority: Critical
>
> If you define an extension in *.mvn/extensions.xml* it is automatically
> retrieved and installed when you first build but ONLY if it is present in
> maven central.
> I understand it's obviously a little 'chicken and egg' scenario but it would
> be really useful for making a seamless out of the box experience if it could
> either a) read the pom and use the pluginRepositories from there, or b) if
> you could perhaps specify the repository inside the extensions.xml file?
> The only work around I can currently find is to ask the user to add an active
> profile to their settings.xml which obviously isn't as nice.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MNG-6298) 3.5.2: ClassNotFoundException: javax.annotation.security.RolesAllowed
[
https://issues.apache.org/jira/browse/MNG-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314908#comment-16314908
]
Karl Heinz Marbaise edited comment on MNG-6298 at 1/6/18 9:21 PM:
--
Tack [~Bengt1982]. I appreciate you support for the Maven project. I have
updated the branch accordingly. Lets wait for CI result. BTW. Small hint.
Usually you should mention the issue in the commit message like:
{code}
[MXXX-XX] Subject
o more details
{code}
That makes it easier to associate the pr/commit with the appropriate issue
entry...
Kind regards
Karl Heinz Marbaise
was (Author: khmarbaise):
Tack [~Bengt1982]. I appreciate you support for the Maven project. I have
updated the branch accordingly. Lets wait for CI result.
> 3.5.2: ClassNotFoundException: javax.annotation.security.RolesAllowed
> -
>
> Key: MNG-6298
> URL: https://issues.apache.org/jira/browse/MNG-6298
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.5.2
> Environment: Mac OS X 10.12.6, Ubuntu 15.10 64 bit, and Windows is
> presumed.
>Reporter: Ryan Heaton
>Priority: Critical
> Fix For: 3.5.3-candidate
>
>
> Maven 3.5.2 appears to have introduces some kind of a class loading error,
> manifesting itself like this:
> {noformat}
> Caused by: java.lang.ClassNotFoundException:
> javax.annotation.security.RolesAllowed
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 184 more
> {noformat}
> Previous versions of Maven do not manifest this.
> To reproduce this:
> * Clone [the Enunciate sample
> project|https://github.com/stoicflame/enunciate-sample].
> * Build the project (mvn clean package) with 3.5.0 and note the success.
> * Build the project with 3.5.2 and note the failure.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6298) 3.5.2: ClassNotFoundException: javax.annotation.security.RolesAllowed
[
https://issues.apache.org/jira/browse/MNG-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314908#comment-16314908
]
Karl Heinz Marbaise commented on MNG-6298:
--
Tack [~Bengt1982]. I appreciate you support for the Maven project. I have
updated the branch accordingly. Lets wait for CI result.
> 3.5.2: ClassNotFoundException: javax.annotation.security.RolesAllowed
> -
>
> Key: MNG-6298
> URL: https://issues.apache.org/jira/browse/MNG-6298
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.5.2
> Environment: Mac OS X 10.12.6, Ubuntu 15.10 64 bit, and Windows is
> presumed.
>Reporter: Ryan Heaton
>Priority: Critical
> Fix For: 3.5.3-candidate
>
>
> Maven 3.5.2 appears to have introduces some kind of a class loading error,
> manifesting itself like this:
> {noformat}
> Caused by: java.lang.ClassNotFoundException:
> javax.annotation.security.RolesAllowed
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 184 more
> {noformat}
> Previous versions of Maven do not manifest this.
> To reproduce this:
> * Clone [the Enunciate sample
> project|https://github.com/stoicflame/enunciate-sample].
> * Build the project (mvn clean package) with 3.5.0 and note the success.
> * Build the project with 3.5.2 and note the failure.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6308) display packaging & groupId:artifactId when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MNG-6308:
---
Description:
Packaging is a key information, since it defines what bindings will be: it is
short and should be visible in the build log
proposal:
{code}[INFO]
[INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT[15/15]
[INFO] --- pom
--{code}
final choice:
{code}[INFO] ---< org.apache.maven:apache-maven
>
[INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT[15/15]
[INFO] [ pom
]-{code}
was:
Packaging is a key information, since it defines what bindings will be: it is
short and should be visible in the build log
proposal:
{code}[INFO]
[INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT[15/15]
[INFO] --- pom
--{code}
> display packaging & groupId:artifactId when building a module
> -
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is
> short and should be visible in the build log
> proposal:
> {code}[INFO]
>
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] --- pom
> --{code}
> final choice:
> {code}[INFO] ---< org.apache.maven:apache-maven
> >
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] [ pom
> ]-{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6308) display packaging & groupId:artifactId when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MNG-6308:
---
Summary: display packaging & groupId:artifactId when building a module
(was: display packaging when building a module)
> display packaging & groupId:artifactId when building a module
> -
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is
> short and should be visible in the build log
> proposal:
> {code}[INFO]
>
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] --- pom
> --{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6298) 3.5.2: ClassNotFoundException: javax.annotation.security.RolesAllowed
[
https://issues.apache.org/jira/browse/MNG-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314904#comment-16314904
]
Bengt Söderberg commented on MNG-6298:
--
Hi [~khmarbaise], updated the commit with the requested changes. My first
commit to maven, thanks for your patience :)
> 3.5.2: ClassNotFoundException: javax.annotation.security.RolesAllowed
> -
>
> Key: MNG-6298
> URL: https://issues.apache.org/jira/browse/MNG-6298
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.5.2
> Environment: Mac OS X 10.12.6, Ubuntu 15.10 64 bit, and Windows is
> presumed.
>Reporter: Ryan Heaton
>Priority: Critical
> Fix For: 3.5.3-candidate
>
>
> Maven 3.5.2 appears to have introduces some kind of a class loading error,
> manifesting itself like this:
> {noformat}
> Caused by: java.lang.ClassNotFoundException:
> javax.annotation.security.RolesAllowed
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 184 more
> {noformat}
> Previous versions of Maven do not manifest this.
> To reproduce this:
> * Clone [the Enunciate sample
> project|https://github.com/stoicflame/enunciate-sample].
> * Build the project (mvn clean package) with 3.5.0 and note the success.
> * Build the project with 3.5.2 and note the failure.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MENFORCER-281) RequirePluginVersions broken with "CI Friendly versions"
[
https://issues.apache.org/jira/browse/MENFORCER-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314900#comment-16314900
]
Hudson commented on MENFORCER-281:
--
Build succeeded in Jenkins: Maven TLP » maven-enforcer » master #9
See https://builds.apache.org/job/maven-box/job/maven-enforcer/job/master/9/
> RequirePluginVersions broken with "CI Friendly versions"
>
>
> Key: MENFORCER-281
> URL: https://issues.apache.org/jira/browse/MENFORCER-281
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4.1, 3.0.0-M1
>Reporter: James Nord
>Assignee: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 3.0.0
>
>
> Maven
> [3.5.0|https://maven.apache.org/docs/3.5.0/release-notes.html#Overview_about_the_changes]
> [introduced CI friendly
> versions|https://maven.apache.org/maven-ci-friendly.html].
> However when used with [multi module
> project|https://maven.apache.org/maven-ci-friendly.html#Multi_Module_Setup]
> the enforcer fails the build as it can not resolve the parent.
> The bug is that the parent resolution of a module in the reactor is
> attempting to use the untransposed version.
> e.g.
> {noformat}
> INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (display-info) @ sub-module
> ---
> [WARNING] Rule 1: org.apache.maven.plugins.enforcer.RequirePluginVersions
> failed with message:
> Failure to find com.acme.product:parent:pom:0.9.8-${revision}SNAPSHOT in
> https://repo.acme.com/content/groups/all was cached in the local repository,
> resolution will not be reattempted until the update interval of acme-internal
> has elapsed or updates are forced
> com.acme.product:parent:pom:0.9.8-${revision}SNAPSHOT
> from the specified remote repositories:
> acme-internal (https://repo.acme.com/content/groups/all, releases=true,
> snapshots=true)
> {noformat}
> to reproduce create a new multi module project as per the linked page above.
> Add the enforcer plugin and rule to the build
> run {{mvn -Drevision=1.2.3-SNAPSHOT}} and watch the build fail.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6298) 3.5.2: ClassNotFoundException: javax.annotation.security.RolesAllowed
[
https://issues.apache.org/jira/browse/MNG-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314885#comment-16314885
]
Karl Heinz Marbaise commented on MNG-6298:
--
Hi [~Bengt1982] can you please take a look at the comment of Robet Scholte on
the dev list https://www.mail-archive.com/dev@maven.apache.org/msg115802.html
> 3.5.2: ClassNotFoundException: javax.annotation.security.RolesAllowed
> -
>
> Key: MNG-6298
> URL: https://issues.apache.org/jira/browse/MNG-6298
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.5.2
> Environment: Mac OS X 10.12.6, Ubuntu 15.10 64 bit, and Windows is
> presumed.
>Reporter: Ryan Heaton
>Priority: Critical
> Fix For: 3.5.3-candidate
>
>
> Maven 3.5.2 appears to have introduces some kind of a class loading error,
> manifesting itself like this:
> {noformat}
> Caused by: java.lang.ClassNotFoundException:
> javax.annotation.security.RolesAllowed
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 184 more
> {noformat}
> Previous versions of Maven do not manifest this.
> To reproduce this:
> * Clone [the Enunciate sample
> project|https://github.com/stoicflame/enunciate-sample].
> * Build the project (mvn clean package) with 3.5.0 and note the success.
> * Build the project with 3.5.2 and note the failure.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6096) Deprecate DefaultArtifactVersion class
[ https://issues.apache.org/jira/browse/MNG-6096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNG-6096: - Fix Version/s: (was: needing-scrub-3.4.0-fallout) 3.5.3-candidate > Deprecate DefaultArtifactVersion class > -- > > Key: MNG-6096 > URL: https://issues.apache.org/jira/browse/MNG-6096 > Project: Maven > Issue Type: Task > Components: core >Affects Versions: needing-scrub-3.4.0-fallout >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.5.3-candidate > > > The DefaultArtifactVersion class parses the version of the artifacts but in > many situations it does not work correctly. > Furthermore based on the references and hints given here: > https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6298) 3.5.2: ClassNotFoundException: javax.annotation.security.RolesAllowed
[
https://issues.apache.org/jira/browse/MNG-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314879#comment-16314879
]
Karl Heinz Marbaise commented on MNG-6298:
--
So branches have been created for [Maven
Core|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=ddd63d9bffdf996c44909b6b0c5f58aa55b16fe0]
and [Integration
Testing|https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commitdiff;h=55db62ff59715248edf37b636821461d0f1081c4].
So lets see if we haven another dev who will second this.
> 3.5.2: ClassNotFoundException: javax.annotation.security.RolesAllowed
> -
>
> Key: MNG-6298
> URL: https://issues.apache.org/jira/browse/MNG-6298
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.5.2
> Environment: Mac OS X 10.12.6, Ubuntu 15.10 64 bit, and Windows is
> presumed.
>Reporter: Ryan Heaton
>Priority: Critical
> Fix For: 3.5.3-candidate
>
>
> Maven 3.5.2 appears to have introduces some kind of a class loading error,
> manifesting itself like this:
> {noformat}
> Caused by: java.lang.ClassNotFoundException:
> javax.annotation.security.RolesAllowed
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 184 more
> {noformat}
> Previous versions of Maven do not manifest this.
> To reproduce this:
> * Clone [the Enunciate sample
> project|https://github.com/stoicflame/enunciate-sample].
> * Build the project (mvn clean package) with 3.5.0 and note the success.
> * Build the project with 3.5.2 and note the failure.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MNG-6332) Cleaned up mvn.cmd Script
[
https://issues.apache.org/jira/browse/MNG-6332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MNG-6332.
Resolution: Fixed
Done in
[68a9d79671a7d385a204300994e06b1a19964bf4|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=68a9d79671a7d385a204300994e06b1a19964bf4]
> Cleaned up mvn.cmd Script
> -
>
> Key: MNG-6332
> URL: https://issues.apache.org/jira/browse/MNG-6332
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.5.2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.3
>
>
> Based on the following [Stackoverflow
> quesiton|https://stackoverflow.com/q/48027497/296328]:
> The given label {{valMHome}} can be removed. In the following case can be
> replaced by using{{stripMHome}} instead.
> {code}
> :chkMHome
> set "MAVEN_HOME=%~dp0.."
> if not "%MAVEN_HOME%"=="" goto valMHome
> goto error
> :valMHome
> :stripMHome
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6332) Cleaned up mvn.cmd Script
[
https://issues.apache.org/jira/browse/MNG-6332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314871#comment-16314871
]
Hudson commented on MNG-6332:
-
Build succeeded in Jenkins: Maven TLP (wip) » maven » master #25
See https://builds.apache.org/job/maven-wip/job/maven/job/master/25/
> Cleaned up mvn.cmd Script
> -
>
> Key: MNG-6332
> URL: https://issues.apache.org/jira/browse/MNG-6332
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.5.2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.3
>
>
> Based on the following [Stackoverflow
> quesiton|https://stackoverflow.com/q/48027497/296328]:
> The given label {{valMHome}} can be removed. In the following case can be
> replaced by using{{stripMHome}} instead.
> {code}
> :chkMHome
> set "MAVEN_HOME=%~dp0.."
> if not "%MAVEN_HOME%"=="" goto valMHome
> goto error
> :valMHome
> :stripMHome
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6332) Cleaned up mvn.cmd Script
[
https://issues.apache.org/jira/browse/MNG-6332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314872#comment-16314872
]
Hudson commented on MNG-6332:
-
Build succeeded in Jenkins: maven-3.x-jenkinsfile » master #154
See https://builds.apache.org/job/maven-3.x-jenkinsfile/job/master/154/
> Cleaned up mvn.cmd Script
> -
>
> Key: MNG-6332
> URL: https://issues.apache.org/jira/browse/MNG-6332
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.5.2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.3
>
>
> Based on the following [Stackoverflow
> quesiton|https://stackoverflow.com/q/48027497/296328]:
> The given label {{valMHome}} can be removed. In the following case can be
> replaced by using{{stripMHome}} instead.
> {code}
> :chkMHome
> set "MAVEN_HOME=%~dp0.."
> if not "%MAVEN_HOME%"=="" goto valMHome
> goto error
> :valMHome
> :stripMHome
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6331) Remove maven-bundle-pugin from build pluginManagement
[ https://issues.apache.org/jira/browse/MNG-6331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314860#comment-16314860 ] Karl Heinz Marbaise commented on MNG-6331: -- Done in [abd73da3a492ee544c6102840fc012409a4ac83d|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=abd73da3a492ee544c6102840fc012409a4ac83d] > Remove maven-bundle-pugin from build pluginManagement > - > > Key: MNG-6331 > URL: https://issues.apache.org/jira/browse/MNG-6331 > Project: Maven > Issue Type: Task >Affects Versions: 3.5.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Trivial > Fix For: 3.5.3 > > > Remove the maven-bundle-plugin from build pluginManagement cause it not used > anywhere in the build. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6331) Remove maven-bundle-pugin from build pluginManagement
[ https://issues.apache.org/jira/browse/MNG-6331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314859#comment-16314859 ] Hudson commented on MNG-6331: - Build succeeded in Jenkins: maven-3.x-jenkinsfile » master #153 See https://builds.apache.org/job/maven-3.x-jenkinsfile/job/master/153/ > Remove maven-bundle-pugin from build pluginManagement > - > > Key: MNG-6331 > URL: https://issues.apache.org/jira/browse/MNG-6331 > Project: Maven > Issue Type: Task >Affects Versions: 3.5.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Trivial > Fix For: 3.5.3 > > > Remove the maven-bundle-plugin from build pluginManagement cause it not used > anywhere in the build. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6331) Remove maven-bundle-pugin from build pluginManagement
[ https://issues.apache.org/jira/browse/MNG-6331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314855#comment-16314855 ] Hudson commented on MNG-6331: - Build succeeded in Jenkins: Maven TLP (wip) » maven » master #24 See https://builds.apache.org/job/maven-wip/job/maven/job/master/24/ > Remove maven-bundle-pugin from build pluginManagement > - > > Key: MNG-6331 > URL: https://issues.apache.org/jira/browse/MNG-6331 > Project: Maven > Issue Type: Task >Affects Versions: 3.5.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Trivial > Fix For: 3.5.3 > > > Remove the maven-bundle-plugin from build pluginManagement cause it not used > anywhere in the build. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6305) Validation of CI friendly version incorrect
[
https://issues.apache.org/jira/browse/MNG-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314829#comment-16314829
]
Hudson commented on MNG-6305:
-
Build succeeded in Jenkins: Maven TLP (wip) » maven » MNG-6332 #3
See https://builds.apache.org/job/maven-wip/job/maven/job/MNG-6332/3/
> Validation of CI friendly version incorrect
> ---
>
> Key: MNG-6305
> URL: https://issues.apache.org/jira/browse/MNG-6305
> Project: Maven
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.5.2
>Reporter: Robert Scholte
>Assignee: Karl Heinz Marbaise
> Fix For: 3.5.3
>
>
> The version may contain some special expression, which are considered as a
> constant.
> However, the following version is treated as valid too:
> {code:xml}
> ${sha1}${var}
> {code}
> The validator should check every expression and verify they're all constants.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6332) Cleaned up mvn.cmd Script
[
https://issues.apache.org/jira/browse/MNG-6332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314830#comment-16314830
]
Hudson commented on MNG-6332:
-
Build succeeded in Jenkins: Maven TLP (wip) » maven » MNG-6332 #3
See https://builds.apache.org/job/maven-wip/job/maven/job/MNG-6332/3/
> Cleaned up mvn.cmd Script
> -
>
> Key: MNG-6332
> URL: https://issues.apache.org/jira/browse/MNG-6332
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.5.2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.3
>
>
> Based on the following [Stackoverflow
> quesiton|https://stackoverflow.com/q/48027497/296328]:
> The given label {{valMHome}} can be removed. In the following case can be
> replaced by using{{stripMHome}} instead.
> {code}
> :chkMHome
> set "MAVEN_HOME=%~dp0.."
> if not "%MAVEN_HOME%"=="" goto valMHome
> goto error
> :valMHome
> :stripMHome
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6305) Validation of CI friendly version incorrect
[
https://issues.apache.org/jira/browse/MNG-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314826#comment-16314826
]
Hudson commented on MNG-6305:
-
Build succeeded in Jenkins: maven-3.x-jenkinsfile » MNG-6332 #2
See https://builds.apache.org/job/maven-3.x-jenkinsfile/job/MNG-6332/2/
> Validation of CI friendly version incorrect
> ---
>
> Key: MNG-6305
> URL: https://issues.apache.org/jira/browse/MNG-6305
> Project: Maven
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.5.2
>Reporter: Robert Scholte
>Assignee: Karl Heinz Marbaise
> Fix For: 3.5.3
>
>
> The version may contain some special expression, which are considered as a
> constant.
> However, the following version is treated as valid too:
> {code:xml}
> ${sha1}${var}
> {code}
> The validator should check every expression and verify they're all constants.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6332) Cleaned up mvn.cmd Script
[
https://issues.apache.org/jira/browse/MNG-6332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314827#comment-16314827
]
Hudson commented on MNG-6332:
-
Build succeeded in Jenkins: maven-3.x-jenkinsfile » MNG-6332 #2
See https://builds.apache.org/job/maven-3.x-jenkinsfile/job/MNG-6332/2/
> Cleaned up mvn.cmd Script
> -
>
> Key: MNG-6332
> URL: https://issues.apache.org/jira/browse/MNG-6332
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.5.2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.3
>
>
> Based on the following [Stackoverflow
> quesiton|https://stackoverflow.com/q/48027497/296328]:
> The given label {{valMHome}} can be removed. In the following case can be
> replaced by using{{stripMHome}} instead.
> {code}
> :chkMHome
> set "MAVEN_HOME=%~dp0.."
> if not "%MAVEN_HOME%"=="" goto valMHome
> goto error
> :valMHome
> :stripMHome
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MENFORCER-281) RequirePluginVersions broken with "CI Friendly versions"
[
https://issues.apache.org/jira/browse/MENFORCER-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314820#comment-16314820
]
Karl Heinz Marbaise commented on MENFORCER-281:
---
Thanks [~jnord_cbs] for your PR with the integration test that helps a lot.
> RequirePluginVersions broken with "CI Friendly versions"
>
>
> Key: MENFORCER-281
> URL: https://issues.apache.org/jira/browse/MENFORCER-281
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4.1, 3.0.0-M1
>Reporter: James Nord
>Assignee: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 3.0.0
>
>
> Maven
> [3.5.0|https://maven.apache.org/docs/3.5.0/release-notes.html#Overview_about_the_changes]
> [introduced CI friendly
> versions|https://maven.apache.org/maven-ci-friendly.html].
> However when used with [multi module
> project|https://maven.apache.org/maven-ci-friendly.html#Multi_Module_Setup]
> the enforcer fails the build as it can not resolve the parent.
> The bug is that the parent resolution of a module in the reactor is
> attempting to use the untransposed version.
> e.g.
> {noformat}
> INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (display-info) @ sub-module
> ---
> [WARNING] Rule 1: org.apache.maven.plugins.enforcer.RequirePluginVersions
> failed with message:
> Failure to find com.acme.product:parent:pom:0.9.8-${revision}SNAPSHOT in
> https://repo.acme.com/content/groups/all was cached in the local repository,
> resolution will not be reattempted until the update interval of acme-internal
> has elapsed or updates are forced
> com.acme.product:parent:pom:0.9.8-${revision}SNAPSHOT
> from the specified remote repositories:
> acme-internal (https://repo.acme.com/content/groups/all, releases=true,
> snapshots=true)
> {noformat}
> to reproduce create a new multi module project as per the linked page above.
> Add the enforcer plugin and rule to the build
> run {{mvn -Drevision=1.2.3-SNAPSHOT}} and watch the build fail.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (MENFORCER-281) RequirePluginVersions broken with "CI Friendly versions"
[
https://issues.apache.org/jira/browse/MENFORCER-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reassigned MENFORCER-281:
-
Assignee: Karl Heinz Marbaise
> RequirePluginVersions broken with "CI Friendly versions"
>
>
> Key: MENFORCER-281
> URL: https://issues.apache.org/jira/browse/MENFORCER-281
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4.1, 3.0.0-M1
>Reporter: James Nord
>Assignee: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 3.0.0
>
>
> Maven
> [3.5.0|https://maven.apache.org/docs/3.5.0/release-notes.html#Overview_about_the_changes]
> [introduced CI friendly
> versions|https://maven.apache.org/maven-ci-friendly.html].
> However when used with [multi module
> project|https://maven.apache.org/maven-ci-friendly.html#Multi_Module_Setup]
> the enforcer fails the build as it can not resolve the parent.
> The bug is that the parent resolution of a module in the reactor is
> attempting to use the untransposed version.
> e.g.
> {noformat}
> INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (display-info) @ sub-module
> ---
> [WARNING] Rule 1: org.apache.maven.plugins.enforcer.RequirePluginVersions
> failed with message:
> Failure to find com.acme.product:parent:pom:0.9.8-${revision}SNAPSHOT in
> https://repo.acme.com/content/groups/all was cached in the local repository,
> resolution will not be reattempted until the update interval of acme-internal
> has elapsed or updates are forced
> com.acme.product:parent:pom:0.9.8-${revision}SNAPSHOT
> from the specified remote repositories:
> acme-internal (https://repo.acme.com/content/groups/all, releases=true,
> snapshots=true)
> {noformat}
> to reproduce create a new multi module project as per the linked page above.
> Add the enforcer plugin and rule to the build
> run {{mvn -Drevision=1.2.3-SNAPSHOT}} and watch the build fail.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6331) Remove maven-bundle-pugin from build pluginManagement
[ https://issues.apache.org/jira/browse/MNG-6331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314809#comment-16314809 ] Hudson commented on MNG-6331: - Build succeeded in Jenkins: Maven TLP (wip) » maven » MNG-6331 #2 See https://builds.apache.org/job/maven-wip/job/maven/job/MNG-6331/2/ > Remove maven-bundle-pugin from build pluginManagement > - > > Key: MNG-6331 > URL: https://issues.apache.org/jira/browse/MNG-6331 > Project: Maven > Issue Type: Task >Affects Versions: 3.5.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Trivial > Fix For: 3.5.3 > > > Remove the maven-bundle-plugin from build pluginManagement cause it not used > anywhere in the build. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6305) Validation of CI friendly version incorrect
[
https://issues.apache.org/jira/browse/MNG-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314808#comment-16314808
]
Hudson commented on MNG-6305:
-
Build succeeded in Jenkins: Maven TLP (wip) » maven » MNG-6331 #2
See https://builds.apache.org/job/maven-wip/job/maven/job/MNG-6331/2/
> Validation of CI friendly version incorrect
> ---
>
> Key: MNG-6305
> URL: https://issues.apache.org/jira/browse/MNG-6305
> Project: Maven
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.5.2
>Reporter: Robert Scholte
>Assignee: Karl Heinz Marbaise
> Fix For: 3.5.3
>
>
> The version may contain some special expression, which are considered as a
> constant.
> However, the following version is treated as valid too:
> {code:xml}
> ${sha1}${var}
> {code}
> The validator should check every expression and verify they're all constants.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MPLUGIN-331) Check the existence of plugin.xml rather than project packaging in PluginReport.canGenerateReport()
[
https://issues.apache.org/jira/browse/MPLUGIN-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314810#comment-16314810
]
ASF GitHub Bot commented on MPLUGIN-331:
rfscholte commented on a change in pull request #10: [MPLUGIN-331] Let
plugin:report support takari-maven-plugin packaging
URL: https://github.com/apache/maven-plugin-tools/pull/10#discussion_r160032052
##
File path:
maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java
##
@@ -197,9 +197,18 @@
@Component
private RuntimeInformation rtInfo;
+/**
+ * Path to {@code plugin.xml} plugin descriptor to generate the report
from.
+ *
+ * @since 3.5.1
+ */
+@Parameter( defaultValue =
"${project.build.outputDirectory}/META-INF/maven/plugin.xml", required = true )
Review comment:
I would like to see this as a readOnly parameter. Changing its value will
break things.
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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
> Check the existence of plugin.xml rather than project packaging in
> PluginReport.canGenerateReport()
> ---
>
> Key: MPLUGIN-331
> URL: https://issues.apache.org/jira/browse/MPLUGIN-331
> Project: Maven Plugin Tools
> Issue Type: Task
> Components: Plugin Plugin
>Reporter: Peter Palaga
>Assignee: Hervé Boutemy
> Fix For: 3.5.1
>
>
> {{org.apache.maven.plugin.plugin.PluginReport.canGenerateReport()}} currently
> reads
> {code}
> return "maven-plugin".equals( project.getPackaging() );
> {code}
> I propose to change it to
> {code}
> return "maven-plugin".equals( project.getPackaging() )
> || "takari-maven-plugin".equals( project.getPackaging() );
> {code}
> so that also takari-maven-plugins are supported.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] rfscholte commented on a change in pull request #10: [MPLUGIN-331] Let plugin:report support takari-maven-plugin packaging
rfscholte commented on a change in pull request #10: [MPLUGIN-331] Let
plugin:report support takari-maven-plugin packaging
URL: https://github.com/apache/maven-plugin-tools/pull/10#discussion_r160032052
##
File path:
maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java
##
@@ -197,9 +197,18 @@
@Component
private RuntimeInformation rtInfo;
+/**
+ * Path to {@code plugin.xml} plugin descriptor to generate the report
from.
+ *
+ * @since 3.5.1
+ */
+@Parameter( defaultValue =
"${project.build.outputDirectory}/META-INF/maven/plugin.xml", required = true )
Review comment:
I would like to see this as a readOnly parameter. Changing its value will
break things.
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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
With regards,
Apache Git Services
[jira] [Updated] (MENFORCER-281) RequirePluginVersions broken with "CI Friendly versions"
[
https://issues.apache.org/jira/browse/MENFORCER-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MENFORCER-281:
--
Fix Version/s: 3.0.0
> RequirePluginVersions broken with "CI Friendly versions"
>
>
> Key: MENFORCER-281
> URL: https://issues.apache.org/jira/browse/MENFORCER-281
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4.1, 3.0.0-M1
>Reporter: James Nord
>Priority: Critical
> Fix For: 3.0.0
>
>
> Maven
> [3.5.0|https://maven.apache.org/docs/3.5.0/release-notes.html#Overview_about_the_changes]
> [introduced CI friendly
> versions|https://maven.apache.org/maven-ci-friendly.html].
> However when used with [multi module
> project|https://maven.apache.org/maven-ci-friendly.html#Multi_Module_Setup]
> the enforcer fails the build as it can not resolve the parent.
> The bug is that the parent resolution of a module in the reactor is
> attempting to use the untransposed version.
> e.g.
> {noformat}
> INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (display-info) @ sub-module
> ---
> [WARNING] Rule 1: org.apache.maven.plugins.enforcer.RequirePluginVersions
> failed with message:
> Failure to find com.acme.product:parent:pom:0.9.8-${revision}SNAPSHOT in
> https://repo.acme.com/content/groups/all was cached in the local repository,
> resolution will not be reattempted until the update interval of acme-internal
> has elapsed or updates are forced
> com.acme.product:parent:pom:0.9.8-${revision}SNAPSHOT
> from the specified remote repositories:
> acme-internal (https://repo.acme.com/content/groups/all, releases=true,
> snapshots=true)
> {noformat}
> to reproduce create a new multi module project as per the linked page above.
> Add the enforcer plugin and rule to the build
> run {{mvn -Drevision=1.2.3-SNAPSHOT}} and watch the build fail.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MENFORCER-283) Java 9 banDuplicateClasses incorrectly sees module-info.class as duplicate
[
https://issues.apache.org/jira/browse/MENFORCER-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MENFORCER-283:
--
Fix Version/s: 3.0.0
> Java 9 banDuplicateClasses incorrectly sees module-info.class as duplicate
> --
>
> Key: MENFORCER-283
> URL: https://issues.apache.org/jira/browse/MENFORCER-283
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 1.4.1
>Reporter: Sven Haster
>Priority: Minor
> Fix For: 3.0.0
>
>
> When running the enforcer plugin with banDuplicateClasses rule against a
> project with dependencies on java-9 compatible libraries which include a
> module-info.class file, the plugin sees the multiple module-info files as
> duplicate classes.
> It should simply ignore these similar to package-info.
> In our projects, it is the dependencies on multiple libs from org.ow2.asm
> which provides the module-info class, rendering the following output:
> {noformat}
> [WARNING] Rule 2: org.apache.maven.plugins.enforcer.BanDuplicateClasses
> failed with message:
> Duplicate classes found:
> Found in:
> org.ow2.asm:asm-tree:jar:6.0:compile
> org.ow2.asm:asm:jar:6.0:compile
> org.ow2.asm:asm-util:jar:6.0:compile
> Duplicate classes:
> module-info.class
> {noformat}
> We can easily work around this problem for now by adding a global rule to
> ignore module-info such as the following but it would be nice if the enforces
> plugin ignored this file by default.
> {code:xml}
>
>
> module-info
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MENFORCER-185) Require Release Dependencies ignorant about aggregator build
[ https://issues.apache.org/jira/browse/MENFORCER-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MENFORCER-185: -- Fix Version/s: (was: more-investigation) 3.0.0 > Require Release Dependencies ignorant about aggregator build > > > Key: MENFORCER-185 > URL: https://issues.apache.org/jira/browse/MENFORCER-185 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Standard Rules >Affects Versions: 1.3.1 >Reporter: Thomas Diesler > Fix For: 3.0.0 > > Attachments: MENFORCER-185.patch, seuss.zip > > > If A depends on B it is ok for A-1.0.0-SNAPSHOT to have snapshot dependency > on B-1.0.0-SNAPSHOT if B was build before A during the same reactor build. > Using the requireReleaseDeps rule it seems that SNAPSHOTS are generally not > allowed even when they belong to the same project and were built during the > same reactor build. > We have a complex project with 100+ modules. I want to enforce that no module > has dependencies on project SNAPSHOTS that were not included in the build. In > such case A would use a stale version of B that happened to be available in > the local/remote maven repository. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6331) Remove maven-bundle-pugin from build pluginManagement
[ https://issues.apache.org/jira/browse/MNG-6331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MNG-6331: --- Description: Remove the maven-bundle-plugin from build pluginManagement cause it not used anywhere in the build. (was: Removed the maven-bundle-plugin from build cause it not used anywhere in the build.) > Remove maven-bundle-pugin from build pluginManagement > - > > Key: MNG-6331 > URL: https://issues.apache.org/jira/browse/MNG-6331 > Project: Maven > Issue Type: Task >Affects Versions: 3.5.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Trivial > Fix For: 3.5.3 > > > Remove the maven-bundle-plugin from build pluginManagement cause it not used > anywhere in the build. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6331) Remove maven-bundle-pugin from build pluginManagement
[ https://issues.apache.org/jira/browse/MNG-6331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MNG-6331: --- Summary: Remove maven-bundle-pugin from build pluginManagement (was: Removed maven-bundle-pugin from build) > Remove maven-bundle-pugin from build pluginManagement > - > > Key: MNG-6331 > URL: https://issues.apache.org/jira/browse/MNG-6331 > Project: Maven > Issue Type: Task >Affects Versions: 3.5.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Trivial > Fix For: 3.5.3 > > > Removed the maven-bundle-plugin from build cause it not used anywhere in the > build. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MENFORCER-231) Reactor Module Convergence doesn't work when relativePath is set
[
https://issues.apache.org/jira/browse/MENFORCER-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MENFORCER-231:
--
Fix Version/s: (was: 3.0.1)
> Reactor Module Convergence doesn't work when relativePath is set
>
>
> Key: MENFORCER-231
> URL: https://issues.apache.org/jira/browse/MENFORCER-231
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4
>Reporter: Daniel Roig
> Attachments: menforcer-231.zip
>
>
> When setting version to X in the root pom of a multi-module build and version
> Y in a child pom and the child pom specifies a correct {{}} tag
> in the parent section of the child pom, Maven will not fail the build.
> I tried invoking {{mvn validate}} from the root and it reported that the
> build succeeded. However, if I remove the {{}} from the parent
> section, the enforcer rule correctly reports that the module build is
> incoherent.
> Moreover, if I invoke {{mvn -pl :sub-module validate}} _with_ the
> {{}} reinserted, it will again correctly report an incoherent
> build.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MENFORCER-231) Reactor Module Convergence doesn't work when relativePath is set
[
https://issues.apache.org/jira/browse/MENFORCER-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MENFORCER-231.
-
Resolution: Won't Fix
Assignee: Karl Heinz Marbaise
So maybe I misunderstand a thing here but based on the original attached zip
file containing the example If I run: {{mvn clean}} on the root level I get
(Commented out maven-enforcer):
{code}
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for com.example:child-1:[unknown-version]:
Failure to find com.example:root:pom:1.1-SNAPSHOT in
http://localhost:8081/nexus/content/groups/public was cached in the local
repository, resolution will not be reattempted until the update interval of
nexus has elapsed or updates are forced and 'parent.relativePath' points at
wrong local POM @ line 4, column 11
@
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project com.example:child-1:[unknown-version]
(/Users/kama/Downloads/menforcer-231/child1/child-1/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM for
com.example:child-1:[unknown-version]: Failure to find
com.example:root:pom:1.1-SNAPSHOT in
http://localhost:8081/nexus/content/groups/public was cached in the local
repository, resolution will not be reattempted until the update interval of
nexus has elapsed or updates are forced and 'parent.relativePath' points at
wrong local POM @ line 4, column 11 -> [Help 2]
[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
[ERROR] [Help 2]
http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
{code}
The problem is simply Maven tries to read the whole reactor. Reading the
child-1 it identifies that the parent defined in {{child-1}} does not exists
and will fail cause it can't be found. What you can also see that Maven tries
to resolve that parent from the remote repository...
Before Maven 3.3.9 the behaviour was simply wrong not to resolve the parent
from the remote repository in such cases. See the [Release
Notes|http://maven.apache.org/docs/3.3.9/release-notes.html] more in detail
MNG-5840.
How you can reproduce this:
* Change the version of the parent pom to {{1.1-SNAPSHOT}}
* {{mvn install -N}} on root level
* Change the version of the parent pom back to {{1.0-SNAPSHOT}}
* {{mvn validate}} and you will get the correct error message from
ReactorModuleConvergence.
Based on that I will close the issue. If you have further details don't
hesitate to reopen the issue.
> Reactor Module Convergence doesn't work when relativePath is set
>
>
> Key: MENFORCER-231
> URL: https://issues.apache.org/jira/browse/MENFORCER-231
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4
>Reporter: Daniel Roig
>Assignee: Karl Heinz Marbaise
> Attachments: menforcer-231.zip
>
>
> When setting version to X in the root pom of a multi-module build and version
> Y in a child pom and the child pom specifies a correct {{}} tag
> in the parent section of the child pom, Maven will not fail the build.
> I tried invoking {{mvn validate}} from the root and it reported that the
> build succeeded. However, if I remove the {{}} from the parent
> section, the enforcer rule correctly reports that the module build is
> incoherent.
> Moreover, if I invoke {{mvn -pl :sub-module validate}} _with_ the
> {{}} reinserted, it will again correctly report an incoherent
> build.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MENFORCER-221) Removed deprecated marked constructor from EnforcerExpressionEvaluator
[ https://issues.apache.org/jira/browse/MENFORCER-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MENFORCER-221. - Resolution: Fixed Done in [655a24e6d3b72c5cb6d5fa9448206eccea3834ee|https://gitbox.apache.org/repos/asf?p=maven-enforcer.git;a=commitdiff;h=655a24e6d3b72c5cb6d5fa9448206eccea3834ee] > Removed deprecated marked constructor from EnforcerExpressionEvaluator > -- > > Key: MENFORCER-221 > URL: https://issues.apache.org/jira/browse/MENFORCER-221 > Project: Maven Enforcer Plugin > Issue Type: Task >Affects Versions: 1.4.1, 3.0.0-M1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > > Remove the depreacted marked constructor which has been kept for backward > compatiblity in 1.4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MENFORCER-221) Removed deprecated marked constructor from EnforcerExpressionEvaluator
[ https://issues.apache.org/jira/browse/MENFORCER-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314769#comment-16314769 ] Hudson commented on MENFORCER-221: -- Build succeeded in Jenkins: Maven TLP » maven-enforcer » master #8 See https://builds.apache.org/job/maven-box/job/maven-enforcer/job/master/8/ > Removed deprecated marked constructor from EnforcerExpressionEvaluator > -- > > Key: MENFORCER-221 > URL: https://issues.apache.org/jira/browse/MENFORCER-221 > Project: Maven Enforcer Plugin > Issue Type: Task >Affects Versions: 1.4.1, 3.0.0-M1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > > Remove the depreacted marked constructor which has been kept for backward > compatiblity in 1.4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MENFORCER-221) Removed deprecated marked constructor from EnforcerExpressionEvaluator
[ https://issues.apache.org/jira/browse/MENFORCER-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise reassigned MENFORCER-221: - Assignee: Karl Heinz Marbaise > Removed deprecated marked constructor from EnforcerExpressionEvaluator > -- > > Key: MENFORCER-221 > URL: https://issues.apache.org/jira/browse/MENFORCER-221 > Project: Maven Enforcer Plugin > Issue Type: Task >Affects Versions: 1.4.1, 3.0.0-M1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > > Remove the depreacted marked constructor which has been kept for backward > compatiblity in 1.4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MENFORCER-221) Removed deprecated marked constructor from EnforcerExpressionEvaluator
[ https://issues.apache.org/jira/browse/MENFORCER-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MENFORCER-221: -- Fix Version/s: (was: 3.0.1) 3.0.0 > Removed deprecated marked constructor from EnforcerExpressionEvaluator > -- > > Key: MENFORCER-221 > URL: https://issues.apache.org/jira/browse/MENFORCER-221 > Project: Maven Enforcer Plugin > Issue Type: Task >Affects Versions: 1.4.1, 3.0.0-M1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > > Remove the depreacted marked constructor which has been kept for backward > compatiblity in 1.4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MENFORCER-221) Removed deprecated marked constructor from EnforcerExpressionEvaluator
[ https://issues.apache.org/jira/browse/MENFORCER-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MENFORCER-221: -- Affects Version/s: 3.0.0-M1 > Removed deprecated marked constructor from EnforcerExpressionEvaluator > -- > > Key: MENFORCER-221 > URL: https://issues.apache.org/jira/browse/MENFORCER-221 > Project: Maven Enforcer Plugin > Issue Type: Task >Affects Versions: 1.4.1, 3.0.0-M1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > > Remove the depreacted marked constructor which has been kept for backward > compatiblity in 1.4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MENFORCER-221) Removed deprecated marked constructor from EnforcerExpressionEvaluator
[ https://issues.apache.org/jira/browse/MENFORCER-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MENFORCER-221: -- Affects Version/s: 1.4.1 > Removed deprecated marked constructor from EnforcerExpressionEvaluator > -- > > Key: MENFORCER-221 > URL: https://issues.apache.org/jira/browse/MENFORCER-221 > Project: Maven Enforcer Plugin > Issue Type: Task >Affects Versions: 1.4.1, 3.0.0-M1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > > Remove the depreacted marked constructor which has been kept for backward > compatiblity in 1.4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MENFORCER-221) Removed deprecated marked constructor from EnforcerExpressionEvaluator
[ https://issues.apache.org/jira/browse/MENFORCER-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314756#comment-16314756 ] Hudson commented on MENFORCER-221: -- Build succeeded in Jenkins: Maven TLP » maven-enforcer » MENFORCER-221 #2 See https://builds.apache.org/job/maven-box/job/maven-enforcer/job/MENFORCER-221/2/ > Removed deprecated marked constructor from EnforcerExpressionEvaluator > -- > > Key: MENFORCER-221 > URL: https://issues.apache.org/jira/browse/MENFORCER-221 > Project: Maven Enforcer Plugin > Issue Type: Task >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.1 > > > Remove the depreacted marked constructor which has been kept for backward > compatiblity in 1.4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
