[jira] [Created] (MJAVADOC-670) Minor improvements
Arturo Bernal created MJAVADOC-670: -- Summary: Minor improvements Key: MJAVADOC-670 URL: https://issues.apache.org/jira/browse/MJAVADOC-670 Project: Maven Javadoc Plugin Issue Type: Improvement Reporter: Arturo Bernal -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MARTIFACT-8) multi-module: copy aggregate buildinfo to root target
[ https://issues.apache.org/jira/browse/MARTIFACT-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MARTIFACT-8. - Resolution: Fixed done in https://github.com/apache/maven-artifact-plugin/commit/7ea7f796a2310fbd4153e7ccdb65e4d9388f1b4a and aggregate artifact id added to buildinfo, to discover from root copy in which module the original buildinfo was copied from, in https://github.com/apache/maven-artifact-plugin/commit/9e7bb8716c8d6c819ae9e6e221993d3cadcfab37 > multi-module: copy aggregate buildinfo to root target > - > > Key: MARTIFACT-8 > URL: https://issues.apache.org/jira/browse/MARTIFACT-8 > Project: Maven Artifact Plugin > Issue Type: New Feature > Components: artifact:buildinfo >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 0.1 > > > as seen in MARTIFACT-6, in multi-module builds, aggregate buildinfo can be > generated and attached for deploy only in the last module, even if from a > user point of view, root would be much easier to understand > attaching buildinfo to root module for deployment is tricky, because root > module deployment already happened > but it's easy to copy buildinfo to root target dir, with root artifactId: at > least locally on disk, the buildinfo will be easier to find -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MARTIFACT-8) multi-module: copy aggregate buildinfo to root target
Herve Boutemy created MARTIFACT-8: - Summary: multi-module: copy aggregate buildinfo to root target Key: MARTIFACT-8 URL: https://issues.apache.org/jira/browse/MARTIFACT-8 Project: Maven Artifact Plugin Issue Type: New Feature Components: artifact:buildinfo Reporter: Herve Boutemy Assignee: Herve Boutemy Fix For: 0.1 as seen in MARTIFACT-6, in multi-module builds, aggregate buildinfo can be generated and attached for deploy only in the last module, even if from a user point of view, root would be much easier to understand attaching buildinfo to root module for deployment is tricky, because root module deployment already happened but it's easy to copy buildinfo to root target dir, with root artifactId: at least locally on disk, the buildinfo will be easier to find -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (WAGON-603) Connection reset error from Azure pipelines
[
https://issues.apache.org/jira/browse/WAGON-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265717#comment-17265717
]
Arul Elvis J commented on WAGON-603:
[~michael-o] PFA with system.debug=true along with batch mode
[^failed_logs-batch-wired_jan15.txt]
I can see detailed HTTP logging as below:
[DEBUG] Connection request: [route:
\{s}->https://repo.maven.apache.org:443][total kept alive: 1; route allocated:
5 of 20; total allocated: 5 of 40]
2021-01-15T03:35:23.2584394Z [DEBUG] Connection leased: [id: 122][route:
\{s}->https://repo.maven.apache.org:443][total kept alive: 0; route allocated:
5 of 20; total allocated: 5 of 40]
2021-01-15T03:35:23.2585181Z [DEBUG] http-outgoing-122: set socket timeout to 0
2021-01-15T03:35:23.2585699Z [DEBUG] http-outgoing-122: set socket timeout to
180
2021-01-15T03:35:23.2586397Z [DEBUG] Executing request GET
/maven2/com/fasterxml/jackson/core/jackson-core/2.9.6/jackson-core-2.9.6.jar.sha1
HTTP/1.1
Looking for something else ?
> Connection reset error from Azure pipelines
> ---
>
> Key: WAGON-603
> URL: https://issues.apache.org/jira/browse/WAGON-603
> Project: Maven Wagon
> Issue Type: Bug
> Environment: In both Ubuntu and Windows agent specification
>Reporter: Arul Elvis J
>Priority: Blocker
> Fix For: waiting-for-feedback
>
> Attachments: failed_logs-batch-wired.txt,
> failed_logs-batch-wired_jan15.txt, failed_logs-batch-wired_jan15.txt,
> failed_logs-batch-wired_latest.txt, logs_143613.zip
>
> Original Estimate: 408h
> Remaining Estimate: 408h
>
> When the pipelines are executed in Azure pipelines, we are facing connection
> reset error. Azure pipelines team claims that connection is closed from Maven
> central repo end. Below is the error message. Have attached the complete log
> zip file for your reference. Can you please prioritize as soon as possible,
> as it is impacting all the pipelines including the production builds ?
>
> {{ }}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-resources-plugin:3.0.2:resources
> (default-resources) on project bata-s-sfdc-deferredpromo: Execution
> default-resources of goal
> org.apache.maven.plugins:maven-resources-plugin:3.0.2:resources failed:
> Plugin org.apache.maven.plugins:maven-resources-plugin:3.0.2 or one of its
> dependencies could not be resolved: Failed to collect dependencies at
> org.apache.maven.plugins:maven-resources-plugin:jar:3.0.2 ->
> org.apache.maven:maven-plugin-api:jar:3.0 ->
> org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2 ->
> org.codehaus.plexus:plexus-component-annotations:jar:1.6: Failed to read
> artifact descriptor for
> org.codehaus.plexus:plexus-component-annotations:jar:1.6: Could not transfer
> artifact org.codehaus.plexus:plexus-component-annotations:pom:1.6 from/to
> central ([https://repo.maven.apache.org/maven2)]: Connection reset -> [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]
> The process
> 'C:\ProgramData\chocolatey\lib\maven\apache-maven-3.6.3\bin\mvn.cmd' failed
> with exit code 1
> Could not retrieve code analysis results - Maven run failed.
> {{##[error]Build failed. }}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (WAGON-603) Connection reset error from Azure pipelines
[
https://issues.apache.org/jira/browse/WAGON-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arul Elvis J updated WAGON-603:
---
Attachment: failed_logs-batch-wired_jan15.txt
> Connection reset error from Azure pipelines
> ---
>
> Key: WAGON-603
> URL: https://issues.apache.org/jira/browse/WAGON-603
> Project: Maven Wagon
> Issue Type: Bug
> Environment: In both Ubuntu and Windows agent specification
>Reporter: Arul Elvis J
>Priority: Blocker
> Fix For: waiting-for-feedback
>
> Attachments: failed_logs-batch-wired.txt,
> failed_logs-batch-wired_jan15.txt, failed_logs-batch-wired_jan15.txt,
> failed_logs-batch-wired_latest.txt, logs_143613.zip
>
> Original Estimate: 408h
> Remaining Estimate: 408h
>
> When the pipelines are executed in Azure pipelines, we are facing connection
> reset error. Azure pipelines team claims that connection is closed from Maven
> central repo end. Below is the error message. Have attached the complete log
> zip file for your reference. Can you please prioritize as soon as possible,
> as it is impacting all the pipelines including the production builds ?
>
> {{ }}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-resources-plugin:3.0.2:resources
> (default-resources) on project bata-s-sfdc-deferredpromo: Execution
> default-resources of goal
> org.apache.maven.plugins:maven-resources-plugin:3.0.2:resources failed:
> Plugin org.apache.maven.plugins:maven-resources-plugin:3.0.2 or one of its
> dependencies could not be resolved: Failed to collect dependencies at
> org.apache.maven.plugins:maven-resources-plugin:jar:3.0.2 ->
> org.apache.maven:maven-plugin-api:jar:3.0 ->
> org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2 ->
> org.codehaus.plexus:plexus-component-annotations:jar:1.6: Failed to read
> artifact descriptor for
> org.codehaus.plexus:plexus-component-annotations:jar:1.6: Could not transfer
> artifact org.codehaus.plexus:plexus-component-annotations:pom:1.6 from/to
> central ([https://repo.maven.apache.org/maven2)]: Connection reset -> [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]
> The process
> 'C:\ProgramData\chocolatey\lib\maven\apache-maven-3.6.3\bin\mvn.cmd' failed
> with exit code 1
> Could not retrieve code analysis results - Maven run failed.
> {{##[error]Build failed. }}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (WAGON-603) Connection reset error from Azure pipelines
[
https://issues.apache.org/jira/browse/WAGON-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arul Elvis J updated WAGON-603:
---
Attachment: failed_logs-batch-wired_jan15.txt
> Connection reset error from Azure pipelines
> ---
>
> Key: WAGON-603
> URL: https://issues.apache.org/jira/browse/WAGON-603
> Project: Maven Wagon
> Issue Type: Bug
> Environment: In both Ubuntu and Windows agent specification
>Reporter: Arul Elvis J
>Priority: Blocker
> Fix For: waiting-for-feedback
>
> Attachments: failed_logs-batch-wired.txt,
> failed_logs-batch-wired_jan15.txt, failed_logs-batch-wired_jan15.txt,
> failed_logs-batch-wired_latest.txt, logs_143613.zip
>
> Original Estimate: 408h
> Remaining Estimate: 408h
>
> When the pipelines are executed in Azure pipelines, we are facing connection
> reset error. Azure pipelines team claims that connection is closed from Maven
> central repo end. Below is the error message. Have attached the complete log
> zip file for your reference. Can you please prioritize as soon as possible,
> as it is impacting all the pipelines including the production builds ?
>
> {{ }}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-resources-plugin:3.0.2:resources
> (default-resources) on project bata-s-sfdc-deferredpromo: Execution
> default-resources of goal
> org.apache.maven.plugins:maven-resources-plugin:3.0.2:resources failed:
> Plugin org.apache.maven.plugins:maven-resources-plugin:3.0.2 or one of its
> dependencies could not be resolved: Failed to collect dependencies at
> org.apache.maven.plugins:maven-resources-plugin:jar:3.0.2 ->
> org.apache.maven:maven-plugin-api:jar:3.0 ->
> org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2 ->
> org.codehaus.plexus:plexus-component-annotations:jar:1.6: Failed to read
> artifact descriptor for
> org.codehaus.plexus:plexus-component-annotations:jar:1.6: Could not transfer
> artifact org.codehaus.plexus:plexus-component-annotations:pom:1.6 from/to
> central ([https://repo.maven.apache.org/maven2)]: Connection reset -> [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]
> The process
> 'C:\ProgramData\chocolatey\lib\maven\apache-maven-3.6.3\bin\mvn.cmd' failed
> with exit code 1
> Could not retrieve code analysis results - Maven run failed.
> {{##[error]Build failed. }}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-124) Need better plan for getting dependency-reduced-pom.xml out of basedir
[ https://issues.apache.org/jira/browse/MSHADE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265692#comment-17265692 ] Bruno Medeiros commented on MSHADE-124: --- Writing this temporary file may be the cause of this other issue. > Need better plan for getting dependency-reduced-pom.xml out of basedir > -- > > Key: MSHADE-124 > URL: https://issues.apache.org/jira/browse/MSHADE-124 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 1.7.1 >Reporter: Benson Margulies >Priority: Major > > MSHADE-123 reported that putting the d-r-p into some location other > than 'basedir' causes 'basedir' to follow it around, which can break builds. > This is hard to fix, given the core maven definition of basedir as 'the dir > containing the pom' with no option to change it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (MSHADE-124) Need better plan for getting dependency-reduced-pom.xml out of basedir
[ https://issues.apache.org/jira/browse/MSHADE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Medeiros updated MSHADE-124: -- Comment: was deleted (was: Writing this temporary file may be the cause of this other issue.) > Need better plan for getting dependency-reduced-pom.xml out of basedir > -- > > Key: MSHADE-124 > URL: https://issues.apache.org/jira/browse/MSHADE-124 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 1.7.1 >Reporter: Benson Margulies >Priority: Major > > MSHADE-123 reported that putting the d-r-p into some location other > than 'basedir' causes 'basedir' to follow it around, which can break builds. > This is hard to fix, given the core maven definition of basedir as 'the dir > containing the pom' with no option to change it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHADE-329) Concurrent writes of dependency-reduced-pom.xml adds same exclusion ad infinitum
[
https://issues.apache.org/jira/browse/MSHADE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265656#comment-17265656
]
Bruno Medeiros commented on MSHADE-329:
---
> There is no problem running {{mvn}} in single-thread mode.
I can confirm this bug, same thing happening here if `-T4C` is added to the
build.
I'm attaching a thread dump taken while maven build was stuck, we can seem some
builder threads in `RUNNABLE` state, but writing to files like crazy.
As disabling parallel build seems a very harsh workaround, we are doing this
here:
{code:java}
org.apache.maven.plugins
maven-shade-plugin
3.2.4
false
{code}
I even dare to suggest we disable reduced pom generation by default as most
people using it are just generating a uber jar and don't need a pom for that
(personal opinion).
> Concurrent writes of dependency-reduced-pom.xml adds same exclusion ad
> infinitum
>
>
> Key: MSHADE-329
> URL: https://issues.apache.org/jira/browse/MSHADE-329
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Håkon Hallingstad
>Priority: Major
> Attachments: mshade-329-thread-dump.txt
>
>
> I have a multi-threaded {{mvn install}} that seems to halt but ends up using
> 200% CPU, in about 50% of the invocations. The {{mvn}} command used is:
> {panel}
> mvn -T1C -nsu -Dmaven.source.skip -Dmaven.javadoc.skip -Dmaven.test.skip
> install -rf :MODULE
> {panel}
> Using {{mvnDebug}} I have found out that there are 2 running Java threads,
> each writing {{dependency-reduced-pom.xml}} in two different modules {{A}}
> and {{B}}, respectively. These files seems to become several MB large, before
> they're deleted and then written again, and so forth.
> I have looked into one of the threads, and there is a
> {{rewriteDependencyReducedPomIfWeHaveReduction}} in ShadeMojo with a
> {{loopCounter}} with value 2735, that just keeps increasing. Presumably there
> is something like one dependency-reduced-pom.xml written per iteration.
> From the source code it seems this can only happen if
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/mojo/ShadeMojo.java#L1172
> is hit at least that number of times, meaning the ShadeMojo adds that many
> exclusions, which seems to correspond to hamcrest-core:
> {noformat}
>
>
> junit
> junit
> 4.12
> test
>
>
> hamcrest-core
> org.hamcrest
>
>
> hamcrest-core
> org.hamcrest
>
> ...
> {noformat}
> {panel}
> grep hamcrest-core dependency-reduced-pom.xml | wc -l
> 2735
> {panel}
>
> The same exclusion is added {{loopCounter}} times in {{updateExcludesInDeps}}.
> There is no problem running {{mvn}} in single-thread mode.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHADE-329) Concurrent writes of dependency-reduced-pom.xml adds same exclusion ad infinitum
[
https://issues.apache.org/jira/browse/MSHADE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Medeiros updated MSHADE-329:
--
Attachment: mshade-329-thread-dump.txt
> Concurrent writes of dependency-reduced-pom.xml adds same exclusion ad
> infinitum
>
>
> Key: MSHADE-329
> URL: https://issues.apache.org/jira/browse/MSHADE-329
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Håkon Hallingstad
>Priority: Major
> Attachments: mshade-329-thread-dump.txt
>
>
> I have a multi-threaded {{mvn install}} that seems to halt but ends up using
> 200% CPU, in about 50% of the invocations. The {{mvn}} command used is:
> {panel}
> mvn -T1C -nsu -Dmaven.source.skip -Dmaven.javadoc.skip -Dmaven.test.skip
> install -rf :MODULE
> {panel}
> Using {{mvnDebug}} I have found out that there are 2 running Java threads,
> each writing {{dependency-reduced-pom.xml}} in two different modules {{A}}
> and {{B}}, respectively. These files seems to become several MB large, before
> they're deleted and then written again, and so forth.
> I have looked into one of the threads, and there is a
> {{rewriteDependencyReducedPomIfWeHaveReduction}} in ShadeMojo with a
> {{loopCounter}} with value 2735, that just keeps increasing. Presumably there
> is something like one dependency-reduced-pom.xml written per iteration.
> From the source code it seems this can only happen if
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/mojo/ShadeMojo.java#L1172
> is hit at least that number of times, meaning the ShadeMojo adds that many
> exclusions, which seems to correspond to hamcrest-core:
> {noformat}
>
>
> junit
> junit
> 4.12
> test
>
>
> hamcrest-core
> org.hamcrest
>
>
> hamcrest-core
> org.hamcrest
>
> ...
> {noformat}
> {panel}
> grep hamcrest-core dependency-reduced-pom.xml | wc -l
> 2735
> {panel}
>
> The same exclusion is added {{loopCounter}} times in {{updateExcludesInDeps}}.
> There is no problem running {{mvn}} in single-thread mode.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHADE-329) Concurrent writes of dependency-reduced-pom.xml adds same exclusion ad infinitum
[
https://issues.apache.org/jira/browse/MSHADE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Medeiros updated MSHADE-329:
--
Attachment: (was: mshade-329-stacktrace.txt)
> Concurrent writes of dependency-reduced-pom.xml adds same exclusion ad
> infinitum
>
>
> Key: MSHADE-329
> URL: https://issues.apache.org/jira/browse/MSHADE-329
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Håkon Hallingstad
>Priority: Major
>
> I have a multi-threaded {{mvn install}} that seems to halt but ends up using
> 200% CPU, in about 50% of the invocations. The {{mvn}} command used is:
> {panel}
> mvn -T1C -nsu -Dmaven.source.skip -Dmaven.javadoc.skip -Dmaven.test.skip
> install -rf :MODULE
> {panel}
> Using {{mvnDebug}} I have found out that there are 2 running Java threads,
> each writing {{dependency-reduced-pom.xml}} in two different modules {{A}}
> and {{B}}, respectively. These files seems to become several MB large, before
> they're deleted and then written again, and so forth.
> I have looked into one of the threads, and there is a
> {{rewriteDependencyReducedPomIfWeHaveReduction}} in ShadeMojo with a
> {{loopCounter}} with value 2735, that just keeps increasing. Presumably there
> is something like one dependency-reduced-pom.xml written per iteration.
> From the source code it seems this can only happen if
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/mojo/ShadeMojo.java#L1172
> is hit at least that number of times, meaning the ShadeMojo adds that many
> exclusions, which seems to correspond to hamcrest-core:
> {noformat}
>
>
> junit
> junit
> 4.12
> test
>
>
> hamcrest-core
> org.hamcrest
>
>
> hamcrest-core
> org.hamcrest
>
> ...
> {noformat}
> {panel}
> grep hamcrest-core dependency-reduced-pom.xml | wc -l
> 2735
> {panel}
>
> The same exclusion is added {{loopCounter}} times in {{updateExcludesInDeps}}.
> There is no problem running {{mvn}} in single-thread mode.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHADE-329) Concurrent writes of dependency-reduced-pom.xml adds same exclusion ad infinitum
[
https://issues.apache.org/jira/browse/MSHADE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Medeiros updated MSHADE-329:
--
Attachment: mshade-329-stacktrace.txt
> Concurrent writes of dependency-reduced-pom.xml adds same exclusion ad
> infinitum
>
>
> Key: MSHADE-329
> URL: https://issues.apache.org/jira/browse/MSHADE-329
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Håkon Hallingstad
>Priority: Major
> Attachments: mshade-329-stacktrace.txt
>
>
> I have a multi-threaded {{mvn install}} that seems to halt but ends up using
> 200% CPU, in about 50% of the invocations. The {{mvn}} command used is:
> {panel}
> mvn -T1C -nsu -Dmaven.source.skip -Dmaven.javadoc.skip -Dmaven.test.skip
> install -rf :MODULE
> {panel}
> Using {{mvnDebug}} I have found out that there are 2 running Java threads,
> each writing {{dependency-reduced-pom.xml}} in two different modules {{A}}
> and {{B}}, respectively. These files seems to become several MB large, before
> they're deleted and then written again, and so forth.
> I have looked into one of the threads, and there is a
> {{rewriteDependencyReducedPomIfWeHaveReduction}} in ShadeMojo with a
> {{loopCounter}} with value 2735, that just keeps increasing. Presumably there
> is something like one dependency-reduced-pom.xml written per iteration.
> From the source code it seems this can only happen if
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/mojo/ShadeMojo.java#L1172
> is hit at least that number of times, meaning the ShadeMojo adds that many
> exclusions, which seems to correspond to hamcrest-core:
> {noformat}
>
>
> junit
> junit
> 4.12
> test
>
>
> hamcrest-core
> org.hamcrest
>
>
> hamcrest-core
> org.hamcrest
>
> ...
> {noformat}
> {panel}
> grep hamcrest-core dependency-reduced-pom.xml | wc -l
> 2735
> {panel}
>
> The same exclusion is added {{loopCounter}} times in {{updateExcludesInDeps}}.
> There is no problem running {{mvn}} in single-thread mode.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1765) target/test-classes should not be added to classpath when tests run on modulepath using patch-module
[
https://issues.apache.org/jira/browse/SUREFIRE-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265630#comment-17265630
]
Tibor Digana commented on SUREFIRE-1765:
[~tomdw]
[~poggs]
Maybe the first hint. Please check it out with this command and let me know how
it works. Thx
{{mvn test -Dsurefire.useModulePath=false}}
> target/test-classes should not be added to classpath when tests run on
> modulepath using patch-module
>
>
> Key: SUREFIRE-1765
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1765
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.22.1, 2.22.2
>Reporter: Tom De Wolf
>Priority: Major
> Attachments: reproduce-xxxAnnotation-jdk-bug.zip
>
>
> When running junit tests using the maven-surefire-plugin the
> target/test-classes are added as first entry in the classpath.
> However, when testing a explicit java module with a module-info.java the
> test-classes are already part of the module path using --patch-module. So
> they should not be on the classpath?
> In some scenario's this can give unwanted side-effects, i.e. that the same
> classes are on the modulepath and classpath, possibly with a
> module-info.class in both locations (cfr
> [https://bugs.openjdk.java.net/browse/JDK-8241770).]
> So it seems that it is best that target/test-classes is only added to the
> classpath when it is not put on the module-path.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WAGON-603) Connection reset error from Azure pipelines
[
https://issues.apache.org/jira/browse/WAGON-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265619#comment-17265619
]
Arul Elvis J commented on WAGON-603:
The batch switch is passed along with apache http wire DEBUG level logging.
# Still it runs in non-batch mode ?!
# For debug logs, since system.debug would help ?
> Connection reset error from Azure pipelines
> ---
>
> Key: WAGON-603
> URL: https://issues.apache.org/jira/browse/WAGON-603
> Project: Maven Wagon
> Issue Type: Bug
> Environment: In both Ubuntu and Windows agent specification
>Reporter: Arul Elvis J
>Priority: Blocker
> Fix For: waiting-for-feedback
>
> Attachments: failed_logs-batch-wired.txt,
> failed_logs-batch-wired_latest.txt, logs_143613.zip
>
> Original Estimate: 408h
> Remaining Estimate: 408h
>
> When the pipelines are executed in Azure pipelines, we are facing connection
> reset error. Azure pipelines team claims that connection is closed from Maven
> central repo end. Below is the error message. Have attached the complete log
> zip file for your reference. Can you please prioritize as soon as possible,
> as it is impacting all the pipelines including the production builds ?
>
> {{ }}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-resources-plugin:3.0.2:resources
> (default-resources) on project bata-s-sfdc-deferredpromo: Execution
> default-resources of goal
> org.apache.maven.plugins:maven-resources-plugin:3.0.2:resources failed:
> Plugin org.apache.maven.plugins:maven-resources-plugin:3.0.2 or one of its
> dependencies could not be resolved: Failed to collect dependencies at
> org.apache.maven.plugins:maven-resources-plugin:jar:3.0.2 ->
> org.apache.maven:maven-plugin-api:jar:3.0 ->
> org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2 ->
> org.codehaus.plexus:plexus-component-annotations:jar:1.6: Failed to read
> artifact descriptor for
> org.codehaus.plexus:plexus-component-annotations:jar:1.6: Could not transfer
> artifact org.codehaus.plexus:plexus-component-annotations:pom:1.6 from/to
> central ([https://repo.maven.apache.org/maven2)]: Connection reset -> [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]
> The process
> 'C:\ProgramData\chocolatey\lib\maven\apache-maven-3.6.3\bin\mvn.cmd' failed
> with exit code 1
> Could not retrieve code analysis results - Maven run failed.
> {{##[error]Build failed. }}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-3485) unable to override wagons that are bundled with a different version via extensions
[ https://issues.apache.org/jira/browse/MNG-3485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265591#comment-17265591 ] Hudson commented on MNG-3485: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6012-Missing-Profile-At-End #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/15/ > unable to override wagons that are bundled with a different version via > extensions > -- > > Key: MNG-3485 > URL: https://issues.apache.org/jira/browse/MNG-3485 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.8 >Reporter: Brett Porter >Assignee: Brett Porter >Priority: Major > Fix For: 2.0.9 > > > currently, any wagons distributed with the core cannot be replaced by a > different version via extensions. This was intended, but two issues seem to > have prevented it. > NOTE: the provider-api cannot be replaced, so must be forwards compatible > even if the version is changed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6972) Allow access to org.apache.maven.graph
[
https://issues.apache.org/jira/browse/MNG-6972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265603#comment-17265603
]
Hudson commented on MNG-6972:
-
Build unstable in Jenkins: Maven » Maven TLP » maven »
MNG-6012-Missing-Profile-At-End #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/15/
> Allow access to org.apache.maven.graph
> --
>
> Key: MNG-6972
> URL: https://issues.apache.org/jira/browse/MNG-6972
> Project: Maven
> Issue Type: Improvement
> Components: Class Loading, Plugin API
>Affects Versions: 3.6.3
>Reporter: Michael Kroll
>Assignee: Michael Osipov
>Priority: Major
> Labels: easyfix, pull-request-available
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> Hi
> maven doesn't export org.apache.maven.graph package in
> maven-core/src/main/resources/META-INF/maven/extension.xml so the
> GraphBuilder is not usable in extensions.
> {code:java}
> // leads to java.lang.NoClassDefFoundError:
> Lorg/apache/maven/graph/GraphBuilder;
> @Requirement( hint = GraphBuilder.HINT )
> private GraphBuilder graphBuilder;
> {code}
> Background: if one build extension adds dependencies and another build
> extension uses {{session.getProjectDependencyGraph()}}, then the dependency
> graph is out of date. This is because the graph is only rebuilt after
> executing _all_ extensions. One solution to this would be to update the
> {{MavenSession}} and setting the new dependency graph in the first extension,
> but for this we need access to the {{GraphBuilder}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6566) @Execute should not re-execute goals
[ https://issues.apache.org/jira/browse/MNG-6566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265594#comment-17265594 ] Hudson commented on MNG-6566: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6012-Missing-Profile-At-End #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/15/ > @Execute should not re-execute goals > > > Key: MNG-6566 > URL: https://issues.apache.org/jira/browse/MNG-6566 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Robert Scholte >Assignee: Martin Kanters >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > We're getting quite a lot of requests for -no-fork goals, because now > often plugins are executed twice because of retriggering plugins due to the > @Execute -annotation. > Maven should be able to discover if there's a need to re-execute those > goals/lifecycles. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7041) Update @since, version ranges and other version related strings
[ https://issues.apache.org/jira/browse/MNG-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265592#comment-17265592 ] Hudson commented on MNG-7041: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6012-Missing-Profile-At-End #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/15/ > Update @since, version ranges and other version related strings > --- > > Key: MNG-7041 > URL: https://issues.apache.org/jira/browse/MNG-7041 > Project: Maven > Issue Type: Task > Components: core, Integration Tests >Reporter: Robert Scholte >Assignee: Michael Osipov >Priority: Minor > Fix For: 4.0.0, 4.0.0-alpha-1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
[
https://issues.apache.org/jira/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265601#comment-17265601
]
Hudson commented on MNG-5639:
-
Build unstable in Jenkins: Maven » Maven TLP » maven »
MNG-6012-Missing-Profile-At-End #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/15/
> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> --
>
> Key: MNG-5639
> URL: https://issues.apache.org/jira/browse/MNG-5639
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.2.1
>Reporter: Mark Ingram
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.2.2
>
> Attachments: pom.xml
>
>
> Running mvn help:effective-pom on the attached POM:
> {noformat}[ERROR] The project
> com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
> (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not transfer artifact
> org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to
> spring-milestones (${spring.url}): No connector available to access
> repository spring-milestones (${spring.url}) of type default using the
> available factories WagonRepositoryConnectorFactory @ line 20, column 25 ->
> Help 2]{noformat}
> mvn help:effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution, the full project POM
> model has successfully been resolved. So the correct value for the property
> is known and could in theory be substituted into the repository URL before
> the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it
> includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the
> actual use case - several development streams are setup with individual
> sandboxed Nexus repository holding specific version of several shared
> components. The repository configuration uses the pattern
> $\{nexus.baseurl}/content/groups/$\{stream.name} with the properties set in
> settings.xml file.
> One workaround would be to create profiles for every work stream that
> explicitly list the full repository URL, even then the above feature would be
> nice to allow the $\{nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265593#comment-17265593 ] Hudson commented on MNG-5728: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6012-Missing-Profile-At-End #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0, 4.0.0-alpha-1 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265602#comment-17265602
]
Hudson commented on MNG-5760:
-
Build unstable in Jenkins: Maven » Maven TLP » maven »
MNG-6012-Missing-Profile-At-End #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/15/
> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 4.0.0, 4.0.0-alpha-1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-3259) Regression: Maven drops dependencies in multi-module build
[ https://issues.apache.org/jira/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265597#comment-17265597 ] Hudson commented on MNG-3259: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6012-Missing-Profile-At-End #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/15/ > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: https://issues.apache.org/jira/browse/MNG-3259 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7, 2.0.8, 3.0-alpha-1 >Reporter: Joerg Schaible >Assignee: John Dennis Casey >Priority: Blocker > Fix For: 2.0.9 > > Attachments: MNG-3259-2.zip, MNG-3259.zip > > Time Spent: 5h > Remaining Estimate: 0h > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-4660) Use of --resume-from in multi-module project fails with missing inter-module dependencies
[ https://issues.apache.org/jira/browse/MNG-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265598#comment-17265598 ] Hudson commented on MNG-4660: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6012-Missing-Profile-At-End #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/15/ > Use of --resume-from in multi-module project fails with missing inter-module > dependencies > - > > Key: MNG-4660 > URL: https://issues.apache.org/jira/browse/MNG-4660 > Project: Maven > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 2.2.1, 3.0-beta-1 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) > Java version: 1.6.0_17 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x" version: "10.6.3" arch: "x86_64" Family: "mac" >Reporter: Brian Ferris >Assignee: Robert Scholte >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > Attachments: modules-parent.tar.gz > > Time Spent: 1h 20m > Remaining Estimate: 0h > > In a simple multi-module project with a parent pom "modules-parent", two sub > modules "module-a" and "module-b", where B depends on A, I've not been able > to get the Maven "--resume-from" feature to work. > Specifically, I expect: > > mvn --resume-from module-b test > would resume execution of the "test" goal in "module-b". Instead it fails > with a missing artifact error: > > [INFO] Failed to resolve artifact. > > > > Missing: > > -- > > 1) org.test:module-a:jar:0.0.1-SNAPSHOT > Why isn't Maven resolving the within-multi-module dependency? I've attached > a simple project that reproduces the problem with Maven 2.2.1 and Maven > 3.0-beta-1. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265596#comment-17265596 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6012-Missing-Profile-At-End #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/15/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-4338) Unexepceted "Unknown packaging: bundle" error for plugins with custom lifecycle mapping that defines optional mojos
[
https://issues.apache.org/jira/browse/MNG-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265590#comment-17265590
]
Hudson commented on MNG-4338:
-
Build unstable in Jenkins: Maven » Maven TLP » maven »
MNG-6012-Missing-Profile-At-End #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/15/
> Unexepceted "Unknown packaging: bundle" error for plugins with custom
> lifecycle mapping that defines optional mojos
> ---
>
> Key: MNG-4338
> URL: https://issues.apache.org/jira/browse/MNG-4338
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0
>Reporter: Igor Fedorenko
>Assignee: Benjamin Bentmann
>Priority: Major
> Fix For: 3.0-alpha-3
>
>
> This was originally reported against m2e as
> https://issues.sonatype.org/browse/MNGECLIPSE-1636. Attached sample project
> builds using maven 2.2.1 but fails with using 3.0 snapshot (svn rev 811372)
> {noformat}
> igor@desktop:/tmp/bundle-test$
> /workspaces/tycho-dev/maven/apache-maven/target/apache-maven-3.0-SNAPSHOT/bin/mvn
> -X clean package
> Apache Maven 3.0-SNAPSHOT (r811383; 2009-09-04 12:18:34-0400)
> Java version: 1.6.0_13
> Java home: /opt/jdk1.6.0_13/jre
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "linux" version: "2.6.28-15-generic" arch: "amd64" Family: "unix"
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [DEBUG] Created new class realm project>org.example:bundle-test:1.0.0-SNAPSHOT
> [DEBUG] Included: org.ops4j:maven-pax-plugin:maven-plugin:1.4
> [DEBUG] Excluded: org.apache.maven:maven-project:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-settings:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-model:jar:2.0.7
> [DEBUG] Included: org.codehaus.plexus:plexus-utils:jar:1.4.7
> [DEBUG] Excluded:
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1
> [DEBUG] Included: junit:junit:jar:3.8.1
> [DEBUG] Excluded: classworlds:classworlds:jar:1.1-alpha-2
> [DEBUG] Excluded: org.apache.maven:maven-profile:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-artifact-manager:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-repository-metadata:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-artifact:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven.wagon:wagon-provider-api:jar:1.0-beta-2
> [DEBUG] Excluded: org.apache.maven:maven-plugin-registry:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-plugin-api:jar:2.0.7
> [DEBUG] Included:
> org.apache.maven.archetype:maven-archetype-core:jar:1.0-alpha-7
> [DEBUG] Included: org.codehaus.plexus:plexus-velocity:jar:1.1.2
> [DEBUG] Included: plexus:plexus-utils:jar:1.0.2
> [DEBUG] Included: commons-collections:commons-collections:jar:2.0
> [DEBUG] Included: commons-logging:commons-logging-api:jar:1.0.4
> [DEBUG] Included: velocity:velocity:jar:1.4
> [DEBUG] Included: velocity:velocity-dep:jar:1.4
> [DEBUG] Included: dom4j:dom4j:jar:1.6.1
> [DEBUG] Included: xml-apis:xml-apis:jar:1.0.b2
> [DEBUG] Included: org.apache.maven.shared:maven-downloader:jar:1.0
> [DEBUG] Included:
> org.apache.maven.plugins:maven-compiler-plugin:maven-plugin:2.0.2
> [DEBUG] Included: org.codehaus.plexus:plexus-compiler-api:jar:1.5.3
> [DEBUG] Included: org.codehaus.plexus:plexus-compiler-manager:jar:1.5.3
> [DEBUG] Included: org.codehaus.plexus:plexus-compiler-javac:jar:1.5.3
> [DEBUG] Included:
> org.apache.maven.plugins:maven-eclipse-plugin:maven-plugin:2.5.1
> [DEBUG] Included: org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7
> [DEBUG] Included:
> org.codehaus.plexus:plexus-interactivity-jline:jar:1.0-alpha-5
> [DEBUG] Included: jline:jline:jar:0.9.1
> [DEBUG] Included:
> org.codehaus.plexus:plexus-interactivity-api:jar:1.0-alpha-5
> [DEBUG] Included: org.apache.maven:maven-archiver:jar:2.2
> [DEBUG] Included: org.codehaus.plexus:plexus-resources:jar:1.0-alpha-4
> [DEBUG] Included: biz.aQute:bndlib:jar:0.0.255
> [DEBUG] Included: org.apache.maven.shared:maven-osgi:jar:0.2.0
> [DEBUG] Included: org.eclipse.core:resources:jar:3.3.0-v20070604
> [DEBUG] Included: org.apache.maven.shared:file-management:jar:1.2
> [DEBUG] Included: org.apache.maven.shared:maven-shared-io:jar:1.1
> [DEBUG] Failed to lookup a member of active collection with role:
> org.apache.maven.lifecycle.mapping.LifecycleMapping and role-hint: bundle
> -
> this realm =project>org.example:bundle-test:1.0.0-SNAPSHOT
> this strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> urls[0] =
>
[jira] [Commented] (MNG-3203) maven should execute compiler:compile and :test-compile in separate executions, to allow separate configuration
[ https://issues.apache.org/jira/browse/MNG-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265588#comment-17265588 ] Hudson commented on MNG-3203: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6012-Missing-Profile-At-End #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/15/ > maven should execute compiler:compile and :test-compile in separate > executions, to allow separate configuration > --- > > Key: MNG-3203 > URL: https://issues.apache.org/jira/browse/MNG-3203 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: John Dennis Casey >Assignee: John Dennis Casey >Priority: Major > Fix For: 2.2.0 > > > Currently, it's impossible to configure the two default maven-compiler-plugin > mojos in the jar lifecycle (:compile and :test-compile) separately without > the configuration for one affecting both. This is because they are both > executed in the same (default) execution. We should be assigning these to > different execution id's, to allow separate configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5771) improved user-configurable core extensions mechanism
[
https://issues.apache.org/jira/browse/MNG-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265589#comment-17265589
]
Hudson commented on MNG-5771:
-
Build unstable in Jenkins: Maven » Maven TLP » maven »
MNG-6012-Missing-Profile-At-End #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/15/
> improved user-configurable core extensions mechanism
>
>
> Key: MNG-5771
> URL: https://issues.apache.org/jira/browse/MNG-5771
> Project: Maven
> Issue Type: Improvement
> Components: Class Loading
>Reporter: Igor Fedorenko
>Assignee: igorfie
>Priority: Major
> Fix For: 3.3.1
>
>
> As of version 3.2.5 maven provides two mechanisms to contribute additional
> components to maven core runtime. It is possible to add component jars to
> {{$M2_HOME/lib/ext directory}}. It is also possible to specify component jars
> using {{-Dmaven.ext.class.path}} command line parameter. Neither of the
> mechanisms is user friendly. In both cases, the user is expected to manually
> locate and download all required jar file. In both cases, this has to be done
> on all systems where the extensions are needed. In both cases, all extra jars
> are loaded into single classloader so all extensions must agree of the same
> set of dependencies.
> This jira is to track changes needed to make it possible to configure core
> extensions in terms of groupId/artifactId/version and share set of required
> extensions across multiple systems.
> More specifically,
> * introduce new {{$\{maven.projectBasedir\}/.mvn/extensions.xml}} descriptor
> to specify list of extensions. Initially, the descriptor will only allow
> specification of extension groupId/artifactId/version, but can be extended to
> support dependency includes/excludes mechanism and configuration parameters
> later
> {code:xml}
>
>
>
> ...
> ...
> ...
>
> ...
> ...
>
> {code}
> * change maven to read and load core extensions in separate class realms as
> part of plexus container setup.
> * provide mechanism for extensions to declare exported artifacts and packages
> using {{META-INF/maven/extension.xml}} descriptor.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6957) Versionless reactor dependencies/parent should work even if modules are aggregated in reverse order
[
https://issues.apache.org/jira/browse/MNG-6957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265595#comment-17265595
]
Hudson commented on MNG-6957:
-
Build unstable in Jenkins: Maven » Maven TLP » maven »
MNG-6012-Missing-Profile-At-End #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/15/
> Versionless reactor dependencies/parent should work even if modules are
> aggregated in reverse order
> ---
>
> Key: MNG-6957
> URL: https://issues.apache.org/jira/browse/MNG-6957
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0
>Reporter: Herve Boutemy
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> building Maven Artifact buildconsumer branch
> https://github.com/apache/maven-archetype/tree/buildconsumer
> {noformat}$ mvn verify -Drevlist=test
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'dependencies.dependency.version' for
> org.apache.maven.archetype:archetype-packaging:jar is missing. @
> org.apache.maven.plugins:maven-archetype-plugin:[unknown-version],
> /home/herve/projets/maven/sources/plugins/tools/archetype/maven-archetype-plugin/pom.xml,
> line 81, column 17
> @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project
> org.apache.maven.plugins:maven-archetype-plugin:3.2.0-SNAPSHOT
> (/home/herve/projets/maven/sources/plugins/tools/archetype/maven-archetype-plugin/pom.xml)
> has 1 error
> [ERROR] 'dependencies.dependency.version' for
> org.apache.maven.archetype:archetype-packaging:jar is missing. @
> org.apache.maven.plugins:maven-archetype-plugin:[unknown-version],
> /home/herve/projets/maven/sources/plugins/tools/archetype/maven-archetype-plugin/pom.xml,
> line 81, column 17{noformat}
> This is caused by the order of the modules is the reactor:
> {code:xml}
>
> archetype-models
> archetype-common
> maven-archetype-plugin
> archetype-packaging
>
> {code}
> The version is being resolved before {{archetype-packaging}} is available in
> the context. This should become lazy resolution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6754) Set the same timestamp in multi module builds
[ https://issues.apache.org/jira/browse/MNG-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265587#comment-17265587 ] Hudson commented on MNG-6754: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6012-Missing-Profile-At-End #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/15/ > Set the same timestamp in multi module builds > - > > Key: MNG-6754 > URL: https://issues.apache.org/jira/browse/MNG-6754 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, Deployment >Affects Versions: 3.6.3 >Reporter: Michael Angstadt >Assignee: Michael Osipov >Priority: Minor > Fix For: 4.0.0, 4.0.0-alpha-1 > > > When multi module snapshots are built using Maven, the version timestamp may > be different for each module. This makes it difficult to quickly reference a > historical snapshot of a multi module project, which is something we might do > when determining when a bug was introduced. > [This Stack Overflow question|https://stackoverflow.com/q/45629816/2048802] > provides a good example of the problem. [The accepted > answer|https://stackoverflow.com/a/45715820/2048802] seems like a reasonable > solution, but does not appear to work. [Looking at the > code|https://github.com/apache/maven/blob/d9a0eee7fe2e2b1d77e59cf5bc772e758d29e47d/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java#L85], > there does not appear to be a way to override the timestamp. > Please add a way to use a consistent timestamp for all modules in a build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7022) Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos backward compat code
[
https://issues.apache.org/jira/browse/MNG-7022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265599#comment-17265599
]
Hudson commented on MNG-7022:
-
Build unstable in Jenkins: Maven » Maven TLP » maven »
MNG-6012-Missing-Profile-At-End #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/15/
> Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos backward compat code
>
>
> Key: MNG-7022
> URL: https://issues.apache.org/jira/browse/MNG-7022
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> The handing of optional mojos was dropped long ago in
> ac8db28f3b8cd64192c3d038ee5557354ffb7a30, but the injection remained intact
> for backward compat reasons on legacy {{components.xml}}. Newer setups are
> encouraged to move to
> [{{lifecycle.xml}}|https://maven.apache.org/ref/3.6.3/maven-plugin-api/lifecycle-mappings.html].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7046) Revert MNG-5639 and make repo config static only
[ https://issues.apache.org/jira/browse/MNG-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265600#comment-17265600 ] Hudson commented on MNG-7046: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6012-Missing-Profile-At-End #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/15/ > Revert MNG-5639 and make repo config static only > > > Key: MNG-7046 > URL: https://issues.apache.org/jira/browse/MNG-7046 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories, Dependencies >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > As discussed in MNG-5639 repositories should always be known upfront, they > have to be static to avoid chicken and egg situations, a project should not > influence settings. It should be the way around. > In subsequent ticket it will be verified that repo configuration does not > contain any expression: > https://github.com/apache/maven/commit/d411c3fa98832e7d86d901fe86ff63ba907cf868#commitcomment-44782281. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6551) Packaging 'jar' binding plugin upgrades
[ https://issues.apache.org/jira/browse/MNG-6551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265586#comment-17265586 ] Hudson commented on MNG-6551: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6012-Missing-Profile-At-End #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/15/ > Packaging 'jar' binding plugin upgrades > --- > > Key: MNG-6551 > URL: https://issues.apache.org/jira/browse/MNG-6551 > Project: Maven > Issue Type: Sub-task > Components: core, Dependencies >Affects Versions: 3.5.0, 3.6.0 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This affects: > ||groupId||artifactId||[previous > version|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_jar_packaging]||target > version|| > |org.apache.maven.plugins|maven-resources-plugin|2.6|3.2.0| > |org.apache.maven.plugins|maven-compiler-plugin|3.1|3.8.1| > |org.apache.maven.plugins|maven-surefire-plugin|2.12.4|3.0.0-M5| > |org.apache.maven.plugins|maven-jar-plugin|2.4|3.2.0| > |org.apache.maven.plugins|maven-install-plugin|2.4|3.0.0-M1| > |org.apache.maven.plugins|maven-deploy-plugin|2.7|3.0.0-M1| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6972) Allow access to org.apache.maven.graph
[
https://issues.apache.org/jira/browse/MNG-6972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265584#comment-17265584
]
Hudson commented on MNG-6972:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/15/
> Allow access to org.apache.maven.graph
> --
>
> Key: MNG-6972
> URL: https://issues.apache.org/jira/browse/MNG-6972
> Project: Maven
> Issue Type: Improvement
> Components: Class Loading, Plugin API
>Affects Versions: 3.6.3
>Reporter: Michael Kroll
>Assignee: Michael Osipov
>Priority: Major
> Labels: easyfix, pull-request-available
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> Hi
> maven doesn't export org.apache.maven.graph package in
> maven-core/src/main/resources/META-INF/maven/extension.xml so the
> GraphBuilder is not usable in extensions.
> {code:java}
> // leads to java.lang.NoClassDefFoundError:
> Lorg/apache/maven/graph/GraphBuilder;
> @Requirement( hint = GraphBuilder.HINT )
> private GraphBuilder graphBuilder;
> {code}
> Background: if one build extension adds dependencies and another build
> extension uses {{session.getProjectDependencyGraph()}}, then the dependency
> graph is out of date. This is because the graph is only rebuilt after
> executing _all_ extensions. One solution to this would be to update the
> {{MavenSession}} and setting the new dependency graph in the first extension,
> but for this we need access to the {{GraphBuilder}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265577#comment-17265577 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/15/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6566) @Execute should not re-execute goals
[ https://issues.apache.org/jira/browse/MNG-6566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265575#comment-17265575 ] Hudson commented on MNG-6566: - Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/15/ > @Execute should not re-execute goals > > > Key: MNG-6566 > URL: https://issues.apache.org/jira/browse/MNG-6566 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Robert Scholte >Assignee: Martin Kanters >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > We're getting quite a lot of requests for -no-fork goals, because now > often plugins are executed twice because of retriggering plugins due to the > @Execute -annotation. > Maven should be able to discover if there's a need to re-execute those > goals/lifecycles. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6551) Packaging 'jar' binding plugin upgrades
[ https://issues.apache.org/jira/browse/MNG-6551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265567#comment-17265567 ] Hudson commented on MNG-6551: - Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/15/ > Packaging 'jar' binding plugin upgrades > --- > > Key: MNG-6551 > URL: https://issues.apache.org/jira/browse/MNG-6551 > Project: Maven > Issue Type: Sub-task > Components: core, Dependencies >Affects Versions: 3.5.0, 3.6.0 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This affects: > ||groupId||artifactId||[previous > version|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_jar_packaging]||target > version|| > |org.apache.maven.plugins|maven-resources-plugin|2.6|3.2.0| > |org.apache.maven.plugins|maven-compiler-plugin|3.1|3.8.1| > |org.apache.maven.plugins|maven-surefire-plugin|2.12.4|3.0.0-M5| > |org.apache.maven.plugins|maven-jar-plugin|2.4|3.2.0| > |org.apache.maven.plugins|maven-install-plugin|2.4|3.0.0-M1| > |org.apache.maven.plugins|maven-deploy-plugin|2.7|3.0.0-M1| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265574#comment-17265574 ] Hudson commented on MNG-5728: - Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0, 4.0.0-alpha-1 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7041) Update @since, version ranges and other version related strings
[ https://issues.apache.org/jira/browse/MNG-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265573#comment-17265573 ] Hudson commented on MNG-7041: - Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/15/ > Update @since, version ranges and other version related strings > --- > > Key: MNG-7041 > URL: https://issues.apache.org/jira/browse/MNG-7041 > Project: Maven > Issue Type: Task > Components: core, Integration Tests >Reporter: Robert Scholte >Assignee: Michael Osipov >Priority: Minor > Fix For: 4.0.0, 4.0.0-alpha-1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
[
https://issues.apache.org/jira/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265582#comment-17265582
]
Hudson commented on MNG-5639:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/15/
> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> --
>
> Key: MNG-5639
> URL: https://issues.apache.org/jira/browse/MNG-5639
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.2.1
>Reporter: Mark Ingram
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.2.2
>
> Attachments: pom.xml
>
>
> Running mvn help:effective-pom on the attached POM:
> {noformat}[ERROR] The project
> com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
> (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not transfer artifact
> org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to
> spring-milestones (${spring.url}): No connector available to access
> repository spring-milestones (${spring.url}) of type default using the
> available factories WagonRepositoryConnectorFactory @ line 20, column 25 ->
> Help 2]{noformat}
> mvn help:effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution, the full project POM
> model has successfully been resolved. So the correct value for the property
> is known and could in theory be substituted into the repository URL before
> the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it
> includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the
> actual use case - several development streams are setup with individual
> sandboxed Nexus repository holding specific version of several shared
> components. The repository configuration uses the pattern
> $\{nexus.baseurl}/content/groups/$\{stream.name} with the properties set in
> settings.xml file.
> One workaround would be to create profiles for every work stream that
> explicitly list the full repository URL, even then the above feature would be
> nice to allow the $\{nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265583#comment-17265583
]
Hudson commented on MNG-5760:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/15/
> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 4.0.0, 4.0.0-alpha-1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-4660) Use of --resume-from in multi-module project fails with missing inter-module dependencies
[ https://issues.apache.org/jira/browse/MNG-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265579#comment-17265579 ] Hudson commented on MNG-4660: - Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/15/ > Use of --resume-from in multi-module project fails with missing inter-module > dependencies > - > > Key: MNG-4660 > URL: https://issues.apache.org/jira/browse/MNG-4660 > Project: Maven > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 2.2.1, 3.0-beta-1 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) > Java version: 1.6.0_17 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x" version: "10.6.3" arch: "x86_64" Family: "mac" >Reporter: Brian Ferris >Assignee: Robert Scholte >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > Attachments: modules-parent.tar.gz > > Time Spent: 1h 20m > Remaining Estimate: 0h > > In a simple multi-module project with a parent pom "modules-parent", two sub > modules "module-a" and "module-b", where B depends on A, I've not been able > to get the Maven "--resume-from" feature to work. > Specifically, I expect: > > mvn --resume-from module-b test > would resume execution of the "test" goal in "module-b". Instead it fails > with a missing artifact error: > > [INFO] Failed to resolve artifact. > > > > Missing: > > -- > > 1) org.test:module-a:jar:0.0.1-SNAPSHOT > Why isn't Maven resolving the within-multi-module dependency? I've attached > a simple project that reproduces the problem with Maven 2.2.1 and Maven > 3.0-beta-1. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-3259) Regression: Maven drops dependencies in multi-module build
[ https://issues.apache.org/jira/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265578#comment-17265578 ] Hudson commented on MNG-3259: - Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/15/ > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: https://issues.apache.org/jira/browse/MNG-3259 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7, 2.0.8, 3.0-alpha-1 >Reporter: Joerg Schaible >Assignee: John Dennis Casey >Priority: Blocker > Fix For: 2.0.9 > > Attachments: MNG-3259-2.zip, MNG-3259.zip > > Time Spent: 5h > Remaining Estimate: 0h > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7046) Revert MNG-5639 and make repo config static only
[ https://issues.apache.org/jira/browse/MNG-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265581#comment-17265581 ] Hudson commented on MNG-7046: - Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/15/ > Revert MNG-5639 and make repo config static only > > > Key: MNG-7046 > URL: https://issues.apache.org/jira/browse/MNG-7046 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories, Dependencies >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > As discussed in MNG-5639 repositories should always be known upfront, they > have to be static to avoid chicken and egg situations, a project should not > influence settings. It should be the way around. > In subsequent ticket it will be verified that repo configuration does not > contain any expression: > https://github.com/apache/maven/commit/d411c3fa98832e7d86d901fe86ff63ba907cf868#commitcomment-44782281. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-4338) Unexepceted "Unknown packaging: bundle" error for plugins with custom lifecycle mapping that defines optional mojos
[
https://issues.apache.org/jira/browse/MNG-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265571#comment-17265571
]
Hudson commented on MNG-4338:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/15/
> Unexepceted "Unknown packaging: bundle" error for plugins with custom
> lifecycle mapping that defines optional mojos
> ---
>
> Key: MNG-4338
> URL: https://issues.apache.org/jira/browse/MNG-4338
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0
>Reporter: Igor Fedorenko
>Assignee: Benjamin Bentmann
>Priority: Major
> Fix For: 3.0-alpha-3
>
>
> This was originally reported against m2e as
> https://issues.sonatype.org/browse/MNGECLIPSE-1636. Attached sample project
> builds using maven 2.2.1 but fails with using 3.0 snapshot (svn rev 811372)
> {noformat}
> igor@desktop:/tmp/bundle-test$
> /workspaces/tycho-dev/maven/apache-maven/target/apache-maven-3.0-SNAPSHOT/bin/mvn
> -X clean package
> Apache Maven 3.0-SNAPSHOT (r811383; 2009-09-04 12:18:34-0400)
> Java version: 1.6.0_13
> Java home: /opt/jdk1.6.0_13/jre
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "linux" version: "2.6.28-15-generic" arch: "amd64" Family: "unix"
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [DEBUG] Created new class realm project>org.example:bundle-test:1.0.0-SNAPSHOT
> [DEBUG] Included: org.ops4j:maven-pax-plugin:maven-plugin:1.4
> [DEBUG] Excluded: org.apache.maven:maven-project:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-settings:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-model:jar:2.0.7
> [DEBUG] Included: org.codehaus.plexus:plexus-utils:jar:1.4.7
> [DEBUG] Excluded:
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1
> [DEBUG] Included: junit:junit:jar:3.8.1
> [DEBUG] Excluded: classworlds:classworlds:jar:1.1-alpha-2
> [DEBUG] Excluded: org.apache.maven:maven-profile:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-artifact-manager:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-repository-metadata:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-artifact:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven.wagon:wagon-provider-api:jar:1.0-beta-2
> [DEBUG] Excluded: org.apache.maven:maven-plugin-registry:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-plugin-api:jar:2.0.7
> [DEBUG] Included:
> org.apache.maven.archetype:maven-archetype-core:jar:1.0-alpha-7
> [DEBUG] Included: org.codehaus.plexus:plexus-velocity:jar:1.1.2
> [DEBUG] Included: plexus:plexus-utils:jar:1.0.2
> [DEBUG] Included: commons-collections:commons-collections:jar:2.0
> [DEBUG] Included: commons-logging:commons-logging-api:jar:1.0.4
> [DEBUG] Included: velocity:velocity:jar:1.4
> [DEBUG] Included: velocity:velocity-dep:jar:1.4
> [DEBUG] Included: dom4j:dom4j:jar:1.6.1
> [DEBUG] Included: xml-apis:xml-apis:jar:1.0.b2
> [DEBUG] Included: org.apache.maven.shared:maven-downloader:jar:1.0
> [DEBUG] Included:
> org.apache.maven.plugins:maven-compiler-plugin:maven-plugin:2.0.2
> [DEBUG] Included: org.codehaus.plexus:plexus-compiler-api:jar:1.5.3
> [DEBUG] Included: org.codehaus.plexus:plexus-compiler-manager:jar:1.5.3
> [DEBUG] Included: org.codehaus.plexus:plexus-compiler-javac:jar:1.5.3
> [DEBUG] Included:
> org.apache.maven.plugins:maven-eclipse-plugin:maven-plugin:2.5.1
> [DEBUG] Included: org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7
> [DEBUG] Included:
> org.codehaus.plexus:plexus-interactivity-jline:jar:1.0-alpha-5
> [DEBUG] Included: jline:jline:jar:0.9.1
> [DEBUG] Included:
> org.codehaus.plexus:plexus-interactivity-api:jar:1.0-alpha-5
> [DEBUG] Included: org.apache.maven:maven-archiver:jar:2.2
> [DEBUG] Included: org.codehaus.plexus:plexus-resources:jar:1.0-alpha-4
> [DEBUG] Included: biz.aQute:bndlib:jar:0.0.255
> [DEBUG] Included: org.apache.maven.shared:maven-osgi:jar:0.2.0
> [DEBUG] Included: org.eclipse.core:resources:jar:3.3.0-v20070604
> [DEBUG] Included: org.apache.maven.shared:file-management:jar:1.2
> [DEBUG] Included: org.apache.maven.shared:maven-shared-io:jar:1.1
> [DEBUG] Failed to lookup a member of active collection with role:
> org.apache.maven.lifecycle.mapping.LifecycleMapping and role-hint: bundle
> -
> this realm =project>org.example:bundle-test:1.0.0-SNAPSHOT
> this strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> urls[0] =
> file:/home/igor/.m2/repository/org/ops4j/maven-pax-plugin/1.4/maven-pax-plugin-1.4.jar
[jira] [Commented] (MNG-7022) Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos backward compat code
[
https://issues.apache.org/jira/browse/MNG-7022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265580#comment-17265580
]
Hudson commented on MNG-7022:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/15/
> Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos backward compat code
>
>
> Key: MNG-7022
> URL: https://issues.apache.org/jira/browse/MNG-7022
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> The handing of optional mojos was dropped long ago in
> ac8db28f3b8cd64192c3d038ee5557354ffb7a30, but the injection remained intact
> for backward compat reasons on legacy {{components.xml}}. Newer setups are
> encouraged to move to
> [{{lifecycle.xml}}|https://maven.apache.org/ref/3.6.3/maven-plugin-api/lifecycle-mappings.html].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6754) Set the same timestamp in multi module builds
[ https://issues.apache.org/jira/browse/MNG-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265568#comment-17265568 ] Hudson commented on MNG-6754: - Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/15/ > Set the same timestamp in multi module builds > - > > Key: MNG-6754 > URL: https://issues.apache.org/jira/browse/MNG-6754 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, Deployment >Affects Versions: 3.6.3 >Reporter: Michael Angstadt >Assignee: Michael Osipov >Priority: Minor > Fix For: 4.0.0, 4.0.0-alpha-1 > > > When multi module snapshots are built using Maven, the version timestamp may > be different for each module. This makes it difficult to quickly reference a > historical snapshot of a multi module project, which is something we might do > when determining when a bug was introduced. > [This Stack Overflow question|https://stackoverflow.com/q/45629816/2048802] > provides a good example of the problem. [The accepted > answer|https://stackoverflow.com/a/45715820/2048802] seems like a reasonable > solution, but does not appear to work. [Looking at the > code|https://github.com/apache/maven/blob/d9a0eee7fe2e2b1d77e59cf5bc772e758d29e47d/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java#L85], > there does not appear to be a way to override the timestamp. > Please add a way to use a consistent timestamp for all modules in a build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-3485) unable to override wagons that are bundled with a different version via extensions
[ https://issues.apache.org/jira/browse/MNG-3485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265572#comment-17265572 ] Hudson commented on MNG-3485: - Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/15/ > unable to override wagons that are bundled with a different version via > extensions > -- > > Key: MNG-3485 > URL: https://issues.apache.org/jira/browse/MNG-3485 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.8 >Reporter: Brett Porter >Assignee: Brett Porter >Priority: Major > Fix For: 2.0.9 > > > currently, any wagons distributed with the core cannot be replaced by a > different version via extensions. This was intended, but two issues seem to > have prevented it. > NOTE: the provider-api cannot be replaced, so must be forwards compatible > even if the version is changed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5771) improved user-configurable core extensions mechanism
[
https://issues.apache.org/jira/browse/MNG-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265570#comment-17265570
]
Hudson commented on MNG-5771:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/15/
> improved user-configurable core extensions mechanism
>
>
> Key: MNG-5771
> URL: https://issues.apache.org/jira/browse/MNG-5771
> Project: Maven
> Issue Type: Improvement
> Components: Class Loading
>Reporter: Igor Fedorenko
>Assignee: igorfie
>Priority: Major
> Fix For: 3.3.1
>
>
> As of version 3.2.5 maven provides two mechanisms to contribute additional
> components to maven core runtime. It is possible to add component jars to
> {{$M2_HOME/lib/ext directory}}. It is also possible to specify component jars
> using {{-Dmaven.ext.class.path}} command line parameter. Neither of the
> mechanisms is user friendly. In both cases, the user is expected to manually
> locate and download all required jar file. In both cases, this has to be done
> on all systems where the extensions are needed. In both cases, all extra jars
> are loaded into single classloader so all extensions must agree of the same
> set of dependencies.
> This jira is to track changes needed to make it possible to configure core
> extensions in terms of groupId/artifactId/version and share set of required
> extensions across multiple systems.
> More specifically,
> * introduce new {{$\{maven.projectBasedir\}/.mvn/extensions.xml}} descriptor
> to specify list of extensions. Initially, the descriptor will only allow
> specification of extension groupId/artifactId/version, but can be extended to
> support dependency includes/excludes mechanism and configuration parameters
> later
> {code:xml}
>
>
>
> ...
> ...
> ...
>
> ...
> ...
>
> {code}
> * change maven to read and load core extensions in separate class realms as
> part of plexus container setup.
> * provide mechanism for extensions to declare exported artifacts and packages
> using {{META-INF/maven/extension.xml}} descriptor.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6957) Versionless reactor dependencies/parent should work even if modules are aggregated in reverse order
[
https://issues.apache.org/jira/browse/MNG-6957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265576#comment-17265576
]
Hudson commented on MNG-6957:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/15/
> Versionless reactor dependencies/parent should work even if modules are
> aggregated in reverse order
> ---
>
> Key: MNG-6957
> URL: https://issues.apache.org/jira/browse/MNG-6957
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0
>Reporter: Herve Boutemy
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> building Maven Artifact buildconsumer branch
> https://github.com/apache/maven-archetype/tree/buildconsumer
> {noformat}$ mvn verify -Drevlist=test
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'dependencies.dependency.version' for
> org.apache.maven.archetype:archetype-packaging:jar is missing. @
> org.apache.maven.plugins:maven-archetype-plugin:[unknown-version],
> /home/herve/projets/maven/sources/plugins/tools/archetype/maven-archetype-plugin/pom.xml,
> line 81, column 17
> @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project
> org.apache.maven.plugins:maven-archetype-plugin:3.2.0-SNAPSHOT
> (/home/herve/projets/maven/sources/plugins/tools/archetype/maven-archetype-plugin/pom.xml)
> has 1 error
> [ERROR] 'dependencies.dependency.version' for
> org.apache.maven.archetype:archetype-packaging:jar is missing. @
> org.apache.maven.plugins:maven-archetype-plugin:[unknown-version],
> /home/herve/projets/maven/sources/plugins/tools/archetype/maven-archetype-plugin/pom.xml,
> line 81, column 17{noformat}
> This is caused by the order of the modules is the reactor:
> {code:xml}
>
> archetype-models
> archetype-common
> maven-archetype-plugin
> archetype-packaging
>
> {code}
> The version is being resolved before {{archetype-packaging}} is available in
> the context. This should become lazy resolution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-3203) maven should execute compiler:compile and :test-compile in separate executions, to allow separate configuration
[ https://issues.apache.org/jira/browse/MNG-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265569#comment-17265569 ] Hudson commented on MNG-3203: - Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/15/ > maven should execute compiler:compile and :test-compile in separate > executions, to allow separate configuration > --- > > Key: MNG-3203 > URL: https://issues.apache.org/jira/browse/MNG-3203 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: John Dennis Casey >Assignee: John Dennis Casey >Priority: Major > Fix For: 2.2.0 > > > Currently, it's impossible to configure the two default maven-compiler-plugin > mojos in the jar lifecycle (:compile and :test-compile) separately without > the configuration for one affecting both. This is because they are both > executed in the same (default) execution. We should be assigning these to > different execution id's, to allow separate configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MGPG-75) Creates a signature with the wrong name if a classifier is defined
[ https://issues.apache.org/jira/browse/MGPG-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265565#comment-17265565 ] Łukasz Dywicki commented on MGPG-75: [~rfscholte] can you please refer place where constraint you talk about is defined? The "it is not allowed that main artifacts have classifiers" seems pretty limiting. Given that some builds might produce platform specific artifacts (think of native builds) having classifiers for main artifacts shouldn't be prohibited. Its pretty sad that I was caught by this issue 19 months after PR solving it was submitted. > Creates a signature with the wrong name if a classifier is defined > -- > > Key: MGPG-75 > URL: https://issues.apache.org/jira/browse/MGPG-75 > Project: Maven GPG Plugin > Issue Type: Bug >Reporter: Mike Hummel >Assignee: Robert Scholte >Priority: Major > > See pull request > [https://github.com/apache/maven-gpg-plugin/pull/2#event-2847163553] > > The main file of a feature project is a xml file and has a classifier. The > plugin ignores the classifier and creates a signature with wrong name. > > The feature is created by the apache karaf maven plugin. > > The fix also use the classifier to create the correct signature file. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265557#comment-17265557 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/15/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265554#comment-17265554 ] Hudson commented on MNG-5728: - Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0, 4.0.0-alpha-1 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7022) Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos backward compat code
[
https://issues.apache.org/jira/browse/MNG-7022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265560#comment-17265560
]
Hudson commented on MNG-7022:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/15/
> Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos backward compat code
>
>
> Key: MNG-7022
> URL: https://issues.apache.org/jira/browse/MNG-7022
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> The handing of optional mojos was dropped long ago in
> ac8db28f3b8cd64192c3d038ee5557354ffb7a30, but the injection remained intact
> for backward compat reasons on legacy {{components.xml}}. Newer setups are
> encouraged to move to
> [{{lifecycle.xml}}|https://maven.apache.org/ref/3.6.3/maven-plugin-api/lifecycle-mappings.html].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
[
https://issues.apache.org/jira/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265562#comment-17265562
]
Hudson commented on MNG-5639:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/15/
> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> --
>
> Key: MNG-5639
> URL: https://issues.apache.org/jira/browse/MNG-5639
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.2.1
>Reporter: Mark Ingram
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.2.2
>
> Attachments: pom.xml
>
>
> Running mvn help:effective-pom on the attached POM:
> {noformat}[ERROR] The project
> com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
> (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not transfer artifact
> org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to
> spring-milestones (${spring.url}): No connector available to access
> repository spring-milestones (${spring.url}) of type default using the
> available factories WagonRepositoryConnectorFactory @ line 20, column 25 ->
> Help 2]{noformat}
> mvn help:effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution, the full project POM
> model has successfully been resolved. So the correct value for the property
> is known and could in theory be substituted into the repository URL before
> the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it
> includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the
> actual use case - several development streams are setup with individual
> sandboxed Nexus repository holding specific version of several shared
> components. The repository configuration uses the pattern
> $\{nexus.baseurl}/content/groups/$\{stream.name} with the properties set in
> settings.xml file.
> One workaround would be to create profiles for every work stream that
> explicitly list the full repository URL, even then the above feature would be
> nice to allow the $\{nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6972) Allow access to org.apache.maven.graph
[
https://issues.apache.org/jira/browse/MNG-6972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265564#comment-17265564
]
Hudson commented on MNG-6972:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/15/
> Allow access to org.apache.maven.graph
> --
>
> Key: MNG-6972
> URL: https://issues.apache.org/jira/browse/MNG-6972
> Project: Maven
> Issue Type: Improvement
> Components: Class Loading, Plugin API
>Affects Versions: 3.6.3
>Reporter: Michael Kroll
>Assignee: Michael Osipov
>Priority: Major
> Labels: easyfix, pull-request-available
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> Hi
> maven doesn't export org.apache.maven.graph package in
> maven-core/src/main/resources/META-INF/maven/extension.xml so the
> GraphBuilder is not usable in extensions.
> {code:java}
> // leads to java.lang.NoClassDefFoundError:
> Lorg/apache/maven/graph/GraphBuilder;
> @Requirement( hint = GraphBuilder.HINT )
> private GraphBuilder graphBuilder;
> {code}
> Background: if one build extension adds dependencies and another build
> extension uses {{session.getProjectDependencyGraph()}}, then the dependency
> graph is out of date. This is because the graph is only rebuilt after
> executing _all_ extensions. One solution to this would be to update the
> {{MavenSession}} and setting the new dependency graph in the first extension,
> but for this we need access to the {{GraphBuilder}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-3259) Regression: Maven drops dependencies in multi-module build
[ https://issues.apache.org/jira/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265558#comment-17265558 ] Hudson commented on MNG-3259: - Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/15/ > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: https://issues.apache.org/jira/browse/MNG-3259 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7, 2.0.8, 3.0-alpha-1 >Reporter: Joerg Schaible >Assignee: John Dennis Casey >Priority: Blocker > Fix For: 2.0.9 > > Attachments: MNG-3259-2.zip, MNG-3259.zip > > Time Spent: 5h > Remaining Estimate: 0h > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265563#comment-17265563
]
Hudson commented on MNG-5760:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/15/
> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 4.0.0, 4.0.0-alpha-1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7046) Revert MNG-5639 and make repo config static only
[ https://issues.apache.org/jira/browse/MNG-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265561#comment-17265561 ] Hudson commented on MNG-7046: - Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/15/ > Revert MNG-5639 and make repo config static only > > > Key: MNG-7046 > URL: https://issues.apache.org/jira/browse/MNG-7046 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories, Dependencies >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > As discussed in MNG-5639 repositories should always be known upfront, they > have to be static to avoid chicken and egg situations, a project should not > influence settings. It should be the way around. > In subsequent ticket it will be verified that repo configuration does not > contain any expression: > https://github.com/apache/maven/commit/d411c3fa98832e7d86d901fe86ff63ba907cf868#commitcomment-44782281. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-4660) Use of --resume-from in multi-module project fails with missing inter-module dependencies
[ https://issues.apache.org/jira/browse/MNG-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265559#comment-17265559 ] Hudson commented on MNG-4660: - Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/15/ > Use of --resume-from in multi-module project fails with missing inter-module > dependencies > - > > Key: MNG-4660 > URL: https://issues.apache.org/jira/browse/MNG-4660 > Project: Maven > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 2.2.1, 3.0-beta-1 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) > Java version: 1.6.0_17 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x" version: "10.6.3" arch: "x86_64" Family: "mac" >Reporter: Brian Ferris >Assignee: Robert Scholte >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > Attachments: modules-parent.tar.gz > > Time Spent: 1h 20m > Remaining Estimate: 0h > > In a simple multi-module project with a parent pom "modules-parent", two sub > modules "module-a" and "module-b", where B depends on A, I've not been able > to get the Maven "--resume-from" feature to work. > Specifically, I expect: > > mvn --resume-from module-b test > would resume execution of the "test" goal in "module-b". Instead it fails > with a missing artifact error: > > [INFO] Failed to resolve artifact. > > > > Missing: > > -- > > 1) org.test:module-a:jar:0.0.1-SNAPSHOT > Why isn't Maven resolving the within-multi-module dependency? I've attached > a simple project that reproduces the problem with Maven 2.2.1 and Maven > 3.0-beta-1. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6957) Versionless reactor dependencies/parent should work even if modules are aggregated in reverse order
[
https://issues.apache.org/jira/browse/MNG-6957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265556#comment-17265556
]
Hudson commented on MNG-6957:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/15/
> Versionless reactor dependencies/parent should work even if modules are
> aggregated in reverse order
> ---
>
> Key: MNG-6957
> URL: https://issues.apache.org/jira/browse/MNG-6957
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0
>Reporter: Herve Boutemy
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> building Maven Artifact buildconsumer branch
> https://github.com/apache/maven-archetype/tree/buildconsumer
> {noformat}$ mvn verify -Drevlist=test
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'dependencies.dependency.version' for
> org.apache.maven.archetype:archetype-packaging:jar is missing. @
> org.apache.maven.plugins:maven-archetype-plugin:[unknown-version],
> /home/herve/projets/maven/sources/plugins/tools/archetype/maven-archetype-plugin/pom.xml,
> line 81, column 17
> @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project
> org.apache.maven.plugins:maven-archetype-plugin:3.2.0-SNAPSHOT
> (/home/herve/projets/maven/sources/plugins/tools/archetype/maven-archetype-plugin/pom.xml)
> has 1 error
> [ERROR] 'dependencies.dependency.version' for
> org.apache.maven.archetype:archetype-packaging:jar is missing. @
> org.apache.maven.plugins:maven-archetype-plugin:[unknown-version],
> /home/herve/projets/maven/sources/plugins/tools/archetype/maven-archetype-plugin/pom.xml,
> line 81, column 17{noformat}
> This is caused by the order of the modules is the reactor:
> {code:xml}
>
> archetype-models
> archetype-common
> maven-archetype-plugin
> archetype-packaging
>
> {code}
> The version is being resolved before {{archetype-packaging}} is available in
> the context. This should become lazy resolution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6566) @Execute should not re-execute goals
[ https://issues.apache.org/jira/browse/MNG-6566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1726#comment-1726 ] Hudson commented on MNG-6566: - Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/15/ > @Execute should not re-execute goals > > > Key: MNG-6566 > URL: https://issues.apache.org/jira/browse/MNG-6566 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Robert Scholte >Assignee: Martin Kanters >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > We're getting quite a lot of requests for -no-fork goals, because now > often plugins are executed twice because of retriggering plugins due to the > @Execute -annotation. > Maven should be able to discover if there's a need to re-execute those > goals/lifecycles. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-3485) unable to override wagons that are bundled with a different version via extensions
[ https://issues.apache.org/jira/browse/MNG-3485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265552#comment-17265552 ] Hudson commented on MNG-3485: - Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/15/ > unable to override wagons that are bundled with a different version via > extensions > -- > > Key: MNG-3485 > URL: https://issues.apache.org/jira/browse/MNG-3485 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.8 >Reporter: Brett Porter >Assignee: Brett Porter >Priority: Major > Fix For: 2.0.9 > > > currently, any wagons distributed with the core cannot be replaced by a > different version via extensions. This was intended, but two issues seem to > have prevented it. > NOTE: the provider-api cannot be replaced, so must be forwards compatible > even if the version is changed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6754) Set the same timestamp in multi module builds
[ https://issues.apache.org/jira/browse/MNG-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265548#comment-17265548 ] Hudson commented on MNG-6754: - Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/15/ > Set the same timestamp in multi module builds > - > > Key: MNG-6754 > URL: https://issues.apache.org/jira/browse/MNG-6754 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, Deployment >Affects Versions: 3.6.3 >Reporter: Michael Angstadt >Assignee: Michael Osipov >Priority: Minor > Fix For: 4.0.0, 4.0.0-alpha-1 > > > When multi module snapshots are built using Maven, the version timestamp may > be different for each module. This makes it difficult to quickly reference a > historical snapshot of a multi module project, which is something we might do > when determining when a bug was introduced. > [This Stack Overflow question|https://stackoverflow.com/q/45629816/2048802] > provides a good example of the problem. [The accepted > answer|https://stackoverflow.com/a/45715820/2048802] seems like a reasonable > solution, but does not appear to work. [Looking at the > code|https://github.com/apache/maven/blob/d9a0eee7fe2e2b1d77e59cf5bc772e758d29e47d/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java#L85], > there does not appear to be a way to override the timestamp. > Please add a way to use a consistent timestamp for all modules in a build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7041) Update @since, version ranges and other version related strings
[ https://issues.apache.org/jira/browse/MNG-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265553#comment-17265553 ] Hudson commented on MNG-7041: - Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/15/ > Update @since, version ranges and other version related strings > --- > > Key: MNG-7041 > URL: https://issues.apache.org/jira/browse/MNG-7041 > Project: Maven > Issue Type: Task > Components: core, Integration Tests >Reporter: Robert Scholte >Assignee: Michael Osipov >Priority: Minor > Fix For: 4.0.0, 4.0.0-alpha-1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-4338) Unexepceted "Unknown packaging: bundle" error for plugins with custom lifecycle mapping that defines optional mojos
[
https://issues.apache.org/jira/browse/MNG-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265551#comment-17265551
]
Hudson commented on MNG-4338:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/15/
> Unexepceted "Unknown packaging: bundle" error for plugins with custom
> lifecycle mapping that defines optional mojos
> ---
>
> Key: MNG-4338
> URL: https://issues.apache.org/jira/browse/MNG-4338
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0
>Reporter: Igor Fedorenko
>Assignee: Benjamin Bentmann
>Priority: Major
> Fix For: 3.0-alpha-3
>
>
> This was originally reported against m2e as
> https://issues.sonatype.org/browse/MNGECLIPSE-1636. Attached sample project
> builds using maven 2.2.1 but fails with using 3.0 snapshot (svn rev 811372)
> {noformat}
> igor@desktop:/tmp/bundle-test$
> /workspaces/tycho-dev/maven/apache-maven/target/apache-maven-3.0-SNAPSHOT/bin/mvn
> -X clean package
> Apache Maven 3.0-SNAPSHOT (r811383; 2009-09-04 12:18:34-0400)
> Java version: 1.6.0_13
> Java home: /opt/jdk1.6.0_13/jre
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "linux" version: "2.6.28-15-generic" arch: "amd64" Family: "unix"
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [DEBUG] Created new class realm project>org.example:bundle-test:1.0.0-SNAPSHOT
> [DEBUG] Included: org.ops4j:maven-pax-plugin:maven-plugin:1.4
> [DEBUG] Excluded: org.apache.maven:maven-project:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-settings:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-model:jar:2.0.7
> [DEBUG] Included: org.codehaus.plexus:plexus-utils:jar:1.4.7
> [DEBUG] Excluded:
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1
> [DEBUG] Included: junit:junit:jar:3.8.1
> [DEBUG] Excluded: classworlds:classworlds:jar:1.1-alpha-2
> [DEBUG] Excluded: org.apache.maven:maven-profile:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-artifact-manager:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-repository-metadata:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-artifact:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven.wagon:wagon-provider-api:jar:1.0-beta-2
> [DEBUG] Excluded: org.apache.maven:maven-plugin-registry:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-plugin-api:jar:2.0.7
> [DEBUG] Included:
> org.apache.maven.archetype:maven-archetype-core:jar:1.0-alpha-7
> [DEBUG] Included: org.codehaus.plexus:plexus-velocity:jar:1.1.2
> [DEBUG] Included: plexus:plexus-utils:jar:1.0.2
> [DEBUG] Included: commons-collections:commons-collections:jar:2.0
> [DEBUG] Included: commons-logging:commons-logging-api:jar:1.0.4
> [DEBUG] Included: velocity:velocity:jar:1.4
> [DEBUG] Included: velocity:velocity-dep:jar:1.4
> [DEBUG] Included: dom4j:dom4j:jar:1.6.1
> [DEBUG] Included: xml-apis:xml-apis:jar:1.0.b2
> [DEBUG] Included: org.apache.maven.shared:maven-downloader:jar:1.0
> [DEBUG] Included:
> org.apache.maven.plugins:maven-compiler-plugin:maven-plugin:2.0.2
> [DEBUG] Included: org.codehaus.plexus:plexus-compiler-api:jar:1.5.3
> [DEBUG] Included: org.codehaus.plexus:plexus-compiler-manager:jar:1.5.3
> [DEBUG] Included: org.codehaus.plexus:plexus-compiler-javac:jar:1.5.3
> [DEBUG] Included:
> org.apache.maven.plugins:maven-eclipse-plugin:maven-plugin:2.5.1
> [DEBUG] Included: org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7
> [DEBUG] Included:
> org.codehaus.plexus:plexus-interactivity-jline:jar:1.0-alpha-5
> [DEBUG] Included: jline:jline:jar:0.9.1
> [DEBUG] Included:
> org.codehaus.plexus:plexus-interactivity-api:jar:1.0-alpha-5
> [DEBUG] Included: org.apache.maven:maven-archiver:jar:2.2
> [DEBUG] Included: org.codehaus.plexus:plexus-resources:jar:1.0-alpha-4
> [DEBUG] Included: biz.aQute:bndlib:jar:0.0.255
> [DEBUG] Included: org.apache.maven.shared:maven-osgi:jar:0.2.0
> [DEBUG] Included: org.eclipse.core:resources:jar:3.3.0-v20070604
> [DEBUG] Included: org.apache.maven.shared:file-management:jar:1.2
> [DEBUG] Included: org.apache.maven.shared:maven-shared-io:jar:1.1
> [DEBUG] Failed to lookup a member of active collection with role:
> org.apache.maven.lifecycle.mapping.LifecycleMapping and role-hint: bundle
> -
> this realm =project>org.example:bundle-test:1.0.0-SNAPSHOT
> this strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> urls[0] =
> file:/home/igor/.m2/repository/org/ops4j/maven-pax-plugin/1.4/maven-pax-plugin-1.4.jar
> urls[1]
[jira] [Commented] (MNG-3203) maven should execute compiler:compile and :test-compile in separate executions, to allow separate configuration
[ https://issues.apache.org/jira/browse/MNG-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265549#comment-17265549 ] Hudson commented on MNG-3203: - Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/15/ > maven should execute compiler:compile and :test-compile in separate > executions, to allow separate configuration > --- > > Key: MNG-3203 > URL: https://issues.apache.org/jira/browse/MNG-3203 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: John Dennis Casey >Assignee: John Dennis Casey >Priority: Major > Fix For: 2.2.0 > > > Currently, it's impossible to configure the two default maven-compiler-plugin > mojos in the jar lifecycle (:compile and :test-compile) separately without > the configuration for one affecting both. This is because they are both > executed in the same (default) execution. We should be assigning these to > different execution id's, to allow separate configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6551) Packaging 'jar' binding plugin upgrades
[ https://issues.apache.org/jira/browse/MNG-6551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265547#comment-17265547 ] Hudson commented on MNG-6551: - Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/15/ > Packaging 'jar' binding plugin upgrades > --- > > Key: MNG-6551 > URL: https://issues.apache.org/jira/browse/MNG-6551 > Project: Maven > Issue Type: Sub-task > Components: core, Dependencies >Affects Versions: 3.5.0, 3.6.0 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This affects: > ||groupId||artifactId||[previous > version|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_jar_packaging]||target > version|| > |org.apache.maven.plugins|maven-resources-plugin|2.6|3.2.0| > |org.apache.maven.plugins|maven-compiler-plugin|3.1|3.8.1| > |org.apache.maven.plugins|maven-surefire-plugin|2.12.4|3.0.0-M5| > |org.apache.maven.plugins|maven-jar-plugin|2.4|3.2.0| > |org.apache.maven.plugins|maven-install-plugin|2.4|3.0.0-M1| > |org.apache.maven.plugins|maven-deploy-plugin|2.7|3.0.0-M1| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5771) improved user-configurable core extensions mechanism
[
https://issues.apache.org/jira/browse/MNG-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265550#comment-17265550
]
Hudson commented on MNG-5771:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/15/
> improved user-configurable core extensions mechanism
>
>
> Key: MNG-5771
> URL: https://issues.apache.org/jira/browse/MNG-5771
> Project: Maven
> Issue Type: Improvement
> Components: Class Loading
>Reporter: Igor Fedorenko
>Assignee: igorfie
>Priority: Major
> Fix For: 3.3.1
>
>
> As of version 3.2.5 maven provides two mechanisms to contribute additional
> components to maven core runtime. It is possible to add component jars to
> {{$M2_HOME/lib/ext directory}}. It is also possible to specify component jars
> using {{-Dmaven.ext.class.path}} command line parameter. Neither of the
> mechanisms is user friendly. In both cases, the user is expected to manually
> locate and download all required jar file. In both cases, this has to be done
> on all systems where the extensions are needed. In both cases, all extra jars
> are loaded into single classloader so all extensions must agree of the same
> set of dependencies.
> This jira is to track changes needed to make it possible to configure core
> extensions in terms of groupId/artifactId/version and share set of required
> extensions across multiple systems.
> More specifically,
> * introduce new {{$\{maven.projectBasedir\}/.mvn/extensions.xml}} descriptor
> to specify list of extensions. Initially, the descriptor will only allow
> specification of extension groupId/artifactId/version, but can be extended to
> support dependency includes/excludes mechanism and configuration parameters
> later
> {code:xml}
>
>
>
> ...
> ...
> ...
>
> ...
> ...
>
> {code}
> * change maven to read and load core extensions in separate class realms as
> part of plexus container setup.
> * provide mechanism for extensions to declare exported artifacts and packages
> using {{META-INF/maven/extension.xml}} descriptor.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6957) Versionless reactor dependencies/parent should work even if modules are aggregated in reverse order
[
https://issues.apache.org/jira/browse/MNG-6957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265532#comment-17265532
]
Hudson commented on MNG-6957:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/15/
> Versionless reactor dependencies/parent should work even if modules are
> aggregated in reverse order
> ---
>
> Key: MNG-6957
> URL: https://issues.apache.org/jira/browse/MNG-6957
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0
>Reporter: Herve Boutemy
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> building Maven Artifact buildconsumer branch
> https://github.com/apache/maven-archetype/tree/buildconsumer
> {noformat}$ mvn verify -Drevlist=test
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'dependencies.dependency.version' for
> org.apache.maven.archetype:archetype-packaging:jar is missing. @
> org.apache.maven.plugins:maven-archetype-plugin:[unknown-version],
> /home/herve/projets/maven/sources/plugins/tools/archetype/maven-archetype-plugin/pom.xml,
> line 81, column 17
> @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project
> org.apache.maven.plugins:maven-archetype-plugin:3.2.0-SNAPSHOT
> (/home/herve/projets/maven/sources/plugins/tools/archetype/maven-archetype-plugin/pom.xml)
> has 1 error
> [ERROR] 'dependencies.dependency.version' for
> org.apache.maven.archetype:archetype-packaging:jar is missing. @
> org.apache.maven.plugins:maven-archetype-plugin:[unknown-version],
> /home/herve/projets/maven/sources/plugins/tools/archetype/maven-archetype-plugin/pom.xml,
> line 81, column 17{noformat}
> This is caused by the order of the modules is the reactor:
> {code:xml}
>
> archetype-models
> archetype-common
> maven-archetype-plugin
> archetype-packaging
>
> {code}
> The version is being resolved before {{archetype-packaging}} is available in
> the context. This should become lazy resolution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-4660) Use of --resume-from in multi-module project fails with missing inter-module dependencies
[ https://issues.apache.org/jira/browse/MNG-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265535#comment-17265535 ] Hudson commented on MNG-4660: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/15/ > Use of --resume-from in multi-module project fails with missing inter-module > dependencies > - > > Key: MNG-4660 > URL: https://issues.apache.org/jira/browse/MNG-4660 > Project: Maven > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 2.2.1, 3.0-beta-1 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) > Java version: 1.6.0_17 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x" version: "10.6.3" arch: "x86_64" Family: "mac" >Reporter: Brian Ferris >Assignee: Robert Scholte >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > Attachments: modules-parent.tar.gz > > Time Spent: 1h 20m > Remaining Estimate: 0h > > In a simple multi-module project with a parent pom "modules-parent", two sub > modules "module-a" and "module-b", where B depends on A, I've not been able > to get the Maven "--resume-from" feature to work. > Specifically, I expect: > > mvn --resume-from module-b test > would resume execution of the "test" goal in "module-b". Instead it fails > with a missing artifact error: > > [INFO] Failed to resolve artifact. > > > > Missing: > > -- > > 1) org.test:module-a:jar:0.0.1-SNAPSHOT > Why isn't Maven resolving the within-multi-module dependency? I've attached > a simple project that reproduces the problem with Maven 2.2.1 and Maven > 3.0-beta-1. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265539#comment-17265539
]
Hudson commented on MNG-5760:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/15/
> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 4.0.0, 4.0.0-alpha-1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265530#comment-17265530 ] Hudson commented on MNG-5728: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0, 4.0.0-alpha-1 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265533#comment-17265533 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/15/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
[
https://issues.apache.org/jira/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265538#comment-17265538
]
Hudson commented on MNG-5639:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/15/
> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> --
>
> Key: MNG-5639
> URL: https://issues.apache.org/jira/browse/MNG-5639
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.2.1
>Reporter: Mark Ingram
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.2.2
>
> Attachments: pom.xml
>
>
> Running mvn help:effective-pom on the attached POM:
> {noformat}[ERROR] The project
> com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
> (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not transfer artifact
> org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to
> spring-milestones (${spring.url}): No connector available to access
> repository spring-milestones (${spring.url}) of type default using the
> available factories WagonRepositoryConnectorFactory @ line 20, column 25 ->
> Help 2]{noformat}
> mvn help:effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution, the full project POM
> model has successfully been resolved. So the correct value for the property
> is known and could in theory be substituted into the repository URL before
> the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it
> includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the
> actual use case - several development streams are setup with individual
> sandboxed Nexus repository holding specific version of several shared
> components. The repository configuration uses the pattern
> $\{nexus.baseurl}/content/groups/$\{stream.name} with the properties set in
> settings.xml file.
> One workaround would be to create profiles for every work stream that
> explicitly list the full repository URL, even then the above feature would be
> nice to allow the $\{nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7022) Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos backward compat code
[
https://issues.apache.org/jira/browse/MNG-7022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265536#comment-17265536
]
Hudson commented on MNG-7022:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/15/
> Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos backward compat code
>
>
> Key: MNG-7022
> URL: https://issues.apache.org/jira/browse/MNG-7022
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> The handing of optional mojos was dropped long ago in
> ac8db28f3b8cd64192c3d038ee5557354ffb7a30, but the injection remained intact
> for backward compat reasons on legacy {{components.xml}}. Newer setups are
> encouraged to move to
> [{{lifecycle.xml}}|https://maven.apache.org/ref/3.6.3/maven-plugin-api/lifecycle-mappings.html].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-3485) unable to override wagons that are bundled with a different version via extensions
[ https://issues.apache.org/jira/browse/MNG-3485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265528#comment-17265528 ] Hudson commented on MNG-3485: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/15/ > unable to override wagons that are bundled with a different version via > extensions > -- > > Key: MNG-3485 > URL: https://issues.apache.org/jira/browse/MNG-3485 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.8 >Reporter: Brett Porter >Assignee: Brett Porter >Priority: Major > Fix For: 2.0.9 > > > currently, any wagons distributed with the core cannot be replaced by a > different version via extensions. This was intended, but two issues seem to > have prevented it. > NOTE: the provider-api cannot be replaced, so must be forwards compatible > even if the version is changed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6566) @Execute should not re-execute goals
[ https://issues.apache.org/jira/browse/MNG-6566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265531#comment-17265531 ] Hudson commented on MNG-6566: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/15/ > @Execute should not re-execute goals > > > Key: MNG-6566 > URL: https://issues.apache.org/jira/browse/MNG-6566 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Robert Scholte >Assignee: Martin Kanters >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > We're getting quite a lot of requests for -no-fork goals, because now > often plugins are executed twice because of retriggering plugins due to the > @Execute -annotation. > Maven should be able to discover if there's a need to re-execute those > goals/lifecycles. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-4338) Unexepceted "Unknown packaging: bundle" error for plugins with custom lifecycle mapping that defines optional mojos
[
https://issues.apache.org/jira/browse/MNG-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265527#comment-17265527
]
Hudson commented on MNG-4338:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/15/
> Unexepceted "Unknown packaging: bundle" error for plugins with custom
> lifecycle mapping that defines optional mojos
> ---
>
> Key: MNG-4338
> URL: https://issues.apache.org/jira/browse/MNG-4338
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0
>Reporter: Igor Fedorenko
>Assignee: Benjamin Bentmann
>Priority: Major
> Fix For: 3.0-alpha-3
>
>
> This was originally reported against m2e as
> https://issues.sonatype.org/browse/MNGECLIPSE-1636. Attached sample project
> builds using maven 2.2.1 but fails with using 3.0 snapshot (svn rev 811372)
> {noformat}
> igor@desktop:/tmp/bundle-test$
> /workspaces/tycho-dev/maven/apache-maven/target/apache-maven-3.0-SNAPSHOT/bin/mvn
> -X clean package
> Apache Maven 3.0-SNAPSHOT (r811383; 2009-09-04 12:18:34-0400)
> Java version: 1.6.0_13
> Java home: /opt/jdk1.6.0_13/jre
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "linux" version: "2.6.28-15-generic" arch: "amd64" Family: "unix"
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [DEBUG] Created new class realm project>org.example:bundle-test:1.0.0-SNAPSHOT
> [DEBUG] Included: org.ops4j:maven-pax-plugin:maven-plugin:1.4
> [DEBUG] Excluded: org.apache.maven:maven-project:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-settings:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-model:jar:2.0.7
> [DEBUG] Included: org.codehaus.plexus:plexus-utils:jar:1.4.7
> [DEBUG] Excluded:
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1
> [DEBUG] Included: junit:junit:jar:3.8.1
> [DEBUG] Excluded: classworlds:classworlds:jar:1.1-alpha-2
> [DEBUG] Excluded: org.apache.maven:maven-profile:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-artifact-manager:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-repository-metadata:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-artifact:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven.wagon:wagon-provider-api:jar:1.0-beta-2
> [DEBUG] Excluded: org.apache.maven:maven-plugin-registry:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-plugin-api:jar:2.0.7
> [DEBUG] Included:
> org.apache.maven.archetype:maven-archetype-core:jar:1.0-alpha-7
> [DEBUG] Included: org.codehaus.plexus:plexus-velocity:jar:1.1.2
> [DEBUG] Included: plexus:plexus-utils:jar:1.0.2
> [DEBUG] Included: commons-collections:commons-collections:jar:2.0
> [DEBUG] Included: commons-logging:commons-logging-api:jar:1.0.4
> [DEBUG] Included: velocity:velocity:jar:1.4
> [DEBUG] Included: velocity:velocity-dep:jar:1.4
> [DEBUG] Included: dom4j:dom4j:jar:1.6.1
> [DEBUG] Included: xml-apis:xml-apis:jar:1.0.b2
> [DEBUG] Included: org.apache.maven.shared:maven-downloader:jar:1.0
> [DEBUG] Included:
> org.apache.maven.plugins:maven-compiler-plugin:maven-plugin:2.0.2
> [DEBUG] Included: org.codehaus.plexus:plexus-compiler-api:jar:1.5.3
> [DEBUG] Included: org.codehaus.plexus:plexus-compiler-manager:jar:1.5.3
> [DEBUG] Included: org.codehaus.plexus:plexus-compiler-javac:jar:1.5.3
> [DEBUG] Included:
> org.apache.maven.plugins:maven-eclipse-plugin:maven-plugin:2.5.1
> [DEBUG] Included: org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7
> [DEBUG] Included:
> org.codehaus.plexus:plexus-interactivity-jline:jar:1.0-alpha-5
> [DEBUG] Included: jline:jline:jar:0.9.1
> [DEBUG] Included:
> org.codehaus.plexus:plexus-interactivity-api:jar:1.0-alpha-5
> [DEBUG] Included: org.apache.maven:maven-archiver:jar:2.2
> [DEBUG] Included: org.codehaus.plexus:plexus-resources:jar:1.0-alpha-4
> [DEBUG] Included: biz.aQute:bndlib:jar:0.0.255
> [DEBUG] Included: org.apache.maven.shared:maven-osgi:jar:0.2.0
> [DEBUG] Included: org.eclipse.core:resources:jar:3.3.0-v20070604
> [DEBUG] Included: org.apache.maven.shared:file-management:jar:1.2
> [DEBUG] Included: org.apache.maven.shared:maven-shared-io:jar:1.1
> [DEBUG] Failed to lookup a member of active collection with role:
> org.apache.maven.lifecycle.mapping.LifecycleMapping and role-hint: bundle
> -
> this realm =project>org.example:bundle-test:1.0.0-SNAPSHOT
> this strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> urls[0] =
> file:/home/igor/.m2/repository/org/ops4j/maven-pax-plugin/1.4/maven-pax-plugin-1.4.jar
> urls[1] =
>
[jira] [Commented] (MNG-7046) Revert MNG-5639 and make repo config static only
[ https://issues.apache.org/jira/browse/MNG-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265537#comment-17265537 ] Hudson commented on MNG-7046: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/15/ > Revert MNG-5639 and make repo config static only > > > Key: MNG-7046 > URL: https://issues.apache.org/jira/browse/MNG-7046 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories, Dependencies >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > As discussed in MNG-5639 repositories should always be known upfront, they > have to be static to avoid chicken and egg situations, a project should not > influence settings. It should be the way around. > In subsequent ticket it will be verified that repo configuration does not > contain any expression: > https://github.com/apache/maven/commit/d411c3fa98832e7d86d901fe86ff63ba907cf868#commitcomment-44782281. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6972) Allow access to org.apache.maven.graph
[
https://issues.apache.org/jira/browse/MNG-6972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265540#comment-17265540
]
Hudson commented on MNG-6972:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/15/
> Allow access to org.apache.maven.graph
> --
>
> Key: MNG-6972
> URL: https://issues.apache.org/jira/browse/MNG-6972
> Project: Maven
> Issue Type: Improvement
> Components: Class Loading, Plugin API
>Affects Versions: 3.6.3
>Reporter: Michael Kroll
>Assignee: Michael Osipov
>Priority: Major
> Labels: easyfix, pull-request-available
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> Hi
> maven doesn't export org.apache.maven.graph package in
> maven-core/src/main/resources/META-INF/maven/extension.xml so the
> GraphBuilder is not usable in extensions.
> {code:java}
> // leads to java.lang.NoClassDefFoundError:
> Lorg/apache/maven/graph/GraphBuilder;
> @Requirement( hint = GraphBuilder.HINT )
> private GraphBuilder graphBuilder;
> {code}
> Background: if one build extension adds dependencies and another build
> extension uses {{session.getProjectDependencyGraph()}}, then the dependency
> graph is out of date. This is because the graph is only rebuilt after
> executing _all_ extensions. One solution to this would be to update the
> {{MavenSession}} and setting the new dependency graph in the first extension,
> but for this we need access to the {{GraphBuilder}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5771) improved user-configurable core extensions mechanism
[
https://issues.apache.org/jira/browse/MNG-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265526#comment-17265526
]
Hudson commented on MNG-5771:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/15/
> improved user-configurable core extensions mechanism
>
>
> Key: MNG-5771
> URL: https://issues.apache.org/jira/browse/MNG-5771
> Project: Maven
> Issue Type: Improvement
> Components: Class Loading
>Reporter: Igor Fedorenko
>Assignee: igorfie
>Priority: Major
> Fix For: 3.3.1
>
>
> As of version 3.2.5 maven provides two mechanisms to contribute additional
> components to maven core runtime. It is possible to add component jars to
> {{$M2_HOME/lib/ext directory}}. It is also possible to specify component jars
> using {{-Dmaven.ext.class.path}} command line parameter. Neither of the
> mechanisms is user friendly. In both cases, the user is expected to manually
> locate and download all required jar file. In both cases, this has to be done
> on all systems where the extensions are needed. In both cases, all extra jars
> are loaded into single classloader so all extensions must agree of the same
> set of dependencies.
> This jira is to track changes needed to make it possible to configure core
> extensions in terms of groupId/artifactId/version and share set of required
> extensions across multiple systems.
> More specifically,
> * introduce new {{$\{maven.projectBasedir\}/.mvn/extensions.xml}} descriptor
> to specify list of extensions. Initially, the descriptor will only allow
> specification of extension groupId/artifactId/version, but can be extended to
> support dependency includes/excludes mechanism and configuration parameters
> later
> {code:xml}
>
>
>
> ...
> ...
> ...
>
> ...
> ...
>
> {code}
> * change maven to read and load core extensions in separate class realms as
> part of plexus container setup.
> * provide mechanism for extensions to declare exported artifacts and packages
> using {{META-INF/maven/extension.xml}} descriptor.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7041) Update @since, version ranges and other version related strings
[ https://issues.apache.org/jira/browse/MNG-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265529#comment-17265529 ] Hudson commented on MNG-7041: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/15/ > Update @since, version ranges and other version related strings > --- > > Key: MNG-7041 > URL: https://issues.apache.org/jira/browse/MNG-7041 > Project: Maven > Issue Type: Task > Components: core, Integration Tests >Reporter: Robert Scholte >Assignee: Michael Osipov >Priority: Minor > Fix For: 4.0.0, 4.0.0-alpha-1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-3203) maven should execute compiler:compile and :test-compile in separate executions, to allow separate configuration
[ https://issues.apache.org/jira/browse/MNG-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265525#comment-17265525 ] Hudson commented on MNG-3203: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/15/ > maven should execute compiler:compile and :test-compile in separate > executions, to allow separate configuration > --- > > Key: MNG-3203 > URL: https://issues.apache.org/jira/browse/MNG-3203 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: John Dennis Casey >Assignee: John Dennis Casey >Priority: Major > Fix For: 2.2.0 > > > Currently, it's impossible to configure the two default maven-compiler-plugin > mojos in the jar lifecycle (:compile and :test-compile) separately without > the configuration for one affecting both. This is because they are both > executed in the same (default) execution. We should be assigning these to > different execution id's, to allow separate configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6754) Set the same timestamp in multi module builds
[ https://issues.apache.org/jira/browse/MNG-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265524#comment-17265524 ] Hudson commented on MNG-6754: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/15/ > Set the same timestamp in multi module builds > - > > Key: MNG-6754 > URL: https://issues.apache.org/jira/browse/MNG-6754 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, Deployment >Affects Versions: 3.6.3 >Reporter: Michael Angstadt >Assignee: Michael Osipov >Priority: Minor > Fix For: 4.0.0, 4.0.0-alpha-1 > > > When multi module snapshots are built using Maven, the version timestamp may > be different for each module. This makes it difficult to quickly reference a > historical snapshot of a multi module project, which is something we might do > when determining when a bug was introduced. > [This Stack Overflow question|https://stackoverflow.com/q/45629816/2048802] > provides a good example of the problem. [The accepted > answer|https://stackoverflow.com/a/45715820/2048802] seems like a reasonable > solution, but does not appear to work. [Looking at the > code|https://github.com/apache/maven/blob/d9a0eee7fe2e2b1d77e59cf5bc772e758d29e47d/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java#L85], > there does not appear to be a way to override the timestamp. > Please add a way to use a consistent timestamp for all modules in a build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-3259) Regression: Maven drops dependencies in multi-module build
[ https://issues.apache.org/jira/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265534#comment-17265534 ] Hudson commented on MNG-3259: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/15/ > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: https://issues.apache.org/jira/browse/MNG-3259 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7, 2.0.8, 3.0-alpha-1 >Reporter: Joerg Schaible >Assignee: John Dennis Casey >Priority: Blocker > Fix For: 2.0.9 > > Attachments: MNG-3259-2.zip, MNG-3259.zip > > Time Spent: 5h > Remaining Estimate: 0h > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6551) Packaging 'jar' binding plugin upgrades
[ https://issues.apache.org/jira/browse/MNG-6551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265523#comment-17265523 ] Hudson commented on MNG-6551: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/15/ > Packaging 'jar' binding plugin upgrades > --- > > Key: MNG-6551 > URL: https://issues.apache.org/jira/browse/MNG-6551 > Project: Maven > Issue Type: Sub-task > Components: core, Dependencies >Affects Versions: 3.5.0, 3.6.0 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This affects: > ||groupId||artifactId||[previous > version|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_jar_packaging]||target > version|| > |org.apache.maven.plugins|maven-resources-plugin|2.6|3.2.0| > |org.apache.maven.plugins|maven-compiler-plugin|3.1|3.8.1| > |org.apache.maven.plugins|maven-surefire-plugin|2.12.4|3.0.0-M5| > |org.apache.maven.plugins|maven-jar-plugin|2.4|3.2.0| > |org.apache.maven.plugins|maven-install-plugin|2.4|3.0.0-M1| > |org.apache.maven.plugins|maven-deploy-plugin|2.7|3.0.0-M1| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5771) improved user-configurable core extensions mechanism
[
https://issues.apache.org/jira/browse/MNG-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265505#comment-17265505
]
Hudson commented on MNG-5771:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6952 #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6952/15/
> improved user-configurable core extensions mechanism
>
>
> Key: MNG-5771
> URL: https://issues.apache.org/jira/browse/MNG-5771
> Project: Maven
> Issue Type: Improvement
> Components: Class Loading
>Reporter: Igor Fedorenko
>Assignee: igorfie
>Priority: Major
> Fix For: 3.3.1
>
>
> As of version 3.2.5 maven provides two mechanisms to contribute additional
> components to maven core runtime. It is possible to add component jars to
> {{$M2_HOME/lib/ext directory}}. It is also possible to specify component jars
> using {{-Dmaven.ext.class.path}} command line parameter. Neither of the
> mechanisms is user friendly. In both cases, the user is expected to manually
> locate and download all required jar file. In both cases, this has to be done
> on all systems where the extensions are needed. In both cases, all extra jars
> are loaded into single classloader so all extensions must agree of the same
> set of dependencies.
> This jira is to track changes needed to make it possible to configure core
> extensions in terms of groupId/artifactId/version and share set of required
> extensions across multiple systems.
> More specifically,
> * introduce new {{$\{maven.projectBasedir\}/.mvn/extensions.xml}} descriptor
> to specify list of extensions. Initially, the descriptor will only allow
> specification of extension groupId/artifactId/version, but can be extended to
> support dependency includes/excludes mechanism and configuration parameters
> later
> {code:xml}
>
>
>
> ...
> ...
> ...
>
> ...
> ...
>
> {code}
> * change maven to read and load core extensions in separate class realms as
> part of plexus container setup.
> * provide mechanism for extensions to declare exported artifacts and packages
> using {{META-INF/maven/extension.xml}} descriptor.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265518#comment-17265518
]
Hudson commented on MNG-5760:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6952 #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6952/15/
> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 4.0.0, 4.0.0-alpha-1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6972) Allow access to org.apache.maven.graph
[
https://issues.apache.org/jira/browse/MNG-6972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265519#comment-17265519
]
Hudson commented on MNG-6972:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6952 #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6952/15/
> Allow access to org.apache.maven.graph
> --
>
> Key: MNG-6972
> URL: https://issues.apache.org/jira/browse/MNG-6972
> Project: Maven
> Issue Type: Improvement
> Components: Class Loading, Plugin API
>Affects Versions: 3.6.3
>Reporter: Michael Kroll
>Assignee: Michael Osipov
>Priority: Major
> Labels: easyfix, pull-request-available
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> Hi
> maven doesn't export org.apache.maven.graph package in
> maven-core/src/main/resources/META-INF/maven/extension.xml so the
> GraphBuilder is not usable in extensions.
> {code:java}
> // leads to java.lang.NoClassDefFoundError:
> Lorg/apache/maven/graph/GraphBuilder;
> @Requirement( hint = GraphBuilder.HINT )
> private GraphBuilder graphBuilder;
> {code}
> Background: if one build extension adds dependencies and another build
> extension uses {{session.getProjectDependencyGraph()}}, then the dependency
> graph is out of date. This is because the graph is only rebuilt after
> executing _all_ extensions. One solution to this would be to update the
> {{MavenSession}} and setting the new dependency graph in the first extension,
> but for this we need access to the {{GraphBuilder}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
[
https://issues.apache.org/jira/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265517#comment-17265517
]
Hudson commented on MNG-5639:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6952 #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6952/15/
> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> --
>
> Key: MNG-5639
> URL: https://issues.apache.org/jira/browse/MNG-5639
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.2.1
>Reporter: Mark Ingram
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.2.2
>
> Attachments: pom.xml
>
>
> Running mvn help:effective-pom on the attached POM:
> {noformat}[ERROR] The project
> com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
> (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not transfer artifact
> org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to
> spring-milestones (${spring.url}): No connector available to access
> repository spring-milestones (${spring.url}) of type default using the
> available factories WagonRepositoryConnectorFactory @ line 20, column 25 ->
> Help 2]{noformat}
> mvn help:effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution, the full project POM
> model has successfully been resolved. So the correct value for the property
> is known and could in theory be substituted into the repository URL before
> the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it
> includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the
> actual use case - several development streams are setup with individual
> sandboxed Nexus repository holding specific version of several shared
> components. The repository configuration uses the pattern
> $\{nexus.baseurl}/content/groups/$\{stream.name} with the properties set in
> settings.xml file.
> One workaround would be to create profiles for every work stream that
> explicitly list the full repository URL, even then the above feature would be
> nice to allow the $\{nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7046) Revert MNG-5639 and make repo config static only
[ https://issues.apache.org/jira/browse/MNG-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265516#comment-17265516 ] Hudson commented on MNG-7046: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6952 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6952/15/ > Revert MNG-5639 and make repo config static only > > > Key: MNG-7046 > URL: https://issues.apache.org/jira/browse/MNG-7046 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories, Dependencies >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > As discussed in MNG-5639 repositories should always be known upfront, they > have to be static to avoid chicken and egg situations, a project should not > influence settings. It should be the way around. > In subsequent ticket it will be verified that repo configuration does not > contain any expression: > https://github.com/apache/maven/commit/d411c3fa98832e7d86d901fe86ff63ba907cf868#commitcomment-44782281. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265512#comment-17265512 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6952 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6952/15/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-3485) unable to override wagons that are bundled with a different version via extensions
[ https://issues.apache.org/jira/browse/MNG-3485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265507#comment-17265507 ] Hudson commented on MNG-3485: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6952 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6952/15/ > unable to override wagons that are bundled with a different version via > extensions > -- > > Key: MNG-3485 > URL: https://issues.apache.org/jira/browse/MNG-3485 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.8 >Reporter: Brett Porter >Assignee: Brett Porter >Priority: Major > Fix For: 2.0.9 > > > currently, any wagons distributed with the core cannot be replaced by a > different version via extensions. This was intended, but two issues seem to > have prevented it. > NOTE: the provider-api cannot be replaced, so must be forwards compatible > even if the version is changed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6957) Versionless reactor dependencies/parent should work even if modules are aggregated in reverse order
[
https://issues.apache.org/jira/browse/MNG-6957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265511#comment-17265511
]
Hudson commented on MNG-6957:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6952 #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6952/15/
> Versionless reactor dependencies/parent should work even if modules are
> aggregated in reverse order
> ---
>
> Key: MNG-6957
> URL: https://issues.apache.org/jira/browse/MNG-6957
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0
>Reporter: Herve Boutemy
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> building Maven Artifact buildconsumer branch
> https://github.com/apache/maven-archetype/tree/buildconsumer
> {noformat}$ mvn verify -Drevlist=test
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'dependencies.dependency.version' for
> org.apache.maven.archetype:archetype-packaging:jar is missing. @
> org.apache.maven.plugins:maven-archetype-plugin:[unknown-version],
> /home/herve/projets/maven/sources/plugins/tools/archetype/maven-archetype-plugin/pom.xml,
> line 81, column 17
> @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project
> org.apache.maven.plugins:maven-archetype-plugin:3.2.0-SNAPSHOT
> (/home/herve/projets/maven/sources/plugins/tools/archetype/maven-archetype-plugin/pom.xml)
> has 1 error
> [ERROR] 'dependencies.dependency.version' for
> org.apache.maven.archetype:archetype-packaging:jar is missing. @
> org.apache.maven.plugins:maven-archetype-plugin:[unknown-version],
> /home/herve/projets/maven/sources/plugins/tools/archetype/maven-archetype-plugin/pom.xml,
> line 81, column 17{noformat}
> This is caused by the order of the modules is the reactor:
> {code:xml}
>
> archetype-models
> archetype-common
> maven-archetype-plugin
> archetype-packaging
>
> {code}
> The version is being resolved before {{archetype-packaging}} is available in
> the context. This should become lazy resolution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-3203) maven should execute compiler:compile and :test-compile in separate executions, to allow separate configuration
[ https://issues.apache.org/jira/browse/MNG-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265504#comment-17265504 ] Hudson commented on MNG-3203: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6952 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6952/15/ > maven should execute compiler:compile and :test-compile in separate > executions, to allow separate configuration > --- > > Key: MNG-3203 > URL: https://issues.apache.org/jira/browse/MNG-3203 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: John Dennis Casey >Assignee: John Dennis Casey >Priority: Major > Fix For: 2.2.0 > > > Currently, it's impossible to configure the two default maven-compiler-plugin > mojos in the jar lifecycle (:compile and :test-compile) separately without > the configuration for one affecting both. This is because they are both > executed in the same (default) execution. We should be assigning these to > different execution id's, to allow separate configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-4338) Unexepceted "Unknown packaging: bundle" error for plugins with custom lifecycle mapping that defines optional mojos
[
https://issues.apache.org/jira/browse/MNG-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265506#comment-17265506
]
Hudson commented on MNG-4338:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6952 #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6952/15/
> Unexepceted "Unknown packaging: bundle" error for plugins with custom
> lifecycle mapping that defines optional mojos
> ---
>
> Key: MNG-4338
> URL: https://issues.apache.org/jira/browse/MNG-4338
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0
>Reporter: Igor Fedorenko
>Assignee: Benjamin Bentmann
>Priority: Major
> Fix For: 3.0-alpha-3
>
>
> This was originally reported against m2e as
> https://issues.sonatype.org/browse/MNGECLIPSE-1636. Attached sample project
> builds using maven 2.2.1 but fails with using 3.0 snapshot (svn rev 811372)
> {noformat}
> igor@desktop:/tmp/bundle-test$
> /workspaces/tycho-dev/maven/apache-maven/target/apache-maven-3.0-SNAPSHOT/bin/mvn
> -X clean package
> Apache Maven 3.0-SNAPSHOT (r811383; 2009-09-04 12:18:34-0400)
> Java version: 1.6.0_13
> Java home: /opt/jdk1.6.0_13/jre
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "linux" version: "2.6.28-15-generic" arch: "amd64" Family: "unix"
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [DEBUG] Created new class realm project>org.example:bundle-test:1.0.0-SNAPSHOT
> [DEBUG] Included: org.ops4j:maven-pax-plugin:maven-plugin:1.4
> [DEBUG] Excluded: org.apache.maven:maven-project:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-settings:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-model:jar:2.0.7
> [DEBUG] Included: org.codehaus.plexus:plexus-utils:jar:1.4.7
> [DEBUG] Excluded:
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1
> [DEBUG] Included: junit:junit:jar:3.8.1
> [DEBUG] Excluded: classworlds:classworlds:jar:1.1-alpha-2
> [DEBUG] Excluded: org.apache.maven:maven-profile:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-artifact-manager:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-repository-metadata:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-artifact:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven.wagon:wagon-provider-api:jar:1.0-beta-2
> [DEBUG] Excluded: org.apache.maven:maven-plugin-registry:jar:2.0.7
> [DEBUG] Excluded: org.apache.maven:maven-plugin-api:jar:2.0.7
> [DEBUG] Included:
> org.apache.maven.archetype:maven-archetype-core:jar:1.0-alpha-7
> [DEBUG] Included: org.codehaus.plexus:plexus-velocity:jar:1.1.2
> [DEBUG] Included: plexus:plexus-utils:jar:1.0.2
> [DEBUG] Included: commons-collections:commons-collections:jar:2.0
> [DEBUG] Included: commons-logging:commons-logging-api:jar:1.0.4
> [DEBUG] Included: velocity:velocity:jar:1.4
> [DEBUG] Included: velocity:velocity-dep:jar:1.4
> [DEBUG] Included: dom4j:dom4j:jar:1.6.1
> [DEBUG] Included: xml-apis:xml-apis:jar:1.0.b2
> [DEBUG] Included: org.apache.maven.shared:maven-downloader:jar:1.0
> [DEBUG] Included:
> org.apache.maven.plugins:maven-compiler-plugin:maven-plugin:2.0.2
> [DEBUG] Included: org.codehaus.plexus:plexus-compiler-api:jar:1.5.3
> [DEBUG] Included: org.codehaus.plexus:plexus-compiler-manager:jar:1.5.3
> [DEBUG] Included: org.codehaus.plexus:plexus-compiler-javac:jar:1.5.3
> [DEBUG] Included:
> org.apache.maven.plugins:maven-eclipse-plugin:maven-plugin:2.5.1
> [DEBUG] Included: org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7
> [DEBUG] Included:
> org.codehaus.plexus:plexus-interactivity-jline:jar:1.0-alpha-5
> [DEBUG] Included: jline:jline:jar:0.9.1
> [DEBUG] Included:
> org.codehaus.plexus:plexus-interactivity-api:jar:1.0-alpha-5
> [DEBUG] Included: org.apache.maven:maven-archiver:jar:2.2
> [DEBUG] Included: org.codehaus.plexus:plexus-resources:jar:1.0-alpha-4
> [DEBUG] Included: biz.aQute:bndlib:jar:0.0.255
> [DEBUG] Included: org.apache.maven.shared:maven-osgi:jar:0.2.0
> [DEBUG] Included: org.eclipse.core:resources:jar:3.3.0-v20070604
> [DEBUG] Included: org.apache.maven.shared:file-management:jar:1.2
> [DEBUG] Included: org.apache.maven.shared:maven-shared-io:jar:1.1
> [DEBUG] Failed to lookup a member of active collection with role:
> org.apache.maven.lifecycle.mapping.LifecycleMapping and role-hint: bundle
> -
> this realm =project>org.example:bundle-test:1.0.0-SNAPSHOT
> this strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> urls[0] =
> file:/home/igor/.m2/repository/org/ops4j/maven-pax-plugin/1.4/maven-pax-plugin-1.4.jar
> urls[1] =
>
[jira] [Commented] (MNG-6566) @Execute should not re-execute goals
[ https://issues.apache.org/jira/browse/MNG-6566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265510#comment-17265510 ] Hudson commented on MNG-6566: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6952 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6952/15/ > @Execute should not re-execute goals > > > Key: MNG-6566 > URL: https://issues.apache.org/jira/browse/MNG-6566 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Robert Scholte >Assignee: Martin Kanters >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > We're getting quite a lot of requests for -no-fork goals, because now > often plugins are executed twice because of retriggering plugins due to the > @Execute -annotation. > Maven should be able to discover if there's a need to re-execute those > goals/lifecycles. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7022) Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos backward compat code
[
https://issues.apache.org/jira/browse/MNG-7022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265515#comment-17265515
]
Hudson commented on MNG-7022:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6952 #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6952/15/
> Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos backward compat code
>
>
> Key: MNG-7022
> URL: https://issues.apache.org/jira/browse/MNG-7022
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> The handing of optional mojos was dropped long ago in
> ac8db28f3b8cd64192c3d038ee5557354ffb7a30, but the injection remained intact
> for backward compat reasons on legacy {{components.xml}}. Newer setups are
> encouraged to move to
> [{{lifecycle.xml}}|https://maven.apache.org/ref/3.6.3/maven-plugin-api/lifecycle-mappings.html].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-3259) Regression: Maven drops dependencies in multi-module build
[ https://issues.apache.org/jira/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265513#comment-17265513 ] Hudson commented on MNG-3259: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6952 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6952/15/ > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: https://issues.apache.org/jira/browse/MNG-3259 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7, 2.0.8, 3.0-alpha-1 >Reporter: Joerg Schaible >Assignee: John Dennis Casey >Priority: Blocker > Fix For: 2.0.9 > > Attachments: MNG-3259-2.zip, MNG-3259.zip > > Time Spent: 5h > Remaining Estimate: 0h > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
