[jira] [Created] (MPLUGIN-529) New goals report-no-fork which will not invoke process-classes
Matt Nelson created MPLUGIN-529: --- Summary: New goals report-no-fork which will not invoke process-classes Key: MPLUGIN-529 URL: https://issues.apache.org/jira/browse/MPLUGIN-529 Project: Maven Plugin Tools Issue Type: Improvement Components: Plugin Reporting Plugin Reporter: Matt Nelson Identical root issues as MJAVADOC-369 and JXR-143 Add new goal which does not fork the build when those phases have already executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-554) Support configuration of upload/download threads individually
[
https://issues.apache.org/jira/browse/MRESOLVER-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842478#comment-17842478
]
Matt Nelson commented on MRESOLVER-554:
---
Disabling parallelPut was the immediate workaround.
With some testing it has been observed that 2-3 upload threads seems to be the
sweet spot on our artifact repository infra. But this causes the download
threads to now be constrained to the same parallelism as uploads.
For a ~90 module reactor deploying ~700 artifacts (jar, pom, site, javadoc,
source, etc...) these were the timings observed. When the infra is under
heavier load single threaded deploys have taken over 5 minutes for this reactor.
{noformat}
1 thread210 seconds
2 threads 180 seconds
3 threads 113 seconds
5 threads frequent errors(5xx and timeouts)
{noformat}
> Support configuration of upload/download threads individually
> -
>
> Key: MRESOLVER-554
> URL: https://issues.apache.org/jira/browse/MRESOLVER-554
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Matt Nelson
>Priority: Major
>
> Parallel deploys were introduced in MRESOLVER-32. The thread pool
> configuration is shared for uploads and downloads. It has been observed in
> our environment that uploads frequently error out when attempting to upload
> with the default thread pool size(5), but conversely we don't see the same
> errors for downloads.
> The proposal is to support configuration of upload/download thread pools
> individually.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-554) Support configuration of upload/download threads individually
Matt Nelson created MRESOLVER-554: - Summary: Support configuration of upload/download threads individually Key: MRESOLVER-554 URL: https://issues.apache.org/jira/browse/MRESOLVER-554 Project: Maven Resolver Issue Type: Improvement Components: Resolver Reporter: Matt Nelson Parallel deploys were introduced in MRESOLVER-32. The thread pool configuration is shared for uploads and downloads. It has been observed in our environment that uploads frequently error out when attempting to upload with the default thread pool size(5), but conversely we don't see the same errors for downloads. The proposal is to support configuration of upload/download thread pools individually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-97) META-INF/services/javax.annotation.processing.Processor copied before compilation and causes error
[
https://issues.apache.org/jira/browse/MCOMPILER-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807362#comment-17807362
]
Matt Nelson commented on MCOMPILER-97:
--
{quote}
one could list the annotation processors or processor path explicitly, but this
results in a POM that is hard to develop and maintain (in the sense that one
would have to construct this enumeration and keep it up-to-date) in contrast
with a POM that does not list them explicitly and instead relies on the default
discovery behavior
{quote}
It appears that this is the direction that javac is heading towards.
https://inside.java/2023/10/23/quality-heads-up/
> META-INF/services/javax.annotation.processing.Processor copied before
> compilation and causes error
> --
>
> Key: MCOMPILER-97
> URL: https://issues.apache.org/jira/browse/MCOMPILER-97
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
> Environment: Ubuntu 8.10, JDK 6.
>Reporter: Jesse N. Glick
>Priority: Major
> Attachments: MCOMPILER-97-workaround.zip, maven-6647998-test.zip
>
>
> It is tricky to compile a Maven module which defines a (269-compliant)
> annotation processor. If you write the code for the processor in
> src/main/java and register it in src/main/resources,
> META-INF/services/javax.annotation.processing.Processor is copied to
> target/classes first, and then javac is run. But javac is given
> target/classes in -classpath, so it tries to load the processor, which of
> course has not been compiled yet - a chicken-and-egg problem.
> The most straightforward workaround is to specify
> -proc:none in your POM. This will only
> work, however, if the module does not use any annotation processors defined
> in dependencies. If it does, there may be some other trick involving
> -processorpath and Maven variable substitution to insert the dependency
> classpath.
> Switching the order of resources:resources and compiler:compile would help -
> at least a clean build would work - though it could still cause problems in
> incremental builds. Better would be for the compiler plugin to pass
> -processorpath based on the dependency classpath (i.e. -classpath minus
> target/classes) when using -source 1.6 or higher.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSOURCES-121) Check for duplicated addition of the same file
[ https://issues.apache.org/jira/browse/MSOURCES-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748237#comment-17748237 ] Matt Nelson commented on MSOURCES-121: -- This change appears to introduce a failure when creating a shaded sources jar https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#createSourcesJar > Check for duplicated addition of the same file > -- > > Key: MSOURCES-121 > URL: https://issues.apache.org/jira/browse/MSOURCES-121 > Project: Maven Source Plugin > Issue Type: Bug >Affects Versions: 3.0.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Critical > Fix For: 3.3.0 > > > By configuring the execution of maven-source-plugin twice you can fail the > build during a release only which is annoying for users. > We need to check if we could identify the duplicate execution of > maven-source-plugin and producing the same files twice...If we identify such > situation we should fail the build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRELEASE-1077) Add support for prepare-specific profiles
[ https://issues.apache.org/jira/browse/MRELEASE-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705413#comment-17705413 ] Matt Nelson commented on MRELEASE-1077: --- Documentation follow up is needed for this issue, the since tag was missed on the new property. > Add support for prepare-specific profiles > - > > Key: MRELEASE-1077 > URL: https://issues.apache.org/jira/browse/MRELEASE-1077 > Project: Maven Release Plugin > Issue Type: New Feature > Components: prepare >Affects Versions: 3.0.0-M5 >Reporter: Niels Basjes >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.0.0 > > > In my projects I like to have the latest released version of the software > shown on the website (which is also in the source tree). I do this using the > exec plugin which runs a script to write the project version in a few places. > For this purpose I propose having the option to allow specifying one or more > profiles that are activated during the prepare phase. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MENFORCER-407) Enforcer 3.0.0 breaks with Maven 3.8.4
[
https://issues.apache.org/jira/browse/MENFORCER-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17558582#comment-17558582
]
Matt Nelson commented on MENFORCER-407:
---
[~michael-o] In the above example, the 3.1.1-snapshot was locally built from
the changes proposed in this PR >
https://github.com/apache/maven-dependency-tree/pull/9
Testing with enforcer 3.1.0 and dep tree 3.1.0, still produces the issue.
{noformat}
[DEBUG] Populating class realm
plugin>org.apache.maven.plugins:maven-enforcer-plugin:3.1.0
[DEBUG] Included: org.apache.maven.plugins:maven-enforcer-plugin:jar:3.1.0
[DEBUG] Included: org.apache.maven.shared:maven-dependency-tree:jar:3.1.0
{noformat}
{noformat}
[WARNING]
Dependency convergence error for
org.robolectric:android-all:jar:12-robolectric-7732740:runtime paths to
dependency are:
+-io.mattnelson:menforcer394:pom:1.0-SNAPSHOT
+-dnsjava:dnsjava:jar:3.5.1:runtime
+-org.robolectric:android-all:jar:12-robolectric-7732740:runtime
and
+-io.mattnelson:menforcer394:pom:1.0-SNAPSHOT
+-io.fabric8:kubernetes-client:jar:5.12.2:runtime
+-com.squareup.okhttp3:okhttp:jar:3.12.12:runtime
+-org.robolectric:android-all:jar:10-robolectric-5803371:runtime
[ERROR] Rule 0: org.apache.maven.plugins.enforcer.DependencyConvergence failed
with message:
Failed while enforcing releasability. See above detailed error message.
{noformat}
> Enforcer 3.0.0 breaks with Maven 3.8.4
> --
>
> Key: MENFORCER-407
> URL: https://issues.apache.org/jira/browse/MENFORCER-407
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0
>Reporter: David Pilato
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: enforcer-3.0.0.log, enforcer.3.0.0-M3.log
>
>
> Here is the situation. I'm trying to [upgrade enforcer from 3.0.0-M3 to
> 3.0.0|https://github.com/dadoonet/fscrawler/pull/1214].
>
> Everything worked well on my laptop with Maven 3.5.3. So I looked at the
> version used by Github actions and saw that it's using Maven 3.8.4.
> As soon as I upgraded my local version of Maven to 3.8.4, I started to hit
> the same exact issue. It seems to try to pull
> net.sf.ehcache:sizeof-agent:1.0.1.
> If I revert Enforcer to 3.0.0-M3 with Maven 3.8.4, I can run without any
> issue mvn enforcer:enforce.
> So I suspect that the combination of both upgrades is triggering something.
> I noted also that 3.0.0 now tries to enforce as well dependencies marked as
> provided. Might be the reason of this.
> I attached the full logs when running with 3.0.0 and 3.0.0-M3.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MENFORCER-394) DependencyConvergence in 3.0.0 fails on provided scoped dependencies
[
https://issues.apache.org/jira/browse/MENFORCER-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552854#comment-17552854
]
Matt Nelson commented on MENFORCER-394:
---
{quote}
in this issue and corresponding PR we add filtering for exclude provided scope
and optional artifacts.
{quote}
Does that include the scopes of transitives? or is it only the scope of
directly declared dependencies?
In the reproduction, the declared dependency is runtime scope, then all of its
provided transitives are being elevated to runtime scope for the context of the
convergence analysis.
{noformat}
Dependency convergence error for
org.robolectric:android-all:jar:12-robolectric-7732740:runtime paths to
dependency are:
+-io.mattnelson:menforcer394:pom:1.0-SNAPSHOT
+-dnsjava:dnsjava:jar:3.5.1:runtime
+-org.robolectric:android-all:jar:12-robolectric-7732740:runtime (scope is
being changed from provided to runtime)
and
+-io.mattnelson:menforcer394:pom:1.0-SNAPSHOT
+-io.fabric8:kubernetes-client:jar:5.12.2:runtime
+-com.squareup.okhttp3:okhttp:jar:3.12.12:runtime
+-org.robolectric:android-all:jar:10-robolectric-5803371:runtime (scope
is being changed from provided to runtime)
{noformat}
> DependencyConvergence in 3.0.0 fails on provided scoped dependencies
>
>
> Key: MENFORCER-394
> URL: https://issues.apache.org/jira/browse/MENFORCER-394
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0
>Reporter: Joe Barnett
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.1.0
>
>
> In our project, using version 3.0.0-M3 of the maven-enforcer-plugin's
> DependencyConvergence rule passes. Using version 3.0.0 starts to show
> convergence errors where provided scope dependencies have different versions
> than compile scope dependencies, for example:
> {code:java}
> [WARNING]
> Dependency convergence error for
> org.javassist:javassist:jar:3.28.0-GA:compile paths to dependency are:
> +-com.trib3:testing:jar:1.25-dependabot-maven-org.apache.maven.plugins-maven-enforcer-plugin-3.0.0-SNAPSHOT
> +-io.dropwizard:dropwizard-auth:jar:2.0.23:compile
> +-io.dropwizard:dropwizard-jersey:jar:2.0.23:compile
> +-org.javassist:javassist:jar:3.28.0-GA:compile
> and
> +-com.trib3:testing:jar:1.25-dependabot-maven-org.apache.maven.plugins-maven-enforcer-plugin-3.0.0-SNAPSHOT
> +-io.dropwizard:dropwizard-testing:jar:2.0.23:compile
> +-org.hibernate:hibernate-core:jar:5.5.2.Final:provided
> +-org.javassist:javassist:jar:3.27.0-GA:provided
> {code}
> Is this an intended breaking change? I don't see anything in the release
> announcement that points obviously to a change here. Seems like the provided
> version shouldn't matter as it doesn't get shipped with the artifact?
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MENFORCER-394) DependencyConvergence in 3.0.0 fails on provided scoped dependencies
[
https://issues.apache.org/jira/browse/MENFORCER-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551314#comment-17551314
]
Matt Nelson commented on MENFORCER-394:
---
[~sjaranowski] With the vote[1] to release, I haven't have been able to verify
this fix. Example reproduction provided[2].
[1] https://www.mail-archive.com/dev@maven.apache.org/msg127088.html
[2] https://github.com/mattnelson/maven-examples/tree/enforcer-394
> DependencyConvergence in 3.0.0 fails on provided scoped dependencies
>
>
> Key: MENFORCER-394
> URL: https://issues.apache.org/jira/browse/MENFORCER-394
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0
>Reporter: Joe Barnett
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.1.0
>
>
> In our project, using version 3.0.0-M3 of the maven-enforcer-plugin's
> DependencyConvergence rule passes. Using version 3.0.0 starts to show
> convergence errors where provided scope dependencies have different versions
> than compile scope dependencies, for example:
> {code:java}
> [WARNING]
> Dependency convergence error for
> org.javassist:javassist:jar:3.28.0-GA:compile paths to dependency are:
> +-com.trib3:testing:jar:1.25-dependabot-maven-org.apache.maven.plugins-maven-enforcer-plugin-3.0.0-SNAPSHOT
> +-io.dropwizard:dropwizard-auth:jar:2.0.23:compile
> +-io.dropwizard:dropwizard-jersey:jar:2.0.23:compile
> +-org.javassist:javassist:jar:3.28.0-GA:compile
> and
> +-com.trib3:testing:jar:1.25-dependabot-maven-org.apache.maven.plugins-maven-enforcer-plugin-3.0.0-SNAPSHOT
> +-io.dropwizard:dropwizard-testing:jar:2.0.23:compile
> +-org.hibernate:hibernate-core:jar:5.5.2.Final:provided
> +-org.javassist:javassist:jar:3.27.0-GA:provided
> {code}
> Is this an intended breaking change? I don't see anything in the release
> announcement that points obviously to a change here. Seems like the provided
> version shouldn't matter as it doesn't get shipped with the artifact?
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MENFORCER-394) DependencyConvergence in 3.0.0 fails on provided scoped dependencies
[
https://issues.apache.org/jira/browse/MENFORCER-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17544634#comment-17544634
]
Matt Nelson commented on MENFORCER-394:
---
Noticing some odd behavior trying to verify this change.
The scope of transitive dependencies appear to be converted from provided to
runtime.
{noformat}
Dependency convergence error for
org.robolectric:android-all:jar:12-robolectric-7732740:runtime paths to
dependency are:
+-company:module:jar:0.85-SNAPSHOT
+-company:other-module:jar:3.0:compile
+-dnsjava:dnsjava:jar:3.5.1:compile
+-org.robolectric:android-all:jar:12-robolectric-7732740:runtime
and
+-company:module:jar:0.85-SNAPSHOT
+-io.fabric8:kubernetes-client:jar:5.12.2:runtime
+-com.squareup.okhttp3:okhttp:jar:3.14.9:runtime
+-org.robolectric:android-all:jar:10-robolectric-5803371:runtime
{noformat}
[https://search.maven.org/artifact/dnsjava/dnsjava/3.5.1/bundle]
{code:xml}
org.robolectric
android-all
12-robolectric-7732740
provided
{code}
[https://search.maven.org/artifact/io.fabric8/kubernetes-client/5.12.2/jar]
default scope of compile
{code:xml}
com.squareup.okhttp3
okhttp
${okhttp.version}
{code}
[https://search.maven.org/artifact/com.squareup.okhttp3/okhttp/3.14.9/jar]
{code:xml}
org.robolectric
android-all
provided
{code}
> DependencyConvergence in 3.0.0 fails on provided scoped dependencies
>
>
> Key: MENFORCER-394
> URL: https://issues.apache.org/jira/browse/MENFORCER-394
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0
>Reporter: Joe Barnett
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.0.1
>
>
> In our project, using version 3.0.0-M3 of the maven-enforcer-plugin's
> DependencyConvergence rule passes. Using version 3.0.0 starts to show
> convergence errors where provided scope dependencies have different versions
> than compile scope dependencies, for example:
> {code:java}
> [WARNING]
> Dependency convergence error for
> org.javassist:javassist:jar:3.28.0-GA:compile paths to dependency are:
> +-com.trib3:testing:jar:1.25-dependabot-maven-org.apache.maven.plugins-maven-enforcer-plugin-3.0.0-SNAPSHOT
> +-io.dropwizard:dropwizard-auth:jar:2.0.23:compile
> +-io.dropwizard:dropwizard-jersey:jar:2.0.23:compile
> +-org.javassist:javassist:jar:3.28.0-GA:compile
> and
> +-com.trib3:testing:jar:1.25-dependabot-maven-org.apache.maven.plugins-maven-enforcer-plugin-3.0.0-SNAPSHOT
> +-io.dropwizard:dropwizard-testing:jar:2.0.23:compile
> +-org.hibernate:hibernate-core:jar:5.5.2.Final:provided
> +-org.javassist:javassist:jar:3.27.0-GA:provided
> {code}
> Is this an intended breaking change? I don't see anything in the release
> announcement that points obviously to a change here. Seems like the provided
> version shouldn't matter as it doesn't get shipped with the artifact?
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MPMD-299) Change of default skipEmptyReport value breaks site:jar
[
https://issues.apache.org/jira/browse/MPMD-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17537657#comment-17537657
]
Matt Nelson commented on MPMD-299:
--
{quote}
You are abusing the package phase
{quote}
I was following the {{site:jar}} documentation.
{quote}
Binds by default to the lifecycle phase: package.
{quote}
https://maven.apache.org/plugins/maven-site-plugin/jar-mojo.html
> Change of default skipEmptyReport value breaks site:jar
> ---
>
> Key: MPMD-299
> URL: https://issues.apache.org/jira/browse/MPMD-299
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: CPD, PMD
>Affects Versions: 3.13.0
>Reporter: Matt Nelson
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Change of default skipEmptyReport value in MPMD-225 causes
> [site:jar|https://maven.apache.org/plugins/maven-site-plugin/jar-mojo.html]
> to be empty.
> Had to revert to the value to get site jars working again.
> {code:xml}
>
> org.apache.maven.plugins
> maven-pmd-plugin
> 3.13.0
>
> true
>
>
> {code}
> Working on getting a repro case against
> https://github.com/apache/maven-pmd-plugin
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MENFORCER-402) RequireUpperBoundDeps now follow scope provided transitive dependencies
[
https://issues.apache.org/jira/browse/MENFORCER-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17535129#comment-17535129
]
Matt Nelson commented on MENFORCER-402:
---
[~slachiewicz] I tried posting to the mailing list on this but I must've done
something wrong cause it never showed up. The request to release 3.0.1 was to
get MENFORCER-394 released which includes a fix identical to the one proposed
on the [PRhttps://github.com/apache/maven-enforcer/pull/140]. Would it be
possible to get that PR merged and included with 3.0.1?
https://lists.apache.org/thread/4y91thymlwfblhvfmfy1y9sg24xg2dhq
> RequireUpperBoundDeps now follow scope provided transitive dependencies
> ---
>
> Key: MENFORCER-402
> URL: https://issues.apache.org/jira/browse/MENFORCER-402
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0
>Reporter: Thomas Mortagne
>Priority: Major
>
> I have a dependency on org.infinispan:infinispan-core:12.1.7.Final and
> upgrading to the enforcer plugin 3.0.0 suddenly made my module fail because
> infinispan-core have conflicting provided dependencies on
> javax.annotation-api:
> {noformat}
> Require upper bound dependencies error for
> javax.annotation:javax.annotation-api:1.3.1 [provided] paths to dependency
> are:
> +-org.xwiki.commons:xwiki-commons-cache-infinispan:13.9-SNAPSHOT
> +-org.infinispan:infinispan-core:12.1.7.Final
> +-javax.annotation:javax.annotation-api:1.3.1 [provided]
> and
> +-org.xwiki.commons:xwiki-commons-cache-infinispan:13.9-SNAPSHOT
> +-org.infinispan:infinispan-core:12.1.7.Final
> +-org.infinispan:infinispan-commons:12.1.7.Final
> +-javax.annotation:javax.annotation-api:1.3.1 [provided]
> and
> +-org.xwiki.commons:xwiki-commons-cache-infinispan:13.9-SNAPSHOT
> +-org.infinispan:infinispan-core:12.1.7.Final
> +-org.infinispan:infinispan-component-processor:12.1.7.Final [provided]
> +-javax.annotation:javax.annotation-api:1.3.1 [provided]
> and
> +-org.xwiki.commons:xwiki-commons-cache-infinispan:13.9-SNAPSHOT
> +-org.infinispan:infinispan-core:12.1.7.Final
> +-org.infinispan.protostream:protostream-types:4.4.1.Final
> +-javax.annotation:javax.annotation-api:1.3.2 [provided]
> and
> +-org.xwiki.commons:xwiki-commons-cache-infinispan:13.9-SNAPSHOT
> +-org.infinispan:infinispan-core:12.1.7.Final
> +-org.infinispan.protostream:protostream-processor:4.4.1.Final [provided]
> +-javax.annotation:javax.annotation-api:1.3.2 [provided]
> and
> +-org.xwiki.commons:xwiki-commons-cache-infinispan:13.9-SNAPSHOT
> +-org.infinispan:infinispan-core:12.1.7.Final
> +-org.infinispan:infinispan-commons:12.1.7.Final
> +-org.infinispan:infinispan-commons-jdk11:12.1.7.Final [provided]
> +-javax.annotation:javax.annotation-api:1.3.1 [provided]
> {noformat}
> It's not clear if this was done on purpose since I cannot find anything about
> that in the release note, but I might have missed it. Problem is that
> provided scope dependencies are not necessarily used at runtime (it's often
> used as a way to avoid making transitive a dependency you only need at build
> time) and adding an for a non-transitive dependency feels quite
> weird.
> At least if this is not a bug, it would be nice to make this behavior
> configurable.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MENFORCER-407) Enforcer 3.0.0 breaks with Maven 3.8.4
[
https://issues.apache.org/jira/browse/MENFORCER-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500309#comment-17500309
]
Matt Nelson commented on MENFORCER-407:
---
[~michael-o] I'll echo what has been said on a few of the other issues logged
against enforcer-3.0.0. I pulled down the changes from MSHARED-1016 and was
able to confirm that fixes the issue.
{code:xml}
org.apache.maven.plugins
maven-enforcer-plugin
3.0.0
org.apache.maven.shared
maven-dependency-tree
3.1.1-SNAPSHOT
{code}
> Enforcer 3.0.0 breaks with Maven 3.8.4
> --
>
> Key: MENFORCER-407
> URL: https://issues.apache.org/jira/browse/MENFORCER-407
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0
>Reporter: David Pilato
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: enforcer-3.0.0.log, enforcer.3.0.0-M3.log
>
>
> Here is the situation. I'm trying to [upgrade enforcer from 3.0.0-M3 to
> 3.0.0|https://github.com/dadoonet/fscrawler/pull/1214].
>
> Everything worked well on my laptop with Maven 3.5.3. So I looked at the
> version used by Github actions and saw that it's using Maven 3.8.4.
> As soon as I upgraded my local version of Maven to 3.8.4, I started to hit
> the same exact issue. It seems to try to pull
> net.sf.ehcache:sizeof-agent:1.0.1.
> If I revert Enforcer to 3.0.0-M3 with Maven 3.8.4, I can run without any
> issue mvn enforcer:enforce.
> So I suspect that the combination of both upgrades is triggering something.
> I noted also that 3.0.0 now tries to enforce as well dependencies marked as
> provided. Might be the reason of this.
> I attached the full logs when running with 3.0.0 and 3.0.0-M3.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MENFORCER-407) Enforcer 3.0.0 breaks with Maven 3.8.4
[ https://issues.apache.org/jira/browse/MENFORCER-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17493422#comment-17493422 ] Matt Nelson commented on MENFORCER-407: --- [~michael-o] Does the example help? What brought me to this issue was attempting to upgrade to JDK 17 while using extra-enforcer-rules. extra-enforcer-rules-1.4 was updated[1] to support JDK 17, which also bumped the required[2] enforcer versions, which then introduced changes to the behavior of the dependency convergence rules. [1] https://github.com/mojohaus/extra-enforcer-rules/pull/129 [2] https://github.com/mojohaus/extra-enforcer-rules/issues/131 > Enforcer 3.0.0 breaks with Maven 3.8.4 > -- > > Key: MENFORCER-407 > URL: https://issues.apache.org/jira/browse/MENFORCER-407 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Plugin >Affects Versions: 3.0.0 >Reporter: David Pilato >Priority: Major > Fix For: waiting-for-feedback > > Attachments: enforcer-3.0.0.log, enforcer.3.0.0-M3.log > > > Here is the situation. I'm trying to [upgrade enforcer from 3.0.0-M3 to > 3.0.0|https://github.com/dadoonet/fscrawler/pull/1214]. > > Everything worked well on my laptop with Maven 3.5.3. So I looked at the > version used by Github actions and saw that it's using Maven 3.8.4. > As soon as I upgraded my local version of Maven to 3.8.4, I started to hit > the same exact issue. It seems to try to pull > net.sf.ehcache:sizeof-agent:1.0.1. > If I revert Enforcer to 3.0.0-M3 with Maven 3.8.4, I can run without any > issue mvn enforcer:enforce. > So I suspect that the combination of both upgrades is triggering something. > I noted also that 3.0.0 now tries to enforce as well dependencies marked as > provided. Might be the reason of this. > I attached the full logs when running with 3.0.0 and 3.0.0-M3. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MENFORCER-411) DependencyConvergence should support including/excluding certain dependencies
[
https://issues.apache.org/jira/browse/MENFORCER-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478947#comment-17478947
]
Matt Nelson commented on MENFORCER-411:
---
{quote}Can you give an example of how there would be a later build failure from
one of the causes you mentioned?{quote}
Maven has deterministic class path ordering[1]. Introducing an option to ignore
convergence errors on specific dependencies could introduce build failures if
the pom is reordered or sorted. In this scenario the error would be later in
the build (compile or test) and it would not be as immediately clear that it is
a convergence error.
[1]
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies
> DependencyConvergence should support including/excluding certain dependencies
> -
>
> Key: MENFORCER-411
> URL: https://issues.apache.org/jira/browse/MENFORCER-411
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Standard Rules
>Affects Versions: 3.0.1
>Reporter: Forrest Feaser
>Priority: Major
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> It would be nice if the DependencyConvergence rule could specify certain
> dependencies that should/should not fail the build. This might be useful if
> your project has a lot of dependency conflicts, but you know there are just a
> few troublesome ones that cause issues, and you don't want to resolve the
> conflicts for your entire project.
> Here is my PR: https://github.com/apache/maven-enforcer/pull/136
> Do I need to sign the Contributor License Agreement for this?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MENFORCER-411) DependencyConvergence should support including/excluding certain dependencies
[ https://issues.apache.org/jira/browse/MENFORCER-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478263#comment-17478263 ] Matt Nelson commented on MENFORCER-411: --- Would this introduce a false sense of correctness on a build that could then have later build failures caused by the compile/test classpaths or packaging order in the case of war/shade? > DependencyConvergence should support including/excluding certain dependencies > - > > Key: MENFORCER-411 > URL: https://issues.apache.org/jira/browse/MENFORCER-411 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 3.0.1 >Reporter: Forrest Feaser >Priority: Major > Original Estimate: 4h > Remaining Estimate: 4h > > It would be nice if the DependencyConvergence rule could specify certain > dependencies that should/should not fail the build. This might be useful if > your project has a lot of dependency conflicts, but you know there are just a > few troublesome ones that cause issues, and you don't want to resolve the > conflicts for your entire project. > Here is my PR: https://github.com/apache/maven-enforcer/pull/136 > Do I need to sign the Contributor License Agreement for this? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MENFORCER-407) Enforcer 3.0.0 breaks with Maven 3.8.4
[ https://issues.apache.org/jira/browse/MENFORCER-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478252#comment-17478252 ] Matt Nelson commented on MENFORCER-407: --- [~michael-o] minimal reproducible example https://github.com/mattnelson/maven-examples/tree/menforcer-407 > Enforcer 3.0.0 breaks with Maven 3.8.4 > -- > > Key: MENFORCER-407 > URL: https://issues.apache.org/jira/browse/MENFORCER-407 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Plugin >Affects Versions: 3.0.0 >Reporter: David Pilato >Priority: Major > Fix For: waiting-for-feedback > > Attachments: enforcer-3.0.0.log, enforcer.3.0.0-M3.log > > > Here is the situation. I'm trying to [upgrade enforcer from 3.0.0-M3 to > 3.0.0|https://github.com/dadoonet/fscrawler/pull/1214]. > > Everything worked well on my laptop with Maven 3.5.3. So I looked at the > version used by Github actions and saw that it's using Maven 3.8.4. > As soon as I upgraded my local version of Maven to 3.8.4, I started to hit > the same exact issue. It seems to try to pull > net.sf.ehcache:sizeof-agent:1.0.1. > If I revert Enforcer to 3.0.0-M3 with Maven 3.8.4, I can run without any > issue mvn enforcer:enforce. > So I suspect that the combination of both upgrades is triggering something. > I noted also that 3.0.0 now tries to enforce as well dependencies marked as > provided. Might be the reason of this. > I attached the full logs when running with 3.0.0 and 3.0.0-M3. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MENFORCER-407) Enforcer 3.0.0 breaks with Maven 3.8.4
[
https://issues.apache.org/jira/browse/MENFORCER-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468257#comment-17468257
]
Matt Nelson commented on MENFORCER-407:
---
Trying to see if I can create a minimal reproducible example, not quite there
yet.
But here is what I can share so far. A common theme is that all of the
violations are related to a provided dependencies that do not match convergence
between the other versions, provided or not.
Output from failing rule, redacted internal identifiers.
{noformat}
[WARNING]
Dependency convergence error for
javax.servlet:javax.servlet-api:jar:4.0.1:provided paths to dependency are:
+-mygroup:myartifact:jar:myversion
+-mygroup:myartifact:jar:myversion:compile
+-mygroup:myartifact:jar:myversion:compile
+-javax.servlet:javax.servlet-api:jar:4.0.1:provided
and
+-mygroup:myartifact:jar:myversion
+-mygroup:myartifact:jar:myversion:test
+-org.eclipse.jetty:jetty-jndi:jar:9.4.44.v20210927:test
+-org.eclipse.jetty:jetty-util:jar:9.4.44.v20210927:test
+-javax.servlet:javax.servlet-api:jar:3.1.0:test
and
+-mygroup:myartifact:jar:myversion
+-mygroup:myartifact:jar:myversion:test
+-org.eclipse.jetty:jetty-jndi:jar:9.4.44.v20210927:test
+-org.eclipse.jetty:jetty-webapp:jar:9.4.44.v20210927:test
+-org.eclipse.jetty:jetty-servlet:jar:9.4.44.v20210927:test
+-org.eclipse.jetty:jetty-util-ajax:jar:9.4.44.v20210927:test
+-javax.servlet:javax.servlet-api:jar:3.1.0:test
[WARNING]
Dependency convergence error for javax.servlet:servlet-api:jar:2.4:provided
paths to dependency are:
+-mygroup:myartifact:jar:myversion
+-mygroup:myartifact:jar:myversion:compile
+-commons-configuration:commons-configuration:jar:1.10:compile
+-javax.servlet:servlet-api:jar:2.4:provided
and
+-mygroup:myartifact:jar:myversion
+-mygroup:myartifact:jar:myversion:compile
+-mygroup:myartifact:jar:myversion:compile
+-mygroup:myartifact:jar:myversion:compile
+-net.oauth.core:oauth-provider:jar:20100527:compile
+-javax.servlet:servlet-api:jar:2.4:provided
and
+-mygroup:myartifact:jar:myversion
+-mygroup:myartifact:jar:myversion:compile
+-mygroup:myartifact:jar:myversion:compile
+-mygroup:myartifact:jar:myversion:compile
+-javax.servlet:servlet-api:jar:2.5:provided
and
+-mygroup:myartifact:jar:myversion
+-mygroup:myartifact:jar:myversion:compile
+-mygroup:myartifact:jar:myversion:compile
+-mygroup:myartifact:jar:myversion:compile
+-javax.servlet:servlet-api:jar:2.5:provided
and
+-mygroup:myartifact:jar:myversion
+-mygroup:myartifact:jar:myversion:compile
+-mygroup:myartifact:jar:myversion:compile
+-mygroup:myartifact:jar:myversion:compile
+-javax.servlet:servlet-api:jar:2.4:provided
and
+-mygroup:myartifact:jar:myversion
+-mygroup:myartifact:jar:myversion:compile
+-javax.servlet:servlet-api:jar:2.5:provided
{noformat}
Another interesting bit. I am using the bannedDependencies rule on these
artifacts since we are managing up to the compatible jakarta version. That rule
was passing which leads me to believe that those were not being evaluated
previously. Haven't got far enough into the build yet to see if this starts
failing now as well.
{code:xml}
javax.servlet:javax.servlet-api
javax.servlet:servlet-api
{code}
> Enforcer 3.0.0 breaks with Maven 3.8.4
> --
>
> Key: MENFORCER-407
> URL: https://issues.apache.org/jira/browse/MENFORCER-407
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0
>Reporter: David Pilato
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: enforcer-3.0.0.log, enforcer.3.0.0-M3.log
>
>
> Here is the situation. I'm trying to [upgrade enforcer from 3.0.0-M3 to
> 3.0.0|https://github.com/dadoonet/fscrawler/pull/1214].
>
> Everything worked well on my laptop with Maven 3.5.3. So I looked at the
> version used by Github actions and saw that it's using Maven 3.8.4.
> As soon as I upgraded my local version of Maven to 3.8.4, I started to hit
> the same exact issue. It seems to try to pull
> net.sf.ehcache:sizeof-agent:1.0.1.
> If I revert Enforcer to 3.0.0-M3 with Maven 3.8.4, I can run without any
> issue mvn enforcer:enforce.
> So I suspect that the combination of both upgrades is triggering something.
> I noted also that 3.0.0 now tries to enforce as well dependencies marked as
> provided. Might be the reason of this.
> I attached the full logs when running with 3.0.0 and 3.0.0-M3.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MENFORCER-407) Enforcer 3.0.0 breaks with Maven 3.8.4
[
https://issues.apache.org/jira/browse/MENFORCER-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467040#comment-17467040
]
Matt Nelson commented on MENFORCER-407:
---
{quote}
Different resolution behavior
{quote}
Adding another perspective that I'm seeing this as well. I am able to generate
{{dependency:tree}} and {{dependency:collect}} without error, and the
dependencies listed as a problem with the {{dependencyConvergence}} rule do not
show in the tree/collect outputs.
> Enforcer 3.0.0 breaks with Maven 3.8.4
> --
>
> Key: MENFORCER-407
> URL: https://issues.apache.org/jira/browse/MENFORCER-407
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0
>Reporter: David Pilato
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: enforcer-3.0.0.log, enforcer.3.0.0-M3.log
>
>
> Here is the situation. I'm trying to [upgrade enforcer from 3.0.0-M3 to
> 3.0.0|https://github.com/dadoonet/fscrawler/pull/1214].
>
> Everything worked well on my laptop with Maven 3.5.3. So I looked at the
> version used by Github actions and saw that it's using Maven 3.8.4.
> As soon as I upgraded my local version of Maven to 3.8.4, I started to hit
> the same exact issue. It seems to try to pull
> net.sf.ehcache:sizeof-agent:1.0.1.
> If I revert Enforcer to 3.0.0-M3 with Maven 3.8.4, I can run without any
> issue mvn enforcer:enforce.
> So I suspect that the combination of both upgrades is triggering something.
> I noted also that 3.0.0 now tries to enforce as well dependencies marked as
> provided. Might be the reason of this.
> I attached the full logs when running with 3.0.0 and 3.0.0-M3.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-6843) Parallel build fails due to missing JAR artifacts in compilePath
[
https://issues.apache.org/jira/browse/MNG-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343621#comment-17343621
]
Matt Nelson commented on MNG-6843:
--
{quote}
Btw: It seems that in my case the problem can be worked around by defining the
respective dependencies directly instead of relying on being pulled in
transitively.
{quote}
Not a solution, but can be used as a temporary workaround. Having a compilation
dependency transitively provided can be fragile if the top level dependency no
longer provides that transitive after an update. The dependency plugin's
analyze* goals can alert to this situation with a "used and undeclared" warning.
https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html
> Parallel build fails due to missing JAR artifacts in compilePath
>
>
> Key: MNG-6843
> URL: https://issues.apache.org/jira/browse/MNG-6843
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
> Environment: - Linux (tested Docker using maven:3-jdk-8 tag): happens
> most times.
> - Windows 10: happens sometimes.
>Reporter: Stepan Hrbacek
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Build of our multi module (57) Java maven project is failing phase when
> running it as parallel in 4 threads (mvn -T 4 clean install). The failure
> happens during compilation because packages/classes from compile dependencies
> cannot be found:
> {noformat}
> [main] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project common: Compilation failure: Compilation
> failure:
> [main] [ERROR]
> /home/common/src/main/java/com/foo/ZonedDateTimeParser.java:[6,32] package
> org.apache.commons.lang3 does not exist{noformat}
> After enabling debug logging (with thread names) I have found out that a
> compile path of the failing module is empty (besides target/classes):
> When running in 4 threads (-T 4):
> {noformat}
> [BuilderThread 2] [DEBUG] (f) compilePath = [/home/common/target/classes]
> ...
> [BuilderThread 2] [DEBUG] Command line options:
> [BuilderThread 2] [DEBUG] -d /home/common/target/classes -classpath
> /home/common/target/classes: -sourcepath
> /home/common/src/main/java:/home/common/target/generated-sources/annotations:
> -s /home/common/target/generated-sources/annotations -g -nowarn -target 1.8
> -source 1.8 -encoding UTF-8{noformat}
> When running in a single thread (-T 1):
> {noformat}
> [BuilderThread 0] [DEBUG] (f) compilePath = [/home/common/target/classes,
> /root/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar,
>
> /root/.m2/repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar,
>
> /root/.m2/repository/org/apache/commons/commons-collections4/4.3/commons-collections4-4.3.jar,
>
> /root/.m2/repository/org/apache/commons/commons-lang3/3.9/commons-lang3-3.9.jar,
> /root/.m2/repository/org/jooq/jool-java-8/0.9.14/jool-java-8-0.9.14.jar,
> /root/.m2/repository/org/slf4j/slf4j-api/1.7.26/slf4j-api-1.7.26.jar,
> /root/.m2/repository/org/springframework/spring-beans/5.1.8.RELEASE/spring-beans-5.1.8.RELEASE.jar,
>
> /root/.m2/repository/org/springframework/spring-core/5.1.8.RELEASE/spring-core-5.1.8.RELEASE.jar,
>
> /root/.m2/repository/org/springframework/spring-context/5.1.8.RELEASE/spring-context-5.1.8.RELEASE.jar]
> ...
> [BuilderThread 0] [DEBUG] Command line options:
> [BuilderThread 0] [DEBUG] -d /home/common/target/classes -classpath
> /home/common/target/classes:/root/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar:/root/.m2/repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar:/root/.m2/repository/org/apache/commons/commons-collections4/4.3/commons-collections4-4.3.jar:/root/.m2/repository/org/apache/commons/commons-lang3/3.9/commons-lang3-3.9.jar:/root/.m2/repository/org/jooq/jool-java-8/0.9.14/jool-java-8-0.9.14.jar:/root/.m2/repository/org/slf4j/slf4j-api/1.7.26/slf4j-api-1.7.26.jar:/root/.m2/repository/org/springframework/spring-beans/5.1.8.RELEASE/spring-beans-5.1.8.RELEASE.jar:/root/.m2/repository/org/springframework/spring-core/5.1.8.RELEASE/spring-core-5.1.8.RELEASE.jar:/root/.m2/repository/org/springframework/spring-context/5.1.8.RELEASE/spring-context-5.1.8.RELEASE.jar:
> -sourcepath
> /home/common/src/main/java:/home/common/target/generated-sources/annotations:
> -s /home/common/target/generated-sources/annotations -g -nowarn -target 1.8
> -source 1.8 -encoding UTF-8{noformat}
> After adding custom log messages I have found out that the root cause is that
> org.apache.maven.project.MavenProject.setArtifactFilter() is called with null
> artifactFilter
[jira] [Commented] (MENFORCER-376) Add support for excludes/includes in requireJavaVendor rule
[ https://issues.apache.org/jira/browse/MENFORCER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17331106#comment-17331106 ] Matt Nelson commented on MENFORCER-376: --- Is there a way to signal this issue should be a blocker for the next release 3.0.0 or 3.0.0-M4? The changes proposed here are non passive to the yet to be released changes from MENFORCER-338. I want to protect against a scenario where enforcer is released without this change, thus preventing it from being accepted due to being non passive. > Add support for excludes/includes in requireJavaVendor rule > --- > > Key: MENFORCER-376 > URL: https://issues.apache.org/jira/browse/MENFORCER-376 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Priority: Major > > There was a suggestion here [1] to add includes/excludes support in > requireJavaVendor rule. Right now it's not clear how it would work if you > define the same vendor name in exclude and include lists but implementation > can be more or less copied from BannedDependencies rule. > [1] > https://issues.apache.org/jira/browse/MENFORCER-338?focusedCommentId=17169044=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17169044 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241049#comment-17241049
]
Matt Nelson commented on MNG-6772:
--
{quote}The test fails because your have overridden Central in your POM, but my
corporate settings has a mirror of Central against a local Nexus instance,
therefore the artifacts are not found.
{quote}
Is this an issue with the methods of overriding the location of central
currently being mutually exclusive?
||pom||settings.xml||resolves||central from||
| | |(/)|super pom|
| |(/)|(/)|settings.xml|
|(/)| |(/)|pom|
|(/)|(/)|(x)|?|
Forgetting central and super pom for a moment... Would this be an issue with
any named repository from an import pom that is redefined in project pom or
setting.xml?
It seems like there should be an order of precedence for a where the location
of a repository can be sourced from:
# settings.xml
# project pom
# dependency/import pom
# super pom
> Super POM overwrites remapped central repository in nested import POMs
> --
>
> Key: MNG-6772
> URL: https://issues.apache.org/jira/browse/MNG-6772
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, POM
>Affects Versions: 3.6.2
>Reporter: Eddie Wiegers
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: wontfix-candidate, 4.0.0, 4.0.0-alpha-1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} which is meant to
> specifically override the entry in the Super POM. This is specifically what
> [JFrog Artifactory
> recommends|https://www.jfrog.com/confluence/display/RTF/Maven+Repository#MavenRepository-ManuallyOverridingtheBuilt-inRepositories]
> doing, and seems valid in situations where the _real_ Maven Central may be
> unreachable.
>
> The override takes precedence almost all of the time. However, there is at
> least one scenario where this is not the case, and that is when importing a
> POM that in turn imports another POM.
>
> Digging into the code, it appears the reason this happens is because the
> {{DefaultModelBuilder}} overwrites repositories after interpolation is
> complete:
> [https://github.com/apache/maven/blob/53f04f03e3e58c75dcc791d557758357a6ec7983/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L411]
>
> From what I can tell, this is done with the intention of overwriting
> repositories that were added to the local resolver prior to interpolation
> with the interpolated version. Due to the way the {{DefaultModelResolver}}
> works, an unintended side effect is that the {{central}} repository from the
> Super POM is added once after each interpolation. The first time the
> repository is added, it is added to the {{repositoryIds}} but doesn't
> actually remove the original repository. The second time it is added is when
> the original repository will be replaced. Currently, the repositoryIds are
> preserved in the {{ModelResolver}} when resolving import POMs, leading to the
> behavior I am seeing where the second nested import POM ends up being where
> the failure occurs.
>
> I am planning on submitting a PR to clone the {{ModelResolver}} in a way that
> resets the repositoryIds prior to import POMs being resolved, since they are
> separate artifact builds. That seems like the most consistent fix to me that
> covers cases outside of the the Super POM's {{central}} definition.
>
> *Workarounds*:
> The current workaround is to use a repository ID other than {{central}} for
> my Artifactory repository, which isn't ideal since it leaves the potential
> for long timeouts to occur on the real {{central}} when an artifact can't be
> resolved from my Artifactory repository.
>
> Mirrors are not an ideal workaround since getting them in place on all
> possible build environments isn't trivial.
>
> When looking at the code I noticed
> {{RepositorySystemSession#isIgnoreArtifactDescriptorRepositories()}} being
> checked in various places, which seems like it would also act as a potential
> workaround, but I don't see a way to enable this value via MavenCLI or
> properties of any kind. It seems like this value aligns well with what
> Artifactory is already trying to enforce, so it would make sense to enable
> this in projects that intend to exclusively use Artifactory. Is there a
> supported way to set this value outside of constructing a Maven build in code?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCHANGES-340) Retrieve Jira user/password from settings.xml
[ https://issues.apache.org/jira/browse/MCHANGES-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17188615#comment-17188615 ] Matt Nelson commented on MCHANGES-340: -- [~slachiewicz] What are the next steps to make progress on this issue? > Retrieve Jira user/password from settings.xml > - > > Key: MCHANGES-340 > URL: https://issues.apache.org/jira/browse/MCHANGES-340 > Project: Maven Changes Plugin > Issue Type: New Feature > Components: jira >Reporter: Guillaume Boucherie >Assignee: Sylwester Lachiewicz >Priority: Major > Attachments: MCHANGES-340.patch > > > Add a mechanism to get jira credentials from settings.xml instead from pom > only. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MENFORCER-338) Along with JavaVersion, allow enforcement of the JavaVendor
[
https://issues.apache.org/jira/browse/MENFORCER-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170233#comment-17170233
]
Matt Nelson commented on MENFORCER-338:
---
Thought of another reason why a list of includes would be helpful. The recent
announcement of Eclipse taking over AdoptOpenJDK is going to result in a change
of the vendor name. During this transition period I imagine there will some
overlap where both vendors would be acceptable.
https://github.com/AdoptOpenJDK/TSC/issues/160#issuecomment-646807353
{code:xml}
AdoptOpenJDK
Eclipse Adoptium
{code}
> Along with JavaVersion, allow enforcement of the JavaVendor
> ---
>
> Key: MENFORCER-338
> URL: https://issues.apache.org/jira/browse/MENFORCER-338
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
>Reporter: Jeffrey Bennett
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.0.0-M4
>
>
> It would be useful to be able to ensure that a particular vendor JDK is being
> used. For example, I may need to confirm that we are using AdoptOpenJDK
> 1.8.0_232 and not Oracle JDK 1.8.0_232.
>
> I would assume that you would define a set of enums for the vendors - e.g.
> (OracleJDK, AdoptOpenJDK, JavaOpenJDK, and maybe a few others) so that it
> would look something like this to insure that either Adopt or Amazon JDK
> vendor was used.
> EDIT: implemented as below, to be in line with RequireOs
> {code:xml}
>
> Oracle Corporation
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MENFORCER-338) Along with JavaVersion, allow enforcement of the JavaVendor
[
https://issues.apache.org/jira/browse/MENFORCER-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17169044#comment-17169044
]
Matt Nelson commented on MENFORCER-338:
---
Is there a desire to support a list of includes/excludes?
Only deny licensed vendors
{code:xml}
Oracle Corporation
{code}
Allow multiple approved vendors
{code:xml}
AdoptOpenJDK
Amazon
{code}
> Along with JavaVersion, allow enforcement of the JavaVendor
> ---
>
> Key: MENFORCER-338
> URL: https://issues.apache.org/jira/browse/MENFORCER-338
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
>Reporter: Jeffrey Bennett
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.0.0-M4
>
>
> It would be useful to be able to ensure that a particular vendor JDK is being
> used. For example, I may need to confirm that we are using AdoptOpenJDK
> 1.8.0_232 and not Oracle JDK 1.8.0_232.
>
> I would assume that you would define a set of enums for the vendors - e.g.
> (OracleJDK, AdoptOpenJDK, JavaOpenJDK, and maybe a few others) so that it
> would look something like this to insure that either Adopt or Amazon JDK
> vendor was used.
> EDIT: implemented as below, to be in line with RequireOs
> {code:xml}
>
> Oracle Corporation
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEP-431) new options to control output from dependency:analyze(-only)
[ https://issues.apache.org/jira/browse/MDEP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160053#comment-17160053 ] Matt Nelson commented on MDEP-431: -- This doesn't appear to be fixed in the latest release[1] or in master[2]. [1] https://maven.apache.org/plugins/maven-dependency-plugin/analyze-only-mojo.html [2] https://github.com/apache/maven-dependency-plugin/blob/master/src/main/java/org/apache/maven/plugins/dependency/analyze/AbstractAnalyzeMojo.java > new options to control output from dependency:analyze(-only) > > > Key: MDEP-431 > URL: https://issues.apache.org/jira/browse/MDEP-431 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Affects Versions: 2.8 >Reporter: Robert Platt >Priority: Minor > Attachments: mdep.patch > > > Including dependency:analyze-only with failOnWarning into a build can be very > effective at catching dependency issues. However, it is pretty much > all-or-nothing at the moment. In the case of complex or legacy projects it > can be difficult to incorporate the plugin into the build. > This is a patch (see attached mdep.path) to version 2.8 to provide more > control over dependency analysis output, introducing three new configuration > options. In all cases, the default options provide the current plugin > behavior: > 1. warnUnusedDeclared (default true). Unused declared dependencies generate > a warning if this is true, otherwise it is just info. > 2. ignoreManagedUndeclared (default false). If true, then used undeclared > dependencies which are dependency managed are not reported in the warnings. > The reasoning behind this option is that used undeclared dependencies are > less likely to break a build in subtle ways if they are dependency managed, > since the version will not change without developer intervention. Turning > this option on focuses the analysis on compiling against unmanaged transitive > dependencies. > 3. preferManagedVersionOutput (default false). If true, when outputting XML, > versions are left unspecified for managed dependencies. This can be handy > when you aren't using ignoreManagedUndeclared but want to use managed > versions when fixing undeclared dependencies. > Finally, the wording for the output of unused declared dependencies has been > changed to 'Potentially unused declared dependencies found' because, as > documented, their are limitations to this detection process with the default > analyzer. This wording makes it clearer to developers without that working > knowledge. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCHANGES-340) Retrieve Jira user/password from settings.xml
[ https://issues.apache.org/jira/browse/MCHANGES-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148867#comment-17148867 ] Matt Nelson commented on MCHANGES-340: -- Put out a PR for this > https://github.com/apache/maven-changes-plugin/pull/18 > Retrieve Jira user/password from settings.xml > - > > Key: MCHANGES-340 > URL: https://issues.apache.org/jira/browse/MCHANGES-340 > Project: Maven Changes Plugin > Issue Type: New Feature > Components: jira >Reporter: Guillaume Boucherie >Priority: Major > Attachments: MCHANGES-340.patch > > > Add a mechanism to get jira credentials from settings.xml instead from pom > only. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MPMD-299) Change of default skipEmptyReport value breaks site:jar
[
https://issues.apache.org/jira/browse/MPMD-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17063659#comment-17063659
]
Matt Nelson commented on MPMD-299:
--
Reproduction > https://github.com/apache/maven-pmd-plugin/pull/17
> Change of default skipEmptyReport value breaks site:jar
> ---
>
> Key: MPMD-299
> URL: https://issues.apache.org/jira/browse/MPMD-299
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: CPD, PMD
>Affects Versions: 3.13.0
>Reporter: Matt Nelson
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Change of default skipEmptyReport value in MPMD-225 causes
> [site:jar|https://maven.apache.org/plugins/maven-site-plugin/jar-mojo.html]
> to be empty.
> Had to revert to the value to get site jars working again.
> {code:xml}
>
> org.apache.maven.plugins
> maven-pmd-plugin
> 3.13.0
>
> true
>
>
> {code}
> Working on getting a repro case against
> https://github.com/apache/maven-pmd-plugin
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MPMD-299) Change of default skipEmptyReport value breaks site:jar
Matt Nelson created MPMD-299:
Summary: Change of default skipEmptyReport value breaks site:jar
Key: MPMD-299
URL: https://issues.apache.org/jira/browse/MPMD-299
Project: Maven PMD Plugin
Issue Type: Bug
Components: CPD, PMD
Affects Versions: 3.13.0
Reporter: Matt Nelson
Change of default skipEmptyReport value in MPMD-225 causes
[site:jar|https://maven.apache.org/plugins/maven-site-plugin/jar-mojo.html] to
be empty.
Had to revert to the value to get site jars working again.
{code:xml}
org.apache.maven.plugins
maven-pmd-plugin
3.13.0
true
{code}
Working on getting a repro case against
https://github.com/apache/maven-pmd-plugin
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987160#comment-16987160
]
Matt Nelson commented on MNG-6772:
--
I would also like this fix. I do something very similar. I attempted to migrate
to a couple of import poms but relented when running into this issue, the value
provided to me by the repository overrides was greater than that of the import
pom.
Given the concern of changing the critical dependency resolution paths. Could
something like MNG-6056 or the alternative proposal in MNG-6656 via a
{{maven.experimental.MNG-6772}} be considered?
This is also related to the MNG-6656 umbrella of addressing the base/consumer
experience.
> Super POM overwrites remapped central repository in nested import POMs
> --
>
> Key: MNG-6772
> URL: https://issues.apache.org/jira/browse/MNG-6772
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, POM
>Affects Versions: 3.6.2
>Reporter: Eddie Wiegers
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} which is meant to
> specifically override the entry in the Super POM. This is specifically what
> [JFrog Artifactory
> recommends|https://www.jfrog.com/confluence/display/RTF/Maven+Repository#MavenRepository-ManuallyOverridingtheBuilt-inRepositories]
> doing, and seems valid in situations where the _real_ Maven Central may be
> unreachable.
>
> The override takes precedence almost all of the time. However, there is at
> least one scenario where this is not the case, and that is when importing a
> POM that in turn imports another POM.
>
> Digging into the code, it appears the reason this happens is because the
> {{DefaultModelBuilder}} overwrites repositories after interpolation is
> complete:
> [https://github.com/apache/maven/blob/53f04f03e3e58c75dcc791d557758357a6ec7983/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L411]
>
> From what I can tell, this is done with the intention of overwriting
> repositories that were added to the local resolver prior to interpolation
> with the interpolated version. Due to the way the {{DefaultModelResolver}}
> works, an unintended side effect is that the {{central}} repository from the
> Super POM is added once after each interpolation. The first time the
> repository is added, it is added to the {{repositoryIds}} but doesn't
> actually remove the original repository. The second time it is added is when
> the original repository will be replaced. Currently, the repositoryIds are
> preserved in the {{ModelResolver}} when resolving import POMs, leading to the
> behavior I am seeing where the second nested import POM ends up being where
> the failure occurs.
>
> I am planning on submitting a PR to clone the {{ModelResolver}} in a way that
> resets the repositoryIds prior to import POMs being resolved, since they are
> separate artifact builds. That seems like the most consistent fix to me that
> covers cases outside of the the Super POM's {{central}} definition.
>
> *Workarounds*:
> The current workaround is to use a repository ID other than {{central}} for
> my Artifactory repository, which isn't ideal since it leaves the potential
> for long timeouts to occur on the real {{central}} when an artifact can't be
> resolved from my Artifactory repository.
>
> Mirrors are not an ideal workaround since getting them in place on all
> possible build environments isn't trivial.
>
> When looking at the code I noticed
> {{RepositorySystemSession#isIgnoreArtifactDescriptorRepositories()}} being
> checked in various places, which seems like it would also act as a potential
> workaround, but I don't see a way to enable this value via MavenCLI or
> properties of any kind. It seems like this value aligns well with what
> Artifactory is already trying to enforce, so it would make sense to enable
> this in projects that intend to exclusively use Artifactory. Is there a
> supported way to set this value outside of constructing a Maven build in code?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6766) when i use maven 3.6.2 to replace idea default maven tool,it make error
[ https://issues.apache.org/jira/browse/MNG-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937232#comment-16937232 ] Matt Nelson commented on MNG-6766: -- Intellij has released an update with 3.6.2 support. https://blog.jetbrains.com/idea/2019/09/intellij-idea-2019-2-3-is-out/ > when i use maven 3.6.2 to replace idea default maven tool,it make error > --- > > Key: MNG-6766 > URL: https://issues.apache.org/jira/browse/MNG-6766 > Project: Maven > Issue Type: Bug >Affects Versions: 3.6.2 > Environment: idea community edition 2019.1.1 > Apache maven 3.6.2 >Reporter: xing zhangfan >Priority: Major > > # when i use maven 3.6.2 to replace idea default maven tool,it make error > the error is show me > 2019-09-16 11:17:03,172 [3662125] ERROR - #org.jetbrains.idea.maven - > IntelliJ IDEA 2019.1.1 Build #IC-191.6707.61 2019-09-16 11:17:03,172 > [3662125] ERROR - #org.jetbrains.idea.maven - IntelliJ IDEA 2019.1.1 > Build #IC-191.6707.61 2019-09-16 11:17:03,173 [3662126] ERROR - > #org.jetbrains.idea.maven - JDK: 1.8.0_202-release; VM: OpenJDK 64-Bit Server > VM; Vendor: JetBrains s.r.o 2019-09-16 11:17:03,173 [3662126] ERROR - > #org.jetbrains.idea.maven - OS: Windows 10 2019-09-16 11:17:03,177 [3662130] > ERROR - #org.jetbrains.idea.maven - Last Action: Maven.Reimport > 2019-09-16 11:17:03,747 [3662700] INFO - mponents.impl.stores.StoreUtil - > saveProjectsAndApp took 119 ms 2019-09-16 11:17:13,030 [3671983] INFO - > mponents.impl.stores.StoreUtil - saveProjectsAndApp took 40 ms 2019-09-16 > 11:17:52,141 [3711094] INFO - mponents.impl.stores.StoreUtil - > saveProjectsAndApp took 43 ms 2019-09-16 11:18:36,280 [3755233] INFO - > mponents.impl.stores.StoreUtil - saveProjectsAndApp took 55 ms 2019-09-16 > 11:18:42,547 [3761500] INFO - mponents.impl.stores.StoreUtil - > saveProjectsAndApp took 34 ms 2019-09-16 11:19:15,884 [3794837] INFO - > rationStore.ComponentStoreImpl - Saving Project > 'E:\work-repo\coocaa-tsp-load-data-station-service' > coocaa-tsp-load-data-station-serviceCompilerConfiguration took 16 ms > 2019-09-16 11:19:16,212 [3795165] INFO - ution.rmi.RemoteProcessSupport - > Terminating: 61054/Maven3ServerImpl87a98b1f 2019-09-16 11:19:16,842 [3795795] > INFO - stubs.SerializationManagerImpl - START StubSerializationManager > SHUTDOWN 2019-09-16 11:19:16,842 [3795795] INFO - > stubs.SerializationManagerImpl - END StubSerializationManager SHUTDOWN > 2019-09-16 11:19:16,842 [3795795] INFO - il.indexing.FileBasedIndexImpl - > START INDEX SHUTDOWN 2019-09-16 11:19:17,571 [3796524] INFO - > il.indexing.FileBasedIndexImpl - END INDEX SHUTDOWN 2019-09-16 11:19:17,634 > [3796587] INFO - org.jetbrains.io.BuiltInServer - web server stopped > 2019-09-16 11:19:17,634 [3796587] INFO - Types.impl.FileTypeManagerImpl - > FileTypeManager: 1031 auto-detected filesElapsed time on auto-detect: 1361 ms > 2019-09-16 11:19:17,665 [3796618] INFO - pl.local.NativeFileWatcherImpl - > Watcher terminated with exit code 0 2019-09-16 11:19:17,665 [3796618] INFO > - newvfs.persistent.PersistentFS - VFS dispose started 2019-09-16 > 11:19:17,681 [3796634] INFO - newvfs.persistent.PersistentFS - VFS dispose > completed 2019-09-16 11:19:17,681 [3796634] INFO - > #com.intellij.idea.Main - > -- IDE SHUTDOWN > -- 2019-09-16 > 11:19:17,681 [3796634] INFO - org.jetbrains.io.BuiltInServer - web server > stopped 2019-09-16 11:20:26,931 [ 0] INFO - > #com.intellij.idea.Main - > -- IDE STARTED > -- 2019-09-16 > 11:20:27,083 [ 152] INFO - #com.intellij.idea.Main - IDE: > IntelliJ IDEA (build #IC-191.6707.61, 16 Apr 2019 23:39) 2019-09-16 > 11:20:27,083 [ 152] INFO - #com.intellij.idea.Main - OS: Windows > 10 (10.0, amd64) 2019-09-16 11:20:27,083 [ 152] INFO - > #com.intellij.idea.Main - JRE: 1.8.0_202-release-1483-b44 (JetBrains s.r.o) > 2019-09-16 11:20:27,083 [ 152] INFO - #com.intellij.idea.Main - > JVM: 25.202-b44 (OpenJDK 64-Bit Server VM) 2019-09-16 11:20:27,095 [ 164] > INFO - #com.intellij.idea.Main - JVM Args: -Xms128m -Xmx750m > -XX:ReservedCodeCacheSize=240m -XX:+UseConcMarkSweepGC > -XX:SoftRefLRUPolicyMSPerMB=50 -ea -Dsun.io.useCanonCaches=false > -Djava.net.preferIPv4Stack=true -Djdk.http.auth.tunneling.disabledSchemes="" > -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow > -Djb.vmOptionsFile=D:\IntelliJ IDEA Community Edition > 2019.1.1\bin\idea64.exe.vmoptions -Didea.platform.prefix=Idea >
[jira] [Commented] (MNG-3655) Allow multiple local repositories
[
https://issues.apache.org/jira/browse/MNG-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937231#comment-16937231
]
Matt Nelson commented on MNG-3655:
--
{quote}
Of course one can write poms so that the version contains some classifier
{quote}
Isn't this one of the problems that CI friendly placeholders resolved?
https://maven.apache.org/maven-ci-friendly.html
{quote}
I am interested in splitting local cache of releases and snapshots
{quote}
Check this out > https://github.com/jcgay/maven-distinct-local-repository
> Allow multiple local repositories
> -
>
> Key: MNG-3655
> URL: https://issues.apache.org/jira/browse/MNG-3655
> Project: Maven
> Issue Type: New Feature
> Components: Reactor and workspace
>Reporter: Ittay Dror
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> In some environments, branches are rarely used. This means that if a
> developer wishes to work in parallel on two features, he checks out HEAD into
> two different locations. The problem is that using 'mvn install' in one
> checkout will overwrite the result of 'mvn install' in another. Of course one
> can write poms so that the version contains some classifier and then use 'mvn
> -Dartifact-classifier=first-checkout install', or, read from a file. Both are
> tedious.
> Instead, it would be good to be able to tell maven to first consider some
> path under the checkout before trying a global local repository (for external
> artifacts).
> To make this work when running mvn from a module subdir, maybe allow to write
> settings.xml in the root directory of the checkout. Then, maven should climb
> the directory structure until locating settings.xml (or reaching the global
> root directory) and read there. Using settings.xml in such a way has other
> benefits that it can be under version control. settings.xml will then be able
> to specify a list of local repositories, some absolute paths, some relative
> to it.
> Another approach could be to allow this list of local repositories in the
> global settings.xml file and have an entry in each module's pom indicating
> where it is relative to the local repository (like the parent path attribute)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JXR-143) New goals jxr-no-fork and test-jxr-no-fork which will not invoke generate-*-sources
[ https://issues.apache.org/jira/browse/JXR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872651#comment-16872651 ] Matt Nelson commented on JXR-143: - [~rfscholte] Pinging again, almost 4 months since the PR was merged. Would love to be able to use my contribution. > New goals jxr-no-fork and test-jxr-no-fork which will not invoke > generate-*-sources > --- > > Key: JXR-143 > URL: https://issues.apache.org/jira/browse/JXR-143 > Project: Maven JXR > Issue Type: Improvement > Components: jxr >Reporter: Matt Nelson >Assignee: Robert Scholte >Priority: Major > Fix For: 3.0.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Identical root issues as MJAVADOC-369 > Add new goals which do not fork the build when those phases have already > executed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MSITE-838) Include support for confluence/docbook/twiki by default
[ https://issues.apache.org/jira/browse/MSITE-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Nelson updated MSITE-838: -- Summary: Include support for confluence/docbook/twiki by default (was: Include doxia confluence module) > Include support for confluence/docbook/twiki by default > --- > > Key: MSITE-838 > URL: https://issues.apache.org/jira/browse/MSITE-838 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Reporter: Matt Nelson >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Include doxia confluence module (and possibly all the other modules) > https://github.com/apache/maven-doxia/tree/master/doxia-modules > https://github.com/apache/maven-site-plugin/blob/ab1962164c582db89e2e535d057ee7d7cee91705/pom.xml#L331-L365 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSITE-838) Include doxia confluence module
[
https://issues.apache.org/jira/browse/MSITE-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861294#comment-16861294
]
Matt Nelson commented on MSITE-838:
---
{quote}
This is probably just convience nothing else, isn't it?
{quote}
Yes exactly that, I had a request to add confluence site support to our company
POM. I grabbed the latest version 1.9 and started getting some errors because
the plugin was using 1.8 for all other doxia deps, but confluence was on 1.9.
So instead of having to keep in sync the doxia version of the plugin and the
added deps. It is easier to add all the automatically detectable parsers by
default.
> Include doxia confluence module
> ---
>
> Key: MSITE-838
> URL: https://issues.apache.org/jira/browse/MSITE-838
> Project: Maven Site Plugin
> Issue Type: Improvement
> Components: doxia integration
>Reporter: Matt Nelson
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Include doxia confluence module (and possibly all the other modules)
> https://github.com/apache/maven-doxia/tree/master/doxia-modules
> https://github.com/apache/maven-site-plugin/blob/ab1962164c582db89e2e535d057ee7d7cee91705/pom.xml#L331-L365
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSITE-838) Include doxia confluence module
[
https://issues.apache.org/jira/browse/MSITE-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861266#comment-16861266
]
Matt Nelson commented on MSITE-838:
---
{quote}
Will it work if the parsers are just added to the plugin's dep list on the POM?
{quote}
It should behave the same way markdown does today. I only added the parsers
that have a known expected source directory and/or file extension.
https://maven.apache.org/doxia/references/index.html
> Include doxia confluence module
> ---
>
> Key: MSITE-838
> URL: https://issues.apache.org/jira/browse/MSITE-838
> Project: Maven Site Plugin
> Issue Type: Improvement
> Components: doxia integration
>Reporter: Matt Nelson
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Include doxia confluence module (and possibly all the other modules)
> https://github.com/apache/maven-doxia/tree/master/doxia-modules
> https://github.com/apache/maven-site-plugin/blob/ab1962164c582db89e2e535d057ee7d7cee91705/pom.xml#L331-L365
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSITE-838) Include doxia confluence module
[
https://issues.apache.org/jira/browse/MSITE-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860375#comment-16860375
]
Matt Nelson commented on MSITE-838:
---
{quote}
Can you create a PR for this?
{quote}
Sure, would you like to restrict to confluence only, or add all the other
missing parsers?
{quote}
I read this as a request to be able to parse confluence pages (turning them
into html), not generate confluence pages.
{quote}
Yep this is what I meant. If a {{*.confluence}} file exists in {{src/site}} it
would be processed by the site plugin.
> Include doxia confluence module
> ---
>
> Key: MSITE-838
> URL: https://issues.apache.org/jira/browse/MSITE-838
> Project: Maven Site Plugin
> Issue Type: Improvement
> Components: doxia integration
>Reporter: Matt Nelson
>Priority: Major
>
> Include doxia confluence module (and possibly all the other modules)
> https://github.com/apache/maven-doxia/tree/master/doxia-modules
> https://github.com/apache/maven-site-plugin/blob/ab1962164c582db89e2e535d057ee7d7cee91705/pom.xml#L331-L365
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MSITE-838) Include doxia confluence module
[ https://issues.apache.org/jira/browse/MSITE-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Nelson updated MSITE-838: -- Component/s: doxia integration > Include doxia confluence module > --- > > Key: MSITE-838 > URL: https://issues.apache.org/jira/browse/MSITE-838 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Reporter: Matt Nelson >Priority: Major > > Include doxia confluence module (and possibly all the other modules) > https://github.com/apache/maven-doxia/tree/master/doxia-modules > https://github.com/apache/maven-site-plugin/blob/ab1962164c582db89e2e535d057ee7d7cee91705/pom.xml#L331-L365 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MSITE-838) Include doxia confluence module
Matt Nelson created MSITE-838: - Summary: Include doxia confluence module Key: MSITE-838 URL: https://issues.apache.org/jira/browse/MSITE-838 Project: Maven Site Plugin Issue Type: Improvement Reporter: Matt Nelson Include doxia confluence module (and possibly all the other modules) https://github.com/apache/maven-doxia/tree/master/doxia-modules https://github.com/apache/maven-site-plugin/blob/ab1962164c582db89e2e535d057ee7d7cee91705/pom.xml#L331-L365 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1525) Exception in a @BeforeClass method in a JUnit suite class does not fail the build if ran in parallel
[
https://issues.apache.org/jira/browse/SUREFIRE-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16836575#comment-16836575
]
Matt Nelson commented on SUREFIRE-1525:
---
Noticing the same issue with AfterClass.
> Exception in a @BeforeClass method in a JUnit suite class does not fail the
> build if ran in parallel
>
>
> Key: SUREFIRE-1525
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1525
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.21.0
>Reporter: Ivan Syarov
>Priority: Major
>
> I have a @BeforeClass annotated method in a JUnit test suite class, and if an
> exception is thrown in the method, the parallel build either succeeds if the
> *-DfailIfNoTests* parameter is set to false or fails with "No tests were
> executed" if the parameter is set to true. If the build is started without
> the *parallel* parameter it fails as it should.
> I used a simple project setup to reproduce. I have two test classes, each
> with one test method and a suite class:
> *TestA.class*
> {code:java}
> public class TestA {
> @Test
> public void test() {
> System.out.println("TestA");
> }
> }
> {code}
> *TestB.class*
> {code:java}
> public class TestB {
> @Test
> public void test() {
> System.out.println("TestB");
> }
> }
> {code}
> *TestSuite.class*
> {code:java}
> @RunWith(Suite.class)
> @SuiteClasses({TestA.class, TestB.class})
> public class TestSuite {
> @BeforeClass
> public static void setUp() {
> throw new RuntimeException("ex");
> }
> }
> {code}
> If i execute:
> mvn clean install -Dtest=TestSuite -Dparallel=classes -DthreadCount=2
> -DfailIfNoTests=false
> the build succeeds. If I omit the -DfailIfNoTests=false the build fails, but
> not because of the thrown exception, but with "No tests were executed!". If i
> omit the parallel parameter the build fails appropriately with "There are
> test failures."
> The JUnit version is 4.12
> The surefire plugin version is 2.19.1 - 2.21.0
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JXR-143) New goals jxr-no-fork and test-jxr-no-fork which will not invoke generate-*-sources
[ https://issues.apache.org/jira/browse/JXR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823597#comment-16823597 ] Matt Nelson commented on JXR-143: - [~rfscholte] Are there any other issues blocking a release? > New goals jxr-no-fork and test-jxr-no-fork which will not invoke > generate-*-sources > --- > > Key: JXR-143 > URL: https://issues.apache.org/jira/browse/JXR-143 > Project: Maven JXR > Issue Type: Improvement > Components: jxr >Reporter: Matt Nelson >Assignee: Robert Scholte >Priority: Major > Fix For: 3.0.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Identical root issues as MJAVADOC-369 > Add new goals which do not fork the build when those phases have already > executed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MCHANGES-397) Support sorting github issues
Matt Nelson created MCHANGES-397: Summary: Support sorting github issues Key: MCHANGES-397 URL: https://issues.apache.org/jira/browse/MCHANGES-397 Project: Maven Changes Plugin Issue Type: New Feature Components: github Reporter: Matt Nelson Support sorting github issues similar to the jira goal. http://maven.apache.org/plugins/maven-changes-plugin/jira-report-mojo.html#sortColumnNames -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MCHANGES-317) GitHub: "API rate limit exceeded"
[ https://issues.apache.org/jira/browse/MCHANGES-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805170#comment-16805170 ] Matt Nelson commented on MCHANGES-317: -- [~fedyafed] Can you try setting the oauth token as the password? https://developer.github.com/v3/auth/#via-oauth-tokens > GitHub: "API rate limit exceeded" > - > > Key: MCHANGES-317 > URL: https://issues.apache.org/jira/browse/MCHANGES-317 > Project: Maven Changes Plugin > Issue Type: Bug > Components: github >Affects Versions: 2.9 >Reporter: John Schneider >Priority: Major > > I tried to generate a report and got this message: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project > stax-mate: Error during page generation: Error rendering Maven report: API > rate limit exceeded for 149.###.###.##. See > http://developer.github.com/v3/#rate-limiting for details. (403) -> [Help 1] > I think this is caused by having a low limit for unauthenticated requests. I > think it would be great if there was a way to authenticate... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JXR-143) New goals jxr-no-fork and test-jxr-no-fork which will not invoke generate-*-sources
[ https://issues.apache.org/jira/browse/JXR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16758514#comment-16758514 ] Matt Nelson commented on JXR-143: - [~rfscholte] [~khmarbaise] Can you advise on the next steps I need to do in order to make progress on this issue? > New goals jxr-no-fork and test-jxr-no-fork which will not invoke > generate-*-sources > --- > > Key: JXR-143 > URL: https://issues.apache.org/jira/browse/JXR-143 > Project: Maven JXR > Issue Type: Improvement > Components: jxr >Reporter: Matt Nelson >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Identical root issues as MJAVADOC-369 > Add new goals which do not fork the build when those phases have already > executed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JXR-143) New goals jxr-no-fork and test-jxr-no-fork which will not invoke generate-*-sources
Matt Nelson created JXR-143: --- Summary: New goals jxr-no-fork and test-jxr-no-fork which will not invoke generate-*-sources Key: JXR-143 URL: https://issues.apache.org/jira/browse/JXR-143 Project: Maven JXR Issue Type: Improvement Components: jxr Reporter: Matt Nelson Identical root issues as MJAVADOC-369 Add new goals which do not fork the build when those phases have already executed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEPLOY-206) Support parallel deployment at end
[ https://issues.apache.org/jira/browse/MDEPLOY-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710537#comment-16710537 ] Matt Nelson commented on MDEPLOY-206: - Once I got into the implementation details of this plugin, I realized that MDEPLOY-204 is not a blocker. The parallelism is batched by project instead of by distinct upload request. As such the upload order per module is unchanged. > Support parallel deployment at end > -- > > Key: MDEPLOY-206 > URL: https://issues.apache.org/jira/browse/MDEPLOY-206 > Project: Maven Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy >Reporter: Matt Nelson >Priority: Major > > When deploying at end with a large reactor the deployment process can take > some time. If the DeployMojo was updated to support a configuration value for > the amount of parallelism the deployment could be speed up substantially. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6399) Lift JDK minimum to JDK 8
[
https://issues.apache.org/jira/browse/MNG-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16660998#comment-16660998
]
Matt Nelson commented on MNG-6399:
--
{quote}The deploy plugin problem has nothing to do with JDK 8 or not
{quote}
I provided that example to illustrate where some of the new language feature
would've made the implementation easier. I don't want to get off topic and
debate the details of the fix here.
I would like to stay focused on advocating for the JDK uplift or at a minimum
as [~nhoj.patrick] suggested a formalization of process of when Maven will be
uplifted
For reference, the current baseline of 7 was uplifted with
[3.3.1|https://maven.apache.org/docs/history.html] on {{2015-03-18}} which was
1 month before [7 was publicly end of
life|https://en.wikipedia.org/wiki/Java_version_history#Java_7_updates] on
{{2015-04-14}}
> Lift JDK minimum to JDK 8
> -
>
> Key: MNG-6399
> URL: https://issues.apache.org/jira/browse/MNG-6399
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.0
>Reporter: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 3.6.x-candidate
>
>
> I would like to lift the minimum of Maven Core to JDK 8 (I think it's time)..
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6399) Lift JDK minimum to JDK 8
[ https://issues.apache.org/jira/browse/MNG-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16660751#comment-16660751 ] Matt Nelson commented on MNG-6399: -- I was experimenting with the deploy plugin which I would not be in control of uplifting the baseline. This is under the assumption that the core plugins can not uplift the minimums before core. [https://github.com/mattnelson/maven-deploy-plugin/commit/fef2a4db1e30cfbf81a414317f5a678f1df3e84f] https://issues.apache.org/jira/browse/MDEPLOY-206 > Lift JDK minimum to JDK 8 > - > > Key: MNG-6399 > URL: https://issues.apache.org/jira/browse/MNG-6399 > Project: Maven > Issue Type: Task >Affects Versions: 3.6.0 >Reporter: Karl Heinz Marbaise >Priority: Critical > Fix For: 3.6.x-candidate > > > I would like to lift the minimum of Maven Core to JDK 8 (I think it's time).. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6399) Lift JDK minimum to JDK 8
[ https://issues.apache.org/jira/browse/MNG-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16659687#comment-16659687 ] Matt Nelson commented on MNG-6399: -- I would like to consider a JDK uplift from the larger maven ecosystem perspective, specifically for plugin developers. I think a barrier for contributions is going emerge by requiring the lowest common denominator compile targets. Java 8 introduced quite a few language features that can simplify plugin development(lambdas and streams). I just attempted to introduce a new feature on a plugin that took quite a few more lines and time to implement where a parallel stream would've reduced it to a handful of lines in a few minutes. > Lift JDK minimum to JDK 8 > - > > Key: MNG-6399 > URL: https://issues.apache.org/jira/browse/MNG-6399 > Project: Maven > Issue Type: Task >Affects Versions: 3.6.0 >Reporter: Karl Heinz Marbaise >Priority: Critical > Fix For: 3.6.x-candidate > > > I would like to lift the minimum of Maven Core to JDK 8 (I think it's time).. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MPIR-373) upgrade from 2.9 to 3.0.0 introduce additional warning issue
[
https://issues.apache.org/jira/browse/MPIR-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597950#comment-16597950
]
Matt Nelson commented on MPIR-373:
--
{quote}
How about only showing the details when run in debug-mode? A lot easier to
fix...
{quote}
[~rfscholte] Is this still the proposed solution? Can this issue be reopened?
Upon deeper inspection I am also seeing issues with private plugins that aren't
in central, which implies that this flow isn't using the pluginmgmt section for
resolution.
{noformat}
[INFO] Generating "Plugin Management" report ---
maven-project-info-reports-plugin:3.0.0:plugin-management
[INFO] Could not build project for: custom-company-plugin:Error resolving
project artifact: Failure to find com.company:custom-company-plugin:pom:1.1 in
https://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central has
elapsed or updates are forced for project
com.company:custom-company-plugin:pom:1.1
org.apache.maven.project.ProjectBuildingException: Error resolving project
artifact: Failure to find com.company:custom-company-plugin:pom:1.1 in
https://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central has
elapsed or updates are forced for project
com.company:custom-company-plugin:pom:1.1
at org.apache.maven.project.DefaultProjectBuilder.build
(DefaultProjectBuilder.java:315)
at org.apache.maven.project.DefaultProjectBuilder.build
(DefaultProjectBuilder.java:284)
at
org.apache.maven.report.projectinfo.PluginManagementReport$PluginManagementRenderer.renderSectionPluginManagement
(PluginManagementReport.java:206)
at
org.apache.maven.report.projectinfo.PluginManagementReport$PluginManagementRenderer.renderBody
(PluginManagementReport.java:171)
at org.apache.maven.reporting.AbstractMavenReportRenderer.render
(AbstractMavenReportRenderer.java:80)
at org.apache.maven.report.projectinfo.PluginManagementReport.executeReport
(PluginManagementReport.java:65)
{noformat}
> upgrade from 2.9 to 3.0.0 introduce additional warning issue
>
>
> Key: MPIR-373
> URL: https://issues.apache.org/jira/browse/MPIR-373
> Project: Maven Project Info Reports Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: GW Rogde
>Assignee: Michael Osipov
>Priority: Minor
> Attachments: pom.xml
>
>
> a new warning-message introduced, causing some confusion in the devteam.
> When stepping up to maven-project-info-reports-plugin:3.0.0 (from2.9) the
> stacktrace below is seen.
> mvn3.0.5, 3.3.9 and 3.5.2 all give same stacktrace.
> Seems to caused by the xml-resolver:1.2, having a pom.xml containing the
> section.
>
> {code:java}
>
> deployed
>
> {code}
> Is there some more restrictive pom validation introduced with
> maven-project-info-reports-plugin:3.0.0
> {code:java}
> $ mvn project-info-reports:dependencies
> [WARNING] Unable to create Maven project from repository for artifact
> xml-resolver:xml-resolver:jar:1.2
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [ERROR] 'distributionManagement.status' must not be specified. @ line 36,
> column 13
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:191)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:326)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository
> (RepositoryUtils.java:125)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDescriptionsAndURLs
> (DependenciesRenderer.java:890)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:847)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyTree
> (DependenciesRenderer.java:486)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionProjectDependencyGraph
> (DependenciesRenderer.java:449)
> at
>
[jira] [Commented] (MPIR-373) upgrade from 2.9 to 3.0.0 introduce additional warning issue
[
https://issues.apache.org/jira/browse/MPIR-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596902#comment-16596902
]
Matt Nelson commented on MPIR-373:
--
Seeing this issue with {{commons-httpclient-3.1}} as well.
[https://search.maven.org/classic/#artifactdetails%7Ccommons-httpclient%7Ccommons-httpclient%7C3.1%7Cjar]
{code:xml}
default
Default Site
scp://people.apache.org//www/jakarta.apache.org/httpcomponents/httpclient-3.x/
converted
{code}
> upgrade from 2.9 to 3.0.0 introduce additional warning issue
>
>
> Key: MPIR-373
> URL: https://issues.apache.org/jira/browse/MPIR-373
> Project: Maven Project Info Reports Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: GW Rogde
>Assignee: Michael Osipov
>Priority: Minor
> Attachments: pom.xml
>
>
> a new warning-message introduced, causing some confusion in the devteam.
> When stepping up to maven-project-info-reports-plugin:3.0.0 (from2.9) the
> stacktrace below is seen.
> mvn3.0.5, 3.3.9 and 3.5.2 all give same stacktrace.
> Seems to caused by the xml-resolver:1.2, having a pom.xml containing the
> section.
>
> {code:java}
>
> deployed
>
> {code}
> Is there some more restrictive pom validation introduced with
> maven-project-info-reports-plugin:3.0.0
> {code:java}
> $ mvn project-info-reports:dependencies
> [WARNING] Unable to create Maven project from repository for artifact
> xml-resolver:xml-resolver:jar:1.2
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [ERROR] 'distributionManagement.status' must not be specified. @ line 36,
> column 13
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:191)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:326)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository
> (RepositoryUtils.java:125)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDescriptionsAndURLs
> (DependenciesRenderer.java:890)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:847)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyTree
> (DependenciesRenderer.java:486)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionProjectDependencyGraph
> (DependenciesRenderer.java:449)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody
> (DependenciesRenderer.java:222)
> at org.apache.maven.reporting.AbstractMavenReportRenderer.render
> (AbstractMavenReportRenderer.java:80)
> at org.apache.maven.report.projectinfo.DependenciesReport.executeReport
> (DependenciesReport.java:162)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:251)
> at org.apache.maven.report.projectinfo.AbstractProjectInfoReport.execute
> (AbstractProjectInfoReport.java:220)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
> at
[jira] [Created] (MJAVADOC-534) Support element-list links from java10 dependencies
Matt Nelson created MJAVADOC-534:
Summary: Support element-list links from java10 dependencies
Key: MJAVADOC-534
URL: https://issues.apache.org/jira/browse/MJAVADOC-534
Project: Maven Javadoc Plugin
Issue Type: Improvement
Components: javadoc
Reporter: Matt Nelson
Java 10+ produces[1,2,3] {{element-list}} instead of {{package-list}} files.
The plugin assumes[4,5] {{package-list}} is quite a few places.
[1] https://bugs.openjdk.java.net/browse/JDK-8191363
[2]
https://docs.oracle.com/javase/10/tools/javadoc.htm#GUID-9D532574-1CDB-4D30-99F3-A308DCAEE55F__GUID-29EABEE0-310E-4131-9577-8B2CE569992A
[3]
https://stackoverflow.com/questions/49457896/cant-link-to-jdk10-in-javadoc-comments
[4]
https://github.com/apache/maven-javadoc-plugin/blob/maven-javadoc-plugin-3.0.1/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java
[5 ]
https://github.com/apache/maven-javadoc-plugin/search?utf8=%E2%9C%93=package-list
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MPMD-255) Handle missing analysisCacheLocation file
Matt Nelson created MPMD-255:
Summary: Handle missing analysisCacheLocation file
Key: MPMD-255
URL: https://issues.apache.org/jira/browse/MPMD-255
Project: Maven PMD Plugin
Issue Type: Improvement
Components: PMD
Reporter: Matt Nelson
When the {{analysisCacheLocation}} file is missing the error is not clear it is
the reason for the failure. Can a more descriptive message be added? Or log a
warning and proceed to build without the cache.
{noformat}
Caused by: java.io.FileNotFoundException: my-project\target\classes (The system
cannot find the file specified)
at java.io.FileInputStream.open0 (Native Method)
at java.io.FileInputStream.open (FileInputStream.java:195)
at java.io.FileInputStream. (FileInputStream.java:138)
at java.io.FileInputStream. (FileInputStream.java:93)
at sun.net.www.protocol.file.FileURLConnection.connect
(FileURLConnection.java:90)
at sun.net.www.protocol.file.FileURLConnection.getInputStream
(FileURLConnection.java:188)
at java.net.URL.openStream (URL.java:1045)
at net.sourceforge.pmd.cache.AbstractAnalysisCache.computeClassPathHash
(AbstractAnalysisCache.java:182)
at net.sourceforge.pmd.cache.AbstractAnalysisCache.checkValidity
(AbstractAnalysisCache.java:113)
at net.sourceforge.pmd.processor.AbstractPMDProcessor.processFiles
(AbstractPMDProcessor.java:105)
at net.sourceforge.pmd.PMD.processFiles (PMD.java:311)
at org.apache.maven.plugins.pmd.PmdReport.processFilesWithPMD
(PmdReport.java:503)
at org.apache.maven.plugins.pmd.PmdReport.executePmd (PmdReport.java:432)
at org.apache.maven.plugins.pmd.PmdReport.executePmdWithClassloader
(PmdReport.java:331)
at org.apache.maven.plugins.pmd.PmdReport.canGenerateReport
(PmdReport.java:305)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-427) "Error fetching URL" for valid non-Java API links
[
https://issues.apache.org/jira/browse/MJAVADOC-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371975#comment-16371975
]
Matt Nelson commented on MJAVADOC-427:
--
Logged MJAVADOC-487 for this same issue.
Can JavadocUtil[1] and AbstractJavadocMojo[2] be enhanced to handle the
redirect before handing the URI off to the javadoc tool?
[1]
https://github.com/apache/maven-javadoc-plugin/blob/12dbbde29cf6277ca311cb8afffdf02dbfe0c9b4/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1789
[2]
https://github.com/apache/maven-javadoc-plugin/blob/12dbbde29cf6277ca311cb8afffdf02dbfe0c9b4/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5883
> "Error fetching URL" for valid non-Java API links
> -
>
> Key: MJAVADOC-427
> URL: https://issues.apache.org/jira/browse/MJAVADOC-427
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.10.3
> Environment: Windows 7
> Apache Maven 3.2.1
> java version "1.8.0_05"
> Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
>Reporter: Selena Renee Phillips
>Priority: Major
> Attachments: testcase-detectLinks-enabled-no-manual-link-config.zip,
> testcase-detectLinks-enabled-with-manual-link-config-no-trailing-slash.zip,
> testcase-detectLinks-enabled-with-manual-link-config-trailing-slash.zip,
> testcases-detectLinks-disabled-with-manual-link-config-no-trailing-slash.zip,
> testcases-detectLinks-disabled-with-manual-link-config-trailing-slash.zip
>
>
> When I generate Javadoc for a simple project with 3rd party dependencies, no
> configuration generates links for these dependencies. For valid Javadoc links
> which have a package-list, I get the following error:
> [WARNING] javadoc: warning - Error fetching URL
> Test Cases w/ results (sample project(s)) attached:
> *1. No manual link configuration. 'detectLinks' is set to true.*
> {code:title=pom.xml - No manual link configuration with
> detectLinks=true|borderStyle=solid}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
>
> ${project.basedir}/target
> javadoc
> Epiphany
> Epiphany
> private
> true
> true
> true
> true
>
>
>
>
> javadoc
> test-javadoc
>
>
>
>
> {code}
> Output of 'mvn javadoc:javadoc':
> {code:title=Resulting output for mvn javadoc:javadoc - No manual link
> configuration with detectLinks=true|borderStyle=solid}
> [INFO] Scanning for projects...
> [INFO]
> [INFO] Using the builder
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder
> with a thread count of 1
> [INFO]
> [INFO]
>
> [INFO] Building epiphany 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] >>> maven-javadoc-plugin:2.10.3:javadoc (default-cli) @ epiphany >>>
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.10.3:javadoc (default-cli) @ epiphany <<<
> SNIP DOWNLOADING INFO.
> [INFO]
> [INFO] --- maven-javadoc-plugin:2.10.3:javadoc (default-cli) @ epiphany ---
> [ERROR] Error fetching link:
> http://selenium.googlecode.com/selenium-java/apidocs/package-list. Ignored it.
> [ERROR] Error fetching link:
> http://selenium.googlecode.com/selenium-api/apidocs/package-list. Ignored it.
> [ERROR] Error fetching link:
> http://selenium.googlecode.com/selenium-support/apidocs/package-list. Ignored
> it.
> [ERROR] Error fetching link:
> http://code.google.com/p/guava-libraries/guava/apidocs/package-list. Ignored
> it.
> [ERROR] Error fetching link:
> http://logback.qos.ch/logback-core/apidocs/package-list. Ignored it.
> [ERROR] Error fetching link:
> http://logback.qos.ch/logback-classic/apidocs/package-list. Ignored it.
> [ERROR] Error fetching link: http://testng.org/apidocs/package-list. Ignored
> it.
> [INFO]
> Loading source files for package com.example...
> Constructing Javadoc information...
> Standard Doclet version 1.8.0_05
> Building tree for all the packages and classes...
> Generating
> C:\Users\sephilli\git\javadoc-bug\target\javadoc\com\example\AbstractLoadable.html...
> .SNIP
> 1 warning
> [WARNING] Javadoc Warnings
> [WARNING] javadoc: warning - Error fetching URL: http://www.slf4j.org/apidocs
> [INFO]
>
[jira] [Commented] (MENFORCER-249) "Require Release Dependencies" rule doesn't fail when using a plugin with a SNAPSHOT version
[ https://issues.apache.org/jira/browse/MENFORCER-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16359159#comment-16359159 ] Matt Nelson commented on MENFORCER-249: --- This is already supported. https://maven.apache.org/enforcer/enforcer-rules/requirePluginVersions.html > "Require Release Dependencies" rule doesn't fail when using a plugin with a > SNAPSHOT version > > > Key: MENFORCER-249 > URL: https://issues.apache.org/jira/browse/MENFORCER-249 > Project: Maven Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Affects Versions: 1.4.1 >Reporter: Jean-François Lecomte >Priority: Major > > We are developing our own Maven plugins in my company, so we use SNAPSHOT > versions for these plugins while we are developing them. > Last time we released a version of an artifact that uses this plugin, we > accidentally forgot to release the maven plugin first. > I would expect the "Require Release Dependencies" to fail in such situation > or have another Standard Rule to prevent that... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (WAGON-486) Wagon fails to download artifacts if number of dropped pooled connections (by intermediate) are greater than default retry count
[ https://issues.apache.org/jira/browse/WAGON-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291523#comment-16291523 ] Matt Nelson commented on WAGON-486: --- [~michael-o] I thought it was a similar issue based on a large percentage of the stack trace being down the same path. Discovered after some more troubleshooting that it was actually MRESOLVER-25 since I was able to fix the stuck build with the proposed workaround. > Wagon fails to download artifacts if number of dropped pooled connections (by > intermediate) are greater than default retry count > > > Key: WAGON-486 > URL: https://issues.apache.org/jira/browse/WAGON-486 > Project: Maven Wagon > Issue Type: Bug >Reporter: Martin Myslík > Attachments: build-failure-maven-3.5.0-patched-debug-updated.txt, > build-failure-maven-3.5.0-patched-debug.txt, build-failure-vanilla.txt, > build-success-keep-alive-false.txt, > build-success-maven-3.5.0-patched-debug.txt, build-success-pooling-false.txt, > dump-failed-build.pcap, dump.pcap > > > I was recently discussing and issue with Atlassian team concerning failing > build on Atlassian Pipelines when running Maven build for more than 5 minutes. > The issue was with NAT timeout which kills all idle connections after 5 > mintues and Maven does not try to reconnect once the connection is killed > (and hence cannot download artifacts from Maven central). > Please, take a look at the open issue (it contains more detailed description > and also comments from Atlassian which suggested opening an issue with > Maven): > https://bitbucket.org/site/master/issues/13988/pipelines-kills-idle-maven-connections > Could you, please, take a minute and explain how could proceed with solving > this issue? I am not sure whether this is something that Maven should handle > or whether it is Atlassians issue. > Thank you for your input. > This is the link to my public repo with test project running tests for 15 > mintues. This build fails on Pipelines because of Maven connection that is > being killed during the test: https://bitbucket.org/Smedzlatko/del-me -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WAGON-486) Wagon fails to download artifacts if number of dropped pooled connections (by intermediate) are greater than default retry count
[ https://issues.apache.org/jira/browse/WAGON-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286848#comment-16286848 ] Matt Nelson commented on WAGON-486: --- Jumped the gun on this one a little bit, turns out the root cause was actually MRESOLVER-25 > Wagon fails to download artifacts if number of dropped pooled connections (by > intermediate) are greater than default retry count > > > Key: WAGON-486 > URL: https://issues.apache.org/jira/browse/WAGON-486 > Project: Maven Wagon > Issue Type: Bug >Reporter: Martin Myslík > Attachments: build-failure-maven-3.5.0-patched-debug-updated.txt, > build-failure-maven-3.5.0-patched-debug.txt, build-failure-vanilla.txt, > build-success-keep-alive-false.txt, > build-success-maven-3.5.0-patched-debug.txt, build-success-pooling-false.txt, > dump-failed-build.pcap, dump.pcap > > > I was recently discussing and issue with Atlassian team concerning failing > build on Atlassian Pipelines when running Maven build for more than 5 minutes. > The issue was with NAT timeout which kills all idle connections after 5 > mintues and Maven does not try to reconnect once the connection is killed > (and hence cannot download artifacts from Maven central). > Please, take a look at the open issue (it contains more detailed description > and also comments from Atlassian which suggested opening an issue with > Maven): > https://bitbucket.org/site/master/issues/13988/pipelines-kills-idle-maven-connections > Could you, please, take a minute and explain how could proceed with solving > this issue? I am not sure whether this is something that Maven should handle > or whether it is Atlassians issue. > Thank you for your input. > This is the link to my public repo with test project running tests for 15 > mintues. This build fails on Pipelines because of Maven connection that is > being killed during the test: https://bitbucket.org/Smedzlatko/del-me -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WAGON-486) Wagon fails to download artifacts if number of dropped pooled connections (by intermediate) are greater than default retry count
[
https://issues.apache.org/jira/browse/WAGON-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286681#comment-16286681
]
Matt Nelson commented on WAGON-486:
---
I believe I am running into a similar issue. The stack trace is slightly
different because I got it via executing jstack on the hung process. Has there
been any additional progress with integrating the changes [~michael-o] proposed?
{noformat}
"BuilderThread 1" #31 prio=5 os_prio=0 tid=0x7fe198b99800 nid=0x2cce
runnable [0x7fe193606000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
at sun.security.ssl.InputRecord.read(InputRecord.java:503)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
- locked <0xc74f25a0> (a java.lang.Object)
at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:940)
at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)
- locked <0xc74f2178> (a sun.security.ssl.AppInputStream)
at
org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:139)
at
org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:155)
at
org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:284)
at
org.apache.maven.wagon.providers.http.httpclient.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
at
org.apache.maven.wagon.providers.http.httpclient.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at
org.apache.maven.wagon.providers.http.httpclient.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
at
org.apache.maven.wagon.providers.http.httpclient.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
at
org.apache.maven.wagon.providers.http.httpclient.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
at
org.apache.maven.wagon.providers.http.httpclient.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
at
org.apache.maven.wagon.providers.http.httpclient.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
at
org.apache.maven.wagon.providers.http.httpclient.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
at
org.apache.maven.wagon.providers.http.httpclient.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at
org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec.execute(RetryExec.java:88)
at
org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at
org.apache.maven.wagon.providers.http.httpclient.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at
org.apache.maven.wagon.providers.http.httpclient.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at
org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.execute(AbstractHttpClientWagon.java:834)
at
org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.fillInputData(AbstractHttpClientWagon.java:985)
at
org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.fillInputData(AbstractHttpClientWagon.java:962)
at
org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:126)
at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88)
at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61)
at
org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run(WagonTransporter.java:567)
at
org.eclipse.aether.transport.wagon.WagonTransporter.execute(WagonTransporter.java:435)
at
org.eclipse.aether.transport.wagon.WagonTransporter.get(WagonTransporter.java:412)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:453)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:360)
at
org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:75)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:583)
at
[jira] [Created] (MRESOLVER-32) Support parallel artifact/metadata uploads
Matt Nelson created MRESOLVER-32:
Summary: Support parallel artifact/metadata uploads
Key: MRESOLVER-32
URL: https://issues.apache.org/jira/browse/MRESOLVER-32
Project: Maven Resolver
Issue Type: Improvement
Reporter: Matt Nelson
When using the {{maven-deploy-plugin}} with the {{deployAtEnd}} property on a
large reactor the deployment process can take a considerable amount of time. I
have a large reactor(50+ modules) where the upload takes 50% of the build time,
10 out of 20 minutes solely on the upload.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MJDEPS-9) Introduce failOnWarning as a named property
Matt Nelson created MJDEPS-9:
Summary: Introduce failOnWarning as a named property
Key: MJDEPS-9
URL: https://issues.apache.org/jira/browse/MJDEPS-9
Project: MJDEPS
Issue Type: New Feature
Reporter: Matt Nelson
Priority: Minor
Introduce {{jdeps.failOnWarning}} named property to support command line and
{{}} declarations.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6240) Duplicate components in plugin extension realm when plugin depends on maven-aether-resolver
[
https://issues.apache.org/jira/browse/MNG-6240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16154254#comment-16154254
]
Matt Nelson commented on MNG-6240:
--
Bouncing this again...
[~rfscholte]
When is the 3.5.1 release planned? This is a serious regression with the latest
major version which has been fixed for almost 3 months and still not released.
> Duplicate components in plugin extension realm when plugin depends on
> maven-aether-resolver
> ---
>
> Key: MNG-6240
> URL: https://issues.apache.org/jira/browse/MNG-6240
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.5.0
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
> Fix For: 3.5.1
>
>
> When a plugin extension has a dependency on {{maven-aether-resolver}}, the
> components of this artifact are added into the plugin realm even though Maven
> Core already provides them. This is a regression introduced by the rename of
> this module to {{maven-resolver-provider}} in 3.5.0.
> This rename has kept all the classes of {{maven-aether-resolver}} for
> compatibility, therefore the old artifact name also needs to be exported by
> Maven Core in {{extension.xml}}.
> A visible side-effect of this is MDEPLOY-221, where the two
> {{MetadataGeneratorFactory}} components of {{maven-aether-provider}} (which
> are {{SnapshotMetadataGeneratorFactory}} and
> {{VersionsMetadataGeneratorFactory}}) are present twice as Guice bindings,
> and wrong metadata information is deployed as a consequence. This is due to
> the Flex Mojos plugin extension which depends on {{maven-aether-resolver}}
> used in the build.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MINSTALL-134) Remove checksum generation
[ https://issues.apache.org/jira/browse/MINSTALL-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120843#comment-16120843 ] Matt Nelson commented on MINSTALL-134: -- This issue contradicts MINSTALL-82 where it says that sha256 support could be added in 3.0.0 where as this issue wants to remove checksum generation. > Remove checksum generation > -- > > Key: MINSTALL-134 > URL: https://issues.apache.org/jira/browse/MINSTALL-134 > Project: Maven Install Plugin > Issue Type: Improvement >Affects Versions: 2.5.2 >Reporter: Robert Scholte >Assignee: Robert Scholte > Fix For: 3.0.0 > > > Checksum doesn't make sense for install to local repository. It should be > part of the deployments of artifacts. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MSHARED-650) Fire ExecutionEvent from DefaultMavenReportExecutor
Matt Nelson created MSHARED-650:
---
Summary: Fire ExecutionEvent from DefaultMavenReportExecutor
Key: MSHARED-650
URL: https://issues.apache.org/jira/browse/MSHARED-650
Project: Maven Shared Components
Issue Type: New Feature
Components: maven-reporting-exec
Reporter: Matt Nelson
The event spy features added currently only support plugin mojos. When building
site all the report mojos are grouped together under the site plugin and do not
enable the ability to profile the site and find slow mojos. I dug through the
code and it appears that the {{DefaultMavenReportExecutor}}[1] could be
instrumented with the Catapult to fire events for each report mojo that the
{{EventSpy}}[2] can handle.
[1]
https://github.com/apache/maven-shared/blob/maven-reporting-exec-1.3/src/main/java/org/apache/maven/reporting/exec/DefaultMavenReportExecutor.java
[2]
https://github.com/apache/maven/blob/maven-3.5.0/maven-core/src/main/java/org/apache/maven/eventspy/EventSpy.java
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJAVADOC-387) Handle JDK8 -Xdoclint
[
https://issues.apache.org/jira/browse/MJAVADOC-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16098984#comment-16098984
]
Matt Nelson commented on MJAVADOC-387:
--
Just came across this since the milestone was released this week. Should the
user property be name spaced to the plugin context? {{maven.javadoc.doclint}}
vs {{doclint}}. Name spaced user properties make it clearer to understand the
intent when defined via command line or the properties block away from the
actual plugin block.
> Handle JDK8 -Xdoclint
> -
>
> Key: MJAVADOC-387
> URL: https://issues.apache.org/jira/browse/MJAVADOC-387
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: scolebourne2
>Assignee: Michael Osipov
> Fix For: 3.0.0, 3.0.0-M1
>
>
> The Oracle team have added the doclint tool to JDK 8. The tool validates
> Javadoc as part of a standard Javadoc run. Unfortunately, with the default
> settings, it rejects many HTML elements that are perfectly acceptable to
> browsers, and all invalid Javadoc references (@links). This is likely to
> prove very unpopular with developers.
> Action needed:
> 1) Provide a maven-javadoc-plugin configuration item and property that can
> control the doclint tool (currently this requires using additionalparam
> AFAICT).
> 2) Apply the {{-Xdoclint:none}} option by default, so that doclint is opt-in,
> not opt-out (ie. fix Oracle's messed up default). This will also make it much
> easier for developers to handle migration to JDK 8.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6240) Duplicate components in plugin extension realm when plugin depends on maven-aether-resolver
[
https://issues.apache.org/jira/browse/MNG-6240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16096909#comment-16096909
]
Matt Nelson commented on MNG-6240:
--
Could the 3.5.1 fix version be updated with a projected release date?
https://issues.apache.org/jira/projects/MNG/versions/12338964
> Duplicate components in plugin extension realm when plugin depends on
> maven-aether-resolver
> ---
>
> Key: MNG-6240
> URL: https://issues.apache.org/jira/browse/MNG-6240
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.5.0
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
> Fix For: 3.5.1
>
>
> When a plugin extension has a dependency on {{maven-aether-resolver}}, the
> components of this artifact are added into the plugin realm even though Maven
> Core already provides them. This is a regression introduced by the rename of
> this module to {{maven-resolver-provider}} in 3.5.0.
> This rename has kept all the classes of {{maven-aether-resolver}} for
> compatibility, therefore the old artifact name also needs to be exported by
> Maven Core in {{extension.xml}}.
> A visible side-effect of this is MDEPLOY-221, where the two
> {{MetadataGeneratorFactory}} components of {{maven-aether-provider}} (which
> are {{SnapshotMetadataGeneratorFactory}} and
> {{VersionsMetadataGeneratorFactory}}) are present twice as Guice bindings,
> and wrong metadata information is deployed as a consequence. This is due to
> the Flex Mojos plugin extension which depends on {{maven-aether-resolver}}
> used in the build.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MCHECKSTYLE-340) Migrate plugin to Maven 3.0
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Nelson closed MCHECKSTYLE-340. --- Resolution: Fixed Was trying to clone issue to address the same error with pmd. Will log a new issue instead of cloning > Migrate plugin to Maven 3.0 > --- > > Key: MCHECKSTYLE-340 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-340 > Project: Maven Checkstyle Plugin > Issue Type: Improvement >Affects Versions: 2.17 >Reporter: Matt Nelson >Assignee: Guillaume Boué > Fix For: 3.0.0 > > > Migrate the plugin to Maven 3.0 as described in > https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MCHECKSTYLE-340) Migrate plugin to Maven 3.0
Matt Nelson created MCHECKSTYLE-340: --- Summary: Migrate plugin to Maven 3.0 Key: MCHECKSTYLE-340 URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-340 Project: Maven Checkstyle Plugin Issue Type: Improvement Affects Versions: 2.17 Reporter: Matt Nelson Assignee: Guillaume Boué Fix For: 3.0.0 Migrate the plugin to Maven 3.0 as described in https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MPMD-240) Migrate plugin to Maven 3.0
[
https://issues.apache.org/jira/browse/MPMD-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080528#comment-16080528
]
Matt Nelson commented on MPMD-240:
--
I haven't been able to reproduce with 3.5 which I think it because of the
maven-core extension reservations on org.slf4j.*
http://maven.apache.org/ref/3.5.0/maven-core/core-extensions.html
{noformat}
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd (pmd) on project my-project:
Execution pmd of goal org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd failed:
An API incompatibility was encountered while executing
org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd:
java.lang.IncompatibleClassChangeError: org.slf4j.MDC and
org.slf4j.MDC$MDCCloseable disagree on InnerClasses attribute
[ERROR] -
[ERROR] realm =plugin>org.apache.maven.plugins:maven-pmd-plugin:3.8
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] =
file:/Users/myuser/.m2/repository/org/apache/maven/plugins/maven-pmd-plugin/3.8/maven-pmd-plugin-3.8.jar
[ERROR] urls[1] =
file:/Users/myuser/.m2/repository/net/sourceforge/pmd/pmd-core/5.8.1/pmd-core-5.8.1.jar
[ERROR] urls[2] =
file:/Users/myuser/.m2/repository/com/beust/jcommander/1.48/jcommander-1.48.jar
[ERROR] urls[3] =
file:/Users/myuser/.m2/repository/jaxen/jaxen/1.1.6/jaxen-1.1.6.jar
[ERROR] urls[4] =
file:/Users/myuser/.m2/repository/net/java/dev/javacc/javacc/5.0/javacc-5.0.jar
[ERROR] urls[5] =
file:/Users/myuser/.m2/repository/net/sourceforge/saxon/saxon/9.1.0.8/saxon-9.1.0.8.jar
[ERROR] urls[6] =
file:/Users/myuser/.m2/repository/org/apache/commons/commons-lang3/3.4/commons-lang3-3.4.jar
[ERROR] urls[7] =
file:/Users/myuser/.m2/repository/org/ow2/asm/asm/5.0.4/asm-5.0.4.jar
[ERROR] urls[8] =
file:/Users/myuser/.m2/repository/com/google/code/gson/gson/2.5/gson-2.5.jar
[ERROR] urls[9] =
file:/Users/myuser/.m2/repository/net/sourceforge/saxon/saxon/9.1.0.8/saxon-9.1.0.8-dom.jar
[ERROR] urls[10] =
file:/Users/myuser/.m2/repository/net/sourceforge/pmd/pmd-java/5.8.1/pmd-java-5.8.1.jar
[ERROR] urls[11] =
file:/Users/myuser/.m2/repository/net/sourceforge/pmd/pmd-javascript/5.8.1/pmd-javascript-5.8.1.jar
[ERROR] urls[12] =
file:/Users/myuser/.m2/repository/org/mozilla/rhino/1.7.7/rhino-1.7.7.jar
[ERROR] urls[13] =
file:/Users/myuser/.m2/repository/net/sourceforge/pmd/pmd-jsp/5.8.1/pmd-jsp-5.8.1.jar
[ERROR] urls[14] =
file:/Users/myuser/.m2/repository/org/slf4j/jcl-over-slf4j/1.7.5/jcl-over-slf4j-1.7.5.jar
[ERROR] urls[15] =
file:/Users/myuser/.m2/repository/org/slf4j/slf4j-jdk14/1.7.5/slf4j-jdk14-1.7.5.jar
[ERROR] urls[16] =
file:/Users/myuser/.m2/repository/org/slf4j/slf4j-nop/1.7.5/slf4j-nop-1.7.5.jar
[ERROR] urls[17] =
file:/Users/myuser/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
[ERROR] urls[18] =
file:/Users/myuser/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
[ERROR] urls[19] =
file:/Users/myuser/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
[ERROR] urls[20] =
file:/Users/myuser/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.4/doxia-sink-api-1.4.jar
[ERROR] urls[21] =
file:/Users/myuser/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.4/doxia-logging-api-1.4.jar
[ERROR] urls[22] =
file:/Users/myuser/.m2/repository/org/apache/maven/doxia/doxia-decoration-model/1.4/doxia-decoration-model-1.4.jar
[ERROR] urls[23] =
file:/Users/myuser/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.6/plexus-component-annotations-1.6.jar
[ERROR] urls[24] =
file:/Users/myuser/.m2/repository/org/apache/maven/doxia/doxia-site-renderer/1.4/doxia-site-renderer-1.4.jar
[ERROR] urls[25] =
file:/Users/myuser/.m2/repository/org/apache/maven/doxia/doxia-core/1.4/doxia-core-1.4.jar
[ERROR] urls[26] =
file:/Users/myuser/.m2/repository/xerces/xercesImpl/2.9.1/xercesImpl-2.9.1.jar
[ERROR] urls[27] =
file:/Users/myuser/.m2/repository/xml-apis/xml-apis/1.3.04/xml-apis-1.3.04.jar
[ERROR] urls[28] =
file:/Users/myuser/.m2/repository/commons-lang/commons-lang/2.4/commons-lang-2.4.jar
[ERROR] urls[29] =
file:/Users/myuser/.m2/repository/org/apache/maven/doxia/doxia-module-xhtml/1.4/doxia-module-xhtml-1.4.jar
[ERROR] urls[30] =
file:/Users/myuser/.m2/repository/org/apache/maven/doxia/doxia-module-fml/1.4/doxia-module-fml-1.4.jar
[ERROR] urls[31] =
file:/Users/myuser/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-7/plexus-i18n-1.0-beta-7.jar
[ERROR] urls[32] =
file:/Users/myuser/.m2/repository/org/codehaus/plexus/plexus-velocity/1.1.7/plexus-velocity-1.1.7.jar
[ERROR] urls[33] =
file:/Users/myuser/.m2/repository/org/apache/velocity/velocity/1.5/velocity-1.5.jar
[ERROR] urls[34] =
[jira] [Created] (MPMD-240) Migrate plugin to Maven 3.0
Matt Nelson created MPMD-240: Summary: Migrate plugin to Maven 3.0 Key: MPMD-240 URL: https://issues.apache.org/jira/browse/MPMD-240 Project: Maven PMD Plugin Issue Type: Bug Components: PMD Affects Versions: 3.8 Reporter: Matt Nelson Cloning from MCHECKSTYLE-335 to address the same slf4j issues based on the old maven-core-2.2.1 dependencies. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MJAVADOC-487) Follow redirects
Matt Nelson created MJAVADOC-487:
Summary: Follow redirects
Key: MJAVADOC-487
URL: https://issues.apache.org/jira/browse/MJAVADOC-487
Project: Maven Javadoc Plugin
Issue Type: Improvement
Reporter: Matt Nelson
The javadoc plugin should have the ability to follow redirects.
{noformat}
[WARNING] Error fetching link: http://www.slf4j.org/apidocs/package-list.
Ignored it.
{noformat}
When looking at this link via curl we can see that the link has new location
{noformat}
curl -v http://www.slf4j.org/apidocs/package-list
< HTTP/1.1 302 Found
< Location: https://www.slf4j.org/apidocs/package-list
{noformat}
https://github.com/apache/maven-plugins/blob/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java#L5785
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MDEPLOY-206) Support parallel deployment at end
[
https://issues.apache.org/jira/browse/MDEPLOY-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16013176#comment-16013176
]
Matt Nelson commented on MDEPLOY-206:
-
How is the scope of this issue changed with the maven-3.5.0 conversion to
maven-resolver?
I am using parallel builds with the {{deployAtEnd}} flag on a reactor with 40+
modules. Holding onto all the artifacts until the end there is a huge backlog
of IO operations that are taking 33% of the build time. Some of that time could
be attributed to the resources on the repository, but there is a huge potential
for decreased build times by performing the uploads with any amount of
parallelism. For each module there are 6 uploads and 1 download. The
{{/maven-metadata.xml}} appears to be uploaded twice
{noformat}
15:25:19 [INFO] Uploaded:
http://repo/com/company/project/my-artifact/0.15-SNAPSHOT/my-artifact-0.15-20170516.202515-32.jar
(30689 KB at 7579.2 KB/sec)
15:25:21 [INFO] Uploaded:
http://repo/com/company/project/my-artifact/0.15-SNAPSHOT/my-artifact-0.15-20170516.202515-32.pom
(10 KB at 5.7 KB/sec)
15:25:21 [INFO] Downloaded:
http://repo/com/company/project/my-artifact/maven-metadata.xml (420 B at 3.5
KB/sec)
15:25:22 [INFO] Uploaded:
http://repo/com/company/project/my-artifact/0.15-SNAPSHOT/maven-metadata.xml
(988 B at 1.4 KB/sec)
15:25:24 [INFO] Uploaded:
http://repo/com/company/project/my-artifact/maven-metadata.xml (420 B at 0.2
KB/sec)
15:25:24 [INFO] Uploaded:
http://repo/com/company/project/my-artifact/0.15-SNAPSHOT/my-artifact-0.15-20170516.202515-32-sources.jar
(85 KB at 187.9 KB/sec)
15:25:25 [INFO] Uploaded:
http://repo/com/company/project/my-artifact/0.15-SNAPSHOT/maven-metadata.xml
(988 B at 1.7 KB/sec)
{noformat}
> Support parallel deployment at end
> --
>
> Key: MDEPLOY-206
> URL: https://issues.apache.org/jira/browse/MDEPLOY-206
> Project: Maven Deploy Plugin
> Issue Type: Improvement
> Components: deploy:deploy
>Reporter: Matt Nelson
>
> When deploying at end with a large reactor the deployment process can take
> some time. If the DeployMojo was updated to support a configuration value for
> the amount of parallelism the deployment could be speed up substantially.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1359) Corrupted stdin stream in forked JVM 1. See the dump file
[ https://issues.apache.org/jira/browse/SUREFIRE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15997582#comment-15997582 ] Matt Nelson commented on SUREFIRE-1359: --- Thanks for all the support, I have implemented the workaround. > Corrupted stdin stream in forked JVM 1. See the dump file > - > > Key: SUREFIRE-1359 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1359 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20 > Environment: JDK 1.8.0_121 > maven version 3.5.0 >Reporter: Brian Oxley >Assignee: Tibor Digana > Attachments: 2017-04-13T10-56-35_635-jvmRun1.dumpstream, > 2017-04-13T10-56-36_592.dumpstream, failsafe-summary.xml, > hm.binkley.labs.GitInfoIT.txt, hm.binkley.labs.GreetingControllerIT.txt, > TEST-hm.binkley.labs.GitInfoIT.xml, > TEST-hm.binkley.labs.GreetingControllerIT.xml > > > Surefire 2.20 complains "Corrupted stdin stream in forked JVM 1. See the dump > file". Version 2.19.1 does not, and testing completes successfully. > Project is here: https://github.com/binkley/sproingk. > Run with "mvn clean verify". > Same behavior on Windows 10 (Oracle JDK), MacOS and the Linux subsystem on > Windows. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1359) Corrupted stdin stream in forked JVM 1. See the dump file
[
https://issues.apache.org/jira/browse/SUREFIRE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15997312#comment-15997312
]
Matt Nelson commented on SUREFIRE-1359:
---
{quote}
There is no property since it is not Surefire problem. The IT tool should now
provide a fix. Can you attach your project in Jira and I will try to reproduce
the issue. If the IT framework is Arquillian then this issue was already fixed
there.
{quote}
This is a plugin problem since it worked with 2.19.1. The refactoring of the
ForkedClient is now inspecting the output of all forked processes (even those
which surefire did not spawn). When the output line of a process does not match
the expected prefixes it blows up. Even when I modify the log format pattern of
the my forked processes to include the stdout prefix {{3,}} any multiline
messages still cause the failures.
> Corrupted stdin stream in forked JVM 1. See the dump file
> -
>
> Key: SUREFIRE-1359
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1359
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: JDK 1.8.0_121
> maven version 3.5.0
>Reporter: Brian Oxley
>Assignee: Tibor Digana
> Attachments: 2017-04-13T10-56-35_635-jvmRun1.dumpstream,
> 2017-04-13T10-56-36_592.dumpstream, failsafe-summary.xml,
> hm.binkley.labs.GitInfoIT.txt, hm.binkley.labs.GreetingControllerIT.txt,
> TEST-hm.binkley.labs.GitInfoIT.xml,
> TEST-hm.binkley.labs.GreetingControllerIT.xml
>
>
> Surefire 2.20 complains "Corrupted stdin stream in forked JVM 1. See the dump
> file". Version 2.19.1 does not, and testing completes successfully.
> Project is here: https://github.com/binkley/sproingk.
> Run with "mvn clean verify".
> Same behavior on Windows 10 (Oracle JDK), MacOS and the Linux subsystem on
> Windows.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1359) Corrupted stdin stream in forked JVM 1. See the dump file
[ https://issues.apache.org/jira/browse/SUREFIRE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995865#comment-15995865 ] Matt Nelson commented on SUREFIRE-1359: --- This is still an issue in some workflows and I don't see a way to resolve it. I am using the ProcessBuilder to kick off process in our integration tests. I am also inheriting the IO of the std streams in order to get a unified console output from all the processes. Using the default pipe redirect does not work. https://docs.oracle.com/javase/8/docs/api/java/lang/ProcessBuilder.html#inheritIO-- Is there a recommendation for how to proceed with the corrupted streams? Can I set a property to disable this check? > Corrupted stdin stream in forked JVM 1. See the dump file > - > > Key: SUREFIRE-1359 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1359 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20 > Environment: JDK 1.8.0_121 > maven version 3.5.0 >Reporter: Brian Oxley >Assignee: Tibor Digana > Attachments: 2017-04-13T10-56-35_635-jvmRun1.dumpstream, > 2017-04-13T10-56-36_592.dumpstream, failsafe-summary.xml, > hm.binkley.labs.GitInfoIT.txt, hm.binkley.labs.GreetingControllerIT.txt, > TEST-hm.binkley.labs.GitInfoIT.xml, > TEST-hm.binkley.labs.GreetingControllerIT.xml > > > Surefire 2.20 complains "Corrupted stdin stream in forked JVM 1. See the dump > file". Version 2.19.1 does not, and testing completes successfully. > Project is here: https://github.com/binkley/sproingk. > Run with "mvn clean verify". > Same behavior on Windows 10 (Oracle JDK), MacOS and the Linux subsystem on > Windows. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MPMD-233) Upgrade to PMD 5.6.0
[
https://issues.apache.org/jira/browse/MPMD-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Nelson updated MPMD-233:
-
Description:
PMD-5.6.0 introduced non-passive API changes
https://github.com/pmd/pmd/pull/131
{quote}
00:56:58 [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-pmd-plugin:3.7:pmd (pmd) on project
maven-base-pom-test: Execution pmd of goal
org.apache.maven.plugins:maven-pmd-plugin:3.7:pmd failed: An API
incompatibility was encountered while executing
org.apache.maven.plugins:maven-pmd-plugin:3.7:pmd: java.lang.NoSuchMethodError:
net.sourceforge.pmd.RuleSetFactory.setMinimumPriority(Lnet/sourceforge/pmd/RulePriority;)V
{quote}
was:
PMD-5.6.0 introduced non-passive API changes
https://github.com/pmd/pmd/pull/131
{noformat}
00:56:58 [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-pmd-plugin:3.7:pmd (pmd) on project
maven-base-pom-test: Execution pmd of goal
org.apache.maven.plugins:maven-pmd-plugin:3.7:pmd failed: An API
incompatibility was encountered while executing
org.apache.maven.plugins:maven-pmd-plugin:3.7:pmd: java.lang.NoSuchMethodError:
net.sourceforge.pmd.RuleSetFactory.setMinimumPriority(Lnet/sourceforge/pmd/RulePriority;)V
{noformat}
> Upgrade to PMD 5.6.0
>
>
> Key: MPMD-233
> URL: https://issues.apache.org/jira/browse/MPMD-233
> Project: Maven PMD Plugin
> Issue Type: Improvement
> Components: CPD, PMD
>Affects Versions: 3.7
>Reporter: Matt Nelson
>Assignee: Andreas Dangel
> Fix For: 3.8
>
>
> PMD-5.6.0 introduced non-passive API changes
> https://github.com/pmd/pmd/pull/131
> {quote}
> 00:56:58 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-pmd-plugin:3.7:pmd (pmd) on project
> maven-base-pom-test: Execution pmd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.7:pmd failed: An API
> incompatibility was encountered while executing
> org.apache.maven.plugins:maven-pmd-plugin:3.7:pmd:
> java.lang.NoSuchMethodError:
> net.sourceforge.pmd.RuleSetFactory.setMinimumPriority(Lnet/sourceforge/pmd/RulePriority;)V
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MPMD-233) Upgrade to PMD 5.6.0
[
https://issues.apache.org/jira/browse/MPMD-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Nelson updated MPMD-233:
-
Description:
PMD-5.6.0 introduced non-passive API changes
https://github.com/pmd/pmd/pull/131
{noformat}
00:56:58 [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-pmd-plugin:3.7:pmd (pmd) on project
maven-base-pom-test: Execution pmd of goal
org.apache.maven.plugins:maven-pmd-plugin:3.7:pmd failed: An API
incompatibility was encountered while executing
org.apache.maven.plugins:maven-pmd-plugin:3.7:pmd: java.lang.NoSuchMethodError:
net.sourceforge.pmd.RuleSetFactory.setMinimumPriority(Lnet/sourceforge/pmd/RulePriority;)V
{noformat}
> Upgrade to PMD 5.6.0
>
>
> Key: MPMD-233
> URL: https://issues.apache.org/jira/browse/MPMD-233
> Project: Maven PMD Plugin
> Issue Type: Improvement
> Components: CPD, PMD
>Affects Versions: 3.7
>Reporter: Matt Nelson
>Assignee: Andreas Dangel
> Fix For: 3.8
>
>
> PMD-5.6.0 introduced non-passive API changes
> https://github.com/pmd/pmd/pull/131
> {noformat}
> 00:56:58 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-pmd-plugin:3.7:pmd (pmd) on project
> maven-base-pom-test: Execution pmd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.7:pmd failed: An API
> incompatibility was encountered while executing
> org.apache.maven.plugins:maven-pmd-plugin:3.7:pmd:
> java.lang.NoSuchMethodError:
> net.sourceforge.pmd.RuleSetFactory.setMinimumPriority(Lnet/sourceforge/pmd/RulePriority;)V
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MPMD-233) Upgrade to PMD 5.6.0
Matt Nelson created MPMD-233: Summary: Upgrade to PMD 5.6.0 Key: MPMD-233 URL: https://issues.apache.org/jira/browse/MPMD-233 Project: Maven PMD Plugin Issue Type: Improvement Components: CPD, PMD Affects Versions: 3.7 Reporter: Matt Nelson Assignee: Andreas Dangel Fix For: 3.8 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-5940) Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM
[
https://issues.apache.org/jira/browse/MNG-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15967132#comment-15967132
]
Matt Nelson commented on MNG-5940:
--
Could this issue be retargeted to 3.5.1?
> Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM
> ---
>
> Key: MNG-5940
> URL: https://issues.apache.org/jira/browse/MNG-5940
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: needing-scrub-3.4.0-fallout
>
>
> At the moment the {{maven-source-plugin:jar}} goal is defined in the Maven
> super pom:
> {code:xml}
>
> true
> maven-source-plugin
>
>
> attach-sources
>
> jar
>
>
>
>
> {code}
> where the goal of {{maven-source-plugin}} should be changed from {{jar}} into
> {{jar-no-fork}}, cause most of the time you need to override this behaviour.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MDEP-409) dependency:tree fails for a multi-module project where one module depends on another and "mvn install" not run yet
[
https://issues.apache.org/jira/browse/MDEP-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15762715#comment-15762715
]
Matt Nelson commented on MDEP-409:
--
Gonna bump this again. I have some scripts that I attempted to update to use
the new collect goal from (MDEP-410), but I need the tree goal updated because
the output includes a slightly different dependency set. [~epabst] Would you be
willing to pick up from where it was left and get this pulled?
https://github.com/epabst/maven-plugins/commit/f9335a8aef7f96b1ba16e7782b28639cda7e4370
> dependency:tree fails for a multi-module project where one module depends on
> another and "mvn install" not run yet
> --
>
> Key: MDEP-409
> URL: https://issues.apache.org/jira/browse/MDEP-409
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: tree
>Affects Versions: 2.7
> Environment: Linux
>Reporter: Eric Pabst
> Attachments: MDEP-409.patch
>
>
> When I run dependency:tree on a multi-module project without having run a
> "mvn install", it fails with this error: {noformat}
> [ERROR] Failed to execute goal on project slide-test-module-svn-2: Could not
> resolve dependencies for project
> org.slide:slide-test-module-svn-2:jar:1.1-SNAPSHOT: The following artifacts
> could not be resolved: org.slide:slide-test-module-svn-3:jar:1.1-SNAPSHOT,
> org.slide:git-component-for-testing-slide:jar:1.0.b1782: Could not find
> artifact org.slide:slide-test-module-svn-3:jar:1.1-SNAPSHOT in maven-central
> -> [Help 1]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-2975) test scope does not work with pom dependency
[ https://issues.apache.org/jira/browse/MNG-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15742377#comment-15742377 ] Matt Nelson commented on MNG-2975: -- Sorry for bumping such an old issue, but I would like to get this issue re-evaluated for inclusion in a future release. I agree with [~paragsrivastava] comments. I am developing an SDK with a paired runtime, in order to make it easier for our consumers to test their code my intention was to supply two import poms, one compile/runtime and one test with the matching dependencies required for each goal. > test scope does not work with pom dependency > > > Key: MNG-2975 > URL: https://issues.apache.org/jira/browse/MNG-2975 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4 > Environment: jdk1.5 >Reporter: Franck HUGOT >Assignee: Brett Porter > > I have a project A with pom packaging (pom) that use > this dependency : > > org.springframework > spring-mock > 2.0 > test > > In project B , I try to use the project A like a dependency like this : > > xxx > SOFFWK_LIBS > 1.0 > pom > > I don't get the spring-mock transitive dependency when I compile or test > project B. > Is it because it has a test scope? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MCOMPILER-267) Compiler plugin could have failOnWarning option
[
https://issues.apache.org/jira/browse/MCOMPILER-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15622469#comment-15622469
]
Matt Nelson edited comment on MCOMPILER-267 at 10/31/16 3:42 PM:
-
The docs should be updated to correctly report when the {{failOnWarning}}
property was introduced.
https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#failOnWarning
was (Author: mattnelson):
The docs should be updated to correctly report when the {failOnWarning}
property was introduced.
https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#failOnWarning
> Compiler plugin could have failOnWarning option
> ---
>
> Key: MCOMPILER-267
> URL: https://issues.apache.org/jira/browse/MCOMPILER-267
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Matthieu Baechler
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.6.0
>
>
> Nobody really reads maven output and warnings are rarely spoted.
> I would like to make sure warning could be treated as errors to stop the
> build and avoid merging code introducing new warnings.
> Could you think it would be an possible addition ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCOMPILER-267) Compiler plugin could have failOnWarning option
[
https://issues.apache.org/jira/browse/MCOMPILER-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15622469#comment-15622469
]
Matt Nelson commented on MCOMPILER-267:
---
The docs should be updated to correctly report when the {failOnWarning}
property was introduced.
https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#failOnWarning
> Compiler plugin could have failOnWarning option
> ---
>
> Key: MCOMPILER-267
> URL: https://issues.apache.org/jira/browse/MCOMPILER-267
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Matthieu Baechler
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.6.0
>
>
> Nobody really reads maven output and warnings are rarely spoted.
> I would like to make sure warning could be treated as errors to stop the
> build and avoid merging code introducing new warnings.
> Could you think it would be an possible addition ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5571) Instructions to resume the build can be misleading with -T parallel builds
[
https://issues.apache.org/jira/browse/MNG-5571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15497379#comment-15497379
]
Matt Nelson commented on MNG-5571:
--
There are alternatives that could supply a correct command.
* Update the command to include a {{-pl b,c,d}} option that includes all the
modules that had not finished building.
* Use the reactor dependency graph to only supply the next nodes in the tree
with the also make flag, {{-pl b,c -am}}
> Instructions to resume the build can be misleading with -T parallel builds
> --
>
> Key: MNG-5571
> URL: https://issues.apache.org/jira/browse/MNG-5571
> Project: Maven
> Issue Type: Bug
>Reporter: Derek Lewis
>Priority: Minor
> Attachments: resume-from-testcase.zip
>
>
> In a project with many modules that are able to build in parallel, if one
> fails the build, the output says to use -rf to resume from that module.
> However, this may not run the other modules that were running in parallel.
> If one of those modules also had failures, but had not yet reached those
> failures during the first build, and those modules aren't build in the second
> build, the build will pass, despite these 'hidden' errors.
> In the example I've attached, there are four submodules, a, b, c and d.
> Module d depends on a, b, and c, and all modules share a common parent module.
> The properties fail.a, fail.b, and fail.c will cause the respective module to
> fail.
> Build first with just "mvn install -T4".
> Next, imagine making a change in modules a, b, and c that break them, and
> build with "mvn install -T4 -Dfail.a -Dfail.b -Dfail.c"
> Due to the timing in the test poms (using antrun sleep), this should print:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :c
> {noformat}
> Above that, you will see it reporting the failure of all three modules, but
> in a lot of cases where there are surefire tests failing, it's extremely
> difficult to tell that more than one module failed. As a result, I generally
> just look at the module it's told me to resume from, to find failures.
> So, pretend you've done that, but the errors in a and b remain, and run "mvn
> install -T4 -Dfail.a -Dfail.b -rf :c" as it's suggested.
> The build passes, giving a false sense of confidence.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MDEPLOY-206) Support parallel deployment at end
[ https://issues.apache.org/jira/browse/MDEPLOY-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15322903#comment-15322903 ] Matt Nelson commented on MDEPLOY-206: - Adding a blocker to MDEPLOY-204 since a parallel deployment would further exacerbate the potential for uploading the artifacts out of order. > Support parallel deployment at end > -- > > Key: MDEPLOY-206 > URL: https://issues.apache.org/jira/browse/MDEPLOY-206 > Project: Maven Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy >Reporter: Matt Nelson > > When deploying at end with a large reactor the deployment process can take > some time. If the DeployMojo was updated to support a configuration value for > the amount of parallelism the deployment could be speed up substantially. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MDEPLOY-206) Support parallel deployment at end
Matt Nelson created MDEPLOY-206: --- Summary: Support parallel deployment at end Key: MDEPLOY-206 URL: https://issues.apache.org/jira/browse/MDEPLOY-206 Project: Maven Deploy Plugin Issue Type: Improvement Components: deploy:deploy Reporter: Matt Nelson When deploying at end with a large reactor the deployment process can take some time. If the DeployMojo was updated to support a configuration value for the amount of parallelism the deployment could be speed up substantially. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (MINSTALL-98) installAtEnd broken with parallel builds
[
https://jira.codehaus.org/browse/MINSTALL-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=333794#comment-333794
]
Matt Nelson commented on MINSTALL-98:
-
Thanks for the quick turnaround. When is this fix and the related deployment
fix scheduled to be released?
installAtEnd broken with parallel builds
Key: MINSTALL-98
URL: https://jira.codehaus.org/browse/MINSTALL-98
Project: Maven Install Plugin
Issue Type: Bug
Components: install:install
Affects Versions: 2.5
Reporter: Matt Nelson
Assignee: Robert Scholte
Priority: Minor
Fix For: 2.6
I updated my reactor to depend on install-2.5 and deploy-2.8 to take
advantage of the new installAtEnd(MINSTALL-93) and deployAtEnd(MDEPLOY-157)
features. When I build the reactor in a single thread, it succeeds. When I
build the reactor parallel (-T 2C) it fails every time.
{code}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-install-plugin:2.5:install
(default-install) on project my-server: The packaging for this project did
not assign a file to the build artifact
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Caused by: org.apache.maven.plugin.MojoExecutionException: The packaging for
this project did not assign a file to the build artifact
at
org.apache.maven.plugin.install.InstallMojo.installProject(InstallMojo.java:194)
at
org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:121)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 13 more
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-98) installAtEnd broken with parallel builds
Matt Nelson created MINSTALL-98:
---
Summary: installAtEnd broken with parallel builds
Key: MINSTALL-98
URL: https://jira.codehaus.org/browse/MINSTALL-98
Project: Maven Install Plugin
Issue Type: Bug
Components: install:install
Affects Versions: 2.5
Reporter: Matt Nelson
Priority: Minor
I updated my reactor to depend on install-2.5 and deploy-2.8 to take advantage
of the new installAtEnd and deployAtEnd features. When I build the reactor in a
single thread, it succeeds. When I build the reactor parallel (-T 2C) it fails
every time.
{code}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:2.5:install (default-install) on
project my-server: The packaging for this project did not assign a file to the
build artifact
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Caused by: org.apache.maven.plugin.MojoExecutionException: The packaging for
this project did not assign a file to the build artifact
at
org.apache.maven.plugin.install.InstallMojo.installProject(InstallMojo.java:194)
at
org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:121)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 13 more
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-98) installAtEnd broken with parallel builds
[
https://jira.codehaus.org/browse/MINSTALL-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Nelson updated MINSTALL-98:
Description:
I updated my reactor to depend on install-2.5 and deploy-2.8 to take advantage
of the new installAtEnd(MINSTALL-93) and deployAtEnd(MDEPLOY-157) features.
When I build the reactor in a single thread, it succeeds. When I build the
reactor parallel (-T 2C) it fails every time.
{code}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:2.5:install (default-install) on
project my-server: The packaging for this project did not assign a file to the
build artifact
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Caused by: org.apache.maven.plugin.MojoExecutionException: The packaging for
this project did not assign a file to the build artifact
at
org.apache.maven.plugin.install.InstallMojo.installProject(InstallMojo.java:194)
at
org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:121)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 13 more
{code}
was:
I updated my reactor to depend on install-2.5 and deploy-2.8 to take advantage
of the new installAtEnd and deployAtEnd features. When I build the reactor in a
single thread, it succeeds. When I build the reactor parallel (-T 2C) it fails
every time.
{code}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:2.5:install (default-install) on
project my-server: The packaging for this project did not assign a file to the
build artifact
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Caused by: org.apache.maven.plugin.MojoExecutionException: The packaging for
this project did not assign a file to the build artifact
at
org.apache.maven.plugin.install.InstallMojo.installProject(InstallMojo.java:194)
at
org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:121)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 13 more
{code}
installAtEnd broken with parallel builds
Key: MINSTALL-98
URL:
