[jira] [Commented] (SUREFIRE-1917) Surefire plug-in level dependency doesn't work
[ https://issues.apache.org/jira/browse/SUREFIRE-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748692#comment-17748692 ] Marco Brandizi commented on SUREFIRE-1917: -- Hi all, just to let you know this still doesn't work with surefire 3.1.2 > Surefire plug-in level dependency doesn't work > -- > > Key: SUREFIRE-1917 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1917 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 3.0.0-M5 > Environment: 18:41:33 [root@MAC10143-ROTH tmp]# mvn -v > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: /usr/local/Cellar/maven/3.6.3/libexec > Java version: 11.0.10, vendor: AdoptOpenJDK, runtime: > /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" > 18:48:39 [root@MAC10143-ROTH tmp]# >Reporter: Marco Brandizi >Priority: Major > Attachments: junit-deptest.zip > > > I've been using a Junit 4.x > [listener|https://github.com/marco-brandizi/jutils/blob/master/jutils/src/main/java/uk/ac/ebi/utils/test/junit/TestOutputDecorator.java] > for years, to wrap every test method run with nice header/trailer > decorations. > I've been doing this by adding the dependency to the listener class in the > surefire's section and then using the property listener. > I've just discovered that this doesn't work anymore with 3.0.0-M5 version: it > says that the listener's ClassNotFoundException for the listener class. > You can verify this with the attached simple project. > Using it, I've tried several older versions until I found that the latest > working is 2.19.1, the 2.20.1 raises a NullPointerEx and I didn't get exactly > where (see the .out in the attachment). > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SUREFIRE-1917) Surefire plug-in level dependency doesn't work
[ https://issues.apache.org/jira/browse/SUREFIRE-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17683485#comment-17683485 ] Marco Brandizi edited comment on SUREFIRE-1917 at 2/2/23 4:34 PM: -- Hi all, is there any news on this issue? Last version (3.0.0-M8) still has this problem and I'm forced to declare the listener dependency with test scope, not like a plugin dependency. Thanks in advance. was (Author: mbrandizi): Hi all, is there any news on this issue? Last version (3.0.0-M8) still has this problem and I'm forced to declare the listener dependency with test scope, not like a plugin dependency. > Surefire plug-in level dependency doesn't work > -- > > Key: SUREFIRE-1917 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1917 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 3.0.0-M5 > Environment: 18:41:33 [root@MAC10143-ROTH tmp]# mvn -v > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: /usr/local/Cellar/maven/3.6.3/libexec > Java version: 11.0.10, vendor: AdoptOpenJDK, runtime: > /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" > 18:48:39 [root@MAC10143-ROTH tmp]# >Reporter: Marco Brandizi >Priority: Major > Attachments: junit-deptest.zip > > > I've been using a Junit 4.x > [listener|https://github.com/marco-brandizi/jutils/blob/master/jutils/src/main/java/uk/ac/ebi/utils/test/junit/TestOutputDecorator.java] > for years, to wrap every test method run with nice header/trailer > decorations. > I've been doing this by adding the dependency to the listener class in the > surefire's section and then using the property listener. > I've just discovered that this doesn't work anymore with 3.0.0-M5 version: it > says that the listener's ClassNotFoundException for the listener class. > You can verify this with the attached simple project. > Using it, I've tried several older versions until I found that the latest > working is 2.19.1, the 2.20.1 raises a NullPointerEx and I didn't get exactly > where (see the .out in the attachment). > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-1917) Surefire plug-in level dependency doesn't work
[ https://issues.apache.org/jira/browse/SUREFIRE-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17683485#comment-17683485 ] Marco Brandizi commented on SUREFIRE-1917: -- Hi all, is there any news on this issue? Last version (3.0.0-M8) still has this problem and I'm forced to declare the listener dependency with test scope, not like a plugin dependency. > Surefire plug-in level dependency doesn't work > -- > > Key: SUREFIRE-1917 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1917 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 3.0.0-M5 > Environment: 18:41:33 [root@MAC10143-ROTH tmp]# mvn -v > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: /usr/local/Cellar/maven/3.6.3/libexec > Java version: 11.0.10, vendor: AdoptOpenJDK, runtime: > /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" > 18:48:39 [root@MAC10143-ROTH tmp]# >Reporter: Marco Brandizi >Priority: Major > Attachments: junit-deptest.zip > > > I've been using a Junit 4.x > [listener|https://github.com/marco-brandizi/jutils/blob/master/jutils/src/main/java/uk/ac/ebi/utils/test/junit/TestOutputDecorator.java] > for years, to wrap every test method run with nice header/trailer > decorations. > I've been doing this by adding the dependency to the listener class in the > surefire's section and then using the property listener. > I've just discovered that this doesn't work anymore with 3.0.0-M5 version: it > says that the listener's ClassNotFoundException for the listener class. > You can verify this with the attached simple project. > Using it, I've tried several older versions until I found that the latest > working is 2.19.1, the 2.20.1 raises a NullPointerEx and I didn't get exactly > where (see the .out in the attachment). > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SUREFIRE-1917) Surefire plug-in level dependency doesn't work
[ https://issues.apache.org/jira/browse/SUREFIRE-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Brandizi updated SUREFIRE-1917: - Description: I've been using a Junit 4.x [listener|https://github.com/marco-brandizi/jutils/blob/master/jutils/src/main/java/uk/ac/ebi/utils/test/junit/TestOutputDecorator.java] for years, to wrap every test method run with nice header/trailer decorations. I've been doing this by adding the dependency to the listener class in the surefire's section and then using the property listener. I've just discovered that this doesn't work anymore with 3.0.0-M5 version: it says that the listener's ClassNotFoundException for the listener class. You can verify this with the attached simple project. Using it, I've tried several older versions until I found that the latest working is 2.19.1, the 2.20.1 raises a NullPointerEx and I didn't get exactly where (see the .out in the attachment). was: I've been using a Junit 4.x [listener|https://github.com/marco-brandizi/jutils/blob/master/jutils/src/main/java/uk/ac/ebi/utils/test/junit/TestOutputDecorator.java] that wraps every test method with nice header/trailer decorations. I've been doing this by adding the dependency to the class in the surefire's section and then using the property listener. I've just discovered that this doesn't work anymore with 3.0.0-M5 version: it says that the listener's ClassNotFoundException for the listener class. You can verify this with the attached simple project. Using it, I've tried several older versions until I found that the latest working is 2.19.1, the 2.20.1 raises a NullPointerEx and I didn't get exactly where (see the .out in the attachment). > Surefire plug-in level dependency doesn't work > -- > > Key: SUREFIRE-1917 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1917 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 3.0.0-M5 > Environment: 18:41:33 [root@MAC10143-ROTH tmp]# mvn -v > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: /usr/local/Cellar/maven/3.6.3/libexec > Java version: 11.0.10, vendor: AdoptOpenJDK, runtime: > /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" > 18:48:39 [root@MAC10143-ROTH tmp]# >Reporter: Marco Brandizi >Priority: Major > Attachments: junit-deptest.zip > > > I've been using a Junit 4.x > [listener|https://github.com/marco-brandizi/jutils/blob/master/jutils/src/main/java/uk/ac/ebi/utils/test/junit/TestOutputDecorator.java] > for years, to wrap every test method run with nice header/trailer > decorations. > I've been doing this by adding the dependency to the listener class in the > surefire's section and then using the property listener. > I've just discovered that this doesn't work anymore with 3.0.0-M5 version: it > says that the listener's ClassNotFoundException for the listener class. > You can verify this with the attached simple project. > Using it, I've tried several older versions until I found that the latest > working is 2.19.1, the 2.20.1 raises a NullPointerEx and I didn't get exactly > where (see the .out in the attachment). > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SUREFIRE-1917) Surefire plug-in level dependency doesn't work
Marco Brandizi created SUREFIRE-1917: Summary: Surefire plug-in level dependency doesn't work Key: SUREFIRE-1917 URL: https://issues.apache.org/jira/browse/SUREFIRE-1917 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 3.0.0-M5 Environment: 18:41:33 [root@MAC10143-ROTH tmp]# mvn -v Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) Maven home: /usr/local/Cellar/maven/3.6.3/libexec Java version: 11.0.10, vendor: AdoptOpenJDK, runtime: /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home Default locale: en_GB, platform encoding: UTF-8 OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" 18:48:39 [root@MAC10143-ROTH tmp]# Reporter: Marco Brandizi Attachments: junit-deptest.zip I've been using a Junit 4.x [listener|https://github.com/marco-brandizi/jutils/blob/master/jutils/src/main/java/uk/ac/ebi/utils/test/junit/TestOutputDecorator.java] that wraps every test method with nice header/trailer decorations. I've been doing this by adding the dependency to the class in the surefire's section and then using the property listener. I've just discovered that this doesn't work anymore with 3.0.0-M5 version: it says that the listener's ClassNotFoundException for the listener class. You can verify this with the attached simple project. Using it, I've tried several older versions until I found that the latest working is 2.19.1, the 2.20.1 raises a NullPointerEx and I didn't get exactly where (see the .out in the attachment). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6768) Support inheritable multiple settings
[ https://issues.apache.org/jira/browse/MNG-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17031888#comment-17031888 ] Marco Brandizi commented on MNG-6768: - [~rfscholte], my use case is: - I've my PC-specific settings in .m2 - I've my company-dependent settings in /company-settings.xml. These add and/or override my PC settings (or company server settings). - I need to do some test that imply using company settings and changing a few bits of them via an additional test-settings.xml file, which rely on company-settings.xml definitions. Yes, I could do it via command line parameters, but adding test-settings.xml and importing company-settings.xml from the latter can often be better than writing an .sh (eg, many parameters, many definitions. Yes, ti could be done by copying company-settings.xml into test-settings.xml, but that would create redundancy (and it's not always possible, when test-settings is in places different than , eg, in the CI system). > Support inheritable multiple settings > - > > Key: MNG-6768 > URL: https://issues.apache.org/jira/browse/MNG-6768 > Project: Maven > Issue Type: Improvement > Components: Settings >Reporter: Marco Brandizi >Priority: Minor > Fix For: waiting-for-feedback > > > As far as I know, the --settings option supports just one settings file. > Worse, when it is used, user settings in ~/.m2/settings.xml are ignored (not > tried, but I suspect global settings are too). > To me, this is rather poor. It would be much better if > # user and global settings were inherited and possibly overridden by the > further settings file. > # multiple --settings could be specified and a merge of settings > could be composed by maven (eg, blocks would come from multiple > files, would be overridden, considering the order in the command > line). > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6768) Support inheritable multiple settings
[ https://issues.apache.org/jira/browse/MNG-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Brandizi updated MNG-6768: Description: As far as I know, the --settings option supports just one settings file. Worse, when it is used, user settings in ~/.m2/settings.xml are ignored (not tried, but I suspect global settings are too). To me, this is rather poor. It would be much better if # user and global settings were inherited and possibly overridden by the further settings file. # multiple --settings could be specified and a merge of settings could be composed by maven (eg, blocks would come from multiple files, would be overridden, considering the order in the command line). was: As far as I know, the --settings option supports just one settings file. Worse, when it is used, user settings in ~/.m2/settings.xml are ignored (not tried, but I suspect global settings are too). To me, this is wrong and poor. It would be much better if # user and global settings were inherited and possibly overridden by the further settings file. # multiple --settings could be specified and a merge of settings could be composed by maven (eg, blocks would come from multiple files, would be overridden, considering the order in the command line). > Support inheritable multiple settings > - > > Key: MNG-6768 > URL: https://issues.apache.org/jira/browse/MNG-6768 > Project: Maven > Issue Type: Improvement > Components: Settings >Reporter: Marco Brandizi >Priority: Major > > As far as I know, the --settings option supports just one settings file. > Worse, when it is used, user settings in ~/.m2/settings.xml are ignored (not > tried, but I suspect global settings are too). > To me, this is rather poor. It would be much better if > # user and global settings were inherited and possibly overridden by the > further settings file. > # multiple --settings could be specified and a merge of settings > could be composed by maven (eg, blocks would come from multiple > files, would be overridden, considering the order in the command > line). > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (MNG-6768) Support inheritable multiple settings
Marco Brandizi created MNG-6768: --- Summary: Support inheritable multiple settings Key: MNG-6768 URL: https://issues.apache.org/jira/browse/MNG-6768 Project: Maven Issue Type: Improvement Components: Settings Reporter: Marco Brandizi As far as I know, the --settings option supports just one settings file. Worse, when it is used, user settings in ~/.m2/settings.xml are ignored (not tried, but I suspect global settings are too). To me, this is wrong and poor. It would be much better if # user and global settings were inherited and possibly overridden by the further settings file. # multiple --settings could be specified and a merge of settings could be composed by maven (eg, blocks would come from multiple files, would be overridden, considering the order in the command line). -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (SCM-915) pushChanges=true is ignored
[
https://issues.apache.org/jira/browse/SCM-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16733285#comment-16733285
]
Marco Brandizi commented on SCM-915:
[~michael-o] I confirm that it actually pushes, but the local sandbox is seen
as non-pushed, and the command-line push against it makes the unalignment
notification to disappear, without actually sending anything remotely ('git
pull' has the same effect).
So, I can live with it, it's just so confusing that I could only realise it
after having filed the hereby issue :)
> pushChanges=true is ignored
> ---
>
> Key: SCM-915
> URL: https://issues.apache.org/jira/browse/SCM-915
> Project: Maven SCM
> Issue Type: Bug
>Affects Versions: 1.11.1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T16:41:47+00:00)
> Maven home: /Applications/local/dev/maven
> Java version: 1.8.0_171, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14", arch: "x86_64", family: "mac"
> using the last scm 1.11.1
>Reporter: Marco Brandizi
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: scm.out
>
>
> This command:
> {{mvn scm:checkin -DpushChanges=true -Dmessage="Committing via Maven SCM"}}
> commits changes to the local git clone, but doesn't issue any commit to the
> configured GitHub remote repository.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCM-915) pushChanges=true is ignored
[
https://issues.apache.org/jira/browse/SCM-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16733259#comment-16733259
]
Marco Brandizi commented on SCM-915:
[~michael-o], now I realise it's actually behaving strangely:
[^scm.out] is the output of the command above.
After it, I get this from 'git status':
{{$ git status}}
{{On branch master}}
{{Your branch is ahead of 'origin/master' by 1 commit.}}
{{(use "git push" to publish your local commits)}}{{nothing to commit, working
tree clean}}
{{$}}
But, if I go to the GitHub [web page of the
repository|[http://example.com|https://github.com/marco-brandizi/rdfutils]], I
can see the plugin commit. I've no clue what's going on, isn't it using the
local sandbox?
> pushChanges=true is ignored
> ---
>
> Key: SCM-915
> URL: https://issues.apache.org/jira/browse/SCM-915
> Project: Maven SCM
> Issue Type: Bug
>Affects Versions: 1.11.1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T16:41:47+00:00)
> Maven home: /Applications/local/dev/maven
> Java version: 1.8.0_171, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14", arch: "x86_64", family: "mac"
> using the last scm 1.11.1
>Reporter: Marco Brandizi
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: scm.out
>
>
> This command:
> {{mvn scm:checkin -DpushChanges=true -Dmessage="Committing via Maven SCM"}}
> commits changes to the local git clone, but doesn't issue any commit to the
> configured GitHub remote repository.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SCM-915) pushChanges=true is ignored
[
https://issues.apache.org/jira/browse/SCM-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16733259#comment-16733259
]
Marco Brandizi edited comment on SCM-915 at 1/3/19 5:32 PM:
[~michael-o], now I realise it's actually behaving strangely:
[^scm.out] is the output of the command above.
After it, I get this from 'git status':
{{$ git status}}
{{On branch master}}
{{Your branch is ahead of 'origin/master' by 1 commit.}}
{{(use "git push" to publish your local commits)}}{{nothing to commit, working
tree clean}}
{{$}}
But, if I go to the GitHub [web page of the
repository|https://github.com/marco-brandizi/rdfutils], I can see the plugin's
commit. I've no clue what's going on, isn't it using the local sandbox?
was (Author: zakmck):
[~michael-o], now I realise it's actually behaving strangely:
[^scm.out] is the output of the command above.
After it, I get this from 'git status':
{{$ git status}}
{{On branch master}}
{{Your branch is ahead of 'origin/master' by 1 commit.}}
{{(use "git push" to publish your local commits)}}{{nothing to commit, working
tree clean}}
{{$}}
But, if I go to the GitHub [web page of the
repository|https://github.com/marco-brandizi/rdfutils], I can see the plugin
commit. I've no clue what's going on, isn't it using the local sandbox?
> pushChanges=true is ignored
> ---
>
> Key: SCM-915
> URL: https://issues.apache.org/jira/browse/SCM-915
> Project: Maven SCM
> Issue Type: Bug
>Affects Versions: 1.11.1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T16:41:47+00:00)
> Maven home: /Applications/local/dev/maven
> Java version: 1.8.0_171, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14", arch: "x86_64", family: "mac"
> using the last scm 1.11.1
>Reporter: Marco Brandizi
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: scm.out
>
>
> This command:
> {{mvn scm:checkin -DpushChanges=true -Dmessage="Committing via Maven SCM"}}
> commits changes to the local git clone, but doesn't issue any commit to the
> configured GitHub remote repository.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SCM-915) pushChanges=true is ignored
[
https://issues.apache.org/jira/browse/SCM-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16733259#comment-16733259
]
Marco Brandizi edited comment on SCM-915 at 1/3/19 5:32 PM:
[~michael-o], now I realise it's actually behaving strangely:
[^scm.out] is the output of the command above.
After it, I get this from 'git status':
{{$ git status}}
{{On branch master}}
{{Your branch is ahead of 'origin/master' by 1 commit.}}
{{(use "git push" to publish your local commits)}}{{nothing to commit, working
tree clean}}
{{$}}
But, if I go to the GitHub [web page of the
repository|https://github.com/marco-brandizi/rdfutils], I can see the plugin
commit. I've no clue what's going on, isn't it using the local sandbox?
was (Author: zakmck):
[~michael-o], now I realise it's actually behaving strangely:
[^scm.out] is the output of the command above.
After it, I get this from 'git status':
{{$ git status}}
{{On branch master}}
{{Your branch is ahead of 'origin/master' by 1 commit.}}
{{(use "git push" to publish your local commits)}}{{nothing to commit, working
tree clean}}
{{$}}
But, if I go to the GitHub [web page of the
repository|[http://example.com|https://github.com/marco-brandizi/rdfutils]], I
can see the plugin commit. I've no clue what's going on, isn't it using the
local sandbox?
> pushChanges=true is ignored
> ---
>
> Key: SCM-915
> URL: https://issues.apache.org/jira/browse/SCM-915
> Project: Maven SCM
> Issue Type: Bug
>Affects Versions: 1.11.1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T16:41:47+00:00)
> Maven home: /Applications/local/dev/maven
> Java version: 1.8.0_171, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14", arch: "x86_64", family: "mac"
> using the last scm 1.11.1
>Reporter: Marco Brandizi
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: scm.out
>
>
> This command:
> {{mvn scm:checkin -DpushChanges=true -Dmessage="Committing via Maven SCM"}}
> commits changes to the local git clone, but doesn't issue any commit to the
> configured GitHub remote repository.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SCM-915) pushChanges=true is ignored
[
https://issues.apache.org/jira/browse/SCM-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Brandizi updated SCM-915:
---
Attachment: scm.out
> pushChanges=true is ignored
> ---
>
> Key: SCM-915
> URL: https://issues.apache.org/jira/browse/SCM-915
> Project: Maven SCM
> Issue Type: Bug
>Affects Versions: 1.11.1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T16:41:47+00:00)
> Maven home: /Applications/local/dev/maven
> Java version: 1.8.0_171, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14", arch: "x86_64", family: "mac"
> using the last scm 1.11.1
>Reporter: Marco Brandizi
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: scm.out
>
>
> This command:
> {{mvn scm:checkin -DpushChanges=true -Dmessage="Committing via Maven SCM"}}
> commits changes to the local git clone, but doesn't issue any commit to the
> configured GitHub remote repository.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SCM-915) pushChanges=true is ignored
Marco Brandizi created SCM-915:
--
Summary: pushChanges=true is ignored
Key: SCM-915
URL: https://issues.apache.org/jira/browse/SCM-915
Project: Maven SCM
Issue Type: Bug
Affects Versions: 1.11.1
Environment: Apache Maven 3.3.9
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T16:41:47+00:00)
Maven home: /Applications/local/dev/maven
Java version: 1.8.0_171, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.14", arch: "x86_64", family: "mac"
using the last scm 1.11.1
Reporter: Marco Brandizi
This command:
{{mvn scm:checkin -DpushChanges=true -Dmessage="Committing via Maven SCM"}}
commits changes to the local git clone, but doesn't issue any commit to the
configured GitHub remote repository.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MASSEMBLY-880) Maven assembly per-extension file permissions
Marco Brandizi created MASSEMBLY-880: Summary: Maven assembly per-extension file permissions Key: MASSEMBLY-880 URL: https://issues.apache.org/jira/browse/MASSEMBLY-880 Project: Maven Assembly Plugin Issue Type: New Feature Reporter: Marco Brandizi I often have to write the following when using the Maven Assembly plug-in, in order to have file permissions correctly set for executable and non-executable files: src/main/assembly/resources **/*.sh 0644 0755 src/main/assembly/resources **/*.sh 0755 0755 This is redundant and cumbersome, I wonder if there is a simpler way to do the same, e.g., by specifying maps of file pattern => fileMode. It doesn't seem that anything like that is available, so I'm filing this as a new feature proposal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[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] [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] [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] (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] [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] [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] (MNG-5605) ssh-wagon hangs
[ https://jira.codehaus.org/browse/MNG-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=344456#comment-344456 ] Marco Brandizi commented on MNG-5605: - sftp worked for me too. Thank you so much! :-) Does this mean I'm no longer using wagon-ssh and instead I'm using jsch? Sorry, I'm too unfamiliar with this part of Maven to know if I'm asking a silly thing ;-) ssh-wagon hangs --- Key: MNG-5605 URL: https://jira.codehaus.org/browse/MNG-5605 Project: Maven 2 3 Issue Type: Bug Components: Deployment Affects Versions: 3.2.1 Reporter: Frank Cornelis Priority: Blocker When releasing (using maven-release-plugin) via Maven 3.1.1 everything works as expected. When doing the same via Maven 3.2.1, ssh-wagon all of the sudden hangs on the second ssh upload. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-900) System.err seems to be ignored
[ https://jira.codehaus.org/browse/SUREFIRE-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305857#comment-305857 ] Marco Brandizi commented on SUREFIRE-900: - Thanks for your reply. System.setErr() solved my specific problem. In general, it's strange for me that one cannot do something as easy as mvn test 2/dev/null and see just the standard output, not the standard error, which might give non-useful information in certain situations. But OK, I can live with that. System.err seems to be ignored -- Key: SUREFIRE-900 URL: https://jira.codehaus.org/browse/SUREFIRE-900 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.7.2 Environment: OS/X 10.7.4 Reporter: Marco Brandizi Assignee: Kristian Rosenvold Priority: Minor Attachments: testSureFireStdErr.zip See the attached project. If I send something to System.err from a JUnit test and then I try 'mvn test 2/dev/null', I can still see the output on the console, surefire (or Maven?!) seems to ignore this. I've tried with -Dsurefire.forkMode=false too. Is it possible to redirect the standard error? I'd like to do that because I have a few tests that tests a line command (ie, main()). Since the command is supposed to return XML to the invoker (which, for example, might pipe it to another command), I've implemented this command line by sending all the logging output to System.err (that's possible in Logback via the 'Target' option in the Console appender). When I invoke this line command outside Maven/Surefire it works as I want. In Maven, instead, I cannot what I described. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-900) System.err seems to be ignored
Marco Brandizi created SUREFIRE-900: --- Summary: System.err seems to be ignored Key: SUREFIRE-900 URL: https://jira.codehaus.org/browse/SUREFIRE-900 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.7.2 Environment: OS/X 10.7.4 Reporter: Marco Brandizi Priority: Minor Attachments: testSureFireStdErr.zip See the attached project. If I send something to System.err from a JUnit test and then I try 'mvn test 2/dev/null', I can still see the output on the console, surefire (or Maven?!) seems to ignore this. I've tried with -Dsurefire.forkMode=false too. Is it possible to redirect the standard error? I'd like to do that because I have a few tests that tests a line command (ie, main()). Since the command is supposed to return XML to the invoker (which, for example, might pipe it to another command), I've implemented this command line by sending all the logging output to System.err (that's possible in Logback via the 'Target' option in the Console appender). When I invoke this line command outside Maven/Surefire it works as I want. In Maven, instead, I cannot what I described. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-422) Generated directories have wrong file attributes
[ https://jira.codehaus.org/browse/MASSEMBLY-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=291173#comment-291173 ] Marco Brandizi commented on MASSEMBLY-422: -- I have a similar situation and I found a trick to fix the problem, until this bug is resolved. If I have this in an assembly descriptor: fileSet directorytarget/site/directory fileMode0644/fileMode directoryMode0755/directoryMode outputDirectorydoc/project-site/outputDirectory filteredtrue/filtered /fileSet doc/ will have 0777, while project-site/ and all doc/ sub-folders will have 0755. If I use doc as outputDirectory, all the folders get 0755. This prompted me to try to prefix this to the above block: fileSet directorytarget/directory excludesexclude**/*/exclude/excludes directoryMode0755/directoryMode outputDirectorydoc/outputDirectory filteredtrue/filtered /fileSet which doesn't copy anything in practice, but with the two blocks one after another, doc/ receives the correct 0755 permissions. Generated directories have wrong file attributes Key: MASSEMBLY-422 URL: https://jira.codehaus.org/browse/MASSEMBLY-422 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-4 Reporter: Sergiu Dumitriu Priority: Minor When the assembly creates directories not already found in the resources (for example when using includeBaseDirectorytrue/includeBaseDirectory or outputDirectorysome/new/folder/outputDirectory), the directory has the wrong file attributes (17 octal, ?rwsrwsrwt). This causes the archive to be somewhat broken, since the directory doesn't appear to be a directory according to the file attributes. This causes problems with the Midnight Commander virtual file system, for example. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-616) surefire-report doesn't create target/site/css
surefire-report doesn't create target/site/css -- Key: SUREFIRE-616 URL: http://jira.codehaus.org/browse/SUREFIRE-616 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Report Plugin Environment: Maven 2.2.1, Java 1.6.0_17, OS/X 10.6.3 Reporter: Marco Brandizi I've just try mvn surefire-report:report-only and I get what said in the subject. It creates site surefire-report.html, but not the css/*.css files that are imported by such html. The result is quite ugly to see. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-326) unpack = false does not work
[ http://jira.codehaus.org/browse/MASSEMBLY-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=157860#action_157860 ] Marco Brandizi commented on MASSEMBLY-326: -- I've put my hands back on it. By removing outputFileNameMapping it works! Thanks a lot. unpack = false does not work Key: MASSEMBLY-326 URL: http://jira.codehaus.org/browse/MASSEMBLY-326 Project: Maven 2.x Assembly Plugin Issue Type: Bug Environment: OS/X 10.4, JDK1.5 Reporter: Marco Brandizi Priority: Blocker Attachments: bin.xml, log.txt I use the assembly attached to build a distributable version of a Java command line tool. I'd like to have a lib/ directory with the jars the project depends on, so that I may include them via a BASH script. with unpack = false, I get the error in the attach. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-326) unpack = false does not work
unpack = false does not work Key: MASSEMBLY-326 URL: http://jira.codehaus.org/browse/MASSEMBLY-326 Project: Maven 2.x Assembly Plugin Issue Type: Bug Environment: OS/X 10.4, JDK1.5 Reporter: Marco Brandizi Priority: Blocker Attachments: bin.xml, log.txt I use the assembly attached to build a distributable version of a Java command line tool. I'd like to have a lib/ directory with the jars the project depends on, so that I may include them via a BASH script. with unpack = false, I get the error in the attach. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-326) unpack = false does not work
[ http://jira.codehaus.org/browse/MASSEMBLY-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=135131#action_135131 ] Marco Brandizi commented on MASSEMBLY-326: -- sorry, forgot to include this info too. Mac OS/X 10.4.11 tar (GNU tar) 1.14 +CVE-2006-0300 +CVE-2006-6097 Yes, should be a problem with packaging. I've tried to remove formattar.bz2/format, leaving zip, but a 'lib' file (not directory) is created. If i do unzip -l lib I can see that only one dependent jar is stored in it. It also creates a .zip which is sized 18Mb, so apparently all the jars are poured in it, but when I unzip it I have an empty lib/ directory... unpack = false does not work Key: MASSEMBLY-326 URL: http://jira.codehaus.org/browse/MASSEMBLY-326 Project: Maven 2.x Assembly Plugin Issue Type: Bug Environment: OS/X 10.4, JDK1.5 Reporter: Marco Brandizi Priority: Blocker Attachments: bin.xml, log.txt I use the assembly attached to build a distributable version of a Java command line tool. I'd like to have a lib/ directory with the jars the project depends on, so that I may include them via a BASH script. with unpack = false, I get the error in the attach. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MASSEMBLY-326) unpack = false does not work
[ http://jira.codehaus.org/browse/MASSEMBLY-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=135131#action_135131 ] zakmck edited comment on MASSEMBLY-326 at 5/16/08 10:02 AM: sorry, forgot to include this info too. Mac OS/X 10.4.11 tar (GNU tar) 1.14 +CVE-2006-0300 +CVE-2006-6097 java version 1.5.0_13 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing) Maven version: 2.0.8 Yes, should be a problem with packaging. I've tried to remove formattar.bz2/format, leaving zip, but a 'lib' file (not directory) is created. If i do unzip -l lib I can see that only one dependent jar is stored in it. It also creates a .zip which is sized 18Mb, so apparently all the jars are poured in it, but when I unzip it I have an empty lib/ directory. was (Author: zakmck): sorry, forgot to include this info too. Mac OS/X 10.4.11 tar (GNU tar) 1.14 +CVE-2006-0300 +CVE-2006-6097 Yes, should be a problem with packaging. I've tried to remove formattar.bz2/format, leaving zip, but a 'lib' file (not directory) is created. If i do unzip -l lib I can see that only one dependent jar is stored in it. It also creates a .zip which is sized 18Mb, so apparently all the jars are poured in it, but when I unzip it I have an empty lib/ directory... unpack = false does not work Key: MASSEMBLY-326 URL: http://jira.codehaus.org/browse/MASSEMBLY-326 Project: Maven 2.x Assembly Plugin Issue Type: Bug Environment: OS/X 10.4, JDK1.5 Reporter: Marco Brandizi Priority: Blocker Attachments: bin.xml, log.txt I use the assembly attached to build a distributable version of a Java command line tool. I'd like to have a lib/ directory with the jars the project depends on, so that I may include them via a BASH script. with unpack = false, I get the error in the attach. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MASSEMBLY-326) unpack = false does not work
[ http://jira.codehaus.org/browse/MASSEMBLY-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=135131#action_135131 ] zakmck edited comment on MASSEMBLY-326 at 5/16/08 10:03 AM: I have the envirnoment: Mac OS/X 10.4.11 tar (GNU tar) 1.14 +CVE-2006-0300 +CVE-2006-6097 java version 1.5.0_13 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing) Maven version: 2.0.8 Yes, should be a problem with packaging. I've tried to remove formattar.bz2/format, leaving zip, but a 'lib' file (not directory) is created. If i do unzip -l lib I can see that only one dependent jar is stored in it. It also creates a .zip which is sized 18Mb, so apparently all the jars are poured in it, but when I unzip it I have an empty lib/ directory. was (Author: zakmck): sorry, forgot to include this info too. Mac OS/X 10.4.11 tar (GNU tar) 1.14 +CVE-2006-0300 +CVE-2006-6097 java version 1.5.0_13 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing) Maven version: 2.0.8 Yes, should be a problem with packaging. I've tried to remove formattar.bz2/format, leaving zip, but a 'lib' file (not directory) is created. If i do unzip -l lib I can see that only one dependent jar is stored in it. It also creates a .zip which is sized 18Mb, so apparently all the jars are poured in it, but when I unzip it I have an empty lib/ directory. unpack = false does not work Key: MASSEMBLY-326 URL: http://jira.codehaus.org/browse/MASSEMBLY-326 Project: Maven 2.x Assembly Plugin Issue Type: Bug Environment: OS/X 10.4, JDK1.5 Reporter: Marco Brandizi Priority: Blocker Attachments: bin.xml, log.txt I use the assembly attached to build a distributable version of a Java command line tool. I'd like to have a lib/ directory with the jars the project depends on, so that I may include them via a BASH script. with unpack = false, I get the error in the attach. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-326) unpack = false does not work
[ http://jira.codehaus.org/browse/MASSEMBLY-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=135137#action_135137 ] Marco Brandizi commented on MASSEMBLY-326: -- It is attached, is bin.xml. unpack = false does not work Key: MASSEMBLY-326 URL: http://jira.codehaus.org/browse/MASSEMBLY-326 Project: Maven 2.x Assembly Plugin Issue Type: Bug Environment: OS/X 10.4, JDK1.5 Reporter: Marco Brandizi Priority: Blocker Attachments: bin.xml, log.txt I use the assembly attached to build a distributable version of a Java command line tool. I'd like to have a lib/ directory with the jars the project depends on, so that I may include them via a BASH script. with unpack = false, I get the error in the attach. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
