[jira] (MNG-5591) Installing workspace reader triggers MNG-5503
[
https://jira.codehaus.org/browse/MNG-5591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341905#comment-341905
]
Mikolaj Izdebski commented on MNG-5591:
---
Using git bisection method I have identified the following commit to introduce
the regression:
{code}
commit 1d84cbeffad39dcd57f85cb312e17c46c9d3dac7
Author: Jason van Zyl
Date: Sun Feb 9 21:52:35 2014 -0500
MNG-5578: Make the workspace reader pluggable by creating a session scope
where the MavenSession created can be injected in implementations that have the
@SessionScoped annotation
{code}
> Installing workspace reader triggers MNG-5503
> -
>
> Key: MNG-5591
> URL: https://jira.codehaus.org/browse/MNG-5591
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.2.1
>Reporter: Mikolaj Izdebski
> Attachments: dummy-extension.tar.gz
>
>
> It looks like Maven 3.2.1 introduced a regression. Installing
> extension which provides workspace reader triggers MNG-5503.
> Maven resolves artifacts from reactor, workspace, repositories (in
> that order). In standard Maven distribution there is no workspace,
> but Maven provides an extension point which allows extensions to
> install workspace reader by providing a component with role
> {{org.eclipse.aether.repository.WorkspaceReader}} and role hint {{ide}}.
> Installing workspace reader extension in Maven 3.2.1 triggers a
> regression - Maven fails to resolve artifacts produced by reactor
> build (MNG-5503). Even though artifact is present in reactor Maven
> queries workspace about it and if artifact is not found there it
> continues with repositories. Expected behaviour is resolving artifact
> from reactor.
> Steps to reproduce this:
> 1) download and extract {{apache-maven-3.2.1-bin.tar.gz}}
> 2) download dummy-extension.tar.gz and build it with {{mvn package}}
> 3) download reproducer for MNG-5503 from:
> https://bugzilla.redhat.com/attachment.cgi?id=784786
> 4) try to build reproducer project, it succeeds
> 5) copy {{dummy-extension-1.0.0.jar}} to Maven {{lib/ext}}
> 6) try to build reproducer project, it fails
> When repeating the same steps for Maven 3.1.1 failure is not reproducible.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5591) Installing workspace reader triggers MNG-5503
[
https://jira.codehaus.org/browse/MNG-5591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikolaj Izdebski updated MNG-5591:
--
Patch Submitted: Yes
> Installing workspace reader triggers MNG-5503
> -
>
> Key: MNG-5591
> URL: https://jira.codehaus.org/browse/MNG-5591
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.2.1
>Reporter: Mikolaj Izdebski
> Attachments:
> 0001-MNG-5591-Set-role-hint-for-ReactorReader-to-default.patch,
> dummy-extension.tar.gz
>
>
> It looks like Maven 3.2.1 introduced a regression. Installing
> extension which provides workspace reader triggers MNG-5503.
> Maven resolves artifacts from reactor, workspace, repositories (in
> that order). In standard Maven distribution there is no workspace,
> but Maven provides an extension point which allows extensions to
> install workspace reader by providing a component with role
> {{org.eclipse.aether.repository.WorkspaceReader}} and role hint {{ide}}.
> Installing workspace reader extension in Maven 3.2.1 triggers a
> regression - Maven fails to resolve artifacts produced by reactor
> build (MNG-5503). Even though artifact is present in reactor Maven
> queries workspace about it and if artifact is not found there it
> continues with repositories. Expected behaviour is resolving artifact
> from reactor.
> Steps to reproduce this:
> 1) download and extract {{apache-maven-3.2.1-bin.tar.gz}}
> 2) download dummy-extension.tar.gz and build it with {{mvn package}}
> 3) download reproducer for MNG-5503 from:
> https://bugzilla.redhat.com/attachment.cgi?id=784786
> 4) try to build reproducer project, it succeeds
> 5) copy {{dummy-extension-1.0.0.jar}} to Maven {{lib/ext}}
> 6) try to build reproducer project, it fails
> When repeating the same steps for Maven 3.1.1 failure is not reproducible.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5591) Installing workspace reader triggers MNG-5503
[
https://jira.codehaus.org/browse/MNG-5591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikolaj Izdebski updated MNG-5591:
--
Attachment: 0001-MNG-5591-Set-role-hint-for-ReactorReader-to-default.patch
Proposed patch which fixed the issue
> Installing workspace reader triggers MNG-5503
> -
>
> Key: MNG-5591
> URL: https://jira.codehaus.org/browse/MNG-5591
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.2.1
>Reporter: Mikolaj Izdebski
> Attachments:
> 0001-MNG-5591-Set-role-hint-for-ReactorReader-to-default.patch,
> dummy-extension.tar.gz
>
>
> It looks like Maven 3.2.1 introduced a regression. Installing
> extension which provides workspace reader triggers MNG-5503.
> Maven resolves artifacts from reactor, workspace, repositories (in
> that order). In standard Maven distribution there is no workspace,
> but Maven provides an extension point which allows extensions to
> install workspace reader by providing a component with role
> {{org.eclipse.aether.repository.WorkspaceReader}} and role hint {{ide}}.
> Installing workspace reader extension in Maven 3.2.1 triggers a
> regression - Maven fails to resolve artifacts produced by reactor
> build (MNG-5503). Even though artifact is present in reactor Maven
> queries workspace about it and if artifact is not found there it
> continues with repositories. Expected behaviour is resolving artifact
> from reactor.
> Steps to reproduce this:
> 1) download and extract {{apache-maven-3.2.1-bin.tar.gz}}
> 2) download dummy-extension.tar.gz and build it with {{mvn package}}
> 3) download reproducer for MNG-5503 from:
> https://bugzilla.redhat.com/attachment.cgi?id=784786
> 4) try to build reproducer project, it succeeds
> 5) copy {{dummy-extension-1.0.0.jar}} to Maven {{lib/ext}}
> 6) try to build reproducer project, it fails
> When repeating the same steps for Maven 3.1.1 failure is not reproducible.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-866) "successful" release:perform with dryRun=true should not invoke release:clean
Jürgen created MRELEASE-866: --- Summary: "successful" release:perform with dryRun=true should not invoke release:clean Key: MRELEASE-866 URL: https://jira.codehaus.org/browse/MRELEASE-866 Project: Maven Release Plugin Issue Type: Wish Components: clean, perform Affects Versions: 2.4.2 Environment: maven-2.2.1 Reporter: Jürgen Priority: Minor I recently upgraded maven-release-plugin version to 2.4.2 from 2.0 I observed a change in the behaviour of release:perform together with dryRun (on a side-note, in 2.0 dryRun user property did not seem to have an effect on release:perform) basically: 1. dryRun=true release:prepare 2. dryRun=false release:prepare: generate tag+release info 3. dryRun=true (due to it being considered in 2.4.2) release:perform: no deployment into repository, BUT release:clean removes release info 4. dryRun=false release:perform: fails, lacks release info I know I should not do step #3, but I recommend not to execute release:clean after a "successful" release:perform with dryRun=true -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-640) Maven searches only central repository for imported dependencies
[ https://jira.codehaus.org/browse/MSITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341912#comment-341912 ] Christian Höltje commented on MSITE-640: Additional information at: http://stackoverflow.com/questions/15366056/how-can-i-get-the-maven-site-plugin-to-resolve-the-parent-pom-xml-of-my-multimod > Maven searches only central repository for imported dependencies > > > Key: MSITE-640 > URL: https://jira.codehaus.org/browse/MSITE-640 > Project: Maven Site Plugin > Issue Type: Bug > Components: Maven 3 >Affects Versions: 3.0 > Environment: Windows 7 >Reporter: Markus Tippmann > Attachments: stacktrace.txt > > > We are using dependencyManagement with "import" scope like described here: > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies > Problem occurs only at site generation, not at build time, where it works > perfectly. > The site plugin tries to find the imported artifacts, but searches only the > central repository and ignores the repositories in settings.xml > configuration. Mirror settings work, if "central" is mirrored, but > dependencies need to be resolved from two repositories, so one mirror does > not help here. > I try to attach the relevant parts of the stacktrace. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-640) Maven searches only central repository for imported dependencies
[ https://jira.codehaus.org/browse/MSITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341914#comment-341914 ] Jim Hurne commented on MSITE-640: - It has been two years since this bug was opened, and it is still a problem. That means that people are ether downgrading to 3.3 of the maven-site-plugin, or are implementing crazy workarounds like manually editing files in the .m2/repository directory, and have been doing so for two years. Michael Koch suggested a fix in this earlier comment: http://jira.codehaus.org/browse/MSITE-640?focusedCommentId=326248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-326248 Any chance someone could look at the fix suggested by Michael? Is there anything else myself or the community can do to move this bug forward? > Maven searches only central repository for imported dependencies > > > Key: MSITE-640 > URL: https://jira.codehaus.org/browse/MSITE-640 > Project: Maven Site Plugin > Issue Type: Bug > Components: Maven 3 >Affects Versions: 3.0 > Environment: Windows 7 >Reporter: Markus Tippmann > Attachments: stacktrace.txt > > > We are using dependencyManagement with "import" scope like described here: > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies > Problem occurs only at site generation, not at build time, where it works > perfectly. > The site plugin tries to find the imported artifacts, but searches only the > central repository and ignores the repositories in settings.xml > configuration. Mirror settings work, if "central" is mirrored, but > dependencies need to be resolved from two repositories, so one mirror does > not help here. > I try to attach the relevant parts of the stacktrace. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MANTTASKS-245) Ability to download sources/documentation depending on some parameter
Jacek Lewandowski created MANTTASKS-245: --- Summary: Ability to download sources/documentation depending on some parameter Key: MANTTASKS-245 URL: https://jira.codehaus.org/browse/MANTTASKS-245 Project: Maven Ant Tasks Issue Type: Wish Affects Versions: 2.1.3 Reporter: Jacek Lewandowski Priority: Trivial I would like to download sources/documentation only in case when I run specific ant target - for example when I want to generate IntelliJ Idea or Eclipse project. However, I don't want to download them when I just want to build the project. I think it can be done by providing some additional parameters, such as "disableSourcesDownload", "disableJavaDocsDownload" which would have effect when set to true. Therefore, it will be backward compatible. Is it possible to add those parameters and to provide some other way to control downloading sources and documentation? Or, can I submit a patch for that? -- 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:comment-tabpanel&focusedCommentId=341937#comment-341937
]
Kirill Kozlov commented on SUREFIRE-1062:
-
Hi! Sorry for delay.
I've sent pull-request with fix and 2 simple tests. I see that tests are
disabled in maven build for the module, but I want to make sure that the fix
works, at least in my environment.
https://github.com/apache/maven-surefire/pull/35
> 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
>
> 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-1066) version 2.14.1 runs tests only if named *Test.java
[ https://jira.codehaus.org/browse/SUREFIRE-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341938#comment-341938 ] Karl Heinz Marbaise commented on SUREFIRE-1066: --- First which test classes are beeing run is based on the [include rules of maven-surefire-plugin|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#includes] which is not related to any annotation if you use plain maven-surefire-plugin. To make discussion simpler [i have setup an example github project which contains a configuration for testng as well as junit|https://github.com/khmarbaise/surefire]. I have checked maven-surefire-plugin 2.11, 2.7.2, 2.14.1 and 2.16 and all of them behave the same. Only a test class [which fulfils the naming convention|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#includes] its test will be exeuted. The naming conventions is needed to [separate between unit and integration tests|http://maven.apache.org/surefire/maven-failsafe-plugin/]. > version 2.14.1 runs tests only if named *Test.java > -- > > Key: SUREFIRE-1066 > URL: https://jira.codehaus.org/browse/SUREFIRE-1066 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.14.1, 2.16 >Reporter: Max Calderoni > > This is a regression from 2.11, where it was working fine. > For TestNG (and JUnit) tests, in order to be run by surefire, all you needed > to do is to get the correct annotations in place (@Test) regardless of the > name of your test classes. > Looks like between version 2.11 and 2.14.1 surefire started *not* running > classes whose name did not end with the word 'Test' (like it was few years > back, when there were no annotations). > That means that upgrading to 2.16 will break previous test code. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1066) version 2.14.1 runs tests only if named *Test.java
[ https://jira.codehaus.org/browse/SUREFIRE-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341938#comment-341938 ] Karl Heinz Marbaise edited comment on SUREFIRE-1066 at 2/24/14 2:13 PM: First which test classes are beeing run is based on the [include rules of maven-surefire-plugin|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#includes] which is not related to any annotation if you use plain maven-surefire-plugin. To make discussion simpler [i have setup an example github project which contains a configuration for testng as well as junit|https://github.com/khmarbaise/surefire]. I have checked maven-surefire-plugin 2.11, 2.7.2, 2.14.1 and 2.16 and all of them behave the same. Only a test class [which fulfils the naming convention|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#includes] its test will be exeuted. The naming conventions is needed to [separate between unit and integration tests|http://maven.apache.org/surefire/maven-failsafe-plugin/]. Apart from the above i can't reproduce your issue. was (Author: khmarbaise): First which test classes are beeing run is based on the [include rules of maven-surefire-plugin|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#includes] which is not related to any annotation if you use plain maven-surefire-plugin. To make discussion simpler [i have setup an example github project which contains a configuration for testng as well as junit|https://github.com/khmarbaise/surefire]. I have checked maven-surefire-plugin 2.11, 2.7.2, 2.14.1 and 2.16 and all of them behave the same. Only a test class [which fulfils the naming convention|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#includes] its test will be exeuted. The naming conventions is needed to [separate between unit and integration tests|http://maven.apache.org/surefire/maven-failsafe-plugin/]. > version 2.14.1 runs tests only if named *Test.java > -- > > Key: SUREFIRE-1066 > URL: https://jira.codehaus.org/browse/SUREFIRE-1066 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.14.1, 2.16 >Reporter: Max Calderoni > > This is a regression from 2.11, where it was working fine. > For TestNG (and JUnit) tests, in order to be run by surefire, all you needed > to do is to get the correct annotations in place (@Test) regardless of the > name of your test classes. > Looks like between version 2.11 and 2.14.1 surefire started *not* running > classes whose name did not end with the word 'Test' (like it was few years > back, when there were no annotations). > That means that upgrading to 2.16 will break previous test code. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1066) version 2.14.1 runs tests only if named *Test.java
[ https://jira.codehaus.org/browse/SUREFIRE-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341939#comment-341939 ] Max Calderoni commented on SUREFIRE-1066: - Karl, thanks for checking: now i would like to reproduce your tests to see what the difference is. However, after cloning the link you provide, https://github.com/khmarbaise/surefire, and doing 'mvn install' the two maven projects require a parent, which i am not sure how to access... Can you specify please? com.soebes.smpp smpp 0.6.3 > version 2.14.1 runs tests only if named *Test.java > -- > > Key: SUREFIRE-1066 > URL: https://jira.codehaus.org/browse/SUREFIRE-1066 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.14.1, 2.16 >Reporter: Max Calderoni > > This is a regression from 2.11, where it was working fine. > For TestNG (and JUnit) tests, in order to be run by surefire, all you needed > to do is to get the correct annotations in place (@Test) regardless of the > name of your test classes. > Looks like between version 2.11 and 2.14.1 surefire started *not* running > classes whose name did not end with the word 'Test' (like it was few years > back, when there were no annotations). > That means that upgrading to 2.16 will break previous test code. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1066) version 2.14.1 runs tests only if named *Test.java
[ https://jira.codehaus.org/browse/SUREFIRE-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341940#comment-341940 ] Max Calderoni commented on SUREFIRE-1066: - ...never mind, was my company's mirror.. please disregard... Going to check your code now. > version 2.14.1 runs tests only if named *Test.java > -- > > Key: SUREFIRE-1066 > URL: https://jira.codehaus.org/browse/SUREFIRE-1066 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.14.1, 2.16 >Reporter: Max Calderoni > > This is a regression from 2.11, where it was working fine. > For TestNG (and JUnit) tests, in order to be run by surefire, all you needed > to do is to get the correct annotations in place (@Test) regardless of the > name of your test classes. > Looks like between version 2.11 and 2.14.1 surefire started *not* running > classes whose name did not end with the word 'Test' (like it was few years > back, when there were no annotations). > That means that upgrading to 2.16 will break previous test code. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1066) version 2.14.1 runs tests only if named *Test.java
[ https://jira.codehaus.org/browse/SUREFIRE-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341943#comment-341943 ] Max Calderoni commented on SUREFIRE-1066: - Verified, finding the same as you said. Please let me check back with team first, as i believe someone was reproducing this issue. After double-checking (maybe has to do with profiles) will then close this issue. > version 2.14.1 runs tests only if named *Test.java > -- > > Key: SUREFIRE-1066 > URL: https://jira.codehaus.org/browse/SUREFIRE-1066 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.14.1, 2.16 >Reporter: Max Calderoni > > This is a regression from 2.11, where it was working fine. > For TestNG (and JUnit) tests, in order to be run by surefire, all you needed > to do is to get the correct annotations in place (@Test) regardless of the > name of your test classes. > Looks like between version 2.11 and 2.14.1 surefire started *not* running > classes whose name did not end with the word 'Test' (like it was few years > back, when there were no annotations). > That means that upgrading to 2.16 will break previous test code. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAR-175) Documentation problem for test-jar
Karl Heinz Marbaise created MJAR-175:
Summary: Documentation problem for test-jar
Key: MJAR-175
URL: https://jira.codehaus.org/browse/MJAR-175
Project: Maven JAR Plugin
Issue Type: Improvement
Affects Versions: 2.4
Environment: all
Reporter: Karl Heinz Marbaise
Priority: Minor
The web-site contains an example to [create a
test-jar|http://maven.apache.org/plugins/maven-jar-plugin/usage.html] which
explains: {{To reuse this artifact in an other project, you must declare this
dependency with classifier test-jar :}} which must be type as the following:
To reuse this artifact in an other project, you must declare this dependency
with type test-jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAR-175) Documentation problem for test-jar
[
https://jira.codehaus.org/browse/MJAR-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MJAR-175.
Resolution: Fixed
Fix Version/s: 2.5
Assignee: Karl Heinz Marbaise
Fixed in [r1571455|http://svn.apache.org/r1571455].
> Documentation problem for test-jar
> --
>
> Key: MJAR-175
> URL: https://jira.codehaus.org/browse/MJAR-175
> Project: Maven JAR Plugin
> Issue Type: Improvement
>Affects Versions: 2.4
> Environment: all
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 2.5
>
>
> The web-site contains an example to [create a
> test-jar|http://maven.apache.org/plugins/maven-jar-plugin/usage.html] which
> explains: {{To reuse this artifact in an other project, you must declare this
> dependency with classifier test-jar :}} which must be type as the following:
> To reuse this artifact in an other project, you must declare this dependency
> with type test-jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5591) Installing workspace reader triggers MNG-5503
[
https://jira.codehaus.org/browse/MNG-5591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341954#comment-341954
]
Jason van Zyl commented on MNG-5591:
That dummy workspace reader never returns any versions and returns null for
findArtifact so I'm not sure what's happening but that implementation should
never return anything so something else is going on. Do you have the source for
the actual WorkspaceReader that is causing the issue?
> Installing workspace reader triggers MNG-5503
> -
>
> Key: MNG-5591
> URL: https://jira.codehaus.org/browse/MNG-5591
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.2.1
>Reporter: Mikolaj Izdebski
> Attachments:
> 0001-MNG-5591-Set-role-hint-for-ReactorReader-to-default.patch,
> dummy-extension.tar.gz
>
>
> It looks like Maven 3.2.1 introduced a regression. Installing
> extension which provides workspace reader triggers MNG-5503.
> Maven resolves artifacts from reactor, workspace, repositories (in
> that order). In standard Maven distribution there is no workspace,
> but Maven provides an extension point which allows extensions to
> install workspace reader by providing a component with role
> {{org.eclipse.aether.repository.WorkspaceReader}} and role hint {{ide}}.
> Installing workspace reader extension in Maven 3.2.1 triggers a
> regression - Maven fails to resolve artifacts produced by reactor
> build (MNG-5503). Even though artifact is present in reactor Maven
> queries workspace about it and if artifact is not found there it
> continues with repositories. Expected behaviour is resolving artifact
> from reactor.
> Steps to reproduce this:
> 1) download and extract {{apache-maven-3.2.1-bin.tar.gz}}
> 2) download dummy-extension.tar.gz and build it with {{mvn package}}
> 3) download reproducer for MNG-5503 from:
> https://bugzilla.redhat.com/attachment.cgi?id=784786
> 4) try to build reproducer project, it succeeds
> 5) copy {{dummy-extension-1.0.0.jar}} to Maven {{lib/ext}}
> 6) try to build reproducer project, it fails
> When repeating the same steps for Maven 3.1.1 failure is not reproducible.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5591) Installing workspace reader triggers MNG-5503
[
https://jira.codehaus.org/browse/MNG-5591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341958#comment-341958
]
Mikolaj Izdebski commented on MNG-5591:
---
The dummy workspace reader I provided is supposed simulate an empty workspace,
which doesn't contain any artifacts. I expect Maven behaviour to remain
unchanged after adding empty workspace, but Maven 3.2.1 changes behaviour and
that's what this bug report is about. (Behaviour changes no matter if
workspace is empty or not, but empty workspace is the simplest reproducer. The
actual workspace reader is avaiable at Github, but it shouldn't be needed to
reproduce the problem. The code is at
https://github.com/mizdebsk/xmvn/blob/master/xmvn-connector-aether/src/main/java/org/fedoraproject/xmvn/connector/aether/XMvnWorkspaceReader.java)
I think the problem is in incorrect {{@Named}} annotation in {{ReactorReader}}
class. In this case {{@Named}} with no argument is equivalent to {{@Named(
"org.apache.maven.ReactorReader" )}}, however code in {{DefaultMaven}} is
calling {{PlexusContainer.lookup()}} with no hint argument which is equivalent
to hint {{default}}. Sisu uses implicit role hint {{default}} only for
components which class names are prefixed with {{Default}}. Since
{{ReactorReader}} is not, hole hint {{default}} needs to be explicitly added as
argument to {{@Named}}.
> Installing workspace reader triggers MNG-5503
> -
>
> Key: MNG-5591
> URL: https://jira.codehaus.org/browse/MNG-5591
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.2.1
>Reporter: Mikolaj Izdebski
> Attachments:
> 0001-MNG-5591-Set-role-hint-for-ReactorReader-to-default.patch,
> dummy-extension.tar.gz
>
>
> It looks like Maven 3.2.1 introduced a regression. Installing
> extension which provides workspace reader triggers MNG-5503.
> Maven resolves artifacts from reactor, workspace, repositories (in
> that order). In standard Maven distribution there is no workspace,
> but Maven provides an extension point which allows extensions to
> install workspace reader by providing a component with role
> {{org.eclipse.aether.repository.WorkspaceReader}} and role hint {{ide}}.
> Installing workspace reader extension in Maven 3.2.1 triggers a
> regression - Maven fails to resolve artifacts produced by reactor
> build (MNG-5503). Even though artifact is present in reactor Maven
> queries workspace about it and if artifact is not found there it
> continues with repositories. Expected behaviour is resolving artifact
> from reactor.
> Steps to reproduce this:
> 1) download and extract {{apache-maven-3.2.1-bin.tar.gz}}
> 2) download dummy-extension.tar.gz and build it with {{mvn package}}
> 3) download reproducer for MNG-5503 from:
> https://bugzilla.redhat.com/attachment.cgi?id=784786
> 4) try to build reproducer project, it succeeds
> 5) copy {{dummy-extension-1.0.0.jar}} to Maven {{lib/ext}}
> 6) try to build reproducer project, it fails
> When repeating the same steps for Maven 3.1.1 failure is not reproducible.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5591) Installing workspace reader triggers MNG-5503
[
https://jira.codehaus.org/browse/MNG-5591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341958#comment-341958
]
Mikolaj Izdebski edited comment on MNG-5591 at 2/24/14 6:21 PM:
The dummy workspace reader I provided is supposed simulate an empty workspace,
which doesn't contain any artifacts. I expect Maven behaviour to remain
unchanged after adding empty workspace, but Maven 3.2.1 changes behaviour and
that's what this bug report is about. (Behaviour changes no matter if
workspace is empty or not, but empty workspace is the simplest reproducer. The
actual workspace reader is avaiable at Github, but it shouldn't be needed to
reproduce the problem. The code is at
https://github.com/mizdebsk/xmvn/blob/master/xmvn-connector-aether/src/main/java/org/fedoraproject/xmvn/connector/aether/XMvnWorkspaceReader.java)
I think the problem is in incorrect {{@Named}} annotation in {{ReactorReader}}
class. In this case {{@Named}} with no argument is equivalent to {{@Named(
"org.apache.maven.ReactorReader" )}}, however code in {{DefaultMaven}} is
calling {{PlexusContainer.lookup()}} with no hint argument which is equivalent
to hint {{default}}. Sisu uses implicit role hint {{default}} only for
components which class names are prefixed with {{Default}}. Since
{{ReactorReader}} is not, role hint {{default}} needs to be explicitly added as
argument to {{@Named}}.
was (Author: mizdebsk):
The dummy workspace reader I provided is supposed simulate an empty workspace,
which doesn't contain any artifacts. I expect Maven behaviour to remain
unchanged after adding empty workspace, but Maven 3.2.1 changes behaviour and
that's what this bug report is about. (Behaviour changes no matter if
workspace is empty or not, but empty workspace is the simplest reproducer. The
actual workspace reader is avaiable at Github, but it shouldn't be needed to
reproduce the problem. The code is at
https://github.com/mizdebsk/xmvn/blob/master/xmvn-connector-aether/src/main/java/org/fedoraproject/xmvn/connector/aether/XMvnWorkspaceReader.java)
I think the problem is in incorrect {{@Named}} annotation in {{ReactorReader}}
class. In this case {{@Named}} with no argument is equivalent to {{@Named(
"org.apache.maven.ReactorReader" )}}, however code in {{DefaultMaven}} is
calling {{PlexusContainer.lookup()}} with no hint argument which is equivalent
to hint {{default}}. Sisu uses implicit role hint {{default}} only for
components which class names are prefixed with {{Default}}. Since
{{ReactorReader}} is not, hole hint {{default}} needs to be explicitly added as
argument to {{@Named}}.
> Installing workspace reader triggers MNG-5503
> -
>
> Key: MNG-5591
> URL: https://jira.codehaus.org/browse/MNG-5591
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.2.1
>Reporter: Mikolaj Izdebski
> Attachments:
> 0001-MNG-5591-Set-role-hint-for-ReactorReader-to-default.patch,
> dummy-extension.tar.gz
>
>
> It looks like Maven 3.2.1 introduced a regression. Installing
> extension which provides workspace reader triggers MNG-5503.
> Maven resolves artifacts from reactor, workspace, repositories (in
> that order). In standard Maven distribution there is no workspace,
> but Maven provides an extension point which allows extensions to
> install workspace reader by providing a component with role
> {{org.eclipse.aether.repository.WorkspaceReader}} and role hint {{ide}}.
> Installing workspace reader extension in Maven 3.2.1 triggers a
> regression - Maven fails to resolve artifacts produced by reactor
> build (MNG-5503). Even though artifact is present in reactor Maven
> queries workspace about it and if artifact is not found there it
> continues with repositories. Expected behaviour is resolving artifact
> from reactor.
> Steps to reproduce this:
> 1) download and extract {{apache-maven-3.2.1-bin.tar.gz}}
> 2) download dummy-extension.tar.gz and build it with {{mvn package}}
> 3) download reproducer for MNG-5503 from:
> https://bugzilla.redhat.com/attachment.cgi?id=784786
> 4) try to build reproducer project, it succeeds
> 5) copy {{dummy-extension-1.0.0.jar}} to Maven {{lib/ext}}
> 6) try to build reproducer project, it fails
> When repeating the same steps for Maven 3.1.1 failure is not reproducible.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
