[jira] [Commented] (MCOMPILER-481) JPMS Regression: cannot access (requires static module not include anymore)
[
https://issues.apache.org/jira/browse/MCOMPILER-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17679435#comment-17679435
]
Robert Scholte commented on MCOMPILER-481:
--
[~cstamas] what makes you think it is a plugin bug?
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-compiler-plugin/job/master/
is green. Tested succesfully locally with 3.8.7, but failed with
3.9.0-SNAPSHOT. Looks more like a Maven bug.
> JPMS Regression: cannot access (requires static module not include
> anymore)
> ---
>
> Key: MCOMPILER-481
> URL: https://issues.apache.org/jira/browse/MCOMPILER-481
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Blocker
> Fix For: 3.10.0
>
> Attachments: compiler-bug.tar.gz
>
>
> Version 3.8.1 is not affected.
> The problem lies in how the module-path is constructed by the
> maven-compiler-plugin – not sure what changes from 3.8.1 caused this.
> In 3.8.1:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> In 3.9.0:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> Running with 3.9.0 yields:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.9.0:testCompile
> (default-testCompile) on project compiler-bug-app: Compilation failure
> [ERROR]
> /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38]
> cannot access org.eclipse.jetty.util.ajax.JSON
> [ERROR] class file for org.eclipse.jetty.util.ajax.JSON not found {code}
> Class {{JSON}} is in {{{}jetty-
[jira] [Commented] (MSCRIPTING-11) Lifecycle
[ https://issues.apache.org/jira/browse/MSCRIPTING-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17681236#comment-17681236 ] Robert Scholte commented on MSCRIPTING-11: -- I don't understand this request? Of course the context can be filled with these things, but every new entity might come with possible security related issues (hence I blocked adding settings, because it gives easy access to credentials). What is the usecase? > Lifecycle > - > > Key: MSCRIPTING-11 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-11 > Project: Maven Scripting > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Hüseyin Kartal >Priority: Major > Labels: features, pull-request-available > > Make the current maven lifecycle phase available in the groovy script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSCRIPTING-11) Lifecycle
[
https://issues.apache.org/jira/browse/MSCRIPTING-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17681311#comment-17681311
]
Robert Scholte commented on MSCRIPTING-11:
--
I think in both cases the answer is execution-blocks
For 1: you want a script that looks like:
{code:java}
if ("compile".equals(phase)) { /* do this*/ } else if
("test-compile".equals(phase)) { /* do that*/ }
{code}
If that is the case, you'd better do this:
{code:xml}
org.apache.maven.plugins
maven-scripting-plugin
3.0.0
compile-script
compile
test-compile-script
test-compile
{code}
for 2: I would make a profile called "setup", and have a couple of execution
blocks using install:install-file
> Lifecycle
> -
>
> Key: MSCRIPTING-11
> URL: https://issues.apache.org/jira/browse/MSCRIPTING-11
> Project: Maven Scripting
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Hüseyin Kartal
>Priority: Major
> Labels: features, pull-request-available
>
> Make the current maven lifecycle phase available in the groovy script.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSCRIPTING-11) Lifecycle
[ https://issues.apache.org/jira/browse/MSCRIPTING-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17681770#comment-17681770 ] Robert Scholte commented on MSCRIPTING-11: -- Based on those extra requirements it makes more sense to me to write your own plugin or extension. I prefer not to turn the scripting-plugin into a swiss army knife. > Lifecycle > - > > Key: MSCRIPTING-11 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-11 > Project: Maven Scripting > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Hüseyin Kartal >Priority: Major > Labels: features, pull-request-available > > Make the current maven lifecycle phase available in the groovy script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MCOMPILER-489) User property for multiReleaseOutput
[ https://issues.apache.org/jira/browse/MCOMPILER-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MCOMPILER-489. Assignee: Robert Scholte Resolution: Won't Fix > User property for multiReleaseOutput > > > Key: MCOMPILER-489 > URL: https://issues.apache.org/jira/browse/MCOMPILER-489 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: John Patrick >Assignee: Robert Scholte >Priority: Minor > Labels: CompilerOptions > > Add support so multiReleaseOutput can be provided as a user property. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSITE-764) Introduce 'update' goal
[ https://issues.apache.org/jira/browse/MSITE-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17683139#comment-17683139 ] Robert Scholte commented on MSITE-764: -- Could be, but let's document it as it is not that straightforward. And you should probably need to verify it as well. > Introduce 'update' goal > --- > > Key: MSITE-764 > URL: https://issues.apache.org/jira/browse/MSITE-764 > Project: Maven Site Plugin > Issue Type: New Feature >Reporter: Robert Scholte >Priority: Minor > Fix For: backlog, wontfix-candidate > > > Quite often site documentation is published as part of the release. This > means that changes to the documentation depend on a new release before being > visible OR you must accept that the documentation refers to a snapshot > version instead of the latest release version. > With the update-goal it will be possible to immediately publish > documentation changes without changes references to released project. > The siteskinner-maven-plugin > [http://www.mojohaus.org/siteskinner-maven-plugin/] (originally written by > me) at MojoHaus contains a lot of code which can form the base for this goal. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSITE-764) Introduce 'update' goal
[ https://issues.apache.org/jira/browse/MSITE-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17683833#comment-17683833 ] Robert Scholte commented on MSITE-764: -- Right > Introduce 'update' goal > --- > > Key: MSITE-764 > URL: https://issues.apache.org/jira/browse/MSITE-764 > Project: Maven Site Plugin > Issue Type: New Feature >Reporter: Robert Scholte >Priority: Minor > Fix For: backlog, wontfix-candidate > > > Quite often site documentation is published as part of the release. This > means that changes to the documentation depend on a new release before being > visible OR you must accept that the documentation refers to a snapshot > version instead of the latest release version. > With the update-goal it will be possible to immediately publish > documentation changes without changes references to released project. > The siteskinner-maven-plugin > [http://www.mojohaus.org/siteskinner-maven-plugin/] (originally written by > me) at MojoHaus contains a lot of code which can form the base for this goal. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-446) Compiler is crashing while setting JPMS module version
[
https://issues.apache.org/jira/browse/MCOMPILER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737288#comment-17737288
]
Robert Scholte commented on MCOMPILER-446:
--
I think this issue should have been closed. There's already a mechanism that
automatically sets the module-version based on the project version. IMO this
should always be in sync to prevent any confusion.
> Compiler is crashing while setting JPMS module version
> --
>
> Key: MCOMPILER-446
> URL: https://issues.apache.org/jira/browse/MCOMPILER-446
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Bruno Medeiros
>Priority: Major
>
> I have upgraded maven compiler plugin to 3.8.1 and I started getting this
> error:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project common: Fatal error compiling: error: bad value
> for --module-version option: 'local-SNAPSHOT' -> [Help 1]{code}
> Because we set versions in pom to local-SNAPHOT (and use maven-version-plugin
> when we actually realease to set a proper version), all our builds are
> failing locally.
> It seems javac does not like versions that do not have just alpha characters,
> like ours local-SNAPHOT.
> I thought about a few ways to fix that:
> * Allow the use of --module-version to be optional through config
> * Allow the version itself to be configurable
> * Validate if the version is a valid version for --module-version and not
> set it in case it is not
> Let me know what you guys think, I can try to provide a PR with the given
> solution.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MCOMPILER-446) Compiler is crashing while setting JPMS module version
[
https://issues.apache.org/jira/browse/MCOMPILER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-446.
Assignee: Robert Scholte
Resolution: Resolved
> Compiler is crashing while setting JPMS module version
> --
>
> Key: MCOMPILER-446
> URL: https://issues.apache.org/jira/browse/MCOMPILER-446
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Bruno Medeiros
>Assignee: Robert Scholte
>Priority: Major
>
> I have upgraded maven compiler plugin to 3.8.1 and I started getting this
> error:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project common: Fatal error compiling: error: bad value
> for --module-version option: 'local-SNAPSHOT' -> [Help 1]{code}
> Because we set versions in pom to local-SNAPHOT (and use maven-version-plugin
> when we actually realease to set a proper version), all our builds are
> failing locally.
> It seems javac does not like versions that do not have just alpha characters,
> like ours local-SNAPHOT.
> I thought about a few ways to fix that:
> * Allow the use of --module-version to be optional through config
> * Allow the version itself to be configurable
> * Validate if the version is a valid version for --module-version and not
> set it in case it is not
> Let me know what you guys think, I can try to provide a PR with the given
> solution.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7832) revert artifact handlers move to plugins
[ https://issues.apache.org/jira/browse/MNG-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739656#comment-17739656 ] Robert Scholte commented on MNG-7832: - IIRC the reason behind the moving the artifact handler as well are custom artifacts. A small anecdote regarding custom artifact handlers: TIBCO also has the concept of applications and libraries, but they call it differently and it is XML. One of the standard Maven plugins goals (something like dependency:tree or dependency:unpack) didn't work, because Maven couldn't find the right artifact handler, because Maven was treating embedded handlers different from custom handlers. In my opinion there should be no difference between embedded and custom artifact handlers. To enforce that, I prefer to have this kind of logic in the packaging-plugin OR a better mechanism that custom artifact handlers are treated the same. > revert artifact handlers move to plugins > > > Key: MNG-7832 > URL: https://issues.apache.org/jira/browse/MNG-7832 > Project: Maven > Issue Type: Sub-task > Components: Dependencies, Plugins and Lifecycle >Reporter: Herve Boutemy >Priority: Major > > MNG-5697 proposed to move at the same time packaging mapping AND artifact > handlers to packaging-oriented plugins > packaging mapping is feasible, and can make sense: user configures a > packaging plugin in his pom.xml to benefit from the full associated build > lifecycle, why not > but attifact handler is completely another beast: it's about consuming an > artifact as a dependency, then not lead at all by the packaging of the > project consuming the artifact > we need to split the 2 aspects: > 1. finish lifecycle mapping definition to plugins, and remove at the end the > definition from core, while learning users how to not any more benefit from > implicit core definition > 2. revert artifact handlers copy to packaging plugins, because they create > confusion: artifacts will never be consumed with an artifact handler defined > by an associated packaging plugin > once someone finds something reasonable about artifact handlers, we can > implement it later -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7844) Support for DTD entities and XInclude in the code at build time
[ https://issues.apache.org/jira/browse/MNG-7844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744319#comment-17744319 ] Robert Scholte commented on MNG-7844: - Just a couple of my personnal opinions: the fact that XML can have an include mechanism doesn't mean Maven should support it. It will be a target for vulnerability injection. What's the _important_ usecase that requires this? I assume it is more about mixins, which I believe should be done based on GAV: it is just another way of handling a parent pom. > Support for DTD entities and XInclude in the code at build time > --- > > Key: MNG-7844 > URL: https://issues.apache.org/jira/browse/MNG-7844 > Project: Maven > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.x-candidate > > > The idea is to open a bit more the POM XML to composition. > The prerequisite is that the _original_ pom is not installed / uploaded > anymore and needs to be processed and trimmed, so that the consumer pom is > installed/uploaded. The consumer pom mechanism would have to be slightly > changed to make sure DTD entities and xinclude are fully processed and merged > in. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MWRAPPER-137) Can't match distributionUrl when using MINGW64
Robert Scholte created MWRAPPER-137:
---
Summary: Can't match distributionUrl when using MINGW64
Key: MWRAPPER-137
URL: https://issues.apache.org/jira/browse/MWRAPPER-137
Project: Maven Wrapper
Issue Type: Bug
Components: Maven Wrapper Scripts
Affects Versions: 3.3.1
Reporter: Robert Scholte
Any mvnw command fails with the following message:
{noformat}
$ ./mvnw verify
'istributionUrl is not valid, must match *-bin.zip or maven-mvnd-*.zip, but
found
'https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/4.0.0-alpha-13/apache-maven-4.0.0-alpha-13-bin.zip
{noformat}
Also notice that the {{d}} from distributionUrl has been replaced with a single
quote.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-27) turn artifacts into Java 9 modules
[ https://issues.apache.org/jira/browse/MRESOLVER-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856440#comment-17856440 ] Robert Scholte commented on MRESOLVER-27: - Let's start by providing module descriptors for the modules that don't have dependecies or don't rely on third party dependencies. So that's maven-resolver-api, maven-resolver-spi and maven-resolver-util. I'll prepare a MR. > turn artifacts into Java 9 modules > -- > > Key: MRESOLVER-27 > URL: https://issues.apache.org/jira/browse/MRESOLVER-27 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Affects Versions: Maven Artifact Resolver 1.1.0 >Reporter: Herve Boutemy >Priority: Minor > > Java 9 with Jigsaw modules is coming > Maven Artifact Resolver: > # has a chance to be turned into Java 9 modules > # could be useful as Java 9 modules > Automatic Modules Names in MRESOLVER-26 is a quickstart, but turning > artifacts into real Java 9 modules would be more powerful, even if it > requires more work -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-573) CollectionConfiguration should ignore module-info.java
Robert Scholte created MRESOLVER-573: Summary: CollectionConfiguration should ignore module-info.java Key: MRESOLVER-573 URL: https://issues.apache.org/jira/browse/MRESOLVER-573 Project: Maven Resolver Issue Type: Improvement Reporter: Robert Scholte This is in preparation of MRESOLVER-27 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-573) CollectionConfiguration should ignore module-info.java
[ https://issues.apache.org/jira/browse/MRESOLVER-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRESOLVER-573. Resolution: Fixed > CollectionConfiguration should ignore module-info.java > -- > > Key: MRESOLVER-573 > URL: https://issues.apache.org/jira/browse/MRESOLVER-573 > Project: Maven Resolver > Issue Type: Improvement >Reporter: Robert Scholte >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > > This is in preparation of MRESOLVER-27 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8163) MavenSessionBuilderSupplier depends on Resolver internal code
Robert Scholte created MNG-8163: --- Summary: MavenSessionBuilderSupplier depends on Resolver internal code Key: MNG-8163 URL: https://issues.apache.org/jira/browse/MNG-8163 Project: Maven Issue Type: Improvement Reporter: Robert Scholte Assignee: Tamas Cservenak See current most recent tag: https://github.com/apache/maven/blob/maven-4.0.0-beta-3/maven-api-impl/src/main/java/org/apache/maven/internal/impl/resolver/MavenSessionBuilderSupplier.java#L37-L42 Once MRESOLVER-27 is in place I expect that these internal packages are not accessible anymore (for those using the modulepath). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8163) MavenSessionBuilderSupplier depends on Resolver internal code
[ https://issues.apache.org/jira/browse/MNG-8163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856724#comment-17856724 ] Robert Scholte commented on MNG-8163: - Tools like IDEs, CI-servers and maybe even other tools need to have a consistent way of resolving dependencies (I'd prefer to call it m2 style, to make a clear difference with the Maven buildtool) and they might be using the modulepath. One way to solve this, is to export these packages only to the maven-api-impl module. > MavenSessionBuilderSupplier depends on Resolver internal code > - > > Key: MNG-8163 > URL: https://issues.apache.org/jira/browse/MNG-8163 > Project: Maven > Issue Type: Improvement >Reporter: Robert Scholte >Assignee: Tamas Cservenak >Priority: Major > > See current most recent tag: > https://github.com/apache/maven/blob/maven-4.0.0-beta-3/maven-api-impl/src/main/java/org/apache/maven/internal/impl/resolver/MavenSessionBuilderSupplier.java#L37-L42 > Once MRESOLVER-27 is in place I expect that these internal packages are not > accessible anymore (for those using the modulepath). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-27) turn artifacts into Java 9 modules
[ https://issues.apache.org/jira/browse/MRESOLVER-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MRESOLVER-27: Description: Java 9 with Jigsaw modules is coming Maven Artifact Resolver: # has a chance to be turned into Java 9 modules # could be useful as Java 9 modules Automatic Modules Names in MRESOLVER-26 is a quickstart, but turning artifacts into real Java 9 modules would be more powerful, even if it requires more work NOTE: partly done for api, spi and utils in https://github.com/apache/maven-resolver/commit/8266e6c320a7cf4deed3deb253ff4fd506d1d8f2 was: Java 9 with Jigsaw modules is coming Maven Artifact Resolver: # has a chance to be turned into Java 9 modules # could be useful as Java 9 modules Automatic Modules Names in MRESOLVER-26 is a quickstart, but turning artifacts into real Java 9 modules would be more powerful, even if it requires more work > turn artifacts into Java 9 modules > -- > > Key: MRESOLVER-27 > URL: https://issues.apache.org/jira/browse/MRESOLVER-27 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Affects Versions: Maven Artifact Resolver 1.1.0 >Reporter: Herve Boutemy >Priority: Minor > > Java 9 with Jigsaw modules is coming > Maven Artifact Resolver: > # has a chance to be turned into Java 9 modules > # could be useful as Java 9 modules > Automatic Modules Names in MRESOLVER-26 is a quickstart, but turning > artifacts into real Java 9 modules would be more powerful, even if it > requires more work > NOTE: partly done for api, spi and utils in > https://github.com/apache/maven-resolver/commit/8266e6c320a7cf4deed3deb253ff4fd506d1d8f2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8223) DefaultTransformerContextBuilder fails incorrectly with No Unique Source
Robert Scholte created MNG-8223: --- Summary: DefaultTransformerContextBuilder fails incorrectly with No Unique Source Key: MNG-8223 URL: https://issues.apache.org/jira/browse/MNG-8223 Project: Maven Issue Type: Improvement Affects Versions: 4.0.0-beta-3 Reporter: Robert Scholte suppose the following structure: * multimodule-thirdparty * multimodule-private * multimodule-all private and thirdparty are 2 different repos. For my private project I need some changes in thirdparty as well. I want to build both using multimodule-all, with is a simple aggregator pom referring to 2 modules: ../multimodule-thirdparty and ../multimodule-private With Maven3 this works fine, but Maven4 complains about 2 paths not being identical: /absolute/path/to/multimodule-all/../multimodule-thirdparty/pom.xml is not /absolute/path/to/multimodule-thirdparty/pom.xml Somewhere down the road the path to the pom should be normalized, so they are the same again. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8218) Non-normalized paths are compared which fails when using relativePath
[
https://issues.apache.org/jira/browse/MNG-8218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877020#comment-17877020
]
Robert Scholte commented on MNG-8218:
-
It happened for me on quite a big project, so need to figure out what really
triggered the bug.
> Non-normalized paths are compared which fails when using relativePath
> -
>
> Key: MNG-8218
> URL: https://issues.apache.org/jira/browse/MNG-8218
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-beta-3
>Reporter: Delany
>Priority: Major
>
> Given a project structure of
> > parent/pom.xml
> > parent/common/pom.xml
> > parent/common_biometriccommon/pom.xml
> Where the common module pom references submodules like so
> {code:java}
>
> ../common_biometriccommon {code}
> And the biometriccommon child module references its parent
> {code:java}
> ../common/pom.xml
> {code}
> The build is successful with 3.9.9 but fails in Maven 4 with an Internal
> error: java.lang.IllegalStateException: No unique Source for ...
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MENFORCER-509) ReactorModuleConvergence should support better recognize multimodule roots
Robert Scholte created MENFORCER-509:
Summary: ReactorModuleConvergence should support better recognize
multimodule roots
Key: MENFORCER-509
URL: https://issues.apache.org/jira/browse/MENFORCER-509
Project: Maven Enforcer Plugin
Issue Type: Improvement
Components: reactorModuleConvergence
Reporter: Robert Scholte
Attachments: reactormoduleconvergence.zip
In case there's an aggregator outside of a multimodule project to trigger one
or more multimodules, this rule fails.
In the code is a valid question: // After we are sure having consistent version
we can simply use the first one?
Most of the time the answer is yes, but not always.
Attached is an example.
Running {{mvn validate}} from base-project succeeds, but not from
{{extended-project}}
Also notice that base-project is executed before extended-project, however it
doesn't seem to be the first of the sorted projects?!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MENFORCER-509) ReactorModuleConvergence should better recognize multimodule roots
[
https://issues.apache.org/jira/browse/MENFORCER-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MENFORCER-509:
-
Summary: ReactorModuleConvergence should better recognize multimodule roots
(was: ReactorModuleConvergence should support better recognize multimodule
roots)
> ReactorModuleConvergence should better recognize multimodule roots
> --
>
> Key: MENFORCER-509
> URL: https://issues.apache.org/jira/browse/MENFORCER-509
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: reactorModuleConvergence
>Reporter: Robert Scholte
>Priority: Major
> Attachments: reactormoduleconvergence.zip
>
>
> In case there's an aggregator outside of a multimodule project to trigger one
> or more multimodules, this rule fails.
> In the code is a valid question: // After we are sure having consistent
> version we can simply use the first one?
> Most of the time the answer is yes, but not always.
> Attached is an example.
> Running {{mvn validate}} from base-project succeeds, but not from
> {{extended-project}}
> Also notice that base-project is executed before extended-project, however it
> doesn't seem to be the first of the sorted projects?!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-446) Compiler is crashing while setting JPMS module version
[
https://issues.apache.org/jira/browse/MCOMPILER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755195#comment-17755195
]
Robert Scholte commented on MCOMPILER-446:
--
Right, unless somebody creates a backport patch for Java 17. See for example
https://bugs.openjdk.org/browse/JDK-8240169 that backports can be done.
> Compiler is crashing while setting JPMS module version
> --
>
> Key: MCOMPILER-446
> URL: https://issues.apache.org/jira/browse/MCOMPILER-446
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Bruno Medeiros
>Assignee: Robert Scholte
>Priority: Major
>
> I have upgraded maven compiler plugin to 3.8.1 and I started getting this
> error:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project common: Fatal error compiling: error: bad value
> for --module-version option: 'local-SNAPSHOT' -> [Help 1]{code}
> Because we set versions in pom to local-SNAPHOT (and use maven-version-plugin
> when we actually realease to set a proper version), all our builds are
> failing locally.
> It seems javac does not like versions that do not have just alpha characters,
> like ours local-SNAPHOT.
> I thought about a few ways to fix that:
> * Allow the use of --module-version to be optional through config
> * Allow the version itself to be configurable
> * Validate if the version is a valid version for --module-version and not
> set it in case it is not
> Let me know what you guys think, I can try to provide a PR with the given
> solution.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-682) Reactor builds fail when multiple modules with same groupId:artifactId
[
https://issues.apache.org/jira/browse/MJAVADOC-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766074#comment-17766074
]
Robert Scholte commented on MJAVADOC-682:
-
The JavadocModule uses GA as key, seems like you want GAV here:
https://github.com/apache/maven-javadoc-plugin/blob/master/src/main/java/org/apache/maven/plugins/javadoc/JavadocModule.java#L34
> Reactor builds fail when multiple modules with same groupId:artifactId
> --
>
> Key: MJAVADOC-682
> URL: https://issues.apache.org/jira/browse/MJAVADOC-682
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0, 3.1.1, 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1,
> 3.5.0, 3.6.0
> Environment: Debian Linux versions 10.10 through 12.1
> OpenJDK 64-bit versions 11.0.11 through 17.0.8
> Maven versions 3.8.1 through 3.9.4
>Reporter: AO Industries, Inc.
>Priority: Major
> Labels: jpms
>
> In versions 3.1.0 through 3.6.0, when a reactor build has multiple projects
> with the same groupId and artifactId, even when different versions, the
> javadoc fails with:
> Exit code: 1 - error: module not found: com.aoindustries.example
> Plugin 3.0.1 works.
> We have created a minimal example project that demonstrates this bug:
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name]
>
> — Copy from demo project README.md —
> h2. To Reproduce:
> # Clone this project: {{git clone
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]}}
> # Change to project directory: {{cd
> maven-javadoc-plugin-failing-multiple-projects-same-name}}
> # Perform build to see error in {{jar}} goal: {{mvn verify}}
> # Also fails with {{javadoc}} goal: {{mvn clean compile javadoc:javadoc}}
> h2. Notes:
> * Can build individual modules directly, such as {{(cd module-1 && mvn
> verify)}}
> * Reverting to maven-javadoc-plugin version 3.0.1 makes it work
> * Changing the groupId or artifactId in either module-1 or module-2 makes it
> work.
> * Changing module names, package names, or class names in modules has no
> effect.
> * We believe this to be distinct from [Issue
> #673|https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-673]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-1563) NoClassDefFoundError for JPMS modules with "require static"
[
https://issues.apache.org/jira/browse/SUREFIRE-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17772809#comment-17772809
]
Robert Scholte commented on SUREFIRE-1563:
--
Not sure what the status is, and what you expect here:
{{}}
{{ --add-modules=org.slf4j}}
{{}}
This works, not sure if it is enough
The rational: By default all static required modules are not added to the
runtime, as they are optional. The developer needs to decide how to execute
these tests: without these or with one or more optional(static) modules.
> NoClassDefFoundError for JPMS modules with "require static"
> ---
>
> Key: SUREFIRE-1563
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1563
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Major
> Attachments: maven-jpms.tgz
>
>
> When a Maven module has a {{module-info.java}} that contains a {{requires
> static}}, Surefire throws {{NoClassDefFoundError}} when running the tests for
> that Maven module.
> If the dependency is declared only as {{required}} (no {{static}}), then the
> tests run fine.
> Attached a reproducible project.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSCRIPTING-10) Page Not Found on majority of Maven Scripting Plugin pages
[ https://issues.apache.org/jira/browse/MSCRIPTING-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MSCRIPTING-10: - Description: On page https://maven.apache.org/plugins/maven-scripting-plugin/index.html there is "Page Not Found" response for following links: [https://maven.apache.org/plugins/maven-scripting-plugin/usage.html] [https://maven.apache.org/plugins/maven-scripting-plugin/faq.html] [https://maven.apache.org/plugins/maven-scripting-plugin/mail-lists.html] [https://maven.apache.org/plugins/maven-scripting-plugin/mail-lists.html] [https://maven.apache.org/plugins/maven-scripting-plugin/issue-tracking.html] [https://maven.apache.org/plugins/maven-scripting-plugin/source-repository.html] was: On page https://maven.apache.org/plugins/maven-scripting-plugin/index.html there is "Page Not Found" response for following links: [https://maven.apache.org/plugins/maven-scripting-plugin/usage.html] [https://maven.apache.org/plugins/maven-scripting-plugin/faq.html] [https://maven.apache.org/plugins/maven-scripting-plugin/mail-lists.html] [https://maven.apache.org/plugins/maven-scripting-plugin/mail-lists.html] [https://maven.apache.org/plugins/maven-scripting-plugin/issue-tracking.html] > Page Not Found on majority of Maven Scripting Plugin pages > -- > > Key: MSCRIPTING-10 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-10 > Project: Maven Scripting > Issue Type: Bug > Environment: Web >Reporter: Milan Kubec >Priority: Major > > On page https://maven.apache.org/plugins/maven-scripting-plugin/index.html > there is "Page Not Found" response for following links: > [https://maven.apache.org/plugins/maven-scripting-plugin/usage.html] > [https://maven.apache.org/plugins/maven-scripting-plugin/faq.html] > [https://maven.apache.org/plugins/maven-scripting-plugin/mail-lists.html] > [https://maven.apache.org/plugins/maven-scripting-plugin/mail-lists.html] > [https://maven.apache.org/plugins/maven-scripting-plugin/issue-tracking.html] > [https://maven.apache.org/plugins/maven-scripting-plugin/source-repository.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSCRIPTING-11) Lifecycle
[ https://issues.apache.org/jira/browse/MSCRIPTING-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MSCRIPTING-11. Assignee: Robert Scholte Resolution: Won't Fix The original question to expose the lifecycle or phase will not be supported. By using execution-blocks you already control the phase in which is it executed. > Lifecycle > - > > Key: MSCRIPTING-11 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-11 > Project: Maven Scripting > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Hüseyin Kartal >Assignee: Robert Scholte >Priority: Major > Labels: features, pull-request-available > > Make the current maven lifecycle phase available in the groovy script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MJLINK-80) Support additional resources
Robert Scholte created MJLINK-80: Summary: Support additional resources Key: MJLINK-80 URL: https://issues.apache.org/jira/browse/MJLINK-80 Project: Maven JLink Plugin Issue Type: New Feature Affects Versions: 3.2.0 Reporter: Robert Scholte This plugin does 2 steps into 1: # run the jlink-command to create the image files into an empty directory # bundle the content into a jar. You cannot prepare resources into the jlink output directory, because jlink will fail. So this plugin must be extended to support additional resoures. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MJLINK-80) Support additional resources
[ https://issues.apache.org/jira/browse/MJLINK-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MJLINK-80. Fix Version/s: 3.3.0 Assignee: Robert Scholte Resolution: Fixed Fixed with https://github.com/apache/maven-jlink-plugin/commit/a6e3a10dcfbf7b936748fd3e21e3dc54972f2a15 > Support additional resources > > > Key: MJLINK-80 > URL: https://issues.apache.org/jira/browse/MJLINK-80 > Project: Maven JLink Plugin > Issue Type: New Feature >Affects Versions: 3.2.0 >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > Fix For: 3.3.0 > > > This plugin does 2 steps into 1: > # run the jlink-command to create the image files into an empty directory > # bundle the content into a jar. > You cannot prepare resources into the jlink output directory, because jlink > will fail. > So this plugin must be extended to support additional resoures. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MEAR-322) Module repackaged as invalid archive
[
https://issues.apache.org/jira/browse/MEAR-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622799#comment-17622799
]
Robert Scholte commented on MEAR-322:
-
Everybody can report a bug, but due to a huge amount of spam, they are first
validated before being moved to a JDK- issue. People that have proven their
value sometimes get direct access, I'm one of the few.
The easiest way is to say what you want to be added, I'll copy/paste when I
agree.
I'm not going to ask for backports if it is already fixed in a newer version.
So if this is a JDK11 issue, better to provide a backport patch on that branch.
> Module repackaged as invalid archive
>
>
> Key: MEAR-322
> URL: https://issues.apache.org/jira/browse/MEAR-322
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Piotr Zygielo
>Priority: Major
> Fix For: more-investigation
>
>
> After m-ear-p upgrade from 3.2.0 to 3.3.0, ear produced by plugin contains
> invalid entry. That causes jar tool to error with
> {quote}java.util.zip.ZipException: only DEFLATED entries can have EXT
> descriptor
> at java.base/java.util.zip.ZipInputStream.readLOC(ZipInputStream.java:313)
> at
> java.base/java.util.zip.ZipInputStream.getNextEntry(ZipInputStream.java:125)
> at jdk.jartool/sun.tools.jar.Main.extract(Main.java:1360)
> at jdk.jartool/sun.tools.jar.Main.run(Main.java:409)
> at jdk.jartool/sun.tools.jar.Main.main(Main.java:1680)
> {quote}
> Seems to be connected to setting {{archive/compress=false}} in the original
> jar project (original project - valid at its origin, becomes invalid part of
> ear).
> This happens for original project with {{packaging=clojure}} in my case.
> 07a84983809b4ec416b1330412bbd83844a88a44 is the first bad commit
>
>
> Reproducer: [https://github.com/pzrep/MEAR-322]
> and its failure: [https://github.com/pzrep/MEAR-322/actions/runs/3306348660]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7595) [REGRESSION] $pom.-expressions in remote pom cause warnings
Robert Scholte created MNG-7595:
---
Summary: [REGRESSION] $pom.-expressions in remote pom cause
warnings
Key: MNG-7595
URL: https://issues.apache.org/jira/browse/MNG-7595
Project: Maven
Issue Type: Bug
Affects Versions: 4.0.0-alpha-2
Reporter: Robert Scholte
When depending on
[wagon-http-1.0-beta-6|https://repo1.maven.org/maven2/org/apache/maven/wagon/wagon-http/1.0-beta-6/wagon-http-1.0-beta-6.pom]
you'll get a warning like:
{noformat}
[WARNING] The POM for org.apache.maven.wagon:wagon-http:jar:1.0-beta-6 is
invalid, transitive dependencies (if any) will not be available: 1 problem was
encountered while building the effective model for
C:\Users\rober\.m2\repository\org\apache\maven\wagon\wagon-http\1.0-beta-6\wagon-http-1.0-beta-6.pom
[ERROR] 'dependencies.dependency.groupId' for
${pom.groupId}:wagon-http-shared:jar with value '${pom.groupId}' does not match
a valid coordinate id pattern. @ org.apache.maven.wagon:wagon-http:1.0-beta-6
{noformat}
Even though this is an old artifact, IMO we should not have such a warning for
remote poms, as they cannot be changed. So the question is: do we need to
reconsider the decision to only allow $project.-expressions for the build-pom?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7595) [REGRESSION] $pom.-expressions in remote pom cause warnings
[
https://issues.apache.org/jira/browse/MNG-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17631284#comment-17631284
]
Robert Scholte commented on MNG-7595:
-
The issue here is that it exists in Central, which is immutable. Fixing it
there would require resigning it. The pom reader should only be strict for
local poms, not for remote poms.
Now that we've identified this issue, I see more things that should be done:
- have a filter that resolves properties in dependencies (maybe even more) for
non pom-packaging pomfiles (I see a pattern where properties are used to
overwrite values in a parent, such as the dependency version)
- same needs to be done when there will be a pdt-file.
> [REGRESSION] $pom.-expressions in remote pom cause warnings
> ---
>
> Key: MNG-7595
> URL: https://issues.apache.org/jira/browse/MNG-7595
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-2
>Reporter: Robert Scholte
>Priority: Major
>
> When depending on
> [wagon-http-1.0-beta-6|https://repo1.maven.org/maven2/org/apache/maven/wagon/wagon-http/1.0-beta-6/wagon-http-1.0-beta-6.pom]
> you'll get a warning like:
> {noformat}
> [WARNING] The POM for org.apache.maven.wagon:wagon-http:jar:1.0-beta-6 is
> invalid, transitive dependencies (if any) will not be available: 1 problem
> was encountered while building the effective model for
> C:\Users\rober\.m2\repository\org\apache\maven\wagon\wagon-http\1.0-beta-6\wagon-http-1.0-beta-6.pom
> [ERROR] 'dependencies.dependency.groupId' for
> ${pom.groupId}:wagon-http-shared:jar with value '${pom.groupId}' does not
> match a valid coordinate id pattern. @
> org.apache.maven.wagon:wagon-http:1.0-beta-6
> {noformat}
> Even though this is an old artifact, IMO we should not have such a warning
> for remote poms, as they cannot be changed. So the question is: do we need to
> reconsider the decision to only allow $project.-expressions for the build-pom?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-6211) Improve relocation message
Robert Scholte created MNG-6211:
---
Summary: Improve relocation message
Key: MNG-6211
URL: https://issues.apache.org/jira/browse/MNG-6211
Project: Maven
Issue Type: Improvement
Components: Dependencies
Reporter: Robert Scholte
Consider the following setup:
{noformat}
A:1.0 -> B:1.1
C:1.1 -> B:1.0
B:1.4 >>> D:1.4
My -> A:1.0, B:1.3, C:1.1
{noformat}
When upgrading My B to 1.4, I'll get a warning about the relocation. But when I
replace B:1.4 with D:1.4, B:1.1 will be pulled in because it is a transitive
dependency of A and because D is not aware being the relocation of B.
In this case the relocation should be INFO, because following the instruction
will have an unpleasant surprise.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MNG-6212) Attach relocation files
Robert Scholte created MNG-6212: --- Summary: Attach relocation files Key: MNG-6212 URL: https://issues.apache.org/jira/browse/MNG-6212 Project: Maven Issue Type: Improvement Reporter: Robert Scholte Maven should attach the relocation-files to the MavenProject, so the maven-install-plugin and maven-deploy-plugin can publish these files together with the targeted artifact. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MWAR-405) Workaround XStream incompatibility with Java9
[
https://issues.apache.org/jira/browse/MWAR-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MWAR-405:
---
Assignee: Robert Scholte
> Workaround XStream incompatibility with Java9
> -
>
> Key: MWAR-405
> URL: https://issues.apache.org/jira/browse/MWAR-405
> Project: Maven WAR Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Enrico Olivelli
>Assignee: Robert Scholte
>Priority: Blocker
>
> The problem is that XStreams tries to access "comparator" field of
> java.util.TreeMap and this is forbidden in Java9
> {code}
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> field private final java.util.Comparator java.util.TreeMap.comparator
> accessible: module java.base does not "opens java.util" to unnamed module
> Happens while initializing
> org.apache.maven.plugins.war.util.WebappStructureSerializer
> {code}
> A possibile workaround is to change the initialization of XStreams in a way
> that only useful converters are registers, thus bypassing the problem
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MWAR-405) Workaround XStream incompatibility with Java9
[
https://issues.apache.org/jira/browse/MWAR-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15966301#comment-15966301
]
Robert Scholte commented on MWAR-405:
-
I actually like this solution and should be easy to apply. We can predict quite
well which converters we need.
> Workaround XStream incompatibility with Java9
> -
>
> Key: MWAR-405
> URL: https://issues.apache.org/jira/browse/MWAR-405
> Project: Maven WAR Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Enrico Olivelli
>Assignee: Robert Scholte
>Priority: Blocker
>
> The problem is that XStreams tries to access "comparator" field of
> java.util.TreeMap and this is forbidden in Java9
> {code}
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> field private final java.util.Comparator java.util.TreeMap.comparator
> accessible: module java.base does not "opens java.util" to unnamed module
> Happens while initializing
> org.apache.maven.plugins.war.util.WebappStructureSerializer
> {code}
> A possibile workaround is to change the initialization of XStreams in a way
> that only useful converters are registers, thus bypassing the problem
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-6020) Maven fails to detect pom.xml XML syntax error
[
https://issues.apache.org/jira/browse/MNG-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MNG-6020:
---
Assignee: Robert Scholte
> Maven fails to detect pom.xml XML syntax error
> --
>
> Key: MNG-6020
> URL: https://issues.apache.org/jira/browse/MNG-6020
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.5
> Environment: Mac OS X
>Reporter: Archie Cobbs
>Assignee: Robert Scholte
>Priority: Minor
>
> I had a typo in my POM: there was an extra trailing {{}} tag in the
> XML. This made the POM not be valid XML.
> Maven did not detect this error. While that may seem like a feature, it's
> really a bug, in particular because Maven will also happily deploy this
> invalid XML file.
> It led to this interesting situation which had us scratching our heads for a
> while; see https://issues.sonatype.org/browse/OSSRH-22411 for details.
> Recommendation: maven should throw an error if {{pom.xml}} is not valid XML.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MNG-6020) Maven fails to detect pom.xml XML syntax error
[
https://issues.apache.org/jira/browse/MNG-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-6020.
---
Resolution: Fixed
Fix Version/s: 3.5.0
Fixed while upgrading Modello for Maven 3.5.0
> Maven fails to detect pom.xml XML syntax error
> --
>
> Key: MNG-6020
> URL: https://issues.apache.org/jira/browse/MNG-6020
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.5
> Environment: Mac OS X
>Reporter: Archie Cobbs
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.5.0
>
>
> I had a typo in my POM: there was an extra trailing {{}} tag in the
> XML. This made the POM not be valid XML.
> Maven did not detect this error. While that may seem like a feature, it's
> really a bug, in particular because Maven will also happily deploy this
> invalid XML file.
> It led to this interesting situation which had us scratching our heads for a
> while; see https://issues.sonatype.org/browse/OSSRH-22411 for details.
> Recommendation: maven should throw an error if {{pom.xml}} is not valid XML.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6216) IndexArrayOutOfBounds when parsing POM
[
https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15966374#comment-15966374
]
Robert Scholte commented on MNG-6216:
-
By accident I hit this issue today. There are probably 2 issues in play, I was
able to partly reproduce it.
The root cause is upgrade of the Modello Plugin, which contained a
[fix|https://github.com/codehaus-plexus/modello/issues/5] regarding invalid
XML.
What happened in my case is that one of the parents contained its content
twice, i.e.
{code:xml}
...
...
{code}
The weird thing is that the file was correct in the artifact repository, so for
some reason during the download the content was duplicated.
Anyhow, I think we shouldn't use this strict setup in case of indirect poms
since often we cannot change these (third party files) and Maven used to expect
those kind of poms.
The other thing is that in plexus-utils we need to improve PI reading after the
closing-tag.
And a completely different issue: why was the content doubled.
So the workaround is probably, clean your local repository and download the
poms again.
> IndexArrayOutOfBounds when parsing POM
> ---
>
> Key: MNG-6216
> URL: https://issues.apache.org/jira/browse/MNG-6216
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Marc Savy
> Attachments: log
>
>
> When building apiman https://github.com/apiman/apiman.git on Maven 3.5.0 the
> XML parser seems to have some issues parsing the apiman-test-common module.
> If you want to reproduce, you can simply use mvn clean install, no profiles
> needed.
> Log: https://gist.github.com/msavy/a1b4307fb238a543dfd6af426b42d446
> Also attached.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6217) Creating a WARNING by using executions in pluginManagement
[
https://issues.apache.org/jira/browse/MNG-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15966459#comment-15966459
]
Robert Scholte commented on MNG-6217:
-
I know situations where adding execution blocks make sense. If you have a
company parent and you have plugins which should be executed pased on the type
of project, then it is often easier to do this setup, so developers only have
to specify the plugins groupId+artifactId to make that plugin part of the build
lifecycle. This is often done when having a hierarchy of parents is unpractical.
> Creating a WARNING by using executions in pluginManagement
> --
>
> Key: MNG-6217
> URL: https://issues.apache.org/jira/browse/MNG-6217
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.5.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.1
>
>
> I can often observe that defining something like this in pluginManagement:
> {code:xml}
>
>
> ...
>
>
>
>
>
>
> {code}
> which is superfluous and shut not being done.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6216) IndexArrayOutOfBounds when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15966584#comment-15966584 ] Robert Scholte commented on MNG-6216: - The parser used to stop with the closing project-tag, always assuming that was the end of the XML, see also MNG-6020. So yes, parsing is now more correct but exposes issues in case there is content after the closing project tag. We can only be strict like this for the pom.xml files of the reactor. Other files should be assumed that they cannot be changed. > IndexArrayOutOfBounds when parsing POM > --- > > Key: MNG-6216 > URL: https://issues.apache.org/jira/browse/MNG-6216 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Marc Savy > Attachments: log > > > When building apiman https://github.com/apiman/apiman.git on Maven 3.5.0 the > XML parser seems to have some issues parsing the apiman-test-common module. > If you want to reproduce, you can simply use mvn clean install, no profiles > needed. > Log: https://gist.github.com/msavy/a1b4307fb238a543dfd6af426b42d446 > Also attached. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MDEP-528) Plugin descriptor is missing configuration entries
[
https://issues.apache.org/jira/browse/MDEP-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15970422#comment-15970422
]
Robert Scholte commented on MDEP-528:
-
The mentioned {{}} is used in case there's a default value
and/or a property which can be used to set it. You should have a look at the
{{parameters/>}}
> Plugin descriptor is missing configuration entries
> --
>
> Key: MDEP-528
> URL: https://issues.apache.org/jira/browse/MDEP-528
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 2.10
>Reporter: Martin Höller
>Priority: Minor
>
> The plugin descriptor seem to be missing some entries, which
> leads to XML errors in IDEs.
> According to the documentation
> (https://maven.apache.org/plugins/maven-dependency-plugin/examples/exclude-dependencies-from-dependency-analysis.html)
> the analyse goal supports an "ignoredUsedUndeclaredDependencies" parameter.
> This parameter works as expected when following the instructions on the
> mentioned documentation page.
> However, the IDE reports invalid XML inside the -tag, for the
> >ignoredUsedUndeclaredDependencies> tag. Looking at the plugin descriptor
> plugin.xml inside the maven-dependency-plugin-2.10.jar, there is a
> configuration-entry that is missing some parameters:
> {code:xml}
>
> default-value="default">${analyzer}
>
> default-value="false">${failOnWarning}
> default-value="false">${ignoreNonCompile}
> default-value="${project.build.directory}"/>
> default-value="false">${outputXML}
> default-value="${project}"/>
> default-value="$$$%%%">${scriptableFlag}
> default-value="false">${scriptableOutput}
> default-value="false">${mdep.analyze.skip}
> default-value="false">${verbose}
>
> {code}
> Seems like this descriptor needs to be updated/re-generated.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MCOMPILER-293) Add advice message in case automodules are used
Robert Scholte created MCOMPILER-293:
Summary: Add advice message in case automodules are used
Key: MCOMPILER-293
URL: https://issues.apache.org/jira/browse/MCOMPILER-293
Project: Maven Compiler Plugin
Issue Type: Improvement
Reporter: Robert Scholte
Assignee: Robert Scholte
As mentioned by the JSR-376 project lead:
{quote}
Strongly advise developers never to publish, for broad use, explicit modules
that require automatic modules. That's risky: An automatic module is
unreliable, since it can depend on types on the class path, and its name and
exported packages could change if and when it's converted into an explicit
module. It's fine to declare and use explicit modules that require automatic
modules in limited settings, but they should never be published to Maven
Central or any similar public repository.
{quote}
The maven-compiler-plugin should help making people aware of it. In case of an
application (without exported packages) the message should be at INFO level,
for libraries (with exported packages) the message should be at warning level.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6220) Add CLI options to control color output
[
https://issues.apache.org/jira/browse/MNG-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15973336#comment-15973336
]
Robert Scholte commented on MNG-6220:
-
I really wonder if there's a need for this in the form of a commandline option.
[~aheritier] WDYT? My idea is that we need to introduce extension points for
better CI support, just like we did with Maven 3 for better IDE support.
> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
> Issue Type: New Feature
>Reporter: Manuel Ryan
>
> Currently, the only way to enable/disable color output is to use the
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment
> with the ansicolor plugin), there is no CLI option combination to support the
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6220) Add CLI options to control color output
[
https://issues.apache.org/jira/browse/MNG-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975202#comment-15975202
]
Robert Scholte commented on MNG-6220:
-
[~mryan] Just to let you know: Arnaud is working on both Maven and Jenkins
(Cloudbees).
We should try to only keep a limit set of CLI options. Based on Arnauds answer
there's no need for such an option. And to me that makes sense: the output for
Maven (console) and Jenkins (webpage) is different, so Jenkins must do output
parsing anyway to enable/disable color support.
> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
> Issue Type: New Feature
>Reporter: Manuel Ryan
>
> Currently, the only way to enable/disable color output is to use the
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment
> with the ansicolor plugin), there is no CLI option combination to support the
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MEJB-109) JDK 9 - EA compatibility Issue
[
https://issues.apache.org/jira/browse/MEJB-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15977357#comment-15977357
]
Robert Scholte commented on MEJB-109:
-
Workaround: add {{org.codehaus.plexus:plexus-archiver:3.0.3}} as dependency to
the plugin
> JDK 9 - EA compatibility Issue
> --
>
> Key: MEJB-109
> URL: https://issues.apache.org/jira/browse/MEJB-109
> Project: Maven EJB Plugin
> Issue Type: Bug
>Affects Versions: 2.5.1
> Environment: MAC OS X 10.12.4, IntelliJ IDEA 2017.1.1
> Build #IU-171.4073.35, built on April 6, 2017
>Reporter: Prafulla Kotecha
>
> When I run Maven-ejb-plugin with JDK 9 as the project SDK within intelliJ
> IDEA, I get this error log:
> {code}
> [INFO] --- maven-ejb-plugin:2.5.1:ejb (default-ejb) @ ---
> [WARNING] Error injecting: org.codehaus.plexus.archiver.jar.JarArchiver
> java.lang.ExceptionInInitializerError
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:487)
> at
> com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:86)
> at
> com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:105)
> at
> com.google.inject.internal.ConstructorInjector.access$000(ConstructorInjector.java:32)
> at
> com.google.inject.internal.ConstructorInjector$1.call(ConstructorInjector.java:89)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:133)
> at
> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
> at
> com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:87)
> at
> com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:267)
> at
> com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
> at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
> at
> com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1051)
> at
> org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
> at
> com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:53)
> at
> com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:65)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:133)
> at
> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
> at
> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:63)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
> at
> com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
> at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
> at org.eclipse.sisu.inject.Guice4$1.get(Guice4.java:162)
> at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:81)
> at
> org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
> at
> org.eclipse.sisu.plexus.PlexusRequirements$RequirementProvider.get(PlexusRequirements.java:250)
> at
> org.eclipse.sisu.plexus.ProvidedPropertyBinding.injectProperty(ProvidedPropertyBinding.java:48)
> at
> org.eclipse.sisu.bean.BeanInjector.injectMembers(BeanInjector.java:52)
> at
> com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:140)
> at
> com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:114)
> at
> com.google.inject.internal.Con
[jira] [Commented] (MNG-6220) Add CLI options to control color output
[
https://issues.apache.org/jira/browse/MNG-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15977364#comment-15977364
]
Robert Scholte commented on MNG-6220:
-
I don't think that colors are build specific properties. I can't think of a
reason why you want to have colors for some builds and no colors for others.
Instead it is a global settings for your environment/system. Hence,
SystemProperties makes more sense to me.
> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
> Issue Type: New Feature
>Reporter: Manuel Ryan
>
> Currently, the only way to enable/disable color output is to use the
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment
> with the ansicolor plugin), there is no CLI option combination to support the
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MEJB-109) JDK 9 - EA compatibility Issue
[
https://issues.apache.org/jira/browse/MEJB-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MEJB-109.
---
Resolution: Fixed
Assignee: Robert Scholte
Fix Version/s: 3.0.0
Already fixed fix MEJB-106
> JDK 9 - EA compatibility Issue
> --
>
> Key: MEJB-109
> URL: https://issues.apache.org/jira/browse/MEJB-109
> Project: Maven EJB Plugin
> Issue Type: Bug
>Affects Versions: 2.5.1
> Environment: MAC OS X 10.12.4, IntelliJ IDEA 2017.1.1
> Build #IU-171.4073.35, built on April 6, 2017
>Reporter: Prafulla Kotecha
>Assignee: Robert Scholte
> Fix For: 3.0.0
>
>
> When I run Maven-ejb-plugin with JDK 9 as the project SDK within intelliJ
> IDEA, I get this error log:
> {code}
> [INFO] --- maven-ejb-plugin:2.5.1:ejb (default-ejb) @ ---
> [WARNING] Error injecting: org.codehaus.plexus.archiver.jar.JarArchiver
> java.lang.ExceptionInInitializerError
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:487)
> at
> com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:86)
> at
> com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:105)
> at
> com.google.inject.internal.ConstructorInjector.access$000(ConstructorInjector.java:32)
> at
> com.google.inject.internal.ConstructorInjector$1.call(ConstructorInjector.java:89)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:133)
> at
> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
> at
> com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:87)
> at
> com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:267)
> at
> com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
> at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
> at
> com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1051)
> at
> org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
> at
> com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:53)
> at
> com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:65)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:133)
> at
> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
> at
> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:63)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
> at
> com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
> at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
> at org.eclipse.sisu.inject.Guice4$1.get(Guice4.java:162)
> at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:81)
> at
> org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
> at
> org.eclipse.sisu.plexus.PlexusRequirements$RequirementProvider.get(PlexusRequirements.java:250)
> at
> org.eclipse.sisu.plexus.ProvidedPropertyBinding.injectProperty(ProvidedPropertyBinding.java:48)
> at
> org.eclipse.sisu.bean.BeanInjector.injectMembers(BeanInjector.java:52)
> at
> com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:140)
> at
> com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:114)
> at
>
[jira] [Commented] (MNG-6220) Add CLI options to control color output
[
https://issues.apache.org/jira/browse/MNG-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15978416#comment-15978416
]
Robert Scholte commented on MNG-6220:
-
Let's do it like all colors are controlled as well:
e.g.
{{set MAVEN_OPTS=-Dstyle.color=enabled}}
This is one option to enable it for *every* build.
{{mvn | less -R}}
or
{{mvn -Dstyle.color=enabled | less -R}}
> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
> Issue Type: New Feature
>Reporter: Manuel Ryan
>
> Currently, the only way to enable/disable color output is to use the
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment
> with the ansicolor plugin), there is no CLI option combination to support the
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MEJB-109) JDK 9 - EA compatibility Issue
[
https://issues.apache.org/jira/browse/MEJB-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979014#comment-15979014
]
Robert Scholte commented on MEJB-109:
-
[~prafullkotecha], Ensure you're adding the dependency to the maven-ejb-plugin,
not the project itself. Anyhow, I think we should release this soon.
> JDK 9 - EA compatibility Issue
> --
>
> Key: MEJB-109
> URL: https://issues.apache.org/jira/browse/MEJB-109
> Project: Maven EJB Plugin
> Issue Type: Bug
>Affects Versions: 2.5.1
> Environment: MAC OS X 10.12.4, IntelliJ IDEA 2017.1.1
> Build #IU-171.4073.35, built on April 6, 2017
>Reporter: Prafulla Kotecha
>Assignee: Robert Scholte
> Fix For: 3.0.0
>
>
> When I run Maven-ejb-plugin with JDK 9 as the project SDK within intelliJ
> IDEA, I get this error log:
> {code}
> [INFO] --- maven-ejb-plugin:2.5.1:ejb (default-ejb) @ ---
> [WARNING] Error injecting: org.codehaus.plexus.archiver.jar.JarArchiver
> java.lang.ExceptionInInitializerError
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:487)
> at
> com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:86)
> at
> com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:105)
> at
> com.google.inject.internal.ConstructorInjector.access$000(ConstructorInjector.java:32)
> at
> com.google.inject.internal.ConstructorInjector$1.call(ConstructorInjector.java:89)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:133)
> at
> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
> at
> com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:87)
> at
> com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:267)
> at
> com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
> at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
> at
> com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1051)
> at
> org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
> at
> com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:53)
> at
> com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:65)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:133)
> at
> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
> at
> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:63)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
> at
> com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
> at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
> at org.eclipse.sisu.inject.Guice4$1.get(Guice4.java:162)
> at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:81)
> at
> org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
> at
> org.eclipse.sisu.plexus.PlexusRequirements$RequirementProvider.get(PlexusRequirements.java:250)
> at
> org.eclipse.sisu.plexus.ProvidedPropertyBinding.injectProperty(ProvidedPropertyBinding.java:48)
> at
> org.eclipse.sisu.bean.BeanInjector.injectMembers(BeanInjector.java:52)
> at
> com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:140)
> at
> com
[jira] [Closed] (MWAR-405) Workaround XStream incompatibility with Java9
[
https://issues.apache.org/jira/browse/MWAR-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MWAR-405.
---
Resolution: Fixed
Fix Version/s: 3.1.0
Fixed in [r1792363|http://svn.apache.org/viewvc?rev=1792363&view=rev]
Thanks for the patch!
> Workaround XStream incompatibility with Java9
> -
>
> Key: MWAR-405
> URL: https://issues.apache.org/jira/browse/MWAR-405
> Project: Maven WAR Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Enrico Olivelli
>Assignee: Robert Scholte
>Priority: Blocker
> Fix For: 3.1.0
>
>
> The problem is that XStreams tries to access "comparator" field of
> java.util.TreeMap and this is forbidden in Java9
> {code}
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> field private final java.util.Comparator java.util.TreeMap.comparator
> accessible: module java.base does not "opens java.util" to unnamed module
> Happens while initializing
> org.apache.maven.plugins.war.util.WebappStructureSerializer
> {code}
> A possibile workaround is to change the initialization of XStreams in a way
> that only useful converters are registers, thus bypassing the problem
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5883) Silence unnecessary legacy local repository warning
[
https://issues.apache.org/jira/browse/MNG-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980414#comment-15980414
]
Robert Scholte commented on MNG-5883:
-
Agreeing with Arnaud. Legacy repository is not reliable and should be removed
in the end. Would be good to link to the issues which describe where the
current repository fails. Those should be fix instead of discussing the
loglevel of this message.
> Silence unnecessary legacy local repository warning
> ---
>
> Key: MNG-5883
> URL: https://issues.apache.org/jira/browse/MNG-5883
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3, 3.5.0
>Reporter: Ben Caradoc-Davies
>Assignee: Christian Schulte
>Priority: Trivial
>
> Having been burned on several occasions by the new local repository
> behaviour, which in effect scopes artifacts by their origin (when first
> stored in the local repository), I was delighted by the introduction of the
> -llr command line option in 3.0.3. I now use this behaviour for all builds to
> avoid the build instability caused by remote repository migration. This
> avoids the need to start each build with:
> {code}
> find ~/.m2/repository -name "_*.repositories" -exec rm -f {} \;
> {code}
> Given that users of -llr have made an informed choice to do so, please remove
> the (in my view unnecessary) warning that it generates:
> {code}
> [WARNING] Disabling enhanced local repository: using legacy is strongly
> discouraged to ensure build reproducibility.
> {code}
> Kind regards,
> Ben.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Issue Comment Deleted] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.
[ https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6112: Comment: was deleted (was: FAILURE: Integrated in Jenkins build maven-3.x Jigsaw #5 (See [https://builds.apache.org/job/maven-3.x%20Jigsaw/5/]) [MNG-6112] Central repository in the 4.0.0 super POM should declare (schulte: rev c5f9b130c0281ab0c14a28310a200da7e84fcdd1) * (edit) maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml ) > Central repository in the 4.0.0 super POM should declare update policy > 'never'. > --- > > Key: MNG-6112 > URL: https://issues.apache.org/jira/browse/MNG-6112 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-beta-1 >Reporter: Christian Schulte > Fix For: 3.5.1-candidate > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Issue Comment Deleted] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.
[ https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6112: Comment: was deleted (was: FAILURE: Integrated in Jenkins build maven-3.x Jigsaw #6 (See [https://builds.apache.org/job/maven-3.x%20Jigsaw/6/]) [MNG-6112] Central repository in the 4.0.0 super POM should declare (schulte: rev 6b0b7a932efd172dbd3ff9322e7f372fb0cdf5ee) * (edit) maven-core/src/main/java/org/apache/maven/bridge/MavenRepositorySystem.java ) > Central repository in the 4.0.0 super POM should declare update policy > 'never'. > --- > > Key: MNG-6112 > URL: https://issues.apache.org/jira/browse/MNG-6112 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-beta-1 >Reporter: Christian Schulte > Fix For: 3.5.1-candidate > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.
[ https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15985348#comment-15985348 ] Robert Scholte commented on MNG-6112: - I'm missing the reason why did has to be changed. I should dive into this issue, but [some old blog|https://blog.saddey.net/2010/02/07/maven-never-say-never-in-an-updatepolicy/] matches the way I think the `never`-policy should work. I don't think that's what we want. > Central repository in the 4.0.0 super POM should declare update policy > 'never'. > --- > > Key: MNG-6112 > URL: https://issues.apache.org/jira/browse/MNG-6112 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-beta-1 >Reporter: Christian Schulte > Fix For: 3.5.1-candidate > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MNG-6222) Support exclusion of direct plugin dependencies
Robert Scholte created MNG-6222:
---
Summary: Support exclusion of direct plugin dependencies
Key: MNG-6222
URL: https://issues.apache.org/jira/browse/MNG-6222
Project: Maven
Issue Type: Improvement
Components: Plugins and Lifecycle
Reporter: Robert Scholte
Based on
http://stackoverflow.com/questions/43630262/how-to-exclude-a-direct-dependency-of-a-maven-plugin
{code:xml}
org.jvnet.jaxb2.maven2
maven-jaxb2-plugin
0.13.2
{code}
Up until now there hasn't been any reason to do this, but this seems like a
valid one. Most clean solution I can think of is allowing to override the scope
with "none" for plugin dependencies.
This solution won't break the pom-4.0.0.xsd
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6222) Support exclusion of direct plugin dependencies
[
https://issues.apache.org/jira/browse/MNG-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6222:
Fix Version/s: Issues to be reviewed for 4.x
> Support exclusion of direct plugin dependencies
> ---
>
> Key: MNG-6222
> URL: https://issues.apache.org/jira/browse/MNG-6222
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Reporter: Robert Scholte
> Fix For: Issues to be reviewed for 4.x
>
>
> Based on
> http://stackoverflow.com/questions/43630262/how-to-exclude-a-direct-dependency-of-a-maven-plugin
> {code:xml}
>
>
>
> org.jvnet.jaxb2.maven2
> maven-jaxb2-plugin
> 0.13.2
>
>
>
>
>
>
> {code}
> Up until now there hasn't been any reason to do this, but this seems like a
> valid one. Most clean solution I can think of is allowing to override the
> scope with "none" for plugin dependencies.
> This solution won't break the pom-4.0.0.xsd
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6222) Support exclusion of direct plugin dependencies
[
https://issues.apache.org/jira/browse/MNG-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6222:
Description:
Based on
http://stackoverflow.com/questions/43630262/how-to-exclude-a-direct-dependency-of-a-maven-plugin
{code:xml}
org.jvnet.jaxb2.maven2
maven-jaxb2-plugin
0.13.2
{code}
Up until now there hasn't been any reason to do this, but this seems like a
valid one. Most clean solution I can think of is allowing to override the scope
with "none" for plugin dependencies.
This solution won't break the pom-4.0.0.xsd
was:
Based on
http://stackoverflow.com/questions/43630262/how-to-exclude-a-direct-dependency-of-a-maven-plugin
{code:xml}
org.jvnet.jaxb2.maven2
maven-jaxb2-plugin
0.13.2
{code}
Up until now there hasn't been any reason to do this, but this seems like a
valid one. Most clean solution I can think of is allowing to override the scope
with "none" for plugin dependencies.
This solution won't break the pom-4.0.0.xsd
> Support exclusion of direct plugin dependencies
> ---
>
> Key: MNG-6222
> URL: https://issues.apache.org/jira/browse/MNG-6222
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Reporter: Robert Scholte
> Fix For: Issues to be reviewed for 4.x
>
>
> Based on
> http://stackoverflow.com/questions/43630262/how-to-exclude-a-direct-dependency-of-a-maven-plugin
> {code:xml}
>
>
>
> org.jvnet.jaxb2.maven2
> maven-jaxb2-plugin
> 0.13.2
>
>
>
>
>
>
>
>
> {code}
> Up until now there hasn't been any reason to do this, but this seems like a
> valid one. Most clean solution I can think of is allowing to override the
> scope with "none" for plugin dependencies.
> This solution won't break the pom-4.0.0.xsd
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1368) Not very informative fatal exit from testing - missing quotation in generated execution command
[
https://issues.apache.org/jira/browse/SUREFIRE-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SUREFIRE-1368:
-
Description:
Dears,
I am starting build {{mvn -X -e clean install}} which includes test written
using TestNG framework v. 6.8.8.
There comes following information:
{noformat}
[INFO] --- maven-surefire-plugin:2.15:test (default-test) @
logviewerservice-test ---
[INFO] Surefire report directory:
C:\StorageSpace\Projects\clj_project\logviewerservice-master\logviewerservice-test\target\surefire-reports
---
T E S T S
---
Das System kann den angegebenen Pfad nicht finden.
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
...
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test) on
project logviewerservice-test: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked VM
terminated without saying properly goodbye. VM crash or System.exit called ?
{noformat}
The "Das System kann den angegebenen Pfad nicht finden." means, that given
system path cannot be found.
1. Why mvn uses console language and not English?
2. Error message does not state which path cannot be found, so it makes
impossible to solve the problem, as testing uses many different paths.
3. Everything happend before even target/surefire-reports directory is created.
Can you help with that issue?
The configuration is simple:
{code:xml}
org.apache.maven.plugins
maven-surefire-plugin
2.19.1
{code}
What is ofcourse interesting, why v. 2.19.1 appears to be v. 2.15 in build.
Errors and exceptions are below:
{noformat}
[DEBUG] boot(compact) classpath: surefire-booter-2.15.jar
surefire-api-2.15.jar test-classes classes
... (bunch of jars)
surefire-testng-utils-2.15.jar surefire-grouper-2.15.jar
surefire-testng-2.15.jar common-java5-2.15.jar
Forking command line: cmd.exe /X /C "${jdk180.path}\bin\java
"-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
Das System kann den angegebenen Pfad nicht finden.
[ERROR] Command wascmd.exe /X /C "${jdk180.path}\bin\java
"-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test) on
project myservice-test: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked VM
terminated without saying properly goodbye. VM crash or System.exit called ?
Command wascmd.exe /X /C "${jdk180.path}\bin\java
"-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
[jira] [Comment Edited] (SUREFIRE-1368) Not very informative fatal exit from testing - missing quotation in generated execution command
[
https://issues.apache.org/jira/browse/SUREFIRE-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15984339#comment-15984339
]
Robert Scholte edited comment on SUREFIRE-1368 at 4/27/17 9:16 AM:
---
I am placing hipothesis which is also mentioned here:
http://stackoverflow.com/questions/15295183/maven-surefire-2-13-fails-to-fork-on-windows
In my case: Forking command line: cmd.exe /X /C "$\{jdk180.path}\bin\java
"-Djava.library.path=C:/Program Files (x86)/Foo/DLL"
The path: $\{jdk180.path}\bin\java is surrounded only on the left side by
quotation mark. The right side has no quotation mark. The next quotation mark
belongs to -Djava.library.path=C:/Program Files (x86)/Foo/DLL
was (Author: habdank):
I am placing hipothesis which is also mentioned here:
http://stackoverflow.com/questions/15295183/maven-surefire-2-13-fails-to-fork-on-windows
In my case: Forking command line: cmd.exe /X /C "${jdk180.path}\bin\java
"-Djava.library.path=C:/Program Files (x86)/Foo/DLL"
The path: ${jdk180.path}\bin\java is surrounded only on the left side by
quotation mark. The right side has no quotation mark. The next quotation mark
belongs to -Djava.library.path=C:/Program Files (x86)/Foo/DLL
> Not very informative fatal exit from testing - missing quotation in generated
> execution command
> ---
>
> Key: SUREFIRE-1368
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1368
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.15, 2.19.1
> Environment: Windows 10
>Reporter: Seweryn Habdank-Wojewodzki
>
> Dears,
> I am starting build {{mvn -X -e clean install}} which includes test written
> using TestNG framework v. 6.8.8.
> There comes following information:
> {noformat}
> [INFO] --- maven-surefire-plugin:2.15:test (default-test) @
> logviewerservice-test ---
> [INFO] Surefire report directory:
> C:\StorageSpace\Projects\clj_project\logviewerservice-master\logviewerservice-test\target\surefire-reports
> ---
> T E S T S
> ---
> Das System kann den angegebenen Pfad nicht finden.
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test) on
> project logviewerservice-test: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked
> VM terminated without saying properly goodbye. VM crash or System.exit called
> ?
> {noformat}
> The "Das System kann den angegebenen Pfad nicht finden." means, that given
> system path cannot be found.
> 1. Why mvn uses console language and not English?
> 2. Error message does not state which path cannot be found, so it makes
> impossible to solve the problem, as testing uses many different paths.
> 3. Everything happend before even target/surefire-reports directory is
> created.
> Can you help with that issue?
> The configuration is simple:
> {code:xml}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> {code}
> What is ofcourse interesting, why v. 2.19.1 appears to be v. 2.15 in build.
> Errors and exceptions are below:
> {noformat}
> [DEBUG] boot(compact) classpath: surefire-booter-2.15.jar
> surefire-api-2.15.jar test-classes classes
> ... (bunch of jars)
> surefire-testng-utils-2.15.jar surefire-grouper-2.15.jar
> surefire-testng-2.15.jar common-java5-2.15.jar
> Forking command line: cmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> Das System kann den angegebenen Pfad nicht finden.
> [ERROR] Command wascmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test)
> on project myservice-test: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked
> VM
[jira] [Commented] (SUREFIRE-1368) Not very informative fatal exit from testing - missing quotation in generated execution command
[
https://issues.apache.org/jira/browse/SUREFIRE-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986252#comment-15986252
]
Robert Scholte commented on SUREFIRE-1368:
--
I'm pretty sure the cause is simply that {{jdk180.path}} is not resolved. Just
run on your system: {{$\{jdk180.path}\bin\java}} and you will see the same
message (also explains why the message is in German, it's the OS complaining).
> Not very informative fatal exit from testing - missing quotation in generated
> execution command
> ---
>
> Key: SUREFIRE-1368
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1368
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.15, 2.19.1
> Environment: Windows 10
>Reporter: Seweryn Habdank-Wojewodzki
>
> Dears,
> I am starting build {{mvn -X -e clean install}} which includes test written
> using TestNG framework v. 6.8.8.
> There comes following information:
> {noformat}
> [INFO] --- maven-surefire-plugin:2.15:test (default-test) @
> logviewerservice-test ---
> [INFO] Surefire report directory:
> C:\StorageSpace\Projects\clj_project\logviewerservice-master\logviewerservice-test\target\surefire-reports
> ---
> T E S T S
> ---
> Das System kann den angegebenen Pfad nicht finden.
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test) on
> project logviewerservice-test: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked
> VM terminated without saying properly goodbye. VM crash or System.exit called
> ?
> {noformat}
> The "Das System kann den angegebenen Pfad nicht finden." means, that given
> system path cannot be found.
> 1. Why mvn uses console language and not English?
> 2. Error message does not state which path cannot be found, so it makes
> impossible to solve the problem, as testing uses many different paths.
> 3. Everything happend before even target/surefire-reports directory is
> created.
> Can you help with that issue?
> The configuration is simple:
> {code:xml}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> {code}
> What is ofcourse interesting, why v. 2.19.1 appears to be v. 2.15 in build.
> Errors and exceptions are below:
> {noformat}
> [DEBUG] boot(compact) classpath: surefire-booter-2.15.jar
> surefire-api-2.15.jar test-classes classes
> ... (bunch of jars)
> surefire-testng-utils-2.15.jar surefire-grouper-2.15.jar
> surefire-testng-2.15.jar common-java5-2.15.jar
> Forking command line: cmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> Das System kann den angegebenen Pfad nicht finden.
> [ERROR] Command wascmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test)
> on project myservice-test: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked
> VM terminated without saying properly goodbye. VM crash or System.exit called
> ?
> Command wascmd.exe /X /C "${jdk180.path}\bin\java
> "-Djava.library.path=C:/Program Files (x86)/Foo/DLL" -jar
> C:\StorageSpace\Projects\my-project\target\surefire\surefirebooter3832366471835279317.jar
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire9145576077183878807tmp
>
> C:\StorageSpace\Projects\my-project\target\surefire\surefire_0107990010860156596tmp"
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleMo
[jira] [Issue Comment Deleted] (MNG-4347) import-scoped dependencies of direct dependencies are not resolved using profile modifications from settings.xml
[ https://issues.apache.org/jira/browse/MNG-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-4347: Comment: was deleted (was: SUCCESS: Integrated in Jenkins build maven-3.x Jigsaw #34 (See [https://builds.apache.org/job/maven-3.x%20Jigsaw/34/]) [MNG-4347] import-scoped dependencies of direct dependencies are not (schulte: rev c3a4bd14d235911a5425f5ec70d39bbcdcd39569) * (edit) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultModelResolver.java ) > import-scoped dependencies of direct dependencies are not resolved using > profile modifications from settings.xml > > > Key: MNG-4347 > URL: https://issues.apache.org/jira/browse/MNG-4347 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies, General, > Profiles, Settings >Affects Versions: 2.2.1 >Reporter: John Casey >Priority: Critical > Fix For: 2.2.2, 3.5.1-candidate > > > Given: > * project A lists project B as a dependency > * project B lists project C as an import-scoped entry in dependencyManagement > * project B's dependency version for project C is a SNAPSHOT > * the user's settings.xml file modifies the definition of the central > repository to enable searching for SNAPSHOT artifacts. > When project A's dependency POMs are retrieved as part of collecting the > transitive dependency closure for A, B's project instance is built. During > this process, the POM for project C should be retrieved from central > (according to the modifications in settings.xml). However, the profile > information from the settings.xml is never applied to project B's POM, and > never modifies the central repository definition found there. Since the > default definition for the repository 'central' from the super POM has > snapshots disabled, project C's POM cannot be found, and the build fails. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-6223) mvn -f outputs invalid error when specifying POM directory
[
https://issues.apache.org/jira/browse/MNG-6223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6223:
Fix Version/s: (was: 3.5.1-candidate)
3.5.1
> mvn -f outputs invalid error when specifying POM directory
> --
>
> Key: MNG-6223
> URL: https://issues.apache.org/jira/browse/MNG-6223
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0-alpha-1, 3.5.0
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T15:39:06-04:00)
> Maven home: /Users/cgould/dev/tools/apache-maven-3.5.0
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
>Reporter: Charles Gould
>Priority: Minor
> Fix For: 3.5.1
>
> Attachments: alternate-pom.zip
>
>
> Basic multi-module project: common, client, and server modules.
>
> {noformat}
> $ mvn -f client package
> POM file client specified with the -f/--file command line argument does not
> exist
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building alternate-pom-client 1.0
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> alternate-pom-client ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /Users/cgould/dev/personal/alternate-pom/client/src/main/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
> alternate-pom-client ---
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
> alternate-pom-client ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /Users/cgould/dev/personal/alternate-pom/client/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @
> alternate-pom-client ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @
> alternate-pom-client ---
> [INFO] No tests to run.
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ alternate-pom-client ---
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.764 s
> [INFO] Finished at: 2017-04-29T14:03:22-04:00
> [INFO] Final Memory: 11M/309M
> [INFO]
>
> {noformat}
> There is an error message, but the client module proceeds to build
> nonetheless.
> I don't see the error message when I run:
> {noformat}
> $ mvn -f client/pom.xml package
> {noformat}
> I've verified it doesn't happen on 3.3.9, but it does happen on 3.5.0 and
> 3.5.0-alpha-1.
> Sample project attached.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SCM-807) JGit impl check-in fails unless the Maven project is in the working copy root
[
https://issues.apache.org/jira/browse/SCM-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15991214#comment-15991214
]
Robert Scholte commented on SCM-807:
Having unittests would indeed help.
And I'm a bit woried about the complete removal of the last block with the
comment: {{// if a specific fileSet is given, we have to check if the file is
really tracked}}. Not familiar with that piece of code, so can't say if it can
be removed safely.
> JGit impl check-in fails unless the Maven project is in the working copy root
> -
>
> Key: SCM-807
> URL: https://issues.apache.org/jira/browse/SCM-807
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.4
>Reporter: Richard DiCroce
> Attachments: scm-807.txt
>
>
> Another problem exposed by maven-release-plugin: the JGit SCM
> implementation's check-in fails unless the Maven project is in the working
> copy root because it confuses the working copy's location with the Maven
> project's location.
> The attached patch resolves the issue. Combined with the patch attached to
> SCM-806, release:prepare now mostly succeeds with the JGit implementation.
> There is still a problem with the POM not being transformed correctly, but
> that's a problem in maven-release-plugin.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MDOAP-49) Website still points to jira.codehaus.org
[ https://issues.apache.org/jira/browse/MDOAP-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MDOAP-49. --- Resolution: Fixed Assignee: Hervé Boutemy Fix Version/s: 3.0.0 Already fixed in [1671465|http://svn.apache.org/viewvc?rev=1671465&view=rev] as part of the codehaus to asf migration. Will be updated with the next release. > Website still points to jira.codehaus.org > - > > Key: MDOAP-49 > URL: https://issues.apache.org/jira/browse/MDOAP-49 > Project: Maven DOAP Plugin > Issue Type: Bug >Reporter: Sebb >Assignee: Hervé Boutemy > Fix For: 3.0.0 > > > As the subject says -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-5899) Reactor is no longer using the dependency reduced pom created by maven-shade-plugin
[ https://issues.apache.org/jira/browse/MNG-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15991297#comment-15991297 ] Robert Scholte commented on MNG-5899: - I think we should revise this *after* splitting up the build-pom and consumer-pom. I can imagine that during the construction of a buildplan the dependencies to a reactor module don't have to be fully resolved yet. That can be done after that module has been build or actually when it is required by another module. In the end the result must be the same as using that dependency from the local repsoitory. > Reactor is no longer using the dependency reduced pom created by > maven-shade-plugin > --- > > Key: MNG-5899 > URL: https://issues.apache.org/jira/browse/MNG-5899 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.1, 3.3.3 >Reporter: Trask Stalnaker > > This works with maven 3.2.5 and prior, but does not work with the latest > releases (3.3.1 and 3.3.3), or master (tested against 3.3.7-SNAPSHOT). > I did some bisecting and found the commit that caused the breakage: > https://github.com/apache/maven/commit/be3fb200326208ca4b8c41ebf16d5ae6b8049792 > In particular, this commit introduced some code to not rebuild the model if > it was already loaded during reactor resolution. > This is causing maven not to use the dependency reduced pom created by the > maven-shade-plugin. > Removing this code fixes the situation. I'm hoping that code was just > introduced as a performance optimization, and that I haven't broken anything > functionally by removing it (the tests still pass at least). > I will submit a pull request with the change for review. > Here is the original maven-shade-plugin issue as reported by the Apache Storm > team: https://issues.apache.org/jira/browse/MSHADE-206 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-5188) Test scope dependency incorrectly promoted to compile scope
[
https://issues.apache.org/jira/browse/MNG-5188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15991321#comment-15991321
]
Robert Scholte commented on MNG-5188:
-
[~atomashpolskiy] The project to this issue gives the following output, which
is as expected. MNG-6224 is a different usecase.
{noformat}
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ module2 ---
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile from plugin realm
ClassRealm[plugin>org.apache.maven.plugins:maven-compiler-plugin:3.1, parent:
sun.misc.Launcher$AppClassLoader@1174ec5]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-compiler-plugin:3.1:compile' with basic
configurator -->
[DEBUG] (f) basedir = E:\tmp-help\junit-transitive\module2
[DEBUG] (f) buildDirectory = E:\tmp-help\junit-transitive\module2\target
[DEBUG] (f) classpathElements =
[E:\tmp-help\junit-transitive\module2\target\classes,
E:\tmp-help\junit-transitive\module1\target\module1-0.0.1-SNAPSHOT.jar,
d:\maven_repo\.m2\repository\org\apache\openjpa\openjpa\2.1.1\openjpa-2.1.1.jar,
d:\maven_repo\.m2\repository\commons-lang\commons-lang\2.4\commons-lang-2.4.jar,
d:\maven_repo\.m2\repository\commons-collections\commons-collections\3.2.1\commons-collections-3.2.1.jar,
d:\maven_repo\.m2\repository\net\sourceforge\serp\serp\1.13.1\serp-1.13.1.jar,
d:\maven_repo\.m2\repository\org\apache\geronimo\specs\geronimo-jms_1.1_spec\1.1.1\geronimo-jms_1.1_spec-1.1.1.jar,
d:\maven_repo\.m2\repository\org\apache\geronimo\specs\geronimo-jta_1.1_spec\1.1.1\geronimo-jta_1.1_spec-1.1.1.jar,
d:\maven_repo\.m2\repository\commons-pool\commons-pool\1.5.4\commons-pool-1.5.4.jar,
d:\maven_repo\.m2\repository\org\apache\geronimo\specs\geronimo-jpa_2.0_spec\1.1\geronimo-jpa_2.0_spec-1.1.jar]
[DEBUG] (f) compileSourceRoots =
[E:\tmp-help\junit-transitive\module2\src\main\java]
[DEBUG] (f) compilerId = javac
[DEBUG] (f) debug = true
[DEBUG] (f) failOnError = true
[DEBUG] (f) forceJavacCompilerUse = false
[DEBUG] (f) fork = false
[DEBUG] (f) generatedSourcesDirectory =
E:\tmp-help\junit-transitive\module2\target\generated-sources\annotations
[DEBUG] (f) mojoExecution =
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile {execution:
default-compile}
[DEBUG] (f) optimize = false
[DEBUG] (f) outputDirectory =
E:\tmp-help\junit-transitive\module2\target\classes
[DEBUG] (f) projectArtifact = com.example:module2:jar:0.0.1-SNAPSHOT
[DEBUG] (f) showDeprecation = false
[DEBUG] (f) showWarnings = false
[DEBUG] (f) skipMultiThreadWarning = false
[DEBUG] (f) source = 1.5
[DEBUG] (f) staleMillis = 0
[DEBUG] (f) target = 1.5
[DEBUG] (f) useIncrementalCompilation = true
[DEBUG] (f) verbose = false
[DEBUG] (f) mavenSession = org.apache.maven.execution.MavenSession@7557b9e
[DEBUG] (f) session = org.apache.maven.execution.MavenSession@7557b9e
[DEBUG] -- end configuration --
[DEBUG] Using compiler 'javac'.
[DEBUG] Source directories: [E:\tmp-help\junit-transitive\module2\src\main\java]
[DEBUG] Classpath: [E:\tmp-help\junit-transitive\module2\target\classes
E:\tmp-help\junit-transitive\module1\target\module1-0.0.1-SNAPSHOT.jar
d:\maven_repo\.m2\repository\org\apache\openjpa\openjpa\2.1.1\openjpa-2.1.1.jar
d:\maven_repo\.m2\repository\commons-lang\commons-lang\2.4\commons-lang-2.4.jar
d:\maven_repo\.m2\repository\commons-collections\commons-collections\3.2.1\commons-collections-3.2.1.jar
d:\maven_repo\.m2\repository\net\sourceforge\serp\serp\1.13.1\serp-1.13.1.jar
d:\maven_repo\.m2\repository\org\apache\geronimo\specs\geronimo-jms_1.1_spec\1.1.1\geronimo-jms_1.1_spec-1.1.1.jar
d:\maven_repo\.m2\repository\org\apache\geronimo\specs\geronimo-jta_1.1_spec\1.1.1\geronimo-jta_1.1_spec-1.1.1.jar
d:\maven_repo\.m2\repository\commons-pool\commons-pool\1.5.4\commons-pool-1.5.4.jar
d:\maven_repo\.m2\repository\org\apache\geronimo\specs\geronimo-jpa_2.0_spec\1.1\geronimo-jpa_2.0_spec-1.1.jar]
[DEBUG] Output directory: E:\tmp-help\junit-transitive\module2\target\classes
[DEBUG] CompilerReuseStrategy: reuseCreated
[DEBUG] useIncrementalCompilation enabled
[DEBUG] Stale source detected:
E:\tmp-help\junit-transitive\module2\src\main\java\module2\Foo.java
[INFO] Changes detected - recompiling the module!
[DEBUG] Classpath:
[DEBUG] E:\tmp-help\junit-transitive\module2\target\classes
[DEBUG] E:\tmp-help\junit-transitive\module1\target\module1-0.0.1-SNAPSHOT.jar
[DEBUG]
d:\maven_repo\.m2\repository\org\apache\openjpa\openjpa\2.1.1\openjpa-2.1.1.jar
[DEBUG]
d:\maven_repo\.m2\repository\commons-lang\commons-lang\2.4\commons-lang-2.4.jar
[DEBUG]
d:\maven_repo\.m2\repository\commons-collections\commons-collections\3.2.1\commons-collections-3.2.1.jar
[DEBUG]
d:\maven_repo\.m2\repository\net\sourceforge\serp\serp\1.13.1\serp-1.13.1.jar
[DEBUG]
d:\maven_repo\.m2\repository\org\apache\geronimo\specs\geroni
[jira] [Commented] (MNG-6224) Dependency version from test scope leaks into compile scope
[
https://issues.apache.org/jira/browse/MNG-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15991338#comment-15991338
]
Robert Scholte commented on MNG-6224:
-
This is more related to MNG-6058. The discussion is more about what has a
higher priority: scope or distance? Or to put it differently: is it possible to
have a different version of an artifact on the classpath compared to the
test-classpath.
It has always been the definition that for every groupId+artifactId there's
only one scope and one version(nearest). That explains why 3.0.1 is chosen.
> Dependency version from test scope leaks into compile scope
> ---
>
> Key: MNG-6224
> URL: https://issues.apache.org/jira/browse/MNG-6224
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Andrei Tomashpolskiy
> Attachments: mvn_package.txt
>
>
> Despite test scope being non-transitive [1] it's still used to resolve
> versions of compile dependencies. This might be causing issues in IDEs that
> rely on the Dependency plugin to assemble the application's classpath.
> E.g. for the following project configuration *javax.servlet-api* version is
> resolved to *3.0.1* (using nearest-first strategy to resolve conflicts):
> {noformat}
> project1
> |-- project2:compile
> |..|-- jetty-server:compile
> ||-- javax.servlet-api:3.1.0:compile
> |-- jersey-test-framework-core:test
> |..|-- javax.servlet-api:3.0.1:compile
> {noformat}
> My understanding is that it should rather be resolved to 3.1.0, because
> version 3.0.1 stems from the test scope and should be ignored (AFAIK Maven
> Shade plugin works in that way).
> Please see a runnable code example in
> https://github.com/atomashpolskiy/maven-transitive-test-dependencies
> Thank you!
> [1]
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MDOAP-49) Website still points to jira.codehaus.org
[ https://issues.apache.org/jira/browse/MDOAP-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MDOAP-49. --- Resolution: Fixed Patched by [~hboutemy] in rev1011501 > Website still points to jira.codehaus.org > - > > Key: MDOAP-49 > URL: https://issues.apache.org/jira/browse/MDOAP-49 > Project: Maven DOAP Plugin > Issue Type: Bug >Reporter: Sebb >Assignee: Hervé Boutemy > Fix For: 3.0.0 > > > As the subject says -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-6025) Add a ProjectArtifactsCache similar to PluginArtifactsCache
[ https://issues.apache.org/jira/browse/MNG-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6025: Fix Version/s: 3.5.1-candidate > Add a ProjectArtifactsCache similar to PluginArtifactsCache > --- > > Key: MNG-6025 > URL: https://issues.apache.org/jira/browse/MNG-6025 > Project: Maven > Issue Type: Improvement > Components: core >Affects Versions: 3.3.9 >Reporter: Anton Tanasenko >Assignee: Jason van Zyl >Priority: Minor > Fix For: 3.5.1-candidate, needing-scrub-3.4.0-fallout > > > Every mojo execution, if it specifies dependency resolution other than > 'none', will cause a resolution to be performed. > There is a guard in MojoExecutor's DependencyContext which guards against > performing this resolution multiple times by looking at the changes to > dependencyArtifacts list. > However, during a build in an incremental/interactive environment, like > eclipse m2e or maven console, those mojos might be executed at an arbitrary > time and will not benefit from that DependencyContext check. > I propose having a ProjectArtifactsCache (very similar to > PluginArtifactsCache) that will cache artifact set as returned by > LifecycleDependencyResolver#getDependencies(). > While it does not improve cli builds, incremental/interactive builds will > receive a huge performance boost between pom changes. > I've been able to get build of a project with a lot of dependencies (jenkins > plugin) and a number of (fully incremental) mojo executions from 7 seconds to > around 1.5 on a single java file change in eclipse m2e after introducing this > cache. > I will provide a patch shortly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1265) reuseForks=false fails on jdk-9-ea builds
[ https://issues.apache.org/jira/browse/SUREFIRE-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15995267#comment-15995267 ] Robert Scholte commented on SUREFIRE-1265: -- [~eolivelli] you must use at least maven-compiler-plugin 3.6.1 to make it work > reuseForks=false fails on jdk-9-ea builds > - > > Key: SUREFIRE-1265 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1265 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.19.1 >Reporter: Michael Musgrove >Assignee: Tibor Digana > Labels: jigsaw > Fix For: 2.20.1 > > Attachments: j9test.tar, Java9Example.zip > > > When I run any surefire test (with reuseForks=false) that uses java.sql > classes on recent jdk-9 ea builds it fails with: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on > project maven-surefire-plugin-example: Execution default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: > java.lang.NoClassDefFoundError: java/sql/SQLException: java.sql.SQLException > -> [Help 1] > If I run it with reuseForks=true it works fine. > This problem was introduced in jdk build 9-ea+122 > (http://download.java.net/java/jdk9/changes/jdk-9+122.html) when the jigsaw > team addressed: > d20279be77d9 8154189 Deprivilege java.sql and java.sql.rowset module -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Issue Comment Deleted] (SUREFIRE-1265) reuseForks=false fails on jdk-9-ea builds
[ https://issues.apache.org/jira/browse/SUREFIRE-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated SUREFIRE-1265: - Comment: was deleted (was: [~eolivelli] you must use at least maven-compiler-plugin 3.6.1 to make it work) > reuseForks=false fails on jdk-9-ea builds > - > > Key: SUREFIRE-1265 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1265 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.19.1 >Reporter: Michael Musgrove >Assignee: Tibor Digana > Labels: jigsaw > Fix For: 2.20.1 > > Attachments: j9test.tar, Java9Example.zip > > > When I run any surefire test (with reuseForks=false) that uses java.sql > classes on recent jdk-9 ea builds it fails with: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on > project maven-surefire-plugin-example: Execution default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: > java.lang.NoClassDefFoundError: java/sql/SQLException: java.sql.SQLException > -> [Help 1] > If I run it with reuseForks=true it works fine. > This problem was introduced in jdk build 9-ea+122 > (http://download.java.net/java/jdk9/changes/jdk-9+122.html) when the jigsaw > team addressed: > d20279be77d9 8154189 Deprivilege java.sql and java.sql.rowset module -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1265) reuseForks=false fails on jdk-9-ea builds
[
https://issues.apache.org/jira/browse/SUREFIRE-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15995614#comment-15995614
]
Robert Scholte commented on SUREFIRE-1265:
--
well, I was too fast. It is a very simple Test which doesn't use any specific
Java 9 features, 2.5.1 is good enough.
What needs to be done is activate the javax.se.ee module using {{--add-modules
java.se.ee}}. See also
[SO|http://stackoverflow.com/questions/43574426/how-to-resolve-java-lang-noclassdeffounderror-javax-xml-bind-jaxbexception-in-j]
> reuseForks=false fails on jdk-9-ea builds
> -
>
> Key: SUREFIRE-1265
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1265
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Michael Musgrove
>Assignee: Tibor Digana
> Labels: jigsaw
> Fix For: 2.20.1
>
> Attachments: j9test.tar, Java9Example.zip
>
>
> When I run any surefire test (with reuseForks=false) that uses java.sql
> classes on recent jdk-9 ea builds it fails with:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on
> project maven-surefire-plugin-example: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed:
> java.lang.NoClassDefFoundError: java/sql/SQLException: java.sql.SQLException
> -> [Help 1]
> If I run it with reuseForks=true it works fine.
> This problem was introduced in jdk build 9-ea+122
> (http://download.java.net/java/jdk9/changes/jdk-9+122.html) when the jigsaw
> team addressed:
> d20279be77d9 8154189 Deprivilege java.sql and java.sql.rowset module
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1265) reuseForks=false fails on jdk-9-ea builds
[ https://issues.apache.org/jira/browse/SUREFIRE-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15995684#comment-15995684 ] Robert Scholte commented on SUREFIRE-1265: -- compiling works fine, if must be passed by surefire > reuseForks=false fails on jdk-9-ea builds > - > > Key: SUREFIRE-1265 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1265 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.19.1 >Reporter: Michael Musgrove >Assignee: Tibor Digana > Labels: jigsaw > Fix For: 2.20.1 > > Attachments: j9test.tar, Java9Example.zip > > > When I run any surefire test (with reuseForks=false) that uses java.sql > classes on recent jdk-9 ea builds it fails with: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on > project maven-surefire-plugin-example: Execution default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: > java.lang.NoClassDefFoundError: java/sql/SQLException: java.sql.SQLException > -> [Help 1] > If I run it with reuseForks=true it works fine. > This problem was introduced in jdk build 9-ea+122 > (http://download.java.net/java/jdk9/changes/jdk-9+122.html) when the jigsaw > team addressed: > d20279be77d9 8154189 Deprivilege java.sql and java.sql.rowset module -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1265) reuseForks=false fails on jdk-9-ea builds
[
https://issues.apache.org/jira/browse/SUREFIRE-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15995714#comment-15995714
]
Robert Scholte commented on SUREFIRE-1265:
--
http://download.java.net/java/jigsaw/docs/api/java/lang/ClassLoader.html#findClass-java.lang.String-java.lang.String-
So I think we should also use this method to find a class, i.e.
{{findClass("java.se.ee", name);}} with reflection
> reuseForks=false fails on jdk-9-ea builds
> -
>
> Key: SUREFIRE-1265
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1265
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Michael Musgrove
>Assignee: Tibor Digana
> Labels: jigsaw
> Fix For: 2.20.1
>
> Attachments: j9test.tar, Java9Example.zip
>
>
> When I run any surefire test (with reuseForks=false) that uses java.sql
> classes on recent jdk-9 ea builds it fails with:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on
> project maven-surefire-plugin-example: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed:
> java.lang.NoClassDefFoundError: java/sql/SQLException: java.sql.SQLException
> -> [Help 1]
> If I run it with reuseForks=true it works fine.
> This problem was introduced in jdk build 9-ea+122
> (http://download.java.net/java/jdk9/changes/jdk-9+122.html) when the jigsaw
> team addressed:
> d20279be77d9 8154189 Deprivilege java.sql and java.sql.rowset module
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6127) Fix plugin execution configuration interference
[ https://issues.apache.org/jira/browse/MNG-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6127: Fix Version/s: 3.5.1-candidate > Fix plugin execution configuration interference > --- > > Key: MNG-6127 > URL: https://issues.apache.org/jira/browse/MNG-6127 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.3.9 >Reporter: Mario Krizmanic > Fix For: 3.5.1-candidate, needing-scrub-3.4.0-fallout > > > The plugin execution configuration may interfere across maven modules > included in a build in case a plugin extension provides a default > configuration. > Because the custom plugin configuration defined in the maven modules is > merged to the plugin execution configuration and the merged configuration is > re-used during building the other included maven modules, so the other maven > modules may be build using the invalid configuration. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARCHETYPE-519) archetype:generate with specified remote archetypeCatalog falls back to internal catalog
[
https://issues.apache.org/jira/browse/ARCHETYPE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15998169#comment-15998169
]
Robert Scholte commented on ARCHETYPE-519:
--
A URL has never been a valid value for archetypeCatalog. I'd suggest to remove
that parameter.
> archetype:generate with specified remote archetypeCatalog falls back to
> internal catalog
>
>
> Key: ARCHETYPE-519
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-519
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 3.0.0
> Environment: Mac OS X 10.11.6, Apache Maven 3.2.3
>Reporter: Philip Mundt
>Assignee: Robert Scholte
> Fix For: 3.0.1
>
>
> We were surprised to find out that our archetype was "suddenly" not working
> anymore. It turns out it was the release of
> {{org.apache.maven.plugins:maven-archetype-plugin:3.0.0}} from 12/Feb/17 that
> was the culprit.
> When running:
> {{mvn org.apache.maven.plugins:maven-archetype-plugin:3.0.0:generate
> -DarchetypeCatalog=}} we end up with the
> plugin falling back to the internal catalog:
> {code}
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO]
>
> [INFO]
> [INFO] >>> maven-archetype-plugin:3.0.0:generate (default-cli) >
> generate-sources @ standalone-pom >>>
> [INFO]
> [INFO] <<< maven-archetype-plugin:3.0.0:generate (default-cli) <
> generate-sources @ standalone-pom <<<
> [INFO]
> [INFO] --- maven-archetype-plugin:3.0.0:generate (default-cli) @
> standalone-pom ---
> [INFO] Generating project in Interactive mode
> [INFO] No catalog defined. Using internal catalog
> [INFO] No archetype defined. Using maven-archetype-quickstart
> (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
> Choose archetype:
> 1: internal -> org.apache.maven.archetypes:maven-archetype-archetype (An
> archetype which contains a sample archetype.)
> 2: internal -> org.apache.maven.archetypes:maven-archetype-j2ee-simple (An
> archetype which contains a simplifed sample J2EE application.)
> 3: internal -> org.apache.maven.archetypes:maven-archetype-plugin (An
> archetype which contains a sample Maven plugin.)
> 4: internal -> org.apache.maven.archetypes:maven-archetype-plugin-site (An
> archetype which contains a sample Maven plugin site.
> This archetype can be layered upon an existing Maven plugin project.)
> 5: internal -> org.apache.maven.archetypes:maven-archetype-portlet (An
> archetype which contains a sample JSR-268 Portlet.)
> 6: internal -> org.apache.maven.archetypes:maven-archetype-profiles ()
> 7: internal -> org.apache.maven.archetypes:maven-archetype-quickstart (An
> archetype which contains a sample Maven project.)
> 8: internal -> org.apache.maven.archetypes:maven-archetype-site (An archetype
> which contains a sample Maven site which demonstrates
> some of the supported document types like APT, XDoc, and FML and
> demonstrates how
> to i18n your site. This archetype can be layered upon an existing Maven
> project.)
> 9: internal -> org.apache.maven.archetypes:maven-archetype-site-simple (An
> archetype which contains a sample Maven site.)
> 10: internal -> org.apache.maven.archetypes:maven-archetype-webapp (An
> archetype which contains a sample Maven Webapp project.)
> Choose a number or apply filter (format: [groupId:]artifactId, case sensitive
> contains):
> {code}
> Version 2.4 works as expected (the archetype catalog exists under given URL
> and can be downloaded).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MJAVADOC-480) Javadoc generation broken on Java9 if there are references to javax.xml.bind.annontation.XmlElement and building code for java8
[
https://issues.apache.org/jira/browse/MJAVADOC-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15998570#comment-15998570
]
Robert Scholte commented on MJAVADOC-480:
-
Could you try to add {{--add-modules
java.se.ee}} See http://openjdk.java.net/jeps/261 for the
details.
> Javadoc generation broken on Java9 if there are references to
> javax.xml.bind.annontation.XmlElement and building code for java8
> ---
>
> Key: MJAVADOC-480
> URL: https://issues.apache.org/jira/browse/MJAVADOC-480
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Enrico Olivelli
>Priority: Blocker
>
> The code uses javax.xml.bind.annotation.XmlElement annotations
> Plugin configuration:
> {code}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.4
>
> true
>
>
>
>
> attach-javadocs
>
> jar
>
>
>
>
> {code}
> This is my error
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:jar (attach-javadocs) on
> project scripting-api: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 -
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlField.java:22:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlField.java:23:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlRootElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlFieldValue.java:19:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlRootElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlDatabaseSchema.java:21:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlDatabaseSchema.java:22:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlRootElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/mock/MockContactsDB.java:27:
> error: package javax.xml.bind is not visible
> [ERROR] import javax.xml.bind.JAXB;
> [ERROR] ^
> [ERROR] (package javax.xml.bind is declared in module java.xml.bind, which is
> not in the module graph)
> [ERROR]
> [ERROR] Command line was:
> /home/diennea.lan/enrico.olivelli/dev/jdk-9/bin/javadoc @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/home/diennea.lan/enrico.olivelli/dev/magnews/scripting/target/apidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MJAVADOC-480) Javadoc generation broken on Java9 if there are references to javax.xml.bind.annontation.XmlElement and building code for java8
[
https://issues.apache.org/jira/browse/MJAVADOC-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MJAVADOC-480:
Priority: Minor (was: Blocker)
> Javadoc generation broken on Java9 if there are references to
> javax.xml.bind.annontation.XmlElement and building code for java8
> ---
>
> Key: MJAVADOC-480
> URL: https://issues.apache.org/jira/browse/MJAVADOC-480
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Enrico Olivelli
>Priority: Minor
>
> The code uses javax.xml.bind.annotation.XmlElement annotations
> Plugin configuration:
> {code}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.4
>
> true
>
>
>
>
> attach-javadocs
>
> jar
>
>
>
>
> {code}
> This is my error
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:jar (attach-javadocs) on
> project scripting-api: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 -
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlField.java:22:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlField.java:23:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlRootElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlFieldValue.java:19:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlRootElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlDatabaseSchema.java:21:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlDatabaseSchema.java:22:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlRootElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/mock/MockContactsDB.java:27:
> error: package javax.xml.bind is not visible
> [ERROR] import javax.xml.bind.JAXB;
> [ERROR] ^
> [ERROR] (package javax.xml.bind is declared in module java.xml.bind, which is
> not in the module graph)
> [ERROR]
> [ERROR] Command line was:
> /home/diennea.lan/enrico.olivelli/dev/jdk-9/bin/javadoc @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/home/diennea.lan/enrico.olivelli/dev/magnews/scripting/target/apidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MJAVADOC-480) Javadoc generation broken on Java9 if there are references to javax.xml.bind.annontation.XmlElement and building code for java8
[
https://issues.apache.org/jira/browse/MJAVADOC-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16001282#comment-16001282
]
Robert Scholte commented on MJAVADOC-480:
-
Thanks for the confirmation. This would be a valid usecase to introduce a
profile:
{code:xml}
[9,)
org.apache.maven.plugins
maven-javadoc-plugin
--add-modules ALL-SYSTEM
${additionalparam}
{code}
I don't think we should do some magic in this plugin to resolve this, the
developer should be aware of this setup.
However, let's add a FAQ or example page for it.
> Javadoc generation broken on Java9 if there are references to
> javax.xml.bind.annontation.XmlElement and building code for java8
> ---
>
> Key: MJAVADOC-480
> URL: https://issues.apache.org/jira/browse/MJAVADOC-480
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Enrico Olivelli
>Priority: Blocker
>
> The code uses javax.xml.bind.annotation.XmlElement annotations
> Plugin configuration:
> {code}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.4
>
> true
>
>
>
>
> attach-javadocs
>
> jar
>
>
>
>
> {code}
> This is my error
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:jar (attach-javadocs) on
> project scripting-api: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 -
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlField.java:22:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlField.java:23:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlRootElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlFieldValue.java:19:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlRootElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlDatabaseSchema.java:21:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/xml/XmlDatabaseSchema.java:22:
> error: package javax.xml.bind.annotation is not visible
> [ERROR] import javax.xml.bind.annotation.XmlRootElement;
> [ERROR] ^
> [ERROR] (package javax.xml.bind.annotation is declared in module
> java.xml.bind, which is not in the module graph)
> [ERROR]
> /home/diennea.lan/enrico.olivelli/dev/magnews/scripting/src/main/java/scripting/mock/MockContactsDB.java:27:
> error: package javax.xml.bind is not visible
> [ERROR] import javax.xml.bind.JAXB;
> [ERROR] ^
> [ERROR] (package javax.xml.bind is declared in module java.xml.bind, which is
> not in the module graph)
> [ERROR]
> [ERROR] Command line was:
> /home/diennea.lan/enrico.olivelli/dev/jdk-9/bin/javadoc @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/home/diennea.lan/enrico.olivelli/dev/magnews/scripting/target/apidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARCHETYPE-519) archetype:generate with specified remote archetypeCatalog falls back to internal catalog
[
https://issues.apache.org/jira/browse/ARCHETYPE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16007928#comment-16007928
]
Robert Scholte commented on ARCHETYPE-519:
--
I've started a thread for it on the
[dev-list|http://mail-archives.apache.org/mod_mbox/maven-dev/201705.mbox/%3cop.yzxkl9xlkdkhrr@desktop-2khsk44%3e],
you can read the responses yourself. Feel free to join the discussion there.
> archetype:generate with specified remote archetypeCatalog falls back to
> internal catalog
>
>
> Key: ARCHETYPE-519
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-519
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 3.0.0
> Environment: Mac OS X 10.11.6, Apache Maven 3.2.3
>Reporter: Philip Mundt
>Assignee: Robert Scholte
> Fix For: 3.0.1
>
>
> We were surprised to find out that our archetype was "suddenly" not working
> anymore. It turns out it was the release of
> {{org.apache.maven.plugins:maven-archetype-plugin:3.0.0}} from 12/Feb/17 that
> was the culprit.
> When running:
> {{mvn org.apache.maven.plugins:maven-archetype-plugin:3.0.0:generate
> -DarchetypeCatalog=}} we end up with the
> plugin falling back to the internal catalog:
> {code}
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO]
>
> [INFO]
> [INFO] >>> maven-archetype-plugin:3.0.0:generate (default-cli) >
> generate-sources @ standalone-pom >>>
> [INFO]
> [INFO] <<< maven-archetype-plugin:3.0.0:generate (default-cli) <
> generate-sources @ standalone-pom <<<
> [INFO]
> [INFO] --- maven-archetype-plugin:3.0.0:generate (default-cli) @
> standalone-pom ---
> [INFO] Generating project in Interactive mode
> [INFO] No catalog defined. Using internal catalog
> [INFO] No archetype defined. Using maven-archetype-quickstart
> (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
> Choose archetype:
> 1: internal -> org.apache.maven.archetypes:maven-archetype-archetype (An
> archetype which contains a sample archetype.)
> 2: internal -> org.apache.maven.archetypes:maven-archetype-j2ee-simple (An
> archetype which contains a simplifed sample J2EE application.)
> 3: internal -> org.apache.maven.archetypes:maven-archetype-plugin (An
> archetype which contains a sample Maven plugin.)
> 4: internal -> org.apache.maven.archetypes:maven-archetype-plugin-site (An
> archetype which contains a sample Maven plugin site.
> This archetype can be layered upon an existing Maven plugin project.)
> 5: internal -> org.apache.maven.archetypes:maven-archetype-portlet (An
> archetype which contains a sample JSR-268 Portlet.)
> 6: internal -> org.apache.maven.archetypes:maven-archetype-profiles ()
> 7: internal -> org.apache.maven.archetypes:maven-archetype-quickstart (An
> archetype which contains a sample Maven project.)
> 8: internal -> org.apache.maven.archetypes:maven-archetype-site (An archetype
> which contains a sample Maven site which demonstrates
> some of the supported document types like APT, XDoc, and FML and
> demonstrates how
> to i18n your site. This archetype can be layered upon an existing Maven
> project.)
> 9: internal -> org.apache.maven.archetypes:maven-archetype-site-simple (An
> archetype which contains a sample Maven site.)
> 10: internal -> org.apache.maven.archetypes:maven-archetype-webapp (An
> archetype which contains a sample Maven Webapp project.)
> Choose a number or apply filter (format: [groupId:]artifactId, case sensitive
> contains):
> {code}
> Version 2.4 works as expected (the archetype catalog exists under given URL
> and can be downloaded).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MCOMPILER-285) Support test-compile for JDK 9 build b148+
[
https://issues.apache.org/jira/browse/MCOMPILER-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16007933#comment-16007933
]
Robert Scholte commented on MCOMPILER-285:
--
[~dmlloyd], confirmed. See also MCOMPILER-294
> Support test-compile for JDK 9 build b148+
> --
>
> Key: MCOMPILER-285
> URL: https://issues.apache.org/jira/browse/MCOMPILER-285
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.6.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
> Fix For: 3.6.1
>
>
> {quote}
> JDK 9 build b148 includes an important Refresh of the module system.
> This refresh includes a disruptive change that is important to understand.
> For those that have been trying out modules with regular JDK 9 builds then be
> aware that `requires public` changes to `requires transitive`. In addition,
> the binary representation of the module declaration (module-info.class) has
> changed so that you need to recompile any modules that were compiled with
> previous JDK 9 builds.
> {quote}
> To be able to compile the test sources, you must specify the module name (i.e
> {{-Xmodule:the.module.name}}). This information is already available in
> {{src/main/java/module-info.java}}, so no need to ask for it again. Due to
> the change of the binary representation the original trick wiith
> ASM-6.0_ALPHA doesn't work anymore.
> We're going to add a second parser based on QDox, which doesn't parse the
> class file but the source file. This way we have to options to extract the
> module name.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6233) maven-resolver-provider mixes jsr330 and plexus annotations
[ https://issues.apache.org/jira/browse/MNG-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16011143#comment-16011143 ] Robert Scholte commented on MNG-6233: - I assume we still generate the metadata-descriptor to have faster access compared to class scanning. > maven-resolver-provider mixes jsr330 and plexus annotations > --- > > Key: MNG-6233 > URL: https://issues.apache.org/jira/browse/MNG-6233 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9, 3.5.0 >Reporter: Igor Fedorenko > Fix For: 3.5.1-candidate > > > Mixed annotations confuse guice/sisu and result in hard to troubleshoot and > impossible to workaround problems in applications that embed Maven core > runtime, like m2e and gshell. > I believe plugins annotations where left in the code by mistake so the plan > is to update the code to use jsr330 exclusively and completely remove plexus > annotations. This change is fully transparent to the users (and we've been > using it internally for couple of months now). > See also https://github.com/apache/maven/pull/116 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6233) maven-resolver-provider mixes jsr330 and plexus annotations
[ https://issues.apache.org/jira/browse/MNG-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16011158#comment-16011158 ] Robert Scholte commented on MNG-6233: - IIRC [~jvanzyl] prepared this on his system. However, JSR330 doesn't support different configurations with the same implementation, like we do for lifecycles. Not sure what happened to that part. If Jason can apply it on the current sourcetree without issues, we could do that. Otherwise let's go for a per-module upgrade, although I think it should all fit within one release. That said, having 1 issue with a checklist for all modules is good enough for me. > maven-resolver-provider mixes jsr330 and plexus annotations > --- > > Key: MNG-6233 > URL: https://issues.apache.org/jira/browse/MNG-6233 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9, 3.5.0 >Reporter: Igor Fedorenko > Fix For: 3.5.1-candidate > > > Mixed annotations confuse guice/sisu and result in hard to troubleshoot and > impossible to workaround problems in applications that embed Maven core > runtime, like m2e and gshell. > I believe plugins annotations where left in the code by mistake so the plan > is to update the code to use jsr330 exclusively and completely remove plexus > annotations. This change is fully transparent to the users (and we've been > using it internally for couple of months now). > See also https://github.com/apache/maven/pull/116 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MCOMPILER-295) Upgrade ASM to 6.0_ALPHA2
Robert Scholte created MCOMPILER-295: Summary: Upgrade ASM to 6.0_ALPHA2 Key: MCOMPILER-295 URL: https://issues.apache.org/jira/browse/MCOMPILER-295 Project: Maven Compiler Plugin Issue Type: New Feature Reporter: Robert Scholte Assignee: Robert Scholte 6.0_ALPHA uses an old format of the module-info.class -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MINVOKER-218) Change package to o.a.m.plugins
Robert Scholte created MINVOKER-218: --- Summary: Change package to o.a.m.plugins Key: MINVOKER-218 URL: https://issues.apache.org/jira/browse/MINVOKER-218 Project: Maven Invoker Plugin Issue Type: Task Reporter: Robert Scholte Assignee: Robert Scholte Priority: Minor Fix For: 3.0.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MINVOKER-218) Change package to o.a.m.plugins
[ https://issues.apache.org/jira/browse/MINVOKER-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MINVOKER-218. --- Resolution: Fixed Fixed in [r1795243|http://svn.apache.org/viewvc?rev=1795243&view=rev] > Change package to o.a.m.plugins > --- > > Key: MINVOKER-218 > URL: https://issues.apache.org/jira/browse/MINVOKER-218 > Project: Maven Invoker Plugin > Issue Type: Task >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MINVOKER-204) Upgrade to Maven3 plugin
[ https://issues.apache.org/jira/browse/MINVOKER-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MINVOKER-204. --- Resolution: Fixed Fixed in [r1795239|http://svn.apache.org/viewvc?rev=1795239&view=rev] > Upgrade to Maven3 plugin > > > Key: MINVOKER-204 > URL: https://issues.apache.org/jira/browse/MINVOKER-204 > Project: Maven Invoker Plugin > Issue Type: Improvement >Reporter: Robert Scholte >Assignee: Robert Scholte > Fix For: 3.0.0 > > > All Maven2 dependencies will be upgraded to Maven3. We remove Maven2 code > when there's a better solution with Maven3. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MINVOKER-188) IT - staging-dependencies fails when using with maven mirror
[ https://issues.apache.org/jira/browse/MINVOKER-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MINVOKER-188. --- Resolution: Cannot Reproduce Assignee: Robert Scholte (was: Karl Heinz Marbaise) Cannot reproduce it anymore, with 3.0.0-SNAPSHOT the test succeeds. That's good enough for me to confirm it is fixed. > IT - staging-dependencies fails when using with maven mirror > > > Key: MINVOKER-188 > URL: https://issues.apache.org/jira/browse/MINVOKER-188 > Project: Maven Invoker Plugin > Issue Type: Task >Affects Versions: 1.10 >Reporter: Dan Tran >Assignee: Robert Scholte > > When running mirror settings under ~/.m2/setttings.xml, this test always fail > [INFO] Building: staging-dependencies/pom.xml > [INFO] ..FAILED (2.9 s) > [INFO] The build exited with code 1. See > /data/jenkins-work/jobs/maven-invoker-plugin/workspace/target/it/staging-dependencies/build.log > for details. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MINVOKER-219) Change default value for cloneProjectsTo
Robert Scholte created MINVOKER-219:
---
Summary: Change default value for cloneProjectsTo
Key: MINVOKER-219
URL: https://issues.apache.org/jira/browse/MINVOKER-219
Project: Maven Invoker Plugin
Issue Type: Improvement
Reporter: Robert Scholte
Assignee: Robert Scholte
Priority: Minor
Fix For: 3.0.0
Up until now {{cloneProjectsTo}} is never set, which means that by default the
source-directory gets polluted with the IT test execution.
You often see this parameter is ste to {{target/its}}, so let's use that as the
new default.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MINVOKER-219) Change default value for cloneProjectsTo
[
https://issues.apache.org/jira/browse/MINVOKER-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MINVOKER-219:
Description:
Up until now {{cloneProjectsTo}} is never set, which means that by default the
source-directory gets polluted with the IT test execution.
You often see this parameter is set to {{target/its}}, so let's use that as the
new default.
To ensure the IT output-folder is in the correct state, it is also better the
set {{cloneClean}} to {{true}} by default. This is more efficient compared to
{{mvn clean}} because only a subset of the folders are cleaned.
was:
Up until now {{cloneProjectsTo}} is never set, which means that by default the
source-directory gets polluted with the IT test execution.
You often see this parameter is ste to {{target/its}}, so let's use that as the
new default.
> Change default value for cloneProjectsTo
>
>
> Key: MINVOKER-219
> URL: https://issues.apache.org/jira/browse/MINVOKER-219
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.0.0
>
>
> Up until now {{cloneProjectsTo}} is never set, which means that by default
> the source-directory gets polluted with the IT test execution.
> You often see this parameter is set to {{target/its}}, so let's use that as
> the new default.
> To ensure the IT output-folder is in the correct state, it is also better the
> set {{cloneClean}} to {{true}} by default. This is more efficient compared to
> {{mvn clean}} because only a subset of the folders are cleaned.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MINVOKER-219) Change default value for cloneProjectsTo and cloneClean
[
https://issues.apache.org/jira/browse/MINVOKER-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MINVOKER-219:
Summary: Change default value for cloneProjectsTo and cloneClean (was:
Change default value for cloneProjectsTo)
> Change default value for cloneProjectsTo and cloneClean
> ---
>
> Key: MINVOKER-219
> URL: https://issues.apache.org/jira/browse/MINVOKER-219
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.0.0
>
>
> Up until now {{cloneProjectsTo}} is never set, which means that by default
> the source-directory gets polluted with the IT test execution.
> You often see this parameter is set to {{target/its}}, so let's use that as
> the new default.
> To ensure the IT output-folder is in the correct state, it is also better the
> set {{cloneClean}} to {{true}} by default. This is more efficient compared to
> {{mvn clean}} because only a subset of the folders are cleaned.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MINVOKER-219) Change default value for cloneProjectsTo and cloneClean
[
https://issues.apache.org/jira/browse/MINVOKER-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MINVOKER-219.
---
Resolution: Fixed
Fixed in [1795362|http://svn.apache.org/viewvc?rev=1795362&view=rev]
> Change default value for cloneProjectsTo and cloneClean
> ---
>
> Key: MINVOKER-219
> URL: https://issues.apache.org/jira/browse/MINVOKER-219
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.0.0
>
>
> Up until now {{cloneProjectsTo}} is never set, which means that by default
> the source-directory gets polluted with the IT test execution.
> You often see this parameter is set to {{target/its}}, so let's use that as
> the new default.
> To ensure the IT output-folder is in the correct state, it is also better the
> set {{cloneClean}} to {{true}} by default. This is more efficient compared to
> {{mvn clean}} because only a subset of the folders are cleaned.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MCOMPILER-296) Add jpms.args to the META-INF folder
Robert Scholte created MCOMPILER-296:
Summary: Add jpms.args to the META-INF folder
Key: MCOMPILER-296
URL: https://issues.apache.org/jira/browse/MCOMPILER-296
Project: Maven Compiler Plugin
Issue Type: Improvement
Reporter: Robert Scholte
Assignee: Robert Scholte
When compiling a Java9 project with some specific jigsaw/jpms flag, e.g. to
open access to certain modules, those flags are probably also required at
runtime. If these flags used for a library, that library-user might need to use
that same set of flags, but how could he be aware of these flags?
I'd like to add {{META-INF/jpms.args}} to store these specific flags. This file
provides easy access to these arguments and can be used by other tools/plugins.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MSHADE-242) Plugin does not work with Java 9
[
https://issues.apache.org/jira/browse/MSHADE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16018879#comment-16018879
]
Robert Scholte commented on MSHADE-242:
---
Still waiting for the next ASM release, 6.0_ALPHA is not compatible with the
current {{module-info.class}} implementation anymore.
> Plugin does not work with Java 9
>
>
> Key: MSHADE-242
> URL: https://issues.apache.org/jira/browse/MSHADE-242
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.4.3
> Environment: ╰─✘ java -version
> openjdk version "9-internal"
> OpenJDK Runtime Environment (build 9-internal+0-2016-11-17-101644.norman.jdk9)
> OpenJDK 64-Bit Server VM (build 9-internal+0-2016-11-17-101644.norman.jdk9,
> mixed mode)
>Reporter: Norman Maurer
>
> When trying to use the shade plugin with java9 I get:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade (default) on project
> netty-common: Error creating shaded jar: null: IllegalArgumentException ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade (default) on
> project netty-common: Error creating shaded jar: null
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> 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:537)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating
> shaded jar: null
> at
> org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:540)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 20 more
> Caused by: java.lang.IllegalArgumentException
> at org.objectweb.asm.ClassReader.(Unknown Source)
> at org.objectweb.asm.ClassReader.(Unknown Source)
> at org.objectweb.asm.ClassReader.(Unknown Source)
> at org.vafer.jdependency.Clazzpath.addClazzpathUnit(Clazzpath.java:201)
> at org.vafer.jdependency.Clazzpath.addClazzpathUnit(Clazzpath.java:132)
> at
> org.apache.maven.plugins.shade.filter.MinijarFilter.(MinijarFilter.java:94)
> at
> org.apache.maven.plugins.shade.mojo.ShadeMojo.getFilters(ShadeMojo.java:814)
> at
> org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:446)
> ... 22 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARCHETYPE-528) Archetype:generate from repos besides central does not work
[
https://issues.apache.org/jira/browse/ARCHETYPE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16027514#comment-16027514
]
Robert Scholte commented on ARCHETYPE-528:
--
bq. maven central is hardcoded into the plugin
I'm pretty sure that all hardcoded references to Maven Central have been
removed from this plugin. It means that it is falling back to Mavens own
defaults.
bq. the "archetype" repository isn't being used for fetching the catalog but
can be used for fetching artifacts
In case of a mirror I know this is working. This is a case which hasn't been
covered yet.
bq. it complains about the "archetype" repository missing despite it being
defined
Very likely related to the previous bullet.
For me this line is interesting: {{[DEBUG] Searching for remote catalog:
https://repo.maven.apache.org/maven2/archetype-catalog.xml}}. It should have
picked the archetype-repository. So this is a clear message that the
refactoring is not complete yet.
> Archetype:generate from repos besides central does not work
> ---
>
> Key: ARCHETYPE-528
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-528
> Project: Maven Archetype
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: João Cabrita
>Priority: Critical
> Attachments: settings.xml
>
>
> {noformat}
> mvn -X -P camunda -DarchetypeCatalog=remote
> org.apache.maven.plugins:maven-archetype-plugin:3.0.1:generate
> -Dfilter=org.camunda.bpm.archetype:
> {noformat}
> Results in the following:
> {noformat}
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-archetype-plugin:3.0.1:generate' with basic
> configurator -->
> [DEBUG] (f) archetypeCatalog = remote
> [DEBUG] (f) basedir = C:\Users\joao.cabrita\projects\bpm
> [DEBUG] (f) filter = org.camunda.bpm.archetype:
> [DEBUG] (f) interactiveMode = true
> [DEBUG] (f) localRepository = id: local
> url: file:///C:/Users/joao.cabrita/.m2/repository/
>layout: default
> snapshots: [enabled => true, update => always]
> releases: [enabled => true, update => always]
> [DEBUG] (f) remoteArtifactRepositories = [ id: central
> url: https://app.camunda.com/nexus/content/repositories/camunda-bpm
>layout: default
> proxy: proxy.brisa.pt:3128
> snapshots: [enabled => true, update => daily]
> releases: [enabled => true, update => daily]
> , id: archetype
> url: https://app.camunda.com/nexus/content/repositories/camunda-bpm
>layout: default
> proxy: proxy.brisa.pt:3128
> snapshots: [enabled => true, update => daily]
> releases: [enabled => true, update => daily]
> ]
> [DEBUG] (f) session = org.apache.maven.execution.MavenSession@325f7fa9
> [DEBUG] -- end configuration --
> [INFO] Generating project in Interactive mode
> [DEBUG] Searching for remote catalog:
> https://repo.maven.apache.org/maven2/archetype-catalog.xml
> [WARNING] No archetype found in remote catalog. Defaulting to internal catalog
> [INFO] Your filter doesn't match any archetype, so try again with another
> value.
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {noformat}
> I've attached my settings.xml file.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MJAR-193) Allow other mojos to contribute to the manifest
[ https://issues.apache.org/jira/browse/MJAR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16027607#comment-16027607 ] Robert Scholte commented on MJAR-193: - I think the proper way is to have some kind of extensionpoint in the maven-jar-plugin where you can add MANIFEST-logic. One of the fundamental rules is that plugins should not be aware of each other and I think this can be solved within the maven-jar-plugin. > Allow other mojos to contribute to the manifest > --- > > Key: MJAR-193 > URL: https://issues.apache.org/jira/browse/MJAR-193 > Project: Maven JAR Plugin > Issue Type: Improvement >Reporter: Carsten Ziegeler > Fix For: waiting-for-feedback > > > It would be great to have a programmatic way to add entries to the manifest > from other mojos. The most important client of such a way would be the maven > bundle plugin (from the Apache Felix project) that calculates additional > headers for OSGi bundles. Right now, that bundle does not only do the > calculation but generates the jar file as well. > While a workaround would be to let the bundle plugin generate the full > manifest and configure the jar plugin to use it, this is not very elegant. > Passing down a map of manifest entries from one mojo to the jar plugin would > solve this in a much better way. > And I could imagine that other mojos/plugins might benefit for this as well. > This would be a simple but very convenient enhancement to the plugin -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MCOMPILER-298) Support "-parameters" compiler option as a configuration key
[
https://issues.apache.org/jira/browse/MCOMPILER-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MCOMPILER-298:
-
Attachment: mcompiler298-IT.patch
I think this patch contains an IT which should work.
> Support "-parameters" compiler option as a configuration key
>
>
> Key: MCOMPILER-298
> URL: https://issues.apache.org/jira/browse/MCOMPILER-298
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.6.1
>Reporter: brian clozel
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Minor
> Labels: pull-request-available
> Fix For: 3.6.2
>
> Attachments: mcompiler298-IT.patch
>
>
> The {{-parameters}} flag is, as of JDK8, a standard compiler option for the
> compiler. This option should be frequently used by developers and it would
> make sense to have it as a first class option (like source, target and many
> others) rather than using {{compilerArgs}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MPMD-238) Execution default-cli of goal org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd failed: A required class was missing while executing org.apache.maven.plugins:maven-pmd-plugi
[
https://issues.apache.org/jira/browse/MPMD-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MPMD-238.
---
Resolution: Not A Problem
> Execution default-cli of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd failed: A required class
> was missing while executing
> org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd:
> org/objectweb/asm/ClassVisitor
> --
>
> Key: MPMD-238
> URL: https://issues.apache.org/jira/browse/MPMD-238
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.8
> Environment: Mac OS X 10.12.4, Oracle JDK 1.8.0_131, Apache Maven
> 3.5.0
>Reporter: Martijn Verburg
>Priority: Blocker
> Labels: maven
>
> When running {{mvn pmd:pmd}} on a project the command fails with:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd (default-cli) on
> project jclarity-util: Execution default-cli of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd failed: A required class
> was missing while executing
> org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd:
> org/objectweb/asm/ClassVisitor
> -
> realm =plugin>org.apache.maven.plugins:maven-pmd-plugin:3.8
> strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> urls[0] =
> file:/Users/karianna/.m2/repository/org/apache/maven/plugins/maven-pmd-plugin/3.8/maven-pmd-plugin-3.8.jar
> urls[1] =
> file:/Users/karianna/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
> urls[2] =
> file:/Users/karianna/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
> urls[3] =
> file:/Users/karianna/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> urls[4] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.4/doxia-sink-api-1.4.jar
> urls[5] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.4/doxia-logging-api-1.4.jar
> urls[6] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-decoration-model/1.4/doxia-decoration-model-1.4.jar
> urls[7] =
> file:/Users/karianna/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.6/plexus-component-annotations-1.6.jar
> urls[8] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-site-renderer/1.4/doxia-site-renderer-1.4.jar
> urls[9] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-core/1.4/doxia-core-1.4.jar
> urls[10] =
> file:/Users/karianna/.m2/repository/xerces/xercesImpl/2.9.1/xercesImpl-2.9.1.jar
> urls[11] =
> file:/Users/karianna/.m2/repository/xml-apis/xml-apis/1.3.04/xml-apis-1.3.04.jar
> urls[12] =
> file:/Users/karianna/.m2/repository/commons-lang/commons-lang/2.4/commons-lang-2.4.jar
> urls[13] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-module-xhtml/1.4/doxia-module-xhtml-1.4.jar
> urls[14] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-module-fml/1.4/doxia-module-fml-1.4.jar
> urls[15] =
> file:/Users/karianna/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-7/plexus-i18n-1.0-beta-7.jar
> urls[16] =
> file:/Users/karianna/.m2/repository/org/codehaus/plexus/plexus-velocity/1.1.7/plexus-velocity-1.1.7.jar
> urls[17] =
> file:/Users/karianna/.m2/repository/org/apache/velocity/velocity/1.5/velocity-1.5.jar
> urls[18] = file:/Users/karianna/.m2/repository/oro/oro/2.0.8/oro-2.0.8.jar
> urls[19] =
> file:/Users/karianna/.m2/repository/org/apache/velocity/velocity-tools/2.0/velocity-tools-2.0.jar
> urls[20] =
> file:/Users/karianna/.m2/repository/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar
> urls[21] =
> file:/Users/karianna/.m2/repository/commons-digester/commons-digester/1.8/commons-digester-1.8.jar
> urls[22] =
> file:/Users/karianna/.m2/repository/commons-chain/commons-chain/1.1/commons-chain-1.1.jar
> urls[23] =
> file:/Users/karianna/.m2/repository/sslext/sslext/1.2-0/sslext-1.2-0.jar
> urls[24] =
> file:/Users/karianna/.m2/repository/org/apache/struts/struts-core/1.3.8/struts-core-1.3.8.jar
> urls[25] =
> file:/Users/karianna/.m2/repository/antlr/antlr/2.7.2/antlr-2.7.2.jar
> urls[26] =
> file:/Users/karianna/.m2/repository/org/apache/struts/struts-taglib/1.3.8/struts-taglib-1.3.8.jar
> urls[27] =
> file:/Users/karianna/.m2/repository/org/apache/struts/struts-tiles/1.3.8/struts-tiles-1.3.8.jar
> urls[28] =
> file:/Users/karianna/.m2/repository/commons-collections/commons-collections/3
[jira] [Reopened] (MPMD-238) Execution default-cli of goal org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd failed: A required class was missing while executing org.apache.maven.plugins:maven-pmd-plu
[
https://issues.apache.org/jira/browse/MPMD-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reopened MPMD-238:
-
> Execution default-cli of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd failed: A required class
> was missing while executing
> org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd:
> org/objectweb/asm/ClassVisitor
> --
>
> Key: MPMD-238
> URL: https://issues.apache.org/jira/browse/MPMD-238
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.8
> Environment: Mac OS X 10.12.4, Oracle JDK 1.8.0_131, Apache Maven
> 3.5.0
>Reporter: Martijn Verburg
>Priority: Blocker
> Labels: maven
>
> When running {{mvn pmd:pmd}} on a project the command fails with:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd (default-cli) on
> project jclarity-util: Execution default-cli of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd failed: A required class
> was missing while executing
> org.apache.maven.plugins:maven-pmd-plugin:3.8:pmd:
> org/objectweb/asm/ClassVisitor
> -
> realm =plugin>org.apache.maven.plugins:maven-pmd-plugin:3.8
> strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> urls[0] =
> file:/Users/karianna/.m2/repository/org/apache/maven/plugins/maven-pmd-plugin/3.8/maven-pmd-plugin-3.8.jar
> urls[1] =
> file:/Users/karianna/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
> urls[2] =
> file:/Users/karianna/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
> urls[3] =
> file:/Users/karianna/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> urls[4] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.4/doxia-sink-api-1.4.jar
> urls[5] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.4/doxia-logging-api-1.4.jar
> urls[6] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-decoration-model/1.4/doxia-decoration-model-1.4.jar
> urls[7] =
> file:/Users/karianna/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.6/plexus-component-annotations-1.6.jar
> urls[8] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-site-renderer/1.4/doxia-site-renderer-1.4.jar
> urls[9] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-core/1.4/doxia-core-1.4.jar
> urls[10] =
> file:/Users/karianna/.m2/repository/xerces/xercesImpl/2.9.1/xercesImpl-2.9.1.jar
> urls[11] =
> file:/Users/karianna/.m2/repository/xml-apis/xml-apis/1.3.04/xml-apis-1.3.04.jar
> urls[12] =
> file:/Users/karianna/.m2/repository/commons-lang/commons-lang/2.4/commons-lang-2.4.jar
> urls[13] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-module-xhtml/1.4/doxia-module-xhtml-1.4.jar
> urls[14] =
> file:/Users/karianna/.m2/repository/org/apache/maven/doxia/doxia-module-fml/1.4/doxia-module-fml-1.4.jar
> urls[15] =
> file:/Users/karianna/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-7/plexus-i18n-1.0-beta-7.jar
> urls[16] =
> file:/Users/karianna/.m2/repository/org/codehaus/plexus/plexus-velocity/1.1.7/plexus-velocity-1.1.7.jar
> urls[17] =
> file:/Users/karianna/.m2/repository/org/apache/velocity/velocity/1.5/velocity-1.5.jar
> urls[18] = file:/Users/karianna/.m2/repository/oro/oro/2.0.8/oro-2.0.8.jar
> urls[19] =
> file:/Users/karianna/.m2/repository/org/apache/velocity/velocity-tools/2.0/velocity-tools-2.0.jar
> urls[20] =
> file:/Users/karianna/.m2/repository/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar
> urls[21] =
> file:/Users/karianna/.m2/repository/commons-digester/commons-digester/1.8/commons-digester-1.8.jar
> urls[22] =
> file:/Users/karianna/.m2/repository/commons-chain/commons-chain/1.1/commons-chain-1.1.jar
> urls[23] =
> file:/Users/karianna/.m2/repository/sslext/sslext/1.2-0/sslext-1.2-0.jar
> urls[24] =
> file:/Users/karianna/.m2/repository/org/apache/struts/struts-core/1.3.8/struts-core-1.3.8.jar
> urls[25] =
> file:/Users/karianna/.m2/repository/antlr/antlr/2.7.2/antlr-2.7.2.jar
> urls[26] =
> file:/Users/karianna/.m2/repository/org/apache/struts/struts-taglib/1.3.8/struts-taglib-1.3.8.jar
> urls[27] =
> file:/Users/karianna/.m2/repository/org/apache/struts/struts-tiles/1.3.8/struts-tiles-1.3.8.jar
> urls[28] =
> file:/Users/karianna/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3
