[jira] (MRELEASE-869) Add 'tagByProject' configuration flag to release:prepare
Christopher Currie created MRELEASE-869: --- Summary: Add 'tagByProject' configuration flag to release:prepare Key: MRELEASE-869 URL: https://jira.codehaus.org/browse/MRELEASE-869 Project: Maven Release Plugin Issue Type: New Feature Components: prepare Affects Versions: 2.5 Environment: Git Reporter: Christopher Currie For projects using Git, it would be convenient for sub projects to be referenced as Git submodules. This almost works perfectly in conjunction with the 'commitByProject' flag. The one additional feature I would want is to have each sub project be tagged. A 'tagByProject' flag would have the following semantics: * require and/or implicitly set commitByProject=true * change the commit message to use the project name rather than the parent name * tag the commit with a tag based on the project name rather than the parent project name. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl reassigned MNG-624: - Assignee: Jason van Zyl > automatic parent versioning > --- > > Key: MNG-624 > URL: https://jira.codehaus.org/browse/MNG-624 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Brett Porter >Assignee: Jason van Zyl >Priority: Blocker > Fix For: Issues to be reviewed for 4.x > > Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl reassigned MNG-624: - Assignee: (was: Jason van Zyl) > automatic parent versioning > --- > > Key: MNG-624 > URL: https://jira.codehaus.org/browse/MNG-624 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Brett Porter >Priority: Blocker > Fix For: Issues to be reviewed for 4.x > > Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1062) TestNG listeners on separate lines in pom.xml
[
https://jira.codehaus.org/browse/SUREFIRE-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian reassigned SUREFIRE-1062:
Assignee: Andreas Gudian
> TestNG listeners on separate lines in pom.xml
> -
>
> Key: SUREFIRE-1062
> URL: https://jira.codehaus.org/browse/SUREFIRE-1062
> Project: Maven Surefire
> Issue Type: Improvement
> Components: TestNG support
>Affects Versions: 2.16
>Reporter: Kirill Kozlov
>Assignee: Andreas Gudian
>Priority: Minor
> Fix For: 2.17
>
>
> Currently, maven-surefire-plugin doesn't support setting TestNG listeners on
> the separate lines in pom.xml. User must put all listeners at the same line,
> so the line becomes very long.
> For example, for the following configuration the plugin throws unclear
> exception. It's very hard to determine the reason, cause the first idea is
> that something wrong with your classpath.
> {code}
> ...
>
> listener
>
> com.company1.testng.listeners.Listener1,
> com.company2.testng.listeners.Listener2
>
>
> ...
> {code}
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.16:test (default-test) on
> project allure-testng-example: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.16:test failed: There was an
> error in the forked process
> [ERROR] org.apache.maven.surefire.testset.TestSetFailedException: Cannot find
> listener class
> [ERROR] com.company2.testng.listeners.Listener2; nested exception is
> java.lang.ClassNotFoundException:
> [ERROR] com.company2.testng.listeners.Listener2
> [ERROR] java.lang.ClassNotFoundException:
> [ERROR] ru.befree.qa.tools.testng.listeners.LoggerListener
> [ERROR] at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> [ERROR] at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> [ERROR] at java.security.AccessController.doPrivileged(Native Method)
> [ERROR] at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> [ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> [ERROR] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> [ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> [ERROR] at java.lang.Class.forName0(Native Method)
> [ERROR] at java.lang.Class.forName(Class.java:190)
> [ERROR] at
> org.apache.maven.surefire.testng.conf.AbstractDirectConfigurator.loadClass(AbstractDirectConfigurator.java:139)
> [ERROR] at
> org.apache.maven.surefire.testng.conf.AbstractDirectConfigurator.loadListenerClasses(AbstractDirectConfigurator.java:127)
> [ERROR] at
> org.apache.maven.surefire.testng.conf.TestNGMapConfigurator.getConvertedOptions(TestNGMapConfigurator.java:81)
> [ERROR] at
> org.apache.maven.surefire.testng.conf.TestNG652Configurator.getConvertedOptions(TestNG652Configurator.java:40)
> [ERROR] at
> org.apache.maven.surefire.testng.conf.TestNGMapConfigurator.configure(TestNGMapConfigurator.java:52)
> [ERROR] at
> org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:214)
> [ERROR] at
> org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:84)
> [ERROR] at
> org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:92)
> [ERROR] at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> [ERROR] at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> [ERROR] at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> [ERROR] -> [Help 1]
> {code}
> Is it a problem to fix AbstractDirectConfigurator class to split the value of
> *listener* property using new line symbols too?
> Current implementation is:
> {code}
> String[] classNames = listenerClasses.split( " *, *" );
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1062) TestNG listeners on separate lines in pom.xml
[
https://jira.codehaus.org/browse/SUREFIRE-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian updated SUREFIRE-1062:
-
Fix Version/s: 2.17
> TestNG listeners on separate lines in pom.xml
> -
>
> Key: SUREFIRE-1062
> URL: https://jira.codehaus.org/browse/SUREFIRE-1062
> Project: Maven Surefire
> Issue Type: Improvement
> Components: TestNG support
>Affects Versions: 2.16
>Reporter: Kirill Kozlov
>Priority: Minor
> Fix For: 2.17
>
>
> Currently, maven-surefire-plugin doesn't support setting TestNG listeners on
> the separate lines in pom.xml. User must put all listeners at the same line,
> so the line becomes very long.
> For example, for the following configuration the plugin throws unclear
> exception. It's very hard to determine the reason, cause the first idea is
> that something wrong with your classpath.
> {code}
> ...
>
> listener
>
> com.company1.testng.listeners.Listener1,
> com.company2.testng.listeners.Listener2
>
>
> ...
> {code}
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.16:test (default-test) on
> project allure-testng-example: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.16:test failed: There was an
> error in the forked process
> [ERROR] org.apache.maven.surefire.testset.TestSetFailedException: Cannot find
> listener class
> [ERROR] com.company2.testng.listeners.Listener2; nested exception is
> java.lang.ClassNotFoundException:
> [ERROR] com.company2.testng.listeners.Listener2
> [ERROR] java.lang.ClassNotFoundException:
> [ERROR] ru.befree.qa.tools.testng.listeners.LoggerListener
> [ERROR] at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> [ERROR] at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> [ERROR] at java.security.AccessController.doPrivileged(Native Method)
> [ERROR] at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> [ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> [ERROR] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> [ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> [ERROR] at java.lang.Class.forName0(Native Method)
> [ERROR] at java.lang.Class.forName(Class.java:190)
> [ERROR] at
> org.apache.maven.surefire.testng.conf.AbstractDirectConfigurator.loadClass(AbstractDirectConfigurator.java:139)
> [ERROR] at
> org.apache.maven.surefire.testng.conf.AbstractDirectConfigurator.loadListenerClasses(AbstractDirectConfigurator.java:127)
> [ERROR] at
> org.apache.maven.surefire.testng.conf.TestNGMapConfigurator.getConvertedOptions(TestNGMapConfigurator.java:81)
> [ERROR] at
> org.apache.maven.surefire.testng.conf.TestNG652Configurator.getConvertedOptions(TestNG652Configurator.java:40)
> [ERROR] at
> org.apache.maven.surefire.testng.conf.TestNGMapConfigurator.configure(TestNGMapConfigurator.java:52)
> [ERROR] at
> org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:214)
> [ERROR] at
> org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:84)
> [ERROR] at
> org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:92)
> [ERROR] at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> [ERROR] at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> [ERROR] at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> [ERROR] -> [Help 1]
> {code}
> Is it a problem to fix AbstractDirectConfigurator class to split the value of
> *listener* property using new line symbols too?
> Current implementation is:
> {code}
> String[] classNames = listenerClasses.split( " *, *" );
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-652) Resource filtering does not work if line contains single @
[
https://jira.codehaus.org/browse/MASSEMBLY-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MASSEMBLY-652:
-
Description:
I want to include and filter Microsoft SQL Server SQL-files. SQL Server has
extended properties which are declared as (extended property "Version" on a
database):
{noformat}
exec DB.sys.sp_addextendedproperty
@name='Version'
, @value='${project.version}'
go
{noformat}
However, if I filter the file which contains this call the expression
$\{project.version} is not been replaced. I get it working only when adding a
second "@"
{noformat}
exec DB.sys.sp_addextendedproperty
@name='Version'
, @value='@${project.version}'
go
{noformat}
This evaluates to
{noformat}
exec DB.sys.sp_addextendedproperty
@name='Version'
, @value='@2.03.002'
go
{noformat}
However the "@" is not really wanted.
Thank you.
PS: Please rename attached "test.txt" to "test.sql". Got an server error while
trying to upload "test.sql".
was:
I want to include and filter Microsoft SQL Server SQL-files. SQL Server has
extended properties which are declared as (extended property "Version" on a
database):
exec DB.sys.sp_addextendedproperty
@name='Version'
, @value='${project.version}'
go
However, if I filter the file which contains this call the expression
${project.version} is not been replaced. I get it working only when adding a
second "@"
exec DB.sys.sp_addextendedproperty
@name='Version'
, @value='@${project.version}'
go
This evaluates to
exec DB.sys.sp_addextendedproperty
@name='Version'
, @value='@2.03.002'
go
However the "@" is not really wanted.
Thank you.
PS: Please rename attached "test.txt" to "test.sql". Got an server error while
trying to upload "test.sql".
> Resource filtering does not work if line contains single @
> --
>
> Key: MASSEMBLY-652
> URL: https://jira.codehaus.org/browse/MASSEMBLY-652
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: filtering
>Affects Versions: 2.4
>Reporter: Michael Gruebsch
>Priority: Minor
> Fix For: 2.5
>
> Attachments: assembly.xml, pom.xml, test.txt
>
>
> I want to include and filter Microsoft SQL Server SQL-files. SQL Server has
> extended properties which are declared as (extended property "Version" on a
> database):
> {noformat}
> exec DB.sys.sp_addextendedproperty
> @name='Version'
> , @value='${project.version}'
> go
> {noformat}
> However, if I filter the file which contains this call the expression
> $\{project.version} is not been replaced. I get it working only when adding a
> second "@"
> {noformat}
> exec DB.sys.sp_addextendedproperty
> @name='Version'
> , @value='@${project.version}'
> go
> {noformat}
> This evaluates to
> {noformat}
> exec DB.sys.sp_addextendedproperty
> @name='Version'
> , @value='@2.03.002'
> go
> {noformat}
> However the "@" is not really wanted.
> Thank you.
> PS: Please rename attached "test.txt" to "test.sql". Got an server error
> while trying to upload "test.sql".
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-686) Update version of maven-filtering to 1.2
[ https://jira.codehaus.org/browse/MASSEMBLY-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MASSEMBLY-686: -- Fix Version/s: 2.5 > Update version of maven-filtering to 1.2 > > > Key: MASSEMBLY-686 > URL: https://jira.codehaus.org/browse/MASSEMBLY-686 > Project: Maven Assembly Plugin > Issue Type: Improvement > Components: filtering >Affects Versions: 2.4 >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: 2.5 > > > We should update to maven-filtering 1.2 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1024) "verify" goal ignores "dependenciesToScan" parameter when checking tests existence
[
https://jira.codehaus.org/browse/SUREFIRE-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342605#comment-342605
]
Andreas Gudian commented on SUREFIRE-1024:
--
Sorry, I have to push that one back one version, as I didn't have time to dig
into your patch, yet.
> "verify" goal ignores "dependenciesToScan" parameter when checking tests
> existence
> --
>
> Key: SUREFIRE-1024
> URL: https://jira.codehaus.org/browse/SUREFIRE-1024
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.16
>Reporter: Dmitry Kholodilov
> Fix For: 2.18
>
> Attachments:
> verify_goal_ignores_dependenciesToScan_parameter_when_checking_tests_existence.patch
>
>
> Consider Maven project with packaging=pom that executes tests from some
> external jar:
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> test
> test
> test
> pom
>
>
> test
> tests-jar
> 1.0
> tests
>
>
> org.testng
> testng
> 6.8
>
>
>
>
>
> maven-failsafe-plugin
> 2.17-SNAPSHOT
>
>
> test:tests-jar
>
>
>
>
> integration-test
> integration-test
>
> integration-test
>
>
>
> verify
> verify
>
> verify
>
>
>
>
>
>
>
> {code}
> (real use case is execution of prebuilt end-to-end tests of some system after
> its deployment)
> When we run `mvn clean verify` on such project, failsafe plugin's "verify"
> goal reports the following:
> {noformat}
> [INFO] --- maven-failsafe-plugin:2.16:verify (verify) @ test ---
> [INFO] No tests to run.
> {noformat}
> Consequently, even if there are test failures, build success is reported.
> The reason of such behavior is that VerifyMojo ignores "dependenciesToScan"
> parameter. So, the fix is easy - check its existence along with
> "testClassesDirectory" existence, the same way as implemented in
> AbstractSurefireMojo.
> The patch in attachment includes integration test that checks for build
> failure when there is failed test from dependency jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1028) Unable to run single test (junit)
[
https://jira.codehaus.org/browse/SUREFIRE-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian updated SUREFIRE-1028:
-
Fix Version/s: (was: 2.17)
2.18
> Unable to run single test (junit)
> -
>
> Key: SUREFIRE-1028
> URL: https://jira.codehaus.org/browse/SUREFIRE-1028
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.16
>Reporter: Diwaker Gupta
>Priority: Critical
> Fix For: 2.18
>
>
> This is a regression from 2.15. It also looks like Surefire keeps regressing
> on this feature (e.g. see SUREFIRE-827) -- are there no unit or integration
> tests to prevent such regressions?
> With Surefire 2.15
> {noformat}
> $ mvn test -Dtest=MyTest#testFoo
> ...
> Results :
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> With Surefire 2.16
> {noformat}
> $ mvn test -Dtest=MyTest#testFoo
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1017) Failures do not show test-package since 2.13
[
https://jira.codehaus.org/browse/SUREFIRE-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian updated SUREFIRE-1017:
-
Fix Version/s: (was: 2.17)
2.18
> Failures do not show test-package since 2.13
>
>
> Key: SUREFIRE-1017
> URL: https://jira.codehaus.org/browse/SUREFIRE-1017
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 2.13, 2.14, 2.15
>Reporter: Christian Spriegel
> Fix For: 2.18
>
>
> Older versions of surefire always showed the package name of each failed test
> in the result overview.
> Since surefire 2.13 I simply get the classname:
> {code}
> Results :
> Failed tests:
> RoundtripTest>AbstractTestNGSpringContextTests.run:196->test:115 error
> RoundtripTest>AbstractTestNGSpringContextTests.run:196->test:115 error
> {code}
> As you can see I have two tests called RoundtripTest in the overview. These
> testclasses are in different packages, but I do not know which one is which.
> My testsuite has 830 testcases, where ~650 are called RoundtripTest. So its
> quite hard now for me to identify the failing tests.
> SUREFIRE-936 seems to have changed this. I have not checked the git commit,
> but from the description I assume that was the change.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1024) "verify" goal ignores "dependenciesToScan" parameter when checking tests existence
[
https://jira.codehaus.org/browse/SUREFIRE-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian updated SUREFIRE-1024:
-
Fix Version/s: (was: 2.17)
2.18
> "verify" goal ignores "dependenciesToScan" parameter when checking tests
> existence
> --
>
> Key: SUREFIRE-1024
> URL: https://jira.codehaus.org/browse/SUREFIRE-1024
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.16
>Reporter: Dmitry Kholodilov
> Fix For: 2.18
>
> Attachments:
> verify_goal_ignores_dependenciesToScan_parameter_when_checking_tests_existence.patch
>
>
> Consider Maven project with packaging=pom that executes tests from some
> external jar:
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> test
> test
> test
> pom
>
>
> test
> tests-jar
> 1.0
> tests
>
>
> org.testng
> testng
> 6.8
>
>
>
>
>
> maven-failsafe-plugin
> 2.17-SNAPSHOT
>
>
> test:tests-jar
>
>
>
>
> integration-test
> integration-test
>
> integration-test
>
>
>
> verify
> verify
>
> verify
>
>
>
>
>
>
>
> {code}
> (real use case is execution of prebuilt end-to-end tests of some system after
> its deployment)
> When we run `mvn clean verify` on such project, failsafe plugin's "verify"
> goal reports the following:
> {noformat}
> [INFO] --- maven-failsafe-plugin:2.16:verify (verify) @ test ---
> [INFO] No tests to run.
> {noformat}
> Consequently, even if there are test failures, build success is reported.
> The reason of such behavior is that VerifyMojo ignores "dependenciesToScan"
> parameter. So, the fix is easy - check its existence along with
> "testClassesDirectory" existence, the same way as implemented in
> AbstractSurefireMojo.
> The patch in attachment includes integration test that checks for build
> failure when there is failed test from dependency jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1063) Typo in error message
[
https://jira.codehaus.org/browse/SUREFIRE-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian reassigned SUREFIRE-1063:
Assignee: Andreas Gudian
> Typo in error message
> -
>
> Key: SUREFIRE-1063
> URL: https://jira.codehaus.org/browse/SUREFIRE-1063
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.15
>Reporter: Gili
>Assignee: Andreas Gudian
>Priority: Minor
> Fix For: 2.17
>
>
> When Surefire fails, it dies with the following message:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-cli) on
> project web.backend: Execution default-cli of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked
> VM terminated without saying properly goodbye. VM crash or System.exit called
> ?
> [ERROR] Command wascmd.exe /X /C [etc]
> {code}
> Please fix the error message so "wascmd.exe" is "was cmd.exe". This used to
> be correct, but someone broke it a few releases back.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1034) dependencesToScan versus classifiers: what's the scoop?
[ https://jira.codehaus.org/browse/SUREFIRE-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Gudian updated SUREFIRE-1034: - Fix Version/s: (was: 2.17) 2.18 > dependencesToScan versus classifiers: what's the scoop? > --- > > Key: SUREFIRE-1034 > URL: https://jira.codehaus.org/browse/SUREFIRE-1034 > Project: Maven Surefire > Issue Type: Bug >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: 2.18 > > > # The doc could really use an example of dependenciesToScan > # The doc should tell me the syntax for using classifiers > # if classifiers don't work, please make them work. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1041) JUnit47 provider: Exception in JUnit Runner can crash test run without visible stack trace
[
https://jira.codehaus.org/browse/SUREFIRE-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian reassigned SUREFIRE-1041:
Assignee: Andreas Gudian
> JUnit47 provider: Exception in JUnit Runner can crash test run without
> visible stack trace
> --
>
> Key: SUREFIRE-1041
> URL: https://jira.codehaus.org/browse/SUREFIRE-1041
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Dan Fabulich
>Assignee: Andreas Gudian
> Fix For: 2.17
>
> Attachments: SUREFIRE-1041.patch, SUREFIRE-1041-testcase.zip
>
>
> Run the attached Maven project. Surefire is configured to use the JUnit47
> provider. There's one test, marked with @RunWith(BadRunner.class); the
> BadRunner class throws a NullPointerException in its "run" method.
> Expected: The tests should fail with a visible stacktrace; that's what
> happens when you don't use the JUnit47 provider.
> Actual: The tests fail with this unhelpful error:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.16:test (default-test) on
> project test: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.16:test failed:
> java.lang.RuntimeException: null,null,null,null,null: source is null -> [Help
> 1]
> {code}
> I'm also attaching a patch that fixes this problem: SimpleReportEntry should
> not throw a NPE with a null source/name, but should instead just accept them
> and convert them to the string "null." This allows the test to fail naturally
> and render the stacktrace in the console output and in surefire reports.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1047) Add @{...} property evaluation for the argLine
[
https://jira.codehaus.org/browse/SUREFIRE-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian closed SUREFIRE-1047.
Resolution: Fixed
> Add @{...} property evaluation for the argLine
> --
>
> Key: SUREFIRE-1047
> URL: https://jira.codehaus.org/browse/SUREFIRE-1047
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: 2.16
>Reporter: Henning Schmiedehausen
>Assignee: Andreas Gudian
> Fix For: 2.17
>
>
> Replaces expressions @{property-name} in the argLine with the corresponding
> properties from the model. This allows late evaluation of property values
> when the plugin is executed (as compared to evaluation when the pom is parsed
> as is done with ${property-name} expressions).
> This allows other plugins to modify or set properties with the changes
> getting picked up by surefire.
> Please merge the pull request at
> https://github.com/apache/maven-surefire/pull/30
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-580) Allow "fail fast" or stop running on first failure
[ https://jira.codehaus.org/browse/SUREFIRE-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Gudian updated SUREFIRE-580: Component/s: TestNG support > Allow "fail fast" or stop running on first failure > -- > > Key: SUREFIRE-580 > URL: https://jira.codehaus.org/browse/SUREFIRE-580 > Project: Maven Surefire > Issue Type: New Feature > Components: Junit 4.x support, TestNG support >Reporter: Paul Curren > > We have some slow Selenium builds. Waiting for indication of failure can take > a long time. It would be helpful if there was an option to finish the test > run on the first failure. > We could configure this on some of our slower builds so improve the speed of > the feedback loop in the cases where there are failures. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPLUGIN-261) sort goals in generated plugin.xml
[ https://jira.codehaus.org/browse/MPLUGIN-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MPLUGIN-261. - Resolution: Fixed Fix Version/s: 3.3 Assignee: Herve Boutemy done in [r1575558|http://svn.apache.org/r1575558] > sort goals in generated plugin.xml > -- > > Key: MPLUGIN-261 > URL: https://jira.codehaus.org/browse/MPLUGIN-261 > Project: Maven Plugin Tools > Issue Type: Wish > Components: Plugin Plugin >Affects Versions: 3.2 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Trivial > Fix For: 3.3 > > > this will ease plugin.xml reading and comparison over time -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-624: -- Assignee: (was: Ralph Goers) > automatic parent versioning > --- > > Key: MNG-624 > URL: https://jira.codehaus.org/browse/MNG-624 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Brett Porter >Priority: Blocker > Fix For: Issues to be reviewed for 4.x > > Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPLUGIN-261) sort goals in generated plugin.xml
Herve Boutemy created MPLUGIN-261: - Summary: sort goals in generated plugin.xml Key: MPLUGIN-261 URL: https://jira.codehaus.org/browse/MPLUGIN-261 Project: Maven Plugin Tools Issue Type: Wish Components: Plugin Plugin Affects Versions: 3.2 Reporter: Herve Boutemy Priority: Trivial this will ease plugin.xml reading and comparison over time -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-687) Change the prefered location for assembly descriptors and filter files
[
https://jira.codehaus.org/browse/MASSEMBLY-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MASSEMBLY-687.
-
Resolution: Fixed
Fixed in [r1575551|http://svn.apache.org/r1575551]
> Change the prefered location for assembly descriptors and filter files
> --
>
> Key: MASSEMBLY-687
> URL: https://jira.codehaus.org/browse/MASSEMBLY-687
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: site
>Affects Versions: 2.4
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 2.5
>
>
> We should [improve the
> documentation|http://maven.apache.org/plugins/maven-assembly-plugin/usage.html]
> according to the default folder layout which uses {{src/main/assembly}}
> whereas we documented
> [here|https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html]
> {{src/assembly}} as the prefered location.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-687) Change the prefered location for assembly descriptors and filter files
[
https://jira.codehaus.org/browse/MASSEMBLY-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reassigned MASSEMBLY-687:
-
Assignee: Karl Heinz Marbaise
> Change the prefered location for assembly descriptors and filter files
> --
>
> Key: MASSEMBLY-687
> URL: https://jira.codehaus.org/browse/MASSEMBLY-687
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: site
>Affects Versions: 2.4
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 2.5
>
>
> We should [improve the
> documentation|http://maven.apache.org/plugins/maven-assembly-plugin/usage.html]
> according to the default folder layout which uses {{src/main/assembly}}
> whereas we documented
> [here|https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html]
> {{src/assembly}} as the prefered location.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-687) Change the prefered location for assembly descriptors and filter files
[
https://jira.codehaus.org/browse/MASSEMBLY-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342601#comment-342601
]
Karl Heinz Marbaise commented on MASSEMBLY-687:
---
The have been many other locations like {{src/assemble/}} instead of
{{src/assembly}}.
> Change the prefered location for assembly descriptors and filter files
> --
>
> Key: MASSEMBLY-687
> URL: https://jira.codehaus.org/browse/MASSEMBLY-687
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: site
>Affects Versions: 2.4
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 2.5
>
>
> We should [improve the
> documentation|http://maven.apache.org/plugins/maven-assembly-plugin/usage.html]
> according to the default folder layout which uses {{src/main/assembly}}
> whereas we documented
> [here|https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html]
> {{src/assembly}} as the prefered location.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-687) Change the prefered location for assembly descriptors and filter files
[
https://jira.codehaus.org/browse/MASSEMBLY-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MASSEMBLY-687:
--
Fix Version/s: 2.5
> Change the prefered location for assembly descriptors and filter files
> --
>
> Key: MASSEMBLY-687
> URL: https://jira.codehaus.org/browse/MASSEMBLY-687
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: site
>Affects Versions: 2.4
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 2.5
>
>
> We should [improve the
> documentation|http://maven.apache.org/plugins/maven-assembly-plugin/usage.html]
> according to the default folder layout which uses {{src/main/assembly}}
> whereas we documented
> [here|https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html]
> {{src/assembly}} as the prefered location.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-687) Change the prefered location for assembly descriptors and filter files
Karl Heinz Marbaise created MASSEMBLY-687:
-
Summary: Change the prefered location for assembly descriptors and
filter files
Key: MASSEMBLY-687
URL: https://jira.codehaus.org/browse/MASSEMBLY-687
Project: Maven Assembly Plugin
Issue Type: Improvement
Components: site
Affects Versions: 2.4
Reporter: Karl Heinz Marbaise
Priority: Minor
We should [improve the
documentation|http://maven.apache.org/plugins/maven-assembly-plugin/usage.html]
according to the default folder layout which uses {{src/main/assembly}} whereas
we documented
[here|https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html]
{{src/assembly}} as the prefered location.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-652) Resource filtering does not work if line contains single @
[
https://jira.codehaus.org/browse/MASSEMBLY-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MASSEMBLY-652:
--
Fix Version/s: 2.5
> Resource filtering does not work if line contains single @
> --
>
> Key: MASSEMBLY-652
> URL: https://jira.codehaus.org/browse/MASSEMBLY-652
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: filtering
>Affects Versions: 2.4
>Reporter: Michael Gruebsch
>Priority: Minor
> Fix For: 2.5
>
> Attachments: assembly.xml, pom.xml, test.txt
>
>
> I want to include and filter Microsoft SQL Server SQL-files. SQL Server has
> extended properties which are declared as (extended property "Version" on a
> database):
> exec DB.sys.sp_addextendedproperty
> @name='Version'
> , @value='${project.version}'
> go
> However, if I filter the file which contains this call the expression
> ${project.version} is not been replaced. I get it working only when adding a
> second "@"
> exec DB.sys.sp_addextendedproperty
> @name='Version'
> , @value='@${project.version}'
> go
> This evaluates to
> exec DB.sys.sp_addextendedproperty
> @name='Version'
> , @value='@2.03.002'
> go
> However the "@" is not really wanted.
> Thank you.
> PS: Please rename attached "test.txt" to "test.sql". Got an server error
> while trying to upload "test.sql".
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-652) Resource filtering does not work if line contains single @
[
https://jira.codehaus.org/browse/MASSEMBLY-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342600#comment-342600
]
Karl Heinz Marbaise commented on MASSEMBLY-652:
---
Unfortunately i have to acknowledge this as a bug. I have created a [sample
project on github which exactly shows the described
behaviour|https://github.com/khmarbaise/massembly/tree/master/massembly-652].
> Resource filtering does not work if line contains single @
> --
>
> Key: MASSEMBLY-652
> URL: https://jira.codehaus.org/browse/MASSEMBLY-652
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: filtering
>Affects Versions: 2.4
>Reporter: Michael Gruebsch
>Priority: Minor
> Fix For: 2.5
>
> Attachments: assembly.xml, pom.xml, test.txt
>
>
> I want to include and filter Microsoft SQL Server SQL-files. SQL Server has
> extended properties which are declared as (extended property "Version" on a
> database):
> exec DB.sys.sp_addextendedproperty
> @name='Version'
> , @value='${project.version}'
> go
> However, if I filter the file which contains this call the expression
> ${project.version} is not been replaced. I get it working only when adding a
> second "@"
> exec DB.sys.sp_addextendedproperty
> @name='Version'
> , @value='@${project.version}'
> go
> This evaluates to
> exec DB.sys.sp_addextendedproperty
> @name='Version'
> , @value='@2.03.002'
> go
> However the "@" is not really wanted.
> Thank you.
> PS: Please rename attached "test.txt" to "test.sql". Got an server error
> while trying to upload "test.sql".
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-686) Update version of maven-filtering to 1.2
Karl Heinz Marbaise created MASSEMBLY-686: - Summary: Update version of maven-filtering to 1.2 Key: MASSEMBLY-686 URL: https://jira.codehaus.org/browse/MASSEMBLY-686 Project: Maven Assembly Plugin Issue Type: Improvement Components: filtering Affects Versions: 2.4 Reporter: Karl Heinz Marbaise Priority: Minor We should update to maven-filtering 1.2 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-665) OS dependent behaviour while packaging
[
https://jira.codehaus.org/browse/MASSEMBLY-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342599#comment-342599
]
Karl Heinz Marbaise commented on MASSEMBLY-665:
---
Would you please so kind to attach a full working example to the issue or may
be a reference to a github project which would make the analysis easier. Thanks
in advance.
> OS dependent behaviour while packaging
> --
>
> Key: MASSEMBLY-665
> URL: https://jira.codehaus.org/browse/MASSEMBLY-665
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: sles 11 / windows 7
>Reporter: Jörg Sesterhenn
>
> Given this part of a assembly descriptor:
> {code}
>
>
> src/main/script
> bin
> true
>
> *
>
>
>
> /src/main/conf
> conf
>
> *
>
>
>
> {code}
> Under windows 7 this packages everything as (I) expected:
> {code}
> src/
> main/
> conf/
> script/
> {code}
>
> Under linux the package misses the directory 'conf':
> {code}
> src/
> main/
> script/
> {code}
> Linux seems to interpret the directory as absolute path due to the leading
> slash.
> Please either
> * accept the above config and build the same package on any system, or
> * fail the build with an invalid descriptor error, or
> * (at least) log a warning that due to the config builds are depending on the
> OS.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-664) Using pom artifact as a dependency results in build failures
[
https://jira.codehaus.org/browse/MASSEMBLY-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MASSEMBLY-664.
-
Resolution: Cannot Reproduce
I have created a [sample project based on your
pom|https://github.com/khmarbaise/massembly/tree/master/massembly-664] (I just
used a different artifact as dependency with the packaging type pom) which
results into the following message:
{code}
[INFO] --- maven-site-plugin:3.3:attach-descriptor (attach-descriptor) @
massembly-664 ---
[INFO]
[INFO] --- maven-assembly-plugin:2.4:single (default) @ massembly-664 ---
[WARNING] Cannot include project artifact:
com.soebes.test.assembly:massembly-664:pom:0.0.1-SNAPSHOT; it doesn't have an
associated file or directory.
[INFO] Building jar:
/Users/kama/ws-git/apache/massembly/massembly-664/target/massembly-664-0.0.1-SNAPSHOT-jar-with-dependencies.jar
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1.955s
[INFO] Finished at: Sat Mar 08 15:08:01 CET 2014
[INFO] Final Memory: 16M/981M
[INFO]
{code}
This looks like either your example pom is not equivalent to the original
problem or i missed something. The things which looks different to me is the
part {{single failed: For artifact {null:null:null:jar}: The groupId cannot be
empty. -> [Help 1]}} which i can't reproduce.
So I will close this issue. If you have any objections or would like to change
the example to get a better analysis to the problem you simple fork it on
Github and send pull request for the example project so we can discuss the
problem and of course we can reopen the issue.
> Using pom artifact as a dependency results in build failures
>
>
> Key: MASSEMBLY-664
> URL: https://jira.codehaus.org/browse/MASSEMBLY-664
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: Apache Maven 3.0.5
> (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 06:51:28-0700)
> Maven home: C:\gnu\maven
> Java version: 1.6.0_37, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files (x86)\Java\jdk1.6.0_37\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Belai Beshah
> Attachments: pom.xml
>
>
> A project with an artifact of pom dependency fails with the
> following error:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.4:single (default) on
> project zip-error-sample: Execution default of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed: For
> artifact {null:null:null:jar}: The groupId cannot be empty. -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-628) Bogus warning when assembling to a directory
[ https://jira.codehaus.org/browse/MASSEMBLY-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342595#comment-342595 ] Dennis Lundberg commented on MASSEMBLY-628: --- Thanks for that excellent explanation Karl Heinz. I've been wondering about the cause of this warning myself. > Bogus warning when assembling to a directory > > > Key: MASSEMBLY-628 > URL: https://jira.codehaus.org/browse/MASSEMBLY-628 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: c:\Users\visola\Downloads\springsource\apache-maven-3.0.3 > Java version: 1.6.0_32, vendor: Sun Microsystems Inc. > Java home: c:\Program Files\Java\jdk1.6.0_32\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" > maven-assembly-plugin:2.3 >Reporter: Vinicius Isola > Attachments: test.zip > > > When adding a "dir" format to the assembly file, it will output a bogus > warning like the following: > [WARNING] Assembly file: c:\Users\visola\temp\test\target\test-1.0.0 is not a > regular file (it may be a directory). It cannot be attached to the project > build for installation or deployment. > I think it is related to bug: http://jira.codehaus.org/browse/MASSEMBLY-289 > Attached is an example project that can reproduce the problem just running > "mvn clean install" -- This message was sent by Atlassian JIRA (v6.1.6#6162)
