[jira] [Created] (MSITE-813) Broken link to codehaus wiki
Bernd Eckenfels created MSITE-813: - Summary: Broken link to codehaus wiki Key: MSITE-813 URL: https://issues.apache.org/jira/browse/MSITE-813 Project: Maven Site Plugin Issue Type: Bug Components: documentation Reporter: Bernd Eckenfels The currently deployed site for the maven-jar-plugin (MJAR) has a broken link to docs.codehaus.org/display/MAVENUSER/JAR+Plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-2802) Concurrent-safe access to local Maven repository
[ https://issues.apache.org/jira/browse/MNG-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-2802: Description: It seems that access to local Maven repository is not concurrent-safe that is multiple Mavens running in parallel may damage contents of local Maven repository. It would be a nice improvement, because sharing of local repository will lower the need for contacting any other repository. I know that Maven proxy can be used, but that adds another layer which may unnecessarily stress the machine it runs on. *NOTE:* http://takari.io/book/30-team-maven.html#concurrent-safe-local-repository is a Takari Extension for Apache Maven that introduces a concurrent-safe local-repository. was:It seems that access to local Maven repository is not concurrent-safe that is multiple Mavens running in parallel may damage contents of local Maven repository. It would be a nice improvement, because sharing of local repository will lower the need for contacting any other repository. I know that Maven proxy can be used, but that adds another layer which may unnecessarily stress the machine it runs on. > Concurrent-safe access to local Maven repository > > > Key: MNG-2802 > URL: https://issues.apache.org/jira/browse/MNG-2802 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Stepan Roh >Assignee: John Casey >Priority: Major > Fix For: Issues to be reviewed for 3.x > > > It seems that access to local Maven repository is not concurrent-safe that is > multiple Mavens running in parallel may damage contents of local Maven > repository. It would be a nice improvement, because sharing of local > repository will lower the need for contacting any other repository. I know > that Maven proxy can be used, but that adds another layer which may > unnecessarily stress the machine it runs on. > *NOTE:* > http://takari.io/book/30-team-maven.html#concurrent-safe-local-repository is > a Takari Extension for Apache Maven that introduces a concurrent-safe > local-repository. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MSHARED-701) Remove installation of pom checksum - IT's do not fail
Karl Heinz Marbaise created MSHARED-701:
---
Summary: Remove installation of pom checksum - IT's do not fail
Key: MSHARED-701
URL: https://issues.apache.org/jira/browse/MSHARED-701
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-artifact-transfer
Affects Versions: maven-artifact-transfer-0.10.0
Reporter: Karl Heinz Marbaise
Assignee: Karl Heinz Marbaise
Fix For: maven-artifact-transfer-0.10.0
DefaultProjectInstaller:
{code:java}
if ( isPomArtifact )
{
if ( pomFile != null )
{
installer.install( buildingRequest,
Collections.singletonList( new
ProjectArtifact( project ) ) );
installChecksums( buildingRequest, artifact, createChecksum );
addMetaDataFilesForArtifact( buildingRequest, artifact,
metadataFiles, createChecksum );
}
}
{code}
If I comment out the above line {{installChecksums(...);}} unfortunately the
IT's don't show me that.
This mean in consequence I need supplemental IT's to check this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] Coogrr commented on issue #3: Added Documentation for duplicateBehaviour option
Coogrr commented on issue #3: Added Documentation for duplicateBehaviour option URL: https://github.com/apache/maven-assembly-plugin/pull/3#issuecomment-373469025 Yeah, that makes sense to me, I've made changes that should do that. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SUREFIRE-1497) Flag to select modulepath or classpath
[ https://issues.apache.org/jira/browse/SUREFIRE-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16400685#comment-16400685 ] Stephen Colebourne commented on SUREFIRE-1497: -- The attachment shows the problem. When surefire is set to v2.21.0 it tests in "module mode", using the service list in module-info.java. When surefire is set to v2.20.1 it tests in "classpath mode", using the service list in META-INF/services. The attached project is setup such that "module mode" is correct but "classpath mode" has a bug. As a library author, I cannot control or know whether the project will be used in "module mode" or "classpath mode". As such, what is needed is a way to test in both "module mode" and "classpath mode" - at present surefire provides no mechanism to test both modes. NOTE: The attached project uses surefire v2.21.0 so will pass. Change the pom.xml version of surefire to v2.20.1 to see it fail (because the META-INF/services file is incorrect). > Flag to select modulepath or classpath > -- > > Key: SUREFIRE-1497 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1497 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.21.0 >Reporter: Stephen Colebourne >Priority: Major > Attachments: maven-issue4.zip > > > SUREFIRE-1262 added the ability to run tests using the modulepath, which is > great. However, as a library developer I cannot guarantee that the code will > be run on the modulepath, it might well be run on the classpath. > As such, can I request a flag that turns the behaviour in SUREFIRE-1262 on > and off? This would allow a single pom.xml to run surefire twice, once with > the code on the modulepath and once with the code on the classpath, to ensure > that the behaviour always works however the code is run. (Other solutions to > achieve the same goal may be possible, but this seems the most obvious). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MSHARED-700) Upgrade parent to 31
[ https://issues.apache.org/jira/browse/MSHARED-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MSHARED-700. --- Resolution: Fixed Done in [1fa3c89078c4d6509a2f3945dec6e95b83df6b5d|https://gitbox.apache.org/repos/asf?p=maven-invoker.git;a=commitdiff;h=1fa3c89078c4d6509a2f3945dec6e95b83df6b5d] > Upgrade parent to 31 > > > Key: MSHARED-700 > URL: https://issues.apache.org/jira/browse/MSHARED-700 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-invoker >Affects Versions: maven-invoker-3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-invoker-3.0.1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1497) Flag to select modulepath or classpath
[ https://issues.apache.org/jira/browse/SUREFIRE-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne updated SUREFIRE-1497: - Attachment: maven-issue4.zip > Flag to select modulepath or classpath > -- > > Key: SUREFIRE-1497 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1497 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.21.0 >Reporter: Stephen Colebourne >Priority: Major > Attachments: maven-issue4.zip > > > SUREFIRE-1262 added the ability to run tests using the modulepath, which is > great. However, as a library developer I cannot guarantee that the code will > be run on the modulepath, it might well be run on the classpath. > As such, can I request a flag that turns the behaviour in SUREFIRE-1262 on > and off? This would allow a single pom.xml to run surefire twice, once with > the code on the modulepath and once with the code on the classpath, to ensure > that the behaviour always works however the code is run. (Other solutions to > achieve the same goal may be possible, but this seems the most obvious). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MCOMPILER-330) Add java.* JPMS modules for testing only is hard
Stephen Colebourne created MCOMPILER-330: Summary: Add java.* JPMS modules for testing only is hard Key: MCOMPILER-330 URL: https://issues.apache.org/jira/browse/MCOMPILER-330 Project: Maven Compiler Plugin Issue Type: Improvement Affects Versions: 3.7.0 Environment: Windows 10, Maven v3.5.2 Reporter: Stephen Colebourne Attachments: maven-issue3.zip Attached is a project demonstrating this issue (which affects both compiler and surefire). The basic problem here is where the project depends on a java.* module for testing but not at compile time. For example, the test code depends on `java.desktop` module, but the main code does not. While this has similarities with MCOMPILER-320 it is different because there is no way to refer to the `java.*` JPMS modules as dependencies. Right now the workaround is to add both --add-modules and --add-reads, as shown in the attachment. This is painful low-level stuff that Maven should be hiding the user from. NOTE: the attachment will succeed when run. Delete the compiler/surefire plugin config to see the issue. Rather than tackle this problem directly, my preference would be to have a module-patch.java file that allows users to declare additional dependencies/exports/services that only apply at testing time. This would be interpreted whenever --patch-module is being used. (As well as the example explained here, I've also run into the need to export packages that only exist in tests, and this currently also requires low-level argLine manipulation). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MCOMPILER-329) Compile fails with optional and scope test sections with JPMS modules
Stephen Colebourne created MCOMPILER-329: Summary: Compile fails with optional and scope test sections with JPMS modules Key: MCOMPILER-329 URL: https://issues.apache.org/jira/browse/MCOMPILER-329 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 3.7.0 Environment: Windows 10, Maven v3.5.2 Reporter: Stephen Colebourne Attachments: maven-issue2.zip Attached is a simple project that demonstrates this bug. The pom.xml has one significant dependency - Guava, an automatic module. The same dependency is added twice - once declared optional and once declared as scope=test. In addition, the module-info declares the dependency using `requires static`. The duplicate dependency causes the plugin problems determining the modulepath, as the result is the error "module not found". It isn't clear whether the module isn't being added to the modulepath or whether it is there and not being seen. While this may be an odd setup, it greatly complicated finding SUREFIRE-1501 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1501) Optional dependencies not correctly handled with JPMS modules
[ https://issues.apache.org/jira/browse/SUREFIRE-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne updated SUREFIRE-1501: - Description: Attached is a pointlessly simple project for Java 9. The module-info declares an _optional_ dependency on Google Guava (an automatic module) using _requires static_. This optionality is reflected in the pom.xml, where the dependency is marked as optional. It fails in surefire with JAVA_HOME=jdk9. The reason seems to be that although the Guava jar file is added to the modulepath, it is not referenced using --add-modules. As such, the module graph builder never pulls it in, despite it being on the modulepath. (Optional dependencies need to be directly added using --add-modules if in Maven's dependency graph) Adding the --add-modules to the `argLine` parameter solves the problem, but this is a bug because the surefire plugin should handle the situation without manually adding it. NOTE! The attachment has the --add-modules manually added to the pom.xml. Remove it to see the bug. was: Attached is a pointlessly simple project for Java 9. The module-info declares an _optional_ dependency on Google Guava (an automatic module) using _requires static_. This optionality is reflected in the pom.xml, where the dependency is marked as optional. It fails in surefire with JAVA_HOME=jdk9. The reason seems to be that although the Guava jar file is added to the modulepath, it is not referenced using --add-modules. As such, the module graph builder never pulls it in, despite it being on the modulepath. (Optional dependencies need to be directly added using --add-modules if in Maven's dependency graph) Adding the --add-modules to the `argLine` parameter solves the problem, but this is a bug because the surefire plugin should handle the situation without manually adding it. > Optional dependencies not correctly handled with JPMS modules > - > > Key: SUREFIRE-1501 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1501 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.21.0 > Environment: Windows 10, Maven v3.5.2 >Reporter: Stephen Colebourne >Priority: Major > Attachments: maven-issue1.zip > > > Attached is a pointlessly simple project for Java 9. The module-info declares > an _optional_ dependency on Google Guava (an automatic module) using > _requires static_. This optionality is reflected in the pom.xml, where the > dependency is marked as optional. > It fails in surefire with JAVA_HOME=jdk9. The reason seems to be that > although the Guava jar file is added to the modulepath, it is not referenced > using --add-modules. As such, the module graph builder never pulls it in, > despite it being on the modulepath. (Optional dependencies need to be > directly added using --add-modules if in Maven's dependency graph) > Adding the --add-modules to the `argLine` parameter solves the problem, but > this is a bug because the surefire plugin should handle the situation without > manually adding it. > NOTE! The attachment has the --add-modules manually added to the pom.xml. > Remove it to see the bug. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SUREFIRE-1501) Optional dependencies not correctly handled with JPMS modules
Stephen Colebourne created SUREFIRE-1501: Summary: Optional dependencies not correctly handled with JPMS modules Key: SUREFIRE-1501 URL: https://issues.apache.org/jira/browse/SUREFIRE-1501 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.21.0 Environment: Windows 10, Maven v3.5.2 Reporter: Stephen Colebourne Attachments: maven-issue1.zip Attached is a pointlessly simple project for Java 9. The module-info declares an _optional_ dependency on Google Guava (an automatic module) using _requires static_. This optionality is reflected in the pom.xml, where the dependency is marked as optional. It fails in surefire with JAVA_HOME=jdk9. The reason seems to be that although the Guava jar file is added to the modulepath, it is not referenced using --add-modules. As such, the module graph builder never pulls it in, despite it being on the modulepath. (Optional dependencies need to be directly added using --add-modules if in Maven's dependency graph) Adding the --add-modules to the `argLine` parameter solves the problem, but this is a bug because the surefire plugin should handle the situation without manually adding it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-2802) Concurrent-safe access to local Maven repository
[ https://issues.apache.org/jira/browse/MNG-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16400127#comment-16400127 ] Erik Håkansson commented on MNG-2802: - This issue plagues a lot of our builds. A lock file with a PID seems like it should solve the issue. > Concurrent-safe access to local Maven repository > > > Key: MNG-2802 > URL: https://issues.apache.org/jira/browse/MNG-2802 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Stepan Roh >Assignee: John Casey >Priority: Major > Fix For: Issues to be reviewed for 3.x > > > It seems that access to local Maven repository is not concurrent-safe that is > multiple Mavens running in parallel may damage contents of local Maven > repository. It would be a nice improvement, because sharing of local > repository will lower the need for contacting any other repository. I know > that Maven proxy can be used, but that adds another layer which may > unnecessarily stress the machine it runs on. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
