[jira] [Commented] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[ https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16139344#comment-16139344 ] ASF GitHub Bot commented on SUREFIRE-1396: -- Github user jon-bell commented on the issue: https://github.com/apache/maven-surefire/pull/161 @Tibor17 Is there anything else I can do to help get this merged? > Provider class path is incorrect for custom provider in Failsafe > > > Key: SUREFIRE-1396 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1396 > Project: Maven Surefire > Issue Type: Bug >Reporter: Jonathan Bell > > Hi, > When using a custom Surefire provider with Surefire (not Failsafe), the > "provider classpath" contains only the provider and surefire-api. However, > when using a custom provider with Failsafe, the provider class path ends up > including a lot more... it seems like perhaps all plugins that are loaded? > This has caused some mayhem for me when using a custom provider in projects > that use a specific version of SLF4J... because then failsafe forces 1.5.6 to > be loaded (from this process of incorrectly finding the custom provider), > causing a crash. > It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the > Surefire plugin hardcoded, which isn't correct when it's actually Failsafe). > I've got a patched fork of master on GitHub > (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2) > that fixes it and an integration test that demonstrates the flaw. I am not > 100% sure on the formatting of the integration test (i.e., I am opening a > JIRA ticket so that I suppose I can name it under the JIRA issue? How should > I specify the current version of surefire in the integration test package?) - > if the fix is welcome against master I'd be happy to open a PR on GitHub. I > am also happy to merge against a different branch if it's more helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MNG-6233) maven-resolver-provider mixes JRS 330 and Plexus annotations
[ https://issues.apache.org/jira/browse/MNG-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6233. --- > maven-resolver-provider mixes JRS 330 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 >Assignee: Igor Fedorenko > Fix For: 3.5.1 > > > 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.4.14#64029)
[jira] [Commented] (MANTRUN-200) Scriptdef tasks fail to load when running on Java9
[
https://issues.apache.org/jira/browse/MANTRUN-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138732#comment-16138732
]
Robert Scholte commented on MANTRUN-200:
With Classworld it is possible to control the order of ClassLoaders.
Btw, when running the test with Java 8 it fails as well, so it is not J9
specific.
> Scriptdef tasks fail to load when running on Java9
> --
>
> Key: MANTRUN-200
> URL: https://issues.apache.org/jira/browse/MANTRUN-200
> Project: Maven Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Dan Berindei
>
> I have a Maven project using maven-antrun-plugin:
> {code}
>
>
>4.0.0
>my-test-app
>my-test-group
>1.0-SNAPSHOT
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.8
>
>
> compile
> compile
>
>
>
>
>
>
>
>
> run
>
>
>
>
>
>
>
> {code}
> The Ant build file uses a script:
> {code}
>
>
>
>
>
>
>
>
>
> {code}
> On Java 8 it works, but on Java 9 (9-ea+162) it can't find the script engine:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (compile) on
> project my-test-app: An Ant BuildException has occured: The following error
> occurred while executing this line:
> /home/dan/scriptdef-test/build.xml:10: Unable to create javax script engine
> for javascript
> around Ant part .. @ 4:47 in
> /home/dan/scriptdef-test/target/antrun/build-main.xml
> ...
> Caused by: /home/dan/scriptdef-test/build.xml:10: Unable to create javax
> script engine for javascript
> at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:84)
> at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
> at
> org.apache.tools.ant.taskdefs.optional.script.ScriptDef.executeScript(ScriptDef.java:350)
> at
> org.apache.tools.ant.taskdefs.optional.script.ScriptDefBase.execute(ScriptDefBase.java:50)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:547)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:435)
> at org.apache.tools.ant.Target.performTasks(Target.java:456)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:441)
> ... 34 more
> {noformat}
> I have attached a debugger and I saw that the {{ScriptEngineManager}} used by
> {{JavaxScriptRunner}} doesn't have any script engines, because the service
> loader it uses doesn't find any {{ScriptEngineFactory}} implementations. I
> have tried {{\--add-modules jdk.scripting.nashorn}} and {{\--add-opens
> jdk.scripting.nashorn/jdk.nashorn.api.scripting=ALL-UNNAMED}}, but neither
> helped.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MANTRUN-200) Scriptdef tasks fail to load when running on Java9
[
https://issues.apache.org/jira/browse/MANTRUN-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138712#comment-16138712
]
Guillaume Boué commented on MANTRUN-200:
[~rfscholte] Yes, the parent used by ServiceLoader to delegate is returned by
{{getParent()}}, and this is {{null}}. Just considering modules, it means only
services present in modules loaded by the bootstrap classloader are found. I
think Nashorn is loaded with the system classloader in Java 9 (and was
previously loaded with bootstrap classloader). So from what I gathered, passing
the system classloader, instead of {{null}}, in {{world.newRealm( realmId, null
)}} would solve this Jira issue, meaning the Nashorn implementation would be
found (I tested this previously and it really solves it).
But I'm afraid it would just hide another issue: a module loaded by the Maven
core extension classloader still would not be found. For that, I believe you
would need to pass Core Ext classloader as parent in {{world.newRealm( realmId,
null )}}, or even pass whatever {{parent}} was passed to {{createRealm}} in
{{DefaultClassRealmManager}}, but I tested that this has bad consequences for
plugins using the Site Plugin. The problem was that the search for a given
class would now delegate to the parent first and then plugin classloader. In
the case of the Site Plugin, the parent would be the Site Plugin's realm, and
this would mean that it is the classes loaded by maven-site that are found
before the ones of the plugin itself...and this quickly turned into version
conflicts and ClassNotFoundException when the plugin overrides a dependency...
> Scriptdef tasks fail to load when running on Java9
> --
>
> Key: MANTRUN-200
> URL: https://issues.apache.org/jira/browse/MANTRUN-200
> Project: Maven Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Dan Berindei
>
> I have a Maven project using maven-antrun-plugin:
> {code}
>
>
>4.0.0
>my-test-app
>my-test-group
>1.0-SNAPSHOT
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.8
>
>
> compile
> compile
>
>
>
>
>
>
>
>
> run
>
>
>
>
>
>
>
> {code}
> The Ant build file uses a script:
> {code}
>
>
>
>
>
>
>
>
>
> {code}
> On Java 8 it works, but on Java 9 (9-ea+162) it can't find the script engine:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (compile) on
> project my-test-app: An Ant BuildException has occured: The following error
> occurred while executing this line:
> /home/dan/scriptdef-test/build.xml:10: Unable to create javax script engine
> for javascript
> around Ant part .. @ 4:47 in
> /home/dan/scriptdef-test/target/antrun/build-main.xml
> ...
> Caused by: /home/dan/scriptdef-test/build.xml:10: Unable to create javax
> script engine for javascript
> at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:84)
> at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
> at
> org.apache.tools.ant.taskdefs.optional.script.ScriptDef.executeScript(ScriptDef.java:350)
> at
> org.apache.tools.ant.taskdefs.optional.script.ScriptDefBase.execute(ScriptDefBase.java:50)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:547)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:435)
> at org.apache.tools.ant.Target.performTasks(Target.java:456)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:441)
> ... 34 more
> {noformat}
> I
[jira] [Commented] (MANTRUN-200) Scriptdef tasks fail to load when running on Java9
[
https://issues.apache.org/jira/browse/MANTRUN-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138644#comment-16138644
]
Robert Scholte commented on MANTRUN-200:
I think I found an important part of the issue, see
[DefaultClassRealmManager|https://maven.apache.org/ref/3.5.0/maven-core/xref/org/apache/maven/classrealm/DefaultClassRealmManager.html#L123]
{code}
ClassRealm classRealm = world.newRealm( realmId, null );
{code}
Creating a realm like this means calling {{new URLClassLoader( new URL\[0],
null )}}
Converting this to a unittest:
{code}
@Test
public void testLoadClass_ServiceLocator() throws Exception
{
ServiceLoader sef1 = ServiceLoader.load(
ScriptEngineFactory.class );
assertTrue( "ServiceLoader.load( ScriptEngineFactory.class ) failed",
sef1.iterator().hasNext() );
ServiceLoader sef2 = ServiceLoader.load(
ScriptEngineFactory.class, new URLClassLoader( new URL[0] ) );
assertTrue( "ServiceLoader.load( ScriptEngineFactory.class, new
URLClassLoader( new URL[0] ) ) failed", sef2.iterator().hasNext() );
ServiceLoader sef3 = ServiceLoader.load(
ScriptEngineFactory.class, new URLClassLoader( new URL[0], null ) );
assertTrue( "ServiceLoader.load( ScriptEngineFactory.class, new
URLClassLoader( new URL[0], null ) ) failed", sef3.iterator().hasNext() );
}
{code}
With Java 7 it all succeed, with Java the third one fails.
Not sure if this should be considered as regression or if we need to pass
something else ourselves. I'll contact Java 9 devs.
> Scriptdef tasks fail to load when running on Java9
> --
>
> Key: MANTRUN-200
> URL: https://issues.apache.org/jira/browse/MANTRUN-200
> Project: Maven Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Dan Berindei
>
> I have a Maven project using maven-antrun-plugin:
> {code}
>
>
>4.0.0
>my-test-app
>my-test-group
>1.0-SNAPSHOT
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.8
>
>
> compile
> compile
>
>
>
>
>
>
>
>
> run
>
>
>
>
>
>
>
> {code}
> The Ant build file uses a script:
> {code}
>
>
>
>
>
>
>
>
>
> {code}
> On Java 8 it works, but on Java 9 (9-ea+162) it can't find the script engine:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (compile) on
> project my-test-app: An Ant BuildException has occured: The following error
> occurred while executing this line:
> /home/dan/scriptdef-test/build.xml:10: Unable to create javax script engine
> for javascript
> around Ant part .. @ 4:47 in
> /home/dan/scriptdef-test/target/antrun/build-main.xml
> ...
> Caused by: /home/dan/scriptdef-test/build.xml:10: Unable to create javax
> script engine for javascript
> at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:84)
> at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
> at
> org.apache.tools.ant.taskdefs.optional.script.ScriptDef.executeScript(ScriptDef.java:350)
> at
> org.apache.tools.ant.taskdefs.optional.script.ScriptDefBase.execute(ScriptDefBase.java:50)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:547)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:435)
> at org.apache.tools.ant.Target.performTasks(Target.java:456)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:441)
> ... 34 more
> {noformat}
> I have attached a debugger and I saw that the
[jira] [Commented] (MANTRUN-200) Scriptdef tasks fail to load when running on Java9
[
https://issues.apache.org/jira/browse/MANTRUN-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138560#comment-16138560
]
Guillaume Boué commented on MANTRUN-200:
[~rfscholte] The parent class loader in {{ClassRealm}} is indeed correct, the
issue is related to the new way {{ServiceLoader}} looks for services in Java 9
modules: it delegates directly to {{ClassLoader.getParent()}} and this ignores
ClassRealm's {{parentClassLoader}}. This Jira issue was actually the subject of
[that previous mail of
mine|http://mail-archives.apache.org/mod_mbox/maven-dev/201706.mbox/%3C49a731c4-a3ed-83d5-13a7-b0e8ec845ad6%40apache.org%3E].
I haven't got around to work more on this but it'd be great to have insights
of Java 9 devs.
> Scriptdef tasks fail to load when running on Java9
> --
>
> Key: MANTRUN-200
> URL: https://issues.apache.org/jira/browse/MANTRUN-200
> Project: Maven Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Dan Berindei
>
> I have a Maven project using maven-antrun-plugin:
> {code}
>
>
>4.0.0
>my-test-app
>my-test-group
>1.0-SNAPSHOT
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.8
>
>
> compile
> compile
>
>
>
>
>
>
>
>
> run
>
>
>
>
>
>
>
> {code}
> The Ant build file uses a script:
> {code}
>
>
>
>
>
>
>
>
>
> {code}
> On Java 8 it works, but on Java 9 (9-ea+162) it can't find the script engine:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (compile) on
> project my-test-app: An Ant BuildException has occured: The following error
> occurred while executing this line:
> /home/dan/scriptdef-test/build.xml:10: Unable to create javax script engine
> for javascript
> around Ant part .. @ 4:47 in
> /home/dan/scriptdef-test/target/antrun/build-main.xml
> ...
> Caused by: /home/dan/scriptdef-test/build.xml:10: Unable to create javax
> script engine for javascript
> at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:84)
> at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
> at
> org.apache.tools.ant.taskdefs.optional.script.ScriptDef.executeScript(ScriptDef.java:350)
> at
> org.apache.tools.ant.taskdefs.optional.script.ScriptDefBase.execute(ScriptDefBase.java:50)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:547)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:435)
> at org.apache.tools.ant.Target.performTasks(Target.java:456)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:441)
> ... 34 more
> {noformat}
> I have attached a debugger and I saw that the {{ScriptEngineManager}} used by
> {{JavaxScriptRunner}} doesn't have any script engines, because the service
> loader it uses doesn't find any {{ScriptEngineFactory}} implementations. I
> have tried {{\--add-modules jdk.scripting.nashorn}} and {{\--add-opens
> jdk.scripting.nashorn/jdk.nashorn.api.scripting=ALL-UNNAMED}}, but neither
> helped.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MDEPLOY-221) deploy generates wrong timestamps in maven-metadata.xml
[
https://issues.apache.org/jira/browse/MDEPLOY-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138465#comment-16138465
]
Jay mann commented on MDEPLOY-221:
--
This is a MAJOR^10 bug, you guys should at least say something about it on the
maven home page, we've wasted a couple days trying to figure out why our nexus
repo was getting corrupt. Honestly you should prob pull 3.5.0 off the site
until a fix is released.
> deploy generates wrong timestamps in maven-metadata.xml
> ---
>
> Key: MDEPLOY-221
> URL: https://issues.apache.org/jira/browse/MDEPLOY-221
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 2.8.2
>Reporter: Roland Illig
>Assignee: Guillaume Boué
>
> When deploying an artifact to a Nexus server, the file {{maven-metadata.xml}}
> can end up with inconsistent timestamps.
> {noformat}
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 24 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 171 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
> (18 kB at 591 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
> (2.2 kB at 71 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 92 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 92 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 59 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 43 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 33 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 40 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76-sources.jar
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76-sources.jar
> (12 kB at 386 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 92 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 59 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 65 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
>
[jira] [Commented] (MNG-6274) snapshot timestamps of modules in multimodule build are not aligned
[
https://issues.apache.org/jira/browse/MNG-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138464#comment-16138464
]
Jesse Glick commented on MNG-6274:
--
AFAIK this only applies to {{deploy}} (to a remote repository), not {{install}}
(to the local repository).
> snapshot timestamps of modules in multimodule build are not aligned
> ---
>
> Key: MNG-6274
> URL: https://issues.apache.org/jira/browse/MNG-6274
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories, core
>Affects Versions: 3.5.0
>Reporter: James Nord
>
> If you have a multi-module build with SNAPSHOT versions and deploy it to your
> repository all of the modules have different time-stamps.
> This is a pain when you want to refer to many of these snapshots in a
> different project.
> Rather than being able to update a single property to reference the newly
> deployed version you need to make as many changes as the number of the
> dependencies your are using from this project. This is cumbersome and error
> prone.
> It would be much better if all the modules where deployed with the same
> time-stamp if they where part of the same reactor (e.g. the start time of the
> reactor build and not the start time of the module build)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6274) snapshot timestamps of modules in multimodule build are not aligned
[ https://issues.apache.org/jira/browse/MNG-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Nord updated MNG-6274: Description: If you have a multi-module build with SNAPSHOT versions and deploy it to your repository all of the modules have different time-stamps. This is a pain when you want to refer to many of these snapshots in a different project. Rather than being able to update a single property to reference the newly deployed version you need to make as many changes as the number of the dependencies your are using from this project. This is cumbersome and error prone. It would be much better if all the modules where deployed with the same time-stamp if they where part of the same reactor (e.g. the start time of the reactor build and not the start time of the module build) was: If you have a multi-module build with SNAPSHOT versions and either install or deploy it to your local repository all of the modules have different time-stamps. This is a pain when you want to refer to many of these snapshots in a different project. Rather than being able to update a single property to reference the newly deployed version you need to make as many changes as the number of the dependencies your are using from this project. This is cumbersome and error prone. It would be much better if all the modules where deployed with the same time-stamp if they where part of the same reactor (e.g. the start time of the reactor build and not the start time of the module build) > snapshot timestamps of modules in multimodule build are not aligned > --- > > Key: MNG-6274 > URL: https://issues.apache.org/jira/browse/MNG-6274 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, core >Affects Versions: 3.5.0 >Reporter: James Nord > > If you have a multi-module build with SNAPSHOT versions and deploy it to your > repository all of the modules have different time-stamps. > This is a pain when you want to refer to many of these snapshots in a > different project. > Rather than being able to update a single property to reference the newly > deployed version you need to make as many changes as the number of the > dependencies your are using from this project. This is cumbersome and error > prone. > It would be much better if all the modules where deployed with the same > time-stamp if they where part of the same reactor (e.g. the start time of the > reactor build and not the start time of the module build) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6274) snapshot timestamps of modules in multimodule build are not aligned
[ https://issues.apache.org/jira/browse/MNG-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138437#comment-16138437 ] Jesse Glick commented on MNG-6274: -- [Example question about this|https://stackoverflow.com/q/13589893/12916] > snapshot timestamps of modules in multimodule build are not aligned > --- > > Key: MNG-6274 > URL: https://issues.apache.org/jira/browse/MNG-6274 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, core >Affects Versions: 3.5.0 >Reporter: James Nord > > If you have a multi-module build with SNAPSHOT versions and either install or > deploy it to your local repository all of the modules have different > time-stamps. > This is a pain when you want to refer to many of these snapshots in a > different project. > Rather than being able to update a single property to reference the newly > deployed version you need to make as many changes as the number of the > dependencies your are using from this project. This is cumbersome and error > prone. > It would be much better if all the modules where deployed with the same > time-stamp if they where part of the same reactor (e.g. the start time of the > reactor build and not the start time of the module build) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6274) snapshot timestamps of modules in multimodule build are not aligned
[ https://issues.apache.org/jira/browse/MNG-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Nord updated MNG-6274: Description: If you have a multi-module build with SNAPSHOT versions and either install or deploy it to your local repository all of the modules have different time-stamps. This is a pain when you want to refer to many of these snapshots in a different project. Rather than being able to update a single property to reference the newly deployed version you need to make as many changes as the number of the dependencies your are using from this project. This is cumbersome and error prone. It would be much better if all the modules where deployed with the same time-stamp if they where part of the same reactor (e.g. the start time of the reactor build and not the start time of the module build) was: If you have a multi-module build with SNAPSHOT versions and either install or deploy it to your local repository all of the modules have different timestamps. This is a pain when you want to refer to many of these snapshots in a different project. Rather than being able to update a single property to reference the newly deployed version you need to make as many changes as the number of the dependencies your are using from this project. This is cumbersome and error prone. It would be much better if all the modules where dpeployed with the same timestamp if they where part of the same reactor (e.g. the start time of the reactor build and not the start time of the module build) > snapshot timestamps of modules in multimodule build are not aligned > --- > > Key: MNG-6274 > URL: https://issues.apache.org/jira/browse/MNG-6274 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, core >Affects Versions: 3.5.0 >Reporter: James Nord > > If you have a multi-module build with SNAPSHOT versions and either install or > deploy it to your local repository all of the modules have different > time-stamps. > This is a pain when you want to refer to many of these snapshots in a > different project. > Rather than being able to update a single property to reference the newly > deployed version you need to make as many changes as the number of the > dependencies your are using from this project. This is cumbersome and error > prone. > It would be much better if all the modules where deployed with the same > time-stamp if they where part of the same reactor (e.g. the start time of the > reactor build and not the start time of the module build) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6274) snapshot timestamps of modules in multimodule build are not aligned
[ https://issues.apache.org/jira/browse/MNG-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Nord updated MNG-6274: Description: If you have a multi-module build with SNAPSHOT versions and either install or deploy it to your local repository all of the modules have different timestamps. This is a pain when you want to refer to many of these snapshots in a different project. Rather than being able to update a single property to reference the newly deployed version you need to make as many changes as the number of the dependencies your are using from this project. This is cumbersome and error prone. It would be much better if all the modules where dpeployed with the same timestamp if they where part of the same reactor (e.g. the start time of the reactor build and not the start time of the module build) was: If you have a multi-module build with SNAPSHOT versions and either install or delpoy it to your local repository all of the modules have different timestampts. This is a pain when you want to refer to many of these snapshots in a different project. Rather than being able to update a single property to reference the newly deployed version you need to make as many changes as the number of the dependencies your are using from this project. This is cumbersome and error prone. It would be much better if all the modules where dpeployed with the same timestamp if they where part of the same reactor (e.g. the start time of the reactor build and not the start time of the module build) > snapshot timestamps of modules in multimodule build are not aligned > --- > > Key: MNG-6274 > URL: https://issues.apache.org/jira/browse/MNG-6274 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, core >Affects Versions: 3.5.0 >Reporter: James Nord > > If you have a multi-module build with SNAPSHOT versions and either install or > deploy it to your local repository all of the modules have different > timestamps. > This is a pain when you want to refer to many of these snapshots in a > different project. > Rather than being able to update a single property to reference the newly > deployed version you need to make as many changes as the number of the > dependencies your are using from this project. This is cumbersome and error > prone. > It would be much better if all the modules where dpeployed with the same > timestamp if they where part of the same reactor (e.g. the start time of the > reactor build and not the start time of the module build) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MNG-6274) snapshot timestamps of modules in multimodule build are not aligned
James Nord created MNG-6274: --- Summary: snapshot timestamps of modules in multimodule build are not aligned Key: MNG-6274 URL: https://issues.apache.org/jira/browse/MNG-6274 Project: Maven Issue Type: Improvement Components: Artifacts and Repositories, core Affects Versions: 3.5.0 Reporter: James Nord If you have a multi-module build with SNAPSHOT versions and either install or delpoy it to your local repository all of the modules have different timestampts. This is a pain when you want to refer to many of these snapshots in a different project. Rather than being able to update a single property to reference the newly deployed version you need to make as many changes as the number of the dependencies your are using from this project. This is cumbersome and error prone. It would be much better if all the modules where dpeployed with the same timestamp if they where part of the same reactor (e.g. the start time of the reactor build and not the start time of the module build) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6255) Maven script cannot parse jvm.config with CRLF
[
https://issues.apache.org/jira/browse/MNG-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138161#comment-16138161
]
ASF GitHub Bot commented on MNG-6255:
-
Github user grkvlt commented on the issue:
https://github.com/apache/maven/pull/127
ping?
> Maven script cannot parse jvm.config with CRLF
> --
>
> Key: MNG-6255
> URL: https://issues.apache.org/jira/browse/MNG-6255
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 7 with MINGW64 environment via Git for Windows
> 0.1.1 including GNU coreutils and bash 4.4.12
>Reporter: Andrew Kennedy
>
> A project with a {{.mvn/jvm.config}} file that has *CRLF* line endings will
> not parse it correctly. The script uses the {{tr}} command to change *LF* to
> space, but this leaves *CR* behind. For example, with the {{jvm.config}} file
> containing the text {{-Xmx1024m -Xms512m}} followed by *CRLF*, the following
> error message is printed:
> {code}
> $ mvn install
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Invalid initial heap size: -Xms512m
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MPLUGIN-324) javadoc generated by helpmojo goal of maven-plugin-plugin produces build failures
[
https://issues.apache.org/jira/browse/MPLUGIN-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138105#comment-16138105
]
Christoph Lembeck edited comment on MPLUGIN-324 at 8/23/17 9:03 AM:
The javadoc-plugin only fails, if yo configure it to show the private members
too:
{code}
org.apache.maven.plugins
maven-javadoc-plugin
private
attach-javadocs
jar
{code}
was (Author: chrlembeck):
The javadoc-plugin only fails, if yo configure it to show the private members
too:
{code}
org.apache.maven.plugins
maven-javadoc-plugin
private
attach-javadocs
jar
{code}
> javadoc generated by helpmojo goal of maven-plugin-plugin produces build
> failures
> -
>
> Key: MPLUGIN-324
> URL: https://issues.apache.org/jira/browse/MPLUGIN-324
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.5
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
> Java version: 1.8.0_131, vendor: Oracle Corporation
>Reporter: Christoph Lembeck
>
> In our project we use the {{helpmojo}} goal of the {{maven-plugin-plugin}} to
> generate a HelpMojo class.
> Unfortunately the maven-javadoc-plugin fails to process that generated file
> because the generated javadoc comments contain the illegal symbol '{{<}}'.
> Here is the error message:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.0.0-M1:jar (attach-javadocs)
> on project codegen-maven-plugin: MavenReportException: Error while generating
> Javadoc:
> [ERROR] Exit code: 1 -
> D:\eclipse\codegen\codegen-maven-plugin\target\generated-sources\plugin\de\chrlembeck\codegen\HelpMojo.java:354:
> error: malformed HTML
> [ERROR] * @throws NegativeArraySizeException if indent < 0
> [ERROR] ^
> {code}
> And this is the generated output, that fails:
> {code}
> /**
> * Splits the specified text into lines of convenient display length.
> *
> * @param text The text to split into lines, must not be
> null.
> * @param indent The base indentation level of each line, must not be
> negative.
> * @param indentSize The size of each indentation, must not be negative.
> * @param lineLength The length of the line, must not be negative.
> * @return The sequence of display lines, never null.
> * @throws NegativeArraySizeException if indent < 0
> */
> private static List toLines( String text, int indent, int
> indentSize, int lineLength )
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MPLUGIN-324) javadoc generated by helpmojo goal of maven-plugin-plugin produces build failures
[
https://issues.apache.org/jira/browse/MPLUGIN-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138105#comment-16138105
]
Christoph Lembeck commented on MPLUGIN-324:
---
The javadoc-plugin only fails, if yo configure it to show the private members
too:
{code}
org.apache.maven.plugins
maven-javadoc-plugin
private
attach-javadocs
jar
{code}
> javadoc generated by helpmojo goal of maven-plugin-plugin produces build
> failures
> -
>
> Key: MPLUGIN-324
> URL: https://issues.apache.org/jira/browse/MPLUGIN-324
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.5
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
> Java version: 1.8.0_131, vendor: Oracle Corporation
>Reporter: Christoph Lembeck
>
> In our project we use the {{helpmojo}} goal of the {{maven-plugin-plugin}} to
> generate a HelpMojo class.
> Unfortunately the maven-javadoc-plugin fails to process that generated file
> because the generated javadoc comments contain the illegal symbol '{{<}}'.
> Here is the error message:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.0.0-M1:jar (attach-javadocs)
> on project codegen-maven-plugin: MavenReportException: Error while generating
> Javadoc:
> [ERROR] Exit code: 1 -
> D:\eclipse\codegen\codegen-maven-plugin\target\generated-sources\plugin\de\chrlembeck\codegen\HelpMojo.java:354:
> error: malformed HTML
> [ERROR] * @throws NegativeArraySizeException if indent < 0
> [ERROR] ^
> {code}
> And this is the generated output, that fails:
> {code}
> /**
> * Splits the specified text into lines of convenient display length.
> *
> * @param text The text to split into lines, must not be
> null.
> * @param indent The base indentation level of each line, must not be
> negative.
> * @param indentSize The size of each indentation, must not be negative.
> * @param lineLength The length of the line, must not be negative.
> * @return The sequence of display lines, never null.
> * @throws NegativeArraySizeException if indent < 0
> */
> private static List toLines( String text, int indent, int
> indentSize, int lineLength )
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MPLUGIN-324) javadoc generated by helpmojo goal of maven-plugin-plugin produces build failures
Christoph Lembeck created MPLUGIN-324:
-
Summary: javadoc generated by helpmojo goal of maven-plugin-plugin
produces build failures
Key: MPLUGIN-324
URL: https://issues.apache.org/jira/browse/MPLUGIN-324
Project: Maven Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Affects Versions: 3.5
Environment: Apache Maven 3.5.0
(ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
Java version: 1.8.0_131, vendor: Oracle Corporation
Reporter: Christoph Lembeck
In out project we use the {{helpmojo}} goal of the {{maven-plugin-plugin}} to
generate a HelpMojo class.
Unfortunately the maven-javadoc-plugin fails to process that generated file
because the generated javadoc comments contain the illegal symbol '{{<}}'.
Here is the error message:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.0.0-M1:jar (attach-javadocs) on
project codegen-maven-plugin: MavenReportException: Error while generating
Javadoc:
[ERROR] Exit code: 1 -
D:\eclipse\codegen\codegen-maven-plugin\target\generated-sources\plugin\de\chrlembeck\codegen\HelpMojo.java:354:
error: malformed HTML
[ERROR] * @throws NegativeArraySizeException if indent < 0
[ERROR] ^
{code}
And this is the generated output, that fails:
{code}
/**
* Splits the specified text into lines of convenient display length.
*
* @param text The text to split into lines, must not be
null.
* @param indent The base indentation level of each line, must not be
negative.
* @param indentSize The size of each indentation, must not be negative.
* @param lineLength The length of the line, must not be negative.
* @return The sequence of display lines, never null.
* @throws NegativeArraySizeException if indent < 0
*/
private static List toLines( String text, int indent, int
indentSize, int lineLength )
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MPLUGIN-324) javadoc generated by helpmojo goal of maven-plugin-plugin produces build failures
[
https://issues.apache.org/jira/browse/MPLUGIN-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Lembeck updated MPLUGIN-324:
--
Description:
In our project we use the {{helpmojo}} goal of the {{maven-plugin-plugin}} to
generate a HelpMojo class.
Unfortunately the maven-javadoc-plugin fails to process that generated file
because the generated javadoc comments contain the illegal symbol '{{<}}'.
Here is the error message:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.0.0-M1:jar (attach-javadocs) on
project codegen-maven-plugin: MavenReportException: Error while generating
Javadoc:
[ERROR] Exit code: 1 -
D:\eclipse\codegen\codegen-maven-plugin\target\generated-sources\plugin\de\chrlembeck\codegen\HelpMojo.java:354:
error: malformed HTML
[ERROR] * @throws NegativeArraySizeException if indent < 0
[ERROR] ^
{code}
And this is the generated output, that fails:
{code}
/**
* Splits the specified text into lines of convenient display length.
*
* @param text The text to split into lines, must not be
null.
* @param indent The base indentation level of each line, must not be
negative.
* @param indentSize The size of each indentation, must not be negative.
* @param lineLength The length of the line, must not be negative.
* @return The sequence of display lines, never null.
* @throws NegativeArraySizeException if indent < 0
*/
private static List toLines( String text, int indent, int
indentSize, int lineLength )
{code}
was:
In out project we use the {{helpmojo}} goal of the {{maven-plugin-plugin}} to
generate a HelpMojo class.
Unfortunately the maven-javadoc-plugin fails to process that generated file
because the generated javadoc comments contain the illegal symbol '{{<}}'.
Here is the error message:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.0.0-M1:jar (attach-javadocs) on
project codegen-maven-plugin: MavenReportException: Error while generating
Javadoc:
[ERROR] Exit code: 1 -
D:\eclipse\codegen\codegen-maven-plugin\target\generated-sources\plugin\de\chrlembeck\codegen\HelpMojo.java:354:
error: malformed HTML
[ERROR] * @throws NegativeArraySizeException if indent < 0
[ERROR] ^
{code}
And this is the generated output, that fails:
{code}
/**
* Splits the specified text into lines of convenient display length.
*
* @param text The text to split into lines, must not be
null.
* @param indent The base indentation level of each line, must not be
negative.
* @param indentSize The size of each indentation, must not be negative.
* @param lineLength The length of the line, must not be negative.
* @return The sequence of display lines, never null.
* @throws NegativeArraySizeException if indent < 0
*/
private static List toLines( String text, int indent, int
indentSize, int lineLength )
{code}
> javadoc generated by helpmojo goal of maven-plugin-plugin produces build
> failures
> -
>
> Key: MPLUGIN-324
> URL: https://issues.apache.org/jira/browse/MPLUGIN-324
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.5
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
> Java version: 1.8.0_131, vendor: Oracle Corporation
>Reporter: Christoph Lembeck
>
> In our project we use the {{helpmojo}} goal of the {{maven-plugin-plugin}} to
> generate a HelpMojo class.
> Unfortunately the maven-javadoc-plugin fails to process that generated file
> because the generated javadoc comments contain the illegal symbol '{{<}}'.
> Here is the error message:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.0.0-M1:jar (attach-javadocs)
> on project codegen-maven-plugin: MavenReportException: Error while generating
> Javadoc:
> [ERROR] Exit code: 1 -
> D:\eclipse\codegen\codegen-maven-plugin\target\generated-sources\plugin\de\chrlembeck\codegen\HelpMojo.java:354:
> error: malformed HTML
> [ERROR] * @throws NegativeArraySizeException if indent < 0
> [ERROR] ^
> {code}
> And this is the generated output, that fails:
> {code}
> /**
> * Splits the specified text into lines of convenient display length.
> *
> * @param text The text to split into lines, must not be
> null.
> * @param indent The base indentation level of each line, must not be
>
[jira] [Created] (MSHADE-259) Shade plugin attaches the test jar which causes it deployed twice during release of project
Niraj Agarwal created MSHADE-259:
Summary: Shade plugin attaches the test jar which causes it
deployed twice during release of project
Key: MSHADE-259
URL: https://issues.apache.org/jira/browse/MSHADE-259
Project: Maven Shade Plugin
Issue Type: Bug
Affects Versions: 3.1.0
Reporter: Niraj Agarwal
When using shade plugin to relocate the packages of a dependency for an
application maven project for main artifact as well as test jar (using option
shadeTestJar), it attaches the test-jar using {{projectHelper.attachArtifact(
project, "jar", "tests", shadedTests )}}, this causes the duplicate entry of
test artifact which causes issues (build failure) during release as
maven-deploy-plugin tries to deploy the test-jar twice to nexus which causes
the 2nd deploy fail.
To shade the test jar I need to add {{maven-jar-plugin}} with goal {{test-jar}}
so that a test jar is created which then can be used by shade plugin to perform
the shading and relocation of packages in the test jar. {{maven-jar-plugin}}
itself also attaches the test-jar artifact.
Here is the section of the pom.xml file which was used to create the test-jar,
shade it and then deploy it.
{code}
org.apache.maven.plugins
maven-jar-plugin
3.0.2
package
test-jar
org.apache.maven.plugins
maven-shade-plugin
3.1.0
package
shade
true
false
false
false
com.google.code.gson:gson
com.google.gson
io.sample.shaded.com.google.gson
org.apache.maven.plugins
maven-deploy-plugin
2.8.2
true
{code}
Here is the issue/logs captured during release of application project
{code}
# maven-jar-plugin attaches following test artifact to maven project
artifact:io.sample:sample-app:test-jar:tests:1.0.0
# maven-shade-plugin attaches following test artifact to maven project
artifact:io.sample:sample-app:jar:tests:1.0.0
# maven-deploy-plugin tries to deploy the above 2 test artifacts to nexus and
fails on 2nd deploy
[INFO] [INFO] Uploading:
http://maven-nexus.mycompany.com/nexus/content/repositories/releases/io/sample/sample-app/1.0.0/sample-app-1.0.0-tests.jar
[INFO] [INFO] Uploaded:
http://maven-nexus.mycompany.com/nexus/content/repositories/releases/io/sample/sample-app/1.0.0/sample-app-1.0.0-tests.jar
(233 KB at 3412.8 KB/sec)
[INFO] [INFO] Uploading:
http://maven-nexus.mycompany.com/nexus/content/repositories/releases/io/sample/sample-app/1.0.0/sample-app-1.0.0-tests.jar
[INFO] [INFO]
[INFO] [INFO] Reactor Summary:
[INFO] [INFO]
[INFO] [INFO] sample-app FAILURE [ 5.283 s]
[INFO] [INFO]
[INFO] [INFO] BUILD FAILURE
[INFO] [INFO]
[INFO] [INFO] Total time: 05:01 min
[INFO] [INFO] Finished at: 2017-08-23T22:13:55+00:00
[INFO] [INFO] Final Memory: 160M/1167M
[INFO] [INFO]
[INFO] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
project sample-app: Failed to deploy artifacts: Could not transfer artifact
io.sample:sample-app:jar:tests:1.0.0 from/to releases
(http://maven-nexus.mycompany.com/nexus/content/repositories/releases): Failed
to transfer file:
http://maven-nexus.mycompany.com/nexus/content/repositories/releases/io/sample/sample-app/1.0.0/sample-app-1.0.0-tests.jar.
Return code is: 400, ReasonPhrase: Bad Request. -> [Help 1]
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1264) Some tests can be lost when running in parallel with parameterized tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16137983#comment-16137983
]
Valentin Baranov commented on SUREFIRE-1264:
[~tibor17], unfortunately, I had no time for this during past few days :(
> Some tests can be lost when running in parallel with parameterized tests
>
>
> Key: SUREFIRE-1264
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1264
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.19.1
> Environment: Maven 3.3.9
> Java 1.8.0_45 (Oracle)
> System: OS X
> Reproduced on Linux too, with both OpenJDK 7 and Java 7 from Oracle.
>Reporter: Jean-Luc Derrien
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: failure-2.21-snapshot-SUREFIRE-1264.zip, pom.xml
>
>
> Hello,
> It appears some tests can be lost when using the parallel mode with
> parameterized tests. Here is a [small
> project|https://github.com/jderrien/surefire-junit-tests/tree/simple-1] I've
> used to try to reproduce the issue we have seen.
> This is not something that happens on every run, but it's quite frequent.
> With this loop, the problem should appear in less than 2 minutes, maybe on
> the first run when (un)lucky:
> {code}
> time while true; do mvn clean test > last.log ; tail -25 last.log ; if [
> "$(grep -c 'Tests run: 12' last.log)" == "0" ]; then break; fi ; done
> {code}
> Normal run:
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => stop
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.006 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec -
> in [p2]
> Results :
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> When tests have been lost (here one test lost according to the output):
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec -
> in [p2]
> Results :
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Note: there are 3 test classes and 18 tests on the [master
> branch|https://github.com/jderrien/surefire-junit-tests/tree/master] and it's
> even more frequent/easy to reproduce.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
