[GitHub] [maven] michael-o commented on issue #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
michael-o commented on issue #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException URL: https://github.com/apache/maven/pull/277#issuecomment-575516402 > > > Let me check tomorrow. (I thought I checked “mvn test -Prun-its”, but maybe I forgot) Don't forget, they are here: https://github.com/apache/maven-integration-testing 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 With regards, Apache Git Services
[jira] [Commented] (MPOM-236) scm-publish:publish-scm java.lang.AbstractMethodError failure on Git checkout
[
https://issues.apache.org/jira/browse/MPOM-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017762#comment-17017762
]
Hudson commented on MPOM-236:
-
Build failed in Jenkins: Maven TLP » maven-apache-parent » master #39
See
https://builds.apache.org/job/maven-box/job/maven-apache-parent/job/master/39/
> scm-publish:publish-scm java.lang.AbstractMethodError failure on Git checkout
> -
>
> Key: MPOM-236
> URL: https://issues.apache.org/jira/browse/MPOM-236
> Project: Maven POMs
> Issue Type: Bug
> Components: asf
>Affects Versions: ASF-22
>Reporter: Christofer Dutz
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: ASF-23
>
>
> after updating to the lates apache-parent 22, we're having problems pushing
> our generated site to git on jenkins ... we're getting strange API
> compatibility errors ...
> {noformat}[DEBUG] -- end configuration --
> [INFO] Checking out the pub tree from
> scm:git:https://gitbox.apache.org/repos/asf/plc4x-website.git into
> /home/jenkins/jenkins-slave/workspace/PLC4X_PLC4X_develop/target/scmpublish-checkout
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 4.487 s
> [INFO] Finished at: 2020-01-16T10:26:43Z
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-scm-publish-plugin:3.0.0:publish-scm
> (default-cli) on project plc4x-jenkins-tools: Execution default-cli of goal
> org.apache.maven.plugins:maven-scm-publish-plugin:3.0.0:publish-scm failed:
> An API incompatibility was encountered while executing
> org.apache.maven.plugins:maven-scm-publish-plugin:3.0.0:publish-scm:
> java.lang.AbstractMethodError:
> org.apache.maven.scm.command.checkout.AbstractCheckOutCommand.executeCheckOutCommand(Lorg/apache/maven/scm/provider/ScmProviderRepository;Lorg/apache/maven/scm/ScmFileSet;Lorg/apache/maven/scm/ScmVersion;ZZ)Lorg/apache/maven/scm/command/checkout/CheckOutScmResult;{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MANTTASKS-206) dependecies task overrides custom definition of 'central' repository
[
https://issues.apache.org/jira/browse/MANTTASKS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MANTTASKS-206:
Description:
While using
{code:xml}
{code}
with pom
{code:xml}
...
central
[https://custom/mvn/central]
true
true
{code}
the task is still trying to resolve my dependencies from
[http://repo2.maven.org/maven2].
A patch resolving this issue is attached.
was:
While using
{code:xml}
{code}
with pom
{code:xml}
...
central
[https://custom/mvn/central]
true
true
{code}
the task is still trying to resolve my dependecies from
[http://repo2.maven.org/maven2].
A patch resolving this issue is attached.
> dependecies task overrides custom definition of 'central' repository
>
>
> Key: MANTTASKS-206
> URL: https://issues.apache.org/jira/browse/MANTTASKS-206
> Project: Maven Ant Tasks (RETIRED)
> Issue Type: Bug
>Affects Versions: 2.1.1
>Reporter: Miroslaw Michalski
>Assignee: Paul Gier
>Priority: Major
> Fix For: 2.1.2
>
> Attachments: patch2.txt
>
>
> While using
> {code:xml}
> pathId="maven.dependency.classpath" useScope="test">
>
> {code}
> with pom
> {code:xml}
>
> ...
>
>
> central
> [https://custom/mvn/central]
>
>true
>
>
>true
>
>
>
> {code}
> the task is still trying to resolve my dependencies from
> [http://repo2.maven.org/maven2].
> A patch resolving this issue is attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MANTTASKS-206) dependecies task overrides custom definition of 'central' repository
[
https://issues.apache.org/jira/browse/MANTTASKS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MANTTASKS-206:
Description:
While using
{code:xml}
{code}
with pom
{code:xml}
...
central
[https://custom/mvn/central]
true
true
{code}
the task is still trying to resolve my dependecies from
[http://repo2.maven.org/maven2].
A patch resolving this issue is attached.
was:
While using
with pom
...
central
https://custom/mvn/central
true
true
the task is still trying to resolve my dependecies from
http://repo2.maven.org/maven2.
A patch resolving this issue is attached.
> dependecies task overrides custom definition of 'central' repository
>
>
> Key: MANTTASKS-206
> URL: https://issues.apache.org/jira/browse/MANTTASKS-206
> Project: Maven Ant Tasks (RETIRED)
> Issue Type: Bug
>Affects Versions: 2.1.1
>Reporter: Miroslaw Michalski
>Assignee: Paul Gier
>Priority: Major
> Fix For: 2.1.2
>
> Attachments: patch2.txt
>
>
> While using
> {code:xml} pathId="maven.dependency.classpath" useScope="test">
>
> {code}
> with pom
> {code:xml}
> ...
>
>
> central
> [https://custom/mvn/central]
>
>true
>
>
>true
>
>
>
> {code}
> the task is still trying to resolve my dependecies from
> [http://repo2.maven.org/maven2].
> A patch resolving this issue is attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MPOM-236) scm-publish:publish-scm java.lang.AbstractMethodError failure on Git checkout
[
https://issues.apache.org/jira/browse/MPOM-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MPOM-236:
---
Summary: scm-publish:publish-scm java.lang.AbstractMethodError failure on
Git checkout (was: scm-publish:publish-scm failure on Git checkout)
> scm-publish:publish-scm java.lang.AbstractMethodError failure on Git checkout
> -
>
> Key: MPOM-236
> URL: https://issues.apache.org/jira/browse/MPOM-236
> Project: Maven POMs
> Issue Type: Bug
> Components: asf
>Affects Versions: ASF-22
>Reporter: Christofer Dutz
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: ASF-23
>
>
> after updating to the lates apache-parent 22, we're having problems pushing
> our generated site to git on jenkins ... we're getting strange API
> compatibility errors ...
> {noformat}[DEBUG] -- end configuration --
> [INFO] Checking out the pub tree from
> scm:git:https://gitbox.apache.org/repos/asf/plc4x-website.git into
> /home/jenkins/jenkins-slave/workspace/PLC4X_PLC4X_develop/target/scmpublish-checkout
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 4.487 s
> [INFO] Finished at: 2020-01-16T10:26:43Z
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-scm-publish-plugin:3.0.0:publish-scm
> (default-cli) on project plc4x-jenkins-tools: Execution default-cli of goal
> org.apache.maven.plugins:maven-scm-publish-plugin:3.0.0:publish-scm failed:
> An API incompatibility was encountered while executing
> org.apache.maven.plugins:maven-scm-publish-plugin:3.0.0:publish-scm:
> java.lang.AbstractMethodError:
> org.apache.maven.scm.command.checkout.AbstractCheckOutCommand.executeCheckOutCommand(Lorg/apache/maven/scm/provider/ScmProviderRepository;Lorg/apache/maven/scm/ScmFileSet;Lorg/apache/maven/scm/ScmVersion;ZZ)Lorg/apache/maven/scm/command/checkout/CheckOutScmResult;{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MPOM-236) scm-publish:publish-scm failure on Git checkout
Herve Boutemy created MPOM-236:
--
Summary: scm-publish:publish-scm failure on Git checkout
Key: MPOM-236
URL: https://issues.apache.org/jira/browse/MPOM-236
Project: Maven POMs
Issue Type: Bug
Components: asf
Affects Versions: ASF-22
Reporter: Christofer Dutz
Assignee: Herve Boutemy
Fix For: ASF-23
after updating to the lates apache-parent 22, we're having problems pushing our
generated site to git on jenkins ... we're getting strange API compatibility
errors ...
{noformat}[DEBUG] -- end configuration --
[INFO] Checking out the pub tree from
scm:git:https://gitbox.apache.org/repos/asf/plc4x-website.git into
/home/jenkins/jenkins-slave/workspace/PLC4X_PLC4X_develop/target/scmpublish-checkout
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 4.487 s
[INFO] Finished at: 2020-01-16T10:26:43Z
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-scm-publish-plugin:3.0.0:publish-scm
(default-cli) on project plc4x-jenkins-tools: Execution default-cli of goal
org.apache.maven.plugins:maven-scm-publish-plugin:3.0.0:publish-scm failed: An
API incompatibility was encountered while executing
org.apache.maven.plugins:maven-scm-publish-plugin:3.0.0:publish-scm:
java.lang.AbstractMethodError:
org.apache.maven.scm.command.checkout.AbstractCheckOutCommand.executeCheckOutCommand(Lorg/apache/maven/scm/provider/ScmProviderRepository;Lorg/apache/maven/scm/ScmFileSet;Lorg/apache/maven/scm/ScmVersion;ZZ)Lorg/apache/maven/scm/command/checkout/CheckOutScmResult;{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] suztomo commented on issue #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
suztomo commented on issue #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException URL: https://github.com/apache/maven/pull/277#issuecomment-575467785 Let me check tomorrow. (I thought I checked “mvn test -Prun-its”, but maybe I forgot) 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 With regards, Apache Git Services
[GitHub] [maven] michael-o edited a comment on issue #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
michael-o edited a comment on issue #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException URL: https://github.com/apache/maven/pull/277#issuecomment-575381279 OK, there is some work to be done. IT for MNG-5175 is failing. See http://home.apache.org/~michaelo/issues/MNG-6732/. It needs to be modified or split. @suztomo Do you have a proposal? @rfscholte What would be the proper approach here? The PR makes sense to me. 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 With regards, Apache Git Services
[GitHub] [maven] michael-o commented on issue #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
michael-o commented on issue #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException URL: https://github.com/apache/maven/pull/277#issuecomment-575381279 OK, there is some work to be done. IT for MNG-5175 is failing. See http://home.apache.org/~michaelo/issues/MNG-6732/. It needs to be modified or split. @rfscholte What would be the proper approach here? The PR makes sense to me. 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 With regards, Apache Git Services
[jira] [Commented] (MNG-6732) DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
[
https://issues.apache.org/jira/browse/MNG-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017533#comment-17017533
]
Michael Osipov commented on MNG-6732:
-
I was able to make your test project run according to the instructions.
> DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon
> ArtifactTransferException
> -
>
> Key: MNG-6732
> URL: https://issues.apache.org/jira/browse/MNG-6732
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.6.1
>Reporter: Tomo Suzuki
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0-candidate
>
> Attachments: 62884438-89260580-bd04-11e9-8c4a-897d4b736dc7.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> h1. Problem
> Sometimes [Linkage Checker enforcer
> rule|https://github.com/GoogleCloudPlatform/cloud-opensource-java/tree/master/enforcer-rules]
> does not receive resolved artifact list because of a missing artifact even
> when the missing artifact is unused after Maven's dependency mediation.
> h1. Background
> The enforcer rule fails to retrieve artifact list through
> {{DefaultProjectDependenciesResolver.resolve}} when applied to
> [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client]
> because of the missing {{xerces:xerces-impl:2.6.2}}, even though the
> artifact does not appear in the final dependency graph. The artifact does not
> appear in the graph because of Maven's dependency mediation.
> Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central.
> In contrast, the enforcer rule can retrieve artifact list when applied to
> [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker]
> project even though it outputs "[WARNING] The POM for
> xerces:xerces-impl:jar:2.6.2 is missing, no dependency information
> available". The missing artifact does not appear in final dependency graph.
> [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834]
> h1. Diagnosis
> Currently {{DefaultArtifactDescriptorReader.loadPom}} method checks
> "ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon
> ArtifactNotFoundException. This allows
> {{DefaultProjectDependenciesResolver.resolve}} calls
> {{repoSystem.resolveDependencies}} to obtain partially resolved artifact
> list, rather than failing entirely, when there is a missing artifact (such as
> {{xerces:xerces-impl:2.6.2}})
> However, when a retired Maven repository is involved (such as
> [http://repository.codehaus.org/] ),
> {{DefaultArtifactDescriptorReader.loadPom}} gets an ArtifactTransferException
> and throws ArtifactDescriptorException without checking
> "ArtifactDescriptorPolicy.IGNORE_MISSING" policy (excerpt below), and thus
> {{DefaultProjectDependenciesResolver.resolve}} does not return partially
> resolved artifact list.
> {code:java}
> catch ( ArtifactResolutionException e )
> {
> if ( e.getCause() instanceof ArtifactNotFoundException )
> {
> missingDescriptor( session, trace, a, (Exception)
> e.getCause() );
> if ( ( getPolicy( session, a, request ) &
> ArtifactDescriptorPolicy.IGNORE_MISSING ) != 0 )
> {
> return null;
> }
> }
> result.addException( e );
> throw new ArtifactDescriptorException( result );
> }
> {code}
> from
> [DefaultArtifactDescriptorReader.java|https://github.com/apache/maven/blob/d3ace78/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java#L255]
> ArtifactNotFoundException is a special case of
> [ArtifactTransferException|https://maven.apache.org/resolver/apidocs/org/eclipse/aether/transfer/ArtifactTransferException.html].
> h1. Example Project
> Example project to demonstrate the diagnosis:
> [https://github.com/suztomo/maven-missing-artifact] . In this example, even
> though module-b and module-c have the same dependency section, module-c fails
> to run Maven because of a repository section containing a retired repository
> URL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MPOM-199) remove Archetypes parent POM from menu
[ https://issues.apache.org/jira/browse/MPOM-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017508#comment-17017508 ] Hudson commented on MPOM-199: - Build succeeded in Jenkins: Maven TLP » maven-parent » master #34 See https://builds.apache.org/job/maven-box/job/maven-parent/job/master/34/ > remove Archetypes parent POM from menu > -- > > Key: MPOM-199 > URL: https://issues.apache.org/jira/browse/MPOM-199 > Project: Maven POMs > Issue Type: Task > Components: maven >Affects Versions: MAVEN-32 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: MAVEN-33 > > > was forgotten when working on MPOM-183, then version 32 site has broken link -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MPOM-223) Introduce parent for extensions
[ https://issues.apache.org/jira/browse/MPOM-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017507#comment-17017507 ] Hudson commented on MPOM-223: - Build succeeded in Jenkins: Maven TLP » maven-parent » master #33 See https://builds.apache.org/job/maven-box/job/maven-parent/job/master/33/ > Introduce parent for extensions > --- > > Key: MPOM-223 > URL: https://issues.apache.org/jira/browse/MPOM-223 > Project: Maven POMs > Issue Type: New Feature >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > Fix For: MAVEN-34 > > > Extensions are like plugins, but with a different purpose. So beside plugins > it makes sense to also maintain extensions, which deserve their own parent. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] michael-o commented on issue #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
michael-o commented on issue #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException URL: https://github.com/apache/maven/pull/277#issuecomment-575340406 These aren't the issues I see, still analyzing. 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 With regards, Apache Git Services
[GitHub] [maven] rfscholte commented on issue #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
rfscholte commented on issue #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException URL: https://github.com/apache/maven/pull/277#issuecomment-575339710 https://github.com/apache/maven-integration-testing/commit/e284945d8600a63a3cda60e1f90433cc7674e1ed should fix the http issues (master is also back to blue). All branches need to merge in master 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 With regards, Apache Git Services
[GitHub] [maven] michael-o commented on issue #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
michael-o commented on issue #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException URL: https://github.com/apache/maven/pull/277#issuecomment-575317741 ITs are runing, I see repeated failures at home on my box and on a server at work. Will post the failures shortly. 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 With regards, Apache Git Services
[jira] [Commented] (MSKINS-105) Provide alt text for all images
[ https://issues.apache.org/jira/browse/MSKINS-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017429#comment-17017429 ] Hudson commented on MSKINS-105: --- Build succeeded in Jenkins: Maven TLP » maven-fluido-skin » master #35 See https://builds.apache.org/job/maven-box/job/maven-fluido-skin/job/master/35/ > Provide alt text for all images > --- > > Key: MSKINS-105 > URL: https://issues.apache.org/jira/browse/MSKINS-105 > Project: Maven Skins > Issue Type: Sub-task > Components: Fluido Skin >Affects Versions: fluido-1.3.1 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: fluido-1.9 > > > Issued error: > bq. An img element must have an alt attribute, except under certain > conditions. For details, consult guidance on providing text alternatives for > images. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-assembly-plugin] turbanoff opened a new pull request #16: [MASSEMBLY-874] maven-assembly plugin always downloads dependencies from net
turbanoff opened a new pull request #16: [MASSEMBLY-874] maven-assembly plugin always downloads dependencies from net URL: https://github.com/apache/maven-assembly-plugin/pull/16 use main list of remote repositories when build dependency set - [*] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) 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 With regards, Apache Git Services
[jira] [Comment Edited] (MASSEMBLY-874) maven-assembly plugin always downloads dependencies from net
[
https://issues.apache.org/jira/browse/MASSEMBLY-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016987#comment-17016987
]
Andrey Turbanov edited comment on MASSEMBLY-874 at 1/16/20 5:11 PM:
As I can in debugger see artifacts are downloaded there -
https://github.com/apache/maven-assembly-plugin/blob/master/src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java#L158
Perhaps code should set more parameters in {{ProjectBuildingRequest}}.
Something like this:
{code}
Index:
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
<+>UTF-8
===
---
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
(revision 178d0d0e3af1557f0c1400de33cce9885e1d89ab)
+++
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
(date 1579186139177)
@@ -180,7 +180,9 @@
private ProjectBuildingRequest getProjectBuildingRequest(
AssemblerConfigurationSource configSource )
{
-return configSource.getMavenSession().getProjectBuildingRequest();
+ProjectBuildingRequest pbr =
configSource.getMavenSession().getProjectBuildingRequest();
+pbr.setRemoteRepositories( project.getRemoteArtifactRepositories() );
+return pbr;
}
private boolean isUnpackWithOptions( DependencySet dependencySet )
{code}
It's still unclear for my why plugin tries to "build" project from dependency.
You can see that {{project.getRemoteArtifactRepositories()}} contains all
defined remote repositories, while default
{{pbr.getRemoteArtifactRepositories()}} contains only one.
!maven_assembly_repositories_after_and_before_change.png!
Before fix. *mvn package -U* run
{code}
[INFO] --- maven-assembly-plugin:3.2.0:single (default) @ dxcore-ipfservice ---
[INFO] Reading assembly descriptor: assembly.xml
Downloading from Nexus:
https://maven.in.devexperts.com/content/groups/public/com/dxfeed/ipf-api/327/ipf-api-327.pom
Downloading from Nexus:
https://maven.in.devexperts.com/content/groups/public/com/devexperts/mdd/ipfservice/327/ipfservice-327.pom
Downloading from Nexus:
https://maven.in.devexperts.com/content/groups/public/com/devexperts/mdd/storage/327/storage-327.pom
[INFO] Building zip:
D:\Projects\dxcore-assembly\Tools\ipfservice\target\dxcore-ipfservice.zip
[INFO]
[INFO] Reactor Summary for dxcore TURBO-SNAPSHOT:
[INFO]
[INFO] dxcore . SUCCESS [ 0.014 s]
[INFO] dxcore-tools-parent SUCCESS [ 0.015 s]
[INFO] dxcore-ipfservice .. SUCCESS [ 2.228 s]
{code}
After fix. *mvn package -U* run
{code}
[INFO] --- maven-assembly-plugin:3.2.1-dx:single (default) @ dxcore-ipfservice
---
[INFO] Reading assembly descriptor: assembly.xml
[INFO] Building zip:
D:\Projects\dxcore-assembly\Tools\ipfservice\target\dxcore-ipfservice.zip
[INFO]
[INFO] Reactor Summary for dxcore TURBO-SNAPSHOT:
[INFO]
[INFO] dxcore . SUCCESS [ 0.015 s]
[INFO] dxcore-tools-parent SUCCESS [ 0.015 s]
[INFO] dxcore-ipfservice .. SUCCESS [ 1.919 s]
{code}
was (Author: turbanoff):
As I can in debugger see artifacts are downloaded there -
https://github.com/apache/maven-assembly-plugin/blob/master/src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java#L158
Perhaps code should set more parameters in {{ProjectBuildingRequest}}.
Something like this:
{code}
Index:
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
<+>UTF-8
===
---
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
(revision 178d0d0e3af1557f0c1400de33cce9885e1d89ab)
+++
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
(date 1579186139177)
@@ -180,7 +180,9 @@
private ProjectBuildingRequest getProjectBuildingRequest(
AssemblerConfigurationSource configSource )
{
-return configSource.getMavenSession().getProjectBuildingRequest();
+ProjectBuildingRequest pbr =
configSource.getMavenSession().getProjectBuildingRequest();
+pbr.setRemoteRepositories( project.getRemoteArtifactRepositories() );
+return pbr;
}
private boolean isUnpackWithOptions( DependencySet dependencySet )
{code}
It's still unclear for my why plugin tries to "build" project from dependency.
You can see that {{project.getRemoteArtifactRepositories()}} contains all
defined
[jira] [Comment Edited] (MASSEMBLY-874) maven-assembly plugin always downloads dependencies from net
[
https://issues.apache.org/jira/browse/MASSEMBLY-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016987#comment-17016987
]
Andrey Turbanov edited comment on MASSEMBLY-874 at 1/16/20 5:01 PM:
As I can in debugger see artifacts are downloaded there -
https://github.com/apache/maven-assembly-plugin/blob/master/src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java#L158
Perhaps code should set more parameters in {{ProjectBuildingRequest}}.
Something like this:
{code}
Index:
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
<+>UTF-8
===
---
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
(revision 178d0d0e3af1557f0c1400de33cce9885e1d89ab)
+++
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
(date 1579186139177)
@@ -180,7 +180,9 @@
private ProjectBuildingRequest getProjectBuildingRequest(
AssemblerConfigurationSource configSource )
{
-return configSource.getMavenSession().getProjectBuildingRequest();
+ProjectBuildingRequest pbr =
configSource.getMavenSession().getProjectBuildingRequest();
+pbr.setRemoteRepositories( project.getRemoteArtifactRepositories() );
+return pbr;
}
private boolean isUnpackWithOptions( DependencySet dependencySet )
{code}
It's still unclear for my why plugin tries to "build" project from dependency.
You can see that {{project.getRemoteArtifactRepositories()}} contains all
defined remote repositories, while default
{{pbr.getRemoteArtifactRepositories()}} contains only one.
!maven_assembly_repositories_after_and_before_change.png!
was (Author: turbanoff):
As I can in debugger see artifacts are downloaded there -
https://github.com/apache/maven-assembly-plugin/blob/master/src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java#L158
Perhaps code should set more parameters in {{ProjectBuildingRequest}}.
Something like this:
{code}
Index:
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
<+>UTF-8
===
---
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
(revision 178d0d0e3af1557f0c1400de33cce9885e1d89ab)
+++
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
(date 1579186139177)
@@ -180,7 +180,9 @@
private ProjectBuildingRequest getProjectBuildingRequest(
AssemblerConfigurationSource configSource )
{
-return configSource.getMavenSession().getProjectBuildingRequest();
+ProjectBuildingRequest pbr =
configSource.getMavenSession().getProjectBuildingRequest();
+pbr.setRemoteRepositories( project.getRemoteArtifactRepositories() );
+return pbr;
}
private boolean isUnpackWithOptions( DependencySet dependencySet )
{code}
It's still unclear for my why plugin tries to "build" project from dependency.
You can see that {{project.getRemoteArtifactRepositories()}} contains all
defined remote repositories, while default
{{pbr.getRemoteArtifactRepositories()}} contains only one.
> maven-assembly plugin always downloads dependencies from net
>
>
> Key: MASSEMBLY-874
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-874
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 3.1.0
> Environment: Multi-Module build
>Reporter: Roland Schäuble
>Assignee: Enrico Olivelli
>Priority: Major
> Attachments: make.log,
> maven_assembly_repositories_after_and_before_change.png
>
>
> The maven-assembly-plugin always loads it own dependencies from the internet,
> although the required dependencies are available in the local m2 repositiory.
> The local repository is updated with the dependencies but during the next
> build, the files are downloaded from the internet again instead of getting
> them from the local repo.
> In the attached log, near the end, the unnecessary downloads begin with
> "Downloading from central:
> [https://repo.maven.apache.org/maven2/com/lowagie/itext/2.1.7.js5/itext-2.1.7.js5.pom.;|https://repo.maven.apache.org/maven2/com/lowagie/itext/2.1.7.js5/itext-2.1.7.js5.pom.]
> The files are definitely available in my local repository under
> ~/.m2/repository/com/...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MASSEMBLY-874) maven-assembly plugin always downloads dependencies from net
[
https://issues.apache.org/jira/browse/MASSEMBLY-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016987#comment-17016987
]
Andrey Turbanov edited comment on MASSEMBLY-874 at 1/16/20 5:01 PM:
As I can in debugger see artifacts are downloaded there -
https://github.com/apache/maven-assembly-plugin/blob/master/src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java#L158
Perhaps code should set more parameters in {{ProjectBuildingRequest}}.
Something like this:
{code}
Index:
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
<+>UTF-8
===
---
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
(revision 178d0d0e3af1557f0c1400de33cce9885e1d89ab)
+++
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
(date 1579186139177)
@@ -180,7 +180,9 @@
private ProjectBuildingRequest getProjectBuildingRequest(
AssemblerConfigurationSource configSource )
{
-return configSource.getMavenSession().getProjectBuildingRequest();
+ProjectBuildingRequest pbr =
configSource.getMavenSession().getProjectBuildingRequest();
+pbr.setRemoteRepositories( project.getRemoteArtifactRepositories() );
+return pbr;
}
private boolean isUnpackWithOptions( DependencySet dependencySet )
{code}
It's still unclear for my why plugin tries to "build" project from dependency.
You can see that {{project.getRemoteArtifactRepositories()}} contains all
defined remote repositories, while default
{{pbr.getRemoteArtifactRepositories()}} contains only one.
was (Author: turbanoff):
As I can in debugger see artifacts are downloaded there -
https://github.com/apache/maven-assembly-plugin/blob/master/src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java#L158
Perhaps code should set more parameters in {{ProjectBuildingRequest}}.
Something like this:
{code}
Index:
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
<+>UTF-8
===
---
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
(revision 178d0d0e3af1557f0c1400de33cce9885e1d89ab)
+++
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
(date 1579186139177)
@@ -180,7 +180,9 @@
private ProjectBuildingRequest getProjectBuildingRequest(
AssemblerConfigurationSource configSource )
{
-return configSource.getMavenSession().getProjectBuildingRequest();
+ProjectBuildingRequest pbr =
configSource.getMavenSession().getProjectBuildingRequest();
+pbr.setRemoteRepositories( project.getRemoteArtifactRepositories() );
+return pbr;
}
private boolean isUnpackWithOptions( DependencySet dependencySet )
{code}
It's still unclear for my why plugin tries to "build" project from dependency.
> maven-assembly plugin always downloads dependencies from net
>
>
> Key: MASSEMBLY-874
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-874
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 3.1.0
> Environment: Multi-Module build
>Reporter: Roland Schäuble
>Assignee: Enrico Olivelli
>Priority: Major
> Attachments: make.log,
> maven_assembly_repositories_after_and_before_change.png
>
>
> The maven-assembly-plugin always loads it own dependencies from the internet,
> although the required dependencies are available in the local m2 repositiory.
> The local repository is updated with the dependencies but during the next
> build, the files are downloaded from the internet again instead of getting
> them from the local repo.
> In the attached log, near the end, the unnecessary downloads begin with
> "Downloading from central:
> [https://repo.maven.apache.org/maven2/com/lowagie/itext/2.1.7.js5/itext-2.1.7.js5.pom.;|https://repo.maven.apache.org/maven2/com/lowagie/itext/2.1.7.js5/itext-2.1.7.js5.pom.]
> The files are definitely available in my local repository under
> ~/.m2/repository/com/...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MDEPLOY-266) More verbose output for deployment to trace down errors (esp. 401)
[ https://issues.apache.org/jira/browse/MDEPLOY-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Hohwiller updated MDEPLOY-266: --- Description: There are many reasons why a deployment of maven artifacts can fail: * network error * error on server side in repo server * no login configured * wrong login configured * no password configured * wrong password configured (password may be encrypted so even almost impossible to determine) * repository ID in distribution-management and server ID in settings.xml do not match * etc. It is really hard to check all the possibilities (please note that the distributionManagement may be configured in a parent^N pom and out of sight so you need to print the effective-pom. Many maven users even do not have a clue how to do that). However, maven-deploy-plugin only prints that the deployment failed and an HTTP status code (typically 401). But this is very little information. Tons of users are therefore waisting their own time and especially also the time of others (e.g. OSSRH team) to trace down the reason. It should be trivial for maven-deploy-plugin to log some more informations: * ID of repository that deployment is going to use * whether a server tag from settings.xml could be resolved for this ID * the login that is used for the deployment or a WARNING if login is undefined * WARNING if password is undefined (obviously you should not log the password) With this simple information users could save many hours/days of valuable time to trace down errors more easily. was: There are many reasons why a deployment of maven artifacts can fail: * network error * error on server side in repo server * no login configured * wrong login configured * no password configured * wrong password configured (password may be encrypted so even almost impossible to determine) * repository ID in distribution-management and server ID in settings.xml do not match * etc. It is really hard to check all the possibilities. However, maven-deploy-plugin only prints that the deployment failed and an HTTP status code (typically 401). But this is very little information. Tons of users are therefore waisting their own time and especially also the time of others (e.g. OSSRH team) to trace down the reason. It should be trivial for maven-deploy-plugin to log some more informations: * ID of repository that deployment is going to use * whether a server tag from settings.xml could be resolved for this ID * the login that is used for the deployment or a WARNING if login is undefined * WARNING if password is undefined (obviously you should not log the password) With this simple information users could save many hours/days of valuable time to trace down errors more easily. > More verbose output for deployment to trace down errors (esp. 401) > -- > > Key: MDEPLOY-266 > URL: https://issues.apache.org/jira/browse/MDEPLOY-266 > Project: Maven Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.8.2 >Reporter: Jörg Hohwiller >Priority: Major > > There are many reasons why a deployment of maven artifacts can fail: > * network error > * error on server side in repo server > * no login configured > * wrong login configured > * no password configured > * wrong password configured (password may be encrypted so even almost > impossible to determine) > * repository ID in distribution-management and server ID in settings.xml do > not match > * etc. > It is really hard to check all the possibilities (please note that the > distributionManagement may be configured in a parent^N pom and out of sight > so you need to print the effective-pom. Many maven users even do not have a > clue how to do that). However, maven-deploy-plugin only prints that the > deployment failed and an HTTP status code (typically 401). But this is very > little information. Tons of users are therefore waisting their own time and > especially also the time of others (e.g. OSSRH team) to trace down the reason. > It should be trivial for maven-deploy-plugin to log some more informations: > * ID of repository that deployment is going to use > * whether a server tag from settings.xml could be resolved for this ID > * the login that is used for the deployment or a WARNING if login is > undefined > * WARNING if password is undefined (obviously you should not log the > password) > With this simple information users could save many hours/days of valuable > time to trace down errors more easily. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MDEPLOY-266) More verbose output for deployment to trace down errors (esp. 401)
Jörg Hohwiller created MDEPLOY-266: -- Summary: More verbose output for deployment to trace down errors (esp. 401) Key: MDEPLOY-266 URL: https://issues.apache.org/jira/browse/MDEPLOY-266 Project: Maven Deploy Plugin Issue Type: Improvement Affects Versions: 2.8.2 Reporter: Jörg Hohwiller There are many reasons why a deployment of maven artifacts can fail: * network error * error on server side in repo server * no login configured * wrong login configured * no password configured * wrong password configured (password may be encrypted so even almost impossible to determine) * repository ID in distribution-management and server ID in settings.xml do not match * etc. It is really hard to check all the possibilities. However, maven-deploy-plugin only prints that the deployment failed and an HTTP status code (typically 401). But this is very little information. Tons of users are therefore waisting their own time and especially also the time of others (e.g. OSSRH team) to trace down the reason. It should be trivial for maven-deploy-plugin to log some more informations: * ID of repository that deployment is going to use * whether a server tag from settings.xml could be resolved for this ID * the login that is used for the deployment or a WARNING if login is undefined * WARNING if password is undefined (obviously you should not log the password) With this simple information users could save many hours/days of valuable time to trace down errors more easily. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] suztomo commented on a change in pull request #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
suztomo commented on a change in pull request #277: [MNG-6732] -
DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon
ArtifactTransferException
URL: https://github.com/apache/maven/pull/277#discussion_r367493463
##
File path:
maven-resolver-provider/src/test/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReaderTest.java
##
@@ -27,25 +27,39 @@
import org.eclipse.aether.artifact.DefaultArtifact;
import org.eclipse.aether.impl.ArtifactDescriptorReader;
import org.eclipse.aether.impl.RepositoryEventDispatcher;
+import org.eclipse.aether.repository.RemoteRepository;
import org.eclipse.aether.resolution.ArtifactDescriptorRequest;
import org.mockito.ArgumentCaptor;
public class DefaultArtifactDescriptorReaderTest
extends AbstractRepositoryTestCase
{
-public void testMng5459()
+DefaultArtifactDescriptorReader reader;
Review comment:
Marked them as private.
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
With regards,
Apache Git Services
[GitHub] [maven] suztomo commented on a change in pull request #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
suztomo commented on a change in pull request #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException URL: https://github.com/apache/maven/pull/277#discussion_r367493554 ## File path: maven-resolver-provider/src/test/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReaderTest.java ## @@ -56,11 +70,11 @@ public void testMng5459() reader.readArtifactDescriptor( session, request ); // verify -verify( eventDispatcher ).dispatch( event.capture() ); +verify(mockEventDispatcher).dispatch( eventCaptor.capture() ); Review comment: Fixed. 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 With regards, Apache Git Services
[jira] [Updated] (MNG-6732) DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
[
https://issues.apache.org/jira/browse/MNG-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6732:
Fix Version/s: 3.7.0-candidate
> DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon
> ArtifactTransferException
> -
>
> Key: MNG-6732
> URL: https://issues.apache.org/jira/browse/MNG-6732
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.6.1
>Reporter: Tomo Suzuki
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0-candidate
>
> Attachments: 62884438-89260580-bd04-11e9-8c4a-897d4b736dc7.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> h1. Problem
> Sometimes [Linkage Checker enforcer
> rule|https://github.com/GoogleCloudPlatform/cloud-opensource-java/tree/master/enforcer-rules]
> does not receive resolved artifact list because of a missing artifact even
> when the missing artifact is unused after Maven's dependency mediation.
> h1. Background
> The enforcer rule fails to retrieve artifact list through
> {{DefaultProjectDependenciesResolver.resolve}} when applied to
> [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client]
> because of the missing {{xerces:xerces-impl:2.6.2}}, even though the
> artifact does not appear in the final dependency graph. The artifact does not
> appear in the graph because of Maven's dependency mediation.
> Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central.
> In contrast, the enforcer rule can retrieve artifact list when applied to
> [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker]
> project even though it outputs "[WARNING] The POM for
> xerces:xerces-impl:jar:2.6.2 is missing, no dependency information
> available". The missing artifact does not appear in final dependency graph.
> [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834]
> h1. Diagnosis
> Currently {{DefaultArtifactDescriptorReader.loadPom}} method checks
> "ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon
> ArtifactNotFoundException. This allows
> {{DefaultProjectDependenciesResolver.resolve}} calls
> {{repoSystem.resolveDependencies}} to obtain partially resolved artifact
> list, rather than failing entirely, when there is a missing artifact (such as
> {{xerces:xerces-impl:2.6.2}})
> However, when a retired Maven repository is involved (such as
> [http://repository.codehaus.org/] ),
> {{DefaultArtifactDescriptorReader.loadPom}} gets an ArtifactTransferException
> and throws ArtifactDescriptorException without checking
> "ArtifactDescriptorPolicy.IGNORE_MISSING" policy (excerpt below), and thus
> {{DefaultProjectDependenciesResolver.resolve}} does not return partially
> resolved artifact list.
> {code:java}
> catch ( ArtifactResolutionException e )
> {
> if ( e.getCause() instanceof ArtifactNotFoundException )
> {
> missingDescriptor( session, trace, a, (Exception)
> e.getCause() );
> if ( ( getPolicy( session, a, request ) &
> ArtifactDescriptorPolicy.IGNORE_MISSING ) != 0 )
> {
> return null;
> }
> }
> result.addException( e );
> throw new ArtifactDescriptorException( result );
> }
> {code}
> from
> [DefaultArtifactDescriptorReader.java|https://github.com/apache/maven/blob/d3ace78/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java#L255]
> ArtifactNotFoundException is a special case of
> [ArtifactTransferException|https://maven.apache.org/resolver/apidocs/org/eclipse/aether/transfer/ArtifactTransferException.html].
> h1. Example Project
> Example project to demonstrate the diagnosis:
> [https://github.com/suztomo/maven-missing-artifact] . In this example, even
> though module-b and module-c have the same dependency section, module-c fails
> to run Maven because of a repository section containing a retired repository
> URL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MNG-6732) DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
[
https://issues.apache.org/jira/browse/MNG-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-6732:
---
Assignee: Michael Osipov
> DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon
> ArtifactTransferException
> -
>
> Key: MNG-6732
> URL: https://issues.apache.org/jira/browse/MNG-6732
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.6.1
>Reporter: Tomo Suzuki
>Assignee: Michael Osipov
>Priority: Major
> Attachments: 62884438-89260580-bd04-11e9-8c4a-897d4b736dc7.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> h1. Problem
> Sometimes [Linkage Checker enforcer
> rule|https://github.com/GoogleCloudPlatform/cloud-opensource-java/tree/master/enforcer-rules]
> does not receive resolved artifact list because of a missing artifact even
> when the missing artifact is unused after Maven's dependency mediation.
> h1. Background
> The enforcer rule fails to retrieve artifact list through
> {{DefaultProjectDependenciesResolver.resolve}} when applied to
> [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client]
> because of the missing {{xerces:xerces-impl:2.6.2}}, even though the
> artifact does not appear in the final dependency graph. The artifact does not
> appear in the graph because of Maven's dependency mediation.
> Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central.
> In contrast, the enforcer rule can retrieve artifact list when applied to
> [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker]
> project even though it outputs "[WARNING] The POM for
> xerces:xerces-impl:jar:2.6.2 is missing, no dependency information
> available". The missing artifact does not appear in final dependency graph.
> [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834]
> h1. Diagnosis
> Currently {{DefaultArtifactDescriptorReader.loadPom}} method checks
> "ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon
> ArtifactNotFoundException. This allows
> {{DefaultProjectDependenciesResolver.resolve}} calls
> {{repoSystem.resolveDependencies}} to obtain partially resolved artifact
> list, rather than failing entirely, when there is a missing artifact (such as
> {{xerces:xerces-impl:2.6.2}})
> However, when a retired Maven repository is involved (such as
> [http://repository.codehaus.org/] ),
> {{DefaultArtifactDescriptorReader.loadPom}} gets an ArtifactTransferException
> and throws ArtifactDescriptorException without checking
> "ArtifactDescriptorPolicy.IGNORE_MISSING" policy (excerpt below), and thus
> {{DefaultProjectDependenciesResolver.resolve}} does not return partially
> resolved artifact list.
> {code:java}
> catch ( ArtifactResolutionException e )
> {
> if ( e.getCause() instanceof ArtifactNotFoundException )
> {
> missingDescriptor( session, trace, a, (Exception)
> e.getCause() );
> if ( ( getPolicy( session, a, request ) &
> ArtifactDescriptorPolicy.IGNORE_MISSING ) != 0 )
> {
> return null;
> }
> }
> result.addException( e );
> throw new ArtifactDescriptorException( result );
> }
> {code}
> from
> [DefaultArtifactDescriptorReader.java|https://github.com/apache/maven/blob/d3ace78/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java#L255]
> ArtifactNotFoundException is a special case of
> [ArtifactTransferException|https://maven.apache.org/resolver/apidocs/org/eclipse/aether/transfer/ArtifactTransferException.html].
> h1. Example Project
> Example project to demonstrate the diagnosis:
> [https://github.com/suztomo/maven-missing-artifact] . In this example, even
> though module-b and module-c have the same dependency section, module-c fails
> to run Maven because of a repository section containing a retired repository
> URL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] michael-o commented on a change in pull request #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
michael-o commented on a change in pull request #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException URL: https://github.com/apache/maven/pull/277#discussion_r367489433 ## File path: maven-resolver-provider/src/test/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReaderTest.java ## @@ -56,11 +70,11 @@ public void testMng5459() reader.readArtifactDescriptor( session, request ); // verify -verify( eventDispatcher ).dispatch( event.capture() ); +verify(mockEventDispatcher).dispatch( eventCaptor.capture() ); Review comment: Spaces missing 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 With regards, Apache Git Services
[GitHub] [maven] michael-o commented on a change in pull request #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
michael-o commented on a change in pull request #277: [MNG-6732] -
DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon
ArtifactTransferException
URL: https://github.com/apache/maven/pull/277#discussion_r367489232
##
File path:
maven-resolver-provider/src/test/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReaderTest.java
##
@@ -27,25 +27,39 @@
import org.eclipse.aether.artifact.DefaultArtifact;
import org.eclipse.aether.impl.ArtifactDescriptorReader;
import org.eclipse.aether.impl.RepositoryEventDispatcher;
+import org.eclipse.aether.repository.RemoteRepository;
import org.eclipse.aether.resolution.ArtifactDescriptorRequest;
import org.mockito.ArgumentCaptor;
public class DefaultArtifactDescriptorReaderTest
extends AbstractRepositoryTestCase
{
-public void testMng5459()
+DefaultArtifactDescriptorReader reader;
Review comment:
>
>
> These can be private
I agree, make this and the subsequent ones private
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
With regards,
Apache Git Services
[jira] [Comment Edited] (MASSEMBLY-874) maven-assembly plugin always downloads dependencies from net
[
https://issues.apache.org/jira/browse/MASSEMBLY-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016987#comment-17016987
]
Andrey Turbanov edited comment on MASSEMBLY-874 at 1/16/20 3:25 PM:
As I can in debugger see artifacts are downloaded there -
https://github.com/apache/maven-assembly-plugin/blob/master/src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java#L158
Perhaps code should set more parameters in {{ProjectBuildingRequest}}.
Something like this:
{code}
Index:
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
<+>UTF-8
===
---
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
(revision 178d0d0e3af1557f0c1400de33cce9885e1d89ab)
+++
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
(date 1579186139177)
@@ -180,7 +180,9 @@
private ProjectBuildingRequest getProjectBuildingRequest(
AssemblerConfigurationSource configSource )
{
-return configSource.getMavenSession().getProjectBuildingRequest();
+ProjectBuildingRequest pbr =
configSource.getMavenSession().getProjectBuildingRequest();
+pbr.setRemoteRepositories( project.getRemoteArtifactRepositories() );
+return pbr;
}
private boolean isUnpackWithOptions( DependencySet dependencySet )
{code}
It's still unclear for my why plugin tries to "build" project from dependency.
was (Author: turbanoff):
As I can in debugger see artifacts are downloaded there -
https://github.com/apache/maven-assembly-plugin/blob/master/src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java#L158
Perhaps code should set more parameters in {{ProjectBuildingRequest}}.
Something like this:
{code}
Index:
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
<+>UTF-8
===
---
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
(revision 178d0d0e3af1557f0c1400de33cce9885e1d89ab)
+++
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
(date 1579186139177)
@@ -180,7 +180,9 @@
private ProjectBuildingRequest getProjectBuildingRequest(
AssemblerConfigurationSource configSource )
{
-return configSource.getMavenSession().getProjectBuildingRequest();
+ProjectBuildingRequest pbr =
configSource.getMavenSession().getProjectBuildingRequest();
+pbr.setRemoteRepositories( project.getRemoteArtifactRepositories() );
+return pbr;
}
private boolean isUnpackWithOptions( DependencySet dependencySet )
{code}
> maven-assembly plugin always downloads dependencies from net
>
>
> Key: MASSEMBLY-874
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-874
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 3.1.0
> Environment: Multi-Module build
>Reporter: Roland Schäuble
>Assignee: Enrico Olivelli
>Priority: Major
> Attachments: make.log
>
>
> The maven-assembly-plugin always loads it own dependencies from the internet,
> although the required dependencies are available in the local m2 repositiory.
> The local repository is updated with the dependencies but during the next
> build, the files are downloaded from the internet again instead of getting
> them from the local repo.
> In the attached log, near the end, the unnecessary downloads begin with
> "Downloading from central:
> [https://repo.maven.apache.org/maven2/com/lowagie/itext/2.1.7.js5/itext-2.1.7.js5.pom.;|https://repo.maven.apache.org/maven2/com/lowagie/itext/2.1.7.js5/itext-2.1.7.js5.pom.]
> The files are definitely available in my local repository under
> ~/.m2/repository/com/...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MASSEMBLY-874) maven-assembly plugin always downloads dependencies from net
[
https://issues.apache.org/jira/browse/MASSEMBLY-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016987#comment-17016987
]
Andrey Turbanov edited comment on MASSEMBLY-874 at 1/16/20 2:50 PM:
As I can in debugger see artifacts are downloaded there -
https://github.com/apache/maven-assembly-plugin/blob/master/src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java#L158
Perhaps code should set more parameters in {{ProjectBuildingRequest}}.
Something like this:
{code}
Index:
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
<+>UTF-8
===
---
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
(revision 178d0d0e3af1557f0c1400de33cce9885e1d89ab)
+++
src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java
(date 1579186139177)
@@ -180,7 +180,9 @@
private ProjectBuildingRequest getProjectBuildingRequest(
AssemblerConfigurationSource configSource )
{
-return configSource.getMavenSession().getProjectBuildingRequest();
+ProjectBuildingRequest pbr =
configSource.getMavenSession().getProjectBuildingRequest();
+pbr.setRemoteRepositories( project.getRemoteArtifactRepositories() );
+return pbr;
}
private boolean isUnpackWithOptions( DependencySet dependencySet )
{code}
was (Author: turbanoff):
As I can in debugger see artifacts are downloaded there -
https://github.com/apache/maven-assembly-plugin/blob/master/src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java#L158
Perhaps code should set more parameters in {{ProjectBuildingRequest}}
> maven-assembly plugin always downloads dependencies from net
>
>
> Key: MASSEMBLY-874
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-874
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 3.1.0
> Environment: Multi-Module build
>Reporter: Roland Schäuble
>Assignee: Enrico Olivelli
>Priority: Major
> Attachments: make.log
>
>
> The maven-assembly-plugin always loads it own dependencies from the internet,
> although the required dependencies are available in the local m2 repositiory.
> The local repository is updated with the dependencies but during the next
> build, the files are downloaded from the internet again instead of getting
> them from the local repo.
> In the attached log, near the end, the unnecessary downloads begin with
> "Downloading from central:
> [https://repo.maven.apache.org/maven2/com/lowagie/itext/2.1.7.js5/itext-2.1.7.js5.pom.;|https://repo.maven.apache.org/maven2/com/lowagie/itext/2.1.7.js5/itext-2.1.7.js5.pom.]
> The files are definitely available in my local repository under
> ~/.m2/repository/com/...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MASSEMBLY-874) maven-assembly plugin always downloads dependencies from net
[
https://issues.apache.org/jira/browse/MASSEMBLY-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016987#comment-17016987
]
Andrey Turbanov commented on MASSEMBLY-874:
---
As I can in debugger see artifacts are downloaded there -
https://github.com/apache/maven-assembly-plugin/blob/master/src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java#L158
Perhaps code should set more parameters in {{ProjectBuildingRequest}}
> maven-assembly plugin always downloads dependencies from net
>
>
> Key: MASSEMBLY-874
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-874
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 3.1.0
> Environment: Multi-Module build
>Reporter: Roland Schäuble
>Assignee: Enrico Olivelli
>Priority: Major
> Attachments: make.log
>
>
> The maven-assembly-plugin always loads it own dependencies from the internet,
> although the required dependencies are available in the local m2 repositiory.
> The local repository is updated with the dependencies but during the next
> build, the files are downloaded from the internet again instead of getting
> them from the local repo.
> In the attached log, near the end, the unnecessary downloads begin with
> "Downloading from central:
> [https://repo.maven.apache.org/maven2/com/lowagie/itext/2.1.7.js5/itext-2.1.7.js5.pom.;|https://repo.maven.apache.org/maven2/com/lowagie/itext/2.1.7.js5/itext-2.1.7.js5.pom.]
> The files are definitely available in my local repository under
> ~/.m2/repository/com/...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-shade-plugin] michael-o merged pull request #36: Update CONTRIBUTING hyperlinks
michael-o merged pull request #36: Update CONTRIBUTING hyperlinks URL: https://github.com/apache/maven-shade-plugin/pull/36 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 With regards, Apache Git Services
[GitHub] [maven-shade-plugin] liec0dez opened a new pull request #36: Update CONTRIBUTING hyperlinks
liec0dez opened a new pull request #36: Update CONTRIBUTING hyperlinks URL: https://github.com/apache/maven-shade-plugin/pull/36 - Fix outdated links to dev mailing list and GitHub PR help Following this checklist to help us incorporate your contribution quickly and easily: - [x] ~~Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MSHADE) filed for the change (usually before you start working on it).~~ **Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes.** - [x] Each commit in the pull request should have a meaningful subject line and body. - [ ] ~~Format the pull request title like `[MSHADE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MSHADE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message.~~ - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] ~~Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.~~ - [ ] ~~You have run the integration tests successfully (`mvn -Prun-its clean verify`).~~ If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). 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 With regards, Apache Git Services
[jira] [Comment Edited] (MJAVADOC-617) aggregate-jar does nothing if aggregator modules are referenced using relative pathes and are not in sub folders (
[
https://issues.apache.org/jira/browse/MJAVADOC-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016819#comment-17016819
]
Chris Lott edited comment on MJAVADOC-617 at 1/16/20 11:37 AM:
---
Please tell me if this symptom is caused by the same problem. I have a simple
multi-module project with parent and a single child. Working in the parent, I
invoke the javadoc:aggregate version 3.1.1 feature like this
{noformat}
mvn -f . javadoc:aggregate{noformat}
I know this usage is a little silly, maven defaults to the current directory so
there's no need for the -f option. But it appears harmless.
Anyhhow, when invoked like this the full maven build runs and javadoc is
generated in the child module. But in the last step, where I expect the
aggregation to happen, the plugin shows that it has been invoked:
{noformat}
maven-javadoc-plugin:3.1.1:aggregate{noformat}
But it shows no other output, does not print an error or warning, and it does
not copy the child module's javadoc files into parent/target/site/apidocs/
I tested with version 3.0.1 and saw the expected behavior! So this seems like a
regression in version 3.1.1.
Our workaround is to invoke maven with an absolute path, essentially we do this:
{noformat}
mvn -f $(pwd) javadoc:aggregate{noformat}
and that works fine.
I can open a new issue if necessary.
Thanks in advance!
was (Author: chrislott):
Please tell me if this symptom is caused by the same problem. I have a simple
multi-module project with parent and a single child. Working in the parent, I
invoke the javadoc:aggregate version 3.1.1 feature like this
{noformat}
mvn -f . javadoc:aggregate{noformat}
I know this usage is a little silly, maven defaults to the current directory so
there's no need for the -f option. But it appears harmless.
Anyhhow, when invoked like this the full maven build runs and javadoc is
generated in the child module. But in the last step, where I expect the
aggregation to happen, the plugin shows that it has been invoked:
{noformat}
maven-javadoc-plugin:3.1.1:aggregate{noformat}
But it shows no other output, does not print an error or warning, and it does
not copy the child module's javadoc files into parent/target/site/apidocs/
I tried to fall back to version 3.0.0 but that throws a null pointer exception
:( if there's another version I should try, let me know.
Our workaround is to invoke maven with an absolute path, essentially we do this:
{noformat}
mvn -f $(pwd) javadoc:aggregate{noformat}
and that works fine.
I can open a new issue if necessary.
Thanks in advance!
> aggregate-jar does nothing if aggregator modules are referenced using
> relative pathes and are not in sub folders (
> --
>
> Key: MJAVADOC-617
> URL: https://issues.apache.org/jira/browse/MJAVADOC-617
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0, 3.1.1
>Reporter: Reto Weiss
>Priority: Major
> Attachments: fix.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If an aggregator project has modules that are not located in sub folders and
> are referenced using relative pathes (e.g. "../project1") then the javadoc
> aggregate-jar does nothing.
> It does not fail but no javadoc is generated at all.
> This works with 3.0.1.
> See attached Zip File with three projects all, project1 and project2. Project
> all is the aggregator project. It references project 1 and project 2 with
> ../project1 and ../project2
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MJAVADOC-617) aggregate-jar does nothing if aggregator modules are referenced using relative pathes and are not in sub folders (
[
https://issues.apache.org/jira/browse/MJAVADOC-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016819#comment-17016819
]
Chris Lott edited comment on MJAVADOC-617 at 1/16/20 11:35 AM:
---
Please tell me if this symptom is caused by the same problem. I have a simple
multi-module project with parent and a single child. Working in the parent, I
invoke the javadoc:aggregate version 3.1.1 feature like this
{noformat}
mvn -f . javadoc:aggregate{noformat}
I know this usage is a little silly, maven defaults to the current directory so
there's no need for the -f option. But it appears harmless.
Anyhhow, when invoked like this the full maven build runs and javadoc is
generated in the child module. But in the last step, where I expect the
aggregation to happen, the plugin shows that it has been invoked:
{noformat}
maven-javadoc-plugin:3.1.1:aggregate{noformat}
But it shows no other output, does not print an error or warning, and it does
not copy the child module's javadoc files into parent/target/site/apidocs/
I tried to fall back to version 3.0.0 but that throws a null pointer exception
:( if there's another version I should try, let me know.
Our workaround is to invoke maven with an absolute path, essentially we do this:
{noformat}
mvn -f $(pwd) javadoc:aggregate{noformat}
and that works fine.
I can open a new issue if necessary.
Thanks in advance!
was (Author: chrislott):
Please tell me if this symptom is caused by the same problem. I have a simple
multi-module project with parent and a single child. Working in the parent, I
invoke the javadoc:aggregate version 3.1.1 feature like this
{noformat}
mvn -f . javadoc:aggregate{noformat}
I know this usage is a little silly, maven defaults to the current directory so
there's no need for the -f option. But it appears harmless.
Anyhhow, when invoked like this the full maven build runs and javadoc is
generated in the child module. But in the last step, where I expect the
aggregation to happen, the plugin shows that it has been invoked:
{noformat}
maven-javadoc-plugin:3.1.1:aggregate{noformat}
But it shows no other output, does not print an error or warning, and it does
not copy the child module's javadoc files into parent/target/site/apidocs/
I tried to fall back to version 3.0.0 but that throws a null pointer exception
:( if there's another version I should try, let me know.
I can open a new issue if necessary.
Thanks in advance!
> aggregate-jar does nothing if aggregator modules are referenced using
> relative pathes and are not in sub folders (
> --
>
> Key: MJAVADOC-617
> URL: https://issues.apache.org/jira/browse/MJAVADOC-617
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0, 3.1.1
>Reporter: Reto Weiss
>Priority: Major
> Attachments: fix.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If an aggregator project has modules that are not located in sub folders and
> are referenced using relative pathes (e.g. "../project1") then the javadoc
> aggregate-jar does nothing.
> It does not fail but no javadoc is generated at all.
> This works with 3.0.1.
> See attached Zip File with three projects all, project1 and project2. Project
> all is the aggregator project. It references project 1 and project 2 with
> ../project1 and ../project2
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MJAVADOC-617) aggregate-jar does nothing if aggregator modules are referenced using relative pathes and are not in sub folders (
[
https://issues.apache.org/jira/browse/MJAVADOC-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016819#comment-17016819
]
Chris Lott edited comment on MJAVADOC-617 at 1/16/20 11:33 AM:
---
Please tell me if this symptom is caused by the same problem. I have a simple
multi-module project with parent and a single child. Working in the parent, I
invoke the javadoc:aggregate version 3.1.1 feature like this
{noformat}
mvn -f . javadoc:aggregate{noformat}
I know this usage is a little silly, maven defaults to the current directory so
there's no need for the -f option. But it appears harmless.
Anyhhow, when invoked like this the full maven build runs and javadoc is
generated in the child module. But in the last step, where I expect the
aggregation to happen, the plugin shows that it has been invoked:
{noformat}
maven-javadoc-plugin:3.1.1:aggregate{noformat}
But it shows no other output, does not print an error or warning, and it does
not copy the child module's javadoc files into parent/target/site/apidocs/
I tried to fall back to version 3.0.0 but that throws a null pointer exception
:( if there's another version I should try, let me know.
I can open a new issue if necessary.
Thanks in advance!
was (Author: chrislott):
Please tell me if this symptom is caused by the same problem. I have a simple
multi-module project with parent and a single child. Working in the parent, I
invoke the javadoc:aggregate version 3.1.1 feature like this
{noformat}
mvn -f . javadoc:aggregate{noformat}
I know this usage is a little silly, maven defaults to the current directory so
there's no need for the -f option. But it appears harmless.
Anyhhow, when invoked like this the full maven build runs and javadoc is
generated in the child module. But in the last step, where I expect the
aggregation to happen, the plugin shows that it has been invoked:
{noformat}
maven-javadoc-plugin:3.1.1:aggregate{noformat}
But it shows no other output, does not print an error or warning, and it does
not copy the child module's javadoc files into parent/target/site/apidocs/
Thanks in advance!
> aggregate-jar does nothing if aggregator modules are referenced using
> relative pathes and are not in sub folders (
> --
>
> Key: MJAVADOC-617
> URL: https://issues.apache.org/jira/browse/MJAVADOC-617
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0, 3.1.1
>Reporter: Reto Weiss
>Priority: Major
> Attachments: fix.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If an aggregator project has modules that are not located in sub folders and
> are referenced using relative pathes (e.g. "../project1") then the javadoc
> aggregate-jar does nothing.
> It does not fail but no javadoc is generated at all.
> This works with 3.0.1.
> See attached Zip File with three projects all, project1 and project2. Project
> all is the aggregator project. It references project 1 and project 2 with
> ../project1 and ../project2
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MJAVADOC-617) aggregate-jar does nothing if aggregator modules are referenced using relative pathes and are not in sub folders (
[
https://issues.apache.org/jira/browse/MJAVADOC-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016819#comment-17016819
]
Chris Lott edited comment on MJAVADOC-617 at 1/16/20 11:32 AM:
---
Please tell me if this symptom is caused by the same problem. I have a simple
multi-module project with parent and a single child. Working in the parent, I
invoke the javadoc:aggregate version 3.1.1 feature like this
{noformat}
mvn -f . javadoc:aggregate{noformat}
I know this usage is a little silly, maven defaults to the current directory so
there's no need for the -f option. But it appears harmless.
Anyhhow, when invoked like this the full maven build runs and javadoc is
generated in the child module. But in the last step, where I expect the
aggregation to happen, the plugin shows that it has been invoked:
{noformat}
maven-javadoc-plugin:3.1.1:aggregate{noformat}
But it shows no other output, does not print an error or warning, and it does
not copy the child module's javadoc files into parent/target/site/apidocs/
Thanks in advance!
was (Author: chrislott):
Please tell me if this symptom is caused by the same problem. I have a simple
multi-module project with parent and a single child. Working in the parent, I
invoke the javadoc:aggregate version 3.1.1 feature like this
{noformat}
mvn -f . javadoc:aggregate{noformat}
The full build runs and javadoc is generated in the child module. But in the
last step, where I expect the aggregation to happen, the plugin shows that it
has been invoked:
{noformat}
maven-javadoc-plugin:3.1.1:aggregate{noformat}
But it shows no other output, does not print an error or warning, and it does
not copy the child module's javadoc files into parent/target/site/apidocs/
Thanks in advance!
> aggregate-jar does nothing if aggregator modules are referenced using
> relative pathes and are not in sub folders (
> --
>
> Key: MJAVADOC-617
> URL: https://issues.apache.org/jira/browse/MJAVADOC-617
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0, 3.1.1
>Reporter: Reto Weiss
>Priority: Major
> Attachments: fix.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If an aggregator project has modules that are not located in sub folders and
> are referenced using relative pathes (e.g. "../project1") then the javadoc
> aggregate-jar does nothing.
> It does not fail but no javadoc is generated at all.
> This works with 3.0.1.
> See attached Zip File with three projects all, project1 and project2. Project
> all is the aggregator project. It references project 1 and project 2 with
> ../project1 and ../project2
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MJAVADOC-617) aggregate-jar does nothing if aggregator modules are referenced using relative pathes and are not in sub folders (
[
https://issues.apache.org/jira/browse/MJAVADOC-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016819#comment-17016819
]
Chris Lott commented on MJAVADOC-617:
-
Please tell me if this symptom is caused by the same problem. I have a simple
multi-module project with parent and a single child. Working in the parent, I
invoke the javadoc:aggregate version 3.1.1 feature like this
{noformat}
mvn -f . javadoc:aggregate{noformat}
The full build runs and javadoc is generated in the child module. But in the
last step, where I expect the aggregation to happen, the plugin shows that it
has been invoked:
{noformat}
maven-javadoc-plugin:3.1.1:aggregate{noformat}
But it shows no other output, does not print an error or warning, and it does
not copy the child module's javadoc files into parent/target/site/apidocs/
Thanks in advance!
> aggregate-jar does nothing if aggregator modules are referenced using
> relative pathes and are not in sub folders (
> --
>
> Key: MJAVADOC-617
> URL: https://issues.apache.org/jira/browse/MJAVADOC-617
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0, 3.1.1
>Reporter: Reto Weiss
>Priority: Major
> Attachments: fix.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If an aggregator project has modules that are not located in sub folders and
> are referenced using relative pathes (e.g. "../project1") then the javadoc
> aggregate-jar does nothing.
> It does not fail but no javadoc is generated at all.
> This works with 3.0.1.
> See attached Zip File with three projects all, project1 and project2. Project
> all is the aggregator project. It references project 1 and project 2 with
> ../project1 and ../project2
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MPMD-241) Document the version relationship between plugin and pmd
[ https://issues.apache.org/jira/browse/MPMD-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel updated MPMD-241: Fix Version/s: 3.13.0 > Document the version relationship between plugin and pmd > > > Key: MPMD-241 > URL: https://issues.apache.org/jira/browse/MPMD-241 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: tankilo >Assignee: Andreas Dangel >Priority: Minor > Fix For: 3.13.0 > > > I search through https://maven.apache.org/plugins/maven-pmd-plugin/index.html > and failed to find any release history that explains the version relationship > between maven pmd plugin and pmd itself. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MPMD-241) Document the version relationship between plugin and pmd
[ https://issues.apache.org/jira/browse/MPMD-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel reassigned MPMD-241: --- Assignee: Andreas Dangel > Document the version relationship between plugin and pmd > > > Key: MPMD-241 > URL: https://issues.apache.org/jira/browse/MPMD-241 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: tankilo >Assignee: Andreas Dangel >Priority: Minor > > I search through https://maven.apache.org/plugins/maven-pmd-plugin/index.html > and failed to find any release history that explains the version relationship > between maven pmd plugin and pmd itself. -- 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=17016800#comment-17016800 ] David Kornel commented on SUREFIRE-1730: [~tibordigana] Hello, how it's going with M5 release? > 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] [Updated] (MPMD-241) Document the version relationship between plugin and pmd
[ https://issues.apache.org/jira/browse/MPMD-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel updated MPMD-241: Summary: Document the version relationship between plugin and pmd (was: Please provide the version relationship between plugin and pmd) > Document the version relationship between plugin and pmd > > > Key: MPMD-241 > URL: https://issues.apache.org/jira/browse/MPMD-241 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: tankilo >Priority: Minor > > I search through https://maven.apache.org/plugins/maven-pmd-plugin/index.html > and failed to find any release history that explains the version relationship > between maven pmd plugin and pmd itself. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-dependency-plugin] pzygielo commented on issue #30: (doc) Fix protocol and change repository address
pzygielo commented on issue #30: (doc) Fix protocol and change repository address URL: https://github.com/apache/maven-dependency-plugin/pull/30#issuecomment-575082945 I didn't check it before, but it seems that [Jenkins job](https://builds.apache.org/job/maven-box/job/maven-dependency-plugin/job/master/53/testReport/) reported the same. 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 With regards, Apache Git Services
[jira] [Updated] (MPMD-225) Create report even if no warnings have been found by default
[ https://issues.apache.org/jira/browse/MPMD-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel updated MPMD-225: Fix Version/s: 3.13.0 > Create report even if no warnings have been found by default > - > > Key: MPMD-225 > URL: https://issues.apache.org/jira/browse/MPMD-225 > Project: Maven PMD Plugin > Issue Type: Wish >Reporter: Johannes Wienke >Assignee: Andreas Dangel >Priority: Major > Fix For: 3.13.0 > > > Right now, no report for the site plugin is generated if no violations have > been found. This is sometimes quite confusing as this state cannot be > distinguished from "the plugin didn't work at all". Checkstyle for example > just generates an empty report in these cases, which is what I would also > like for the pmd plugin. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MPMD-225) Create report even if no warnings have been found by default
[ https://issues.apache.org/jira/browse/MPMD-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel updated MPMD-225: Summary: Create report even if no warnings have been found by default (was: Create report even if no warnings have been found) > Create report even if no warnings have been found by default > - > > Key: MPMD-225 > URL: https://issues.apache.org/jira/browse/MPMD-225 > Project: Maven PMD Plugin > Issue Type: Wish >Reporter: Johannes Wienke >Priority: Major > > Right now, no report for the site plugin is generated if no violations have > been found. This is sometimes quite confusing as this state cannot be > distinguished from "the plugin didn't work at all". Checkstyle for example > just generates an empty report in these cases, which is what I would also > like for the pmd plugin. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MPMD-225) Create report even if no warnings have been found by default
[ https://issues.apache.org/jira/browse/MPMD-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel reassigned MPMD-225: --- Assignee: Andreas Dangel > Create report even if no warnings have been found by default > - > > Key: MPMD-225 > URL: https://issues.apache.org/jira/browse/MPMD-225 > Project: Maven PMD Plugin > Issue Type: Wish >Reporter: Johannes Wienke >Assignee: Andreas Dangel >Priority: Major > > Right now, no report for the site plugin is generated if no violations have > been found. This is sometimes quite confusing as this state cannot be > distinguished from "the plugin didn't work at all". Checkstyle for example > just generates an empty report in these cases, which is what I would also > like for the pmd plugin. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MANTRUN-200) Scriptdef tasks fail to load when running on Java9
[
https://issues.apache.org/jira/browse/MANTRUN-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016706#comment-17016706
]
Dan Berindei commented on MANTRUN-200:
--
For future reference, this did not work for me:
{code:xml}
{code}
I got
{noformat}
[ERROR] /home/dan/Work/scriptdef-test/build.xml:3: Reference
maven.plugin.classpath not found.
{noformat}
This worked:
{code:xml}
{code}
> Scriptdef tasks fail to load when running on Java9
> --
>
> Key: MANTRUN-200
> URL: https://issues.apache.org/jira/browse/MANTRUN-200
> Project: Maven Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Dan Berindei
>Assignee: Robert Scholte
>Priority: Major
>
> I have a Maven project using maven-antrun-plugin:
> {code}
>
>
>4.0.0
>my-test-app
>my-test-group
>1.0-SNAPSHOT
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.8
>
>
> compile
> compile
>
>
>
>
>
>
>
>
> run
>
>
>
>
>
>
>
> {code}
> The Ant build file uses a script:
> {code}
>
>
>
>
>
>
>
>
>
> {code}
> On Java 8 it works, but on Java 9 (9-ea+162) it can't find the script engine:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (compile) on
> project my-test-app: An Ant BuildException has occured: The following error
> occurred while executing this line:
> /home/dan/scriptdef-test/build.xml:10: Unable to create javax script engine
> for javascript
> around Ant part .. @ 4:47 in
> /home/dan/scriptdef-test/target/antrun/build-main.xml
> ...
> Caused by: /home/dan/scriptdef-test/build.xml:10: Unable to create javax
> script engine for javascript
> at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:84)
> at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
> at
> org.apache.tools.ant.taskdefs.optional.script.ScriptDef.executeScript(ScriptDef.java:350)
> at
> org.apache.tools.ant.taskdefs.optional.script.ScriptDefBase.execute(ScriptDefBase.java:50)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:547)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:435)
> at org.apache.tools.ant.Target.performTasks(Target.java:456)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:441)
> ... 34 more
> {noformat}
> I have attached a debugger and I saw that the {{ScriptEngineManager}} used by
> {{JavaxScriptRunner}} doesn't have any script engines, because the service
> loader it uses doesn't find any {{ScriptEngineFactory}} implementations. I
> have tried {{\--add-modules jdk.scripting.nashorn}} and {{\--add-opens
> jdk.scripting.nashorn/jdk.nashorn.api.scripting=ALL-UNNAMED}}, but neither
> helped.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-dependency-plugin] pzygielo opened a new pull request #30: (doc) Fix protocol and change repository address
pzygielo opened a new pull request #30: (doc) Fix protocol and change repository address URL: https://github.com/apache/maven-dependency-plugin/pull/30 Protocol change due to https://support.sonatype.com/hc/en-us/articles/360041287334. Upon connection to http://repo1.maven.org/maven2/ following is presented: > 501 HTTPS Required. > Use https://repo1.maven.org/maven2/ > More information at https://links.sonatype.com/central/501-https-required Address change due to TestGetMojo failures: > Error transferring file: java.security.cert.CertificateException: > No subject alternative DNS name matching repo1.maven.apache.org found --- To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) 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 With regards, Apache Git Services
[jira] [Updated] (MPMD-296) Copy ruleset files into a subdirectory of target
[
https://issues.apache.org/jira/browse/MPMD-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Dangel updated MPMD-296:
Description:
>From MPMD-289:
{quote}
if we're copying ruleset files into the build dir & expecting very specific
(and somewhat generic) file names in downstream processes, we should output
everything into specific sub-directories under the maven build directory (e.g.,
target/pmd/report/pmd.xml, target/pmd/rulesets/pmd.xml)
{quote}
Note: This improvement will change existing behavior by default.
Therefore a new parameter should be introduced to allow to change it back to
the old behavior.
Reason why this improvement makes sense: In case, your ruleset is called
"pmd.xml", then this conflicts with the report format xml, which is written to
"target/pmd.xml" as well. Therefore, the rulesets should be copied into
"target/pmd/rulesets/..." instead of to "target/" directly.
was:
>From MPMD-289:
{quote}
if we're copying ruleset files into the build dir & expecting very specific
(and somewhat generic) file names in downstream processes, we should output
everything into specific sub-directories under the maven build directory (e.g.,
target/pmd/report/pmd.xml, target/pmd/rulesets/pmd.xml)
{quote}
Note: This improvement will change existing behavior by default.
Therefore a new parameter should be introduced to allow to change it back to
the old behavior.
Reason why this improvement makes sense: In case, your ruleset is called
"pmd.xml", then this conflicts with the report format xml, which is written to
"target/pmd.xml" as well. Therefore, the rulesets should be copied into
"target/pmd-rulesets/..." instead of to "target/" directly.
> Copy ruleset files into a subdirectory of target
>
>
> Key: MPMD-296
> URL: https://issues.apache.org/jira/browse/MPMD-296
> Project: Maven PMD Plugin
> Issue Type: Improvement
> Components: PMD
>Reporter: Andreas Dangel
>Assignee: Andreas Dangel
>Priority: Major
> Fix For: 3.13.0
>
>
> From MPMD-289:
> {quote}
> if we're copying ruleset files into the build dir & expecting very specific
> (and somewhat generic) file names in downstream processes, we should output
> everything into specific sub-directories under the maven build directory
> (e.g., target/pmd/report/pmd.xml, target/pmd/rulesets/pmd.xml)
> {quote}
> Note: This improvement will change existing behavior by default.
> Therefore a new parameter should be introduced to allow to change it back to
> the old behavior.
> Reason why this improvement makes sense: In case, your ruleset is called
> "pmd.xml", then this conflicts with the report format xml, which is written
> to "target/pmd.xml" as well. Therefore, the rulesets should be copied into
> "target/pmd/rulesets/..." instead of to "target/" directly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
