[jira] [Commented] (MDEP-494) Remove/replace Maven2 specific code
[ https://issues.apache.org/jira/browse/MDEP-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802468#comment-16802468 ] John Lin commented on MDEP-494: --- Hi, I created https://issues.apache.org/jira/browse/MDEP-644 to reintroduce the verbose option for dependency:tree. > Remove/replace Maven2 specific code > --- > > Key: MDEP-494 > URL: https://issues.apache.org/jira/browse/MDEP-494 > Project: Maven Dependency Plugin > Issue Type: Improvement >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MDEP-644) Reintroduce the verbose option for dependency:tree
John Lin created MDEP-644: - Summary: Reintroduce the verbose option for dependency:tree Key: MDEP-644 URL: https://issues.apache.org/jira/browse/MDEP-644 Project: Maven Dependency Plugin Issue Type: New Feature Components: tree Reporter: John Lin The verbose option for dependency:tree is removed in maven-dependency-plugin 3.0. This issue is to reintroduce the option. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MDEP-639) Not showing omitted dependencies when running dependency:tree verbose
[
https://issues.apache.org/jira/browse/MDEP-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802464#comment-16802464
]
John Lin edited comment on MDEP-639 at 3/27/19 5:41 AM:
It seems that it is expected:
[https://github.com/apache/maven-dependency-plugin/pull/4/files|https://github.com/apache/maven-dependency-plugin/pull/4/files.].
They removed the verbose option since maven-dependency-plugin 3.0.
was (Author: johnlinp):
It seems that it is expected:
[https://github.com/apache/maven-dependency-plugin/pull/4/files|https://github.com/apache/maven-dependency-plugin/pull/4/files.].
They removed the verbose option in Maven 3.0.
> Not showing omitted dependencies when running dependency:tree verbose
> -
>
> Key: MDEP-639
> URL: https://issues.apache.org/jira/browse/MDEP-639
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: tree
>Affects Versions: 3.1.1
> Environment: Ubuntu 18.04.1 LTS (64-bit) Bionic Beaver Linux
> 4.15.0-44-generic x86_64
>Reporter: Grzegorz Solecki
>Priority: Major
>
> When you run:
> {code:sh}
> $ mvn dependency:tree -Dverbose
> {code}
> it does not show omitted dependencies.
> It happens for version 3+.
> When I change to 2.10 it is working flawlessly
> Environment details:
> {code:sh}
> $ mvn -version
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> 2018-10-24T14:41:47-04:00)
> Maven home: /home/grzsol1/dev/tls/mvn/current
> Java version: 1.8.0_191, vendor: Oracle Corporation, runtime:
> /home/grzsol1/dev/jdk/jdk1.8.0_191/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-44-generic", arch: "amd64", family: "unix"
> Ubuntu 18.04.1 LTS (64-bit) Bionic Beaver Linux 4.15.0-44-generic x86_64
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MDEP-639) Not showing omitted dependencies when running dependency:tree verbose
[
https://issues.apache.org/jira/browse/MDEP-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802464#comment-16802464
]
John Lin commented on MDEP-639:
---
It seems that it is expected:
[https://github.com/apache/maven-dependency-plugin/pull/4/files|https://github.com/apache/maven-dependency-plugin/pull/4/files.].
They removed the verbose option in Maven 3.0.
> Not showing omitted dependencies when running dependency:tree verbose
> -
>
> Key: MDEP-639
> URL: https://issues.apache.org/jira/browse/MDEP-639
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: tree
>Affects Versions: 3.1.1
> Environment: Ubuntu 18.04.1 LTS (64-bit) Bionic Beaver Linux
> 4.15.0-44-generic x86_64
>Reporter: Grzegorz Solecki
>Priority: Major
>
> When you run:
> {code:sh}
> $ mvn dependency:tree -Dverbose
> {code}
> it does not show omitted dependencies.
> It happens for version 3+.
> When I change to 2.10 it is working flawlessly
> Environment details:
> {code:sh}
> $ mvn -version
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> 2018-10-24T14:41:47-04:00)
> Maven home: /home/grzsol1/dev/tls/mvn/current
> Java version: 1.8.0_191, vendor: Oracle Corporation, runtime:
> /home/grzsol1/dev/jdk/jdk1.8.0_191/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-44-generic", arch: "amd64", family: "unix"
> Ubuntu 18.04.1 LTS (64-bit) Bionic Beaver Linux 4.15.0-44-generic x86_64
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-surefire] Tibor17 commented on issue #224: Work-in-progress Test new travis script
Tibor17 commented on issue #224: Work-in-progress Test new travis script URL: https://github.com/apache/maven-surefire/pull/224#issuecomment-476945489 This build [1] on branch `parallel` shows that we can make it within 47:20 min on Windows Server 2008 and 33 min on Ubuntu. [1]: https://builds.apache.org/job/maven-box/job/maven-surefire/job/parallel/2 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-surefire] asfgit closed pull request #210: [SUREFIRE-1222] ForkClient attempts to consume unrelated lines
asfgit closed pull request #210: [SUREFIRE-1222] ForkClient attempts to consume unrelated lines URL: https://github.com/apache/maven-surefire/pull/210 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-surefire] Tibor17 edited a comment on issue #224: Work-in-progress Test new travis script
Tibor17 edited a comment on issue #224: Work-in-progress Test new travis script URL: https://github.com/apache/maven-surefire/pull/224#issuecomment-476867529 @eolivelli Can you try to configure `maven-failsafe-plugin` to run parallel ITs in module `surefire-its`? How many CPU do we have on TravisCI? We should maybe run parallel tests with `maven-invoker-plugin` in the module `maven-failsafe-plugin`. Is it possible in TravisCI to call another workspace from this one as we know it in Jenkins? As for instance two or three sets of ITs would run one by one in forked jobs. 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] (MDEP-631) purge-local-repository doesn't include dependencies with scope provided
[
https://issues.apache.org/jira/browse/MDEP-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802242#comment-16802242
]
Robert Kleinschmager commented on MDEP-631:
---
I have debugged the problem down to it's source, but failed for now, to solve
it.
So I would like to describe my current findings:
Find attached an integration test, which confirms the problem:
[^MDEP-631-its.patch]
The problem can be nailed to
[maven-resolver-impl-1.1.1:DefaultDependencyCollector.java#L375|https://github.com/apache/maven-resolver/blob/maven-resolver-1.1.1/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultDependencyCollector.java#L375]
(I found maven-artifact-transfer-0.11.0 and maven-resolver-impl-1.1.1 on the
classpath). There an {{DependencySelector}} is decinding, that the _pprovided_
dependency can be skipped. This {{DependencySelector}} is configured to skip
all dependencies with scope _test_ and _provided_ (see attached
[^MDEP-631-problemsource-stracktrace.png] ). Following the stacktrace (see
attached [^MDEP-631-problemsource-stracktrace.png] ) shows, that this
{{DependencySelector}} is directly coming from the {{RepositorySystemSession}}
which is taken at
[PurgeLocalRepositoryMojo.java#L576|https://github.com/apache/maven-dependency-plugin/blob/maven-dependency-plugin-3.1.1/src/main/java/org/apache/maven/plugins/dependency/PurgeLocalRepositoryMojo.java#L576].
As most of the code lies within _maven-artifact-transfer_ or _maven-resolver_,
we have small chances to do something. One idea, which came into my mind was,
to provide an independent, but fully loaded {{RepositorySystemSession}} with a
different {{DependencySelector}} instance. This idea failed, as
{{DependencySelector}} is not directly on the classpath and [~khmarbaise] and
[~rfscholte] confirmed, that solution would not be easy.
> purge-local-repository doesn't include dependencies with scope provided
> ---
>
> Key: MDEP-631
> URL: https://issues.apache.org/jira/browse/MDEP-631
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: purge-local-repository
>Affects Versions: 3.1.1
>Reporter: Benjamin Donze
>Priority: Major
> Labels: up-for-grabs
> Attachments: MDEP-631-its.patch,
> MDEP-631-problemsource-stracktrace.png, MDEP-631-problemsource-variables.png
>
>
> When configuring a goal using purge-local-repository within a pom file the
> dependencies with of the module with scope provided are not purged from local
> repository.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MDEP-631) purge-local-repository doesn't include dependencies with scope provided
[ https://issues.apache.org/jira/browse/MDEP-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Kleinschmager updated MDEP-631: -- Attachment: MDEP-631-its.patch > purge-local-repository doesn't include dependencies with scope provided > --- > > Key: MDEP-631 > URL: https://issues.apache.org/jira/browse/MDEP-631 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: purge-local-repository >Affects Versions: 3.1.1 >Reporter: Benjamin Donze >Priority: Major > Labels: up-for-grabs > Attachments: MDEP-631-its.patch, > MDEP-631-problemsource-stracktrace.png, MDEP-631-problemsource-variables.png > > > When configuring a goal using purge-local-repository within a pom file the > dependencies with of the module with scope provided are not purged from local > repository. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MDEP-631) purge-local-repository doesn't include dependencies with scope provided
[ https://issues.apache.org/jira/browse/MDEP-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Kleinschmager updated MDEP-631: -- Attachment: MDEP-631-problemsource-stracktrace.png MDEP-631-problemsource-variables.png > purge-local-repository doesn't include dependencies with scope provided > --- > > Key: MDEP-631 > URL: https://issues.apache.org/jira/browse/MDEP-631 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: purge-local-repository >Affects Versions: 3.1.1 >Reporter: Benjamin Donze >Priority: Major > Labels: up-for-grabs > Attachments: MDEP-631-its.patch, > MDEP-631-problemsource-stracktrace.png, MDEP-631-problemsource-variables.png > > > When configuring a goal using purge-local-repository within a pom file the > dependencies with of the module with scope provided are not purged from local > repository. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MSHARED-810) Support Java 12
[ https://issues.apache.org/jira/browse/MSHARED-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rune Flobakk updated MSHARED-810: - Description: ASM 7.1 supports Java 12 (and supposedly Java 13): [https://asm.ow2.io/versions.html] I have upgraded to v7.1 and tested it with maven-dependency-plugin:analyze on a Java 12 project, and it works fine with only the dependency update. [https://github.com/runeflobakk/maven-dependency-analyzer/commit/a8f026e296109badafdd57312b5032d4f5d33fcc] I am happy to make a pull request for it! (or if you prefer to just make the simple change yourself, that's would of course also be great. Just wanted to let you know of the simple change to make it compatible with Java 12) was: ASM 7.1 supports Java 12 (and supposedly Java 13): [https://asm.ow2.io/versions.html] I have upgraded to v7.1 and tested it with maven-dependency-plugin:analyze on a Java 12 project, and it works fine with only the dependency update. [https://github.com/runeflobakk/maven-dependency-analyzer/commit/a8f026e296109badafdd57312b5032d4f5d33fcc] I am happy to make a pull request for it! > Support Java 12 > --- > > Key: MSHARED-810 > URL: https://issues.apache.org/jira/browse/MSHARED-810 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-analyzer >Affects Versions: maven-dependency-analyzer-1.11.1 >Reporter: Rune Flobakk >Priority: Minor > Labels: Java12 > > ASM 7.1 supports Java 12 (and supposedly Java 13): > [https://asm.ow2.io/versions.html] > I have upgraded to v7.1 and tested it with maven-dependency-plugin:analyze on > a Java 12 project, and it works fine with only the dependency update. > [https://github.com/runeflobakk/maven-dependency-analyzer/commit/a8f026e296109badafdd57312b5032d4f5d33fcc] > I am happy to make a pull request for it! > (or if you prefer to just make the simple change yourself, that's would of > course also be great. Just wanted to let you know of the simple change to > make it compatible with Java 12) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-surefire] Tibor17 commented on issue #224: Work-in-progress Test new travis script
Tibor17 commented on issue #224: Work-in-progress Test new travis script URL: https://github.com/apache/maven-surefire/pull/224#issuecomment-476867529 @eolivelli Can you try to configure `maven-failsafe-plugin` to run parallel ITs in module `surefire-its`? How many CPU do we have on TravisCI? We should maybe run parallel tests with `maven-invoker-plugin` in the module `maven-failsafe-plugin`. 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] (MGPG-69) Drop Maven 2 support (require Maven 3)
[ https://issues.apache.org/jira/browse/MGPG-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802199#comment-16802199 ] Hudson commented on MGPG-69: Build failed in Jenkins: Maven TLP » maven-gpg-plugin » MGPG-69 #2 See https://builds.apache.org/job/maven-box/job/maven-gpg-plugin/job/MGPG-69/2/ > Drop Maven 2 support (require Maven 3) > -- > > Key: MGPG-69 > URL: https://issues.apache.org/jira/browse/MGPG-69 > Project: Maven GPG Plugin > Issue Type: Improvement >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-checkstyle-plugin] eolivelli commented on issue #10: [MCHECKSTYLE-163] Add integration test
eolivelli commented on issue #10: [MCHECKSTYLE-163] Add integration test URL: https://github.com/apache/maven-checkstyle-plugin/pull/10#issuecomment-476824933 I will merge soon, thanks 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-checkstyle-plugin] eolivelli commented on issue #11: [MCHECKSTYLE-54] Add integration test
eolivelli commented on issue #11: [MCHECKSTYLE-54] Add integration test URL: https://github.com/apache/maven-checkstyle-plugin/pull/11#issuecomment-476825057 I will merge soon, thanks 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-checkstyle-plugin] eolivelli commented on issue #5: [MCHECKSTYLE-353] - Don't resolve any dependencies
eolivelli commented on issue #5: [MCHECKSTYLE-353] - Don't resolve any dependencies URL: https://github.com/apache/maven-checkstyle-plugin/pull/5#issuecomment-476824750 @zregvart did you have time to test the new proposal ? I would like to cut a release and I am mostly waiting only for this patch 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-6538) Upgrade Maven Artifact Resolver to 1.3.3 to restore API
[ https://issues.apache.org/jira/browse/MNG-6538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802103#comment-16802103 ] Hudson commented on MNG-6538: - Build succeeded in Jenkins: Maven TLP » maven » runITsWithJavaEA #25 See https://builds.apache.org/job/maven-box/job/maven/job/runITsWithJavaEA/25/ > Upgrade Maven Artifact Resolver to 1.3.3 to restore API > --- > > Key: MNG-6538 > URL: https://issues.apache.org/jira/browse/MNG-6538 > Project: Maven > Issue Type: Task > Components: Embedding >Affects Versions: 3.6.0 >Reporter: Hervé Boutemy >Assignee: Karl Heinz Marbaise >Priority: Major > Fix For: 3.6.1 > > > IntelliJ IDEA Maven integration was broken by API removal done in MRESOLVER-36 > the missing API was added back (with empty implementation) in MRESOLVER-64 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6543) Upgrade plexus classworld to support java 9+ ClassLoader.findClass(String moduleName, String name) in Mojos
[ https://issues.apache.org/jira/browse/MNG-6543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802105#comment-16802105 ] Hudson commented on MNG-6543: - Build succeeded in Jenkins: Maven TLP » maven » runITsWithJavaEA #25 See https://builds.apache.org/job/maven-box/job/maven/job/runITsWithJavaEA/25/ > Upgrade plexus classworld to support java 9+ ClassLoader.findClass(String > moduleName, String name) in Mojos > --- > > Key: MNG-6543 > URL: https://issues.apache.org/jira/browse/MNG-6543 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.6.0 >Reporter: Romain Manni-Bucau >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.6.1 > > Attachments: MNG-6543-xjc.zip > > > Goal is to include > https://github.com/codehaus-plexus/plexus-classworlds/pull/4 in Maven and > enable Mojos using this Java 9 new JPMS API to work under java 9+ > see [Java 9 ClassLoader.findClass(String moduleName,String > name)|https://docs.oracle.com/javase/9/docs/api/java/lang/ClassLoader.html#findClass-java.lang.String-java.lang.String-] > see MNG-6506 for more details -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6506) Mojos are unable to load package annotations on Java >= 9
[
https://issues.apache.org/jira/browse/MNG-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802104#comment-16802104
]
Hudson commented on MNG-6506:
-
Build succeeded in Jenkins: Maven TLP » maven » runITsWithJavaEA #25
See https://builds.apache.org/job/maven-box/job/maven/job/runITsWithJavaEA/25/
> Mojos are unable to load package annotations on Java >= 9
> -
>
> Key: MNG-6506
> URL: https://issues.apache.org/jira/browse/MNG-6506
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.6.0
>Reporter: Andreas Veithen
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: up-for-grabs
> Fix For: 3.6.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> On Java 9 and above, calls to {{java.lang.Package.getAnnotation(Class)}} from
> within a Mojo always return {{null}} (unless the {{package-info}} class has
> been loaded by some other means before).
> The reason appears to be an incompatibility between Java 9 and Plexus
> Classworlds:
> * Java 9 ultimately calls {{findClass}} (instead of {{loadClass}}) to get the
> {{package-info}} class.
> * The {{findClass}} implementation in {{ClassRealm}} always throws
> {{ClassNotFoundException}}:
> https://github.com/codehaus-plexus/plexus-classworlds/blob/master/src/main/java/org/codehaus/plexus/classworlds/realm/ClassRealm.java#L275.
> This in particular affects plugins that interact with the JAXB API because it
> relies on package annotations.
> A workaround is to preload the required {{package-info}} classes using
> {{loadClass}}; see e.g. http://svn.apache.org/viewvc?rev=1845026=rev.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6522) Prepare Maven's Core Integration Test Suite to test with Java 12 and 13-ea
[ https://issues.apache.org/jira/browse/MNG-6522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802106#comment-16802106 ] Hudson commented on MNG-6522: - Build succeeded in Jenkins: Maven TLP » maven » runITsWithJavaEA #25 See https://builds.apache.org/job/maven-box/job/maven/job/runITsWithJavaEA/25/ > Prepare Maven's Core Integration Test Suite to test with Java 12 and 13-ea > -- > > Key: MNG-6522 > URL: https://issues.apache.org/jira/browse/MNG-6522 > Project: Maven > Issue Type: Improvement > Components: Integration Tests >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.1 > > > * JDK 12 Windows and Linux (/) > - JDK 13 Window and Linux (/) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-surefire] eolivelli commented on issue #224: Work-in-progress Test new travis script
eolivelli commented on issue #224: Work-in-progress Test new travis script URL: https://github.com/apache/maven-surefire/pull/224#issuecomment-476819827 @Tibor17 build on this branch is working, but I think it will exceed the 50 min timeout. It is a limitation of free Travis account 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] [Closed] (MASSEMBLY-907) Dependencies are not included when run with mvn install
[ https://issues.apache.org/jira/browse/MASSEMBLY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MASSEMBLY-907. - Resolution: Not A Problem Assignee: Karl Heinz Marbaise So first I would say this issue is not bug anymore ? If you have a different opinion please let me know...and give me more details. Apart from that If you have an example project of that structure github or a like I can take a look...cause from my first feeling the usage of maven-resources-plugin and maven-assembly-plugin sounds a little bit wrong but I'm not sure cause I don't know the exact situation. So now this has become a support question which should be continued on the users mailing list > Dependencies are not included when run with mvn install > --- > > Key: MASSEMBLY-907 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-907 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Lau Bakman >Assignee: Karl Heinz Marbaise >Priority: Major > Attachments: assembly_deps.zip > > > We have just updated to version 3.1.1 due to MASSEMBLY-873 and have stumbled > upon a problem. > Our project is structured similar to the attached project. When we build our > project using "mvn clean package" the project is assembled correctly > including dependencies. If we on the other hand build our project using "mvn > clean install", only the top level jar files are assembled and all > dependencies are missing. > This worked in version 3.1.0. > Is this by design? And if it is, is there a way to revert to the old behavior? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-surefire] Tibor17 commented on issue #224: Work-in-progress Test new travis script
Tibor17 commented on issue #224: Work-in-progress Test new travis script URL: https://github.com/apache/maven-surefire/pull/224#issuecomment-476800622 The build is still in queue. Why we support only `master` - such limitation? This branch `fix/new-travis` is not 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-surefire] eolivelli commented on issue #224: Work-in-progress Test new travis script
eolivelli commented on issue #224: Work-in-progress Test new travis script URL: https://github.com/apache/maven-surefire/pull/224#issuecomment-476797714 @Tibor17 see https://travis-ci.org/apache/maven-surefire/jobs/511615879 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] (MJAVADOC-591) javadoc fails with maven.compiler.release=8 and Automatic-Module-Name
[
https://issues.apache.org/jira/browse/MJAVADOC-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Varga updated MJAVADOC-591:
--
Description:
In a module, which defines an Automatic-Module-Name and (inherits)
maven.compiler.release=8, but does not set source=8, javadoc generation fails
with:
{code:java}
16052 [ERROR] Exit code: 2 - error: option --module-path not allowed with
target 8
16052 [ERROR] error: option --add-modules not allowed with target 8
16052 [ERROR] error: option --patch-module not allowed with target 8
16053 [ERROR]
16053 [ERROR] Command line was: /home/nite/jdk-12/bin/javadoc @options @packages
{code}
This occurs with both javadoc-11.0.2 and javadoc-12. Using either
maven-javadoc-plugin-3.0.1, defining source=8 or removing Automatic-Module-Name
works just fine.
I think the problem is that maven.compiler.release is propagated to release
property, but that is not taken into account when --add-modules is generated
and propagated.
was:
In a module, which defines an Automatic-Module-Name and (inherits)
maven.compiler.release=8, but does not set source=8, javadoc generation fails
with:
{code:java}
16052 [ERROR] Exit code: 2 - error: option --module-path not allowed with
target 8
16052 [ERROR] error: option --add-modules not allowed with target 8
16052 [ERROR] error: option --patch-module not allowed with target 8
16053 [ERROR]
16053 [ERROR] Command line was: /home/nite/jdk-12/bin/javadoc @options @packages
{code}
This occurs with both javadoc-11.0.2 and javadoc-12. Using either
maven-javadoc-plugin-3.0.1 or defining source=8 works just fine.
I think the problem is that maven.compiler.release is propagated to release
property, but that is not taken into account when --add-modules is generated
and propagated.
> javadoc fails with maven.compiler.release=8 and Automatic-Module-Name
> -
>
> Key: MJAVADOC-591
> URL: https://issues.apache.org/jira/browse/MJAVADOC-591
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Robert Varga
>Priority: Major
>
> In a module, which defines an Automatic-Module-Name and (inherits)
> maven.compiler.release=8, but does not set source=8, javadoc generation fails
> with:
> {code:java}
> 16052 [ERROR] Exit code: 2 - error: option --module-path not allowed with
> target 8
> 16052 [ERROR] error: option --add-modules not allowed with target 8
> 16052 [ERROR] error: option --patch-module not allowed with target 8
> 16053 [ERROR]
> 16053 [ERROR] Command line was: /home/nite/jdk-12/bin/javadoc @options
> @packages
> {code}
> This occurs with both javadoc-11.0.2 and javadoc-12. Using either
> maven-javadoc-plugin-3.0.1, defining source=8 or removing
> Automatic-Module-Name works just fine.
> I think the problem is that maven.compiler.release is propagated to release
> property, but that is not taken into account when --add-modules is generated
> and propagated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-591) javadoc fails with maven.compiler.release=8 and Automatic-Module-Name
Robert Varga created MJAVADOC-591:
-
Summary: javadoc fails with maven.compiler.release=8 and
Automatic-Module-Name
Key: MJAVADOC-591
URL: https://issues.apache.org/jira/browse/MJAVADOC-591
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 3.1.0
Reporter: Robert Varga
In a module, which defines an Automatic-Module-Name and (inherits)
maven.compiler.release=8, but does not set source=8, javadoc generation fails
with:
{code:java}
16052 [ERROR] Exit code: 2 - error: option --module-path not allowed with
target 8
16052 [ERROR] error: option --add-modules not allowed with target 8
16052 [ERROR] error: option --patch-module not allowed with target 8
16053 [ERROR]
16053 [ERROR] Command line was: /home/nite/jdk-12/bin/javadoc @options @packages
{code}
This occurs with both javadoc-11.0.2 and javadoc-12. Using either
maven-javadoc-plugin-3.0.1 or defining source=8 works just fine.
I think the problem is that maven.compiler.release is propagated to release
property, but that is not taken into account when --add-modules is generated
and propagated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-surefire] Tibor17 commented on issue #224: Work-in-progress Test new travis script
Tibor17 commented on issue #224: Work-in-progress Test new travis script URL: https://github.com/apache/maven-surefire/pull/224#issuecomment-476778190 There's still jdk 11.0.2 in runtime. Why is that? The `openjdk8` was not installed? 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-surefire] eolivelli opened a new pull request #224: Work-in-progress Test new travis script
eolivelli opened a new pull request #224: Work-in-progress Test new travis script URL: https://github.com/apache/maven-surefire/pull/224 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-surefire] eolivelli closed pull request #224: Work-in-progress Test new travis script
eolivelli closed pull request #224: Work-in-progress Test new travis script URL: https://github.com/apache/maven-surefire/pull/224 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] [Created] (MNGSITE-365) EOL page surprisingly links to current M3 plugins
Paul Benedict created MNGSITE-365:
-
Summary: EOL page surprisingly links to current M3 plugins
Key: MNGSITE-365
URL: https://issues.apache.org/jira/browse/MNGSITE-365
Project: Maven Project Web Site
Issue Type: Improvement
Reporter: Paul Benedict
Assignee: Paul Benedict
The EOL page has links on "Plugin" and "Version" columns. The former links to
the current plugin sites; the second links to the last M2 versions,
respectively.
An unsuspecting user (like me!) was clicking through the "Plugin" column, and
didn't realize it was the current documentation. This is a small usability
issue, but one I believe should be fixed. I am supporting ancient M2 stuff so I
come to the page often. The links are too good of a trap.
Recommendation:
# Set the "Plugin" links to their EOL versions.
# Amend the "Plugin" values to include the V of the GAV (to make explicit the
connection between the two columns). Example: {{clean:2.6.1}}
# Remove the "Version" links.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-907) Dependencies are not included when run with mvn install
[ https://issues.apache.org/jira/browse/MASSEMBLY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801896#comment-16801896 ] Lau Bakman commented on MASSEMBLY-907: -- Thank you for your time on this issue. Just trying to understand what is happening. I am using a dir format because I am assembling an application that includes native libraries as well. I use the assembly plugin (and later maven-resources-plugin) to build a directory structure that I can take and use directly for my installers. For example: module-services: Root folder for my services. |- libs: Directory containing jar dependencies used by my services |- win32: Directory containing Windows 32-bit native libraries |- win64: Directory containing Windows 64-bit native libraries |- linux32: Directory containing Linux 32-bit native libraries |- linux64: Directory containing Linux 64-bit native libraries | launcher.jar: Service launcher | *-service.jar: A number of services loaded by the service launcher - these may vary on the build and these are the ones I would like to avoid specifying dependencies for. My installer step will then grab the service files, libs directory and the appropriate native directory from the module-services folder and create an installer for the appropriate architecture. I do not know if it is the right tool for the job, but maven-assembly-plugin have been doing great until now. If you have any suggestions on how to do this differently, I am open to new ideas. As for the different combinations, the only thing I changed in my project when discovering this problem was the version of maven-assembly-plugin. > Dependencies are not included when run with mvn install > --- > > Key: MASSEMBLY-907 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-907 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Lau Bakman >Priority: Major > Attachments: assembly_deps.zip > > > We have just updated to version 3.1.1 due to MASSEMBLY-873 and have stumbled > upon a problem. > Our project is structured similar to the attached project. When we build our > project using "mvn clean package" the project is assembled correctly > including dependencies. If we on the other hand build our project using "mvn > clean install", only the top level jar files are assembled and all > dependencies are missing. > This worked in version 3.1.0. > Is this by design? And if it is, is there a way to revert to the old behavior? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-907) Dependencies are not included when run with mvn install
[ https://issues.apache.org/jira/browse/MASSEMBLY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801872#comment-16801872 ] Karl Heinz Marbaise commented on MASSEMBLY-907: --- This can be a coincidence based on using a different version of JDK a different version of Maven or different version of the assembly-plugin etc. or simply changed the order of modules in your pom file etc. which changed the order of the reactor. Furthermore I don't know why you are using the format: dir ...in your descriptor. And yes you have to do the dependencies to be sure the reactor is in the expected order... > Dependencies are not included when run with mvn install > --- > > Key: MASSEMBLY-907 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-907 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Lau Bakman >Priority: Major > Attachments: assembly_deps.zip > > > We have just updated to version 3.1.1 due to MASSEMBLY-873 and have stumbled > upon a problem. > Our project is structured similar to the attached project. When we build our > project using "mvn clean package" the project is assembled correctly > including dependencies. If we on the other hand build our project using "mvn > clean install", only the top level jar files are assembled and all > dependencies are missing. > This worked in version 3.1.0. > Is this by design? And if it is, is there a way to revert to the old behavior? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MSHARED-810) Support Java 12
Rune Flobakk created MSHARED-810: Summary: Support Java 12 Key: MSHARED-810 URL: https://issues.apache.org/jira/browse/MSHARED-810 Project: Maven Shared Components Issue Type: Bug Components: maven-dependency-analyzer Affects Versions: maven-dependency-analyzer-1.11.1 Reporter: Rune Flobakk ASM 7.1 supports Java 12 (and supposedly Java 13): [https://asm.ow2.io/versions.html] I have upgraded to v7.1 and tested it with maven-dependency-plugin:analyze on a Java 12 project, and it works fine with only the dependency update. [https://github.com/runeflobakk/maven-dependency-analyzer/commit/a8f026e296109badafdd57312b5032d4f5d33fcc] I am happy to make a pull request for it! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-907) Dependencies are not included when run with mvn install
[ https://issues.apache.org/jira/browse/MASSEMBLY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801867#comment-16801867 ] Lau Bakman commented on MASSEMBLY-907: -- Interesting. I have tried to add the dependency to the assembly pom and that does indeed include the dependencies in the output, although the output is no longer structured as I expect it to be. But that is a different matter for me to figure out. Just a few things: * Reading the FAQ ([http://maven.apache.org/components/plugins/maven-assembly-plugin/faq.html#module-binaries]). I do not get an error when building my original project. Everything seems to work - except that the dependencies are missing from my output. * I am curious as to why this has worked for us since we started using maven-assembly-plugin in 2014 and only just stopped working with version 3.1.1 and also why only when executed using "mvn install" and not "mvn package". We have a configuration where we want to package all jar files with similar artifact id's, like the "spike.services.*" example. Having to maintain an additional dependency list is something that we would like to avoid if possible. > Dependencies are not included when run with mvn install > --- > > Key: MASSEMBLY-907 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-907 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Lau Bakman >Priority: Major > Attachments: assembly_deps.zip > > > We have just updated to version 3.1.1 due to MASSEMBLY-873 and have stumbled > upon a problem. > Our project is structured similar to the attached project. When we build our > project using "mvn clean package" the project is assembled correctly > including dependencies. If we on the other hand build our project using "mvn > clean install", only the top level jar files are assembled and all > dependencies are missing. > This worked in version 3.1.0. > Is this by design? And if it is, is there a way to revert to the old behavior? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-907) Dependencies are not included when run with mvn install
[
https://issues.apache.org/jira/browse/MASSEMBLY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801826#comment-16801826
]
Karl Heinz Marbaise commented on MASSEMBLY-907:
---
The simple issue is that you a relying on the defined order of modules in your
parent {{pom.xml}} which is defined as:
{code:xml}
common
services
assembly
{code}
But this is not reliable.
In your {{assembly}} you have to define dependencies to the modules you would
like have been packaged in your assembly. and that would make sure the order of
building is the one you expect..In consequence you have to add dependencies in
the {{pom.xml}} of the {{assembly}} module. The definition of the module set in
the assembly descriptor will not influence the build order of the reactor.
> Dependencies are not included when run with mvn install
> ---
>
> Key: MASSEMBLY-907
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-907
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Lau Bakman
>Priority: Major
> Attachments: assembly_deps.zip
>
>
> We have just updated to version 3.1.1 due to MASSEMBLY-873 and have stumbled
> upon a problem.
> Our project is structured similar to the attached project. When we build our
> project using "mvn clean package" the project is assembled correctly
> including dependencies. If we on the other hand build our project using "mvn
> clean install", only the top level jar files are assembled and all
> dependencies are missing.
> This worked in version 3.1.0.
> Is this by design? And if it is, is there a way to revert to the old behavior?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven-surefire] eolivelli opened a new pull request #224: Work-in-progress Test new travis script
eolivelli opened a new pull request #224: Work-in-progress Test new travis script URL: https://github.com/apache/maven-surefire/pull/224 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] [Created] (MASSEMBLY-907) Dependencies are not included when run with mvn install
Lau Bakman created MASSEMBLY-907: Summary: Dependencies are not included when run with mvn install Key: MASSEMBLY-907 URL: https://issues.apache.org/jira/browse/MASSEMBLY-907 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 3.1.1 Reporter: Lau Bakman Attachments: assembly_deps.zip We have just updated to version 3.1.1 due to MASSEMBLY-873 and have stumbled upon a problem. Our project is structured similar to the attached project. When we build our project using "mvn clean package" the project is assembled correctly including dependencies. If we on the other hand build our project using "mvn clean install", only the top level jar files are assembled and all dependencies are missing. This worked in version 3.1.0. Is this by design? And if it is, is there a way to revert to the old behavior? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1655) Surefire leaks classloaders when using in-process strategy
[ https://issues.apache.org/jira/browse/SUREFIRE-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Oehme updated SUREFIRE-1655: --- Description: The test classloader is created [here|https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/InPluginVMSurefireStarter.java#L77], but never closed. As a result, the underlying JARs in that classloader remain open and cannot be deleted. Also, their content can be stale when opened using java.util.ZipFile. This is a problem when running Maven integration tests using the Embedded3xLauncher. We are developing a Maven extension and want to make sure it works well with surefire/failsafe. This classloader leak means we have to use a forking launcher instead, which slows down our tests considerably. was: The test classloader is created [here|[https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/InPluginVMSurefireStarter.java#L77]], but never closed. As a result, the underlying JARs in that classloader remain open and cannot be deleted. Also, their content can be stale when opened using java.util.ZipFile. This is a problem when running Maven integration tests using the Embedded3xLauncher. We are developing a Maven extension and want to make sure it works well with surefire/failsafe. This classloader leak means we have to use a forking launcher instead, which slows down our tests considerably. > Surefire leaks classloaders when using in-process strategy > -- > > Key: SUREFIRE-1655 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1655 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Stefan Oehme >Priority: Minor > > The test classloader is created > [here|https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/InPluginVMSurefireStarter.java#L77], > but never closed. As a result, the underlying JARs in that classloader > remain open and cannot be deleted. Also, their content can be stale when > opened using java.util.ZipFile. > This is a problem when running Maven integration tests using the > Embedded3xLauncher. We are developing a Maven extension and want to make sure > it works well with surefire/failsafe. This classloader leak means we have to > use a forking launcher instead, which slows down our tests considerably. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1655) Surefire leaks classloaders when using in-process strategy
[ https://issues.apache.org/jira/browse/SUREFIRE-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Oehme updated SUREFIRE-1655: --- Description: The test classloader is created [here|[https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/InPluginVMSurefireStarter.java#L77]], but never closed. As a result, the underlying JARs in that classloader remain open and cannot be deleted. Also, their content can be stale when opened using java.util.ZipFile. This is a problem when running Maven integration tests using the Embedded3xLauncher. We are developing a Maven extension and want to make sure it works well with surefire/failsafe. This classloader leak means we have to use a forking launcher instead, which slows down our tests considerably. was: The test classloader is created [here| [https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/InPluginVMSurefireStarter.java#L77]], but never closed. As a result, the underlying JARs in that classloader remain open and cannot be deleted. Also, their content can be stale when opened using java.util.ZipFile. This is a problem when running Maven integration tests using the Embedded3xLauncher. We are developing a Maven extension and want to make sure it works well with surefire/failsafe. This classloader leak means we have to use a forking launcher instead, which slows down our tests considerably. > Surefire leaks classloaders when using in-process strategy > -- > > Key: SUREFIRE-1655 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1655 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Stefan Oehme >Priority: Minor > > The test classloader is created > [here|[https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/InPluginVMSurefireStarter.java#L77]], > but never closed. As a result, the underlying JARs in that classloader > remain open and cannot be deleted. Also, their content can be stale when > opened using java.util.ZipFile. > This is a problem when running Maven integration tests using the > Embedded3xLauncher. We are developing a Maven extension and want to make sure > it works well with surefire/failsafe. This classloader leak means we have to > use a forking launcher instead, which slows down our tests considerably. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1655) Surefire leaks classloaders when using in-process strategy
[ https://issues.apache.org/jira/browse/SUREFIRE-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Oehme updated SUREFIRE-1655: --- Description: The test classloader is created [here| [https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/InPluginVMSurefireStarter.java#L77]], but never closed. As a result, the underlying JARs in that classloader remain open and cannot be deleted. Also, their content can be stale when opened using java.util.ZipFile. This is a problem when running Maven integration tests using the Embedded3xLauncher. We are developing a Maven extension and want to make sure it works well with surefire/failsafe. This classloader leak means we have to use a forking launcher instead, which slows down our tests considerably. was: The test classloader is created [here|[https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/InPluginVMSurefireStarter.java#L77]], but never closed. As a result, the underlying JARs in that classloader remain open and cannot be deleted. Also, their content can be stale when opened using java.util.ZipFile. This is a problem when running Maven integration tests using the Embedded3xLauncher. We are developing a Maven extension and want to make sure it works well with surefire/failsafe. This classloader leak means we have to use a forking launcher instead, which slows down our tests considerably. > Surefire leaks classloaders when using in-process strategy > -- > > Key: SUREFIRE-1655 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1655 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Stefan Oehme >Priority: Minor > > The test classloader is created [here| > [https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/InPluginVMSurefireStarter.java#L77]], > but never closed. As a result, the underlying JARs in that classloader > remain open and cannot be deleted. Also, their content can be stale when > opened using java.util.ZipFile. > This is a problem when running Maven integration tests using the > Embedded3xLauncher. We are developing a Maven extension and want to make sure > it works well with surefire/failsafe. This classloader leak means we have to > use a forking launcher instead, which slows down our tests considerably. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SUREFIRE-1655) Surefire leaks classloaders when using in-process strategy
Stefan Oehme created SUREFIRE-1655: -- Summary: Surefire leaks classloaders when using in-process strategy Key: SUREFIRE-1655 URL: https://issues.apache.org/jira/browse/SUREFIRE-1655 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin, Maven Surefire Plugin Reporter: Stefan Oehme The test classloader is created [here|[https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/InPluginVMSurefireStarter.java#L77]], but never closed. As a result, the underlying JARs in that classloader remain open and cannot be deleted. Also, their content can be stale when opened using java.util.ZipFile. This is a problem when running Maven integration tests using the Embedded3xLauncher. We are developing a Maven extension and want to make sure it works well with surefire/failsafe. This classloader leak means we have to use a forking launcher instead, which slows down our tests considerably. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6506) Mojos are unable to load package annotations on Java >= 9
[
https://issues.apache.org/jira/browse/MNG-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801537#comment-16801537
]
Roman Grigoriadi commented on MNG-6506:
---
Thanks for pointing out Andreas.
> Mojos are unable to load package annotations on Java >= 9
> -
>
> Key: MNG-6506
> URL: https://issues.apache.org/jira/browse/MNG-6506
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.6.0
>Reporter: Andreas Veithen
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: up-for-grabs
> Fix For: 3.6.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> On Java 9 and above, calls to {{java.lang.Package.getAnnotation(Class)}} from
> within a Mojo always return {{null}} (unless the {{package-info}} class has
> been loaded by some other means before).
> The reason appears to be an incompatibility between Java 9 and Plexus
> Classworlds:
> * Java 9 ultimately calls {{findClass}} (instead of {{loadClass}}) to get the
> {{package-info}} class.
> * The {{findClass}} implementation in {{ClassRealm}} always throws
> {{ClassNotFoundException}}:
> https://github.com/codehaus-plexus/plexus-classworlds/blob/master/src/main/java/org/codehaus/plexus/classworlds/realm/ClassRealm.java#L275.
> This in particular affects plugins that interact with the JAXB API because it
> relies on package annotations.
> A workaround is to preload the required {{package-info}} classes using
> {{loadClass}}; see e.g. http://svn.apache.org/viewvc?rev=1845026=rev.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Moved] (MNGSITE-364) Please improve
[
https://issues.apache.org/jira/browse/MNGSITE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov moved MNG-6617 to MNGSITE-364:
-
Component/s: (was: Documentation: Guides)
Key: MNGSITE-364 (was: MNG-6617)
Project: Maven Project Web Site (was: Maven)
> Please improve
> ---
>
> Key: MNGSITE-364
> URL: https://issues.apache.org/jira/browse/MNGSITE-364
> Project: Maven Project Web Site
> Issue Type: Improvement
>Reporter: Aaron Digulla
>Priority: Major
>
> Please improve the page at [https://maven.apache.org/maven-ci-friendly.html]
> I think the document explains an important feature but I find it confusing.
> * Why would someone want to use this feature? Which problems does it solve
> and which are created?
> * How will Maven determine the values for ${sha1} and ${changelist}?
> * You mention
> 1.0.0-${buildNumber}-SNAPSHOT"will _not work as expected_". Why not? Explain
> why the build number doesn't make as much sense as the other variables.
> * In the section "Dependencies" why not use {{dependencyManagement}}?
> * Under "Install / Deploy", you say "will not be consumable by Maven
> anymore". Why?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[
https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801493#comment-16801493
]
Aaron Digulla edited comment on MRESOURCES-171 at 3/26/19 9:03 AM:
---
My preferred solution is: The plugin uses ISO-8859-1 when reading and writing
.properties files by default and this encoding can be overridden with a config
option. So when people have found a way to work around the encoding in their
code (like creating their own {{Reader}}), they can configure the plugin to use
${project.build.sourceEncoding}.
was (Author: digulla):
My preferred solution is: The plugin uses ISO-8859-1 when reading and writing
.properties files by default and this encoding can be overridden with a config
option. So when people have found a way to work around the encoding in their
code (like creating their own {{Reader}}), they can configure the plugin to use
${{{project.build.sourceEncoding}}}.
> ISO8859-1 properties files get changed into UTF-8 when filtered
> ---
>
> Key: MRESOURCES-171
> URL: https://issues.apache.org/jira/browse/MRESOURCES-171
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: filtering
>Reporter: Alex Collins
>Priority: Minor
> Attachments: filtering-bug.zip
>
>
> Create:
> src/main/resources/test.properties
> And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u
> formatting.
> When adding this line:
> src/main/resourcestrue
> Expected:
> ISO8859-1 encoded file in jar.
> Actual:
> UTF-8 encoded file in jar.
> ---
> If there are any property files (which can only be ISO8859-1) they appear to
> be converted into UTF-8 in the jar.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[
https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801493#comment-16801493
]
Aaron Digulla commented on MRESOURCES-171:
--
My preferred solution is: The plugin uses ISO-8859-1 when reading and writing
.properties files by default and this encoding can be overridden with a config
option. So when people have found a way to work around the encoding in their
code (like creating their own {{Reader}}), they can configure the plugin to use
${{{project.build.sourceEncoding}}}.
> ISO8859-1 properties files get changed into UTF-8 when filtered
> ---
>
> Key: MRESOURCES-171
> URL: https://issues.apache.org/jira/browse/MRESOURCES-171
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: filtering
>Reporter: Alex Collins
>Priority: Minor
> Attachments: filtering-bug.zip
>
>
> Create:
> src/main/resources/test.properties
> And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u
> formatting.
> When adding this line:
> src/main/resourcestrue
> Expected:
> ISO8859-1 encoded file in jar.
> Actual:
> UTF-8 encoded file in jar.
> ---
> If there are any property files (which can only be ISO8859-1) they appear to
> be converted into UTF-8 in the jar.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MASSEMBLY-811) Document possible values for handlerName in containerDescriptorHandler plus their configuration
[ https://issues.apache.org/jira/browse/MASSEMBLY-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801485#comment-16801485 ] Aaron Digulla edited comment on MASSEMBLY-811 at 3/26/19 8:52 AM: -- Fixed with [https://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-container-descriptor-handlers.html] Please close the issue. was (Author: digulla): Seems to be fixed now with [https://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-container-descriptor-handlers.html] > Document possible values for handlerName in containerDescriptorHandler plus > their configuration > --- > > Key: MASSEMBLY-811 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-811 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: component descriptor >Affects Versions: 2.6 >Reporter: Aaron Digulla >Priority: Major > > There is no documentation that I could find on the official site > (https://maven.apache.org/plugins/maven-assembly-plugin/) which explains > which handlers exist and how to configure them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-811) Document possible values for handlerName in containerDescriptorHandler plus their configuration
[ https://issues.apache.org/jira/browse/MASSEMBLY-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801485#comment-16801485 ] Aaron Digulla commented on MASSEMBLY-811: - Seems to be fixed now with [https://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-container-descriptor-handlers.html] > Document possible values for handlerName in containerDescriptorHandler plus > their configuration > --- > > Key: MASSEMBLY-811 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-811 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: component descriptor >Affects Versions: 2.6 >Reporter: Aaron Digulla >Priority: Major > > There is no documentation that I could find on the official site > (https://maven.apache.org/plugins/maven-assembly-plugin/) which explains > which handlers exist and how to configure them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6617) Please improve
Aaron Digulla created MNG-6617:
--
Summary: Please improve
Key: MNG-6617
URL: https://issues.apache.org/jira/browse/MNG-6617
Project: Maven
Issue Type: Improvement
Components: Documentation: Guides
Reporter: Aaron Digulla
Please improve the page at [https://maven.apache.org/maven-ci-friendly.html]
I think the document explains an important feature but I find it confusing.
* Why would someone want to use this feature? Which problems does it solve and
which are created?
* How will Maven determine the values for ${sha1} and ${changelist}?
* You mention
1.0.0-${buildNumber}-SNAPSHOT"will _not work as expected_". Why not? Explain
why the build number doesn't make as much sense as the other variables.
* In the section "Dependencies" why not use {{dependencyManagement}}?
* Under "Install / Deploy", you say "will not be consumable by Maven anymore".
Why?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1654) Remove deprecated parameter 'forkMode' and use only 'forkCount'
[ https://issues.apache.org/jira/browse/SUREFIRE-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801474#comment-16801474 ] Dejan Stojadinović commented on SUREFIRE-1654: -- I started to work on this. > Remove deprecated parameter 'forkMode' and use only 'forkCount' > --- > > Key: SUREFIRE-1654 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1654 > Project: Maven Surefire > Issue Type: Dependency upgrade > Components: Maven Failsafe Plugin, Maven Surefire Plugin, process > forking >Reporter: Tibor Digana >Priority: Major > Fix For: 3.0.0-M6 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1494) Make Provider surefire-junit47 default provider and deprecate surefire-junit4 Provider
[ https://issues.apache.org/jira/browse/SUREFIRE-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801475#comment-16801475 ] Dejan Stojadinović commented on SUREFIRE-1494: -- I started to work on this. > Make Provider surefire-junit47 default provider and deprecate surefire-junit4 > Provider > -- > > Key: SUREFIRE-1494 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1494 > Project: Maven Surefire > Issue Type: New Feature >Reporter: Tibor Digana >Priority: Major > Fix For: 3.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MCHECKSTYLE-372) Missing cache file invalidation when suppressionsLocation file is modified
Robin Karlsson created MCHECKSTYLE-372: -- Summary: Missing cache file invalidation when suppressionsLocation file is modified Key: MCHECKSTYLE-372 URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-372 Project: Maven Checkstyle Plugin Issue Type: Bug Affects Versions: 3.0.0 Reporter: Robin Karlsson I came across some buggy behavior with suppressions file and the cache file. Steps to reproduce: 1. Have code with violations. 2. Run checkstyle:check. 3. Add a suppressions file (with suppressionsLocation) that suppress the violations. 4. Re-run checkstyle:check. Violations are suppressed as expected. 5. Modify suppressions file so that the violations are no longer suppressed. 6. Re-run checkstyle:check. No violations, even though they shouldn't be suppressed. Work-arounds: * Disable the use of cache file. * Include the suppressions file from the config file instead of with suppressionsLocation in the plugin config. Is this a known issue? Is this by design? For performance reasons you might not want to wipe the cache file when the suppression file is modified (but AFAICT that's what Checkstyle does when a suppressions file is included via the config). On the other hand, this bit me because I modified a regexp in the suppression file so that it accidentally no longer suppressed what it was supposed to suppress. Since I didn't get any violations I thought it still worked. But when the cache file got reset the violations came back. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
