[jira] Commented: (MRELEASE-335) release:branch commits changes to tags/ directory
[ http://jira.codehaus.org/browse/MRELEASE-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249515#action_249515 ] Marcin Kuthan commented on MRELEASE-335: To avoid commits into tag, you can use the following command: mvn release:branch -DbranchName=1.0.x -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false -DsuppressCommitBeforeBranch=true -DremoteTagging=false For me it should be a default behavior for release:branch. In my case the current development is made in trunk, released versions are tagged. If I need to fix released version, I create "patch" branch from the corresponding tag. E.g brach 1.0.x from tag 1.0. Make a fix and release 1.0.x branch as 1.0.1 (and the tag 1.0.1 is created as a result). So, branch is always created from a tag not from a trunk. And according to the SVN book, created tag must not be changed. > release:branch commits changes to tags/ directory > - > > Key: MRELEASE-335 > URL: http://jira.codehaus.org/browse/MRELEASE-335 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.0-beta-7 >Reporter: Alex B > > It should be possible to create a branch from a tag using the release plugin > without comitting changes to the tags/ directory in subversion. > If this cannot be automated, then perhaps it should be possible to set the > versions and scm urls etc after making the copy from the tag to the branch > manually -- 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-214) IOException when generating dependency report in a multi-module build
[
http://jira.codehaus.org/browse/MPIR-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249516#action_249516
]
Lukas Theussl commented on MPIR-214:
What exactly is the bug? Is there something missing in the report? This is just
an exception that is caught and logged in error mode but I see no bug here.
> IOException when generating dependency report in a multi-module build
> -
>
> Key: MPIR-214
> URL: http://jira.codehaus.org/browse/MPIR-214
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.3.1
> Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 11:58:32+0100)
> Java version: 1.6.0_20
> Java home: D:\Julien\jdk1.6.0_20\jre
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Julien HENRY
>
> Running mvn clean site on my project produce the following error:
> {code}
> [ERROR] IOException:
> D:\Projects\jwebunit\jwebunit-commons-tests\target\classes (Acces denied)
> java.io.FileNotFoundException:
> D:\Projects\jwebunit\jwebunit-commons-tests\target\classes (Acces denied)
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.(ZipFile.java:114)
> at java.util.jar.JarFile.(JarFile.java:135)
> at java.util.jar.JarFile.(JarFile.java:99)
> at
> org.apache.maven.shared.jar.JarAnalyzer.(JarAnalyzer.java:105)
> at
> org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:273)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1374)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:544)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:271)
> {code}
> It doesn't prevent the build to complete.
> You can reproduce on the project:
> https://jwebunit.svn.sourceforge.net/svnroot/jwebunit/trunk
> Build instructions (need toolchains):
> http://jwebunit.sourceforge.net/building-maven.html#Installing_Maven
> Running mvn clean project-info-reports:dependencies works fine so I guess
> there is a bad interaction with another report.
--
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] Closed: (SUREFIRE-644) Use an iterator instead of accessing the list items by index.
[ http://jira.codehaus.org/browse/SUREFIRE-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-644. --- Resolution: Fixed Fix Version/s: 2.7.1 Assignee: Kristian Rosenvold Fixed in r1052094 > Use an iterator instead of accessing the list items by index. > - > > Key: SUREFIRE-644 > URL: http://jira.codehaus.org/browse/SUREFIRE-644 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 2.7 >Reporter: Stefan Birkner >Assignee: Kristian Rosenvold >Priority: Trivial > Fix For: 2.7.1 > > Attachments: SurefireBooter.patch > > > The class SurefireBooter builds an url from the list by accesing the items of > the list of class path urls by index. > The patch uses an iterator. -- 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] Closed: (SUREFIRE-651) Setting printSummary=true disables redirectTestOutputToFile
[ http://jira.codehaus.org/browse/SUREFIRE-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-651. --- Resolution: Fixed Assignee: Kristian Rosenvold Resolved in r1052088 > Setting printSummary=true disables redirectTestOutputToFile > --- > > Key: SUREFIRE-651 > URL: http://jira.codehaus.org/browse/SUREFIRE-651 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.4.2, 2.5, 2.6 > Environment: Linux, Windows >Reporter: Roman Ivashin >Assignee: Kristian Rosenvold > Fix For: 2.7.1 > > Attachments: test.zip > > > Setting printSummary=true disables redirectTestOutputToFile, i.e. the > reportsDirectory/testName-output.txt files are not created. > Please see the testcase attached. -- 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: (MRELEASE-454) The Release-Plugin does not rewrite dependencies in the DependencyManagement with scope "import"
[ http://jira.codehaus.org/browse/MRELEASE-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pedro Rodriguez updated MRELEASE-454: - Attachment: MRELEASE-412_and_MRELEASE-454.patch This is the patch file to fix MRELEASE-412 and MRELEASE-454 Please, ignore the previous MRELEASE-454.path > The Release-Plugin does not rewrite dependencies in the DependencyManagement > with scope "import" > > > Key: MRELEASE-454 > URL: http://jira.codehaus.org/browse/MRELEASE-454 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-9 >Reporter: Jens Mühlenhoff > Attachments: MRELEASE-412_and_MRELEASE-454.patch, MRELEASE-454.diff, > MRELEASE-454.patch > > > Add the following node to the pom. Then prepare the release and this section > will not be rewriten, because the "imported" entry will not appear in > project.getDependencyManagement().getDependencies(). This methode returns all > the resolved dependencies. In this situation the transformDocument method > from AbstractRewritePomsPhase could not change the given dependencies, > because it is not visible to the method. > > > > dist > deps > pom > 4.0.4-SNAPSHOT > import > > > -- 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-412) release:prepare does not update properties during rewrite-poms-for-development phase.
[
http://jira.codehaus.org/browse/MRELEASE-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249463#action_249463
]
Pedro Rodriguez commented on MRELEASE-412:
--
The unit tests couldnt show it because the problem occurs at the integration
level of the release phases.
The rewrite-poms-for-release phase changed the property only in the xml.
During the rewrite-poms-for-development, the new xml (with the "release"
version value) get parsed. However, the same unchanged reactor project (with
the previous development property value) is used.
The development version is not set during the rewrite-poms-for-development
phase because the value of the property in the xml is not the same that in the
project model.
Fix: The project model needs to be updated when we change a property value.
We have fixed this issue at the same time that the MRELEASE-454
> release:prepare does not update properties during
> rewrite-poms-for-development phase.
> -
>
> Key: MRELEASE-412
> URL: http://jira.codehaus.org/browse/MRELEASE-412
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-8
> Environment: Maven version: 2.0.10-RC8
> Java version: 1.5.0_14
> OS name: "linux" version: "2.6.28.4" arch: "i386" Family: "unix"
>Reporter: Christian Schulte
>Priority: Blocker
> Attachments: MRELEASE-412.patch
>
>
> When a dependency version is specified using a property like
> ${someExpression} that property is correctly updated during the
> rewrite-poms-for-release phase but not during the
> rewrite-poms-for-development phase. The attached patch solves this for me.
--
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-4951) Create re-usable component for encrypting passwords
[ http://jira.codehaus.org/browse/MNG-4951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249462#action_249462 ] Anders Hammar commented on MNG-4951: Robert, thanks for the heads-up! I'll continue the discussion regarding that plugin somewhere else more appropriate. In any case, that plugin proves the point of the enhancement in this jira. > Create re-usable component for encrypting passwords > --- > > Key: MNG-4951 > URL: http://jira.codehaus.org/browse/MNG-4951 > Project: Maven 2 & 3 > Issue Type: New Feature >Affects Versions: 3.0.1 > Environment: n/a >Reporter: Anders Hammar > > I'm thinking of creating a plugin that would create the master password file > and encrypt the passwords in settings.xml. > To create the master password and encrypting the passwords, I could copy the > code in the private org.apache.maven.cli.MavenCli.encryption(...) method, but > (as the comment in the code also suggests) moving the functionality to a > re-usable component would be better. It should then be used by Maven as well > as anything else that would do something similar (like a plugin). -- 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-3283) Plugins that require dependency resolution in early phases cause dependency resolution issue
[ http://jira.codehaus.org/browse/MNG-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249458#action_249458 ] Emmanuel Potvin commented on MNG-3283: -- I tried with 3.0.1 and it is still not fixed. Am I alone with this problem??? > Plugins that require dependency resolution in early phases cause dependency > resolution issue > > > Key: MNG-3283 > URL: http://jira.codehaus.org/browse/MNG-3283 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle, Reactor and > workspace >Affects Versions: 2.0.7 >Reporter: Alfie Kirkpatrick >Assignee: Brian Fox > Fix For: Issues to be reviewed for 3.x > > Attachments: maven-dependency-bug.zip > > > What we're seeing is that some multi-project configurations succeed on > 'mvn package' but fail on 'mvn generate-sources'. They are failing when > one project in the reactor references another project in the reactor > which is not installed in the local repo. It seems that the referenced > project has not quite "made it" into the reactor this early in the phase > lifecycle. But it does work correctly if you target a later phase at the > outset which is really confusing. > The problem only occurs when a plugin binds itself to the > generate-sources phase and has @requiresDependencyResolution, presumably > because this is what triggers resolution of the referenced dependency > too early in the lifecycle, and hence the error. > We are seeing this problem when trying to run 'mvn eclipse:eclipse' > because this only executes the generate-sources phase by default and we > have other mojos which genuinely do generate source, such as java2wsdl. > A workaround we're using is to run 'mvn process-classes eclipse:eclipse'. > Attached is a really simple project that exhibits this problem. -- 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] Closed: (MRESOURCES-61) PluginDescriptor not found
[ http://jira.codehaus.org/browse/MRESOURCES-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MRESOURCES-61. -- Resolution: Not A Bug Fix Version/s: (was: 2.5) Assignee: Olivier Lamy > PluginDescriptor not found > -- > > Key: MRESOURCES-61 > URL: http://jira.codehaus.org/browse/MRESOURCES-61 > Project: Maven 2.x Resources Plugin > Issue Type: Bug >Reporter: Brill Pappin >Assignee: Olivier Lamy > Attachments: maven-eclipse-integration-plugin.txt > > > The following error, every time I run a build has been ongoing for quite some > time now. > 3/21/08 3:34:06 PM EDT: Build error for /aleixo-console/pom.xml; > java.lang.IllegalStateException: The PluginDescriptor for the plugin > org.apache.maven.plugins:maven-resources-plugin was not found > It seems to go away if I run with a -U to update the plugins but comes back > regularly. > Can somebody please fix whatever issue is causing this to occur? -- 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] Closed: (MRESOURCES-104) while filtering resources the token replacement stops at the character @
[
http://jira.codehaus.org/browse/MRESOURCES-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MRESOURCES-104.
---
Resolution: Fixed
fixed [rev 1052028|http://svn.apache.org/viewvc?view=revision&revision=1052028]
SNAPSHOT deployed.
> while filtering resources the token replacement stops at the character @
> -
>
> Key: MRESOURCES-104
> URL: http://jira.codehaus.org/browse/MRESOURCES-104
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: Windows XP, Java 1.6.0_16
>Reporter: Thomas Fahrmeyer
>Assignee: Olivier Lamy
>Priority: Critical
> Fix For: 2.5
>
> Attachments: m3-resource-filtering.zip, MRESOURCES-104.zip
>
>
> Create a simple file hello.txt under src/main/resources with following
> content:
> "
> This property ${testProperty} was replaced
> but the one behind a @ will not be processed, as you
> see: ${testProperty}. You shouldn't see a property reference.
> "
> define a build section in your pom.xml like this
>
>
>
> src/main/resources
> true
>
> **/*.txt
>
>
>
> src/main/resources
> false
>
> **/*.txt
>
>
>
> Run the command:
> mvn process-resources -DtestProperty=IwasReplaced
> this produces the output
> "
> This property IwasReplaced was replaced
> but the one behind a @ will not be processed, as you
> see: ${testProperty}. You shouldn't see a property reference.
> "
> As you see, the second property reference was not resolved. The replacement
> just stops after the @ character.
--
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] Closed: (MSHARED-176) Add support of stopping at the end of line to prevent issue with endToken not found
[ http://jira.codehaus.org/browse/MSHARED-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSHARED-176. Resolution: Fixed fixed [rev 1052026|http://svn.apache.org/viewvc?view=revision&revision=1052026] > Add support of stopping at the end of line to prevent issue with endToken not > found > --- > > Key: MSHARED-176 > URL: http://jira.codehaus.org/browse/MSHARED-176 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-filtering >Affects Versions: maven-filtering-1.0-beta-4 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: maven-filtering-1.0-beta-5 > > > see MRESSOURCES-104 > So stopping searching endToken will be done at the EOL. > Option to preserve previous possible -- 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: (MSHARED-176) Add support of stopping at the end of line to prevent issue with endToken not found
[ http://jira.codehaus.org/browse/MSHARED-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MSHARED-176: - Fix Version/s: maven-filtering-1.0-beta-5 Assignee: Olivier Lamy > Add support of stopping at the end of line to prevent issue with endToken not > found > --- > > Key: MSHARED-176 > URL: http://jira.codehaus.org/browse/MSHARED-176 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-filtering >Affects Versions: maven-filtering-1.0-beta-4 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: maven-filtering-1.0-beta-5 > > > see MRESSOURCES-104 > So stopping searching endToken will be done at the EOL. > Option to preserve previous possible -- 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: (MSHARED-176) Add support of stopping at the end of line to prevent issue with endToken not found
Add support of stopping at the end of line to prevent issue with endToken not found --- Key: MSHARED-176 URL: http://jira.codehaus.org/browse/MSHARED-176 Project: Maven Shared Components Issue Type: Bug Components: maven-filtering Affects Versions: maven-filtering-1.0-beta-4 Reporter: Olivier Lamy see MRESSOURCES-104 So stopping searching endToken will be done at the EOL. Option to preserve previous possible -- 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: (MRESOURCES-104) while filtering resources the token replacement stops at the character @
[
http://jira.codehaus.org/browse/MRESOURCES-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249453#action_249453
]
Olivier Lamy commented on MRESOURCES-104:
-
xmas gift :-)
BTW in fact we won't probably support anymore the multi line filtering :P
> while filtering resources the token replacement stops at the character @
> -
>
> Key: MRESOURCES-104
> URL: http://jira.codehaus.org/browse/MRESOURCES-104
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: Windows XP, Java 1.6.0_16
>Reporter: Thomas Fahrmeyer
>Assignee: Olivier Lamy
>Priority: Critical
> Fix For: 2.5
>
> Attachments: m3-resource-filtering.zip, MRESOURCES-104.zip
>
>
> Create a simple file hello.txt under src/main/resources with following
> content:
> "
> This property ${testProperty} was replaced
> but the one behind a @ will not be processed, as you
> see: ${testProperty}. You shouldn't see a property reference.
> "
> define a build section in your pom.xml like this
>
>
>
> src/main/resources
> true
>
> **/*.txt
>
>
>
> src/main/resources
> false
>
> **/*.txt
>
>
>
> Run the command:
> mvn process-resources -DtestProperty=IwasReplaced
> this produces the output
> "
> This property IwasReplaced was replaced
> but the one behind a @ will not be processed, as you
> see: ${testProperty}. You shouldn't see a property reference.
> "
> As you see, the second property reference was not resolved. The replacement
> just stops after the @ character.
--
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: (MRESOURCES-104) while filtering resources the token replacement stops at the character @
[
http://jira.codehaus.org/browse/MRESOURCES-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249451#action_249451
]
Stephane Nicoll edited comment on MRESOURCES-104 at 12/22/10 12:14 PM:
---
go, go, go Olivier ;)
was (Author: sni):
go, go, go Oliver ;)
> while filtering resources the token replacement stops at the character @
> -
>
> Key: MRESOURCES-104
> URL: http://jira.codehaus.org/browse/MRESOURCES-104
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: Windows XP, Java 1.6.0_16
>Reporter: Thomas Fahrmeyer
>Assignee: Olivier Lamy
>Priority: Critical
> Fix For: 2.5
>
> Attachments: m3-resource-filtering.zip, MRESOURCES-104.zip
>
>
> Create a simple file hello.txt under src/main/resources with following
> content:
> "
> This property ${testProperty} was replaced
> but the one behind a @ will not be processed, as you
> see: ${testProperty}. You shouldn't see a property reference.
> "
> define a build section in your pom.xml like this
>
>
>
> src/main/resources
> true
>
> **/*.txt
>
>
>
> src/main/resources
> false
>
> **/*.txt
>
>
>
> Run the command:
> mvn process-resources -DtestProperty=IwasReplaced
> this produces the output
> "
> This property IwasReplaced was replaced
> but the one behind a @ will not be processed, as you
> see: ${testProperty}. You shouldn't see a property reference.
> "
> As you see, the second property reference was not resolved. The replacement
> just stops after the @ character.
--
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: (MRESOURCES-104) while filtering resources the token replacement stops at the character @
[
http://jira.codehaus.org/browse/MRESOURCES-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249451#action_249451
]
Stephane Nicoll commented on MRESOURCES-104:
go, go, go Oliver ;)
> while filtering resources the token replacement stops at the character @
> -
>
> Key: MRESOURCES-104
> URL: http://jira.codehaus.org/browse/MRESOURCES-104
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: Windows XP, Java 1.6.0_16
>Reporter: Thomas Fahrmeyer
>Assignee: Olivier Lamy
>Priority: Critical
> Fix For: 2.5
>
> Attachments: m3-resource-filtering.zip, MRESOURCES-104.zip
>
>
> Create a simple file hello.txt under src/main/resources with following
> content:
> "
> This property ${testProperty} was replaced
> but the one behind a @ will not be processed, as you
> see: ${testProperty}. You shouldn't see a property reference.
> "
> define a build section in your pom.xml like this
>
>
>
> src/main/resources
> true
>
> **/*.txt
>
>
>
> src/main/resources
> false
>
> **/*.txt
>
>
>
> Run the command:
> mvn process-resources -DtestProperty=IwasReplaced
> this produces the output
> "
> This property IwasReplaced was replaced
> but the one behind a @ will not be processed, as you
> see: ${testProperty}. You shouldn't see a property reference.
> "
> As you see, the second property reference was not resolved. The replacement
> just stops after the @ character.
--
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-4951) Create re-usable component for encrypting passwords
[ http://jira.codehaus.org/browse/MNG-4951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249450#action_249450 ] Robert Scholte commented on MNG-4951: - Anders, At codehaus I've started on a plugin called the setup-maven-plugin. One of it's features in encrypting passwords. It's still a sandbox project and it was developed against Maven 3.0-alpha-1 Still some work to do, maybe even splitting it up in a few separate projects, now this kind of godmojo can setup anything * http://mojo.codehaus.org/setup-maven-plugin * http://mojo.codehaus.org/setup-maven-plugin/user-settings-mojo.html * http://mojo.codehaus.org/setup-maven-plugin/global-settings-mojo.html * http://mojo.codehaus.org/setup-maven-plugin/settings-security-mojo.html > Create re-usable component for encrypting passwords > --- > > Key: MNG-4951 > URL: http://jira.codehaus.org/browse/MNG-4951 > Project: Maven 2 & 3 > Issue Type: New Feature >Affects Versions: 3.0.1 > Environment: n/a >Reporter: Anders Hammar > > I'm thinking of creating a plugin that would create the master password file > and encrypt the passwords in settings.xml. > To create the master password and encrypting the passwords, I could copy the > code in the private org.apache.maven.cli.MavenCli.encryption(...) method, but > (as the comment in the code also suggests) moving the functionality to a > re-usable component would be better. It should then be used by Maven as well > as anything else that would do something similar (like a plugin). -- 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: (MRELEASE-454) The Release-Plugin does not rewrite dependencies in the DependencyManagement with scope "import"
[ http://jira.codehaus.org/browse/MRELEASE-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pedro Rodriguez updated MRELEASE-454: - Attachment: MRELEASE-454.patch This is the complete patch containing both changes and unit tests Please, ignore MRELEASE-454.diff > The Release-Plugin does not rewrite dependencies in the DependencyManagement > with scope "import" > > > Key: MRELEASE-454 > URL: http://jira.codehaus.org/browse/MRELEASE-454 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-9 >Reporter: Jens Mühlenhoff > Attachments: MRELEASE-454.diff, MRELEASE-454.patch > > > Add the following node to the pom. Then prepare the release and this section > will not be rewriten, because the "imported" entry will not appear in > project.getDependencyManagement().getDependencies(). This methode returns all > the resolved dependencies. In this situation the transformDocument method > from AbstractRewritePomsPhase could not change the given dependencies, > because it is not visible to the method. > > > > dist > deps > pom > 4.0.4-SNAPSHOT > import > > > -- 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-454) The Release-Plugin does not rewrite dependencies in the DependencyManagement with scope "import"
[
http://jira.codehaus.org/browse/MRELEASE-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=247472#action_247472
]
Pedro Rodriguez edited comment on MRELEASE-454 at 12/22/10 10:41 AM:
-
The rewriteDependencies method was rewritten to use raw dependency definitions
directly from the pom xml.
Only dependencies found in the pom xml document are processed.
However, it was required to interpolate the "groupId", "artifactId" and
"version" in the xml in order to compare with the resolved dependencies.
Regarding the "MRELEASE-412" issue while updating properties during the
rewrite-poms-for-development phase, we only observed that in the case of a
dependency management import and it was fixed.
New unit tests:
One additional "rewrite-for-release" unit test was added
imported-dependency-management-in-reactor
Two additional "rewrite-poms-for-development" unit tests were added:
pom-with-parent-and-properties-in-dependency-management
pom-with-parent-and-properties-in-dependency-management-import
Persistent issue
Maven (2.2.1) always resolves imported dependencyManagement from the
repository, ignoring the reactor. Also, Maven does not recognize the imported
dependencyManagement pom as a dependency so the reactor order is broken.
The workaround we use for that is:
1) Manually order the modules to ensure that dependencyManagement
imported POM gets built before the importing module.
2) Execute release:prepare with preparationGoals "install" to ensure
that the imported POM can be resolved from the repository during the importing
module build.
Note: In the new Unit Tests we have added for dependency-management-import we
bypassed these issues making available the required artifacts in the test
repository.
There is already a JIRA open for this: MNG-4052.
MNG-4052: import scope dependencies prefer to download pom rather than find it
in the current project
This issue appears currently closed by it was fixed in 3.0-alpha-3 version.
However, the current development version (2.2-SNAPSHOT) of the
maven-release-plugin uses Maven 2.0.9.
Next (Question): How do we plan to upgrade the plugins to Maven 3?
Are we going to create a new "release" branch for the Maven 3 development? ...
maven-release-plugin development version "3.0-SNAPSHOT"
was (Author: prodriguez):
The problem is that the current code rewrites the dependencies already
resolved.
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase, Line 272
if ( project.getDependencyManagement() != null )
{
Element dependencyRoot = rootElement.getChild( "dependencyManagement",
namespace );
if ( dependencyRoot != null )
{
rewriteDependencies(
project.getDependencyManagement().getDependencies(), dependencyRoot,
mappedVersions, resolvedSnapshotDependencies,
originalVersions, projectId,
properties, result, releaseDescriptor );
}
}
A simple fix could be to add the "imported dependency management" dependencies
to the dependencies list we want to rewrite:
if ( project.getDependencyManagement() != null )
{
Element dependencyRoot = rootElement.getChild( "dependencyManagement",
namespace );
if ( dependencyRoot != null )
{
List dependencies = new ArrayList(
project.getDependencyManagement().getDependencies() );
// Add "imported dependencyManagement" to the dependencies list to
allow them to be rewrited as well
Element dependencyManagementDependenciesRoot =
dependencyRoot.getChild("dependencies", namespace);
if( dependencyManagementDependenciesRoot != null )
{
List dependencyManagementDependencyElements =
dependencyManagementDependenciesRoot.getChildren();
for (Iterator iterator = dependencyManagementDependencyElements
.iterator(); iterator.hasNext();)
{
Element dependencyManagementDependency = (Element)
iterator.next();
Element groupId =
dependencyManagementDependency.getChild( "groupId", namespace );
Element artifactId =
dependencyManagementDependency.getChild( "artifactId", namespace );
Element version =
dependencyManagementDependency.getChild( "version", namespace );
Element scope =
dependencyManagementDependency.getChild( "scope", namespace );
Element type = dependencyManagementDependency.getChild(
"type", namespace );
if( groupId != null && artifactId != null && version !=
null && scope != null && type != null &&
"pom".equals(type.getText()) &&
"import".equals(scope.getText()) )
[jira] Commented: (MRESOURCES-104) while filtering resources the token replacement stops at the character @
[
http://jira.codehaus.org/browse/MRESOURCES-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249428#action_249428
]
Alexandre Bénard commented on MRESOURCES-104:
-
I confirm the bug on 3.0.1 and 3.0.2-SNAPSHOT (from today) but not on 2.2.1.
I notice 2 things.
First, filtering depend on the number of @ before the ${testProperty}:
- odd the ${testProperty} is not processed,
- even the ${testProperty} is processed.
Secondly, if you add one @ after the ${testProperty}, the all the file is
correctly processed.
So, a workaround could be to add a @ in a comment at the end of the file.
The first example modify like this works:
This property ${project.version} was replaced
but the one behind a @ will not be processed, as you
see: ${project.version}. You shouldn't see a property reference.
But if there is a second @, all the file is correctly processed !!!
> while filtering resources the token replacement stops at the character @
> -
>
> Key: MRESOURCES-104
> URL: http://jira.codehaus.org/browse/MRESOURCES-104
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: Windows XP, Java 1.6.0_16
>Reporter: Thomas Fahrmeyer
>Assignee: Arnaud Heritier
>Priority: Critical
> Fix For: 2.5
>
> Attachments: m3-resource-filtering.zip, MRESOURCES-104.zip
>
>
> Create a simple file hello.txt under src/main/resources with following
> content:
> "
> This property ${testProperty} was replaced
> but the one behind a @ will not be processed, as you
> see: ${testProperty}. You shouldn't see a property reference.
> "
> define a build section in your pom.xml like this
>
>
>
> src/main/resources
> true
>
> **/*.txt
>
>
>
> src/main/resources
> false
>
> **/*.txt
>
>
>
> Run the command:
> mvn process-resources -DtestProperty=IwasReplaced
> this produces the output
> "
> This property IwasReplaced was replaced
> but the one behind a @ will not be processed, as you
> see: ${testProperty}. You shouldn't see a property reference.
> "
> As you see, the second property reference was not resolved. The replacement
> just stops after the @ character.
--
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: (MRESOURCES-133) if "<%@ page import = "java.util.List" %>" is present in a file, filtering does'nt work
[
http://jira.codehaus.org/browse/MRESOURCES-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249426#action_249426
]
Alexandre Bénard commented on MRESOURCES-133:
-
Sorry, I missed it.
I add a comment on MRESOURCES-104
> if "<%@ page import = "java.util.List" %>" is present in a file, filtering
> does'nt work
> ---
>
> Key: MRESOURCES-133
> URL: http://jira.codehaus.org/browse/MRESOURCES-133
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.4.3
> Environment: Windows 7
>Reporter: Alexandre Bénard
>Assignee: Benjamin Bentmann
> Attachments: pom.xml, test.properties
>
>
> If you have this test.properties file in src/main/resources directory (for
> example):
><%@ page import = "java.util.List" %>
>${project.name}
>${project.version}
> And you add correct filtering information in pom.xml:
>
> src/main/resources
> true
>
> **/*.xml
> **/*.jsp
> **/*.properties
>
>
> With "mvn package" command, the build is successful but the file is not
> filtered.
> If you remove the first line (<%@ page import = "java.util.List" %>), there
> is no problem.
> Produce in 3.0.1 and 3.0.2-snapshot (from today) but not in 2.2.1.
--
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: (MSITE-524) Duplicate registration of doxia-module-docbook-simplifed
[
http://jira.codehaus.org/browse/MSITE-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249422#action_249422
]
Paul Ferraro commented on MSITE-524:
FYI - this error can be reproduced using version 1.1.4 of
org.apache.maven.doxia:doxia-module-docbook-simple as well as the latest
3.0-beta-4-SNAPSHOT of org.apache.maven.plugins:maven-site-plugin.
I do not see this error with any of the other doxia modules.
Any ideas?
> Duplicate registration of doxia-module-docbook-simplifed
>
>
> Key: MSITE-524
> URL: http://jira.codehaus.org/browse/MSITE-524
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
>Affects Versions: 3.0-beta-3
> Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
> Java version: 1.6.0_21
> Java home: D:\java\jdk\jre
> Default locale: cs_CZ, platform encoding: Cp1250
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Petr Prochazka
>Priority: Blocker
> Attachments: maven-site.zip, site-debug.log, site.log
>
>
> I have project site with page written in simplified docbook and I obtain
> exception:
> {noformat}[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site (default-site) on
> project mave
> n-site-error: Error during page generation: Files 'docbook\index.xml' clashes
> with existing 'D:\Projects-test\maven-site
> \src\site\docbook\index.xml'. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugi
> n:3.0-beta-3:site (default-site) on project maven-site-error: Error during
> page generation
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:314)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:151)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:132)
> 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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error during page
> generation
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:127)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
> ... 19 more
> Caused by: org.apache.maven.doxia.siterenderer.RendererException: Files
> 'docbook\index.xml' clashes with existing 'D:\Pr
> ojects-test\maven-site\src\site\docbook\index.xml'.
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.addModuleFiles(DefaultSiteRenderer.java:259)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.locateDocumentFiles(DefaultSiteRenderer.java:168)
> at
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.locateDocuments(AbstractSiteRenderingMojo.java:411)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:148)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:122)
> ... 21 more{noformat}
> I use this setting of plugin:
> {noformat}
> maven-site-plugin
> 3.0-beta-3
>
>
> org.apache.maven.doxia
> doxia-mod
[jira] Updated: (MCHANGES-190) HTML in changes.xml stopped working
[ http://jira.codehaus.org/browse/MCHANGES-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MCHANGES-190: --- Attachment: MCHANGES-190-2.patch Although unrelated to this issue, looking at the announcement mail feature, I noticed that the 'announcement-generate' goal supports template encodings but the 'announcement-mail' goal does not. This patch adds a 'templateEncoding' parameter to the 'announcement-mail' goal. > HTML in changes.xml stopped working > --- > > Key: MCHANGES-190 > URL: http://jira.codehaus.org/browse/MCHANGES-190 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: changes.xml >Affects Versions: 2.3 > Environment: Maven version: 2.0.10 > Java version: 1.5.0_17 > OS name: "linux" version: "2.6.32-686" arch: "i386" Family: "unix" >Reporter: Christian Schulte >Priority: Critical > Attachments: changes.xml, changes.xml, MCHANGES-190-2.patch, > MCHANGES-190.patch, MCHANGES-190.zip > > > The fix for MCHANGES-189 does not seem to be correct. A changes.xml file > containing HTML-Tags got rendered correctly using version 2.2. Starting with > version 2.3, HTML-Tags will be encoded using HTML entities for the '<' and > '>' characters leading to the actual tags getting shown in the report. See > the attached example changes.xml file containing HTML no longer working with > version 2.3. -- 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: (MCHANGES-190) HTML in changes.xml stopped working
[ http://jira.codehaus.org/browse/MCHANGES-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249420#action_249420 ] Christian Schulte commented on MCHANGES-190: Setting 'escapeHTML' to 'false' the patch works for me. > HTML in changes.xml stopped working > --- > > Key: MCHANGES-190 > URL: http://jira.codehaus.org/browse/MCHANGES-190 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: changes.xml >Affects Versions: 2.3 > Environment: Maven version: 2.0.10 > Java version: 1.5.0_17 > OS name: "linux" version: "2.6.32-686" arch: "i386" Family: "unix" >Reporter: Christian Schulte >Priority: Critical > Attachments: changes.xml, changes.xml, MCHANGES-190.patch, > MCHANGES-190.zip > > > The fix for MCHANGES-189 does not seem to be correct. A changes.xml file > containing HTML-Tags got rendered correctly using version 2.2. Starting with > version 2.3, HTML-Tags will be encoded using HTML entities for the '<' and > '>' characters leading to the actual tags getting shown in the report. See > the attached example changes.xml file containing HTML no longer working with > version 2.3. -- 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-4951) Create re-usable component for encrypting passwords
Create re-usable component for encrypting passwords --- Key: MNG-4951 URL: http://jira.codehaus.org/browse/MNG-4951 Project: Maven 2 & 3 Issue Type: New Feature Affects Versions: 3.0.1 Environment: n/a Reporter: Anders Hammar I'm thinking of creating a plugin that would create the master password file and encrypt the passwords in settings.xml. To create the master password and encrypting the passwords, I could copy the code in the private org.apache.maven.cli.MavenCli.encryption(...) method, but (as the comment in the code also suggests) moving the functionality to a re-usable component would be better. It should then be used by Maven as well as anything else that would do something similar (like a plugin). -- 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] Closed: (MNG-4950) Javadoc improvements to DefaultSettingsWriter/Reader
[ http://jira.codehaus.org/browse/MNG-4950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4950. -- Resolution: Fixed Fix Version/s: 3.0.2 Assignee: Benjamin Bentmann Applied in [r1051868|http://svn.apache.org/viewvc?view=revision&revision=1051868]. > Javadoc improvements to DefaultSettingsWriter/Reader > > > Key: MNG-4950 > URL: http://jira.codehaus.org/browse/MNG-4950 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Settings >Affects Versions: 3.0.1 > Environment: n/a >Reporter: Anders Hammar >Assignee: Benjamin Bentmann >Priority: Trivial > Fix For: 3.0.2 > > Attachments: maven-settings-builder.patch > > > The javadocs of DefaultSettingsWriter and DefaultSettingsReader is just > copied from the interface and should better reflect what these classes do. > I fixed this in the attached patch (project: maven-settings-builder on trunk). -- 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-4950) Javadoc improvements to DefaultSettingsWriter/Reader
[ http://jira.codehaus.org/browse/MNG-4950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-4950: --- Priority: Trivial (was: Major) > Javadoc improvements to DefaultSettingsWriter/Reader > > > Key: MNG-4950 > URL: http://jira.codehaus.org/browse/MNG-4950 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Settings >Affects Versions: 3.0.1 > Environment: n/a >Reporter: Anders Hammar >Priority: Trivial > Attachments: maven-settings-builder.patch > > > The javadocs of DefaultSettingsWriter and DefaultSettingsReader is just > copied from the interface and should better reflect what these classes do. > I fixed this in the attached patch (project: maven-settings-builder on trunk). -- 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-4950) Javadoc improvements to DefaultSettingsWriter/Reader
Javadoc improvements to DefaultSettingsWriter/Reader Key: MNG-4950 URL: http://jira.codehaus.org/browse/MNG-4950 Project: Maven 2 & 3 Issue Type: Improvement Components: Settings Affects Versions: 3.0.1 Environment: n/a Reporter: Anders Hammar Attachments: maven-settings-builder.patch The javadocs of DefaultSettingsWriter and DefaultSettingsReader is just copied from the interface and should better reflect what these classes do. I fixed this in the attached patch (project: maven-settings-builder on trunk). -- 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] Closed: (MRESOURCES-133) if "<%@ page import = "java.util.List" %>" is present in a file, filtering does'nt work
[
http://jira.codehaus.org/browse/MRESOURCES-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MRESOURCES-133.
Resolution: Duplicate
Assignee: Benjamin Bentmann
> if "<%@ page import = "java.util.List" %>" is present in a file, filtering
> does'nt work
> ---
>
> Key: MRESOURCES-133
> URL: http://jira.codehaus.org/browse/MRESOURCES-133
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.4.3
> Environment: Windows 7
>Reporter: Alexandre Bénard
>Assignee: Benjamin Bentmann
> Attachments: pom.xml, test.properties
>
>
> If you have this test.properties file in src/main/resources directory (for
> example):
><%@ page import = "java.util.List" %>
>${project.name}
>${project.version}
> And you add correct filtering information in pom.xml:
>
> src/main/resources
> true
>
> **/*.xml
> **/*.jsp
> **/*.properties
>
>
> With "mvn package" command, the build is successful but the file is not
> filtered.
> If you remove the first line (<%@ page import = "java.util.List" %>), there
> is no problem.
> Produce in 3.0.1 and 3.0.2-snapshot (from today) but not in 2.2.1.
--
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] Moved: (MRESOURCES-133) if "<%@ page import = "java.util.List" %>" is present in a file, filtering does'nt work
[
http://jira.codehaus.org/browse/MRESOURCES-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann moved MNG-4949 to MRESOURCES-133:
---
Complexity: (was: Intermediate)
Component/s: (was: POM)
Affects Version/s: (was: 3.0.2)
(was: 3.0.1)
2.4.3
Key: MRESOURCES-133 (was: MNG-4949)
Project: Maven 2.x Resources Plugin (was: Maven 2 & 3)
> if "<%@ page import = "java.util.List" %>" is present in a file, filtering
> does'nt work
> ---
>
> Key: MRESOURCES-133
> URL: http://jira.codehaus.org/browse/MRESOURCES-133
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.4.3
> Environment: Windows 7
>Reporter: Alexandre Bénard
> Attachments: pom.xml, test.properties
>
>
> If you have this test.properties file in src/main/resources directory (for
> example):
><%@ page import = "java.util.List" %>
>${project.name}
>${project.version}
> And you add correct filtering information in pom.xml:
>
> src/main/resources
> true
>
> **/*.xml
> **/*.jsp
> **/*.properties
>
>
> With "mvn package" command, the build is successful but the file is not
> filtered.
> If you remove the first line (<%@ page import = "java.util.List" %>), there
> is no problem.
> Produce in 3.0.1 and 3.0.2-snapshot (from today) but not in 2.2.1.
--
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-4949) if "<%@ page import = "java.util.List" %>" is present in a file, filtering does'nt work
if "<%@ page import = "java.util.List" %>" is present in a file, filtering
does'nt work
---
Key: MNG-4949
URL: http://jira.codehaus.org/browse/MNG-4949
Project: Maven 2 & 3
Issue Type: Bug
Components: POM
Affects Versions: 3.0.1, 3.0.2
Environment: Windows 7
Reporter: Alexandre Bénard
Attachments: pom.xml, test.properties
If you have this test.properties file in src/main/resources directory (for
example):
<%@ page import = "java.util.List" %>
${project.name}
${project.version}
And you add correct filtering information in pom.xml:
src/main/resources
true
**/*.xml
**/*.jsp
**/*.properties
With "mvn package" command, the build is successful but the file is not
filtered.
If you remove the first line (<%@ page import = "java.util.List" %>), there is
no problem.
Produce in 3.0.1 and 3.0.2-snapshot (from today) but not in 2.2.1.
--
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: (MPIR-214) IOException when generating dependency report in a multi-module build
IOException when generating dependency report in a multi-module build
-
Key: MPIR-214
URL: http://jira.codehaus.org/browse/MPIR-214
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Components: dependencies
Affects Versions: 2.3.1
Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 11:58:32+0100)
Java version: 1.6.0_20
Java home: D:\Julien\jdk1.6.0_20\jre
Default locale: fr_FR, platform encoding: Cp1252
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
Reporter: Julien HENRY
Running mvn clean site on my project produce the following error:
{code}
[ERROR] IOException: D:\Projects\jwebunit\jwebunit-commons-tests\target\classes
(Acces denied)
java.io.FileNotFoundException:
D:\Projects\jwebunit\jwebunit-commons-tests\target\classes (Acces denied)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:114)
at java.util.jar.JarFile.(JarFile.java:135)
at java.util.jar.JarFile.(JarFile.java:99)
at org.apache.maven.shared.jar.JarAnalyzer.(JarAnalyzer.java:105)
at
org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:273)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1374)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:544)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:271)
{code}
It doesn't prevent the build to complete.
You can reproduce on the project:
https://jwebunit.svn.sourceforge.net/svnroot/jwebunit/trunk
Build instructions (need toolchains):
http://jwebunit.sourceforge.net/building-maven.html#Installing_Maven
Running mvn clean project-info-reports:dependencies works fine so I guess there
is a bad interaction with another report.
--
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-671) surefire should not run abstract test cases
[ http://jira.codehaus.org/browse/SUREFIRE-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249397#action_249397 ] Alasdair Maclean commented on SUREFIRE-671: --- Sorry I'd gone home for the day - as you've already seen, it's JUnit 4. Thanks for fixing this. > surefire should not run abstract test cases > --- > > Key: SUREFIRE-671 > URL: http://jira.codehaus.org/browse/SUREFIRE-671 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.7 >Reporter: Alasdair Maclean >Assignee: Kristian Rosenvold >Priority: Minor > Fix For: 2.7.1 > > Attachments: abstract-test-case.zip, tests.mms.common.MyTestCase.txt > > > Surefire reports a failure if an abstract test case (extending > junit.framework.TestCase) with TestCase in its name contains no tests. This > bug appears to have the same symptoms as issue SUREFIRE-221, but as it's so > old I'm assuming a different cause > Workaround: adding @Ignore to the abstract test case (or change the class > name) -- 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-673) mockito does not always seem to work with 2.7
[ http://jira.codehaus.org/browse/SUREFIRE-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249395#action_249395 ] Kristian Rosenvold commented on SUREFIRE-673: - David confirms fix to be good via twitter > mockito does not always seem to work with 2.7 > - > > Key: SUREFIRE-673 > URL: http://jira.codehaus.org/browse/SUREFIRE-673 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold >Priority: Critical > Fix For: 2.7.1 > > > David Gageot reported this issue with test project. Works with 2.6, not with > 2.7 > https://github.com/dgageot/MockitoSurefire.git -- 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-130) Support tests written in Jython
[ http://jira.codehaus.org/browse/SUREFIRE-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-130: Assignee: (was: fabrizio giustina) > Support tests written in Jython > --- > > Key: SUREFIRE-130 > URL: http://jira.codehaus.org/browse/SUREFIRE-130 > Project: Maven Surefire > Issue Type: New Feature >Reporter: Charlie Groves > Fix For: Backlog > > Attachments: jythonProvider.tar.gz, jythonProviderTest.tar.gz, > MSUREFIRE-122-maven-surefire-plugin.patch, > MSUREFIRE-122-surefire-providers.patch > > > I've written a first pass at a surefire-provider for JUnit and Python > unittest TestCases written in Jython. Before I continue any further I'd like > to make sure that the provider is wanted and that I'm heading in the right > direction. > To do the minimum to get it up and running, I've hooked into the > maven-surefire-plugin to hook my provider into the system somewhat like the > TestNG provider did. maven-surefire-plugin passes a path(defaults to > src/test/jython) to the provider. The provider searches the path for files > matching include patterns and loads those as Python modules. For every class > in the matching modules that extends junit or unittest TestCase, it makes a > SurefireTestSuite and exposes them for running. Sound like a decent approach? > To give it a spin, apply maven-surefire-plugin.patch, mvn install on the > surefire-jython project and run mvn test in jythonProviderTest. It's just > contains a single Junit testcase with a failing and passing test. > I haven't even checked what happens when the jython tests throw exceptions, > and I know there's alot to be done as far as making it a usable plugin, but I > felt like getting some feedback before continuing. -- 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] Closed: (SUREFIRE-672) Failsafe no longer fails builds due to broken failsafe-summary.xml file
[
http://jira.codehaus.org/browse/SUREFIRE-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-672.
---
Resolution: Fixed
Funny how a failing build once again makes us happy. Shame this one got
through, thanks for testing !
> Failsafe no longer fails builds due to broken failsafe-summary.xml file
> ---
>
> Key: SUREFIRE-672
> URL: http://jira.codehaus.org/browse/SUREFIRE-672
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.7
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Windows XP x86-32
> jvmwi3260sr7-20100219_54049 (JIT enabled, AOT enabled)
> OS name: "windows xp" version: "5.1 build 2600 service pack 3" arch: "x86"
> Family: "windows"
>Reporter: Jan Fredrik Wedén
>Assignee: Kristian Rosenvold
>Priority: Blocker
> Fix For: 2.7.1
>
>
> Upgrading maven-failsafe-plugin from version 2.6 to 2.7 causes builds with
> integration test errors to be reported as successful.
> From my understanding, the failsafe verify goal uses the summary file
> (default: target\failsafe-reports\failsafe-summary.xml) to check whether
> executed integration tests passed or had any errors. I've pasted the content
> of this file below as it is generated by the failsafe plugin version 2.6 and
> 2.7 respectively for the same build with the same integration test errors. It
> appears that the integration-test goal does not generate this file correctly
> in version 2.7.
> {code:title=failsafe plugin v2.6: failsafe-summary.xml|language=XML}
>
>
> {code}
> {code:title=failsafe plugin v2.7: failsafe-summary.xml|language=XML}
>
>
> {code}
> The result for this build is that the failsafe plugin version 2.6 fails the
> build (as it should) while failsafe plugin version 2.7 does not and the build
> is reported as successful.
--
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: (MECLIPSE-453) Generated Eclipse WTP application.xml only correct for J2EE 1.4 version
[ http://jira.codehaus.org/browse/MECLIPSE-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249389#action_249389 ] Anthony O. commented on MECLIPSE-453: - That bug still exists in Eclipse 3.5.2, is there a workaround ? > Generated Eclipse WTP application.xml only correct for J2EE 1.4 version > --- > > Key: MECLIPSE-453 > URL: http://jira.codehaus.org/browse/MECLIPSE-453 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.5.1 > Environment: Windows XP SP3, JDK 1.5.0_14, Eclipse Europa 3.3.2, > Maven 2.0.8 >Reporter: M.-Leander Reimer > Attachments: EclipseWtpApplicationXMLWriter.java, JavaEE5.patch > > > The generated Eclipse WTP application.xml has a hard coded header and does > not respect the actual JEE version used, so for JEE5 the header should look > like the following > http://java.sun.com/xml/ns/javaee"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee > http://java.sun.com/xml/ns/javaee/application_5.xsd"; id="Application_ID" > version="5"> > instead of > http://java.sun.com/xml/ns/j2ee"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee > http://java.sun.com/xml/ns/j2ee/application_1_4.xsd"; id="Application_ID" > version="1.4"> > The required, minimal changes are in the method createNewApplicationXml() in > the class EclipseWtpApplicationXMLWriter.java > Unfortunately I could not compile and test the 2.5.1 source from SVN on my > machine (the plugin unit tests failed), but I attached the changed file > anyway. > Best regards, > Leander -- 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-672) Failsafe no longer fails builds due to broken failsafe-summary.xml file
[
http://jira.codehaus.org/browse/SUREFIRE-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249388#action_249388
]
Jan Fredrik Wedén commented on SUREFIRE-672:
Tested the same build containing failing tests with
maven-failsafe-plugin-2.7.1-20101222.020133-14. The summary file now once again
contains the same stuff as 2.6 produced and the build is failed. Great, thanks!
:)
> Failsafe no longer fails builds due to broken failsafe-summary.xml file
> ---
>
> Key: SUREFIRE-672
> URL: http://jira.codehaus.org/browse/SUREFIRE-672
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.7
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Windows XP x86-32
> jvmwi3260sr7-20100219_54049 (JIT enabled, AOT enabled)
> OS name: "windows xp" version: "5.1 build 2600 service pack 3" arch: "x86"
> Family: "windows"
>Reporter: Jan Fredrik Wedén
>Assignee: Kristian Rosenvold
>Priority: Blocker
> Fix For: 2.7.1
>
>
> Upgrading maven-failsafe-plugin from version 2.6 to 2.7 causes builds with
> integration test errors to be reported as successful.
> From my understanding, the failsafe verify goal uses the summary file
> (default: target\failsafe-reports\failsafe-summary.xml) to check whether
> executed integration tests passed or had any errors. I've pasted the content
> of this file below as it is generated by the failsafe plugin version 2.6 and
> 2.7 respectively for the same build with the same integration test errors. It
> appears that the integration-test goal does not generate this file correctly
> in version 2.7.
> {code:title=failsafe plugin v2.6: failsafe-summary.xml|language=XML}
>
>
> {code}
> {code:title=failsafe plugin v2.7: failsafe-summary.xml|language=XML}
>
>
> {code}
> The result for this build is that the failsafe plugin version 2.6 fails the
> build (as it should) while failsafe plugin version 2.7 does not and the build
> is reported as successful.
--
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
