[jira] [Created] (SUREFIRE-1798) trimStackTrace should be false by default
Romain Manni-Bucau created SUREFIRE-1798: Summary: trimStackTrace should be false by default Key: SUREFIRE-1798 URL: https://issues.apache.org/jira/browse/SUREFIRE-1798 Project: Maven Surefire Issue Type: Task Components: Maven Surefire Plugin Reporter: Romain Manni-Bucau True was intended to clean up the output but it always misses any useful data so let's set an useful default -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSITE-863) NoSuchMethodError: 'Xpp3Dom.getInputLocation()' when running reports with Maven versions < 3.6.1
[
https://issues.apache.org/jira/browse/MSITE-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128880#comment-17128880
]
Herve Boutemy commented on MSITE-863:
-
failing ITs restored in
https://github.com/apache/maven-site-plugin/commit/36b11f4455076840df0af3dc51d825358f899198/
(were incorrectly associated to ASF Jenkins JDK 7 issues, given investigating
plugin IT issues is hard and I could not reproduce locally: now I know it's
because I did not try to use an older Maven version, I focused on JDK)
=> as expected, build 107 fails with every old Maven versions
using maven-reporting-exec 1.5-SNAPSHOT with MSHARED-921 fix in
https://github.com/apache/maven-site-plugin/commit/77c7cff6e5dbf1ed848383a933187a5f578b9435/
=> previous failures are gone in build 108
remaining ASF Jenkins failure for build 108 is one stupid Windows agent that
does not recognise mvn command...
> NoSuchMethodError: 'Xpp3Dom.getInputLocation()' when running reports with
> Maven versions < 3.6.1
>
>
> Key: MSITE-863
> URL: https://issues.apache.org/jira/browse/MSITE-863
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: Maven 3
>Affects Versions: 3.9.0
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Blocker
> Fix For: 3.9.1
>
>
> [https://lists.apache.org/thread.html/rbba90de4703f8109b543500a5ee9e5b17b6a1258d95c6b5815b9257a%40%3Cdev.maven.apache.org%3E]
> {noformat}
> mojo-parent (issue-105)$ mvn site site:stage
> ..
> [INFO]
> [INFO] --- maven-site-plugin:3.9.0:site (default-site) @ mojo-parent ---
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-plugin-plugin:3.6.0
> [INFO] preparing maven-plugin-plugin:report report requires 'process-classes'
> forked phase execution
> [INFO]
> [INFO] >>> maven-plugin-plugin:3.6.0:report > process-classes @mojo-parent >>>
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.4:enforce (mojo-enforcer-rules)
> @mojo-parent ---
> [INFO]
> [INFO] <<< maven-plugin-plugin:3.6.0:report < process-classes @mojo-parent <<<
> [INFO] 'process-classes' forked phase execution for
> maven-plugin-plugin:report report preparation done
> [INFO] 1 report detected for maven-plugin-plugin:3.6.0: report
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-changes-plugin:2.11
> [INFO] 1 report configured for maven-changes-plugin:2.11: github-report
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-checkstyle-plugin:2.16
> [INFO] 1 report configured for maven-checkstyle-plugin:2.16: checkstyle
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-javadoc-plugin:3.2.0
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.144 s
> [INFO] Finished at: 2020-05-24T11:50:11+02:00
> [INFO] Final Memory: 30M/128M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.9.0:site (default-site) on
> project mojo-parent: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.9.0:site failed: An API
> incompatibility was encountered while executing
> org.apache.maven.plugins:maven-site-plugin:3.9.0:site:java.lang.NoSuchMethodError:
> 'java.lang.Object org.codehaus.plexus.util.xml.Xpp3Dom.getInputLocation()'
> [ERROR] -
> [ERROR] realm =plugin>org.apache.maven.plugins:maven-site-plugin:3.9.0
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] =
> file:/Users/khmarbaise/.m2/repository/org/apache/maven/plugins/maven-site-plugin/3.9.0/maven-site-plugin-3.9.0.jar{noformat}
> This can be reproduced with 3.0.5 up to 3.6.0.
> Versions 3.6.1, 3.6.2 and 3.6.3 are working fine.
> This means using maven-site-plugin 3.9.0 only working with Maven 3.6.1+
> ...in contradiction to the site[1] which says it is requirement 3.0..
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-272) Add skip capability to deploy-file goal
[ https://issues.apache.org/jira/browse/MDEPLOY-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128809#comment-17128809 ] Tom Esh commented on MDEPLOY-272: - I created a PR ([https://github.com/apache/maven-deploy-plugin/pull/11]) for this Jira Issue. > Add skip capability to deploy-file goal > --- > > Key: MDEPLOY-272 > URL: https://issues.apache.org/jira/browse/MDEPLOY-272 > Project: Maven Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: Tom Esh >Priority: Major > > Currently the deploy-file goal doesn't support the > configuration parameter. > I have a case where that would be very useful, as I would like to > conditionally deploy a file based on a maven property. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MEAR-278) Ear plugin includes the same artifact twice if used without clean
[ https://issues.apache.org/jira/browse/MEAR-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128675#comment-17128675 ] Fabian Meier commented on MEAR-278: --- Sehr geehrte Damen und Herren, ich bin ab 15. Juni wieder im Haus. Viele Grüße Fabian Meier (ik3-mv) > Ear plugin includes the same artifact twice if used without clean > - > > Key: MEAR-278 > URL: https://issues.apache.org/jira/browse/MEAR-278 > Project: Maven Ear Plugin > Issue Type: Bug >Affects Versions: 3.0.1 >Reporter: Fabian Meier >Priority: Major > Labels: infosupport > Attachments: test-ear.zip > > Time Spent: 10m > Remaining Estimate: 0h > > The problem of > https://stackoverflow.com/questions/47436946/maven-ear-plugin-doubled-artifact-when-not-using-clean > still persists. If you rebuild an ear after changing dependency versions, the > new dependencies are included along with the old ones, leading to an > inconsistent ear. The attached Maven project shows this behaviour. It was > first build with "install", where log4j was in version 1.2.8. After changing > the version to 1.2.17, the project was "installed" again, leading to an ear > that contains both log4j versions simultaneously. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MEAR-278) Ear plugin includes the same artifact twice if used without clean
[ https://issues.apache.org/jira/browse/MEAR-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128673#comment-17128673 ] Hudson commented on MEAR-278: - Build unstable in Jenkins: Maven TLP » maven-ear-plugin » master #55 See https://builds.apache.org/job/maven-box/job/maven-ear-plugin/job/master/55/ > Ear plugin includes the same artifact twice if used without clean > - > > Key: MEAR-278 > URL: https://issues.apache.org/jira/browse/MEAR-278 > Project: Maven Ear Plugin > Issue Type: Bug >Affects Versions: 3.0.1 >Reporter: Fabian Meier >Priority: Major > Labels: infosupport > Attachments: test-ear.zip > > Time Spent: 10m > Remaining Estimate: 0h > > The problem of > https://stackoverflow.com/questions/47436946/maven-ear-plugin-doubled-artifact-when-not-using-clean > still persists. If you rebuild an ear after changing dependency versions, the > new dependencies are included along with the old ones, leading to an > inconsistent ear. The attached Maven project shows this behaviour. It was > first build with "install", where log4j was in version 1.2.8. After changing > the version to 1.2.17, the project was "installed" again, leading to an ear > that contains both log4j versions simultaneously. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MNG-6717) mvn site build of archtype project throughs error
[
https://issues.apache.org/jira/browse/MNG-6717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-6717:
---
Assignee: Michael Osipov
> mvn site build of archtype project throughs error
> -
>
> Key: MNG-6717
> URL: https://issues.apache.org/jira/browse/MNG-6717
> Project: Maven
> Issue Type: Bug
> Components: Documentation: Guides
>Affects Versions: 3.6.1
> Environment: $ mvn -version
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T21:00:29+02:00)
> Java version: 1.8.0_111, vendor: Oracle Corporation
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Rudolf Starosta
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.7.0-candidate
>
>
> Following the steps in the Maven tutorial,
> [https://maven.apache.org/guides/getting-started/]
>
> I created a project with
> {code:java}
> mvn -B archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
> -DgroupId=com.mycompany.app
> -DartifactId=my-app
> {code}
> Trying to use "one of the highly prized features of Maven" namely
> {code:java}
> mvn site
> {code}
> I got
> {code:java}
> [INFO]
>
>
> [INFO] BUILD FAILURE
>
> [INFO]
>
>
> [INFO] Total time: 2.363 s
>
> [INFO] Finished at: 2019-07-23T07:52:37+02:00
>
> [INFO]
>
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> my-app: Executio
> n default-site of goal org.apache.maven.plugins:maven-site-plugin:3.3:site
> failed: A required class was missing while executi
> ng org.apache.maven.plugins:maven-site-plugin:3.3:site:
> org/apache/maven/doxia/siterenderer/DocumentContent
> [ERROR] -
>
> [ERROR] realm =plugin>org.apache.maven.plugins:maven-site-plugin:3.3
>
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
>
> [ERROR] urls[0] =
> file:/C:/Users/rudolfstarosta/.m2/repository/org/apache/maven/plugins/maven-site-plugin/3.3/maven-site-plug
> in-3.3.jar
> [...]
>
> {code}
>
> Expected result: mvn builds a web site with the project information.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARCHETYPE-584) Resulting root pom.xml from archetype generation has additional newlines with JDK11
[
https://issues.apache.org/jira/browse/ARCHETYPE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128638#comment-17128638
]
Herve Boutemy commented on ARCHETYPE-584:
-
tested the PR: there are 4 ITs failing
can you check why, please?
> Resulting root pom.xml from archetype generation has additional newlines with
> JDK11
> ---
>
> Key: ARCHETYPE-584
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-584
> Project: Maven Archetype
> Issue Type: Bug
> Components: Archetypes
>Affects Versions: 3.1.1, 3.1.2
>Reporter: Andre Prata
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This issue does not apply to version 3.1.0, it was introduced in version
> 3.1.1.
>
> In our project, we have the default configuration of the root pom.xml that
> contains lines such as this:
> {code:java}
>
> 11
> Greenwich.RELEASE
>
> {code}
> These lines are still in good shape when added to the jar artifact. However,
> upon generating the project from the archetype, we get the following (note
> also the whitespace on the blank lines hinting at some indentation attempts,
> not just the unexpected line breaks)
> {code:java}
>
>
>
> 11
>
>
> Greenwich.RELEASE
>
>
>
> {code}
> This issue does *not* occur in in child module pom.xml files.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-271) Allow to optionally disable checksum creation
[ https://issues.apache.org/jira/browse/MDEPLOY-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128636#comment-17128636 ] Konrad Windszus commented on MDEPLOY-271: - I again summarized the issues related to SHA2 checksums in https://lists.apache.org/thread.html/r9fb5f44f6c44f077516ac3f09e7a76c21b355efd578f866b01a0b3b3%40%3Cusers.maven.apache.org%3E. > Allow to optionally disable checksum creation > - > > Key: MDEPLOY-271 > URL: https://issues.apache.org/jira/browse/MDEPLOY-271 > Project: Maven Deploy Plugin > Issue Type: Improvement >Affects Versions: 3.0.0-M1 >Reporter: Konrad Windszus >Priority: Major > > Since 3.0.0-M1 the deploy goal will always generate SHA1/MD5 for all attached > artifacts. The old configuration option > https://maven.apache.org/plugins-archives/maven-install-plugin-2.4/install-mojo.html#createChecksum > is no longer exposed in the maven-deploy-plugin. That leads to the fact the > m-deploy-plugin 3.0.0-M1 will generate MD5/SHA1 even for attached SHA-512 > artifacts (generated with > https://checksum-maven-plugin.nicoulaj.net/artifacts-mojo.html) which are > supported by Nexus since https://issues.sonatype.org/browse/NEXUS-21802. > It would be nice if one would be able to configure _*which artifacts > (regex/glob on artifactId) should receive which hashes (algorithm)*_. > That way generating only MD5 or SHA1 would be possible and also exclusion of > checksums for certain attached artifacts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEPLOY-271) Allow to optionally disable checksum creation
[ https://issues.apache.org/jira/browse/MDEPLOY-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128615#comment-17128615 ] Konrad Windszus commented on MDEPLOY-271: - Maven Resolver does not yet support creating SHA512/SHA256 checksums. Therefore I currently have to use a different plugin for that. Also the MD5/SHA1 support in the m-deploy-plugin (MDEPLOY-231) is part of the https://github.com/apache/maven-artifact-transfer/blob/d4df3387215336eb52358f054e742ad44ad9e88f/src/main/java/org/apache/maven/shared/transfer/project/deploy/internal/DefaultProjectDeployer.java#L130 but not of the Maven Resolver! > Allow to optionally disable checksum creation > - > > Key: MDEPLOY-271 > URL: https://issues.apache.org/jira/browse/MDEPLOY-271 > Project: Maven Deploy Plugin > Issue Type: Improvement >Affects Versions: 3.0.0-M1 >Reporter: Konrad Windszus >Priority: Major > > Since 3.0.0-M1 the deploy goal will always generate SHA1/MD5 for all attached > artifacts. The old configuration option > https://maven.apache.org/plugins-archives/maven-install-plugin-2.4/install-mojo.html#createChecksum > is no longer exposed in the maven-deploy-plugin. That leads to the fact the > m-deploy-plugin 3.0.0-M1 will generate MD5/SHA1 even for attached SHA-512 > artifacts (generated with > https://checksum-maven-plugin.nicoulaj.net/artifacts-mojo.html) which are > supported by Nexus since https://issues.sonatype.org/browse/NEXUS-21802. > It would be nice if one would be able to configure _*which artifacts > (regex/glob on artifactId) should receive which hashes (algorithm)*_. > That way generating only MD5 or SHA1 would be possible and also exclusion of > checksums for certain attached artifacts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MNG-6405) Incorrect basedir in forked executions when using flatten-maven-plugin with custom outputDirectory
[
https://issues.apache.org/jira/browse/MNG-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6405.
---
> Incorrect basedir in forked executions when using flatten-maven-plugin with
> custom outputDirectory
> --
>
> Key: MNG-6405
> URL: https://issues.apache.org/jira/browse/MNG-6405
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.3
>Reporter: Jesse Glick
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.6.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For [JENKINS-51247|https://issues.jenkins-ci.org/browse/JENKINS-51247] I am
> trying to use a variant of the tip shown
> [here|https://github.com/mojohaus/flatten-maven-plugin/issues/53#issuecomment-340366191]:
> using {{flatten-maven-plugin}} with a generated POM file in the {{target}}
> directory. This works fine in almost all cases, since the plugin calls
> {{MavenProject.setPomFile}}, which leaves the {{basedir}} untouched.
> Unfortunately it fails for mojos which rely on the basedir that are run
> inside a forked execution, as I found when accidentally using {{source:jar}}
> when {{source:jar-no-fork}} was what I wanted. (Ditto when using
> {{findbugs:check}}.) This seems to be because {{deepCopy}} still calls
> {{setFile}}, so the basedir of a cloned project is not the same as the
> original—it is always the parent directory of the POM file.
> Fixing this should be trivial
> {code}
> diff --git
> a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> index 80a51935e..ee7a68635 100644
> --- a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> +++ b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> @@ -1207,7 +1207,8 @@ private void deepCopy( MavenProject project )
> // disown the parent
>
> // copy fields
> -setFile( project.getFile() );
> +file = project.file;
> +basedir = project.basedir;
>
> // don't need a deep copy, they don't get modified or added/removed
> to/from - but make them unmodifiable to be
> // sure!
> {code}
> but I am unsure what the best approach is to validate the fix. A unit test in
> {{MavenProjectTest}}? An IT which calls {{flatten-maven-plugin}},
> {{source:jar}}, and some other mojo TBD which is sensitive to project
> basedir? Both?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSITE-863) NoSuchMethodError: 'Xpp3Dom.getInputLocation()' when running reports with Maven versions < 3.6.1
[
https://issues.apache.org/jira/browse/MSITE-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128603#comment-17128603
]
Hudson commented on MSITE-863:
--
Build failed in Jenkins: Maven TLP » maven-site-plugin » master #108
See
https://builds.apache.org/job/maven-box/job/maven-site-plugin/job/master/108/
> NoSuchMethodError: 'Xpp3Dom.getInputLocation()' when running reports with
> Maven versions < 3.6.1
>
>
> Key: MSITE-863
> URL: https://issues.apache.org/jira/browse/MSITE-863
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: Maven 3
>Affects Versions: 3.9.0
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Blocker
> Fix For: 3.9.1
>
>
> [https://lists.apache.org/thread.html/rbba90de4703f8109b543500a5ee9e5b17b6a1258d95c6b5815b9257a%40%3Cdev.maven.apache.org%3E]
> {noformat}
> mojo-parent (issue-105)$ mvn site site:stage
> ..
> [INFO]
> [INFO] --- maven-site-plugin:3.9.0:site (default-site) @ mojo-parent ---
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-plugin-plugin:3.6.0
> [INFO] preparing maven-plugin-plugin:report report requires 'process-classes'
> forked phase execution
> [INFO]
> [INFO] >>> maven-plugin-plugin:3.6.0:report > process-classes @mojo-parent >>>
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.4:enforce (mojo-enforcer-rules)
> @mojo-parent ---
> [INFO]
> [INFO] <<< maven-plugin-plugin:3.6.0:report < process-classes @mojo-parent <<<
> [INFO] 'process-classes' forked phase execution for
> maven-plugin-plugin:report report preparation done
> [INFO] 1 report detected for maven-plugin-plugin:3.6.0: report
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-changes-plugin:2.11
> [INFO] 1 report configured for maven-changes-plugin:2.11: github-report
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-checkstyle-plugin:2.16
> [INFO] 1 report configured for maven-checkstyle-plugin:2.16: checkstyle
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-javadoc-plugin:3.2.0
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.144 s
> [INFO] Finished at: 2020-05-24T11:50:11+02:00
> [INFO] Final Memory: 30M/128M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.9.0:site (default-site) on
> project mojo-parent: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.9.0:site failed: An API
> incompatibility was encountered while executing
> org.apache.maven.plugins:maven-site-plugin:3.9.0:site:java.lang.NoSuchMethodError:
> 'java.lang.Object org.codehaus.plexus.util.xml.Xpp3Dom.getInputLocation()'
> [ERROR] -
> [ERROR] realm =plugin>org.apache.maven.plugins:maven-site-plugin:3.9.0
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] =
> file:/Users/khmarbaise/.m2/repository/org/apache/maven/plugins/maven-site-plugin/3.9.0/maven-site-plugin-3.9.0.jar{noformat}
> This can be reproduced with 3.0.5 up to 3.6.0.
> Versions 3.6.1, 3.6.2 and 3.6.3 are working fine.
> This means using maven-site-plugin 3.9.0 only working with Maven 3.6.1+
> ...in contradiction to the site[1] which says it is requirement 3.0..
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHARED-921) NoSuchMethodError: 'Xpp3Dom.getInputLocation()' with Maven versions < 3.6.1
[ https://issues.apache.org/jira/browse/MSHARED-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128604#comment-17128604 ] Hudson commented on MSHARED-921: Build failed in Jenkins: Maven TLP » maven-site-plugin » master #108 See https://builds.apache.org/job/maven-box/job/maven-site-plugin/job/master/108/ > NoSuchMethodError: 'Xpp3Dom.getInputLocation()' with Maven versions < 3.6.1 > --- > > Key: MSHARED-921 > URL: https://issues.apache.org/jira/browse/MSHARED-921 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-reporting-exec >Affects Versions: maven-reporting-exec-1.4 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: maven-reporting-exec-1.5 > > > see MSITE-863 for context > this is caused by Xpp3Dom class incompatibility with > Xpp3DomUtils.mergeXpp3Dom(...): > - Xpp3Dom version is taken from Maven core classloader as exported: see > [http://maven.apache.org/ref/3.6.3/maven-core/core-extensions.html] > - Xpp3DomUtils is taken from current plugin classloader > with recent upgrade of plexus-utils in maven-site-plugin 3.9.0, Xpp3DomUtils > is a recent version (plexus-utils >= 3.2.0) that expects to merge the input > location (see [https://github.com/codehaus-plexus/plexus-utils/issues/61)] > but older Maven core versions don't have this input location field in > Xpp3Dom, since they provide older plexus-utils that was upgraded to add > location tracking in MNG-6597 for Maven 3.6.1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MSHARED-663) mark ReportPlugin and ReportSet package private
[
https://issues.apache.org/jira/browse/MSHARED-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MSHARED-663.
-
Assignee: Herve Boutemy
Resolution: Fixed
done in
https://github.com/apache/maven-reporting-exec/commit/c77f6c4eb572b49bde9e3f3a79054bece9634b56/
> mark ReportPlugin and ReportSet package private
> ---
>
> Key: MSHARED-663
> URL: https://issues.apache.org/jira/browse/MSHARED-663
> Project: Maven Shared Components
> Issue Type: Task
> Components: maven-reporting-exec
>Affects Versions: maven-reporting-exec-1.4
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: maven-reporting-exec-1.5
>
>
> once MSHARED-628 is done, maven-site-plugin 3.7 won't use
> {{org.apache.maven.reporting.exec.ReportPlugin}} nor
> {{org.apache.maven.reporting.exec.ReportSet}}
> These classes remain useful for decoupling, but are now pure internal details
> of {{maven-reporting-exec}}: they should just be now package private
> This could not be done for {{maven-reporting-exec}} version 1.4 since
> maven-site-plugin 3.7 is not released yet
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-271) Allow to optionally disable checksum creation
[ https://issues.apache.org/jira/browse/MDEPLOY-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128599#comment-17128599 ] Michael Osipov commented on MDEPLOY-271: I don't fully understand this. Assuming that only Maven Resolver shall create the checksums when uploading files, why is this an issue? > Allow to optionally disable checksum creation > - > > Key: MDEPLOY-271 > URL: https://issues.apache.org/jira/browse/MDEPLOY-271 > Project: Maven Deploy Plugin > Issue Type: Improvement >Affects Versions: 3.0.0-M1 >Reporter: Konrad Windszus >Priority: Major > > Since 3.0.0-M1 the deploy goal will always generate SHA1/MD5 for all attached > artifacts. The old configuration option > https://maven.apache.org/plugins-archives/maven-install-plugin-2.4/install-mojo.html#createChecksum > is no longer exposed in the maven-deploy-plugin. That leads to the fact the > m-deploy-plugin 3.0.0-M1 will generate MD5/SHA1 even for attached SHA-512 > artifacts (generated with > https://checksum-maven-plugin.nicoulaj.net/artifacts-mojo.html) which are > supported by Nexus since https://issues.sonatype.org/browse/NEXUS-21802. > It would be nice if one would be able to configure _*which artifacts > (regex/glob on artifactId) should receive which hashes (algorithm)*_. > That way generating only MD5 or SHA1 would be possible and also exclusion of > checksums for certain attached artifacts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSITE-863) NoSuchMethodError: 'Xpp3Dom.getInputLocation()' when running reports with Maven versions < 3.6.1
[
https://issues.apache.org/jira/browse/MSITE-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128585#comment-17128585
]
Hudson commented on MSITE-863:
--
Build failed in Jenkins: Maven TLP » maven-site-plugin » master #107
See
https://builds.apache.org/job/maven-box/job/maven-site-plugin/job/master/107/
> NoSuchMethodError: 'Xpp3Dom.getInputLocation()' when running reports with
> Maven versions < 3.6.1
>
>
> Key: MSITE-863
> URL: https://issues.apache.org/jira/browse/MSITE-863
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: Maven 3
>Affects Versions: 3.9.0
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Blocker
> Fix For: 3.9.1
>
>
> [https://lists.apache.org/thread.html/rbba90de4703f8109b543500a5ee9e5b17b6a1258d95c6b5815b9257a%40%3Cdev.maven.apache.org%3E]
> {noformat}
> mojo-parent (issue-105)$ mvn site site:stage
> ..
> [INFO]
> [INFO] --- maven-site-plugin:3.9.0:site (default-site) @ mojo-parent ---
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-plugin-plugin:3.6.0
> [INFO] preparing maven-plugin-plugin:report report requires 'process-classes'
> forked phase execution
> [INFO]
> [INFO] >>> maven-plugin-plugin:3.6.0:report > process-classes @mojo-parent >>>
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.4:enforce (mojo-enforcer-rules)
> @mojo-parent ---
> [INFO]
> [INFO] <<< maven-plugin-plugin:3.6.0:report < process-classes @mojo-parent <<<
> [INFO] 'process-classes' forked phase execution for
> maven-plugin-plugin:report report preparation done
> [INFO] 1 report detected for maven-plugin-plugin:3.6.0: report
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-changes-plugin:2.11
> [INFO] 1 report configured for maven-changes-plugin:2.11: github-report
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-checkstyle-plugin:2.16
> [INFO] 1 report configured for maven-checkstyle-plugin:2.16: checkstyle
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-javadoc-plugin:3.2.0
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.144 s
> [INFO] Finished at: 2020-05-24T11:50:11+02:00
> [INFO] Final Memory: 30M/128M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.9.0:site (default-site) on
> project mojo-parent: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.9.0:site failed: An API
> incompatibility was encountered while executing
> org.apache.maven.plugins:maven-site-plugin:3.9.0:site:java.lang.NoSuchMethodError:
> 'java.lang.Object org.codehaus.plexus.util.xml.Xpp3Dom.getInputLocation()'
> [ERROR] -
> [ERROR] realm =plugin>org.apache.maven.plugins:maven-site-plugin:3.9.0
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] =
> file:/Users/khmarbaise/.m2/repository/org/apache/maven/plugins/maven-site-plugin/3.9.0/maven-site-plugin-3.9.0.jar{noformat}
> This can be reproduced with 3.0.5 up to 3.6.0.
> Versions 3.6.1, 3.6.2 and 3.6.3 are working fine.
> This means using maven-site-plugin 3.9.0 only working with Maven 3.6.1+
> ...in contradiction to the site[1] which says it is requirement 3.0..
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) keep adding to the List duplicate artifacts
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-5868.
---
> Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
> keep adding to the List duplicate artifacts
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.7.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at:
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> MSHADE-195-example ---
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO]
> {noformat}
> Install plugin tries to install two identical artifacts which will work for
> maven-install-plugin but would fail a deploy to repository manager (for
> releases) etc.
> So after diving into the problem i found the following code in maven-core
> (MavenProject.java):
> {code:java}
> /**
> * Add or replace an artifact. This method is now deprecated. Use the
> @{MavenProjectHelper} to attach artifacts to a
> * project. In spite of the 'throws' declaration on this API, this method
> has never thrown an exception since Maven
> * 3.0.x. Historically, it logged and ignored a second addition of the
> same g/a/v/c/t. Now it replaces the file for
> * the artifact, so that plugins (e.g. shade) can change the pathname of
> the file for a particular set of
> * coordinates.
> *
> * @param artifact the artifact to add or replace.
> * @throws DuplicateArtifactAttachmentException
> */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
> * Add an attached artifact or replace the file for an existing artifact.
> *
> * @see
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
> * @param project project reference.
> * @param artifact artifact to add or replace.
> */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-5387) Add ability to replace an artifact in mid-build
[ https://issues.apache.org/jira/browse/MNG-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-5387. --- Fix Version/s: (was: 3.7.0-candidate) Resolution: Duplicate Olivier, reclosing as dup of MNG-5868. > Add ability to replace an artifact in mid-build > --- > > Key: MNG-5387 > URL: https://issues.apache.org/jira/browse/MNG-5387 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.1.0-alpha-1, 3.2.3 >Reporter: Benson Margulies >Assignee: Olivier Lamy >Priority: Major > > To clean up how the shade plugin works, we need an API to allow it to say, > 'please replace the jar file that the jar plugin has given you with this > other one here.' > It turns out we already more or less have this method, due to a collection of > historical conflict. > At some point in time, http://jira.codehaus.org/browse/MNG-3119 called for > Maven to reject more than one call to attach the same artifact to the build. > However, this proved an unacceptable incompatibility at the time. Instead, > under http://jira.codehaus.org/browse/MNG-4013, Maven was changed to log but > otherwise ignore all calls to 'addArtifact' on MavenProject after the first > for a G/A/V/C/T coordinate. > This decision to take 'first wins' instead of 'last wins' doesn't help much > of anyone. It prevents something like shade from intentionally displacing an > earlier execution's results, and while it doesn't produce backtraces, ever, > it can still be entirely confusing. > Under this JIRA, I'm switching to 'last one wins'. This could still be > confusing, and someone might argue that there should be some way to > distinguish casual and incorrect user config that results in two plugins > trying to deliver the same thing from something intentional. On the other > hand, if two plugins are configured to attach the same G/A/V/C, having the > last one win makes more sense, and has the effect of enabling the desired > behavior in shade. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) keep adding to the List duplicate artifacts
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5868:
Fix Version/s: (was: 3.7.0-candidate)
3.7.0
> Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
> keep adding to the List duplicate artifacts
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.7.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at:
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> MSHADE-195-example ---
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO]
> {noformat}
> Install plugin tries to install two identical artifacts which will work for
> maven-install-plugin but would fail a deploy to repository manager (for
> releases) etc.
> So after diving into the problem i found the following code in maven-core
> (MavenProject.java):
> {code:java}
> /**
> * Add or replace an artifact. This method is now deprecated. Use the
> @{MavenProjectHelper} to attach artifacts to a
> * project. In spite of the 'throws' declaration on this API, this method
> has never thrown an exception since Maven
> * 3.0.x. Historically, it logged and ignored a second addition of the
> same g/a/v/c/t. Now it replaces the file for
> * the artifact, so that plugins (e.g. shade) can change the pathname of
> the file for a particular set of
> * coordinates.
> *
> * @param artifact the artifact to add or replace.
> * @throws DuplicateArtifactAttachmentException
> */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
> * Add an attached artifact or replace the file for an existing artifact.
> *
> * @see
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
> * @param project project reference.
> * @param artifact artifact to add or replace.
> */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (MNG-5387) Add ability to replace an artifact in mid-build
[ https://issues.apache.org/jira/browse/MNG-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reopened MNG-5387: - > Add ability to replace an artifact in mid-build > --- > > Key: MNG-5387 > URL: https://issues.apache.org/jira/browse/MNG-5387 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.1.0-alpha-1, 3.2.3 >Reporter: Benson Margulies >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.7.0-candidate > > > To clean up how the shade plugin works, we need an API to allow it to say, > 'please replace the jar file that the jar plugin has given you with this > other one here.' > It turns out we already more or less have this method, due to a collection of > historical conflict. > At some point in time, http://jira.codehaus.org/browse/MNG-3119 called for > Maven to reject more than one call to attach the same artifact to the build. > However, this proved an unacceptable incompatibility at the time. Instead, > under http://jira.codehaus.org/browse/MNG-4013, Maven was changed to log but > otherwise ignore all calls to 'addArtifact' on MavenProject after the first > for a G/A/V/C/T coordinate. > This decision to take 'first wins' instead of 'last wins' doesn't help much > of anyone. It prevents something like shade from intentionally displacing an > earlier execution's results, and while it doesn't produce backtraces, ever, > it can still be entirely confusing. > Under this JIRA, I'm switching to 'last one wins'. This could still be > confusing, and someone might argue that there should be some way to > distinguish casual and incorrect user config that results in two plugins > trying to deliver the same thing from something intentional. On the other > hand, if two plugins are configured to attach the same G/A/V/C, having the > last one win makes more sense, and has the effect of enabling the desired > behavior in shade. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MNG-5939) Problem doing release when sources are generate as well
[ https://issues.apache.org/jira/browse/MNG-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-5939. --- Fix Version/s: (was: 3.7.0-candidate) Resolution: Duplicate Olivier, reclosing as dup of MNG-5868. > Problem doing release when sources are generate as well > --- > > Key: MNG-5939 > URL: https://issues.apache.org/jira/browse/MNG-5939 > Project: Maven > Issue Type: Bug >Affects Versions: 3.2.3 > Environment: Ubuntu 12.04.5 LTS > Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; > 2014-02-14T18:37:52+01:00) > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T17:41:47+01:00) > Java version: 1.7.0_76, vendor: Oracle Corporation >Reporter: chibbe >Assignee: Olivier Lamy >Priority: Major > Attachments: > 0001-MNG-5939-Addresses-duplicate-attached-artifact-probl.patch, foo.bar.zip > > > If I specified that sources should be generated with jar-no-fork goal > https://maven.apache.org/plugins/maven-source-plugin/jar-no-fork-mojo.html . > When doing a release with maven-release-plugin it will build the source again > when useReleaseProfile is true (use the release profile that adds sources and > javadocs to the released artifact > http://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#useReleaseProfile). > The outcome is that it will run with both jar and jar-no-fork and generate > and deploy 2 -sources.jar artifacts, with same version. That makes the > release build fails. > > The same behavior could be reproduced when running both jar and jar-no-fork > goal between maven 3.2.1. and maven 3.3.9. > > Please find the logs for maven 3.2.1 and 3.3.9 in the foo.bar.zip > With maven 3.3.9 it uploads it 2 times : > Uploaded: > http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar > (722 B at 15.3 KB/sec) > Uploading: > http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar > 722/722 B -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (MNG-5939) Problem doing release when sources are generate as well
[ https://issues.apache.org/jira/browse/MNG-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reopened MNG-5939: - > Problem doing release when sources are generate as well > --- > > Key: MNG-5939 > URL: https://issues.apache.org/jira/browse/MNG-5939 > Project: Maven > Issue Type: Bug >Affects Versions: 3.2.3 > Environment: Ubuntu 12.04.5 LTS > Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; > 2014-02-14T18:37:52+01:00) > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T17:41:47+01:00) > Java version: 1.7.0_76, vendor: Oracle Corporation >Reporter: chibbe >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.7.0-candidate > > Attachments: > 0001-MNG-5939-Addresses-duplicate-attached-artifact-probl.patch, foo.bar.zip > > > If I specified that sources should be generated with jar-no-fork goal > https://maven.apache.org/plugins/maven-source-plugin/jar-no-fork-mojo.html . > When doing a release with maven-release-plugin it will build the source again > when useReleaseProfile is true (use the release profile that adds sources and > javadocs to the released artifact > http://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#useReleaseProfile). > The outcome is that it will run with both jar and jar-no-fork and generate > and deploy 2 -sources.jar artifacts, with same version. That makes the > release build fails. > > The same behavior could be reproduced when running both jar and jar-no-fork > goal between maven 3.2.1. and maven 3.3.9. > > Please find the logs for maven 3.2.1 and 3.3.9 in the foo.bar.zip > With maven 3.3.9 it uploads it 2 times : > Uploaded: > http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar > (722 B at 15.3 KB/sec) > Uploading: > http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar > 722/722 B -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-114) ArtifactNotFoundExceptions when building in parallel
[
https://issues.apache.org/jira/browse/MRESOLVER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128512#comment-17128512
]
Robert Scholte commented on MRESOLVER-114:
--
Let me try to find someone with enough experience whoe wants to help on this
topic.
> ArtifactNotFoundExceptions when building in parallel
>
>
> Key: MRESOLVER-114
> URL: https://issues.apache.org/jira/browse/MRESOLVER-114
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Rainer Reich
>Priority: Major
> Attachments: maven-debug-log.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a multi-module project with quite many modules and many dependencies
> and observe pretty random {{ArtifactNotFoundExceptions}} when building in
> parallel with an empty local repository.
> The "funny" thing is that Maven did in fact download the jar that it
> complained about not finding.
> In this example Maven said it could not find
> {{edu.tum.cs:cup-runtime:jar:11a}} (see stacktrace below)
> But it also said: {{Downloaded from central-mirror:
> [https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar]}}.
> When looking into the local repository after the failed build we found the
> cup-runtime.jar in the correct place with the correct checksum.
> We tried the following to "fix" the problem:
> * build with and without the takari extensions ({{takari-local-repository}}
> & {{takari-smart-builder}}) using {{--builder smart}}
> * also build with {{io.takari.aether:aether-connector-okhttp}} extension
> * only execute goal package instead of install
> * build with these properties: {{-Daether.connector.basic.threads=1
> -Daether.connector.resumeDownloads=false}}
> But nothing helped.
> Unfortunately it seems to be a race condition and we cannot reproduce it
> consistently but it happens in about 1 out of 5 builds.
> {code:java}
> ...
> [2019-11-18T16:46:29.370Z] [INFO] Downloaded from central-mirror:
> https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar
> (13 kB at 738 kB/s)
> ...
> [2019-11-18T16:46:30.894Z] [ERROR] Failed to execute goal on project xy:
> Could not resolve dependencies for project xy: The following artifacts could
> not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> -> [Help 1]
> [2019-11-18T16:46:30.894Z]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project xy: Could not resolve dependencies for project xy: The
> following artifacts could not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject
> (SmartBuilderImpl.java:205)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run
> (SmartBuilderImpl.java:77)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
> [2019-11-18T16:46:30.894Z] at java.util.concurrent.FutureTask.run
> (FutureTask.java:264)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1128)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:628)
> [2019-11-18T16:46:30.894Z] at java.lang.Thread.run (Thread.java:834)
> [2019-11-18T16:46:30.894Z] Caused by:
>
[jira] [Commented] (MNGSITE-413) [CREATE] Maven Website (2020)
[ https://issues.apache.org/jira/browse/MNGSITE-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128490#comment-17128490 ] Robert Scholte commented on MNGSITE-413: It needs a complete redesign. The main page is an overload of text, links, and scares aways newbies, because it is missing overview. you simply get lost if you don't understand the structure. You can see it was made by backend developers, we need help from frontend developers and imrpove the UX. > [CREATE] Maven Website (2020) > -- > > Key: MNGSITE-413 > URL: https://issues.apache.org/jira/browse/MNGSITE-413 > Project: Maven Project Web Site > Issue Type: Task >Reporter: Amelia Eiras >Assignee: Robert Scholte >Priority: Major > > Maven is such a formidable project that requires everyone: > users/coders/contributors alike to properly THANK this ecosystem. > As such, Tomitribe has happily volunteered to collaborate with the wonderful > MavenCommitters on the creation of the Maven website in 2020. > Documentation on requirements [HERE > |https://drive.google.com/drive/folders/1LZyHFJ4XD-mMkL8rcMnfoGj7GMhB0ZIJ?usp=sharing] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MEAR-281) DocumentBuilderFactory not namespace aware in AbstractEarPluginIT
[ https://issues.apache.org/jira/browse/MEAR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128437#comment-17128437 ] Elliotte Rusty Harold commented on MEAR-281: Yes, without this the namespaces wont be checked. This is a very common omission hen using DocumentBuilderFactory. Sun got the defaults wrong. > DocumentBuilderFactory not namespace aware in AbstractEarPluginIT > - > > Key: MEAR-281 > URL: https://issues.apache.org/jira/browse/MEAR-281 > Project: Maven Ear Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > around line 384 > DocumentBuilderFactory dbf = > DocumentBuilderFactory.newInstance(); > dbf.setValidating( true ); > DocumentBuilder docBuilder = dbf.newDocumentBuilder(); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MDEPLOY-271) Allow to optionally disable checksum creation
[ https://issues.apache.org/jira/browse/MDEPLOY-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128409#comment-17128409 ] Konrad Windszus edited comment on MDEPLOY-271 at 6/8/20, 4:15 PM: -- Unfortunately using older version 2.8.2 or older is no option either, as there https://github.com/apache/maven-deploy-plugin/blob/3b62d2a0bd33119194f5605ea0d281652c7d934f/src/main/java/org/apache/maven/plugin/deploy/AbstractDeployMojo.java#L171 -> https://github.com/apache/maven-artifact/blob/ab6be5e8c9d05f20dd37f813063482493788d1e9/src/main/java/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.java#L109 -> https://github.com/apache/maven/blob/a2b800de32cdb9adc1e64a43a0fc32e3ba878103/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultWagonManager.java#L634 is used which generates those checksums as well with no option to disable it. was (Author: kwin): Unfortunately using older version 2.8.2 is no option either, as there https://github.com/apache/maven-deploy-plugin/blob/3b62d2a0bd33119194f5605ea0d281652c7d934f/src/main/java/org/apache/maven/plugin/deploy/AbstractDeployMojo.java#L171 -> https://github.com/apache/maven-artifact/blob/ab6be5e8c9d05f20dd37f813063482493788d1e9/src/main/java/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.java#L109 -> https://github.com/apache/maven/blob/a2b800de32cdb9adc1e64a43a0fc32e3ba878103/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultWagonManager.java#L634 is used which generates those checksums as well with no option to disable it. > Allow to optionally disable checksum creation > - > > Key: MDEPLOY-271 > URL: https://issues.apache.org/jira/browse/MDEPLOY-271 > Project: Maven Deploy Plugin > Issue Type: Improvement >Affects Versions: 3.0.0-M1 >Reporter: Konrad Windszus >Priority: Major > > Since 3.0.0-M1 the deploy goal will always generate SHA1/MD5 for all attached > artifacts. The old configuration option > https://maven.apache.org/plugins-archives/maven-install-plugin-2.4/install-mojo.html#createChecksum > is no longer exposed in the maven-deploy-plugin. That leads to the fact the > m-deploy-plugin 3.0.0-M1 will generate MD5/SHA1 even for attached SHA-512 > artifacts (generated with > https://checksum-maven-plugin.nicoulaj.net/artifacts-mojo.html) which are > supported by Nexus since https://issues.sonatype.org/browse/NEXUS-21802. > It would be nice if one would be able to configure _*which artifacts > (regex/glob on artifactId) should receive which hashes (algorithm)*_. > That way generating only MD5 or SHA1 would be possible and also exclusion of > checksums for certain attached artifacts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MDEPLOY-271) Allow to optionally disable checksum creation
[ https://issues.apache.org/jira/browse/MDEPLOY-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128409#comment-17128409 ] Konrad Windszus edited comment on MDEPLOY-271 at 6/8/20, 4:15 PM: -- Unfortunately using older version 2.8.2 is no option either, as there https://github.com/apache/maven-deploy-plugin/blob/3b62d2a0bd33119194f5605ea0d281652c7d934f/src/main/java/org/apache/maven/plugin/deploy/AbstractDeployMojo.java#L171 -> https://github.com/apache/maven-artifact/blob/ab6be5e8c9d05f20dd37f813063482493788d1e9/src/main/java/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.java#L109 -> https://github.com/apache/maven/blob/a2b800de32cdb9adc1e64a43a0fc32e3ba878103/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultWagonManager.java#L634 is used which generates those checksums as well with no option to disable it. was (Author: kwin): Unfortunately using older version 2.8.2 is no option either, as there https://github.com/apache/maven/blob/a2b800de32cdb9adc1e64a43a0fc32e3ba878103/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultWagonManager.java#L634 is used, which generates those checksums as well with no option to disable it. > Allow to optionally disable checksum creation > - > > Key: MDEPLOY-271 > URL: https://issues.apache.org/jira/browse/MDEPLOY-271 > Project: Maven Deploy Plugin > Issue Type: Improvement >Affects Versions: 3.0.0-M1 >Reporter: Konrad Windszus >Priority: Major > > Since 3.0.0-M1 the deploy goal will always generate SHA1/MD5 for all attached > artifacts. The old configuration option > https://maven.apache.org/plugins-archives/maven-install-plugin-2.4/install-mojo.html#createChecksum > is no longer exposed in the maven-deploy-plugin. That leads to the fact the > m-deploy-plugin 3.0.0-M1 will generate MD5/SHA1 even for attached SHA-512 > artifacts (generated with > https://checksum-maven-plugin.nicoulaj.net/artifacts-mojo.html) which are > supported by Nexus since https://issues.sonatype.org/browse/NEXUS-21802. > It would be nice if one would be able to configure _*which artifacts > (regex/glob on artifactId) should receive which hashes (algorithm)*_. > That way generating only MD5 or SHA1 would be possible and also exclusion of > checksums for certain attached artifacts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEPLOY-231) Move checksum generation from install to deploy plugin
[ https://issues.apache.org/jira/browse/MDEPLOY-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128416#comment-17128416 ] Konrad Windszus commented on MDEPLOY-231: - Just for the record, prior to 3.0.0-M1 the MD5 and SHA1 checksums also have been created via https://github.com/apache/maven-deploy-plugin/blob/3b62d2a0bd33119194f5605ea0d281652c7d934f/src/main/java/org/apache/maven/plugin/deploy/AbstractDeployMojo.java#L171 -> https://github.com/apache/maven-artifact/blob/ab6be5e8c9d05f20dd37f813063482493788d1e9/src/main/java/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.java#L109 -> https://github.com/apache/maven/blob/a2b800de32cdb9adc1e64a43a0fc32e3ba878103/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultWagonManager.java#L634 > Move checksum generation from install to deploy plugin > -- > > Key: MDEPLOY-231 > URL: https://issues.apache.org/jira/browse/MDEPLOY-231 > Project: Maven Deploy Plugin > Issue Type: Improvement >Affects Versions: 3.0.0-M1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Blocker > Fix For: 3.0.0-M1 > > > It is need to consistently move the checksum generation into > maven-deploy-plugin which means to change the maven-artifact-transfer > component accordingly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEPLOY-271) Allow to optionally disable checksum creation
[ https://issues.apache.org/jira/browse/MDEPLOY-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128409#comment-17128409 ] Konrad Windszus commented on MDEPLOY-271: - Unfortunately using older version 2.8.2 is no option either, as there https://github.com/apache/maven/blob/a2b800de32cdb9adc1e64a43a0fc32e3ba878103/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultWagonManager.java#L634 is used, which generates those checksums as well with no option to disable it. > Allow to optionally disable checksum creation > - > > Key: MDEPLOY-271 > URL: https://issues.apache.org/jira/browse/MDEPLOY-271 > Project: Maven Deploy Plugin > Issue Type: Improvement >Affects Versions: 3.0.0-M1 >Reporter: Konrad Windszus >Priority: Major > > Since 3.0.0-M1 the deploy goal will always generate SHA1/MD5 for all attached > artifacts. The old configuration option > https://maven.apache.org/plugins-archives/maven-install-plugin-2.4/install-mojo.html#createChecksum > is no longer exposed in the maven-deploy-plugin. That leads to the fact the > m-deploy-plugin 3.0.0-M1 will generate MD5/SHA1 even for attached SHA-512 > artifacts (generated with > https://checksum-maven-plugin.nicoulaj.net/artifacts-mojo.html) which are > supported by Nexus since https://issues.sonatype.org/browse/NEXUS-21802. > It would be nice if one would be able to configure _*which artifacts > (regex/glob on artifactId) should receive which hashes (algorithm)*_. > That way generating only MD5 or SHA1 would be possible and also exclusion of > checksums for certain attached artifacts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEPLOY-272) Add skip capability to deploy-file goal
[ https://issues.apache.org/jira/browse/MDEPLOY-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128345#comment-17128345 ] Tom Esh commented on MDEPLOY-272: - I can create one. Just making sure that there are not major objections to this capability. > Add skip capability to deploy-file goal > --- > > Key: MDEPLOY-272 > URL: https://issues.apache.org/jira/browse/MDEPLOY-272 > Project: Maven Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: Tom Esh >Priority: Major > > Currently the deploy-file goal doesn't support the > configuration parameter. > I have a case where that would be very useful, as I would like to > conditionally deploy a file based on a maven property. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEPLOY-272) Add skip capability to deploy-file goal
[ https://issues.apache.org/jira/browse/MDEPLOY-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128316#comment-17128316 ] Michael Osipov commented on MDEPLOY-272: PR? > Add skip capability to deploy-file goal > --- > > Key: MDEPLOY-272 > URL: https://issues.apache.org/jira/browse/MDEPLOY-272 > Project: Maven Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: Tom Esh >Priority: Major > > Currently the deploy-file goal doesn't support the > configuration parameter. > I have a case where that would be very useful, as I would like to > conditionally deploy a file based on a maven property. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MEAR-281) DocumentBuilderFactory not namespace aware in AbstractEarPluginIT
[ https://issues.apache.org/jira/browse/MEAR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128317#comment-17128317 ] Michael Osipov commented on MEAR-281: - Does it require to be? > DocumentBuilderFactory not namespace aware in AbstractEarPluginIT > - > > Key: MEAR-281 > URL: https://issues.apache.org/jira/browse/MEAR-281 > Project: Maven Ear Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > around line 384 > DocumentBuilderFactory dbf = > DocumentBuilderFactory.newInstance(); > dbf.setValidating( true ); > DocumentBuilder docBuilder = dbf.newDocumentBuilder(); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MDEPLOY-272) Add skip capability to deploy-file goal
Tom Esh created MDEPLOY-272: --- Summary: Add skip capability to deploy-file goal Key: MDEPLOY-272 URL: https://issues.apache.org/jira/browse/MDEPLOY-272 Project: Maven Deploy Plugin Issue Type: New Feature Components: deploy:deploy-file Affects Versions: 3.0.0-M1 Reporter: Tom Esh Currently the deploy-file goal doesn't support the configuration parameter. I have a case where that would be very useful, as I would like to conditionally deploy a file based on a maven property. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6935) maven3.6.1 deploy fail
[
https://issues.apache.org/jira/browse/MNG-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6935:
External issue URL: (was: https://issues.apache.org/jira/browse/MNG-6469)
> maven3.6.1 deploy fail
> --
>
> Key: MNG-6935
> URL: https://issues.apache.org/jira/browse/MNG-6935
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.6.1
> Environment: maven3.6.1
> nexus3
> nginx 1.15
> os: windows10
>Reporter: hb0730
>Assignee: Michael Osipov
>Priority: Major
>
> When using Maven 3.6.1 native deployment, there will be errors, but maven
> 3.3.9 deployment can be accessed normally, but I can only use HTTP
> {code:java}
> Failed to dispatch transfer event 'PUT PROGRESSED
> http://nexus.hohofast.natapp1.cc/repository/maven-snapshots/com/hohofast/hohofast-recovery/1.0.0-SNAPSHOT/hohofast-recovery-1.0.0-20200608.031900-4.jar
> <>
> E:\IdeaWork\hohofast-work\hohofast-recovery\target\hohofast-recovery-1.0.0-SNAPSHOT.jar'
> to org.apache.maven.cli.transfer.ConsoleMavenTransferListener
> java.lang.IllegalArgumentException: progressed file size cannot be greater
> than size: 131304578 > 85167234 at org.apache.commons.lang3.Validate.isTrue
> (Validate.java:158) at
> org.apache.maven.cli.transfer.AbstractMavenTransferListener$FileSizeFormat.formatProgress
> (AbstractMavenTransferListener.java:195) at
> org.apache.maven.cli.transfer.ConsoleMavenTransferListener.getStatus
> (ConsoleMavenTransferListener.java:117) at
> org.apache.maven.cli.transfer.ConsoleMavenTransferListener.transferProgressed
> (ConsoleMavenTransferListener.java:90) at
> org.eclipse.aether.internal.impl.SafeTransferListener.transferProgressed
> (SafeTransferListener.java:105) at
> org.eclipse.aether.connector.basic.TransferTransportListener.transportProgressed
> (TransferTransportListener.java:95) at
> org.eclipse.aether.transport.wagon.WagonTransferListener.transferProgress
> (WagonTransferListener.java:64) at
> org.apache.maven.wagon.events.TransferEventSupport.fireTransferProgress
> (TransferEventSupport.java:121) at
> org.apache.maven.wagon.AbstractWagon.fireTransferProgress
> (AbstractWagon.java:658) at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.access$200
> (AbstractHttpClientWagon.java:112) at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon$RequestEntityImplementation.writeTo
> (AbstractHttpClientWagon.java:214) at
> org.apache.maven.wagon.providers.http.httpclient.impl.DefaultBHttpClientConnection.sendRequestEntity
> (DefaultBHttpClientConnection.java:156) at
> org.apache.maven.wagon.providers.http.httpclient.impl.conn.CPoolProxy.sendRequestEntity
> (CPoolProxy.java:152) at
> org.apache.maven.wagon.providers.http.httpclient.protocol.HttpRequestExecutor.doSendRequest
> (HttpRequestExecutor.java:238) at
> org.apache.maven.wagon.providers.http.httpclient.protocol.HttpRequestExecutor.execute
> (HttpRequestExecutor.java:123) at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.MainClientExec.execute
> (MainClientExec.java:272) at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.ProtocolExec.execute
> (ProtocolExec.java:185) at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec.execute
> (RetryExec.java:89) 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:185) at
> org.apache.maven.wagon.providers.http.httpclient.impl.client.CloseableHttpClient.execute
> (CloseableHttpClient.java:83) at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.execute
> (AbstractHttpClientWagon.java:958) at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:713) at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:670) at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:652) at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:646) at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:626) at
> org.eclipse.aether.transport.wagon.WagonTransporter$PutTaskRunner.run
> (WagonTransporter.java:686) at
> org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:435) at
> org.eclipse.aether.transport.wagon.WagonTransporter.put
> (WagonTransporter.java:418) at
>
[jira] [Created] (MEAR-281) DocumentBuilderFactory not namespace aware in AbstractEarPluginIT
Elliotte Rusty Harold created MEAR-281: -- Summary: DocumentBuilderFactory not namespace aware in AbstractEarPluginIT Key: MEAR-281 URL: https://issues.apache.org/jira/browse/MEAR-281 Project: Maven Ear Plugin Issue Type: Bug Reporter: Elliotte Rusty Harold around line 384 DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); dbf.setValidating( true ); DocumentBuilder docBuilder = dbf.newDocumentBuilder(); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEPLOY-271) Allow to optionally disable checksum creation
[ https://issues.apache.org/jira/browse/MDEPLOY-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated MDEPLOY-271: Description: Since 3.0.0-M1 the deploy goal will always generate SHA1/MD5 for all attached artifacts. The old configuration option https://maven.apache.org/plugins-archives/maven-install-plugin-2.4/install-mojo.html#createChecksum is no longer exposed in the maven-deploy-plugin. That leads to the fact the m-deploy-plugin 3.0.0-M1 will generate MD5/SHA1 even for attached SHA-512 artifacts (generated with https://checksum-maven-plugin.nicoulaj.net/artifacts-mojo.html) which are supported by Nexus since https://issues.sonatype.org/browse/NEXUS-21802. It would be nice if one would be able to configure _*which artifacts (regex/glob on artifactId) should receive which hashes (algorithm)*_. That way generating only MD5 or SHA1 would be possible and also exclusion of checksums for certain attached artifacts. was:Since 3.0.0-M1 the deploy goal will always generate SHA1/MD5 for all attached artifacts. The old configuration option https://maven.apache.org/plugins-archives/maven-install-plugin-2.4/install-mojo.html#createChecksum is no longer exposed in the maven-deploy-plugin. That leads to the fact the m-deploy-plugin 3.0.0-M1 will generate MD5/SHA1 even for attached SHA-512 artifacts (generated with https://checksum-maven-plugin.nicoulaj.net/artifacts-mojo.html) which are supported by Nexus since https://issues.sonatype.org/browse/NEXUS-21802. > Allow to optionally disable checksum creation > - > > Key: MDEPLOY-271 > URL: https://issues.apache.org/jira/browse/MDEPLOY-271 > Project: Maven Deploy Plugin > Issue Type: Improvement >Affects Versions: 3.0.0-M1 >Reporter: Konrad Windszus >Priority: Major > > Since 3.0.0-M1 the deploy goal will always generate SHA1/MD5 for all attached > artifacts. The old configuration option > https://maven.apache.org/plugins-archives/maven-install-plugin-2.4/install-mojo.html#createChecksum > is no longer exposed in the maven-deploy-plugin. That leads to the fact the > m-deploy-plugin 3.0.0-M1 will generate MD5/SHA1 even for attached SHA-512 > artifacts (generated with > https://checksum-maven-plugin.nicoulaj.net/artifacts-mojo.html) which are > supported by Nexus since https://issues.sonatype.org/browse/NEXUS-21802. > It would be nice if one would be able to configure _*which artifacts > (regex/glob on artifactId) should receive which hashes (algorithm)*_. > That way generating only MD5 or SHA1 would be possible and also exclusion of > checksums for certain attached artifacts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MNG-6935) maven3.6.1 deploy fail
[
https://issues.apache.org/jira/browse/MNG-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-6935:
---
Assignee: Michael Osipov
> maven3.6.1 deploy fail
> --
>
> Key: MNG-6935
> URL: https://issues.apache.org/jira/browse/MNG-6935
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.6.1
> Environment: maven3.6.1
> nexus3
> nginx 1.15
> os: windows10
>Reporter: hb0730
>Assignee: Michael Osipov
>Priority: Major
>
> When using Maven 3.6.1 native deployment, there will be errors, but maven
> 3.3.9 deployment can be accessed normally, but I can only use HTTP
> {code:java}
> Failed to dispatch transfer event 'PUT PROGRESSED
> http://nexus.hohofast.natapp1.cc/repository/maven-snapshots/com/hohofast/hohofast-recovery/1.0.0-SNAPSHOT/hohofast-recovery-1.0.0-20200608.031900-4.jar
> <>
> E:\IdeaWork\hohofast-work\hohofast-recovery\target\hohofast-recovery-1.0.0-SNAPSHOT.jar'
> to org.apache.maven.cli.transfer.ConsoleMavenTransferListener
> java.lang.IllegalArgumentException: progressed file size cannot be greater
> than size: 131304578 > 85167234 at org.apache.commons.lang3.Validate.isTrue
> (Validate.java:158) at
> org.apache.maven.cli.transfer.AbstractMavenTransferListener$FileSizeFormat.formatProgress
> (AbstractMavenTransferListener.java:195) at
> org.apache.maven.cli.transfer.ConsoleMavenTransferListener.getStatus
> (ConsoleMavenTransferListener.java:117) at
> org.apache.maven.cli.transfer.ConsoleMavenTransferListener.transferProgressed
> (ConsoleMavenTransferListener.java:90) at
> org.eclipse.aether.internal.impl.SafeTransferListener.transferProgressed
> (SafeTransferListener.java:105) at
> org.eclipse.aether.connector.basic.TransferTransportListener.transportProgressed
> (TransferTransportListener.java:95) at
> org.eclipse.aether.transport.wagon.WagonTransferListener.transferProgress
> (WagonTransferListener.java:64) at
> org.apache.maven.wagon.events.TransferEventSupport.fireTransferProgress
> (TransferEventSupport.java:121) at
> org.apache.maven.wagon.AbstractWagon.fireTransferProgress
> (AbstractWagon.java:658) at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.access$200
> (AbstractHttpClientWagon.java:112) at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon$RequestEntityImplementation.writeTo
> (AbstractHttpClientWagon.java:214) at
> org.apache.maven.wagon.providers.http.httpclient.impl.DefaultBHttpClientConnection.sendRequestEntity
> (DefaultBHttpClientConnection.java:156) at
> org.apache.maven.wagon.providers.http.httpclient.impl.conn.CPoolProxy.sendRequestEntity
> (CPoolProxy.java:152) at
> org.apache.maven.wagon.providers.http.httpclient.protocol.HttpRequestExecutor.doSendRequest
> (HttpRequestExecutor.java:238) at
> org.apache.maven.wagon.providers.http.httpclient.protocol.HttpRequestExecutor.execute
> (HttpRequestExecutor.java:123) at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.MainClientExec.execute
> (MainClientExec.java:272) at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.ProtocolExec.execute
> (ProtocolExec.java:185) at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec.execute
> (RetryExec.java:89) 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:185) at
> org.apache.maven.wagon.providers.http.httpclient.impl.client.CloseableHttpClient.execute
> (CloseableHttpClient.java:83) at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.execute
> (AbstractHttpClientWagon.java:958) at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:713) at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:670) at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:652) at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:646) at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.put
> (AbstractHttpClientWagon.java:626) at
> org.eclipse.aether.transport.wagon.WagonTransporter$PutTaskRunner.run
> (WagonTransporter.java:686) at
> org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:435) at
> org.eclipse.aether.transport.wagon.WagonTransporter.put
> (WagonTransporter.java:418) at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$PutTaskRunner.runTask
>
[jira] [Created] (MDEPLOY-271) Allow to optionally disable checksum creation
Konrad Windszus created MDEPLOY-271: --- Summary: Allow to optionally disable checksum creation Key: MDEPLOY-271 URL: https://issues.apache.org/jira/browse/MDEPLOY-271 Project: Maven Deploy Plugin Issue Type: Improvement Affects Versions: 3.0.0-M1 Reporter: Konrad Windszus Since 3.0.0-M1 the deploy goal will always generate SHA1/MD5 for all attached artifacts. The old configuration option https://maven.apache.org/plugins-archives/maven-install-plugin-2.4/install-mojo.html#createChecksum is no longer exposed in the maven-deploy-plugin. That leads to the fact the m-deploy-plugin 3.0.0-M1 will generate MD5/SHA1 even for attached SHA-512 artifacts (generated with https://checksum-maven-plugin.nicoulaj.net/artifacts-mojo.html) which are supported by Nexus since https://issues.sonatype.org/browse/NEXUS-21802. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1730) Exception in BeforeAll and AfterAll is not handled
[ https://issues.apache.org/jira/browse/SUREFIRE-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128221#comment-17128221 ] David Kornel commented on SUREFIRE-1730: [~tibordigana] do you have release date of surefire M5? :) > Exception in BeforeAll and AfterAll is not handled > --- > > Key: SUREFIRE-1730 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1730 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 3.0.0-M4 >Reporter: David Kornel >Assignee: Tibor Digana >Priority: Major > > If exception is thrown in `@BeforeAll`, `@AfterAll` surefire skip tests in > class and mark testrun as success. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MINSTALL-138) option to calculate more checksum such sha-256 sha-512
[ https://issues.apache.org/jira/browse/MINSTALL-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17127599#comment-17127599 ] Konrad Windszus edited comment on MINSTALL-138 at 6/8/20, 11:24 AM: bq. but adding sha-512 checksums for absolutely every file in the Maven repository is just overkill IMHO I don't agree here. We are talking about 128 byte for SHA512. IMHO always adding both SHA1 and MD5 is no longer necessary. Maybe just using SHA512 instead of SHA1 (=40 bytes) in addition to MD5 (for older clients) is a reasonable default. That way we are only talking about 88 bytes more for checksums. was (Author: kwin): bq. but adding sha-512 checksums for absolutely every file in the Maven repository is just overkill IMHO I don't agree here. We are talking about 64 byte for SHA512. IMHO always adding both SHA1 and MD5 is no longer necessary. Maybe just using SHA512 instead of SHA1 in addition to MD5 (for older clients) is a reasonable default. That way we are only talking about 56 byte more for checksums. > option to calculate more checksum such sha-256 sha-512 > -- > > Key: MINSTALL-138 > URL: https://issues.apache.org/jira/browse/MINSTALL-138 > Project: Maven Install Plugin > Issue Type: New Feature > Components: install:install, install:install-file >Affects Versions: 2.5.2 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > > currently install generate only sha-1 we should be able to generate sha-256 > and sha-512 as well. > NOTE: sha-512 will be required by Apache policy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MPOM-244) Upload SHA-512 to Staging Repository
[ https://issues.apache.org/jira/browse/MPOM-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated MPOM-244: - Description: As now the ASF staging repository supports SHA2 hashes (https://issues.apache.org/jira/browse/INFRA-14923) they should be generated for - all attached artifacts and - deployed to the Staging repository (i.e. attached to build as well) was: As now the ASF staging repository supports SHA2 hashes (https://issues.apache.org/jira/browse/INFRA-14923) they should be generated for - all attached artifacts and - deployed to the Staging repository > Upload SHA-512 to Staging Repository > > > Key: MPOM-244 > URL: https://issues.apache.org/jira/browse/MPOM-244 > Project: Maven POMs > Issue Type: Improvement >Affects Versions: ASF-23 >Reporter: Konrad Windszus >Priority: Major > > As now the ASF staging repository supports SHA2 hashes > (https://issues.apache.org/jira/browse/INFRA-14923) they should be generated > for > - all attached artifacts and > - deployed to the Staging repository (i.e. attached to build as well) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MRESOLVER-114) ArtifactNotFoundExceptions when building in parallel
[
https://issues.apache.org/jira/browse/MRESOLVER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128180#comment-17128180
]
Michael Osipov edited comment on MRESOLVER-114 at 6/8/20, 11:13 AM:
[~rreich], correct. That kind of synchronization is useless in your case. Can
you provide a new failure log w/o Takari extensions, but with HttpClient debug
logs for headers? Wire not necessary. I want to see whether another transport
happens at all. I will take another look at the Takari extension again.
[~emueller-coremedia], it is always good to file an issue for the sake of
documentation/reference. Please try also the extension from master and see
whether this makes a difference or not.
Are you both in Hamburg?
was (Author: michael-o):
[~rreich], correct. That kind of synchronization is useless in your case. Can
you provide a new failure log w/o Takari extensions, but with HttpClient debug
logs for headers? Wire not necessary. I want to see whether another transport
happens at all. I will take another look at the Takari extension again.
[~emueller-coremedia], it is always good to file an issue for the sake of
documentation/reference. Please try also the extension from master and see
whether this makes a difference or not.
> ArtifactNotFoundExceptions when building in parallel
>
>
> Key: MRESOLVER-114
> URL: https://issues.apache.org/jira/browse/MRESOLVER-114
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Rainer Reich
>Priority: Major
> Attachments: maven-debug-log.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a multi-module project with quite many modules and many dependencies
> and observe pretty random {{ArtifactNotFoundExceptions}} when building in
> parallel with an empty local repository.
> The "funny" thing is that Maven did in fact download the jar that it
> complained about not finding.
> In this example Maven said it could not find
> {{edu.tum.cs:cup-runtime:jar:11a}} (see stacktrace below)
> But it also said: {{Downloaded from central-mirror:
> [https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar]}}.
> When looking into the local repository after the failed build we found the
> cup-runtime.jar in the correct place with the correct checksum.
> We tried the following to "fix" the problem:
> * build with and without the takari extensions ({{takari-local-repository}}
> & {{takari-smart-builder}}) using {{--builder smart}}
> * also build with {{io.takari.aether:aether-connector-okhttp}} extension
> * only execute goal package instead of install
> * build with these properties: {{-Daether.connector.basic.threads=1
> -Daether.connector.resumeDownloads=false}}
> But nothing helped.
> Unfortunately it seems to be a race condition and we cannot reproduce it
> consistently but it happens in about 1 out of 5 builds.
> {code:java}
> ...
> [2019-11-18T16:46:29.370Z] [INFO] Downloaded from central-mirror:
> https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar
> (13 kB at 738 kB/s)
> ...
> [2019-11-18T16:46:30.894Z] [ERROR] Failed to execute goal on project xy:
> Could not resolve dependencies for project xy: The following artifacts could
> not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> -> [Help 1]
> [2019-11-18T16:46:30.894Z]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project xy: Could not resolve dependencies for project xy: The
> following artifacts could not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
>
[jira] [Commented] (MRESOLVER-114) ArtifactNotFoundExceptions when building in parallel
[
https://issues.apache.org/jira/browse/MRESOLVER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128180#comment-17128180
]
Michael Osipov commented on MRESOLVER-114:
--
[~rreich], correct. That kind of synchronization is useless in your case. Can
you provide a new failure log w/o Takari extensions, but with HttpClient debug
logs for headers? Wire not necessary. I want to see whether another transport
happens at all. I will take another look at the Takari extension again.
[~emueller-coremedia], it is always good to file an issue for the sake of
documentation/reference. Please try also the extension from master and see
whether this makes a difference or not.
> ArtifactNotFoundExceptions when building in parallel
>
>
> Key: MRESOLVER-114
> URL: https://issues.apache.org/jira/browse/MRESOLVER-114
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Rainer Reich
>Priority: Major
> Attachments: maven-debug-log.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a multi-module project with quite many modules and many dependencies
> and observe pretty random {{ArtifactNotFoundExceptions}} when building in
> parallel with an empty local repository.
> The "funny" thing is that Maven did in fact download the jar that it
> complained about not finding.
> In this example Maven said it could not find
> {{edu.tum.cs:cup-runtime:jar:11a}} (see stacktrace below)
> But it also said: {{Downloaded from central-mirror:
> [https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar]}}.
> When looking into the local repository after the failed build we found the
> cup-runtime.jar in the correct place with the correct checksum.
> We tried the following to "fix" the problem:
> * build with and without the takari extensions ({{takari-local-repository}}
> & {{takari-smart-builder}}) using {{--builder smart}}
> * also build with {{io.takari.aether:aether-connector-okhttp}} extension
> * only execute goal package instead of install
> * build with these properties: {{-Daether.connector.basic.threads=1
> -Daether.connector.resumeDownloads=false}}
> But nothing helped.
> Unfortunately it seems to be a race condition and we cannot reproduce it
> consistently but it happens in about 1 out of 5 builds.
> {code:java}
> ...
> [2019-11-18T16:46:29.370Z] [INFO] Downloaded from central-mirror:
> https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar
> (13 kB at 738 kB/s)
> ...
> [2019-11-18T16:46:30.894Z] [ERROR] Failed to execute goal on project xy:
> Could not resolve dependencies for project xy: The following artifacts could
> not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> -> [Help 1]
> [2019-11-18T16:46:30.894Z]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project xy: Could not resolve dependencies for project xy: The
> following artifacts could not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject
> (SmartBuilderImpl.java:205)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run
> (SmartBuilderImpl.java:77)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
> [2019-11-18T16:46:30.894Z] at
[GitHub] [maven-shared-utils] elharo merged pull request #51: [MSHARED-919] deprecate defaultString since it's now in the JDK
elharo merged pull request #51: URL: https://github.com/apache/maven-shared-utils/pull/51 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MSHARED-919) Deprecate StringUtils.defaultString
[ https://issues.apache.org/jira/browse/MSHARED-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MSHARED-919. - > Deprecate StringUtils.defaultString > --- > > Key: MSHARED-919 > URL: https://issues.apache.org/jira/browse/MSHARED-919 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Priority: Minor > > In favor of Objects.toString() -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MSHARED-919) Deprecate StringUtils.defaultString
[ https://issues.apache.org/jira/browse/MSHARED-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHARED-919. --- Resolution: Fixed > Deprecate StringUtils.defaultString > --- > > Key: MSHARED-919 > URL: https://issues.apache.org/jira/browse/MSHARED-919 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Priority: Minor > > In favor of Objects.toString() -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-shared-utils] elharo merged pull request #51: [MSHARED-919] deprecate defaultString since it's now in the JDK
elharo merged pull request #51: URL: https://github.com/apache/maven-shared-utils/pull/51 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MSHARED-918) Deprecate StringUtils.equals
[ https://issues.apache.org/jira/browse/MSHARED-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MSHARED-918. - > Deprecate StringUtils.equals > > > Key: MSHARED-918 > URL: https://issues.apache.org/jira/browse/MSHARED-918 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Priority: Minor > > In favor of Objects.equals -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MSHARED-918) Deprecate StringUtils.equals
[ https://issues.apache.org/jira/browse/MSHARED-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHARED-918. --- Resolution: Fixed > Deprecate StringUtils.equals > > > Key: MSHARED-918 > URL: https://issues.apache.org/jira/browse/MSHARED-918 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Priority: Minor > > In favor of Objects.equals -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-shared-utils] elharo merged pull request #50: [MSHARED-918] deprecate equals in favor of Objects.equals()
elharo merged pull request #50: URL: https://github.com/apache/maven-shared-utils/pull/50 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-114) ArtifactNotFoundExceptions when building in parallel
[
https://issues.apache.org/jira/browse/MRESOLVER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128105#comment-17128105
]
Eva Müller commented on MRESOLVER-114:
--
Maybe it's worth to open an
[issue|https://github.com/takari/takari-local-repository/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc]
for this?
Although the [latest release
(takari-local-repository-0.11.2)|https://github.com/takari/takari-local-repository/tree/takari-local-repository-0.11.2]
was on 18 Aug 2015,
the last [commit on
master|https://github.com/takari/takari-local-repository/commits/master] was on
22 Nov 2019.
> ArtifactNotFoundExceptions when building in parallel
>
>
> Key: MRESOLVER-114
> URL: https://issues.apache.org/jira/browse/MRESOLVER-114
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Rainer Reich
>Priority: Major
> Attachments: maven-debug-log.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a multi-module project with quite many modules and many dependencies
> and observe pretty random {{ArtifactNotFoundExceptions}} when building in
> parallel with an empty local repository.
> The "funny" thing is that Maven did in fact download the jar that it
> complained about not finding.
> In this example Maven said it could not find
> {{edu.tum.cs:cup-runtime:jar:11a}} (see stacktrace below)
> But it also said: {{Downloaded from central-mirror:
> [https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar]}}.
> When looking into the local repository after the failed build we found the
> cup-runtime.jar in the correct place with the correct checksum.
> We tried the following to "fix" the problem:
> * build with and without the takari extensions ({{takari-local-repository}}
> & {{takari-smart-builder}}) using {{--builder smart}}
> * also build with {{io.takari.aether:aether-connector-okhttp}} extension
> * only execute goal package instead of install
> * build with these properties: {{-Daether.connector.basic.threads=1
> -Daether.connector.resumeDownloads=false}}
> But nothing helped.
> Unfortunately it seems to be a race condition and we cannot reproduce it
> consistently but it happens in about 1 out of 5 builds.
> {code:java}
> ...
> [2019-11-18T16:46:29.370Z] [INFO] Downloaded from central-mirror:
> https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar
> (13 kB at 738 kB/s)
> ...
> [2019-11-18T16:46:30.894Z] [ERROR] Failed to execute goal on project xy:
> Could not resolve dependencies for project xy: The following artifacts could
> not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> -> [Help 1]
> [2019-11-18T16:46:30.894Z]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project xy: Could not resolve dependencies for project xy: The
> following artifacts could not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject
> (SmartBuilderImpl.java:205)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run
> (SmartBuilderImpl.java:77)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
> [2019-11-18T16:46:30.894Z] at java.util.concurrent.FutureTask.run
> (FutureTask.java:264)
> [2019-11-18T16:46:30.894Z]
[jira] [Commented] (SUREFIRE-1765) target/test-classes should not be added to classpath when tests run on modulepath using patch-module
[ https://issues.apache.org/jira/browse/SUREFIRE-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128106#comment-17128106 ] Christian Stein commented on SUREFIRE-1765: --- With Surefire 3.0.0-M5 being released soon and the junit-platform-maven-plugin already mentioned above -- I created a branch in the micromata/sawdust project showing current issues of Surefire 3.0.0-M4 with running tests in the modular world. Find details in the log of https://travis-ci.org/github/micromata/sawdust/builds/695936739 Having said that, I'm looking forward to update to Surefire 3.0.0-M5 to test-drive its new module-related capabilities implemented in https://issues.apache.org/jira/browse/SUREFIRE-1733 I expect some (all?) modular samples of the micromata/sawdust matrix to execute tests successfully. > target/test-classes should not be added to classpath when tests run on > modulepath using patch-module > > > Key: SUREFIRE-1765 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1765 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.22.1, 2.22.2 >Reporter: Tom De Wolf >Priority: Major > Attachments: reproduce-xxxAnnotation-jdk-bug.zip > > > When running junit tests using the maven-surefire-plugin the > target/test-classes are added as first entry in the classpath. > However, when testing a explicit java module with a module-info.java the > test-classes are already part of the module path using --patch-module. So > they should not be on the classpath? > In some scenario's this can give unwanted side-effects, i.e. that the same > classes are on the modulepath and classpath, possibly with a > module-info.class in both locations (cfr > [https://bugs.openjdk.java.net/browse/JDK-8241770).] > So it seems that it is best that target/test-classes is only added to the > classpath when it is not put on the module-path. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-114) ArtifactNotFoundExceptions when building in parallel
[
https://issues.apache.org/jira/browse/MRESOLVER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128077#comment-17128077
]
Rainer Reich commented on MRESOLVER-114:
I just scrolled a little bit through the takari sources: Their Synchronization
code lives mainly in the {{DefaultFileManager}}.
The only actual locking I could find happens here:
[https://github.com/takari/takari-local-repository/blob/6784e082fc03987f0e8b7448dcae918629f9ab8a/src/main/java/io/takari/filemanager/internal/DefaultFileManager.java#L380]
This line creates a
[FileLock|[https://docs.oracle.com/javase/8/docs/api/java/nio/channels/FileLock.html]].
The Javadoc of FileLock states: "File locks are held on behalf of the entire
Java virtual machine. They are not suitable for controlling access to a file by
multiple threads within the same virtual machine."
I'm also not an expert, but to me this sounds like their whole synchronization
does nothing when all resolving code runs in the same JVM. Maybe their only
goal was to synchronize mulitple Maven calls running against a shared local
repository?
> ArtifactNotFoundExceptions when building in parallel
>
>
> Key: MRESOLVER-114
> URL: https://issues.apache.org/jira/browse/MRESOLVER-114
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Rainer Reich
>Priority: Major
> Attachments: maven-debug-log.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a multi-module project with quite many modules and many dependencies
> and observe pretty random {{ArtifactNotFoundExceptions}} when building in
> parallel with an empty local repository.
> The "funny" thing is that Maven did in fact download the jar that it
> complained about not finding.
> In this example Maven said it could not find
> {{edu.tum.cs:cup-runtime:jar:11a}} (see stacktrace below)
> But it also said: {{Downloaded from central-mirror:
> [https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar]}}.
> When looking into the local repository after the failed build we found the
> cup-runtime.jar in the correct place with the correct checksum.
> We tried the following to "fix" the problem:
> * build with and without the takari extensions ({{takari-local-repository}}
> & {{takari-smart-builder}}) using {{--builder smart}}
> * also build with {{io.takari.aether:aether-connector-okhttp}} extension
> * only execute goal package instead of install
> * build with these properties: {{-Daether.connector.basic.threads=1
> -Daether.connector.resumeDownloads=false}}
> But nothing helped.
> Unfortunately it seems to be a race condition and we cannot reproduce it
> consistently but it happens in about 1 out of 5 builds.
> {code:java}
> ...
> [2019-11-18T16:46:29.370Z] [INFO] Downloaded from central-mirror:
> https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar
> (13 kB at 738 kB/s)
> ...
> [2019-11-18T16:46:30.894Z] [ERROR] Failed to execute goal on project xy:
> Could not resolve dependencies for project xy: The following artifacts could
> not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> -> [Help 1]
> [2019-11-18T16:46:30.894Z]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project xy: Could not resolve dependencies for project xy: The
> following artifacts could not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
>
[jira] [Commented] (MRESOLVER-114) ArtifactNotFoundExceptions when building in parallel
[
https://issues.apache.org/jira/browse/MRESOLVER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17127999#comment-17127999
]
Eva Müller commented on MRESOLVER-114:
--
[~michael-o] No, I did not... But I can have a look - unfortunately I have no
time today.
> ArtifactNotFoundExceptions when building in parallel
>
>
> Key: MRESOLVER-114
> URL: https://issues.apache.org/jira/browse/MRESOLVER-114
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Rainer Reich
>Priority: Major
> Attachments: maven-debug-log.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a multi-module project with quite many modules and many dependencies
> and observe pretty random {{ArtifactNotFoundExceptions}} when building in
> parallel with an empty local repository.
> The "funny" thing is that Maven did in fact download the jar that it
> complained about not finding.
> In this example Maven said it could not find
> {{edu.tum.cs:cup-runtime:jar:11a}} (see stacktrace below)
> But it also said: {{Downloaded from central-mirror:
> [https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar]}}.
> When looking into the local repository after the failed build we found the
> cup-runtime.jar in the correct place with the correct checksum.
> We tried the following to "fix" the problem:
> * build with and without the takari extensions ({{takari-local-repository}}
> & {{takari-smart-builder}}) using {{--builder smart}}
> * also build with {{io.takari.aether:aether-connector-okhttp}} extension
> * only execute goal package instead of install
> * build with these properties: {{-Daether.connector.basic.threads=1
> -Daether.connector.resumeDownloads=false}}
> But nothing helped.
> Unfortunately it seems to be a race condition and we cannot reproduce it
> consistently but it happens in about 1 out of 5 builds.
> {code:java}
> ...
> [2019-11-18T16:46:29.370Z] [INFO] Downloaded from central-mirror:
> https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar
> (13 kB at 738 kB/s)
> ...
> [2019-11-18T16:46:30.894Z] [ERROR] Failed to execute goal on project xy:
> Could not resolve dependencies for project xy: The following artifacts could
> not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> -> [Help 1]
> [2019-11-18T16:46:30.894Z]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project xy: Could not resolve dependencies for project xy: The
> following artifacts could not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject
> (SmartBuilderImpl.java:205)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run
> (SmartBuilderImpl.java:77)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
> [2019-11-18T16:46:30.894Z] at java.util.concurrent.FutureTask.run
> (FutureTask.java:264)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1128)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:628)
> [2019-11-18T16:46:30.894Z] at java.lang.Thread.run (Thread.java:834)
> [2019-11-18T16:46:30.894Z] Caused by:
>
[jira] [Comment Edited] (MRESOLVER-114) ArtifactNotFoundExceptions when building in parallel
[
https://issues.apache.org/jira/browse/MRESOLVER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17127953#comment-17127953
]
Michael Osipov edited comment on MRESOLVER-114 at 6/8/20, 7:31 AM:
---
This basically means that the their {{SyncContext}} impl does not work. At
first glance, their implementation looks exactly how I expect the file locking
to look like. This means that this issue is invalid because of the former. We
need to reach out to Takari or adopt this code into ours and try to figure out
why the locking does not work as expected.
was (Author: michael-o):
This basically means that the their {{SyncContext}} impl does not work. At
first glance, they implementation looks exactly how I expect the file locking
to look like. This means that this issue is invalid because of the former. We
need to reach out to Takari or adopt this code into ours and try to figure out
why the locking does not work as expected.
> ArtifactNotFoundExceptions when building in parallel
>
>
> Key: MRESOLVER-114
> URL: https://issues.apache.org/jira/browse/MRESOLVER-114
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Rainer Reich
>Priority: Major
> Attachments: maven-debug-log.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a multi-module project with quite many modules and many dependencies
> and observe pretty random {{ArtifactNotFoundExceptions}} when building in
> parallel with an empty local repository.
> The "funny" thing is that Maven did in fact download the jar that it
> complained about not finding.
> In this example Maven said it could not find
> {{edu.tum.cs:cup-runtime:jar:11a}} (see stacktrace below)
> But it also said: {{Downloaded from central-mirror:
> [https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar]}}.
> When looking into the local repository after the failed build we found the
> cup-runtime.jar in the correct place with the correct checksum.
> We tried the following to "fix" the problem:
> * build with and without the takari extensions ({{takari-local-repository}}
> & {{takari-smart-builder}}) using {{--builder smart}}
> * also build with {{io.takari.aether:aether-connector-okhttp}} extension
> * only execute goal package instead of install
> * build with these properties: {{-Daether.connector.basic.threads=1
> -Daether.connector.resumeDownloads=false}}
> But nothing helped.
> Unfortunately it seems to be a race condition and we cannot reproduce it
> consistently but it happens in about 1 out of 5 builds.
> {code:java}
> ...
> [2019-11-18T16:46:29.370Z] [INFO] Downloaded from central-mirror:
> https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar
> (13 kB at 738 kB/s)
> ...
> [2019-11-18T16:46:30.894Z] [ERROR] Failed to execute goal on project xy:
> Could not resolve dependencies for project xy: The following artifacts could
> not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> -> [Help 1]
> [2019-11-18T16:46:30.894Z]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project xy: Could not resolve dependencies for project xy: The
> following artifacts could not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject
> (SmartBuilderImpl.java:205)
>
[jira] [Commented] (MRESOLVER-114) ArtifactNotFoundExceptions when building in parallel
[
https://issues.apache.org/jira/browse/MRESOLVER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17127954#comment-17127954
]
Michael Osipov commented on MRESOLVER-114:
--
[~emueller-coremedia], did you actually verify that the lock files are created
at all?
> ArtifactNotFoundExceptions when building in parallel
>
>
> Key: MRESOLVER-114
> URL: https://issues.apache.org/jira/browse/MRESOLVER-114
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Rainer Reich
>Priority: Major
> Attachments: maven-debug-log.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a multi-module project with quite many modules and many dependencies
> and observe pretty random {{ArtifactNotFoundExceptions}} when building in
> parallel with an empty local repository.
> The "funny" thing is that Maven did in fact download the jar that it
> complained about not finding.
> In this example Maven said it could not find
> {{edu.tum.cs:cup-runtime:jar:11a}} (see stacktrace below)
> But it also said: {{Downloaded from central-mirror:
> [https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar]}}.
> When looking into the local repository after the failed build we found the
> cup-runtime.jar in the correct place with the correct checksum.
> We tried the following to "fix" the problem:
> * build with and without the takari extensions ({{takari-local-repository}}
> & {{takari-smart-builder}}) using {{--builder smart}}
> * also build with {{io.takari.aether:aether-connector-okhttp}} extension
> * only execute goal package instead of install
> * build with these properties: {{-Daether.connector.basic.threads=1
> -Daether.connector.resumeDownloads=false}}
> But nothing helped.
> Unfortunately it seems to be a race condition and we cannot reproduce it
> consistently but it happens in about 1 out of 5 builds.
> {code:java}
> ...
> [2019-11-18T16:46:29.370Z] [INFO] Downloaded from central-mirror:
> https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar
> (13 kB at 738 kB/s)
> ...
> [2019-11-18T16:46:30.894Z] [ERROR] Failed to execute goal on project xy:
> Could not resolve dependencies for project xy: The following artifacts could
> not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> -> [Help 1]
> [2019-11-18T16:46:30.894Z]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project xy: Could not resolve dependencies for project xy: The
> following artifacts could not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject
> (SmartBuilderImpl.java:205)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run
> (SmartBuilderImpl.java:77)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
> [2019-11-18T16:46:30.894Z] at java.util.concurrent.FutureTask.run
> (FutureTask.java:264)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1128)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:628)
> [2019-11-18T16:46:30.894Z] at java.lang.Thread.run (Thread.java:834)
> [2019-11-18T16:46:30.894Z] Caused by:
>
[jira] [Commented] (MRESOLVER-114) ArtifactNotFoundExceptions when building in parallel
[
https://issues.apache.org/jira/browse/MRESOLVER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17127953#comment-17127953
]
Michael Osipov commented on MRESOLVER-114:
--
This basically means that the their {{SyncContext}} impl does not work. At
first glance, they implementation looks exactly how I expect the file locking
to look like. This means that this issue is invalid because of the former. We
need to reach out to Takari or adopt this code into ours and try to figure out
why the locking does not work as expected.
> ArtifactNotFoundExceptions when building in parallel
>
>
> Key: MRESOLVER-114
> URL: https://issues.apache.org/jira/browse/MRESOLVER-114
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Rainer Reich
>Priority: Major
> Attachments: maven-debug-log.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a multi-module project with quite many modules and many dependencies
> and observe pretty random {{ArtifactNotFoundExceptions}} when building in
> parallel with an empty local repository.
> The "funny" thing is that Maven did in fact download the jar that it
> complained about not finding.
> In this example Maven said it could not find
> {{edu.tum.cs:cup-runtime:jar:11a}} (see stacktrace below)
> But it also said: {{Downloaded from central-mirror:
> [https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar]}}.
> When looking into the local repository after the failed build we found the
> cup-runtime.jar in the correct place with the correct checksum.
> We tried the following to "fix" the problem:
> * build with and without the takari extensions ({{takari-local-repository}}
> & {{takari-smart-builder}}) using {{--builder smart}}
> * also build with {{io.takari.aether:aether-connector-okhttp}} extension
> * only execute goal package instead of install
> * build with these properties: {{-Daether.connector.basic.threads=1
> -Daether.connector.resumeDownloads=false}}
> But nothing helped.
> Unfortunately it seems to be a race condition and we cannot reproduce it
> consistently but it happens in about 1 out of 5 builds.
> {code:java}
> ...
> [2019-11-18T16:46:29.370Z] [INFO] Downloaded from central-mirror:
> https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar
> (13 kB at 738 kB/s)
> ...
> [2019-11-18T16:46:30.894Z] [ERROR] Failed to execute goal on project xy:
> Could not resolve dependencies for project xy: The following artifacts could
> not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> -> [Help 1]
> [2019-11-18T16:46:30.894Z]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project xy: Could not resolve dependencies for project xy: The
> following artifacts could not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject
> (SmartBuilderImpl.java:205)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run
> (SmartBuilderImpl.java:77)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
> [2019-11-18T16:46:30.894Z] at java.util.concurrent.FutureTask.run
> (FutureTask.java:264)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor.runWorker
>
[jira] [Commented] (MRESOLVER-114) ArtifactNotFoundExceptions when building in parallel
[
https://issues.apache.org/jira/browse/MRESOLVER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17127949#comment-17127949
]
Eva Müller commented on MRESOLVER-114:
--
Thank you for considering PR#41 as compromise.
Just a note on the DefaultSyncContext: We use the takari extension
[takari-local-repository|https://github.com/takari/takari-local-repository]
which implements the
[SyncContext|https://github.com/takari/takari-local-repository/blob/master/src/main/java/io/takari/aether/concurrency/LockingSyncContext.java].
> ArtifactNotFoundExceptions when building in parallel
>
>
> Key: MRESOLVER-114
> URL: https://issues.apache.org/jira/browse/MRESOLVER-114
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Rainer Reich
>Priority: Major
> Attachments: maven-debug-log.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a multi-module project with quite many modules and many dependencies
> and observe pretty random {{ArtifactNotFoundExceptions}} when building in
> parallel with an empty local repository.
> The "funny" thing is that Maven did in fact download the jar that it
> complained about not finding.
> In this example Maven said it could not find
> {{edu.tum.cs:cup-runtime:jar:11a}} (see stacktrace below)
> But it also said: {{Downloaded from central-mirror:
> [https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar]}}.
> When looking into the local repository after the failed build we found the
> cup-runtime.jar in the correct place with the correct checksum.
> We tried the following to "fix" the problem:
> * build with and without the takari extensions ({{takari-local-repository}}
> & {{takari-smart-builder}}) using {{--builder smart}}
> * also build with {{io.takari.aether:aether-connector-okhttp}} extension
> * only execute goal package instead of install
> * build with these properties: {{-Daether.connector.basic.threads=1
> -Daether.connector.resumeDownloads=false}}
> But nothing helped.
> Unfortunately it seems to be a race condition and we cannot reproduce it
> consistently but it happens in about 1 out of 5 builds.
> {code:java}
> ...
> [2019-11-18T16:46:29.370Z] [INFO] Downloaded from central-mirror:
> https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar
> (13 kB at 738 kB/s)
> ...
> [2019-11-18T16:46:30.894Z] [ERROR] Failed to execute goal on project xy:
> Could not resolve dependencies for project xy: The following artifacts could
> not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> -> [Help 1]
> [2019-11-18T16:46:30.894Z]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project xy: Could not resolve dependencies for project xy: The
> following artifacts could not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject
> (SmartBuilderImpl.java:205)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run
> (SmartBuilderImpl.java:77)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
> [2019-11-18T16:46:30.894Z] at java.util.concurrent.FutureTask.run
> (FutureTask.java:264)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor.runWorker
>
[jira] [Updated] (MRESOLVER-114) ArtifactNotFoundExceptions when building in parallel
[
https://issues.apache.org/jira/browse/MRESOLVER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eva Müller updated MRESOLVER-114:
-
Attachment: (was: mvn-build-error.7-ARTIFACT_NOT_FOUND.log)
> ArtifactNotFoundExceptions when building in parallel
>
>
> Key: MRESOLVER-114
> URL: https://issues.apache.org/jira/browse/MRESOLVER-114
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Rainer Reich
>Priority: Major
> Attachments: maven-debug-log.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a multi-module project with quite many modules and many dependencies
> and observe pretty random {{ArtifactNotFoundExceptions}} when building in
> parallel with an empty local repository.
> The "funny" thing is that Maven did in fact download the jar that it
> complained about not finding.
> In this example Maven said it could not find
> {{edu.tum.cs:cup-runtime:jar:11a}} (see stacktrace below)
> But it also said: {{Downloaded from central-mirror:
> [https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar]}}.
> When looking into the local repository after the failed build we found the
> cup-runtime.jar in the correct place with the correct checksum.
> We tried the following to "fix" the problem:
> * build with and without the takari extensions ({{takari-local-repository}}
> & {{takari-smart-builder}}) using {{--builder smart}}
> * also build with {{io.takari.aether:aether-connector-okhttp}} extension
> * only execute goal package instead of install
> * build with these properties: {{-Daether.connector.basic.threads=1
> -Daether.connector.resumeDownloads=false}}
> But nothing helped.
> Unfortunately it seems to be a race condition and we cannot reproduce it
> consistently but it happens in about 1 out of 5 builds.
> {code:java}
> ...
> [2019-11-18T16:46:29.370Z] [INFO] Downloaded from central-mirror:
> https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar
> (13 kB at 738 kB/s)
> ...
> [2019-11-18T16:46:30.894Z] [ERROR] Failed to execute goal on project xy:
> Could not resolve dependencies for project xy: The following artifacts could
> not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> -> [Help 1]
> [2019-11-18T16:46:30.894Z]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project xy: Could not resolve dependencies for project xy: The
> following artifacts could not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject
> (SmartBuilderImpl.java:205)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run
> (SmartBuilderImpl.java:77)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
> [2019-11-18T16:46:30.894Z] at java.util.concurrent.FutureTask.run
> (FutureTask.java:264)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1128)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:628)
> [2019-11-18T16:46:30.894Z] at java.lang.Thread.run (Thread.java:834)
> [2019-11-18T16:46:30.894Z] Caused by:
> org.apache.maven.project.DependencyResolutionException: Could not resolve
>
[jira] [Updated] (MRESOLVER-114) ArtifactNotFoundExceptions when building in parallel
[
https://issues.apache.org/jira/browse/MRESOLVER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eva Müller updated MRESOLVER-114:
-
Attachment: (was: DefaultArtifactResolver.java)
> ArtifactNotFoundExceptions when building in parallel
>
>
> Key: MRESOLVER-114
> URL: https://issues.apache.org/jira/browse/MRESOLVER-114
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Rainer Reich
>Priority: Major
> Attachments: maven-debug-log.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a multi-module project with quite many modules and many dependencies
> and observe pretty random {{ArtifactNotFoundExceptions}} when building in
> parallel with an empty local repository.
> The "funny" thing is that Maven did in fact download the jar that it
> complained about not finding.
> In this example Maven said it could not find
> {{edu.tum.cs:cup-runtime:jar:11a}} (see stacktrace below)
> But it also said: {{Downloaded from central-mirror:
> [https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar]}}.
> When looking into the local repository after the failed build we found the
> cup-runtime.jar in the correct place with the correct checksum.
> We tried the following to "fix" the problem:
> * build with and without the takari extensions ({{takari-local-repository}}
> & {{takari-smart-builder}}) using {{--builder smart}}
> * also build with {{io.takari.aether:aether-connector-okhttp}} extension
> * only execute goal package instead of install
> * build with these properties: {{-Daether.connector.basic.threads=1
> -Daether.connector.resumeDownloads=false}}
> But nothing helped.
> Unfortunately it seems to be a race condition and we cannot reproduce it
> consistently but it happens in about 1 out of 5 builds.
> {code:java}
> ...
> [2019-11-18T16:46:29.370Z] [INFO] Downloaded from central-mirror:
> https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar
> (13 kB at 738 kB/s)
> ...
> [2019-11-18T16:46:30.894Z] [ERROR] Failed to execute goal on project xy:
> Could not resolve dependencies for project xy: The following artifacts could
> not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> -> [Help 1]
> [2019-11-18T16:46:30.894Z]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project xy: Could not resolve dependencies for project xy: The
> following artifacts could not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject
> (SmartBuilderImpl.java:205)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run
> (SmartBuilderImpl.java:77)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
> [2019-11-18T16:46:30.894Z] at java.util.concurrent.FutureTask.run
> (FutureTask.java:264)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1128)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:628)
> [2019-11-18T16:46:30.894Z] at java.lang.Thread.run (Thread.java:834)
> [2019-11-18T16:46:30.894Z] Caused by:
> org.apache.maven.project.DependencyResolutionException: Could not resolve
>
[jira] [Updated] (MRESOLVER-114) ArtifactNotFoundExceptions when building in parallel
[
https://issues.apache.org/jira/browse/MRESOLVER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eva Müller updated MRESOLVER-114:
-
Attachment: mvn-build-error.7-ARTIFACT_NOT_FOUND.log
> ArtifactNotFoundExceptions when building in parallel
>
>
> Key: MRESOLVER-114
> URL: https://issues.apache.org/jira/browse/MRESOLVER-114
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Rainer Reich
>Priority: Major
> Attachments: DefaultArtifactResolver.java, maven-debug-log.txt,
> mvn-build-error.7-ARTIFACT_NOT_FOUND.log
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a multi-module project with quite many modules and many dependencies
> and observe pretty random {{ArtifactNotFoundExceptions}} when building in
> parallel with an empty local repository.
> The "funny" thing is that Maven did in fact download the jar that it
> complained about not finding.
> In this example Maven said it could not find
> {{edu.tum.cs:cup-runtime:jar:11a}} (see stacktrace below)
> But it also said: {{Downloaded from central-mirror:
> [https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar]}}.
> When looking into the local repository after the failed build we found the
> cup-runtime.jar in the correct place with the correct checksum.
> We tried the following to "fix" the problem:
> * build with and without the takari extensions ({{takari-local-repository}}
> & {{takari-smart-builder}}) using {{--builder smart}}
> * also build with {{io.takari.aether:aether-connector-okhttp}} extension
> * only execute goal package instead of install
> * build with these properties: {{-Daether.connector.basic.threads=1
> -Daether.connector.resumeDownloads=false}}
> But nothing helped.
> Unfortunately it seems to be a race condition and we cannot reproduce it
> consistently but it happens in about 1 out of 5 builds.
> {code:java}
> ...
> [2019-11-18T16:46:29.370Z] [INFO] Downloaded from central-mirror:
> https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar
> (13 kB at 738 kB/s)
> ...
> [2019-11-18T16:46:30.894Z] [ERROR] Failed to execute goal on project xy:
> Could not resolve dependencies for project xy: The following artifacts could
> not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> -> [Help 1]
> [2019-11-18T16:46:30.894Z]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project xy: Could not resolve dependencies for project xy: The
> following artifacts could not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject
> (SmartBuilderImpl.java:205)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run
> (SmartBuilderImpl.java:77)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
> [2019-11-18T16:46:30.894Z] at java.util.concurrent.FutureTask.run
> (FutureTask.java:264)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1128)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:628)
> [2019-11-18T16:46:30.894Z] at java.lang.Thread.run (Thread.java:834)
> [2019-11-18T16:46:30.894Z] Caused by:
>
[jira] [Updated] (MRESOLVER-114) ArtifactNotFoundExceptions when building in parallel
[
https://issues.apache.org/jira/browse/MRESOLVER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eva Müller updated MRESOLVER-114:
-
Attachment: DefaultArtifactResolver.java
> ArtifactNotFoundExceptions when building in parallel
>
>
> Key: MRESOLVER-114
> URL: https://issues.apache.org/jira/browse/MRESOLVER-114
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: 1.4.2
>Reporter: Rainer Reich
>Priority: Major
> Attachments: DefaultArtifactResolver.java, maven-debug-log.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a multi-module project with quite many modules and many dependencies
> and observe pretty random {{ArtifactNotFoundExceptions}} when building in
> parallel with an empty local repository.
> The "funny" thing is that Maven did in fact download the jar that it
> complained about not finding.
> In this example Maven said it could not find
> {{edu.tum.cs:cup-runtime:jar:11a}} (see stacktrace below)
> But it also said: {{Downloaded from central-mirror:
> [https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar]}}.
> When looking into the local repository after the failed build we found the
> cup-runtime.jar in the correct place with the correct checksum.
> We tried the following to "fix" the problem:
> * build with and without the takari extensions ({{takari-local-repository}}
> & {{takari-smart-builder}}) using {{--builder smart}}
> * also build with {{io.takari.aether:aether-connector-okhttp}} extension
> * only execute goal package instead of install
> * build with these properties: {{-Daether.connector.basic.threads=1
> -Daether.connector.resumeDownloads=false}}
> But nothing helped.
> Unfortunately it seems to be a race condition and we cannot reproduce it
> consistently but it happens in about 1 out of 5 builds.
> {code:java}
> ...
> [2019-11-18T16:46:29.370Z] [INFO] Downloaded from central-mirror:
> https://mirror.xy.com/repository/maven-all-mirror/edu/tum/cs/cup-runtime/11a/cup-runtime-11a.jar
> (13 kB at 738 kB/s)
> ...
> [2019-11-18T16:46:30.894Z] [ERROR] Failed to execute goal on project xy:
> Could not resolve dependencies for project xy: The following artifacts could
> not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> -> [Help 1]
> [2019-11-18T16:46:30.894Z]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project xy: Could not resolve dependencies for project xy: The
> following artifacts could not be resolved: edu.tum.cs:cup-runtime:jar:11a,
> org.checkerframework:checker-qual:jar:2.5.7, org.ow2.asm:asm:jar:7.2,
> cglib:cglib:jar:3.3.0: Could not find artifact edu.tum.cs:cup-runtime:jar:11a
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> [2019-11-18T16:46:30.894Z] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject
> (SmartBuilderImpl.java:205)
> [2019-11-18T16:46:30.894Z] at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run
> (SmartBuilderImpl.java:77)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
> [2019-11-18T16:46:30.894Z] at java.util.concurrent.FutureTask.run
> (FutureTask.java:264)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1128)
> [2019-11-18T16:46:30.894Z] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:628)
> [2019-11-18T16:46:30.894Z] at java.lang.Thread.run (Thread.java:834)
> [2019-11-18T16:46:30.894Z] Caused by:
> org.apache.maven.project.DependencyResolutionException: Could not
[jira] [Updated] (MEAR-216) Unable to include dependencies of type test-jar
[
https://issues.apache.org/jira/browse/MEAR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MEAR-216:
--
Priority: Major (was: Blocker)
> Unable to include dependencies of type test-jar
> ---
>
> Key: MEAR-216
> URL: https://issues.apache.org/jira/browse/MEAR-216
> Project: Maven Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.10
>Reporter: Maxim Frolov
>Priority: Major
> Fix For: 3.1.0
>
> Attachments: test-jar-in-ear-2.zip, test-jar-in-ear.zip
>
>
> Please implement support for artifacts of type *test-jar*.
> One of the use cases would be to build a test EAR as a mix of production and
> test JARs where the test JARs are used to set up the test data used to test
> the production code.
> Currently including one or more dependencies of type test-jar causes
> *LifecycleExecutionException*:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml
> (default-generate-application-xml) on project suite-systemtests-common-ear:
> Failed to initialize ear modules: Unknown artifact type[test-jar] for
> artifact_id -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml
> (default-generate-application-xml) on project suite-systemtests-common-ear:
> Failed to initialize ear modules
> 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.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
> initialize ear modules
> at
> org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:260)
> at
> org.apache.maven.plugin.ear.GenerateApplicationXmlMojo.execute(GenerateApplicationXmlMojo.java:162)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.plugin.ear.UnknownArtifactTypeException: Unknown
> artifact type[test-jar] for common-domain-impl
> at
> org.apache.maven.plugin.ear.EarModuleFactory.newEarModule(EarModuleFactory.java:88)
> at
> org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:250)
> ... 22 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
