[jira] (SUREFIRE-437) Provide an option to log to the console on every test method
[
https://jira.codehaus.org/browse/SUREFIRE-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355968#comment-355968
]
Karl M. Davis commented on SUREFIRE-437:
I'm bumping into this today myself, on some JUnit tests that are parameterized.
I'm actually surprised I haven't noticed before that Surefire/Failsafe aren't
logging at the start of each test case-- I'd thought it did. Makes it very hard
to correlate log output with test cases, short of adding
{{LOGGER.info("Starting test case foo.");}}
> Provide an option to log to the console on every test method
>
>
> Key: SUREFIRE-437
> URL: https://jira.codehaus.org/browse/SUREFIRE-437
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Reporter: Dan Fabulich
> Fix For: Backlog
>
>
> We already log to the console whenever we regain control from the testing
> framework; in JUnit directory suites, that's once per class, which is pretty
> often, but if you use JUnit TestSuites or TestNG, we lose control at the
> start of the run and don't get it back until the end of the run.
> We should provide an option to log to the console after every test case
> method. It should probably be off by default...?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-890) Prompt for usernames and passwords when running interactively
[
https://jira.codehaus.org/browse/MRELEASE-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353300#comment-353300
]
Karl M. Davis commented on MRELEASE-890:
Sounds reasonable enough to me. That's not really any different than trying
whatever (potentially incorrect) credentials they actually _did_ supply first,
and prompting for new ones if those fail.
> Prompt for usernames and passwords when running interactively
> -
>
> Key: MRELEASE-890
> URL: https://jira.codehaus.org/browse/MRELEASE-890
> Project: Maven Release Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.1
>Reporter: Karl M. Davis
>Priority: Critical
>
> I've been using the release plugin for years now, and also supporting a lot
> of other folks using it.
> It occurred to me today, that one of the most common sources of frustration
> and problems with the release plugin has been authentication: either users
> never added {{}} entries to their {{settings.xml}} or their password
> expired and they forgot to update it. Looking back... this has probably been
> the cause of around half of all the troubleshooting I've helped folks with.
> I think it'd really help the first-run experience for folks if the release
> plugin prompted users for their authentication credentials when they're
> needed: if they're missing in the {{settings.xml}} and if authentication
> failures are encountered. (Only when running interactively, of course.)
> I imagine a lot of other folks' experience here might mirror mine, especially
> in Windows domain environments with obnoxious password expiration policies.
> Even if passwords aren't expiring, though, it seems like I'm setting up a
> development environment on a new machine for myself or someone else about
> once a month. And the {{settings.xml}} authentication credentials are an
> oft-overlooked step.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-890) Prompt for usernames and passwords when running interactively
[
https://jira.codehaus.org/browse/MRELEASE-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353285#comment-353285
]
Karl M. Davis commented on MRELEASE-890:
Robert: I agree, auth is definitely not always required. But the interactive
prompts could cope with that case as well, e.g. "Hit ENTER for anonymous
logins."
> Prompt for usernames and passwords when running interactively
> -
>
> Key: MRELEASE-890
> URL: https://jira.codehaus.org/browse/MRELEASE-890
> Project: Maven Release Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.1
>Reporter: Karl M. Davis
>Priority: Critical
>
> I've been using the release plugin for years now, and also supporting a lot
> of other folks using it.
> It occurred to me today, that one of the most common sources of frustration
> and problems with the release plugin has been authentication: either users
> never added {{}} entries to their {{settings.xml}} or their password
> expired and they forgot to update it. Looking back... this has probably been
> the cause of around half of all the troubleshooting I've helped folks with.
> I think it'd really help the first-run experience for folks if the release
> plugin prompted users for their authentication credentials when they're
> needed: if they're missing in the {{settings.xml}} and if authentication
> failures are encountered. (Only when running interactively, of course.)
> I imagine a lot of other folks' experience here might mirror mine, especially
> in Windows domain environments with obnoxious password expiration policies.
> Even if passwords aren't expiring, though, it seems like I'm setting up a
> development environment on a new machine for myself or someone else about
> once a month. And the {{settings.xml}} authentication credentials are an
> oft-overlooked step.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-890) Prompt for usernames and passwords when running interactively
[
https://jira.codehaus.org/browse/MRELEASE-890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl M. Davis updated MRELEASE-890:
---
Description:
I've been using the release plugin for years now, and also supporting a lot of
other folks using it.
It occurred to me today, that one of the most common sources of frustration and
problems with the release plugin has been authentication: either users never
added {{}} entries to their {{settings.xml}} or their password expired
and they forgot to update it. Looking back... this has probably been the cause
of around half of all the troubleshooting I've helped folks with.
I think it'd really help the first-run experience for folks if the release
plugin prompted users for their authentication credentials when they're needed:
if they're missing in the {{settings.xml}} and if authentication failures are
encountered. (Only when running interactively, of course.)
I imagine a lot of other folks' experience here might mirror mine, especially
in Windows domain environments with obnoxious password expiration policies.
Even if passwords aren't expiring, though, it seems like I'm setting up a
development environment on a new machine for myself or someone else about once
a month. And the {{settings.xml}} authentication credentials are an
oft-overlooked step.
was:
I've been using the release plugin for years now, and also supporting a lot of
other folks using it.
It occurred to me today, that one of the most common sources of frustration and
problems with the release plugin has been authentication: either users never
added {{}} entries to their {{settings.xml}} or their passwords
expired and they forgot to update it. Looking back... this ha probably been the
cause of around half of all the troubleshooting I've helped folks with.
I think it'd really help the first-run experience for folks if the release
plugin prompted users for their authentication credentials when they're needed:
if they're missing in the {{settings.xml}} and if authentication failures are
encountered. (Only when running interactively, of course.)
I imagine a lot of other folks' experience here might mirror mine, especially
in Windows domain environments with obnoxious password expiration policies.
Even if passwords aren't expiring, though, it seems like I'm setting up a
development environment on a new machine for myself or someone else about once
a month. And the {{settings.xml}} authentication credentials are an
oft-overlooked step.
> Prompt for usernames and passwords when running interactively
> -
>
> Key: MRELEASE-890
> URL: https://jira.codehaus.org/browse/MRELEASE-890
> Project: Maven Release Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.1
>Reporter: Karl M. Davis
>Priority: Critical
>
> I've been using the release plugin for years now, and also supporting a lot
> of other folks using it.
> It occurred to me today, that one of the most common sources of frustration
> and problems with the release plugin has been authentication: either users
> never added {{}} entries to their {{settings.xml}} or their password
> expired and they forgot to update it. Looking back... this has probably been
> the cause of around half of all the troubleshooting I've helped folks with.
> I think it'd really help the first-run experience for folks if the release
> plugin prompted users for their authentication credentials when they're
> needed: if they're missing in the {{settings.xml}} and if authentication
> failures are encountered. (Only when running interactively, of course.)
> I imagine a lot of other folks' experience here might mirror mine, especially
> in Windows domain environments with obnoxious password expiration policies.
> Even if passwords aren't expiring, though, it seems like I'm setting up a
> development environment on a new machine for myself or someone else about
> once a month. And the {{settings.xml}} authentication credentials are an
> oft-overlooked step.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-890) Prompt for usernames and passwords when running interactively
Karl M. Davis created MRELEASE-890:
--
Summary: Prompt for usernames and passwords when running
interactively
Key: MRELEASE-890
URL: https://jira.codehaus.org/browse/MRELEASE-890
Project: Maven Release Plugin
Issue Type: Improvement
Affects Versions: 2.5.1
Reporter: Karl M. Davis
Priority: Critical
I've been using the release plugin for years now, and also supporting a lot of
other folks using it.
It occurred to me today, that one of the most common sources of frustration and
problems with the release plugin has been authentication: either users never
added {{}} entries to their {{settings.xml}} or their passwords
expired and they forgot to update it. Looking back... this ha probably been the
cause of around half of all the troubleshooting I've helped folks with.
I think it'd really help the first-run experience for folks if the release
plugin prompted users for their authentication credentials when they're needed:
if they're missing in the {{settings.xml}} and if authentication failures are
encountered. (Only when running interactively, of course.)
I imagine a lot of other folks' experience here might mirror mine, especially
in Windows domain environments with obnoxious password expiration policies.
Even if passwords aren't expiring, though, it seems like I'm setting up a
development environment on a new machine for myself or someone else about once
a month. And the {{settings.xml}} authentication credentials are an
oft-overlooked step.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5434) Maven version ranges do not properly handle versions with more than four components
[
https://jira.codehaus.org/browse/MNG-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=333153#comment-333153
]
Karl M. Davis commented on MNG-5434:
I'd recommend that the "Default Version comparison definition" section on
[Dependency Mediation and Conflict
Resolution|http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges]
be updated to account for the current behavior:
* more than the "standard" four version components are supported
* {{1 > 1.0}}
> Maven version ranges do not properly handle versions with more than four
> components
> ---
>
> Key: MNG-5434
> URL: https://jira.codehaus.org/browse/MNG-5434
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: General
>Affects Versions: 3.0.4
> Environment: Linux 64-bit
>Reporter: Karl M. Davis
> Fix For: 3.0.4
>
>
> When using a version range, e.g. "[1.0-SNAPSHOT,)", versions with more than
> four components are not sorted correctly. For example, "1.0.0.0" will be
> sorted as greater/later than "1.0.0.0.0". However, "1.0.0" will be sorted as
> greater/later than "1.0.0.0".
> The behavior here is a bit odd... all of the maven-metadata-XXX.xml files in
> the local repository will correctly list "1.0.0.0.0" as the "latest" and
> "release" version, but running compile, dependency:tree, etc. will instead
> select "1.0.0.0". Aether API calls are also exhibiting the buggy sorting
> behavior, too.
> I haven't yet tried any debugging to track this down, but I've trolled
> through git and my best guess is that this behavior is related to the version
> of maven-artifact being used. The 2.x releases
> DefaultArtifactVersion.compareTo(...) method does not correctly handle
> versions with more than four components, but the 3.x releases of it do [1].
> Maybe the problem is just that [the compile plugin is still using
> maven-artifact:2.0.9|http://maven.apache.org/plugins/maven-compiler-plugin/dependencies.html]?
> This is hurting us here. While many of our projects use versions with four or
> less components, we follow the [add a version component for branches
> versioning
> strategy|http://janvanbesien.blogspot.com/2009/06/consistent-svn-brach-and-tag-names-for.html]
> to prevent version conflicts between branches. This allows us to use version
> ranges in our POMs, making life a lot easier.
> [1] The following commit seems to be where this was fixed in maven-artifact:
> [maven.git
> beb9d731691beed1b0099a790a8ae1973f55dc0b|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=beb9d731691beed1b0099a790a8ae1973f55dc0b].
> It looks like the code is what was originally proposed in the [Improve
> default support for version
> schemes|http://docs.codehaus.org/display/MAVEN/Versioning] Maven wiki page.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5434) Maven version ranges do not properly handle versions with more than four components
[ https://jira.codehaus.org/browse/MNG-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl M. Davis closed MNG-5434. -- Resolution: Not A Bug Fix Version/s: 3.0.4 As mentioned in my previous comment, I'd just chosen a poor example for my original tests. The behavior is a bit surprising, but not a bug. > Maven version ranges do not properly handle versions with more than four > components > --- > > Key: MNG-5434 > URL: https://jira.codehaus.org/browse/MNG-5434 > Project: Maven 2 & 3 > Issue Type: Bug > Components: General >Affects Versions: 3.0.4 > Environment: Linux 64-bit >Reporter: Karl M. Davis > Fix For: 3.0.4 > > > When using a version range, e.g. "[1.0-SNAPSHOT,)", versions with more than > four components are not sorted correctly. For example, "1.0.0.0" will be > sorted as greater/later than "1.0.0.0.0". However, "1.0.0" will be sorted as > greater/later than "1.0.0.0". > The behavior here is a bit odd... all of the maven-metadata-XXX.xml files in > the local repository will correctly list "1.0.0.0.0" as the "latest" and > "release" version, but running compile, dependency:tree, etc. will instead > select "1.0.0.0". Aether API calls are also exhibiting the buggy sorting > behavior, too. > I haven't yet tried any debugging to track this down, but I've trolled > through git and my best guess is that this behavior is related to the version > of maven-artifact being used. The 2.x releases > DefaultArtifactVersion.compareTo(...) method does not correctly handle > versions with more than four components, but the 3.x releases of it do [1]. > Maybe the problem is just that [the compile plugin is still using > maven-artifact:2.0.9|http://maven.apache.org/plugins/maven-compiler-plugin/dependencies.html]? > This is hurting us here. While many of our projects use versions with four or > less components, we follow the [add a version component for branches > versioning > strategy|http://janvanbesien.blogspot.com/2009/06/consistent-svn-brach-and-tag-names-for.html] > to prevent version conflicts between branches. This allows us to use version > ranges in our POMs, making life a lot easier. > [1] The following commit seems to be where this was fixed in maven-artifact: > [maven.git > beb9d731691beed1b0099a790a8ae1973f55dc0b|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=beb9d731691beed1b0099a790a8ae1973f55dc0b]. > It looks like the code is what was originally proposed in the [Improve > default support for version > schemes|http://docs.codehaus.org/display/MAVEN/Versioning] Maven wiki page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5434) Maven version ranges do not properly handle versions with more than four components
[
https://jira.codehaus.org/browse/MNG-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=333151#comment-333151
]
Karl M. Davis commented on MNG-5434:
I finally had some time to look at this some more, and it appears that I'd just
chosen a poor version to test against. Here's a summary of my test results:
||Version A||Version B||Latest (Numerically)||Latest
(Lexicographically)||Latest (Maven 3.0.4)||
|1.0.0.0|1.0.0.0.0|(ambiguous)|1.0.0.0.0|1.0.0.0|
|1.0.0|1.0.0.0|(ambiguous)|1.0.0.0|1.0.0|
|1.0.0.100-SNAPSHOT|1.0.0.2-SNAPSHOT|1.0.0.100-SNAPSHOT|1.0.0.100-SNAPSHOT|1.0.0.100-SNAPSHOT|
|2|2.0|(ambiguous)|2.0|2|
|3.4.5.6.7.008|3.4.5.6.7.08|(ambiguous)|3.4.5.6.7.008|3.4.5.6.7.008|
|5.6.7.8-fix1.2|5.6.7.8-fix002|5.6.7.8-fix002|5.6.7.8-fix1.2|5.6.7.8-fix002|
|4.5.6.7.8.9.1|4.5.6.7.8.10|4.5.6.7.8.10|4.5.6.7.8.9.1|4.5.6.7.8.10|
Maven's behavior is as expected in all non-ambiguous cases that I tried. I
would say that the {{1 > 1.0}} logic is surprising, but nonetheless reasonable.
> Maven version ranges do not properly handle versions with more than four
> components
> ---
>
> Key: MNG-5434
> URL: https://jira.codehaus.org/browse/MNG-5434
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: General
>Affects Versions: 3.0.4
> Environment: Linux 64-bit
>Reporter: Karl M. Davis
>
> When using a version range, e.g. "[1.0-SNAPSHOT,)", versions with more than
> four components are not sorted correctly. For example, "1.0.0.0" will be
> sorted as greater/later than "1.0.0.0.0". However, "1.0.0" will be sorted as
> greater/later than "1.0.0.0".
> The behavior here is a bit odd... all of the maven-metadata-XXX.xml files in
> the local repository will correctly list "1.0.0.0.0" as the "latest" and
> "release" version, but running compile, dependency:tree, etc. will instead
> select "1.0.0.0". Aether API calls are also exhibiting the buggy sorting
> behavior, too.
> I haven't yet tried any debugging to track this down, but I've trolled
> through git and my best guess is that this behavior is related to the version
> of maven-artifact being used. The 2.x releases
> DefaultArtifactVersion.compareTo(...) method does not correctly handle
> versions with more than four components, but the 3.x releases of it do [1].
> Maybe the problem is just that [the compile plugin is still using
> maven-artifact:2.0.9|http://maven.apache.org/plugins/maven-compiler-plugin/dependencies.html]?
> This is hurting us here. While many of our projects use versions with four or
> less components, we follow the [add a version component for branches
> versioning
> strategy|http://janvanbesien.blogspot.com/2009/06/consistent-svn-brach-and-tag-names-for.html]
> to prevent version conflicts between branches. This allows us to use version
> ranges in our POMs, making life a lot easier.
> [1] The following commit seems to be where this was fixed in maven-artifact:
> [maven.git
> beb9d731691beed1b0099a790a8ae1973f55dc0b|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=beb9d731691beed1b0099a790a8ae1973f55dc0b].
> It looks like the code is what was originally proposed in the [Improve
> default support for version
> schemes|http://docs.codehaus.org/display/MAVEN/Versioning] Maven wiki page.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5434) Maven version ranges do not properly handle versions with more than four components
[ https://jira.codehaus.org/browse/MNG-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319656#comment-319656 ] Karl M. Davis commented on MNG-5434: Actually, I was incorrect about Aether: API calls are sorting artifact versions correctly. For example, org.sonatype.aether.RepositorySystem.resolveVersionRange(RepositorySystemSession, VersionRangeRequest) is working as expected. > Maven version ranges do not properly handle versions with more than four > components > --- > > Key: MNG-5434 > URL: https://jira.codehaus.org/browse/MNG-5434 > Project: Maven 2 & 3 > Issue Type: Bug > Components: General >Affects Versions: 3.0.4 > Environment: Linux 64-bit >Reporter: Karl M. Davis > > When using a version range, e.g. "[1.0-SNAPSHOT,)", versions with more than > four components are not sorted correctly. For example, "1.0.0.0" will be > sorted as greater/later than "1.0.0.0.0". However, "1.0.0" will be sorted as > greater/later than "1.0.0.0". > The behavior here is a bit odd... all of the maven-metadata-XXX.xml files in > the local repository will correctly list "1.0.0.0.0" as the "latest" and > "release" version, but running compile, dependency:tree, etc. will instead > select "1.0.0.0". Aether API calls are also exhibiting the buggy sorting > behavior, too. > I haven't yet tried any debugging to track this down, but I've trolled > through git and my best guess is that this behavior is related to the version > of maven-artifact being used. The 2.x releases > DefaultArtifactVersion.compareTo(...) method does not correctly handle > versions with more than four components, but the 3.x releases of it do [1]. > Maybe the problem is just that [the compile plugin is still using > maven-artifact:2.0.9|http://maven.apache.org/plugins/maven-compiler-plugin/dependencies.html]? > This is hurting us here. While many of our projects use versions with four or > less components, we follow the [add a version component for branches > versioning > strategy|http://janvanbesien.blogspot.com/2009/06/consistent-svn-brach-and-tag-names-for.html] > to prevent version conflicts between branches. This allows us to use version > ranges in our POMs, making life a lot easier. > [1] The following commit seems to be where this was fixed in maven-artifact: > [maven.git > beb9d731691beed1b0099a790a8ae1973f55dc0b|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=beb9d731691beed1b0099a790a8ae1973f55dc0b]. > It looks like the code is what was originally proposed in the [Improve > default support for version > schemes|http://docs.codehaus.org/display/MAVEN/Versioning] Maven wiki page. -- 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] (MNG-5434) Maven version ranges do not properly handle versions with more than four components
Karl M. Davis created MNG-5434: -- Summary: Maven version ranges do not properly handle versions with more than four components Key: MNG-5434 URL: https://jira.codehaus.org/browse/MNG-5434 Project: Maven 2 & 3 Issue Type: Bug Components: General Affects Versions: 3.0.4 Environment: Linux 64-bit Reporter: Karl M. Davis When using a version range, e.g. "[1.0-SNAPSHOT,)", versions with more than four components are not sorted correctly. For example, "1.0.0.0" will be sorted as greater/later than "1.0.0.0.0". However, "1.0.0" will be sorted as greater/later than "1.0.0.0". The behavior here is a bit odd... all of the maven-metadata-XXX.xml files in the local repository will correctly list "1.0.0.0.0" as the "latest" and "release" version, but running compile, dependency:tree, etc. will instead select "1.0.0.0". Aether API calls are also exhibiting the buggy sorting behavior, too. I haven't yet tried any debugging to track this down, but I've trolled through git and my best guess is that this behavior is related to the version of maven-artifact being used. The 2.x releases DefaultArtifactVersion.compareTo(...) method does not correctly handle versions with more than four components, but the 3.x releases of it do [1]. Maybe the problem is just that [the compile plugin is still using maven-artifact:2.0.9|http://maven.apache.org/plugins/maven-compiler-plugin/dependencies.html]? This is hurting us here. While many of our projects use versions with four or less components, we follow the [add a version component for branches versioning strategy|http://janvanbesien.blogspot.com/2009/06/consistent-svn-brach-and-tag-names-for.html] to prevent version conflicts between branches. This allows us to use version ranges in our POMs, making life a lot easier. [1] The following commit seems to be where this was fixed in maven-artifact: [maven.git beb9d731691beed1b0099a790a8ae1973f55dc0b|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=beb9d731691beed1b0099a790a8ae1973f55dc0b]. It looks like the code is what was originally proposed in the [Improve default support for version schemes|http://docs.codehaus.org/display/MAVEN/Versioning] Maven wiki page. -- 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] (MNG-1378) Make dependencies of test-jars transitive
[ https://jira.codehaus.org/browse/MNG-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311914#comment-311914 ] Karl M. Davis commented on MNG-1378: For those still waiting on this, I recommend adopting the OSGi approach: separate test-only modules/projects. It's adds noise to the project structure, but is a cleaner separation. It has the added advantage of de-cluttering your project POMs and working around this issue. > Make dependencies of test-jars transitive > - > > Key: MNG-1378 > URL: https://jira.codehaus.org/browse/MNG-1378 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0 >Reporter: Mark Hobson > Fix For: Issues to be reviewed for 3.x > > Attachments: mng1378.tar.gz > > > test-jar transitive dependencies are calculated as per compile scope rather > than test scope. > The situation is demonstrated nicely in it0077: > * module sub1 has a test-scoped dependency of commons-lang > * module sub2 has a test-scoped dependency of sub1 test-jar > sub2 tests should inherit the commons-lang transitive dependency. For > example: > Index: > maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java > === > --- > maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java > (revision > 328307) > +++ > maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java > (working > copy) > @@ -1,6 +1,7 @@ > package org.apache.maven.it0077; > import junit.framework.TestCase; > +import org.apache.commons.lang.BooleanUtils; > public class PersonTwoTest > extends PersonTest > Results in: > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > c:\maven-components\maven-core-it\it0077\sub2\src\test\java\org\apache\maven\it0077\PersonTwoTest.java:[4,31] > package org.apache.commons.lang does not exist -- 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-542) JUnit 4.4 tests skipped for a failed assumption are not reported as "Skipped"
[
https://jira.codehaus.org/browse/SUREFIRE-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293596#comment-293596
]
Karl M. Davis commented on SUREFIRE-542:
Please note that, in order for JUnit assumptions to work as intended, your
tests must be JUnit 4-style, e.g. not extend from {{TestCase}} and instead use
{{@Test}} annotations. This is obvious in retrospect, but I just blew an hour
or so figuring it out. Hope it saves someone else time.
> JUnit 4.4 tests skipped for a failed assumption are not reported as "Skipped"
> -
>
> Key: SUREFIRE-542
> URL: https://jira.codehaus.org/browse/SUREFIRE-542
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.4.3
> Environment: 64 bit Ubuntu 8.10, OpenJDK 6
>Reporter: Karl M. Davis
>Assignee: Kristian Rosenvold
>Priority: Minor
> Fix For: 2.7.2
>
> Attachments: SUREFIRE-542.patch
>
>
> Junit 4.4 has support for ignoring tests at runtime via code like the
> following:
> {{Assume.assumeTrue(testsShouldBeRun());}}
> When running tests under Surefire that fail their assumptions, the tests are
> reported as successful-- not ignored as they ought to be. The javadoc for
> the Assume class is here: [http://junit.org/apidocs/org/junit/Assume.html].
--
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] (MSITE-596) inheritedReports IT fails
[ https://jira.codehaus.org/browse/MSITE-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=292705#comment-292705 ] Karl M. Davis commented on MSITE-596: - Please note that some folks (me, for example) are now relying on the Maven 3 behavior to exclude reports in child projects. If you change this behavior, a number of my projects would break as I need a way to exclude reports occasionally. > inheritedReports IT fails > - > > Key: MSITE-596 > URL: https://jira.codehaus.org/browse/MSITE-596 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: inheritance, Maven 3 >Affects Versions: 3.0-beta-3 >Reporter: Herve Boutemy > Fix For: 3.1 > > > as discovered in MSITE-595: > - with M2, each report is added: child has 2 reports generated = index+summary > - with M3, each report replaces previous one: child has 1 report = summary > What is the expected behaviour? I'd say M2 is buggy, since POM inheritance > logic usually replaces instead adding > Should we try to stick with M2 behaviour? (if feasible, I still didn't check) -- 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: (MRELEASE-717) Releases from HG fail if project is not in root of repository
Releases from HG fail if project is not in root of repository
-
Key: MRELEASE-717
URL: https://jira.codehaus.org/browse/MRELEASE-717
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.2.1, 2.1
Environment: Windows 7, Java 6, HG 1.9.3
Reporter: Karl M. Davis
Priority: Critical
Given the following HG respo structure, trying to release {{mavenProjectC}}
fails:
{noformat}
repoA/
stuffA/
stuffB/
mavenProjectC/
{noformat}
Specifically, I receive the following error when trying to run
{{release:prepare}}:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.2.1:prepare (default-cli) on
project mavenProjectC: Unable to commit files
[ERROR] Provider message:
[ERROR]
[ERROR] EXECUTION FAILED
[ERROR] Execution of cmd : push failed with exit code: -1.
[ERROR] Working directory was:
[ERROR] C:\workspaces\repoA\mavenProjectC
[ERROR] Your Hg installation seems to be valid and complete.
[ERROR] Hg version: 1.9.3 (OK)
{noformat}
I believe this is the same issue reported by Lee Thompson in [his 2011-07-12
comment|http://jira.codehaus.org/browse/MRELEASE-457?focusedCommentId=270210&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-270210]
on MRELEASE-457. It seems there is currently no way to inform the release
plugin that it's operating in a repository subdirectory.
Lee recommended a {{pomSubDirectory}} parameter be added to the relevant goals,
which I also think will be necessary to solve this issue. I would recommend
instead naming it {{repoRelativePath}}, though.
There's also the issue of what paths should be included in the POM's {{}}
section, as well. Currently, I'm listing something similar to the following:
{noformat}
scm:hg:http://myserver/repoA/mavenProjectC
{noformat}
It's unclear if this is the "correct" way to list it, as opposed to truncating
it to only the repository's path itself.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-356) deprecate the automated release profile
[ https://jira.codehaus.org/browse/MRELEASE-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282454#comment-282454 ] Karl M. Davis commented on MRELEASE-356: Stephen: I hadn't heard that it's back in 3.0. Do you know of any documentation I can read regarding this? > deprecate the automated release profile > --- > > Key: MRELEASE-356 > URL: https://jira.codehaus.org/browse/MRELEASE-356 > Project: Maven 2.x Release Plugin > Issue Type: Task > Components: perform >Reporter: Brett Porter > Fix For: 2.3 > > > the release profile is being removed from the super POM in Maven 2.1-alpha-1, > so the release plugin should pre-emptively start ensuring users do this > themselves -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-632) Faulty svn commandline is generated for passwords containing redirection characters
Faulty svn commandline is generated for passwords containing redirection
characters
---
Key: SCM-632
URL: https://jira.codehaus.org/browse/SCM-632
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-svn
Affects Versions: 1.3
Environment: Windows Server 2008 R2, Java 6 JDK, Maven 2.2.1
Reporter: Karl M. Davis
Similar to SCM-334, I'm getting errors attempting to run a release using a
password that contains DOS redirection characters-- a pipe character, in my
case, though I suspect angle brackets would cause similar problems. For the
time being, the only workarounds seem to be either manually escaping the
password in my settings.xml (which may cause problems elsewhere) or changing
the password to not include a pipe (which would be a giant hassle).
At the start of the Maven debug log I see:
{code}
[DEBUG] Plugin dependencies for:
org.apache.maven.plugins:maven-release-plugin:2.0
are:
...
org.apache.maven.scm:maven-scm-api:jar:1.3:runtime
...
{code}
At the end of the debug log I get the following error (edited to obfuscate
username and half a password):
{code}
[INFO] Verifying that there are no local modifications...
[INFO] Executing: cmd.exe /X /C "svn --username MyUsername --password *
--non-interactive status"
[INFO] Working directory:
J:\DevTools\hudson\jobs\lookups-app-releaseUpdates\workspace\releaseUpdates-3.4
[HUDSON] Archiving
J:\DevTools\hudson\jobs\lookups-app-releaseUpdates\workspace\releaseUpdates-3.4\pom.xml
to
J:\DevTools\hudson\jobs\lookups-app-releaseUpdates\modules\com.knowledgecc.coplink$lookups-app-parent\builds\2011-09-09_16-35-44\archive\com.knowledgecc.coplink\lookups-app-parent\3.4.76-SNAPSHOT\pom.xml
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to check for local modifications
Provider message:
The svn command failed.
Command output:
'halfpass' is not recognized as an internal or external command,
operable program or batch file.
[INFO]
[DEBUG] Trace
org.apache.maven.BuildFailureException: Unable to check for local modifications
Provider message:
The svn command failed.
Command output:
'halfpass' is not recognized as an internal or external command,
operable program or batch file.
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at
org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at hudson.maven.agent.Main.launch(Main.java:173)
at hudson.maven.MavenBuilder.call(MavenBuilder.java:164)
at
hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:868)
at
hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:799)
at hudson.remoting.UserRequest.perform(UserRequest.java:114)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:270)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thre
[jira] Commented: (MNG-5110) Support ${project.baseUri} in resource filtering
[
http://jira.codehaus.org/browse/MNG-5110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269330#action_269330
]
Karl M. Davis commented on MNG-5110:
This can be worked around by adding a property to the POM whose value is set
using this property, e.g.:
{code:title=pom.xml}
${project.baseUri}
{code}
With that in place, $\{myProperty\} can be used in resources, like this:
{code:title=myResource.properties}
# Uses the ${myProperty} property in lieu of ${project.baseUri}, which is broken
myKey=${myProperty}
{code}
> Support ${project.baseUri} in resource filtering
>
>
> Key: MNG-5110
> URL: http://jira.codehaus.org/browse/MNG-5110
> Project: Maven 2 & 3
> Issue Type: Sub-task
>Affects Versions: 3.0.3
> Environment: Windows 7, 32-bit Java 6 JRE (Oracle)
>Reporter: Karl M. Davis
>
> Though the {{${project.baseUri}}} property does work in POMs, it does not
> appear to be working for resource filtering.
--
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: (MNG-5110) Support ${project.baseUri} in resource filtering
Support ${project.baseUri} in resource filtering
Key: MNG-5110
URL: http://jira.codehaus.org/browse/MNG-5110
Project: Maven 2 & 3
Issue Type: Sub-task
Affects Versions: 3.0.3
Environment: Windows 7, 32-bit Java 6 JRE (Oracle)
Reporter: Karl M. Davis
Though the {{${project.baseUri}}} property does work in POMs, it does not
appear to be working for resource filtering.
--
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: (MPIR-181) Dependency reporting plugin overwrites other project's artifact file
[
http://jira.codehaus.org/browse/MPIR-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=240994#action_240994
]
Karl M. Davis commented on MPIR-181:
For what it's worth, that code has changed some now and has some other
problems. Here's the new code (taken from the [Source
Xref|http://maven.apache.org/plugins/maven-project-info-reports-plugin/xref/org/apache/maven/report/projectinfo/dependencies/Dependencies.html#302]):
{noformat}
302 private void mapArtifactFiles( DependencyNode node, Map projectMap )
303 {
304 List childs = node.getChildren();
305 if ( ( childs == null ) || childs.isEmpty() )
306 {
307 return;
308 }
309
310 Iterator it = childs.iterator();
311 while ( it.hasNext() )
312 {
313 DependencyNode anode = (DependencyNode) it.next();
314 String key = ArtifactUtils.versionlessKey( anode.getArtifact()
);
315 Artifact projartifact = (Artifact) projectMap.get( key );
316 if ( projartifact != null )
317 {
318 anode = new DependencyNode( ArtifactUtils.copyArtifact(
projartifact ) );
319 anode.getArtifact().setFile( projartifact.getFile() );
320 }
321
322 mapArtifactFiles( anode, projectMap );
323 }
324 }
{noformat}
Line 318 appears to have been added to address this bug. However, this is just
a local reassignment and leaves the "real" {{anode}} in the dependency tree
as-is. Because of this, the "real" node in the tree never gets its file set.
This floods the log with errors as follows:
{noformat}
[ERROR] Artifact: foo:bar:1.0 has no file.
{noformat}
Furthermore, the local reassignment doesn't bring along the "real" node's
children, which prevents this code from properly recursing through the tree.
(I noticed these problems while trying to track down the cause of those log
errors on one of my builds. If you ever run {{site:site}} with {{-X}}, the
amount of these that get generated is crazy.)
> Dependency reporting plugin overwrites other project's artifact file
>
>
> Key: MPIR-181
> URL: http://jira.codehaus.org/browse/MPIR-181
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
> Environment: Linux
>Reporter: blaabloo
>
> Projectmap is map of artifacts with groupid:artifactid being the key. When
> project has multiple artifacts only one of them is put to the map. Dependency
> node contains information about artifact and file information is the same
> reference as used DefaultLifecycleExecutor. Every dependency's file is set
> from this map and when building multimodule projects the latter projects may
> fail because project's default artifact file is set to one of its attached
> artifacts.
> In org.apache.maven.report.projectinfo.dependencies.Dependencies
> private void mapArtifactFiles( DependencyNode node, Map projectMap )
> {
> List childs = node.getChildren();
> if ( ( childs == null ) || childs.isEmpty() )
> {
> return;
> }
> Iterator it = childs.iterator();
> while ( it.hasNext() )
> {
> DependencyNode anode = (DependencyNode) it.next();
> String key = ArtifactUtils.versionlessKey( anode.getArtifact() );
> Artifact projartifact = (Artifact) projectMap.get( key );
> if ( projartifact != null )
> {
> anode.getArtifact().setFile( projartifact.getFile() );
> }
> mapArtifactFiles( anode, projectMap );
> }
> }
--
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] Updated: (MNG-4872) Dependency exclusions not always honored for dependencies with classifier
[
http://jira.codehaus.org/browse/MNG-4872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl M. Davis updated MNG-4872:
---
Attachment: 2010-10-24-1715-fix-to-maven-project-for-MNG4872.patch
This is a patch for the reported issue. This patch is against the root of
{{maven-project}} in the 2.2.1 tag. If you guys end up doing another 2.2.1
release, I'd greatly appreciate it if you could include these fixes.
Please note that once I'd fixed the lines of code mentioned in the description,
I ran into problems with other methods that made similar assumptions. A lot of
the code in {{maven-project}} neglects to account for anything other than the
project's "main" artifact. I fixed those places that I could find (the ones
that caused my build to go boom) but there are likely others still left.
> Dependency exclusions not always honored for dependencies with classifier
> -
>
> Key: MNG-4872
> URL: http://jira.codehaus.org/browse/MNG-4872
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.2.1
> Environment: Windows 7 64bit, Java 1.6 32bit
>Reporter: Karl M. Davis
>Assignee: Benjamin Bentmann
>Priority: Blocker
> Fix For: 3.0-beta-1
>
> Attachments: 2010-10-24-1715-fix-to-maven-project-for-MNG4872.patch,
> myproj.zip
>
>
> Like the summary says, I've encountered and tracked down a bug that prevents
> dependency exclusions from being honored by plugins when the dependency with
> the exclusions has a classifier. This seems to only occur or surface in
> multi-module builds.
> For example, I have a multi-module project structured as follows:
> {noformat}
> myproj-parent
> myproj-a
> myproj-b
> {noformat}
> If {{myproj-a}} produces a classified artifact (say, an obfuscated JAR via
> ProGuard) and {{myproj-b}} has it as a dependency with exclusions, those
> exclusions will not be honored by plugins run in {{myproj-b}} (say, the
> webstart plugin).
> I think I've tracked the problem down to the
> {{replaceWithActiveArtifact(...)}} method of
> {{org.apache.maven.project.MavenProject}}. Specifically, see [lines 1772
> through
> 1784|http://maven.apache.org/ref/2.2.1/xref/org/apache/maven/project/MavenProject.html#1772].
> The following {{if}} clause does not account for artifacts with classifiers:
> {noformat}
> if ( ref.getArtifact() != null
> && ref.getArtifact().getDependencyConflictId().equals(
> pluginArtifact.getDependencyConflictId() ) )
> {noformat}
> Because the classified {{pluginArtifact}} does not match the _main_ artifact
> of {{ref}}, the artifact is not resolved from the currently building
> project's dependencies. As the method continues, it is instead resolved with
> {{myproj-a}}'s "standard" metadata, which of course don't include the
> exclusions in {{myproj-b}}.
> I've marked this bug a blocker because I can't think of a way around it and
> it's badly polluting one of my project's builds. Due to it, a webstart build
> that only needs 30 artifacts has over 100. I have not yet tried to reproduce
> it in Maven 3.x because our company likely won't be moving to it for a couple
> of months.
--
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: (MRELEASE-611) The update-versions goal fails when project is not at a SNAPSHOT version
The update-versions goal fails when project is not at a SNAPSHOT version
Key: MRELEASE-611
URL: http://jira.codehaus.org/browse/MRELEASE-611
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Karl M. Davis
Priority: Minor
Trying to use the {{update-versions}} goal fails if the project is not at a
{{SNAPSHOT}} version. This is a little silly, as one of the reasons for using
this goal is to fix that exact problem.
It currently fails with:
{noformat}
[INFO] [release:update-versions {execution: default-cli}]
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] You don't have a SNAPSHOT project in the reactor projects list.
[INFO]
{noformat}
--
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: (MNG-4872) Dependency exclusions not always honored for dependencies with classifier
[
http://jira.codehaus.org/browse/MNG-4872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=240640#action_240640
]
Karl M. Davis edited comment on MNG-4872 at 10/22/10 11:38 AM:
---
Sorry, had planned to but needed sleep last night. Here you are. Just run {{mvn
clean package}} on the root {{myproj}} and then take a look in
{{myproj/myproj-b/target/myproj-b-0.0.1-SNAPSHOT.zip}}. You'll notice that the
supposed-to-be-excluded log4j library is in there. If you comment out the
classifier in {{myproj-b}}'s dependency and re-build, the exclusion works as
expected.
was (Author: karlmdavis):
Sorry, had planned to but needed sleep last night. Here you are.
> Dependency exclusions not always honored for dependencies with classifier
> -
>
> Key: MNG-4872
> URL: http://jira.codehaus.org/browse/MNG-4872
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.2.1
> Environment: Windows 7 64bit, Java 1.6 32bit
>Reporter: Karl M. Davis
>Priority: Blocker
> Attachments: myproj.zip
>
>
> Like the summary says, I've encountered and tracked down a bug that prevents
> dependency exclusions from being honored by plugins when the dependency with
> the exclusions has a classifier. This seems to only occur or surface in
> multi-module builds.
> For example, I have a multi-module project structured as follows:
> {noformat}
> myproj-parent
> myproj-a
> myproj-b
> {noformat}
> If {{myproj-a}} produces a classified artifact (say, an obfuscated JAR via
> ProGuard) and {{myproj-b}} has it as a dependency with exclusions, those
> exclusions will not be honored by plugins run in {{myproj-b}} (say, the
> webstart plugin).
> I think I've tracked the problem down to the
> {{replaceWithActiveArtifact(...)}} method of
> {{org.apache.maven.project.MavenProject}}. Specifically, see [lines 1772
> through
> 1784|http://maven.apache.org/ref/2.2.1/xref/org/apache/maven/project/MavenProject.html#1772].
> The following {{if}} clause does not account for artifacts with classifiers:
> {noformat}
> if ( ref.getArtifact() != null
> && ref.getArtifact().getDependencyConflictId().equals(
> pluginArtifact.getDependencyConflictId() ) )
> {noformat}
> Because the classified {{pluginArtifact}} does not match the _main_ artifact
> of {{ref}}, the artifact is not resolved from the currently building
> project's dependencies. As the method continues, it is instead resolved with
> {{myproj-a}}'s "standard" metadata, which of course don't include the
> exclusions in {{myproj-b}}.
> I've marked this bug a blocker because I can't think of a way around it and
> it's badly polluting one of my project's builds. Due to it, a webstart build
> that only needs 30 artifacts has over 100. I have not yet tried to reproduce
> it in Maven 3.x because our company likely won't be moving to it for a couple
> of months.
--
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] Updated: (MNG-4872) Dependency exclusions not always honored for dependencies with classifier
[
http://jira.codehaus.org/browse/MNG-4872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl M. Davis updated MNG-4872:
---
Attachment: myproj.zip
Sorry, had planned to but needed sleep last night. Here you are.
> Dependency exclusions not always honored for dependencies with classifier
> -
>
> Key: MNG-4872
> URL: http://jira.codehaus.org/browse/MNG-4872
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.2.1
> Environment: Windows 7 64bit, Java 1.6 32bit
>Reporter: Karl M. Davis
>Priority: Blocker
> Attachments: myproj.zip
>
>
> Like the summary says, I've encountered and tracked down a bug that prevents
> dependency exclusions from being honored by plugins when the dependency with
> the exclusions has a classifier. This seems to only occur or surface in
> multi-module builds.
> For example, I have a multi-module project structured as follows:
> {noformat}
> myproj-parent
> myproj-a
> myproj-b
> {noformat}
> If {{myproj-a}} produces a classified artifact (say, an obfuscated JAR via
> ProGuard) and {{myproj-b}} has it as a dependency with exclusions, those
> exclusions will not be honored by plugins run in {{myproj-b}} (say, the
> webstart plugin).
> I think I've tracked the problem down to the
> {{replaceWithActiveArtifact(...)}} method of
> {{org.apache.maven.project.MavenProject}}. Specifically, see [lines 1772
> through
> 1784|http://maven.apache.org/ref/2.2.1/xref/org/apache/maven/project/MavenProject.html#1772].
> The following {{if}} clause does not account for artifacts with classifiers:
> {noformat}
> if ( ref.getArtifact() != null
> && ref.getArtifact().getDependencyConflictId().equals(
> pluginArtifact.getDependencyConflictId() ) )
> {noformat}
> Because the classified {{pluginArtifact}} does not match the _main_ artifact
> of {{ref}}, the artifact is not resolved from the currently building
> project's dependencies. As the method continues, it is instead resolved with
> {{myproj-a}}'s "standard" metadata, which of course don't include the
> exclusions in {{myproj-b}}.
> I've marked this bug a blocker because I can't think of a way around it and
> it's badly polluting one of my project's builds. Due to it, a webstart build
> that only needs 30 artifacts has over 100. I have not yet tried to reproduce
> it in Maven 3.x because our company likely won't be moving to it for a couple
> of months.
--
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: (MNG-4872) Dependency exclusions not always honored for dependencies with classifier
Dependency exclusions not always honored for dependencies with classifier
-
Key: MNG-4872
URL: http://jira.codehaus.org/browse/MNG-4872
Project: Maven 2 & 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.2.1
Environment: Windows 7 64bit, Java 1.6 32bit
Reporter: Karl M. Davis
Priority: Blocker
Like the summary says, I've encountered and tracked down a bug that prevents
dependency exclusions from being honored by plugins when the dependency with
the exclusions has a classifier. This seems to only occur or surface in
multi-module builds.
For example, I have a multi-module project structured as follows:
{noformat}
myproj-parent
myproj-a
myproj-b
{noformat}
If {{myproj-a}} produces a classified artifact (say, an obfuscated JAR via
ProGuard) and {{myproj-b}} has it as a dependency with exclusions, those
exclusions will not be honored by plugins run in {{myproj-b}} (say, the
webstart plugin).
I think I've tracked the problem down to the {{replaceWithActiveArtifact(...)}}
method of {{org.apache.maven.project.MavenProject}}. Specifically, see [lines
1772 through
1784|http://maven.apache.org/ref/2.2.1/xref/org/apache/maven/project/MavenProject.html#1772].
The following {{if}} clause does not account for artifacts with classifiers:
{noformat}
if ( ref.getArtifact() != null
&& ref.getArtifact().getDependencyConflictId().equals(
pluginArtifact.getDependencyConflictId() ) )
{noformat}
Because the classified {{pluginArtifact}} does not match the _main_ artifact of
{{ref}}, the artifact is not resolved from the currently building project's
dependencies. As the method continues, it is instead resolved with
{{myproj-a}}'s "standard" metadata, which of course don't include the
exclusions in {{myproj-b}}.
I've marked this bug a blocker because I can't think of a way around it and
it's badly polluting one of my project's builds. Due to it, a webstart build
that only needs 30 artifacts has over 100. I have not yet tried to reproduce it
in Maven 3.x because our company likely won't be moving to it for a couple of
months.
--
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: (MNG-2877) unable to resolve attached artifacts from reactor that are not in repo. (patch applied in svn and IT tests added)
[
http://jira.codehaus.org/browse/MNG-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=227063#action_227063
]
Karl M. Davis commented on MNG-2877:
The problem still seems to exist when running release:prepare in a multi-module
project where one of the modules uses dependency:copy-dependencies for a
secondary artifact of one of the other modules.
For example:
* {{parent-proj}} (running {{release:prepare}} or {{verify}} here will fail)
** {{child-a}}
*** produces a "primary" JAR artifact
*** also produces a "secondary" assembly artifact attached to the build, e.g. a
{{.zip}} of PDF documentation
** {{child-b}}
*** uses {{dependency:unpack-dependencies}} to get the "secondary" assembly
from {{child-a}}
The {{release:prepare}} operation ends up failing when the
{{unpack-dependencies}} goal can't find the secondary artifact of {{child-a}}
in the repository (hasn't been installed yet) or in the reactor (this is the
bug, I think). It fails with the following error:
{{Embedded error: Unable to download the artifact from any repository}}
I would recommend that this bug be re-opened. I am running Maven 2.2.1, using
{{maven-release-plugin:2.0}}, and {{maven-dependency-plugin:2.1}}.
> unable to resolve attached artifacts from reactor that are not in repo.
> (patch applied in svn and IT tests added)
> -
>
> Key: MNG-2877
> URL: http://jira.codehaus.org/browse/MNG-2877
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.0.2, 2.0.3, 2.0.4, 2.0.5
>Reporter: Brian Fox
>Assignee: Jason van Zyl
> Fix For: 2.0.6
>
> Attachments: test-bug-maven-release.zip
>
>
> The patch has been applied here:
> https://svn.apache.org/repos/asf/maven/components/branches/maven-project-mdep64
> and the IT tests are already added to core-it but commented out from the
> suite. To enable it, uncomment this line: //suite.addTestSuite(
> MavenIT0118AttachedArtifactsInReactor.class );
> ---
> This is from MDEP-64:
> We have a project with a few sub-projects. Only one of those subprojects uses
> the maven-dependency-plugin, copying the jar file artifact from one of the
> sibling sub-projects. The dependency plugin has worked fine in another
> multi-project m2 buld and release when the dependency copy was only
> referencing projects outside the multi-project's project tree.
> But in the present multi-project release, copying that sibling jar file with
> the dependency plugin causes the mvn release:prepare step to fail, because it
> can't find the released version in the release repository. It doesn't care
> about referencing sibling project dependencies from the regular pom
> dependencies, it only chokes for the dependency:copy.
> Here's a diagram for the issue with three pseudo-poms. I omitted groupId's,
> scm, distributionManagement, and other content from the poms that were not
> necessary to communicate the basic issue. I've worked around this by using
> the antrun plugin, which is unpleasant and untidy. This seems like it might
> be related to MDEP-44.
> superproject/
> A/ -> no dependencies
> B/ -> dependency:copy A
> //superproject/pom.xml (abbrieviated)
>
> superproject
> pom
> 1.0.0.1-SNAPSHOT
>
> A
> B
>
>
> // superproject/A/pom.xml (abbrievated)
>
>
> superproject
> 1.0.0.1-SNAPSHOT
>
> A
> 1.0.0.1-SNAPSHOT
>
> // superproject/B/pom.xml (abbreviated)
>
>
> superproject
> 1.0.0.1-SNAPSHOT
>
> B
> war
> 1.0.0.1-SNAPSHOT
>
> FooWar
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> copy
>
> copy
>
> package
>
>
>
> A
> ${pom.version}
> jar
>
>
> ${project.build.directory}/${pom.build.finalName}/jars
>
>
>
>
>
>
>
>
> A
> ${pom.version}
>
>
>
> The error message during mvn release:prepare is basically:
> [INFO] Building B
> [INFO] task-segment: [clean, integration-test]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] [dependency:copy {execution: copy}]
> [INFO] Configured Artifact: :A:null:1.0.0.1:jar
> Downloading: /1.0.0.1/A-1.0.0.1.jar
> [WARNING] Unable to get resource from repository sizzle ( details>)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> GroupId:
> ArtifactId: A
> Version: 1.0.0.1
> Reason: Unable to download the artifact from any repository
--
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 m
[jira] Commented: (MRELEASE-459) releaseProfiles has no effect without passing profiles in the command line
[
http://jira.codehaus.org/browse/MRELEASE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=218807#action_218807
]
Karl M. Davis commented on MRELEASE-459:
I actually had to use the following to get things to work:
{{mvn release:perform -Darguments="-PmyProfileToActivate"}}
I think this is because I'm also using the {{-DconnectionUrl=...}} option and
don't have any profiles defined in my {{settings.xml}}.
> releaseProfiles has no effect without passing profiles in the command line
> ---
>
> Key: MRELEASE-459
> URL: http://jira.codehaus.org/browse/MRELEASE-459
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.0-beta-8, 2.0-beta-9
>Reporter: Andreas Christoforides
> Attachments: patch.txt
>
>
> The releaseProfiles parameter on the perform goal is not taken into
> consideration when no other profiles are passed in the command line. In other
> words, the current code only uses the value of the parameter if you have
> additional profiles passed in.
> Example:
> mvn release:perform -P someProfile (uses releaseProfiles value)
> mvn release:perform (does NOT use releaseProfiles value)
> The plugin should use the parameter even if no other profiles are passed. It
> should actually encourage release profiles configured in your POM as opposed
> to arbitrary profiles passed in the command line.
> I have included a patch that uses the releaseProfiles parameter regardless of
> any profiles passed in the command line.
--
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: (MRELEASE-491) Releasing publich nodes with mergeID, but this node only for internal use and not valid with XSD
[ http://jira.codehaus.org/browse/MRELEASE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201571#action_201571 ] Karl M. Davis edited comment on MRELEASE-491 at 12/7/09 10:18 AM: -- This issue is particularly frustrating as it prevents me from using m2eclipse with any non-SNAPSHOT parent POMs I might have released. m2eclipse will flag the parent POM's mergeId element as invalid and refuse to build the child project. Also, reverting back to 2.0-beta-7 does not seem to resolve this problem for me (Maven v2.2.1). My guess is that this problem is caused by another library that the release plugin makes use of-- maybe maven-model? I'm not sure, though, if it's safe to "peg" the version of that plugin in my POM. was (Author: karlmdavis): This issue is particularly frustrating as it prevents me from using m2eclipse with any non-SNAPSHOT parent POMs I might have released. m2eclipse will flag the parent POM's mergeId element as invalid and refuse to build the child project. Also, reverting back to 2.0-beta-7 does not seem to resolve this problem for me (Maven v2.2.1). My guess is that this problem is caused by another library that the release plugin makes use of. > Releasing publich nodes with mergeID, but this node only for internal use and > not valid with XSD > > > Key: MRELEASE-491 > URL: http://jira.codehaus.org/browse/MRELEASE-491 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-9 >Reporter: Hafga > Attachments: poms.zip > > > If you release a POM this plugin will add mergeId node. This node only > allowed for internal use. But this version of POM will publish to repository: > http://maven.apache.org/ref/2.1.0/maven-model/maven.html > > > resource-0 > src/main/resources > > > > > resource-1 > src/test/resources > > -- 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: (MRELEASE-491) Releasing publich nodes with mergeID, but this node only for internal use and not valid with XSD
[ http://jira.codehaus.org/browse/MRELEASE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201571#action_201571 ] Karl M. Davis edited comment on MRELEASE-491 at 12/7/09 10:11 AM: -- This issue is particularly frustrating as it prevents me from using m2eclipse with any non-SNAPSHOT parent POMs I might have released. m2eclipse will flag the parent POM's mergeId element as invalid and refuse to build the child project. Also, reverting back to 2.0-beta-7 does not seem to resolve this problem for me (Maven v2.2.1). My guess is that this problem is caused by another library that the release plugin makes use of. was (Author: karlmdavis): This issue is particularly frustrating as it prevents me from using m2eclipse with any non-SNAPSHOT parent POMs I might have released. m2eclipse will flag the parent POM's mergeId element as invalid and refuse to build the child project. > Releasing publich nodes with mergeID, but this node only for internal use and > not valid with XSD > > > Key: MRELEASE-491 > URL: http://jira.codehaus.org/browse/MRELEASE-491 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-9 >Reporter: Hafga > Attachments: poms.zip > > > If you release a POM this plugin will add mergeId node. This node only > allowed for internal use. But this version of POM will publish to repository: > http://maven.apache.org/ref/2.1.0/maven-model/maven.html > > > resource-0 > src/main/resources > > > > > resource-1 > src/test/resources > > -- 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: (MRELEASE-491) Releasing publich nodes with mergeID, but this node only for internal use and not valid with XSD
[ http://jira.codehaus.org/browse/MRELEASE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201571#action_201571 ] Karl M. Davis commented on MRELEASE-491: This issue is particularly frustrating as it prevents me from using m2eclipse with any non-SNAPSHOT parent POMs I might have released. m2eclipse will flag the parent POM's mergeId element as invalid and refuse to build the child project. > Releasing publich nodes with mergeID, but this node only for internal use and > not valid with XSD > > > Key: MRELEASE-491 > URL: http://jira.codehaus.org/browse/MRELEASE-491 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-9 >Reporter: Hafga > Attachments: poms.zip > > > If you release a POM this plugin will add mergeId node. This node only > allowed for internal use. But this version of POM will publish to repository: > http://maven.apache.org/ref/2.1.0/maven-model/maven.html > > > resource-0 > src/main/resources > > > > > resource-1 > src/test/resources > > -- 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: (SUREFIRE-542) JUnit 4.4 tests skipped for a failed assumption are not reported as "Skipped"
JUnit 4.4 tests skipped for a failed assumption are not reported as "Skipped"
-
Key: SUREFIRE-542
URL: http://jira.codehaus.org/browse/SUREFIRE-542
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.x support
Affects Versions: 2.4.3
Environment: 64 bit Ubuntu 8.10, OpenJDK 6
Reporter: Karl M. Davis
Priority: Minor
Junit 4.4 has support for ignoring tests at runtime via code like the following:
{{Assume.assumeTrue(testsShouldBeRun());}}
When running tests under Surefire that fail their assumptions, the tests are
reported as successful-- not ignored as they ought to be. The javadoc for the
Assume class is here: [http://junit.org/apidocs/org/junit/Assume.html].
--
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: (WAGON-243) wagon-ssh-external does not always detect usage of PSCP (as opposed to SSH)
wagon-ssh-external does not always detect usage of PSCP (as opposed to SSH) --- Key: WAGON-243 URL: http://jira.codehaus.org/browse/WAGON-243 Project: Maven Wagon Issue Type: Bug Components: wagon-ssh-external Affects Versions: 1.0-beta-2 Environment: Windows Vista 32bit, Putty suite Reporter: Karl M. Davis The plugin does not detect that PSCP is being used if the executable's name is all uppercase (as below). It throws a very-unhelpful 'unknown option "-o"' error. c:/Program Files/Putty Suite/PLINK.EXE c:/Program Files/Putty Suite/PSCP.EXE -v This one stumped me for a while. -- 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: (SUREFIRE-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=comments#action_82027 ] Karl M. Davis commented on SUREFIRE-31: --- <> I can't say for certain but I think Maven will try to use the snapshot version in your local repository automatically. It's been a bit since I had to install this myself, so my memory's a bit foggy. If I had my project compiling right now I'd test that for you... but I don't. Give it a try and let us know if it works just having it installed. If not, I'll get my stuff compiling again on Monday and give you instructions on how to get Maven to use the surefire snapshot. Best of luck! > support junit 4.0 > - > > Key: SUREFIRE-31 > URL: http://jira.codehaus.org/browse/SUREFIRE-31 > Project: surefire > Issue Type: Improvement > Components: Junit 4.x support >Reporter: John Didion > Fix For: 2.1 > > Attachments: SUREFIRE-31-maven-surefire-plugin.patch, > SUREFIRE-31-surefire-trunk.patch, surefire-junit4.zip, > SUREFIRE31_karl_maven-surefire-plugin.patch, > SUREFIRE31_karl_surefire_surefire-providers_surefire-junit.patch, > SUREFIRE31_karl_surefire_surefire-providers_surefire-junit_2ndMethod.patch > > > I know this is a pretty sizable task. I just wanted to get it in the system > now that 4.0 has officially been released. Hopefully this will generate some > discussion about how 4.0 will be handled - mainly if it will require a > completely seperate implemenation of surefire (keeping the same API so it can > easily be used by the maven plugin), or if use of 4.0 will be made a > configurable option of the current surefire. > Here's some additional features I'd like to see: > 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an > @Category annotation, or make category a parameter of @Test. However, the > filtering mechanism provided by 4.0 is sufficent to support categories given > the presense of such an annotation. I recommend putting the @Category > annotation in a seperate module (surefire-annotations?) and build support for > it into surefire. Hopefully the junit guys could be convinced to incorporate > it in a later version. > 2. Similarly, support repeated tests via an @Repeated annotation. I'm not > sure how easy this would be to do external to junit. -- 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] Updated: (SUREFIRE-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=all ] Karl M. Davis updated SUREFIRE-31: -- Attachment: SUREFIRE31_karl_surefire_surefire-providers_surefire-junit_2ndMethod.patch This patch is an alternative to the other two I posted. Instead of adding JUnit4 support as a new provider, it patches the existing JUnit3 provider so that it now properly supports the "suite()" method. If you apply this patch and add a "suite()" method to your JUnit4 test classes per http://junit.sourceforge.net/doc/cookbook/cookbook.htm then the JUnit4 tests will be run and reported correctly by Surefire. > support junit 4.0 > - > > Key: SUREFIRE-31 > URL: http://jira.codehaus.org/browse/SUREFIRE-31 > Project: surefire > Issue Type: Improvement > Components: Junit 4.x support >Reporter: John Didion > Fix For: 2.1 > > Attachments: SUREFIRE-31-maven-surefire-plugin.patch, > SUREFIRE-31-surefire-trunk.patch, surefire-junit4.zip, > SUREFIRE31_karl_maven-surefire-plugin.patch, > SUREFIRE31_karl_surefire_surefire-providers_surefire-junit.patch, > SUREFIRE31_karl_surefire_surefire-providers_surefire-junit_2ndMethod.patch > > > I know this is a pretty sizable task. I just wanted to get it in the system > now that 4.0 has officially been released. Hopefully this will generate some > discussion about how 4.0 will be handled - mainly if it will require a > completely seperate implemenation of surefire (keeping the same API so it can > easily be used by the maven plugin), or if use of 4.0 will be made a > configurable option of the current surefire. > Here's some additional features I'd like to see: > 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an > @Category annotation, or make category a parameter of @Test. However, the > filtering mechanism provided by 4.0 is sufficent to support categories given > the presense of such an annotation. I recommend putting the @Category > annotation in a seperate module (surefire-annotations?) and build support for > it into surefire. Hopefully the junit guys could be convinced to incorporate > it in a later version. > 2. Similarly, support repeated tests via an @Repeated annotation. I'm not > sure how easy this would be to do external to junit. -- 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: (SUREFIRE-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=comments#action_76836 ] Karl M. Davis commented on SUREFIRE-31: --- Oh, I should also mention that you will not be able to run both JUnit3 and JUnit4 tests alongside each other with this patch. Two things would need to be done to make that happen: - First, split the surefire-junit provider into "surefire-junit3" and "surefire-junit4" providers with separate projects, POMs, and (most-importantly) dependencies. - Then, further work would need to be done to maven-surefire-plugin. The problem right now is that it can only detect ONE version of JUnit at a time, so if both JUnit3 and JUnit4 are present as dependencies, one will end up "blocking" the other. I'm not familiar enough with Maven's project/dependency API right now to fix that. If one of the regular committers took care of those two things, I think my patches could be included in the next version. In the meantime, they're a better solution for JUnit4 testing with Maven2 than the separate plugin at http://www.unto.net/wiki/Maven_JUnit4_plugin because the results get included in the normal test phase reports. > support junit 4.0 > - > > Key: SUREFIRE-31 > URL: http://jira.codehaus.org/browse/SUREFIRE-31 > Project: surefire > Issue Type: Improvement > Components: Junit 4.x support >Reporter: John Didion > Fix For: 2.1 > > Attachments: SUREFIRE-31-maven-surefire-plugin.patch, > SUREFIRE-31-surefire-trunk.patch, surefire-junit4.zip, > SUREFIRE31_karl_maven-surefire-plugin.patch, > SUREFIRE31_karl_surefire_surefire-providers_surefire-junit.patch > > > I know this is a pretty sizable task. I just wanted to get it in the system > now that 4.0 has officially been released. Hopefully this will generate some > discussion about how 4.0 will be handled - mainly if it will require a > completely seperate implemenation of surefire (keeping the same API so it can > easily be used by the maven plugin), or if use of 4.0 will be made a > configurable option of the current surefire. > Here's some additional features I'd like to see: > 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an > @Category annotation, or make category a parameter of @Test. However, the > filtering mechanism provided by 4.0 is sufficent to support categories given > the presense of such an annotation. I recommend putting the @Category > annotation in a seperate module (surefire-annotations?) and build support for > it into surefire. Hopefully the junit guys could be convinced to incorporate > it in a later version. > 2. Similarly, support repeated tests via an @Repeated annotation. I'm not > sure how easy this would be to do external to junit. -- 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] Updated: (SUREFIRE-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=all ] Karl M. Davis updated SUREFIRE-31: -- Attachment: SUREFIRE31_karl_surefire_surefire-providers_surefire-junit.patch > support junit 4.0 > - > > Key: SUREFIRE-31 > URL: http://jira.codehaus.org/browse/SUREFIRE-31 > Project: surefire > Issue Type: Improvement > Components: Junit 4.x support >Reporter: John Didion > Fix For: 2.1 > > Attachments: SUREFIRE-31-maven-surefire-plugin.patch, > SUREFIRE-31-surefire-trunk.patch, surefire-junit4.zip, > SUREFIRE31_karl_maven-surefire-plugin.patch, > SUREFIRE31_karl_surefire_surefire-providers_surefire-junit.patch > > > I know this is a pretty sizable task. I just wanted to get it in the system > now that 4.0 has officially been released. Hopefully this will generate some > discussion about how 4.0 will be handled - mainly if it will require a > completely seperate implemenation of surefire (keeping the same API so it can > easily be used by the maven plugin), or if use of 4.0 will be made a > configurable option of the current surefire. > Here's some additional features I'd like to see: > 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an > @Category annotation, or make category a parameter of @Test. However, the > filtering mechanism provided by 4.0 is sufficent to support categories given > the presense of such an annotation. I recommend putting the @Category > annotation in a seperate module (surefire-annotations?) and build support for > it into surefire. Hopefully the junit guys could be convinced to incorporate > it in a later version. > 2. Similarly, support repeated tests via an @Repeated annotation. I'm not > sure how easy this would be to do external to junit. -- 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] Updated: (SUREFIRE-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=all ] Karl M. Davis updated SUREFIRE-31: -- Attachment: SUREFIRE31_karl_maven-surefire-plugin.patch > support junit 4.0 > - > > Key: SUREFIRE-31 > URL: http://jira.codehaus.org/browse/SUREFIRE-31 > Project: surefire > Issue Type: Improvement > Components: Junit 4.x support >Reporter: John Didion > Fix For: 2.1 > > Attachments: SUREFIRE-31-maven-surefire-plugin.patch, > SUREFIRE-31-surefire-trunk.patch, surefire-junit4.zip, > SUREFIRE31_karl_maven-surefire-plugin.patch, > SUREFIRE31_karl_surefire_surefire-providers_surefire-junit.patch > > > I know this is a pretty sizable task. I just wanted to get it in the system > now that 4.0 has officially been released. Hopefully this will generate some > discussion about how 4.0 will be handled - mainly if it will require a > completely seperate implemenation of surefire (keeping the same API so it can > easily be used by the maven plugin), or if use of 4.0 will be made a > configurable option of the current surefire. > Here's some additional features I'd like to see: > 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an > @Category annotation, or make category a parameter of @Test. However, the > filtering mechanism provided by 4.0 is sufficent to support categories given > the presense of such an annotation. I recommend putting the @Category > annotation in a seperate module (surefire-annotations?) and build support for > it into surefire. Hopefully the junit guys could be convinced to incorporate > it in a later version. > 2. Similarly, support repeated tests via an @Repeated annotation. I'm not > sure how easy this would be to do external to junit. -- 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: (SUREFIRE-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=comments#action_76833 ] Karl M. Davis commented on SUREFIRE-31: --- As near as I can tell, none of the previous patches work: - surefire-junit4.zip: Does not compile and after spending a bit looking into it, I don't think it can be made to easily. - SUREFIRE-31-surefire-trunk.patch & SUREFIRE-31-maven-surefire-plugin.patch: These can be made to compile (if you comment out some stuff) but they're basically a hack (no offense intended) and don't seem to report results correctly. Both of these patches are based on the JUnit3.x provider, which is the wrong approach, I believe. The code is pretty complicated: involves using proxies (dynamically generated classes, I believe) and a pretty poorly-defined interface. I'm sure there was a reason for writing them this way (perhaps was the standard approach for JUnit3 providers) but it isn't necessary for JUnit4 and should be abandoned. I have created two new patch files which are working perfectly for me. I created the new JUnit4 provider from scratch, (very) loosely based off of the TestNG provider's approach. To apply these patches, check out the maven-surefire-plugin project from https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-surefire-plugin and apply the SUREFIRE31_karl_maven-surefire-plugin.patch file to it (on Windows: right-click the checked-out folder, go to the TortoiseSVN menu, and select Apply Patch). Then, check out the surefire/surefire-providers/surefire-junit project from https://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-providers/surefire-junit and apply the SUREFIRE31_karl_surefire_surefire-providers_surefire-junit.patch file to it. Then, in the root of each project, run "mvn clean install -Dmaven.test.skip=true" to install the surefire updates to your local Maven repository. After that, you should be good to go. Oh, you'll need to make sure that no older versions of JUnit (3.x) are included in your POM-- even as transitive dependencies. If one of your other dependencies is bringing JUnit 3 along for the ride, add an exclusion to your POM, like I had to do in the following case: org.codehaus.mojo jpox-maven-plugin 1.0.3-SNAPSHOT junit junit provided Hope that helps everyone. Please add a comment if you run into any problems with these patches. Enjoy! > support junit 4.0 > - > > Key: SUREFIRE-31 > URL: http://jira.codehaus.org/browse/SUREFIRE-31 > Project: surefire > Issue Type: Improvement > Components: Junit 4.x support >Reporter: John Didion > Fix For: 2.1 > > Attachments: SUREFIRE-31-maven-surefire-plugin.patch, > SUREFIRE-31-surefire-trunk.patch, surefire-junit4.zip > > > I know this is a pretty sizable task. I just wanted to get it in the system > now that 4.0 has officially been released. Hopefully this will generate some > discussion about how 4.0 will be handled - mainly if it will require a > completely seperate implemenation of surefire (keeping the same API so it can > easily be used by the maven plugin), or if use of 4.0 will be made a > configurable option of the current surefire. > Here's some additional features I'd like to see: > 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an > @Category annotation, or make category a parameter of @Test. However, the > filtering mechanism provided by 4.0 is sufficent to support categories given > the presense of such an annotation. I recommend putting the @Category > annotation in a seperate module (surefire-annotations?) and build support for > it into surefire. Hopefully the junit guys could be convinced to incorporate > it in a later version. > 2. Similarly, support repeated tests via an @Repeated annotation. I'm not > sure how easy this would be to do external to junit. -- 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
