[jira] [Updated] (MDEP-620) mvn dependency:unpack via CLI generates ${project.basedir} folder
[
https://issues.apache.org/jira/browse/MDEP-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dimitri R updated MDEP-620:
---
Description:
h3. Steps to reproduce
1. Get a sample dependency first
{noformat}
mvn dependency:get -DgroupId=org.apache.ant -DartifactId=ant -Dversion=1.8.3
-Dpackaging=jar
{noformat}
2. Delete the file
*~/.m2/repository/org/apache/ant/ant/1.8.3/_remote.repositories*
3. Unpack the dependency somewhere
{noformat}
cd /tmp
mkdir unpack
mvn dependency:unpack -Dartifact=org.apache.ant:ant:1.8.3:jar
-DoutputDirectory=./unpack
{noformat}
4. Observe that *${project.basedir}* was created
{noformat}
$ ls -l /tmp/unpack
total 0
... ${project.basedir}
... unpack
{noformat}
*_Note_* Step 2 is only necessary because of _getting_ the dependency, this
wouldn't have to be done if it had been _installed_. This doesn't affect
whether the bug occurs or not.
h3. Workarounds
The closest would be to use {{mvn dependency:copy}} and _then_ unpack manually
through a subsequent command. Interestingly this shows that the bug doesn't
affect {{mvn dependency:copy}}.
Similar/related issues (their fixes don't apply here):
- [https://stackoverflow.com/q/11669446/321797]
- [https://netbeans.org/bugzilla/show_bug.cgi?id=221560]
was:
h3. Steps to reproduce
1. Get a sample dependency first
{noformat}
mvn dependency:get -DgroupId=org.apache.ant -DartifactId=ant -Dversion=1.8.3
-Dpackaging=jar
{noformat}
2. Delete the file
*~/.m2/repository/org/apache/ant/ant/1.8.3/_remote.repositories*
3. Unpack the dependency somewhere
{noformat}
cd /tmp
mkdir unpack
mvn dependency:unpack -Dartifact=org.apache.ant:ant:1.8.3:jar
-DoutputDirectory=./unpack
{noformat}
4. Observe that *${project.basedir}* was created
{noformat}
$ ls -l /tmp/unpack
total 0
... ${project.basedir}
... unpack
{noformat}
*_Note_* Step 2 is only necessary because of _getting_ the dependency, this
wouldn't have to be done if it had been _installed_. This doesn't affect
whether the bug occurs or not.
Similar/related issues (their fixes don't apply here):
- [https://stackoverflow.com/q/11669446/321797]
- [https://netbeans.org/bugzilla/show_bug.cgi?id=221560]
> mvn dependency:unpack via CLI generates ${project.basedir} folder
> -
>
> Key: MDEP-620
> URL: https://issues.apache.org/jira/browse/MDEP-620
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack
> Environment: * Maven 3.5.3
> * CLI
> * macOS and CentOS
>Reporter: Dimitri R
>Priority: Major
>
> h3. Steps to reproduce
> 1. Get a sample dependency first
> {noformat}
> mvn dependency:get -DgroupId=org.apache.ant -DartifactId=ant -Dversion=1.8.3
> -Dpackaging=jar
> {noformat}
> 2. Delete the file
> *~/.m2/repository/org/apache/ant/ant/1.8.3/_remote.repositories*
> 3. Unpack the dependency somewhere
> {noformat}
> cd /tmp
> mkdir unpack
> mvn dependency:unpack -Dartifact=org.apache.ant:ant:1.8.3:jar
> -DoutputDirectory=./unpack
> {noformat}
> 4. Observe that *${project.basedir}* was created
> {noformat}
> $ ls -l /tmp/unpack
> total 0
> ... ${project.basedir}
> ... unpack
> {noformat}
> *_Note_* Step 2 is only necessary because of _getting_ the dependency, this
> wouldn't have to be done if it had been _installed_. This doesn't affect
> whether the bug occurs or not.
> h3. Workarounds
> The closest would be to use {{mvn dependency:copy}} and _then_ unpack
> manually through a subsequent command. Interestingly this shows that the bug
> doesn't affect {{mvn dependency:copy}}.
>
> Similar/related issues (their fixes don't apply here):
> - [https://stackoverflow.com/q/11669446/321797]
> - [https://netbeans.org/bugzilla/show_bug.cgi?id=221560]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MDEP-620) mvn dependency:unpack via CLI generates ${project.basedir} folder
[
https://issues.apache.org/jira/browse/MDEP-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dimitri R updated MDEP-620:
---
Environment:
* Maven 3.5.3
* CLI
* macOS and CentOS
was:
* Maven 3.5.3
* CLI
* macOS and Debian
> mvn dependency:unpack via CLI generates ${project.basedir} folder
> -
>
> Key: MDEP-620
> URL: https://issues.apache.org/jira/browse/MDEP-620
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack
> Environment: * Maven 3.5.3
> * CLI
> * macOS and CentOS
>Reporter: Dimitri R
>Priority: Major
>
> h3. Steps to reproduce
> 1. Get a sample dependency first
> {noformat}
> mvn dependency:get -DgroupId=org.apache.ant -DartifactId=ant -Dversion=1.8.3
> -Dpackaging=jar
> {noformat}
> 2. Delete the file
> *~/.m2/repository/org/apache/ant/ant/1.8.3/_remote.repositories*
> 3. Unpack the dependency somewhere
> {noformat}
> cd /tmp
> mkdir unpack
> mvn dependency:unpack -Dartifact=org.apache.ant:ant:1.8.3:jar
> -DoutputDirectory=./unpack
> {noformat}
> 4. Observe that *${project.basedir}* was created
> {noformat}
> $ ls -l /tmp/unpack
> total 0
> ... ${project.basedir}
> ... unpack
> {noformat}
> *_Note_* Step 2 is only necessary because of _getting_ the dependency, this
> wouldn't have to be done if it had been _installed_. This doesn't affect
> whether the bug occurs or not.
>
> Similar/related issues (their fixes don't apply here):
> - [https://stackoverflow.com/q/11669446/321797]
> - [https://netbeans.org/bugzilla/show_bug.cgi?id=221560]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MDEP-620) mvn dependency:unpack via CLI generates ${project.basedir} folder
Dimitri R created MDEP-620:
--
Summary: mvn dependency:unpack via CLI generates
${project.basedir} folder
Key: MDEP-620
URL: https://issues.apache.org/jira/browse/MDEP-620
Project: Maven Dependency Plugin
Issue Type: Bug
Components: unpack
Environment: * Maven 3.5.3
* CLI
* macOS and Debian
Reporter: Dimitri R
h3. Steps to reproduce
1. Get a sample dependency first
{noformat}
mvn dependency:get -DgroupId=org.apache.ant -DartifactId=ant -Dversion=1.8.3
-Dpackaging=jar
{noformat}
2. Delete the file
*~/.m2/repository/org/apache/ant/ant/1.8.3/_remote.repositories*
3. Unpack the dependency somewhere
{noformat}
cd /tmp
mkdir unpack
mvn dependency:unpack -Dartifact=org.apache.ant:ant:1.8.3:jar
-DoutputDirectory=./unpack
{noformat}
4. Observe that *${project.basedir}* was created
{noformat}
$ ls -l /tmp/unpack
total 0
... ${project.basedir}
... unpack
{noformat}
*_Note_* Step 2 is only necessary because of _getting_ the dependency, this
wouldn't have to be done if it had been _installed_. This doesn't affect
whether the bug occurs or not.
Similar/related issues (their fixes don't apply here):
- [https://stackoverflow.com/q/11669446/321797]
- [https://netbeans.org/bugzilla/show_bug.cgi?id=221560]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6425) Maven inserts incorrect version metadata when 'artifactory matrix parameters' are used.
[
https://issues.apache.org/jira/browse/MNG-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510273#comment-16510273
]
Michael Osipov commented on MNG-6425:
-
Alright, will wait for your test.
> Maven inserts incorrect version metadata when 'artifactory matrix parameters'
> are used.
> ---
>
> Key: MNG-6425
> URL: https://issues.apache.org/jira/browse/MNG-6425
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.5.3
> Environment: Linux, Windows
>Reporter: George Lianeris
>Priority: Major
> Attachments: MNG-6425-wirelog-full.log, MNG-6425-wirelog.log,
> MNG-6425.log
>
>
> When using artifactory matrix parameters as per
> [Artifactory Matrix
> Parameters|https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution#UsingPropertiesinDeploymentandResolution-IntroducingMatrixParameters]
> and they are added to the command line like so:
> mvn -Psomeprofile package deploy:deploy
> -DaltDeploymentRepository=central::default::[https://artifactory.my.co/artifactory/myco-dev;artifactory.licenses=myco]
> The metadata.xml for the artifact (not the version beneath it) acquires
> incorrectly calculated version values on the *second* run.
> What it should be:
> {code:xml}
>
>
> com.myco.foo
> bar
>
>
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> What it is (more or less):
> {code:xml}
>
>
> com.myco.foo
> bar
>
> *1.0.0*
> *1.0.0*
>
> *1.0.0*
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> Note that version 1.0.0 does not exist and was never built. This makes it
> impossible to use the artifactory matrix parameters.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6425) Maven inserts incorrect version metadata when 'artifactory matrix parameters' are used.
[
https://issues.apache.org/jira/browse/MNG-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510266#comment-16510266
]
George Lianeris commented on MNG-6425:
--
So, there are NO release versions of this artifact at all. I never built any,
and they don't exist anywhere except for the metadata.
Please keep in mind that the very first upload generates a correct-ish file,
without the latest/release tags.
I agree that this is very fishy - these versions are coming seemingly from
nowhere. I agree that this may be an artifactory bug, but I don't know how to
diagnose this. If artifactory is serving up an incorrect file that would
explain things: 1.0.4 is already 'latest'.
I will run another trial tomorrow, specifically so we can see when '1.0.5'
decides to appear - however, I am quite certain that the previous version of
this metadata simply lacked any reference to version 1.0.4 whatsoever - that
snapshot was created only when I manually changed the POM version and pushed it
to the build system.
The fact that we have a 'get' which already provides an incorrect file makes
it look like this is an artifactory bug to me.
> Maven inserts incorrect version metadata when 'artifactory matrix parameters'
> are used.
> ---
>
> Key: MNG-6425
> URL: https://issues.apache.org/jira/browse/MNG-6425
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.5.3
> Environment: Linux, Windows
>Reporter: George Lianeris
>Priority: Major
> Attachments: MNG-6425-wirelog-full.log, MNG-6425-wirelog.log,
> MNG-6425.log
>
>
> When using artifactory matrix parameters as per
> [Artifactory Matrix
> Parameters|https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution#UsingPropertiesinDeploymentandResolution-IntroducingMatrixParameters]
> and they are added to the command line like so:
> mvn -Psomeprofile package deploy:deploy
> -DaltDeploymentRepository=central::default::[https://artifactory.my.co/artifactory/myco-dev;artifactory.licenses=myco]
> The metadata.xml for the artifact (not the version beneath it) acquires
> incorrectly calculated version values on the *second* run.
> What it should be:
> {code:xml}
>
>
> com.myco.foo
> bar
>
>
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> What it is (more or less):
> {code:xml}
>
>
> com.myco.foo
> bar
>
> *1.0.0*
> *1.0.0*
>
> *1.0.0*
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> Note that version 1.0.0 does not exist and was never built. This makes it
> impossible to use the artifactory matrix parameters.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6425) Maven inserts incorrect version metadata when 'artifactory matrix parameters' are used.
[
https://issues.apache.org/jira/browse/MNG-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510229#comment-16510229
]
Michael Osipov commented on MNG-6425:
-
Something if fishy about your metadata: look at line 1968:
{{[DEBUG] http-outgoing-1 >> "GET
/artifactory/myco-unrestricted-dev;artifactory.licenses=myco/com/myco/idsys/test/library1/maven-metadata.xml
HTTP/1.1[\r][\n]"}} with the content
{code:xml}
[DEBUG] http-outgoing-1 << "[\n]"
[DEBUG] http-outgoing-1 << "[\n]"
[DEBUG] http-outgoing-1 << " com.myco.idsys.test[\n]"
[DEBUG] http-outgoing-1 << " library1[\n]"
[DEBUG] http-outgoing-1 << " 1.0.0[\n]"
[DEBUG] http-outgoing-1 << " [\n]"
[DEBUG] http-outgoing-1 << "1.0.4[\n]"
[DEBUG] http-outgoing-1 << "1.0.4[\n]"
[DEBUG] http-outgoing-1 << "[\n]"
[DEBUG] http-outgoing-1 << " 1.0.0[\n]"
[DEBUG] http-outgoing-1 << " 1.0.1[\n]"
[DEBUG] http-outgoing-1 << " 1.0.2[\n]"
[DEBUG] http-outgoing-1 << " 1.0.3[\n]"
[DEBUG] http-outgoing-1 << " 1.0.4[\n]"
[DEBUG] http-outgoing-1 << "[\n]"
[DEBUG] http-outgoing-1 << "20180612142911[\n]"
[DEBUG] http-outgoing-1 << " [\n]"
[DEBUG] http-outgoing-1 << "[\n]"
{code}
but you are uploading version 1.0.4-SNAPSHOT. Now line 2316
{{[DEBUG] http-outgoing-1 >> PUT
/artifactory/myco-unrestricted-dev;artifactory.licenses=myco/com/myco/idsys/test/library1/maven-metadata.xml
HTTP/1.1}}
with
{code:xml}
[DEBUG] http-outgoing-1 >> "[\n]"
[DEBUG] http-outgoing-1 >> "[\n]"
[DEBUG] http-outgoing-1 >> " com.myco.idsys.test[\n]"
[DEBUG] http-outgoing-1 >> " library1[\n]"
[DEBUG] http-outgoing-1 >> " [\n]"
[DEBUG] http-outgoing-1 >> "1.0.4[\n]"
[DEBUG] http-outgoing-1 >> "1.0.4[\n]"
[DEBUG] http-outgoing-1 >> "[\n]"
[DEBUG] http-outgoing-1 >> " 1.0.0[\n]"
[DEBUG] http-outgoing-1 >> " 1.0.1[\n]"
[DEBUG] http-outgoing-1 >> " 1.0.2[\n]"
[DEBUG] http-outgoing-1 >> " 1.0.3[\n]"
[DEBUG] http-outgoing-1 >> " 1.0.4[\n]"
[DEBUG] http-outgoing-1 >> " 1.0.4-SNAPSHOT[\n]"
[DEBUG] http-outgoing-1 >> "[\n]"
[DEBUG] http-outgoing-1 >> "20180612142913[\n]"
[DEBUG] http-outgoing-1 >> " [\n]"
[DEBUG] http-outgoing-1 >> "[\n]"
{code}
Why is 1.0.4 released you are uploading 1.0.4-SNAPSHOT? Where do the versions
come from? Have you tried to refresh metadata in Arifactory? This does work in
Nexus, for instance.
> Maven inserts incorrect version metadata when 'artifactory matrix parameters'
> are used.
> ---
>
> Key: MNG-6425
> URL: https://issues.apache.org/jira/browse/MNG-6425
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.5.3
> Environment: Linux, Windows
>Reporter: George Lianeris
>Priority: Major
> Attachments: MNG-6425-wirelog-full.log, MNG-6425-wirelog.log,
> MNG-6425.log
>
>
> When using artifactory matrix parameters as per
> [Artifactory Matrix
> Parameters|https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution#UsingPropertiesinDeploymentandResolution-IntroducingMatrixParameters]
> and they are added to the command line like so:
> mvn -Psomeprofile package deploy:deploy
> -DaltDeploymentRepository=central::default::[https://artifactory.my.co/artifactory/myco-dev;artifactory.licenses=myco]
> The metadata.xml for the artifact (not the version beneath it) acquires
> incorrectly calculated version values on the *second* run.
> What it should be:
> {code:xml}
>
>
> com.myco.foo
> bar
>
>
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> What it is (more or less):
> {code:xml}
>
>
> com.myco.foo
> bar
>
> *1.0.0*
> *1.0.0*
>
> *1.0.0*
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> Note that version 1.0.0 does not exist and was never built. This makes it
> impossible to use the artifactory matrix parameters.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHADE-289) Maven Shade Plugin does not work under Java 10
[
https://issues.apache.org/jira/browse/MSHADE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510200#comment-16510200
]
Michael Osipov commented on MSHADE-289:
---
This happens with other plugins as well. ASM has to be upgraded.
> Maven Shade Plugin does not work under Java 10
> --
>
> Key: MSHADE-289
> URL: https://issues.apache.org/jira/browse/MSHADE-289
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Philip Aston
>Priority: Major
>
> I'm seeing the same symptoms as MSHADE-275 but with 3.1.1.
> My build works with Java 9, but Java 10 gives:
>
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-shade-plugin:3.1.1:shade (default) on project
> client-bootstrap: Error creating shaded jar: null: IllegalArgumentException
> -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-shade-plugin:3.1.1:shade (default) on
> project client-bootstrap: Error creating shaded jar: null
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> 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:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:564)
> 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:546)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> 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:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:564)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
>
[jira] [Closed] (SCM-890) scm-provider-gitexe do not find the repository on latest version
[
https://issues.apache.org/jira/browse/SCM-890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed SCM-890.
--
Resolution: Not A Problem
Assignee: Robert Scholte
> scm-provider-gitexe do not find the repository on latest version
>
>
> Key: SCM-890
> URL: https://issues.apache.org/jira/browse/SCM-890
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.10.0
>Reporter: Charlie Mordant
>Assignee: Robert Scholte
>Priority: Major
>
> Using the latest version, gitexe isn't able to find remote git repository
> (works with 1.8.1).
> I'm using ssh key, do not work with either release or site
> wagon-scm:3.1.0
> {code:java}
> // code placeholder
> [DEBUG] Configuring mojo
> org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare from plugin realm
> ClassRealm[plugin>org.apache.maven.plugins:maven-release-plugin:2.5.3,
> parent: java.net.URLClassLoader@4a574795]
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare' with basic
> configurator -->
> [DEBUG] (f) addSchema = true
> [DEBUG] (f) allowReleasePluginSnapshot = false
> [DEBUG] (f) allowTimestampedSnapshots = false
> [DEBUG] (f) autoVersionSubmodules = true
> [DEBUG] (s) basedir = /var/lib/jenkins/workspace/xxx/project-int-deployment
> [DEBUG] (f) commitByProject = false
> [DEBUG] (f) dryRun = false
> [DEBUG] (f) generateReleasePoms = false
> [DEBUG] (f) javaHome = /usr/lib/jvm/java-8-openjdk-amd64/jre
> [DEBUG] (f) mavenExecutorId = invoker
> [DEBUG] (f) mavenHome =
> /var/lib/jenkins/.m2/wrapper/dists/apache-maven-3.5.3-bin/2c22a6s60afpuloj4v181qvild/apache-maven-3.5.3
> [DEBUG] (f) preparationGoals = clean verify
> [DEBUG] (f) project = MavenProject:
> com.yyy.tce.service.project:project:0.0.1-SNAPSHOT @
> /var/lib/jenkins/workspace/xxx/project-int-deployment/pom.xml
> [DEBUG] (f) projectVersionPolicyId = default
> [DEBUG] (f) pushChanges = true
> [DEBUG] (f) reactorProjects = [MavenProject:
> com.yyy.tce.service.project:project:0.0.1-SNAPSHOT @
> /var/lib/jenkins/workspace/xxx/project-int-deployment/pom.xml]
> [DEBUG] (f) remoteTagging = true
> [DEBUG] (f) resume = true
> [DEBUG] (f) scmCommentPrefix = [ci-skip][maven-release-plugin]
> [DEBUG] (f) session = org.apache.maven.execution.MavenSession@44c5a16f
> [DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@7a6ebe1e
> [DEBUG] (f) suppressCommitBeforeTag = false
> [DEBUG] (f) tagNameFormat = @{project.artifactId}-@{project.version}
> [DEBUG] (f) updateDependencies = true
> [DEBUG] (f) updateWorkingCopyVersions = true
> [DEBUG] (f) useEditMode = false
> [DEBUG] (f) waitBeforeTagging = 0
> [DEBUG] -- end configuration --
> [INFO] Resuming release from phase 'scm-commit-release'
> [INFO] Checking in modified POMs...
> [INFO] Executing: /bin/sh -c cd
> /var/lib/jenkins/workspace/xxx/project-int-deployment && git add -- pom.xml
> [INFO] Working directory:
> /var/lib/jenkins/workspace/xxx/project-int-deployment
> [INFO] Executing: /bin/sh -c cd
> /var/lib/jenkins/workspace/xxx/project-int-deployment && git rev-parse
> --show-prefix
> [INFO] Working directory:
> /var/lib/jenkins/workspace/xxx/project-int-deployment
> [INFO] Executing: /bin/sh -c cd
> /var/lib/jenkins/workspace/xxx/project-int-deployment && git status
> --porcelain .
> [INFO] Working directory:
> /var/lib/jenkins/workspace/xxx/project-int-deployment
> [DEBUG] ?? pom.xml.releaseBackup
> [WARNING] Ignoring unrecognized line: ?? pom.xml.releaseBackup
> [DEBUG] ?? release.properties
> [WARNING] Ignoring unrecognized line: ?? release.properties
> [INFO] Tagging release with the label project-0.0.1...
> [DEBUG] ScmTagPhase :: scmTagParameters remotingTag true
> [DEBUG] ScmTagPhase :: scmTagParameters scmRevision null
> [DEBUG] ScmTagPhase :: fileSet basedir =
> /var/lib/jenkins/workspace/xxx/project-int-deployment; files = []
> [INFO] Executing: /bin/sh -c cd
> /var/lib/jenkins/workspace/xxx/project-int-deployment && git tag -F
> /tmp/maven-scm-2076768482.commit project-0.0.1
> [INFO] Working directory:
> /var/lib/jenkins/workspace/xxx/project-int-deployment
> [INFO] Executing: /bin/sh -c cd
> /var/lib/jenkins/workspace/xxx/project-int-deployment && git push
> git@xxx:tiss/xxx/xxx.git refs/tags/project-0.0.1
> [INFO] Working directory:
> /var/lib/jenkins/workspace/xxx/project-int-deployment
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.271 s
> [INFO] Finished at: 2018-06-12T18:01:37+02:00
> [INFO]
>
[jira] [Commented] (MCHECKSTYLE-344) StringIndexOutOfBoundsException in RuleUtil
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510077#comment-16510077
]
Daniel Ward commented on MCHECKSTYLE-344:
-
Do you know when 3.0.1 will be released? I am suffering from this exact
situation. Is there a work-around?
> StringIndexOutOfBoundsException in RuleUtil
> ---
>
> Key: MCHECKSTYLE-344
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-344
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
> Components: checkstyle:check
>Affects Versions: 2.17
>Reporter: fdvxxii
>Assignee: Guillaume Boué
>Priority: Major
> Fix For: 3.0.1
>
>
> {{RuleUtil}} has a bug at line 95:
> {code}
> final int end = eventSrcName.lastIndexOf('.');
> eventSrcName = eventSrcName.substring(0, end);
> {code}
> This code leads to a StringIndexOutOfBoundsException if the variable does not
> contain a period. I don't know if its a convention to have a period in that
> string, but either way the error message should me more expressive.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCM-890) scm-provider-gitexe do not find the repository on latest version
[
https://issues.apache.org/jira/browse/SCM-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509963#comment-16509963
]
Charlie Mordant commented on SCM-890:
-
Can close, it's on my side
> scm-provider-gitexe do not find the repository on latest version
>
>
> Key: SCM-890
> URL: https://issues.apache.org/jira/browse/SCM-890
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.10.0
>Reporter: Charlie Mordant
>Priority: Major
>
> Using the latest version, gitexe isn't able to find remote git repository
> (works with 1.8.1).
> I'm using ssh key, do not work with either release or site
> wagon-scm:3.1.0
> {code:java}
> // code placeholder
> [DEBUG] Configuring mojo
> org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare from plugin realm
> ClassRealm[plugin>org.apache.maven.plugins:maven-release-plugin:2.5.3,
> parent: java.net.URLClassLoader@4a574795]
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare' with basic
> configurator -->
> [DEBUG] (f) addSchema = true
> [DEBUG] (f) allowReleasePluginSnapshot = false
> [DEBUG] (f) allowTimestampedSnapshots = false
> [DEBUG] (f) autoVersionSubmodules = true
> [DEBUG] (s) basedir = /var/lib/jenkins/workspace/xxx/project-int-deployment
> [DEBUG] (f) commitByProject = false
> [DEBUG] (f) dryRun = false
> [DEBUG] (f) generateReleasePoms = false
> [DEBUG] (f) javaHome = /usr/lib/jvm/java-8-openjdk-amd64/jre
> [DEBUG] (f) mavenExecutorId = invoker
> [DEBUG] (f) mavenHome =
> /var/lib/jenkins/.m2/wrapper/dists/apache-maven-3.5.3-bin/2c22a6s60afpuloj4v181qvild/apache-maven-3.5.3
> [DEBUG] (f) preparationGoals = clean verify
> [DEBUG] (f) project = MavenProject:
> com.yyy.tce.service.project:project:0.0.1-SNAPSHOT @
> /var/lib/jenkins/workspace/xxx/project-int-deployment/pom.xml
> [DEBUG] (f) projectVersionPolicyId = default
> [DEBUG] (f) pushChanges = true
> [DEBUG] (f) reactorProjects = [MavenProject:
> com.yyy.tce.service.project:project:0.0.1-SNAPSHOT @
> /var/lib/jenkins/workspace/xxx/project-int-deployment/pom.xml]
> [DEBUG] (f) remoteTagging = true
> [DEBUG] (f) resume = true
> [DEBUG] (f) scmCommentPrefix = [ci-skip][maven-release-plugin]
> [DEBUG] (f) session = org.apache.maven.execution.MavenSession@44c5a16f
> [DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@7a6ebe1e
> [DEBUG] (f) suppressCommitBeforeTag = false
> [DEBUG] (f) tagNameFormat = @{project.artifactId}-@{project.version}
> [DEBUG] (f) updateDependencies = true
> [DEBUG] (f) updateWorkingCopyVersions = true
> [DEBUG] (f) useEditMode = false
> [DEBUG] (f) waitBeforeTagging = 0
> [DEBUG] -- end configuration --
> [INFO] Resuming release from phase 'scm-commit-release'
> [INFO] Checking in modified POMs...
> [INFO] Executing: /bin/sh -c cd
> /var/lib/jenkins/workspace/xxx/project-int-deployment && git add -- pom.xml
> [INFO] Working directory:
> /var/lib/jenkins/workspace/xxx/project-int-deployment
> [INFO] Executing: /bin/sh -c cd
> /var/lib/jenkins/workspace/xxx/project-int-deployment && git rev-parse
> --show-prefix
> [INFO] Working directory:
> /var/lib/jenkins/workspace/xxx/project-int-deployment
> [INFO] Executing: /bin/sh -c cd
> /var/lib/jenkins/workspace/xxx/project-int-deployment && git status
> --porcelain .
> [INFO] Working directory:
> /var/lib/jenkins/workspace/xxx/project-int-deployment
> [DEBUG] ?? pom.xml.releaseBackup
> [WARNING] Ignoring unrecognized line: ?? pom.xml.releaseBackup
> [DEBUG] ?? release.properties
> [WARNING] Ignoring unrecognized line: ?? release.properties
> [INFO] Tagging release with the label project-0.0.1...
> [DEBUG] ScmTagPhase :: scmTagParameters remotingTag true
> [DEBUG] ScmTagPhase :: scmTagParameters scmRevision null
> [DEBUG] ScmTagPhase :: fileSet basedir =
> /var/lib/jenkins/workspace/xxx/project-int-deployment; files = []
> [INFO] Executing: /bin/sh -c cd
> /var/lib/jenkins/workspace/xxx/project-int-deployment && git tag -F
> /tmp/maven-scm-2076768482.commit project-0.0.1
> [INFO] Working directory:
> /var/lib/jenkins/workspace/xxx/project-int-deployment
> [INFO] Executing: /bin/sh -c cd
> /var/lib/jenkins/workspace/xxx/project-int-deployment && git push
> git@xxx:tiss/xxx/xxx.git refs/tags/project-0.0.1
> [INFO] Working directory:
> /var/lib/jenkins/workspace/xxx/project-int-deployment
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.271 s
> [INFO] Finished at: 2018-06-12T18:01:37+02:00
> [INFO]
>
> [ERROR]
[jira] [Commented] (MSHADE-275) Maven Shade Plugin does not work under Java 10
[
https://issues.apache.org/jira/browse/MSHADE-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509948#comment-16509948
]
Philip Aston commented on MSHADE-275:
-
Thanks for the response. Done: MSHADE-289.
> Maven Shade Plugin does not work under Java 10
> --
>
> Key: MSHADE-275
> URL: https://issues.apache.org/jira/browse/MSHADE-275
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
> Environment: Windows 10, 64 Bit; Java 10, 64 Bit
> Maven 3.3.9, Shade Plugin 3.1.0
>Reporter: Markus Grech
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Fix For: 3.1.1
>
>
> Creating an uber-jar works fine for my project under Java 9, fails under Java
> 10 with the following Exception:
>
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-shade-plugin:3.1.0:shade (default) on project
> compiler: Error creating shaded jar: null: IllegalArgumentException -> [Help
> 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-shade-plugin:3.1.0:shade (default) on
> project compiler: 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:564)
> 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)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating
> shaded jar: null
> at
> org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:546)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 21 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:97)
> at
> org.apache.maven.plugins.shade.mojo.ShadeMojo.getFilters(ShadeMojo.java:834)
> at
> org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:434)
> ... 23 more{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MSHADE-289) Maven Shade Plugin does not work under Java 10
Philip Aston created MSHADE-289:
---
Summary: Maven Shade Plugin does not work under Java 10
Key: MSHADE-289
URL: https://issues.apache.org/jira/browse/MSHADE-289
Project: Maven Shade Plugin
Issue Type: Bug
Affects Versions: 3.1.1
Reporter: Philip Aston
I'm seeing the same symptoms as MSHADE-275 but with 3.1.1.
My build works with Java 9, but Java 10 gives:
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:3.1.1:shade (default) on project
client-bootstrap: Error creating shaded jar: null: IllegalArgumentException ->
[Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:3.1.1:shade (default) on project
client-bootstrap: Error creating shaded jar: null
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:213)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
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:309)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:564)
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:546)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
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:309)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:564)
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: java.lang.IllegalArgumentException
at org.objectweb.asm.ClassReader. (ClassReader.java:160)
at org.objectweb.asm.ClassReader. (ClassReader.java:143)
at
[jira] [Commented] (MNG-6425) Maven inserts incorrect version metadata when 'artifactory matrix parameters' are used.
[
https://issues.apache.org/jira/browse/MNG-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509928#comment-16509928
]
Michael Osipov commented on MNG-6425:
-
Thanks, I will have a look at it a bit later today.
> Maven inserts incorrect version metadata when 'artifactory matrix parameters'
> are used.
> ---
>
> Key: MNG-6425
> URL: https://issues.apache.org/jira/browse/MNG-6425
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.5.3
> Environment: Linux, Windows
>Reporter: George Lianeris
>Priority: Major
> Attachments: MNG-6425-wirelog-full.log, MNG-6425-wirelog.log,
> MNG-6425.log
>
>
> When using artifactory matrix parameters as per
> [Artifactory Matrix
> Parameters|https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution#UsingPropertiesinDeploymentandResolution-IntroducingMatrixParameters]
> and they are added to the command line like so:
> mvn -Psomeprofile package deploy:deploy
> -DaltDeploymentRepository=central::default::[https://artifactory.my.co/artifactory/myco-dev;artifactory.licenses=myco]
> The metadata.xml for the artifact (not the version beneath it) acquires
> incorrectly calculated version values on the *second* run.
> What it should be:
> {code:xml}
>
>
> com.myco.foo
> bar
>
>
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> What it is (more or less):
> {code:xml}
>
>
> com.myco.foo
> bar
>
> *1.0.0*
> *1.0.0*
>
> *1.0.0*
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> Note that version 1.0.0 does not exist and was never built. This makes it
> impossible to use the artifactory matrix parameters.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6425) Maven inserts incorrect version metadata when 'artifactory matrix parameters' are used.
[
https://issues.apache.org/jira/browse/MNG-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509883#comment-16509883
]
George Lianeris commented on MNG-6425:
--
Full log attached.
> Maven inserts incorrect version metadata when 'artifactory matrix parameters'
> are used.
> ---
>
> Key: MNG-6425
> URL: https://issues.apache.org/jira/browse/MNG-6425
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.5.3
> Environment: Linux, Windows
>Reporter: George Lianeris
>Priority: Major
> Attachments: MNG-6425-wirelog-full.log, MNG-6425-wirelog.log,
> MNG-6425.log
>
>
> When using artifactory matrix parameters as per
> [Artifactory Matrix
> Parameters|https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution#UsingPropertiesinDeploymentandResolution-IntroducingMatrixParameters]
> and they are added to the command line like so:
> mvn -Psomeprofile package deploy:deploy
> -DaltDeploymentRepository=central::default::[https://artifactory.my.co/artifactory/myco-dev;artifactory.licenses=myco]
> The metadata.xml for the artifact (not the version beneath it) acquires
> incorrectly calculated version values on the *second* run.
> What it should be:
> {code:xml}
>
>
> com.myco.foo
> bar
>
>
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> What it is (more or less):
> {code:xml}
>
>
> com.myco.foo
> bar
>
> *1.0.0*
> *1.0.0*
>
> *1.0.0*
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> Note that version 1.0.0 does not exist and was never built. This makes it
> impossible to use the artifactory matrix parameters.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6425) Maven inserts incorrect version metadata when 'artifactory matrix parameters' are used.
[
https://issues.apache.org/jira/browse/MNG-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Lianeris updated MNG-6425:
-
Attachment: MNG-6425-wirelog-full.log
> Maven inserts incorrect version metadata when 'artifactory matrix parameters'
> are used.
> ---
>
> Key: MNG-6425
> URL: https://issues.apache.org/jira/browse/MNG-6425
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.5.3
> Environment: Linux, Windows
>Reporter: George Lianeris
>Priority: Major
> Attachments: MNG-6425-wirelog-full.log, MNG-6425-wirelog.log,
> MNG-6425.log
>
>
> When using artifactory matrix parameters as per
> [Artifactory Matrix
> Parameters|https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution#UsingPropertiesinDeploymentandResolution-IntroducingMatrixParameters]
> and they are added to the command line like so:
> mvn -Psomeprofile package deploy:deploy
> -DaltDeploymentRepository=central::default::[https://artifactory.my.co/artifactory/myco-dev;artifactory.licenses=myco]
> The metadata.xml for the artifact (not the version beneath it) acquires
> incorrectly calculated version values on the *second* run.
> What it should be:
> {code:xml}
>
>
> com.myco.foo
> bar
>
>
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> What it is (more or less):
> {code:xml}
>
>
> com.myco.foo
> bar
>
> *1.0.0*
> *1.0.0*
>
> *1.0.0*
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> Note that version 1.0.0 does not exist and was never built. This makes it
> impossible to use the artifactory matrix parameters.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6425) Maven inserts incorrect version metadata when 'artifactory matrix parameters' are used.
[
https://issues.apache.org/jira/browse/MNG-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509875#comment-16509875
]
Michael Osipov commented on MNG-6425:
-
Can you also please share what is downloaded from Artifactory?
> Maven inserts incorrect version metadata when 'artifactory matrix parameters'
> are used.
> ---
>
> Key: MNG-6425
> URL: https://issues.apache.org/jira/browse/MNG-6425
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.5.3
> Environment: Linux, Windows
>Reporter: George Lianeris
>Priority: Major
> Attachments: MNG-6425-wirelog.log, MNG-6425.log
>
>
> When using artifactory matrix parameters as per
> [Artifactory Matrix
> Parameters|https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution#UsingPropertiesinDeploymentandResolution-IntroducingMatrixParameters]
> and they are added to the command line like so:
> mvn -Psomeprofile package deploy:deploy
> -DaltDeploymentRepository=central::default::[https://artifactory.my.co/artifactory/myco-dev;artifactory.licenses=myco]
> The metadata.xml for the artifact (not the version beneath it) acquires
> incorrectly calculated version values on the *second* run.
> What it should be:
> {code:xml}
>
>
> com.myco.foo
> bar
>
>
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> What it is (more or less):
> {code:xml}
>
>
> com.myco.foo
> bar
>
> *1.0.0*
> *1.0.0*
>
> *1.0.0*
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> Note that version 1.0.0 does not exist and was never built. This makes it
> impossible to use the artifactory matrix parameters.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SCM-890) scm-provider-gitexe do not find the repository on latest version
Charlie Mordant created SCM-890:
---
Summary: scm-provider-gitexe do not find the repository on latest
version
Key: SCM-890
URL: https://issues.apache.org/jira/browse/SCM-890
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-gitexe
Affects Versions: 1.10.0
Reporter: Charlie Mordant
Using the latest version, gitexe isn't able to find remote git repository
(works with 1.8.1).
I'm using ssh key, do not work with either release or site
wagon-scm:3.1.0
{code:java}
// code placeholder
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare from plugin realm
ClassRealm[plugin>org.apache.maven.plugins:maven-release-plugin:2.5.3, parent:
java.net.URLClassLoader@4a574795]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare' with basic
configurator -->
[DEBUG] (f) addSchema = true
[DEBUG] (f) allowReleasePluginSnapshot = false
[DEBUG] (f) allowTimestampedSnapshots = false
[DEBUG] (f) autoVersionSubmodules = true
[DEBUG] (s) basedir = /var/lib/jenkins/workspace/xxx/project-int-deployment
[DEBUG] (f) commitByProject = false
[DEBUG] (f) dryRun = false
[DEBUG] (f) generateReleasePoms = false
[DEBUG] (f) javaHome = /usr/lib/jvm/java-8-openjdk-amd64/jre
[DEBUG] (f) mavenExecutorId = invoker
[DEBUG] (f) mavenHome =
/var/lib/jenkins/.m2/wrapper/dists/apache-maven-3.5.3-bin/2c22a6s60afpuloj4v181qvild/apache-maven-3.5.3
[DEBUG] (f) preparationGoals = clean verify
[DEBUG] (f) project = MavenProject:
com.yyy.tce.service.project:project:0.0.1-SNAPSHOT @
/var/lib/jenkins/workspace/xxx/project-int-deployment/pom.xml
[DEBUG] (f) projectVersionPolicyId = default
[DEBUG] (f) pushChanges = true
[DEBUG] (f) reactorProjects = [MavenProject:
com.yyy.tce.service.project:project:0.0.1-SNAPSHOT @
/var/lib/jenkins/workspace/xxx/project-int-deployment/pom.xml]
[DEBUG] (f) remoteTagging = true
[DEBUG] (f) resume = true
[DEBUG] (f) scmCommentPrefix = [ci-skip][maven-release-plugin]
[DEBUG] (f) session = org.apache.maven.execution.MavenSession@44c5a16f
[DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@7a6ebe1e
[DEBUG] (f) suppressCommitBeforeTag = false
[DEBUG] (f) tagNameFormat = @{project.artifactId}-@{project.version}
[DEBUG] (f) updateDependencies = true
[DEBUG] (f) updateWorkingCopyVersions = true
[DEBUG] (f) useEditMode = false
[DEBUG] (f) waitBeforeTagging = 0
[DEBUG] -- end configuration --
[INFO] Resuming release from phase 'scm-commit-release'
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd
/var/lib/jenkins/workspace/xxx/project-int-deployment && git add -- pom.xml
[INFO] Working directory: /var/lib/jenkins/workspace/xxx/project-int-deployment
[INFO] Executing: /bin/sh -c cd
/var/lib/jenkins/workspace/xxx/project-int-deployment && git rev-parse
--show-prefix
[INFO] Working directory: /var/lib/jenkins/workspace/xxx/project-int-deployment
[INFO] Executing: /bin/sh -c cd
/var/lib/jenkins/workspace/xxx/project-int-deployment && git status --porcelain
.
[INFO] Working directory: /var/lib/jenkins/workspace/xxx/project-int-deployment
[DEBUG] ?? pom.xml.releaseBackup
[WARNING] Ignoring unrecognized line: ?? pom.xml.releaseBackup
[DEBUG] ?? release.properties
[WARNING] Ignoring unrecognized line: ?? release.properties
[INFO] Tagging release with the label project-0.0.1...
[DEBUG] ScmTagPhase :: scmTagParameters remotingTag true
[DEBUG] ScmTagPhase :: scmTagParameters scmRevision null
[DEBUG] ScmTagPhase :: fileSet basedir =
/var/lib/jenkins/workspace/xxx/project-int-deployment; files = []
[INFO] Executing: /bin/sh -c cd
/var/lib/jenkins/workspace/xxx/project-int-deployment && git tag -F
/tmp/maven-scm-2076768482.commit project-0.0.1
[INFO] Working directory: /var/lib/jenkins/workspace/xxx/project-int-deployment
[INFO] Executing: /bin/sh -c cd
/var/lib/jenkins/workspace/xxx/project-int-deployment && git push
git@xxx:tiss/xxx/xxx.git refs/tags/project-0.0.1
[INFO] Working directory: /var/lib/jenkins/workspace/xxx/project-int-deployment
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 2.271 s
[INFO] Finished at: 2018-06-12T18:01:37+02:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare (default-cli) on
project project: Unable to tag SCM
[ERROR] Provider message:
[ERROR] The git-push command failed.
[ERROR] Command output:
[ERROR] GitLab: The project you were looking for could not be found.
[ERROR] fatal: Could not read from remote repository.
[ERROR]
[ERROR] Please make sure you have the correct access rights
[ERROR] and the repository exists.
[ERROR] ->
[jira] [Commented] (MSHADE-275) Maven Shade Plugin does not work under Java 10
[
https://issues.apache.org/jira/browse/MSHADE-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509814#comment-16509814
]
Karl Heinz Marbaise commented on MSHADE-275:
Please don't reuse closed ticket. Create a new one with a reference to this
ticket...
> Maven Shade Plugin does not work under Java 10
> --
>
> Key: MSHADE-275
> URL: https://issues.apache.org/jira/browse/MSHADE-275
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
> Environment: Windows 10, 64 Bit; Java 10, 64 Bit
> Maven 3.3.9, Shade Plugin 3.1.0
>Reporter: Markus Grech
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Fix For: 3.1.1
>
>
> Creating an uber-jar works fine for my project under Java 9, fails under Java
> 10 with the following Exception:
>
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-shade-plugin:3.1.0:shade (default) on project
> compiler: Error creating shaded jar: null: IllegalArgumentException -> [Help
> 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-shade-plugin:3.1.0:shade (default) on
> project compiler: 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:564)
> 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)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating
> shaded jar: null
> at
> org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:546)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 21 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:97)
> at
> org.apache.maven.plugins.shade.mojo.ShadeMojo.getFilters(ShadeMojo.java:834)
> at
> org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:434)
> ... 23 more{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MDEP-619) snapshotsOnly is not always respected
Joerg Schaible created MDEP-619:
---
Summary: snapshotsOnly is not always respected
Key: MDEP-619
URL: https://issues.apache.org/jira/browse/MDEP-619
Project: Maven Dependency Plugin
Issue Type: Bug
Components: purge-local-repository
Affects Versions: 3.1.1
Environment: $ mvn -version
Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T20:49:05+01:00)
Maven home: /usr/share/maven-bin-3.5
Java version: 1.8.0_172, vendor: Oracle Corporation
Java home: /opt/oracle-jdk-bin-1.8.0.172/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.9.76-gentoo-r1", arch: "amd64", family: "unix"
Reporter: Joerg Schaible
The configuration parameter snapshotsOnly is not always repected. We use a
profile that can be activated in the root of a multi-project with following
settings:
{code:xml}
purge
purge-group
org.apache.maven.plugins
maven-dependency-plugin
purge-local-repository
clean
purge-local-repository
${project.groupId}
groupId
${purge}
{code}
We'd like to handle all artifacts with the same groupId. The purge parameter
should be used to purge only the snapshots or anything. However, the
snapshotOnly parameter is not respected. The goal will wipe always all
artifacts with the same groupId.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6425) Maven inserts incorrect version metadata when 'artifactory matrix parameters' are used.
[
https://issues.apache.org/jira/browse/MNG-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Lianeris updated MNG-6425:
-
Attachment: MNG-6425-wirelog.log
> Maven inserts incorrect version metadata when 'artifactory matrix parameters'
> are used.
> ---
>
> Key: MNG-6425
> URL: https://issues.apache.org/jira/browse/MNG-6425
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.5.3
> Environment: Linux, Windows
>Reporter: George Lianeris
>Priority: Major
> Attachments: MNG-6425-wirelog.log, MNG-6425.log
>
>
> When using artifactory matrix parameters as per
> [Artifactory Matrix
> Parameters|https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution#UsingPropertiesinDeploymentandResolution-IntroducingMatrixParameters]
> and they are added to the command line like so:
> mvn -Psomeprofile package deploy:deploy
> -DaltDeploymentRepository=central::default::[https://artifactory.my.co/artifactory/myco-dev;artifactory.licenses=myco]
> The metadata.xml for the artifact (not the version beneath it) acquires
> incorrectly calculated version values on the *second* run.
> What it should be:
> {code:xml}
>
>
> com.myco.foo
> bar
>
>
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> What it is (more or less):
> {code:xml}
>
>
> com.myco.foo
> bar
>
> *1.0.0*
> *1.0.0*
>
> *1.0.0*
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> Note that version 1.0.0 does not exist and was never built. This makes it
> impossible to use the artifactory matrix parameters.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6425) Maven inserts incorrect version metadata when 'artifactory matrix parameters' are used.
[
https://issues.apache.org/jira/browse/MNG-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509694#comment-16509694
]
George Lianeris commented on MNG-6425:
--
Hi Michael,
I am inclined to agree with you, but to my surprise the wire log appears to
say otherwise. I have attached the relevant section of the log.
> Maven inserts incorrect version metadata when 'artifactory matrix parameters'
> are used.
> ---
>
> Key: MNG-6425
> URL: https://issues.apache.org/jira/browse/MNG-6425
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.5.3
> Environment: Linux, Windows
>Reporter: George Lianeris
>Priority: Major
> Attachments: MNG-6425-wirelog.log, MNG-6425.log
>
>
> When using artifactory matrix parameters as per
> [Artifactory Matrix
> Parameters|https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution#UsingPropertiesinDeploymentandResolution-IntroducingMatrixParameters]
> and they are added to the command line like so:
> mvn -Psomeprofile package deploy:deploy
> -DaltDeploymentRepository=central::default::[https://artifactory.my.co/artifactory/myco-dev;artifactory.licenses=myco]
> The metadata.xml for the artifact (not the version beneath it) acquires
> incorrectly calculated version values on the *second* run.
> What it should be:
> {code:xml}
>
>
> com.myco.foo
> bar
>
>
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> What it is (more or less):
> {code:xml}
>
>
> com.myco.foo
> bar
>
> *1.0.0*
> *1.0.0*
>
> *1.0.0*
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> Note that version 1.0.0 does not exist and was never built. This makes it
> impossible to use the artifactory matrix parameters.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHADE-275) Maven Shade Plugin does not work under Java 10
[
https://issues.apache.org/jira/browse/MSHADE-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509656#comment-16509656
]
Philip Aston commented on MSHADE-275:
-
I'm seeing the same symptoms with 3.1.1. As above, it works with Java 9, but
Java 10 gives:
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:3.1.1:shade (default) on project
client-bootstrap: Error creating shaded jar: null: IllegalArgumentException ->
[Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:3.1.1:shade (default) on project
client-bootstrap: Error creating shaded jar: null
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:213)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
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:309)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:564)
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:546)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
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:309)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:564)
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: java.lang.IllegalArgumentException
at org.objectweb.asm.ClassReader. (ClassReader.java:160)
at org.objectweb.asm.ClassReader. (ClassReader.java:143)
at org.objectweb.asm.ClassReader. (ClassReader.java:418)
at org.vafer.jdependency.Clazzpath.addClazzpathUnit (Clazzpath.java:201)
at
[jira] [Comment Edited] (MNG-6425) Maven inserts incorrect version metadata when 'artifactory matrix parameters' are used.
[
https://issues.apache.org/jira/browse/MNG-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509579#comment-16509579
]
Michael Osipov edited comment on MNG-6425 at 6/12/18 12:36 PM:
---
The log itself looks fine to me, thank you. Please enable wire log too. Check
wether the uploaded file does already contain the erronous content. Please also
try Maven from master.
I hardly can image that this related to the matrix parameters because the
metadata generation is completely decoupled from the transfer.
was (Author: michael-o):
The log itself looks fine to me, thank you. Please enable wire log too. Check
wether the uploaded file does already contain the erronous content. Please also
try Maven from master.
> Maven inserts incorrect version metadata when 'artifactory matrix parameters'
> are used.
> ---
>
> Key: MNG-6425
> URL: https://issues.apache.org/jira/browse/MNG-6425
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.5.3
> Environment: Linux, Windows
>Reporter: George Lianeris
>Priority: Major
> Attachments: MNG-6425.log
>
>
> When using artifactory matrix parameters as per
> [Artifactory Matrix
> Parameters|https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution#UsingPropertiesinDeploymentandResolution-IntroducingMatrixParameters]
> and they are added to the command line like so:
> mvn -Psomeprofile package deploy:deploy
> -DaltDeploymentRepository=central::default::[https://artifactory.my.co/artifactory/myco-dev;artifactory.licenses=myco]
> The metadata.xml for the artifact (not the version beneath it) acquires
> incorrectly calculated version values on the *second* run.
> What it should be:
> {code:xml}
>
>
> com.myco.foo
> bar
>
>
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> What it is (more or less):
> {code:xml}
>
>
> com.myco.foo
> bar
>
> *1.0.0*
> *1.0.0*
>
> *1.0.0*
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> Note that version 1.0.0 does not exist and was never built. This makes it
> impossible to use the artifactory matrix parameters.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6425) Maven inserts incorrect version metadata when 'artifactory matrix parameters' are used.
[
https://issues.apache.org/jira/browse/MNG-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509579#comment-16509579
]
Michael Osipov commented on MNG-6425:
-
The log itself looks fine to me, thank you. Please enable wire log too. Check
wether the uploaded file does already contain the erronous content. Please also
try Maven from master.
> Maven inserts incorrect version metadata when 'artifactory matrix parameters'
> are used.
> ---
>
> Key: MNG-6425
> URL: https://issues.apache.org/jira/browse/MNG-6425
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.5.3
> Environment: Linux, Windows
>Reporter: George Lianeris
>Priority: Major
> Attachments: MNG-6425.log
>
>
> When using artifactory matrix parameters as per
> [Artifactory Matrix
> Parameters|https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution#UsingPropertiesinDeploymentandResolution-IntroducingMatrixParameters]
> and they are added to the command line like so:
> mvn -Psomeprofile package deploy:deploy
> -DaltDeploymentRepository=central::default::[https://artifactory.my.co/artifactory/myco-dev;artifactory.licenses=myco]
> The metadata.xml for the artifact (not the version beneath it) acquires
> incorrectly calculated version values on the *second* run.
> What it should be:
> {code:xml}
>
>
> com.myco.foo
> bar
>
>
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> What it is (more or less):
> {code:xml}
>
>
> com.myco.foo
> bar
>
> *1.0.0*
> *1.0.0*
>
> *1.0.0*
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> Note that version 1.0.0 does not exist and was never built. This makes it
> impossible to use the artifactory matrix parameters.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6425) Maven inserts incorrect version metadata when 'artifactory matrix parameters' are used.
[
https://issues.apache.org/jira/browse/MNG-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6425:
Description:
When using artifactory matrix parameters as per
[Artifactory Matrix
Parameters|https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution#UsingPropertiesinDeploymentandResolution-IntroducingMatrixParameters]
and they are added to the command line like so:
mvn -Psomeprofile package deploy:deploy
-DaltDeploymentRepository=central::default::[https://artifactory.my.co/artifactory/myco-dev;artifactory.licenses=myco]
The metadata.xml for the artifact (not the version beneath it) acquires
incorrectly calculated version values on the *second* run.
What it should be:
{code:xml}
com.myco.foo
bar
1.0.0-SNAPSHOT
20180611143540
{code}
What it is (more or less):
{code:xml}
com.myco.foo
bar
*1.0.0*
*1.0.0*
*1.0.0*
1.0.0-SNAPSHOT
20180611143540
{code}
Note that version 1.0.0 does not exist and was never built. This makes it
impossible to use the artifactory matrix parameters.
was:
When using artifactory matrix parameters as per
[Artifactory Matrix
Parameters|https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution#UsingPropertiesinDeploymentandResolution-IntroducingMatrixParameters]
and they are added to the command line like so:
mvn -Psomeprofile package deploy:deploy
-DaltDeploymentRepository=central::default::[https://artifactory.my.co/artifactory/myco-dev;artifactory.licenses=myco]
The metadata.xml for the artifact (not the version beneath it) acquires
incorrectly calculated version values on the *second* run.
What it should be:
{code:xml}
com.myco.foo
bar
1.0.0-SNAPSHOT
20180611143540
{code}
What it is (more or less):
{code:xml}
com.myco.foo
bar
{code}
*{{1.0.0}}*
*{{1.0.0}}*
{code:xml}
*1.0.0*
1.0.0-SNAPSHOT
20180611143540
{code}
Note that version 1.0.0 does not exist and was never built. This makes it
impossible to use the artifactory matrix parameters.
> Maven inserts incorrect version metadata when 'artifactory matrix parameters'
> are used.
> ---
>
> Key: MNG-6425
> URL: https://issues.apache.org/jira/browse/MNG-6425
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.5.3
> Environment: Linux, Windows
>Reporter: George Lianeris
>Priority: Major
> Attachments: MNG-6425.log
>
>
> When using artifactory matrix parameters as per
> [Artifactory Matrix
> Parameters|https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution#UsingPropertiesinDeploymentandResolution-IntroducingMatrixParameters]
> and they are added to the command line like so:
> mvn -Psomeprofile package deploy:deploy
> -DaltDeploymentRepository=central::default::[https://artifactory.my.co/artifactory/myco-dev;artifactory.licenses=myco]
> The metadata.xml for the artifact (not the version beneath it) acquires
> incorrectly calculated version values on the *second* run.
> What it should be:
> {code:xml}
>
>
> com.myco.foo
> bar
>
>
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> What it is (more or less):
> {code:xml}
>
>
> com.myco.foo
> bar
>
> *1.0.0*
> *1.0.0*
>
> *1.0.0*
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> Note that version 1.0.0 does not exist and was never built. This makes it
> impossible to use the artifactory matrix parameters.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6425) Maven inserts incorrect version metadata when 'artifactory matrix parameters' are used.
[
https://issues.apache.org/jira/browse/MNG-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6425:
Description:
When using artifactory matrix parameters as per
[Artifactory Matrix
Parameters|https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution#UsingPropertiesinDeploymentandResolution-IntroducingMatrixParameters]
and they are added to the command line like so:
mvn -Psomeprofile package deploy:deploy
-DaltDeploymentRepository=central::default::[https://artifactory.my.co/artifactory/myco-dev;artifactory.licenses=myco]
The metadata.xml for the artifact (not the version beneath it) acquires
incorrectly calculated version values on the *second* run.
What it should be:
{code:xml}
com.myco.foo
bar
1.0.0-SNAPSHOT
20180611143540
{code}
What it is (more or less):
{code:xml}
com.myco.foo
bar
{code}
*{{1.0.0}}*
*{{1.0.0}}*
{code:xml}
*1.0.0*
1.0.0-SNAPSHOT
20180611143540
{code}
Note that version 1.0.0 does not exist and was never built. This makes it
impossible to use the artifactory matrix parameters.
was:
When using artifactory matrix parameters as per
[Artifactory Matrix
Parameters|https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution#UsingPropertiesinDeploymentandResolution-IntroducingMatrixParameters]
and they are added to the command line like so:
mvn -Psomeprofile package deploy:deploy
-DaltDeploymentRepository=central::default::[https://artifactory.my.co/artifactory/myco-dev;artifactory.licenses=myco]
The metadata.xml for the artifact (not the version beneath it) acquires
incorrectly calculated version values on the *second* run.
What it should be:
com.myco.foo
bar
1.0.0-SNAPSHOT
20180611143540
What it is (more or less):
com.myco.foo
bar
*{{1.0.0}}*
*{{1.0.0}}*
*1.0.0*
1.0.0-SNAPSHOT
20180611143540
Note that version 1.0.0 does not exist and was never built. This makes it
impossible to use the artifactory matrix parameters.
> Maven inserts incorrect version metadata when 'artifactory matrix parameters'
> are used.
> ---
>
> Key: MNG-6425
> URL: https://issues.apache.org/jira/browse/MNG-6425
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.5.3
> Environment: Linux, Windows
>Reporter: George Lianeris
>Priority: Major
> Attachments: MNG-6425.log
>
>
> When using artifactory matrix parameters as per
> [Artifactory Matrix
> Parameters|https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution#UsingPropertiesinDeploymentandResolution-IntroducingMatrixParameters]
> and they are added to the command line like so:
> mvn -Psomeprofile package deploy:deploy
> -DaltDeploymentRepository=central::default::[https://artifactory.my.co/artifactory/myco-dev;artifactory.licenses=myco]
> The metadata.xml for the artifact (not the version beneath it) acquires
> incorrectly calculated version values on the *second* run.
> What it should be:
> {code:xml}
>
>
> com.myco.foo
> bar
>
>
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> What it is (more or less):
> {code:xml}
>
>
> com.myco.foo
> bar
>
> {code}
> *{{1.0.0}}*
> *{{1.0.0}}*
> {code:xml}
>
> *1.0.0*
> 1.0.0-SNAPSHOT
>
> 20180611143540
>
>
> {code}
>
> Note that version 1.0.0 does not exist and was never built. This makes it
> impossible to use the artifactory matrix parameters.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1525) Exception in a @BeforeClass method in a JUnit suite class does not fail the build if ran in parallel
[
https://issues.apache.org/jira/browse/SUREFIRE-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Syarov updated SUREFIRE-1525:
--
Description:
I have a @BeforeClass annotated method in a JUnit test suite class, and if an
exception is thrown in the method, the parallel build either succeeds if the
*-DfailIfNoTests* parameter is set to false or fails with "No tests were
executed" if the parameter is set to true. If the build is started without the
*parallel* parameter it fails as it should.
I used a simple project setup to reproduce. I have two test classes, each with
one test method and a suite class:
*TestA.class*
{code:java}
public class TestA {
@Test
public void test() {
System.out.println("TestA");
}
}
{code}
*TestB.class*
{code:java}
public class TestB {
@Test
public void test() {
System.out.println("TestB");
}
}
{code}
*TestSuite.class*
{code:java}
@RunWith(Suite.class)
@SuiteClasses({TestA.class, TestB.class})
public class TestSuite {
@BeforeClass
public static void setUp() {
throw new RuntimeException("ex");
}
}
{code}
If i execute:
mvn clean install -Dtest=TestSuite -Dparallel=classes -DthreadCount=2
-DfailIfNoTests=false
the build succeeds. If I omit the -DfailIfNoTests=false the build fails, but
not because of the thrown exception, but with "No tests were executed!". If i
omit the parallel parameter the build fails appropriately with "There are test
failures."
The JUnit version is 4.12
The surefire plugin version is 2.19.1 - 2.21.0
was:
I have a @BeforeClass annotated method in a JUnit test suite class, and if an
exception is thrown in the method, the parallel build either succeeds if the
*-DfailIfNoTests* parameter is set to false or fails with "No tests were
executed" if the parameter is set to true. If the build is started without the
*parallel* parameter it fails as it should.
I used a simple project setup to reproduce. I have two test classes, each with
one test method and a suite class:
*TestA.class*
{code:java}
public class TestA {
@Test
public void test() {
System.out.println("TestA");
}
}
{code}
*TestB.class*
{code:java}
public class TestB {
@Test
public void test() {
System.out.println("TestB");
}
}
{code}
*TestSuite.class*
{code:java}
@RunWith(Suite.class)
@SuiteClasses({TestA.class, TestB.class})
public class TestSuite {
@BeforeClass
public static void setUp() {
throw new RuntimeException("ex");
}
}
{code}
If i execute:
mvn clean install -Dtest=TestSuite -Dparallel=classes -DthreadCount=2
-DfailIfNoTests=false
the build succeeds. If I omit the -DfailIfNoTests=false the build fails, but
not because of the thrown exception, but with "No tests were executed!". If i
omit the parallel parameter the build fails appropriately with "There are test
failures."
The JUnit version is 4.12
The failsafe plugin version is 2.19.1 - 2.21.0
> Exception in a @BeforeClass method in a JUnit suite class does not fail the
> build if ran in parallel
>
>
> Key: SUREFIRE-1525
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1525
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.21.0
>Reporter: Ivan Syarov
>Priority: Major
>
> I have a @BeforeClass annotated method in a JUnit test suite class, and if an
> exception is thrown in the method, the parallel build either succeeds if the
> *-DfailIfNoTests* parameter is set to false or fails with "No tests were
> executed" if the parameter is set to true. If the build is started without
> the *parallel* parameter it fails as it should.
> I used a simple project setup to reproduce. I have two test classes, each
> with one test method and a suite class:
> *TestA.class*
> {code:java}
> public class TestA {
> @Test
> public void test() {
> System.out.println("TestA");
> }
> }
> {code}
> *TestB.class*
> {code:java}
> public class TestB {
> @Test
> public void test() {
> System.out.println("TestB");
> }
> }
> {code}
> *TestSuite.class*
> {code:java}
> @RunWith(Suite.class)
> @SuiteClasses({TestA.class, TestB.class})
> public class TestSuite {
> @BeforeClass
> public static void setUp() {
> throw new RuntimeException("ex");
> }
> }
> {code}
> If i execute:
> mvn clean install -Dtest=TestSuite -Dparallel=classes -DthreadCount=2
> -DfailIfNoTests=false
> the build succeeds. If I omit the -DfailIfNoTests=false the build fails, but
> not because of the thrown exception, but with "No tests were executed!". If i
> omit the parallel parameter the build fails appropriately with "There are
> test failures."
> The JUnit version
[jira] [Updated] (SUREFIRE-1525) Exception in a @BeforeClass method in a JUnit suite class does not fail the build if ran in parallel
[
https://issues.apache.org/jira/browse/SUREFIRE-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Syarov updated SUREFIRE-1525:
--
Description:
I have a @BeforeClass annotated method in a JUnit test suite class, and if an
exception is thrown in the method, the parallel build either succeeds if the
*-DfailIfNoTests* parameter is set to false or fails with "No tests were
executed" if the parameter is set to true. If the build is started without the
*parallel* parameter it fails as it should.
I used a simple project setup to reproduce. I have two test classes, each with
one test method and a suite class:
*TestA.class*
{code:java}
public class TestA {
@Test
public void test() {
System.out.println("TestA");
}
}
{code}
*TestB.class*
{code:java}
public class TestB {
@Test
public void test() {
System.out.println("TestB");
}
}
{code}
*TestSuite.class*
{code:java}
@RunWith(Suite.class)
@SuiteClasses({TestA.class, TestB.class})
public class TestSuite {
@BeforeClass
public static void setUp() {
throw new RuntimeException("ex");
}
}
{code}
If i execute:
mvn clean install -Dtest=TestSuite -Dparallel=classes -DthreadCount=2
-DfailIfNoTests=false
the build succeeds. If I omit the -DfailIfNoTests=false the build fails, but
not because of the thrown exception, but with "No tests were executed!". If i
omit the parallel parameter the build fails appropriately with "There are test
failures."
The JUnit version is 4.12
The failsafe plugin version is 2.19.1 - 2.21.0
was:
I have a @BeforeClass annotated method in a JUnit test suite class, and if an
exception is thrown in the method, the parallel build either succeeds if the
*-DfailIfNoTests* parameter is set to false or fails with "No tests were
executed" if the parameter is set to true. If the build is started without the
*parallel* parameter it fails as it should.
I used a simple project setup to reproduce. I have two test classes, each with
one test method and a suite class:
*TestA.class*
{code:java}
public class TestA {
@Test
public void test() {
System.out.println("TestA");
}
}
{code}
*TestB.class*
{code:java}
public class TestB {
@Test
public void test() {
System.out.println("TestB");
}
}
{code}
*TestSuite.class*
{code:java}
@RunWith(Suite.class)
@SuiteClasses({TestA.class, TestB.class})
public class TestSuite {
@BeforeClass
public static void setUp() {
throw new RuntimeException("ex");
}
}
{code}
If i execute:
mvn clean install -Dtest=TestSuite -Dparallel=classes -DthreadCount=2
-DfailIfNoTests=false
the build succeeds. If I omit the -DfailIfNoTests=false the build fails, but
not because of the thrown exception, but with "No tests were executed!". If i
omit the parallel parameter the build fails appropriately with "There are test
failures."
> Exception in a @BeforeClass method in a JUnit suite class does not fail the
> build if ran in parallel
>
>
> Key: SUREFIRE-1525
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1525
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.21.0
>Reporter: Ivan Syarov
>Priority: Major
>
> I have a @BeforeClass annotated method in a JUnit test suite class, and if an
> exception is thrown in the method, the parallel build either succeeds if the
> *-DfailIfNoTests* parameter is set to false or fails with "No tests were
> executed" if the parameter is set to true. If the build is started without
> the *parallel* parameter it fails as it should.
> I used a simple project setup to reproduce. I have two test classes, each
> with one test method and a suite class:
> *TestA.class*
> {code:java}
> public class TestA {
> @Test
> public void test() {
> System.out.println("TestA");
> }
> }
> {code}
> *TestB.class*
> {code:java}
> public class TestB {
> @Test
> public void test() {
> System.out.println("TestB");
> }
> }
> {code}
> *TestSuite.class*
> {code:java}
> @RunWith(Suite.class)
> @SuiteClasses({TestA.class, TestB.class})
> public class TestSuite {
> @BeforeClass
> public static void setUp() {
> throw new RuntimeException("ex");
> }
> }
> {code}
> If i execute:
> mvn clean install -Dtest=TestSuite -Dparallel=classes -DthreadCount=2
> -DfailIfNoTests=false
> the build succeeds. If I omit the -DfailIfNoTests=false the build fails, but
> not because of the thrown exception, but with "No tests were executed!". If i
> omit the parallel parameter the build fails appropriately with "There are
> test failures."
> The JUnit version is 4.12
> The failsafe plugin version is 2.19.1 - 2.21.0
>
--
This
[jira] [Updated] (SUREFIRE-1525) Exception in a @BeforeClass method in a JUnit suite class does not fail the build if ran in parallel
[
https://issues.apache.org/jira/browse/SUREFIRE-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Syarov updated SUREFIRE-1525:
--
Description:
I have a @BeforeClass annotated method in a JUnit test suite class, and if an
exception is thrown in the method, the parallel build either succeeds if the
*-DfailIfNoTests* parameter is set to false or fails with "No tests were
executed" if the parameter is set to true. If the build is started without the
*parallel* parameter it fails as it should.
I used a simple project setup to reproduce. I have two test classes, each with
one test method and a suite class:
*TestA.class*
{code:java}
public class TestA {
@Test
public void test() {
System.out.println("TestA");
}
}
{code}
*TestB.class*
{code:java}
public class TestB {
@Test
public void test() {
System.out.println("TestB");
}
}
{code}
*TestSuite.class*
{code:java}
@RunWith(Suite.class)
@SuiteClasses({TestA.class, TestB.class})
public class TestSuite {
@BeforeClass
public static void setUp() {
throw new RuntimeException("ex");
}
}
{code}
If i execute:
mvn clean install -Dtest=TestSuite -Dparallel=classes -DthreadCount=2
-DfailIfNoTests=false
the build succeeds. If I omit the -DfailIfNoTests=false the build fails, but
not because of the thrown exception, but with "No tests were executed!". If i
omit the parallel parameter the build fails appropriately with "There are test
failures."
was:
I have a @BeforeClass annotated method in a JUnit test suite class, and if an
exception is thrown in the method, the parallel build either succeeds if the
*-DfailIfNoTests* parameter is set to false or fails with "No tests were
executed" if the parameter is set to true. If the build is started without the
*parallel* parameter it fails as it should.
I used a simple project setup to reproduce. I have two test classes, each with
one test method and a suite class:
*TestA.class*
{code:java}
public class TestA {
@Test
public void test() {
System.out.println("TestA");
}
}
{code}
*TestB.class*
{code:java}
public class TestB {
@Test
public void test() {
System.out.println("TestB");
}
}
{code}
*TestSuite.class*
{code:java}
@RunWith(Suite.class)
@SuiteClasses({TestA.class, TestB.class})
public class TestSuite {
@BeforeClass
public static void setUp() {
throw new RuntimeException("happened");
}
}
{code}
If i execute:
mvn clean install -Dtest=TestSuite -Dparallel=classes -DthreadCount=2
-DfailIfNoTests=false
the build succeeds. If I omit the -DfailIfNoTests=false the build fails, but
not because of the thrown exception, but with "No tests were executed!". If i
omit the parallel parameter the build fails appropriately with "There are test
failures."
> Exception in a @BeforeClass method in a JUnit suite class does not fail the
> build if ran in parallel
>
>
> Key: SUREFIRE-1525
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1525
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.21.0
>Reporter: Ivan Syarov
>Priority: Major
>
> I have a @BeforeClass annotated method in a JUnit test suite class, and if an
> exception is thrown in the method, the parallel build either succeeds if the
> *-DfailIfNoTests* parameter is set to false or fails with "No tests were
> executed" if the parameter is set to true. If the build is started without
> the *parallel* parameter it fails as it should.
> I used a simple project setup to reproduce. I have two test classes, each
> with one test method and a suite class:
> *TestA.class*
> {code:java}
> public class TestA {
> @Test
> public void test() {
> System.out.println("TestA");
> }
> }
> {code}
> *TestB.class*
> {code:java}
> public class TestB {
> @Test
> public void test() {
> System.out.println("TestB");
> }
> }
> {code}
> *TestSuite.class*
> {code:java}
> @RunWith(Suite.class)
> @SuiteClasses({TestA.class, TestB.class})
> public class TestSuite {
> @BeforeClass
> public static void setUp() {
> throw new RuntimeException("ex");
> }
> }
> {code}
> If i execute:
> mvn clean install -Dtest=TestSuite -Dparallel=classes -DthreadCount=2
> -DfailIfNoTests=false
> the build succeeds. If I omit the -DfailIfNoTests=false the build fails, but
> not because of the thrown exception, but with "No tests were executed!". If i
> omit the parallel parameter the build fails appropriately with "There are
> test failures."
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1525) Exception in a @BeforeClass method in a JUnit suite class does not fail the build if ran in parallel
[
https://issues.apache.org/jira/browse/SUREFIRE-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Syarov updated SUREFIRE-1525:
--
Description:
I have a @BeforeClass annotated method in a JUnit test suite class, and if an
exception is thrown in the method, the parallel build either succeeds if the
*-DfailIfNoTests* parameter is set to false or fails with "No tests were
executed" if the parameter is set to true. If the build is started without the
*parallel* parameter it fails as it should.
I used a simple project setup to reproduce. I have two test classes, each with
one test method and a suite class:
*TestA.class*
{code:java}
public class TestA {
@Test
public void test() {
System.out.println("TestA");
}
}
{code}
*TestB.class*
{code:java}
public class TestB {
@Test
public void test() {
System.out.println("TestB");
}
}
{code}
*TestSuite.class*
{code:java}
@RunWith(Suite.class)
@SuiteClasses({TestA.class, TestB.class})
public class TestSuite {
@BeforeClass
public static void setUp() {
throw new RuntimeException("happened");
}
}
{code}
If i execute:
mvn clean install -Dtest=TestSuite -Dparallel=classes -DthreadCount=2
-DfailIfNoTests=false
the build succeeds. If I omit the -DfailIfNoTests=false the build fails, but
not because of the thrown exception, but with "No tests were executed!". If i
omit the parallel parameter the build fails appropriately with "There are test
failures."
was:
I have a @BeforeClass annotated method in a JUnit test suite class, and if an
exception is thrown in the method, the parallel build either succeeds if the
*-DfailIfNoTests* parameter is set to false or fails with "No tests were
executed" if the parameter is set to true. If the build is started without the
*parallel* parameter it fails as it should.
I used a simple project setup to reproduce. I have two test classes, each with
one test method and a suite class:
*TestA.class*
public class TestA {
@Test
public void test() {
System.out.println("TestA");
}
}
*TestB.class*
public class TestB {
@Test
public void test() {
System.out.println("TestB");
}
}
*TestSuite.class*
@RunWith(Suite.class)
@SuiteClasses(\{TestA.class, TestB.class})
public class TestSuite {
@BeforeClass
public static void setUp() {
throw new RuntimeException("ex");
}
}
If i execute:
mvn clean install -Dtest=TestSuite -Dparallel=classes -DthreadCount=2
-DfailIfNoTests=false
the build succeeds. If I omit the -DfailIfNoTests=false the build fails, but
not because of the thrown exception, but with "No tests were executed!". If i
omit the parallel parameter the build fails appropriately with "There are test
failures."
> Exception in a @BeforeClass method in a JUnit suite class does not fail the
> build if ran in parallel
>
>
> Key: SUREFIRE-1525
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1525
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.21.0
>Reporter: Ivan Syarov
>Priority: Major
>
> I have a @BeforeClass annotated method in a JUnit test suite class, and if an
> exception is thrown in the method, the parallel build either succeeds if the
> *-DfailIfNoTests* parameter is set to false or fails with "No tests were
> executed" if the parameter is set to true. If the build is started without
> the *parallel* parameter it fails as it should.
> I used a simple project setup to reproduce. I have two test classes, each
> with one test method and a suite class:
> *TestA.class*
> {code:java}
> public class TestA {
> @Test
> public void test() {
> System.out.println("TestA");
> }
> }
> {code}
> *TestB.class*
> {code:java}
> public class TestB {
> @Test
> public void test() {
> System.out.println("TestB");
> }
> }
> {code}
> *TestSuite.class*
> {code:java}
> @RunWith(Suite.class)
> @SuiteClasses({TestA.class, TestB.class})
> public class TestSuite {
> @BeforeClass
> public static void setUp() {
> throw new RuntimeException("happened");
> }
> }
> {code}
> If i execute:
> mvn clean install -Dtest=TestSuite -Dparallel=classes -DthreadCount=2
> -DfailIfNoTests=false
> the build succeeds. If I omit the -DfailIfNoTests=false the build fails, but
> not because of the thrown exception, but with "No tests were executed!". If i
> omit the parallel parameter the build fails appropriately with "There are
> test failures."
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SUREFIRE-1525) Exception in a @BeforeClass method in a JUnit suite class does not fail the build if ran in parallel
Ivan Syarov created SUREFIRE-1525:
-
Summary: Exception in a @BeforeClass method in a JUnit suite class
does not fail the build if ran in parallel
Key: SUREFIRE-1525
URL: https://issues.apache.org/jira/browse/SUREFIRE-1525
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.7+ (parallel) support
Affects Versions: 2.21.0
Reporter: Ivan Syarov
I have a @BeforeClass annotated method in a JUnit test suite class, and if an
exception is thrown in the method, the parallel build either succeeds if the
*-DfailIfNoTests* parameter is set to false or fails with "No tests were
executed" if the parameter is set to true. If the build is started without the
*parallel* parameter it fails as it should.
I used a simple project setup to reproduce. I have two test classes, each with
one test method and a suite class:
*TestA.class*
public class TestA {
@Test
public void test() {
System.out.println("TestA");
}
}
*TestB.class*
public class TestB {
@Test
public void test() {
System.out.println("TestB");
}
}
*TestSuite.class*
@RunWith(Suite.class)
@SuiteClasses(\{TestA.class, TestB.class})
public class TestSuite {
@BeforeClass
public static void setUp() {
throw new RuntimeException("ex");
}
}
If i execute:
mvn clean install -Dtest=TestSuite -Dparallel=classes -DthreadCount=2
-DfailIfNoTests=false
the build succeeds. If I omit the -DfailIfNoTests=false the build fails, but
not because of the thrown exception, but with "No tests were executed!". If i
omit the parallel parameter the build fails appropriately with "There are test
failures."
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
