[jira] [Updated] (MJAR-234) Class-Path: attribute in manifest shouldn't have broken names
[ https://issues.apache.org/jira/browse/MJAR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Brandizi updated MJAR-234: Description: I'd like to reopen https://issues.apache.org/jira/browse/MJAR-121: in MANIFEST.MF, when you spawn a list like this for Class-Path: Class-Path: commons-lang-2.4.jar plexus-utils-1.1.jar workflow-base-1. 0.4-SNAPSHOT.jar commons-cli-1.2.jar (there is a space before 0.4, JIRA is not rendering it here) Java doesn't see the classes in workflow-base-1.0.4-SNAPSHOT.jar, which has a break in between. If I change it to list one jar per line (with two spaces at the begin of the line), it works as expected. Also note I do put a blank line at the end in both cases. Generating that list the way you do might be compatible with the jar specifications, but Java 8 apparently isn't compatible with them and hence the end result is a failing JAR. The first fix coming in my mind is to list the files on separated lines. was: I'd like to reopen https://issues.apache.org/jira/browse/MJAR-121: in MANIFEST.MF, when you spawn a list like this for Class-Path: Class-Path: commons-lang-2.4.jar plexus-utils-1.1.jar workflow-base-1. 0.4-SNAPSHOT.jar commons-cli-1.2.jar Java doesn't see the classes in workflow-base-1.0.4-SNAPSHOT.jar, which has a break in between. If I change it to list one jar per line (with two spaces at the begin of the line), it works as expected. Also note I do put a blank line at the end in both cases. Generating that list the way you do might be compatible with the jar specifications, but Java 8 apparently isn't compatible with them and hence the end result is a failing JAR. The first fix coming in my mind is to list the files on separated lines. > Class-Path: attribute in manifest shouldn't have broken names > - > > Key: MJAR-234 > URL: https://issues.apache.org/jira/browse/MJAR-234 > Project: Maven JAR Plugin > Issue Type: Bug > Environment: 10:20:02 $ mvn --version > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T16:41:47+00:00) > Maven home: /Applications/local/dev/maven > Java version: 1.8.0_121, vendor: Oracle Corporation > Java home: > /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: "mac" > 10:21:57 $ > I've tried the 3.0.2 version of the jar plug-in >Reporter: Marco Brandizi > Labels: manifest > > I'd like to reopen https://issues.apache.org/jira/browse/MJAR-121: in > MANIFEST.MF, when you spawn a list like this for Class-Path: > Class-Path: commons-lang-2.4.jar plexus-utils-1.1.jar workflow-base-1. > 0.4-SNAPSHOT.jar commons-cli-1.2.jar > (there is a space before 0.4, JIRA is not rendering it here) > Java doesn't see the classes in workflow-base-1.0.4-SNAPSHOT.jar, which has a > break in between. If I change it to list one jar per line (with two spaces at > the begin of the line), it works as expected. Also note I do put a blank line > at the end in both cases. > Generating that list the way you do might be compatible with the jar > specifications, but Java 8 apparently isn't compatible with them and hence > the end result is a failing JAR. > The first fix coming in my mind is to list the files on separated lines. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MJAR-234) Class-Path: attribute in manifest shouldn't have broken names
[ https://issues.apache.org/jira/browse/MJAR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Brandizi updated MJAR-234: Description: I'd like to reopen https://issues.apache.org/jira/browse/MJAR-121: in MANIFEST.MF, when you spawn a list like this for Class-Path: Class-Path: commons-lang-2.4.jar plexus-utils-1.1.jar workflow-base-1. 0.4-SNAPSHOT.jar commons-cli-1.2.jar (there is a space before 0.4, JIRA is not rendering it here) Java doesn't see the classes in workflow-base-1.0.4-SNAPSHOT.jar, which has a break in between. If I change it manually, to list one jar per line (with two spaces at the begin of the line), it works as expected. Also note I do put a blank line at the end in both cases. Generating that list the way you do might be compatible with the jar specifications, but Java 8 apparently isn't compatible with them and hence the end result is a failing JAR. The first fix coming in my mind is to list one jar per line, as I did. was: I'd like to reopen https://issues.apache.org/jira/browse/MJAR-121: in MANIFEST.MF, when you spawn a list like this for Class-Path: Class-Path: commons-lang-2.4.jar plexus-utils-1.1.jar workflow-base-1. 0.4-SNAPSHOT.jar commons-cli-1.2.jar (there is a space before 0.4, JIRA is not rendering it here) Java doesn't see the classes in workflow-base-1.0.4-SNAPSHOT.jar, which has a break in between. If I change it manually, to list one jar per line (with two spaces at the begin of the line), it works as expected. Also note I do put a blank line at the end in both cases. Generating that list the way you do might be compatible with the jar specifications, but Java 8 apparently isn't compatible with them and hence the end result is a failing JAR. The first fix coming in my mind is to list the files on separated lines. > Class-Path: attribute in manifest shouldn't have broken names > - > > Key: MJAR-234 > URL: https://issues.apache.org/jira/browse/MJAR-234 > Project: Maven JAR Plugin > Issue Type: Bug > Environment: 10:20:02 $ mvn --version > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T16:41:47+00:00) > Maven home: /Applications/local/dev/maven > Java version: 1.8.0_121, vendor: Oracle Corporation > Java home: > /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: "mac" > 10:21:57 $ > I've tried the 3.0.2 version of the jar plug-in >Reporter: Marco Brandizi > Labels: manifest > > I'd like to reopen https://issues.apache.org/jira/browse/MJAR-121: in > MANIFEST.MF, when you spawn a list like this for Class-Path: > Class-Path: commons-lang-2.4.jar plexus-utils-1.1.jar workflow-base-1. > 0.4-SNAPSHOT.jar commons-cli-1.2.jar > (there is a space before 0.4, JIRA is not rendering it here) > Java doesn't see the classes in workflow-base-1.0.4-SNAPSHOT.jar, which has a > break in between. If I change it manually, to list one jar per line (with two > spaces at the begin of the line), it works as expected. Also note I do put a > blank line at the end in both cases. > Generating that list the way you do might be compatible with the jar > specifications, but Java 8 apparently isn't compatible with them and hence > the end result is a failing JAR. > The first fix coming in my mind is to list one jar per line, as I did. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-6193) Properties not working in parent version tag
[
https://issues.apache.org/jira/browse/MNG-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niklas Grebe updated MNG-6193:
--
Description:
Using properties in the parent version tag isn't working and gives an error:
{noformat}
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for com.foo.bar:some-parent:1.0-SNAPSHOT:
Failure to find
org.springframework.boot:spring-boot-starter-parent:pom:${spring.boot.version}
in https://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central has
elapsed or updates are forced and 'parent.relativePath' points at wrong local
POM @ line 19, column 10
{noformat}
It seems like the variable isn't replaced in the parent version tag. I've added
my test pom.xml as an attachment. If you replace the variable with the actual
version it works fine.
was:
Using properties in the parent version tag isn't working and gives an error:
{noformat}
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for com.foo.bar:some-parent:1.0-SNAPSHOT:
Failure to find
org.springframework.boot:spring-boot-starter-parent:pom:${spring.boot.version}
in https://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central has
elapsed or updates are forced and 'parent.relativePath' points at wrong local
POM @ line 19, column 10
{noformat}
It seems like the ${var.name} isn't replaced in the parent version tag. I've
added my test pom.xml as an attachment. If you replace the
${spring.boot.version} with the actual version it works fine.
> Properties not working in parent version tag
>
>
> Key: MNG-6193
> URL: https://issues.apache.org/jira/browse/MNG-6193
> Project: Maven
> Issue Type: Bug
>Reporter: Niklas Grebe
>Priority: Minor
> Attachments: pom.xml
>
>
> Using properties in the parent version tag isn't working and gives an error:
> {noformat}
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for com.foo.bar:some-parent:1.0-SNAPSHOT:
> Failure to find
> org.springframework.boot:spring-boot-starter-parent:pom:${spring.boot.version}
> in https://repo.maven.apache.org/maven2 was cached in the local repository,
> resolution will not be reattempted until the update interval of central has
> elapsed or updates are forced and 'parent.relativePath' points at wrong local
> POM @ line 19, column 10
> {noformat}
> It seems like the variable isn't replaced in the parent version tag. I've
> added my test pom.xml as an attachment. If you replace the variable with the
> actual version it works fine.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MNG-6193) Properties not working in parent version tag
Niklas Grebe created MNG-6193:
-
Summary: Properties not working in parent version tag
Key: MNG-6193
URL: https://issues.apache.org/jira/browse/MNG-6193
Project: Maven
Issue Type: Bug
Reporter: Niklas Grebe
Priority: Minor
Attachments: pom.xml
Using properties in the parent version tag isn't working and gives an error:
{noformat}
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for com.foo.bar:some-parent:1.0-SNAPSHOT:
Failure to find
org.springframework.boot:spring-boot-starter-parent:pom:${spring.boot.version}
in https://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central has
elapsed or updates are forced and 'parent.relativePath' points at wrong local
POM @ line 19, column 10
{noformat}
It seems like the ${var.name} isn't replaced in the parent version tag. I've
added my test pom.xml as an attachment. If you replace the
${spring.boot.version} with the actual version it works fine.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MJAR-234) Class-Path: attribute in manifest shouldn't have broken names
Marco Brandizi created MJAR-234: --- Summary: Class-Path: attribute in manifest shouldn't have broken names Key: MJAR-234 URL: https://issues.apache.org/jira/browse/MJAR-234 Project: Maven JAR Plugin Issue Type: Bug Environment: 10:20:02 $ mvn --version Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T16:41:47+00:00) Maven home: /Applications/local/dev/maven Java version: 1.8.0_121, vendor: Oracle Corporation Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre Default locale: en_GB, platform encoding: UTF-8 OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: "mac" 10:21:57 $ I've tried the 3.0.2 version of the jar plug-in Reporter: Marco Brandizi I'd like to reopen https://issues.apache.org/jira/browse/MJAR-121: in MANIFEST.MF, when you spawn a list like this for Class-Path: Class-Path: commons-lang-2.4.jar plexus-utils-1.1.jar workflow-base-1. 0.4-SNAPSHOT.jar commons-cli-1.2.jar Java doesn't see the classes in workflow-base-1.0.4-SNAPSHOT.jar, which has a break in between. If I change it to list one jar per line (with two spaces at the begin of the line), it works as expected. Also note I do put a blank line at the end in both cases. Generating that list the way you do might be compatible with the jar specifications, but Java 8 apparently isn't compatible with them and hence the end result is a failing JAR. The first fix coming in my mind is to list the files on separated lines. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MJAR-234) Class-Path: attribute in manifest shouldn't have broken names
[ https://issues.apache.org/jira/browse/MJAR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Brandizi updated MJAR-234: Description: I'd like to reopen https://issues.apache.org/jira/browse/MJAR-121: in MANIFEST.MF, when you spawn a list like this for Class-Path: Class-Path: commons-lang-2.4.jar plexus-utils-1.1.jar workflow-base-1. 0.4-SNAPSHOT.jar commons-cli-1.2.jar (there is a space before 0.4, JIRA is not rendering it here) Java doesn't see the classes in workflow-base-1.0.4-SNAPSHOT.jar, which has a break in between. If I change it manually, to list one jar per line (with two spaces at the begin of the line), it works as expected. Also note I do put a blank line at the end in both cases. Generating that list the way you do might be compatible with the jar specifications, but Java 8 apparently isn't compatible with them and hence the end result is a failing JAR. The first fix coming in my mind is to list the files on separated lines. was: I'd like to reopen https://issues.apache.org/jira/browse/MJAR-121: in MANIFEST.MF, when you spawn a list like this for Class-Path: Class-Path: commons-lang-2.4.jar plexus-utils-1.1.jar workflow-base-1. 0.4-SNAPSHOT.jar commons-cli-1.2.jar (there is a space before 0.4, JIRA is not rendering it here) Java doesn't see the classes in workflow-base-1.0.4-SNAPSHOT.jar, which has a break in between. If I change it to list one jar per line (with two spaces at the begin of the line), it works as expected. Also note I do put a blank line at the end in both cases. Generating that list the way you do might be compatible with the jar specifications, but Java 8 apparently isn't compatible with them and hence the end result is a failing JAR. The first fix coming in my mind is to list the files on separated lines. > Class-Path: attribute in manifest shouldn't have broken names > - > > Key: MJAR-234 > URL: https://issues.apache.org/jira/browse/MJAR-234 > Project: Maven JAR Plugin > Issue Type: Bug > Environment: 10:20:02 $ mvn --version > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T16:41:47+00:00) > Maven home: /Applications/local/dev/maven > Java version: 1.8.0_121, vendor: Oracle Corporation > Java home: > /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: "mac" > 10:21:57 $ > I've tried the 3.0.2 version of the jar plug-in >Reporter: Marco Brandizi > Labels: manifest > > I'd like to reopen https://issues.apache.org/jira/browse/MJAR-121: in > MANIFEST.MF, when you spawn a list like this for Class-Path: > Class-Path: commons-lang-2.4.jar plexus-utils-1.1.jar workflow-base-1. > 0.4-SNAPSHOT.jar commons-cli-1.2.jar > (there is a space before 0.4, JIRA is not rendering it here) > Java doesn't see the classes in workflow-base-1.0.4-SNAPSHOT.jar, which has a > break in between. If I change it manually, to list one jar per line (with two > spaces at the begin of the line), it works as expected. Also note I do put a > blank line at the end in both cases. > Generating that list the way you do might be compatible with the jar > specifications, but Java 8 apparently isn't compatible with them and hence > the end result is a failing JAR. > The first fix coming in my mind is to list the files on separated lines. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MJAR-234) Class-Path: attribute in manifest shouldn't have broken names
[ https://issues.apache.org/jira/browse/MJAR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15940638#comment-15940638 ] Karl Heinz Marbaise commented on MJAR-234: -- Do you have an example project which shows the behaviour ? > Class-Path: attribute in manifest shouldn't have broken names > - > > Key: MJAR-234 > URL: https://issues.apache.org/jira/browse/MJAR-234 > Project: Maven JAR Plugin > Issue Type: Bug > Environment: 10:20:02 $ mvn --version > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T16:41:47+00:00) > Maven home: /Applications/local/dev/maven > Java version: 1.8.0_121, vendor: Oracle Corporation > Java home: > /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: "mac" > 10:21:57 $ > I've tried the 3.0.2 version of the jar plug-in >Reporter: Marco Brandizi > Labels: manifest > > I'd like to reopen https://issues.apache.org/jira/browse/MJAR-121: in > MANIFEST.MF, when you spawn a list like this for Class-Path: > Class-Path: commons-lang-2.4.jar plexus-utils-1.1.jar workflow-base-1. > 0.4-SNAPSHOT.jar commons-cli-1.2.jar > (there is a space before 0.4, JIRA is not rendering it here) > Java doesn't see the classes in workflow-base-1.0.4-SNAPSHOT.jar, which has a > break in between. If I change it manually, to list one jar per line (with two > spaces at the begin of the line), it works as expected. Also note I do put a > blank line at the end in both cases. > Generating that list the way you do might be compatible with the jar > specifications, but Java 8 apparently isn't compatible with them and hence > the end result is a failing JAR. > The first fix coming in my mind is to list one jar per line, as I did. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6168) Fix unclosed streams
[ https://issues.apache.org/jira/browse/MNG-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-6168: -- Assignee: Christian Schulte > Fix unclosed streams > > > Key: MNG-6168 > URL: https://issues.apache.org/jira/browse/MNG-6168 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9 >Reporter: Michael Osipov >Assignee: Christian Schulte > Fix For: 3.5.0-candidate > > > Based on > [0535716fd602eb056ed791b89d7f9a3fb882499c|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=0535716fd602eb056ed791b89d7f9a3fb882499c]. > several streams remain unclosed or contain some boilterplate code. Let's > clean that up. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6191) mvn -f complains about illegal readlink option under macOS
[
https://issues.apache.org/jira/browse/MNG-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15941175#comment-15941175
]
Stephen Connolly commented on MNG-6191:
---
Seems to work on quick tests that I have done on macOS and linux... I'll leave
it up to the shell experts to decide if it is the best solution
(the alternative would be to add specific uname detection for macOS and then
use this command on macOS only (and use the existing
{code}
basedir=$(dirname "$(readlink -f "${arg}")")
{code}
for other unixes - note I think there is a missing layer of quotes in that form
too)
> mvn -f complains about illegal readlink option under macOS
> --
>
> Key: MNG-6191
> URL: https://issues.apache.org/jira/browse/MNG-6191
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0-alpha-1
> Environment: Java version: 1.8.0_111, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.10.5", arch: "x86_64", family: "mac"
>Reporter: Andreas Sewe
>Priority: Minor
>
> This is a *regression* from Maven 3.3.9. With 3.5.0-alpha-1, using {{mvn -f}}
> under OS X causes the following error to be printed out (similar to
> MNG-5688), before the command proceeds (AFAICT) without error:
> {noformat}
> > mvn clean package -f releng/repository/pom.xml
> readlink: illegal option -- f
> usage: readlink [-n] [file ...]
> usage: dirname path
> [INFO] Scanning for projects...
> {noformat}
> FWIW, I don’t get this error on a normal {{mvn clean package}} without the
> {{-f}} parameter.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MJAR-234) Class-Path: attribute in manifest shouldn't have broken names
[ https://issues.apache.org/jira/browse/MJAR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15940977#comment-15940977 ] Marco Brandizi commented on MJAR-234: - [~khmarbaise], sorry, I can't. I mean, I have an internal complicated project that behaves like I said, but, when I tried to reproduce the problem with a simple isolated project, it works correctly, despite producing the same format in the manifest. Sorry for having bothered, I guess this bug should be closed and I should stop debugging for today, before it leads me to bang my head on the wall... > Class-Path: attribute in manifest shouldn't have broken names > - > > Key: MJAR-234 > URL: https://issues.apache.org/jira/browse/MJAR-234 > Project: Maven JAR Plugin > Issue Type: Bug > Environment: 10:20:02 $ mvn --version > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T16:41:47+00:00) > Maven home: /Applications/local/dev/maven > Java version: 1.8.0_121, vendor: Oracle Corporation > Java home: > /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: "mac" > 10:21:57 $ > I've tried the 3.0.2 version of the jar plug-in >Reporter: Marco Brandizi > Labels: manifest > > I'd like to reopen https://issues.apache.org/jira/browse/MJAR-121: in > MANIFEST.MF, when you spawn a list like this for Class-Path: > Class-Path: commons-lang-2.4.jar plexus-utils-1.1.jar workflow-base-1. > 0.4-SNAPSHOT.jar commons-cli-1.2.jar > (there is a space before 0.4, JIRA is not rendering it here) > Java doesn't see the classes in workflow-base-1.0.4-SNAPSHOT.jar, which has a > break in between. If I change it manually, to list one jar per line (with two > spaces at the begin of the line), it works as expected. Also note I do put a > blank line at the end in both cases. > Generating that list the way you do might be compatible with the jar > specifications, but Java 8 apparently isn't compatible with them and hence > the end result is a failing JAR. > The first fix coming in my mind is to list one jar per line, as I did. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6191) mvn -f complains about illegal readlink option under macOS
[
https://issues.apache.org/jira/browse/MNG-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15941171#comment-15941171
]
Stephen Connolly commented on MNG-6191:
---
how about
{code}
basedir="$(cd "$(dirname "${arg}")" && pwd -P)"
{code}
> mvn -f complains about illegal readlink option under macOS
> --
>
> Key: MNG-6191
> URL: https://issues.apache.org/jira/browse/MNG-6191
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0-alpha-1
> Environment: Java version: 1.8.0_111, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.10.5", arch: "x86_64", family: "mac"
>Reporter: Andreas Sewe
>Priority: Minor
>
> This is a *regression* from Maven 3.3.9. With 3.5.0-alpha-1, using {{mvn -f}}
> under OS X causes the following error to be printed out (similar to
> MNG-5688), before the command proceeds (AFAICT) without error:
> {noformat}
> > mvn clean package -f releng/repository/pom.xml
> readlink: illegal option -- f
> usage: readlink [-n] [file ...]
> usage: dirname path
> [INFO] Scanning for projects...
> {noformat}
> FWIW, I don’t get this error on a normal {{mvn clean package}} without the
> {{-f}} parameter.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SCM-845) Maven Release Plugin releases SNAPSHOT instead of STABLE version (jgit)
Archimedes Trajano created SCM-845: -- Summary: Maven Release Plugin releases SNAPSHOT instead of STABLE version (jgit) Key: SCM-845 URL: https://issues.apache.org/jira/browse/SCM-845 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-jgit Affects Versions: 1.9.5 Reporter: Archimedes Trajano I just tried to do a release with the exact scenario as https://issues.apache.org/jira/browse/SCM-740 and had the same result. The SCM-740 provided a fix for gitexe which I verified works when I switched to that provider, but jgit has the same issue -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SCM-845) Maven Release Plugin releases SNAPSHOT instead of STABLE version (jgit)
[ https://issues.apache.org/jira/browse/SCM-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Archimedes Trajano updated SCM-845: --- Description: I just tried to do a release with the exact scenario as SCM-740 and had the same result. The SCM-740 provided a fix for gitexe which I verified works when I switched to that provider, but jgit has the same issue (was: I just tried to do a release with the exact scenario as https://issues.apache.org/jira/browse/SCM-740 and had the same result. The SCM-740 provided a fix for gitexe which I verified works when I switched to that provider, but jgit has the same issue) > Maven Release Plugin releases SNAPSHOT instead of STABLE version (jgit) > --- > > Key: SCM-845 > URL: https://issues.apache.org/jira/browse/SCM-845 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-jgit >Affects Versions: 1.9.5 >Reporter: Archimedes Trajano > > I just tried to do a release with the exact scenario as SCM-740 and had the > same result. The SCM-740 provided a fix for gitexe which I verified works > when I switched to that provider, but jgit has the same issue -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6168) Fix unclosed streams
[ https://issues.apache.org/jira/browse/MNG-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15941455#comment-15941455 ] Hudson commented on MNG-6168: - SUCCESS: Integrated in Jenkins build maven-3.x #1581 (See [https://builds.apache.org/job/maven-3.x/1581/]) [MNG-6168] Fix unclosed streams (schulte: [http://git-wip-us.apache.org/repos/asf/?p=maven.git=commit=0931bb2cc7630cc79adb98407db13315b4a709ee]) * (edit) maven-settings-builder/src/main/java/org/apache/maven/settings/io/DefaultSettingsWriter.java * (edit) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionResolver.java * (edit) maven-core/src/main/java/org/apache/maven/artifact/repository/metadata/io/DefaultMetadataReader.java * (edit) maven-model-builder/src/main/java/org/apache/maven/model/io/DefaultModelWriter.java * (edit) maven-core/src/main/java/org/apache/maven/toolchain/io/DefaultToolchainsReader.java * (edit) maven-settings-builder/src/main/java/org/apache/maven/settings/io/DefaultSettingsReader.java * (edit) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java * (edit) maven-model-builder/src/main/java/org/apache/maven/model/io/DefaultModelReader.java > Fix unclosed streams > > > Key: MNG-6168 > URL: https://issues.apache.org/jira/browse/MNG-6168 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9 >Reporter: Michael Osipov >Assignee: Christian Schulte > Fix For: 3.5.0 > > > Based on > [0535716fd602eb056ed791b89d7f9a3fb882499c|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=0535716fd602eb056ed791b89d7f9a3fb882499c]. > several streams remain unclosed or contain some boilterplate code. Let's > clean that up. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MNG-6168) Fix unclosed streams
[ https://issues.apache.org/jira/browse/MNG-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MNG-6168. -- Resolution: Fixed Fix Version/s: (was: 3.5.0-candidate) 3.5.0 > Fix unclosed streams > > > Key: MNG-6168 > URL: https://issues.apache.org/jira/browse/MNG-6168 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9 >Reporter: Michael Osipov >Assignee: Christian Schulte > Fix For: 3.5.0 > > > Based on > [0535716fd602eb056ed791b89d7f9a3fb882499c|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=0535716fd602eb056ed791b89d7f9a3fb882499c]. > several streams remain unclosed or contain some boilterplate code. Let's > clean that up. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (MJAR-234) Class-Path: attribute in manifest shouldn't have broken names
[ https://issues.apache.org/jira/browse/MJAR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15940977#comment-15940977 ] Marco Brandizi edited comment on MJAR-234 at 3/25/17 12:53 AM: --- [~khmarbaise], sorry, I can't. I mean, I have an internal complicated project that behaves like I said, but, when I tried to reproduce the problem with a simple isolated project, that worked correctly, despite producing the same format in the manifest. Sorry for having bothered, I guess this bug should be closed and I should stop debugging for today, before it leads me to bang my head on the wall... was (Author: zakmck): [~khmarbaise], sorry, I can't. I mean, I have an internal complicated project that behaves like I said, but, when I tried to reproduce the problem with a simple isolated project, it works correctly, despite producing the same format in the manifest. Sorry for having bothered, I guess this bug should be closed and I should stop debugging for today, before it leads me to bang my head on the wall... > Class-Path: attribute in manifest shouldn't have broken names > - > > Key: MJAR-234 > URL: https://issues.apache.org/jira/browse/MJAR-234 > Project: Maven JAR Plugin > Issue Type: Bug > Environment: 10:20:02 $ mvn --version > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T16:41:47+00:00) > Maven home: /Applications/local/dev/maven > Java version: 1.8.0_121, vendor: Oracle Corporation > Java home: > /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: "mac" > 10:21:57 $ > I've tried the 3.0.2 version of the jar plug-in >Reporter: Marco Brandizi > Labels: manifest > > I'd like to reopen https://issues.apache.org/jira/browse/MJAR-121: in > MANIFEST.MF, when you spawn a list like this for Class-Path: > Class-Path: commons-lang-2.4.jar plexus-utils-1.1.jar workflow-base-1. > 0.4-SNAPSHOT.jar commons-cli-1.2.jar > (there is a space before 0.4, JIRA is not rendering it here) > Java doesn't see the classes in workflow-base-1.0.4-SNAPSHOT.jar, which has a > break in between. If I change it manually, to list one jar per line (with two > spaces at the begin of the line), it works as expected. Also note I do put a > blank line at the end in both cases. > Generating that list the way you do might be compatible with the jar > specifications, but Java 8 apparently isn't compatible with them and hence > the end result is a failing JAR. > The first fix coming in my mind is to list one jar per line, as I did. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MCOMPILER-291) No possible use compilerArgs arg "-J--add-opens" multiple times
Pascal Schumacher created MCOMPILER-291:
---
Summary: No possible use compilerArgs arg "-J--add-opens" multiple
times
Key: MCOMPILER-291
URL: https://issues.apache.org/jira/browse/MCOMPILER-291
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.6.1
Reporter: Pascal Schumacher
I'm trying to a project with uses lombok to work with java 9.
{code}
org.apache.maven.plugins
maven-compiler-plugin
3.6.1
1.8
1.8
true
-J--add-opens-Jjdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED
-J--add-opens-Jjdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED
-J--add-opens-Jjdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED
-J--add-opens-Jjdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED
-J--add-opens-Jjdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED
-J--add-opens-Jjdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED
-J--add-opens-Jjdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED
-J--add-opens-Jjdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED
-J--add-opens-Jjdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED
{code}
{code}mvn -X compile{code} shows me that the {code}-J--add-opens{code}
arguments are collapsed:
{code}
cmd.exe /X /C ""C:\Program Files\Java\jdk-9\bin\javac.exe"
@C:/Users/User/random-beans/random-beans/target/classes/org.codehaus.plexus.compiler.javac.JavacCompiler9403484282707867963arguments
-J--add-opens -Jjdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED
-Jjdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED
-Jjdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED
-Jjdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED
-Jjdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED
-Jjdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED
-Jjdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED
-Jjdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED
-Jjdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED"
{code}
which results in:
{code}Error: Main Class jdk.compiler.com.sun.tools.javac.util=ALL-UNNAMED could
not be found or load{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6193) Properties not working in parent version tag
[
https://issues.apache.org/jira/browse/MNG-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15940593#comment-15940593
]
Robert Scholte commented on MNG-6193:
-
Closing as duplicate of MNG-5955
> Properties not working in parent version tag
>
>
> Key: MNG-6193
> URL: https://issues.apache.org/jira/browse/MNG-6193
> Project: Maven
> Issue Type: Bug
>Reporter: Niklas Grebe
>Assignee: Robert Scholte
>Priority: Minor
> Attachments: pom.xml
>
>
> Using properties in the parent version tag isn't working and gives an error:
> {noformat}
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for com.foo.bar:some-parent:1.0-SNAPSHOT:
> Failure to find
> org.springframework.boot:spring-boot-starter-parent:pom:${spring.boot.version}
> in https://repo.maven.apache.org/maven2 was cached in the local repository,
> resolution will not be reattempted until the update interval of central has
> elapsed or updates are forced and 'parent.relativePath' points at wrong local
> POM @ line 19, column 10
> {noformat}
> It seems like the variable isn't replaced in the parent version tag. I've
> added my test pom.xml as an attachment. If you replace the variable with the
> actual version it works fine.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MNG-6193) Properties not working in parent version tag
[
https://issues.apache.org/jira/browse/MNG-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-6193.
---
Resolution: Duplicate
Assignee: Robert Scholte
> Properties not working in parent version tag
>
>
> Key: MNG-6193
> URL: https://issues.apache.org/jira/browse/MNG-6193
> Project: Maven
> Issue Type: Bug
>Reporter: Niklas Grebe
>Assignee: Robert Scholte
>Priority: Minor
> Attachments: pom.xml
>
>
> Using properties in the parent version tag isn't working and gives an error:
> {noformat}
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for com.foo.bar:some-parent:1.0-SNAPSHOT:
> Failure to find
> org.springframework.boot:spring-boot-starter-parent:pom:${spring.boot.version}
> in https://repo.maven.apache.org/maven2 was cached in the local repository,
> resolution will not be reattempted until the update interval of central has
> elapsed or updates are forced and 'parent.relativePath' points at wrong local
> POM @ line 19, column 10
> {noformat}
> It seems like the variable isn't replaced in the parent version tag. I've
> added my test pom.xml as an attachment. If you replace the variable with the
> actual version it works fine.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MNG-6194) decomission general@maven unused mailing list
Chris Lambertus created MNG-6194: Summary: decomission general@maven unused mailing list Key: MNG-6194 URL: https://issues.apache.org/jira/browse/MNG-6194 Project: Maven Issue Type: Project Reporter: Chris Lambertus Priority: Trivial Discussion thread on private@maven https://lists.apache.org/thread.html/46fdc79100f13d3df67100bf0706931f074a474d42cddec206524f26@%3Cprivate.maven.apache.org%3E Per Herve: Yes, this list is completely unused and unknown: please delete it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SUREFIRE-1346) surefire-reports overwrite each other when using reuseForks=false
Antoine Tran created SUREFIRE-1346: -- Summary: surefire-reports overwrite each other when using reuseForks=false Key: SUREFIRE-1346 URL: https://issues.apache.org/jira/browse/SUREFIRE-1346 Project: Maven Surefire Issue Type: Bug Components: process forking, TestNG support Affects Versions: 2.19.1 Reporter: Antoine Tran In a Maven project with the setting "false" and TestNg, the file testng-result.xml gets overwritten by the last test. I somehow understand why it is difficult to avoid this by design of fork, but the proper solution, as suggested by SUREFIRE-1018 or SUREFIRE-446, is to use the individual TEST-[className].xml files. However, if I use a Jenkins plugin like testng, I cannot make him ingest these files, as they do not have the same structure as testng-result.xml. This is a bug of testng, rather than the Jenkins plugin testng. Couldn't we make testng-result-[className].xml, for each test, with the testng-result.xml structure? Otherwise, the Jenkins plugin https://wiki.jenkins-ci.org/display/JENKINS/testng-plugin is completely not usable. Thank you. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SUREFIRE-1346) surefire-reports overwrite each other when using reuseForks=false
[ https://issues.apache.org/jira/browse/SUREFIRE-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Tran updated SUREFIRE-1346: --- Description: In a Maven project with the setting "false" and TestNg, the file testng-result.xml gets overwritten by the last test. I somehow understand why it is difficult to avoid this by design of fork, but a workaround solution, as suggested by SUREFIRE-1018 or SUREFIRE-446, is to use the individual TEST-[className].xml files. However, if I use a Jenkins plugin like testng, I cannot make him ingest these files, as they do not have the same structure as testng-result.xml. This is a bug of testng, rather than the Jenkins plugin testng. Couldn't we make testng-result-[className].xml, for each test, with the testng-result.xml structure? Otherwise, the Jenkins plugin https://wiki.jenkins-ci.org/display/JENKINS/testng-plugin is completely not usable. Thank you. was: In a Maven project with the setting "false" and TestNg, the file testng-result.xml gets overwritten by the last test. I somehow understand why it is difficult to avoid this by design of fork, but the proper solution, as suggested by SUREFIRE-1018 or SUREFIRE-446, is to use the individual TEST-[className].xml files. However, if I use a Jenkins plugin like testng, I cannot make him ingest these files, as they do not have the same structure as testng-result.xml. This is a bug of testng, rather than the Jenkins plugin testng. Couldn't we make testng-result-[className].xml, for each test, with the testng-result.xml structure? Otherwise, the Jenkins plugin https://wiki.jenkins-ci.org/display/JENKINS/testng-plugin is completely not usable. Thank you. > surefire-reports overwrite each other when using reuseForks=false > - > > Key: SUREFIRE-1346 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1346 > Project: Maven Surefire > Issue Type: Bug > Components: process forking, TestNG support >Affects Versions: 2.19.1 >Reporter: Antoine Tran > > In a Maven project with the setting "false" and > TestNg, the file testng-result.xml gets overwritten by the last test. > I somehow understand why it is difficult to avoid this by design of fork, but > a workaround solution, as suggested by SUREFIRE-1018 or SUREFIRE-446, is to > use the individual TEST-[className].xml files. > However, if I use a Jenkins plugin like testng, I cannot make him ingest > these files, as they do not have the same structure as testng-result.xml. > This is a bug of testng, rather than the Jenkins plugin testng. Couldn't we > make testng-result-[className].xml, for each test, with the testng-result.xml > structure? Otherwise, the Jenkins plugin > https://wiki.jenkins-ci.org/display/JENKINS/testng-plugin is completely not > usable. > Thank you. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1346) surefire-reports overwrite each other when using reuseForks=false
[ https://issues.apache.org/jira/browse/SUREFIRE-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15940464#comment-15940464 ] Antoine Tran commented on SUREFIRE-1346: None of the duplicated issue are in open state. > surefire-reports overwrite each other when using reuseForks=false > - > > Key: SUREFIRE-1346 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1346 > Project: Maven Surefire > Issue Type: Bug > Components: process forking, TestNG support >Affects Versions: 2.19.1 >Reporter: Antoine Tran > > In a Maven project with the setting "false" and > TestNg, the file testng-result.xml gets overwritten by the last test. > I somehow understand why it is difficult to avoid this by design of fork, but > the proper solution, as suggested by SUREFIRE-1018 or SUREFIRE-446, is to use > the individual TEST-[className].xml files. > However, if I use a Jenkins plugin like testng, I cannot make him ingest > these files, as they do not have the same structure as testng-result.xml. > This is a bug of testng, rather than the Jenkins plugin testng. Couldn't we > make testng-result-[className].xml, for each test, with the testng-result.xml > structure? Otherwise, the Jenkins plugin > https://wiki.jenkins-ci.org/display/JENKINS/testng-plugin is completely not > usable. > Thank you. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
