[jira] (SUREFIRE-939) Class level @Ignore would create incorrect shared state for parallel junit tests
Kristian Rosenvold created SUREFIRE-939: --- Summary: Class level @Ignore would create incorrect shared state for parallel junit tests Key: SUREFIRE-939 URL: https://jira.codehaus.org/browse/SUREFIRE-939 Project: Maven Surefire Issue Type: Bug Components: Junit 4.7+ (parallel) support Affects Versions: 2.12.4 Reporter: Kristian Rosenvold Adding @Ignore at class-level would create some very "dangerous" shared state that could seriously disturb reporting. This is the likely cause of the intermittent IT failure with parallel ignore test -- 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-939) Class level @Ignore would create incorrect shared state for parallel junit tests
[ https://jira.codehaus.org/browse/SUREFIRE-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-939. --- Resolution: Fixed Fix Version/s: 2.13 Assignee: Kristian Rosenvold Fixed with unit test in ab4eea7e0d4cb9920014a4955d38d4e5e081151c > Class level @Ignore would create incorrect shared state for parallel junit > tests > > > Key: SUREFIRE-939 > URL: https://jira.codehaus.org/browse/SUREFIRE-939 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.12.4 >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: 2.13 > > > Adding @Ignore at class-level would create some very "dangerous" shared state > that could seriously disturb reporting. This is the likely cause of the > intermittent IT failure with parallel ignore test -- 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] (MCOMPILER-194) Strange effects with springs @Configurable (AspectJ) and new compiler plugin version 3.0
Andreas Höhmann created MCOMPILER-194: - Summary: Strange effects with springs @Configurable (AspectJ) and new compiler plugin version 3.0 Key: MCOMPILER-194 URL: https://jira.codehaus.org/browse/MCOMPILER-194 Project: Maven 2.x Compiler Plugin Issue Type: Bug Affects Versions: 3.0 Environment: jdk 1.6.0_38, jdk 1.6.0_37 Reporter: Andreas Höhmann Priority: Blocker I have no details I can only report the "effects" .. I have a maven project with compiler-plugin 2.5.1, aspectj-plugin 1.4, java 1.6 and a lot of @Configurable annotations in my code. Aspectj will decorate these classes so @Autowired dependencies injected during runtime. All is working fine. Now I switch to compiler-plugin 3.0 ... nothing else changed! Then "sometimes" I got NPE's because the injected service etc. are not available. I guess aspectj was not successfull. I have no errors etc. anywhere during build. Strang :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-256) Regression: pom properties are no longer expanded in descriptor.
[
https://jira.codehaus.org/browse/MASSEMBLY-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316082#comment-316082
]
Hannes Kogler commented on MASSEMBLY-256:
-
anybody here, to give a good reason why the interpolation is deactivated in the
descriptor's sections by this code?
blacklist.add( "outputFileNameMapping" );
blacklist.add( "outputDirectoryMapping" );
blacklist.add( "outputDirectory" );
I think ESPECIALLY at those 3 tags the interpolation would make the most
sense..
> Regression: pom properties are no longer expanded in descriptor.
>
>
> Key: MASSEMBLY-256
> URL: https://jira.codehaus.org/browse/MASSEMBLY-256
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1, 2.2-beta-2
> Environment: maven 2.0.8
> windows xp sp2
>Reporter: Mark Reynolds
>Assignee: John Casey
> Fix For: 2.2-beta-3
>
> Attachments: assembly-issue.zip
>
>
> Attached is a minimal project which demonstrates this issue.
> The pom contains a property:
>
> ...
>
> file/path
>
>
> The descriptor uses this property in specifying the output directory for a
> fileSet:
>
> ...
>
>
> src/main/files
> ${fileLocation}
>
>
>
> In versions 2.1, 2.2-beta-1, and 2.2-SNAPSHOT of the assembly plugin, this
> property is expanded so the resulting archive has files in file/path/
> In the latest 2.2-beta-2-SNAPSHOT, the resulting archive has files in
> ${fileLocation}/...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-256) Regression: pom properties are no longer expanded in descriptor.
[
https://jira.codehaus.org/browse/MASSEMBLY-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316082#comment-316082
]
Hannes Kogler edited comment on MASSEMBLY-256 at 12/21/12 5:49 AM:
---
anybody here, to give a good reason why the interpolation is deactivated in the
descriptor's sections by this code?
blacklist.add( "outputFileNameMapping" );
blacklist.add( "outputDirectoryMapping" );
blacklist.add( "outputDirectory" );
I think ESPECIALLY at those 3 tags the interpolation would make the most
sense..
or is there any opional parameter do deactivate this blacklist-behavior?
was (Author: ntshko):
anybody here, to give a good reason why the interpolation is deactivated in
the descriptor's sections by this code?
blacklist.add( "outputFileNameMapping" );
blacklist.add( "outputDirectoryMapping" );
blacklist.add( "outputDirectory" );
I think ESPECIALLY at those 3 tags the interpolation would make the most
sense..
> Regression: pom properties are no longer expanded in descriptor.
>
>
> Key: MASSEMBLY-256
> URL: https://jira.codehaus.org/browse/MASSEMBLY-256
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1, 2.2-beta-2
> Environment: maven 2.0.8
> windows xp sp2
>Reporter: Mark Reynolds
>Assignee: John Casey
> Fix For: 2.2-beta-3
>
> Attachments: assembly-issue.zip
>
>
> Attached is a minimal project which demonstrates this issue.
> The pom contains a property:
>
> ...
>
> file/path
>
>
> The descriptor uses this property in specifying the output directory for a
> fileSet:
>
> ...
>
>
> src/main/files
> ${fileLocation}
>
>
>
> In versions 2.1, 2.2-beta-1, and 2.2-SNAPSHOT of the assembly plugin, this
> property is expanded so the resulting archive has files in file/path/
> In the latest 2.2-beta-2-SNAPSHOT, the resulting archive has files in
> ${fileLocation}/...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-394) Property filtering does not work inside the outputDirectory element content
[
https://jira.codehaus.org/browse/MASSEMBLY-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316084#comment-316084
]
Hannes Kogler commented on MASSEMBLY-394:
-
I don't know what this blacklist "feature" is for?
Can anybody please describe why this makes sense?
The other critical point is, that on the one hand the own defined properties
from the pom.xml aren't interpolated in the assembly descriptors tags (
"outputFileNameMapping", "outputDirectoryMapping", "outputDirectory" ), but on
the other hand the interpolation within those tags work without any problems
with the default variables like ${artifact.groupId}.
> Property filtering does not work inside the outputDirectory element content
> ---
>
> Key: MASSEMBLY-394
> URL: https://jira.codehaus.org/browse/MASSEMBLY-394
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-3
> Environment: Maven version: 2.0.10
> Java version: 1.5.0_15
> Ubuntu 8.10
> OS name: "linux" version: "2.6.27-11-generic" arch: "i386" Family: "unix"
>Reporter: Keith Wedinger
>Assignee: John Casey
>
> Inside my POM, I have the following property defined:
>
> b2b_oba
>
> Inside my assembly descriptor, I am attempting to use the property above as
> well as project defined properties to filter the outputDirectory element
> content contained within . The relevant descriptor snippet is
> below:
>
>
>
> ${clump.codejar.output.directory}/${project.name}.jar
>
> ${project.name}/jars/${clump.name}/${clump.version.dir}
>
>
> After running mvn assembly:assembly, the resultant outputDirectory content
> remains as follows. None of the properties are replaced with their
> corresponding values.
> ${project.name}/jars/${project.name}/${clump.version.dir}
> maven-assembly-plugin version 2.1 does not have this issue. When I use
> version 2.1, property filtering on the outputDirectory works correctly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-394) Property filtering does not work inside the outputDirectory element content
[
https://jira.codehaus.org/browse/MASSEMBLY-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316084#comment-316084
]
Hannes Kogler edited comment on MASSEMBLY-394 at 12/21/12 6:01 AM:
---
I don't know what this blacklist "feature" is for?
Can anybody please describe why this makes sense?
The other critical point is, that on the one hand the own defined properties
from the pom.xml aren't interpolated in the assembly descriptors tags (
"outputFileNameMapping", "outputDirectoryMapping", "outputDirectory" ), but on
the other hand the interpolation within those tags work without any problems
with the default variables like ${artifact.groupId}.
so where is the difference?
-> ${artifact.groupId} => works!
-> ${project.properties.anyPropFromPom} =>
won't be interpolated!?
was (Author: ntshko):
I don't know what this blacklist "feature" is for?
Can anybody please describe why this makes sense?
The other critical point is, that on the one hand the own defined properties
from the pom.xml aren't interpolated in the assembly descriptors tags (
"outputFileNameMapping", "outputDirectoryMapping", "outputDirectory" ), but on
the other hand the interpolation within those tags work without any problems
with the default variables like ${artifact.groupId}.
> Property filtering does not work inside the outputDirectory element content
> ---
>
> Key: MASSEMBLY-394
> URL: https://jira.codehaus.org/browse/MASSEMBLY-394
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-3
> Environment: Maven version: 2.0.10
> Java version: 1.5.0_15
> Ubuntu 8.10
> OS name: "linux" version: "2.6.27-11-generic" arch: "i386" Family: "unix"
>Reporter: Keith Wedinger
>Assignee: John Casey
>
> Inside my POM, I have the following property defined:
>
> b2b_oba
>
> Inside my assembly descriptor, I am attempting to use the property above as
> well as project defined properties to filter the outputDirectory element
> content contained within . The relevant descriptor snippet is
> below:
>
>
>
> ${clump.codejar.output.directory}/${project.name}.jar
>
> ${project.name}/jars/${clump.name}/${clump.version.dir}
>
>
> After running mvn assembly:assembly, the resultant outputDirectory content
> remains as follows. None of the properties are replaced with their
> corresponding values.
> ${project.name}/jars/${project.name}/${clump.version.dir}
> maven-assembly-plugin version 2.1 does not have this issue. When I use
> version 2.1, property filtering on the outputDirectory works correctly.
--
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-811) remote-testing
[ https://jira.codehaus.org/browse/SUREFIRE-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tuomas Kiviaho updated SUREFIRE-811: Attachment: ConsoleOutputCapture.patch I've been using the remoting approach by weawing an aspect ontop of "ForkedBooter" for a while now and the only thing that seems to be causing headache is capturing of the console output that is applied by surefire provider to both System out and err. Currently there is no logic preventing it from functioning in such threads that have not been inherited from the thread that turned on the capturing. This would not be a problem in normal style forking where every thread originated from ForkedBooter and System out is isolated by the process. In my case the ForkClient runs in same process and therefore uses the same System.out/err which are currently captured by surefire provider. Luckily this doesn't cause stack overflow, because ForkingRunListener - where the output ultimately ends up just - just encodes the output prior printing it out to the actual console. Here's a simple patch that fixed this issue for me. > remote-testing > -- > > Key: SUREFIRE-811 > URL: https://jira.codehaus.org/browse/SUREFIRE-811 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Failsafe Plugin >Reporter: Henning Gross > Attachments: ConsoleOutputCapture.patch > > > Add the possibility to copy the target folder to remote machine and run > integration-tests there. Copy back the results and handle them as if they > would have been ran locally. > I would volounteer to submit a patch for this feature if theres a chance it > would be accepted. -- 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] (MRELEASE-798) Commit additional files with release plugin
[
https://jira.codehaus.org/browse/MRELEASE-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316102#comment-316102
]
Robert Scholte commented on MRELEASE-798:
-
Ok, so it's related to MRELEASE-51, but I don't think I'll implement it as
{{additionalCommitFiles}}. One idea I have is to add some kind of extension,
which the {{release-plugin}} will call with specific release properties. That
could return a set of files which should be added to the release.
> Commit additional files with release plugin
> ---
>
> Key: MRELEASE-798
> URL: https://jira.codehaus.org/browse/MRELEASE-798
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: prepare, scm
>Affects Versions: 2.3.2
>Reporter: Thorsten Hoeger
>
> Hi,
> is there any possibility to have the release-plugin commit additional files
> which were
> generated/modified in the preparationGoals.
> Now only the pom.xml is commited. Using scm-plugin has some serious drawbacks
> in this
> situation.
> If it is not possible at the moment, is there any chance to get this in the
> future. Maybe
> there could be a parameter additionalCommitFiles with a list of files to
> commit along with
> pom.xml.
--
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] (MRESOURCES-172) option to NOT use the default excludes for file sets
Axel Wienberg created MRESOURCES-172: Summary: option to NOT use the default excludes for file sets Key: MRESOURCES-172 URL: https://jira.codehaus.org/browse/MRESOURCES-172 Project: Maven 2.x Resources Plugin Issue Type: Improvement Components: copy Affects Versions: 2.6 Reporter: Axel Wienberg It is currently not possible to copy a resource whose name starts with a dot (such as .DS_Store or .hiddenfile), or any other name that happens to match DirectoryScanner.DEFAULTEXCLUDES These default excludes are added to every file set, no matter what includes or excludes the user has specified (e.g. an .DS_Store is silently ignored). For these cases, the maven assembly plugin provides an option called useDefaultExcludes, which may be set to false. The maven resource plugin should also offer such an option. -- 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] (MRELEASE-813) Ability to specify tag for release:perform
Gili created MRELEASE-813: - Summary: Ability to specify tag for release:perform Key: MRELEASE-813 URL: https://jira.codehaus.org/browse/MRELEASE-813 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: Mercurial, perform Affects Versions: 2.4 Reporter: Gili We need a way to specify a tag either to release:perform or the HG scm provider. http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html indicates that we should be able to release:perform from a tag without the use of release.properties but there is no way to specify a tag for the HG scm provider. -- 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] (MRELEASE-813) Ability to specify tag for release:perform
[ https://jira.codehaus.org/browse/MRELEASE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316118#comment-316118 ] Gili commented on MRELEASE-813: --- I don't think it makes a lot of sense to pass a tag/branch name into the HG scm provider. Probably the easiest way to fix this is allow users to pass -Dtag on the command-line. This would be consistent with the release:prepare goal. > Ability to specify tag for release:perform > -- > > Key: MRELEASE-813 > URL: https://jira.codehaus.org/browse/MRELEASE-813 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: Mercurial, perform >Affects Versions: 2.4 >Reporter: Gili > > We need a way to specify a tag either to release:perform or the HG scm > provider. > http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html > indicates that we should be able to release:perform from a tag without the > use of release.properties but there is no way to specify a tag for the HG scm > provider. -- 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
