[jira] Commented: (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ http://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=226897#action_226897 ] Mark Derricutt commented on MNG-3092: - After getting Maven 3 running again I retried our builds at $work with it, I did like the lack of -SNAPSHOTs being resolved for working with individual artifacts as it drove me to actually release some long standing 'test support' artifacts. And I see a good upside of this would be much more regular releasing of artifacts across the board. However, when it came to running our integration tests, which use the maven-dependency-plugin to copy all of our projects artifacts (listed as test dependencies) to the target directory, and deploy them into an OSGi container, it was apparent that we'd have to drop the use of version ranges and modify the test projects dependencies EVERY TIME one of the projects artifacts changed, as the ranges no longer resolve -SNAPSHOTs. If this change is going to go ahead and stay in maven 3 - is there an alterative way of doing the above, where an integration build wants to pull in all available SNAPSHOT releases. Ideally, I'd love to see this new behavior the default in Maven 3, but with an override setting to add into the maven-dependency-plugin or somewhere to allow for SNAPSHOTs. Mark > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: http://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Mark Hobson > Fix For: 3.0-beta-1 > > Attachments: MNG-3092.patch > > > Contrary to the 2.0 design docs: > "Resolution of dependency ranges should not resolve to a snapshot > (development version) unless it is included as an explicit boundary." > -- from > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification > The following is equates to true: > VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new > DefaultArtifactVersion( "1.1-SNAPSHOT" ) ) > The attached patch only allows snapshot versions to be contained in a range > if they are equal to one of the boundaries. Note that this is a strict > equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- 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: (MECLIPSE-662) WTP 3.2 support
WTP 3.2 support --- Key: MECLIPSE-662 URL: http://jira.codehaus.org/browse/MECLIPSE-662 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Components: WTP support Affects Versions: 2.8, 2.7, 2.6, 2.5.1, 2.5, 2.4, 2.3, 2.2, 2.1, 2.0 Environment: Eclipse Helios Reporter: Diego Gomes Check if there's any change on layout and update it for the WTP 3.2 -- 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-4716) Make the interpolated POM of a released artifact accessible too
Make the interpolated POM of a released artifact accessible too --- Key: MNG-4716 URL: http://jira.codehaus.org/browse/MNG-4716 Project: Maven 2 & 3 Issue Type: Improvement Components: Deployment Reporter: Tamás Cservenák Make the interpolated POM of a released artifact accessible too. Whether embedded into deployed JAR, or next to "real" POM. Reasoning: the interpolated POM is not for "downstream consumers" (build consuming this artifact), but for about "how this build is done". We always argument against this in way that "profiles" and plugin settings (and other things) are lost with interpolated POM. That's true, but again, I'd like to have an interpolated POM of a _released_ artifact that would describe me _how this artifact was built_, and not to be referenced and consumed by others (as dependency or whatever). So, after deploying org.test:foo:1.0. i'd like to have: /org/test/foo/1.0 foo-1.0.pom foo-1.0.pom.interpolated foo-1.0.jar Or something similar (having the interpolated POM embedded in JAR). Not embedding would allow us to "calculate" interpolated poms for already released POMs too. So, ultimately, POM is "changing", yes, but only when it is consumed. But during release, it is frozen, and will stay like that, since all it's parent POM, deps, plugins are released, are not "moving targets" anymore. -- 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-4716) Make the interpolated POM of a released artifact accessible too
[ http://jira.codehaus.org/browse/MNG-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=226941#action_226941 ] Tamás Cservenák commented on MNG-4716: -- If there are better way to describe "how this build (how this very artifact) was built", just explain it, since that's the one thing I am interested in. > Make the interpolated POM of a released artifact accessible too > --- > > Key: MNG-4716 > URL: http://jira.codehaus.org/browse/MNG-4716 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Deployment >Reporter: Tamás Cservenák > > Make the interpolated POM of a released artifact accessible too. Whether > embedded into deployed JAR, or next to "real" POM. > Reasoning: the interpolated POM is not for "downstream consumers" (build > consuming this artifact), but for about "how this build is done". We always > argument against this in way that "profiles" and plugin settings (and other > things) are lost with interpolated POM. That's true, but again, I'd like to > have an interpolated POM of a _released_ artifact that would describe me _how > this artifact was built_, and not to be referenced and consumed by others (as > dependency or whatever). > So, after deploying org.test:foo:1.0. i'd like to have: > /org/test/foo/1.0 > foo-1.0.pom > foo-1.0.pom.interpolated > foo-1.0.jar > Or something similar (having the interpolated POM embedded in JAR). Not > embedding would allow us to "calculate" interpolated poms for already > released POMs too. > So, ultimately, POM is "changing", yes, but only when it is consumed. But > during release, it is frozen, and will stay like that, since all it's parent > POM, deps, plugins are released, are not "moving targets" anymore. -- 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: (MSITE-438) dropped from site.xml for pom.xml without section
[
http://jira.codehaus.org/browse/MSITE-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSITE-438:
Description:
We have common "pom-parent" artifact that defines repositories,
pluginsManagement, distribution, etc. And there is defined the site.xml
descriptor too.
The site.xml lokks like:
{code:xml}
{code}
but when we build this artifact and deploy it to the repository, there is
automaticaly generated and uploaded different site descriptor
"pom-parent-1.0.0-site.xml" that contains only:
{code:xml}
{code}
The "modules" menu was droped by maven.
After some investigation I found that the "modules" menu section is always
dropped, when the pom.xml for pom-parent does not contains any submodule
definition
{code:xml}
some-submodule
{code}
But I don't want to specify any submodule for this common pom because it is
used as "abstract" parent for all company projects. We want to have only one
central site.xml descriptor definition managed in "pom-parent" project and
avoid its duplication in each inherited project.
The workaround is create some "dummy-submodule" under "pom-parent" and define
the section in pom.xml or define the site.xml descriptor for each
inherited project.
was:
We have common "pom-parent" artifact that defines repositories,
pluginsManagement, distribution, etc. And there is defined the site.xml
descriptor too.
The site.xml lokks like:
but when we build this artifact and deploy it to the repository, there is
automaticaly generated and uploaded different site descriptor
"pom-parent-1.0.0-site.xml" that contains only:
The "modules" menu was droped by maven.
After some investigation I found that the "modules" menu section is always
dropped, when the pom.xml for pom-parent does not contains any submodule
definition
some-submodule
But I don't want to specify any submodule for this common pom because it is
used as "abstract" parent for all company projects. We want to have only one
central site.xml descriptor definition managed in "pom-parent" project and
avoid its duplication in each inherited project.
The workaround is create some "dummy-submodule" under "pom-parent" and define
the section in pom.xml or define the site.xml descriptor for each
inherited project.
> dropped from site.xml for pom.xml without
> section
> --
>
> Key: MSITE-438
> URL: http://jira.codehaus.org/browse/MSITE-438
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: inheritance, multi module
>Affects Versions: 2.0.1
> Environment: Windows XP, CentOS Linux, Maven 2.2.1, Sun JDK 1.6.0_u17
>Reporter: Kek
> Attachments: project.zip
>
>
> We have common "pom-parent" artifact that defines repositories,
> pluginsManagement, distribution, etc. And there is defined the site.xml
> descriptor too.
> The site.xml lokks like:
> {code:xml}
>
>
>
> {code}
> but when we build this artifact and deploy it to the repository, there is
> automaticaly generated and uploaded different site descriptor
> "pom-parent-1.0.0-site.xml" that contains only:
> {code:xml}
>
>
> {code}
> The "modules" menu was droped by maven.
> After some investigation I found that the "modules" menu section is always
> dropped, when the pom.xml for pom-parent does not contains any submodule
> definition
> {code:xml}
> some-submodule
>{code}
> But I don't want to specify any submodule for this common pom because it is
> used as "abstract" parent for all company projects. We want to have only one
> central site.xml descriptor definition managed in "pom-parent" project and
> avoid its duplication in each inherited project.
> The workaround is create some "dummy-submodule" under "pom-parent" and define
> the section in pom.xml or define the site.xml descriptor for each
> inherited project.
--
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: (MSITE-465) Add a site:effective-site goal (similar to help:effective-pom)
[
http://jira.codehaus.org/browse/MSITE-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MSITE-465.
---
Resolution: Fixed
Fix Version/s: 3.0-beta-1
2.2
Assignee: Herve Boutemy
done in r959794 for 2.2 and r959796 for 3.x
> Add a site:effective-site goal (similar to help:effective-pom)
> --
>
> Key: MSITE-465
> URL: http://jira.codehaus.org/browse/MSITE-465
> Project: Maven 2.x Site Plugin
> Issue Type: New Feature
>Reporter: Andreas Sewe
>Assignee: Herve Boutemy
>Priority: Minor
> Fix For: 2.2, 3.0-beta-1
>
>
> As the {{site.xml}} descriptor supports, just like the POM, property
> expansion and inheritance, it would be helpful to have a
> {{site:effective-site}} goal that shows the {{site.xml}} after property
> expansion and inheritance.
--
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-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ http://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=226976#action_226976 ] Mark Derricutt commented on MNG-3092: - I thought I'd come up with a work around by deploying my SNAPSHOT's to my local nexus, given that M3 enforces timestamp'd artifacts rather than -SNAPSHOT.jar files. However, as the metadata still says it's a SNAPSHOT the resolution still fails to resolve the artifact. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: http://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Mark Hobson > Fix For: 3.0-beta-1 > > Attachments: MNG-3092.patch > > > Contrary to the 2.0 design docs: > "Resolution of dependency ranges should not resolve to a snapshot > (development version) unless it is included as an explicit boundary." > -- from > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification > The following is equates to true: > VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new > DefaultArtifactVersion( "1.1-SNAPSHOT" ) ) > The attached patch only allows snapshot versions to be contained in a range > if they are equal to one of the boundaries. Note that this is a strict > equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- 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: (MANTRUN-142) Refactor the tasks parameter to simplify integration with Ant
[ http://jira.codehaus.org/browse/MANTRUN-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MANTRUN-142. - Resolution: Fixed Fixed in [r959831|http://svn.apache.org/viewvc?view=revision&revision=959831]. > Refactor the tasks parameter to simplify integration with Ant > - > > Key: MANTRUN-142 > URL: http://jira.codehaus.org/browse/MANTRUN-142 > Project: Maven 2.x Antrun Plugin > Issue Type: Improvement >Reporter: Paul Gier >Assignee: Paul Gier > Fix For: 1.5 > > > The "tasks" parameter should be renamed to "target" since this would better > reflect what it represents. > Also the way the internal Ant target is created could be refactored to > simplify the integration with Ant. -- 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: (MANTRUN-145) Rename ITs so that they describe what they test
Rename ITs so that they describe what they test --- Key: MANTRUN-145 URL: http://jira.codehaus.org/browse/MANTRUN-145 Project: Maven 2.x Antrun Plugin Issue Type: Improvement Reporter: Paul Gier Priority: Minor Several of the current integration tests have non descriptive names like "test1, test2, etc". These should be renamed. -- 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: (MANTRUN-145) Rename ITs so that they describe what they test
[ http://jira.codehaus.org/browse/MANTRUN-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MANTRUN-145: -- Fix Version/s: 1.5 Assignee: Paul Gier > Rename ITs so that they describe what they test > --- > > Key: MANTRUN-145 > URL: http://jira.codehaus.org/browse/MANTRUN-145 > Project: Maven 2.x Antrun Plugin > Issue Type: Improvement >Reporter: Paul Gier >Assignee: Paul Gier >Priority: Minor > Fix For: 1.5 > > > Several of the current integration tests have non descriptive names like > "test1, test2, etc". These should be renamed. -- 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: (MANTRUN-143) Regression: 1.4 does not resolve $(settings.localRepository} or ${localRepository}
[
http://jira.codehaus.org/browse/MANTRUN-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MANTRUN-143:
--
Fix Version/s: 1.5
Assignee: Paul Gier
> Regression: 1.4 does not resolve $(settings.localRepository} or
> ${localRepository}
> --
>
> Key: MANTRUN-143
> URL: http://jira.codehaus.org/browse/MANTRUN-143
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 20:16:01+0100)
> Java version: 1.6.0_20
> Java home: C:\jdk1.6.0_20\jre
> Default locale: en_GB, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: SebbASF
>Assignee: Paul Gier
> Fix For: 1.5
>
> Attachments: pom.xml
>
>
> Antrun 1.4 fails to resolve the properties localRepository and
> settings.localRepository, whereas 1.3 works fine;
> Properties are resolved OK with 1.3:
> {code}
> > mvn -Dantrun.version=1.3
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building anttest
> [INFO]task-segment: [validate]
> [INFO]
>
> [INFO] [antrun:run {execution: default}]
> [INFO] Executing tasks
> [echo] project.version = 1.0-SNAPSHOT
> [echo] antrun.version = 1.3
> [echo] localRepository = Repository[local|file://C:\Documents and
> Settings\User\.m2\repository]
> [echo] settings.localRepository = C:\Documents and
> Settings\User\.m2\repository
> [INFO] Executed tasks
> {code}
> Properties are not resolved when running with 1.4:
> {code}
> > mvn -Dantrun.version=1.4
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building anttest
> [INFO]task-segment: [validate]
> [INFO]
>
> [INFO] [antrun:run {execution: default}]
> project.artifactId
> [INFO] Executing tasks
> [echo] project.version = 1.0-SNAPSHOT
> [echo] antrun.version = 1.4
> [echo] localRepository = ${localRepository}
> [echo] settings.localRepository = ${settings.localRepository}
> [INFO] Executed tasks
> {code}
--
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: (MANTRUN-145) Rename ITs so that they describe what they test
[ http://jira.codehaus.org/browse/MANTRUN-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MANTRUN-145. - Resolution: Fixed Fixed in [r959834|http://svn.apache.org/viewvc?view=revision&revision=959834]. > Rename ITs so that they describe what they test > --- > > Key: MANTRUN-145 > URL: http://jira.codehaus.org/browse/MANTRUN-145 > Project: Maven 2.x Antrun Plugin > Issue Type: Improvement >Reporter: Paul Gier >Assignee: Paul Gier >Priority: Minor > Fix For: 1.5 > > > Several of the current integration tests have non descriptive names like > "test1, test2, etc". These should be renamed. -- 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: (MANTRUN-144) Debug info being thrown in System.out.println
[ http://jira.codehaus.org/browse/MANTRUN-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MANTRUN-144: -- Fix Version/s: 1.5 Assignee: Paul Gier > Debug info being thrown in System.out.println > - > > Key: MANTRUN-144 > URL: http://jira.codehaus.org/browse/MANTRUN-144 > Project: Maven 2.x Antrun Plugin > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Johann Reyes >Assignee: Paul Gier >Priority: Trivial > Fix For: 1.5 > > Attachments: MANTRUN-144.patch > > > There is a line of code that instead of using getLog().debug, > System.out.println is being used. -- 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: (MANTRUN-144) Debug info being thrown in System.out.println
[ http://jira.codehaus.org/browse/MANTRUN-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MANTRUN-144. - Resolution: Fixed Fixed in [r959835|http://svn.apache.org/viewvc?view=revision&revision=959835]. Thanks for the patch! > Debug info being thrown in System.out.println > - > > Key: MANTRUN-144 > URL: http://jira.codehaus.org/browse/MANTRUN-144 > Project: Maven 2.x Antrun Plugin > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Johann Reyes >Assignee: Paul Gier >Priority: Trivial > Fix For: 1.5 > > Attachments: MANTRUN-144.patch > > > There is a line of code that instead of using getLog().debug, > System.out.println is being used. -- 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: (MANTRUN-146) Some refactoring seems to have broken the plugin with Maven 3
[
http://jira.codehaus.org/browse/MANTRUN-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MANTRUN-146:
--
Fix Version/s: 1.5
Assignee: Paul Gier
> Some refactoring seems to have broken the plugin with Maven 3
> -
>
> Key: MANTRUN-146
> URL: http://jira.codehaus.org/browse/MANTRUN-146
> Project: Maven 2.x Antrun Plugin
> Issue Type: Improvement
>Reporter: Paul Gier
>Assignee: Paul Gier
>Priority: Blocker
> Fix For: 1.5
>
>
> After some refactoring done in MANTRUN-142, the plugin no longer works in
> Maven 3.
> {quote}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:1.5-SNAPSHOT:run (default-cli)
> on project antrun-plugin-test: Execution default-cli of goal
> org.apache.maven.plugins:maven-antrun-plugin:1.5-SNAPSHOT:run failed: An API
> incompatibility was encountered while executing
> org.apache.maven.plugins:maven-antrun-plugin:1.5-SNAPSHOT:run:
> java.lang.NoSuchMethodError:
> org.codehaus.plexus.configuration.xml.XmlPlexusConfiguration.getXpp3Dom()Lorg/codehaus/plexus/util/xml/Xpp3Dom;
> {quote}
--
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: (MANTRUN-146) Some refactoring seems to have broken the plugin with Maven 3
Some refactoring seems to have broken the plugin with Maven 3
-
Key: MANTRUN-146
URL: http://jira.codehaus.org/browse/MANTRUN-146
Project: Maven 2.x Antrun Plugin
Issue Type: Improvement
Reporter: Paul Gier
Priority: Blocker
After some refactoring done in MANTRUN-142, the plugin no longer works in Maven
3.
{quote}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-antrun-plugin:1.5-SNAPSHOT:run (default-cli) on
project antrun-plugin-test: Execution default-cli of goal
org.apache.maven.plugins:maven-antrun-plugin:1.5-SNAPSHOT:run failed: An API
incompatibility was encountered while executing
org.apache.maven.plugins:maven-antrun-plugin:1.5-SNAPSHOT:run:
java.lang.NoSuchMethodError:
org.codehaus.plexus.configuration.xml.XmlPlexusConfiguration.getXpp3Dom()Lorg/codehaus/plexus/util/xml/Xpp3Dom;
{quote}
--
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: (MANTRUN-143) Regression: 1.4 does not resolve $(settings.localRepository} or ${localRepository}
[
http://jira.codehaus.org/browse/MANTRUN-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MANTRUN-143.
-
Resolution: Fixed
Fixed in [r959842|http://svn.apache.org/viewvc?view=revision&revision=959842].
> Regression: 1.4 does not resolve $(settings.localRepository} or
> ${localRepository}
> --
>
> Key: MANTRUN-143
> URL: http://jira.codehaus.org/browse/MANTRUN-143
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 20:16:01+0100)
> Java version: 1.6.0_20
> Java home: C:\jdk1.6.0_20\jre
> Default locale: en_GB, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: SebbASF
>Assignee: Paul Gier
> Fix For: 1.5
>
> Attachments: pom.xml
>
>
> Antrun 1.4 fails to resolve the properties localRepository and
> settings.localRepository, whereas 1.3 works fine;
> Properties are resolved OK with 1.3:
> {code}
> > mvn -Dantrun.version=1.3
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building anttest
> [INFO]task-segment: [validate]
> [INFO]
>
> [INFO] [antrun:run {execution: default}]
> [INFO] Executing tasks
> [echo] project.version = 1.0-SNAPSHOT
> [echo] antrun.version = 1.3
> [echo] localRepository = Repository[local|file://C:\Documents and
> Settings\User\.m2\repository]
> [echo] settings.localRepository = C:\Documents and
> Settings\User\.m2\repository
> [INFO] Executed tasks
> {code}
> Properties are not resolved when running with 1.4:
> {code}
> > mvn -Dantrun.version=1.4
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building anttest
> [INFO]task-segment: [validate]
> [INFO]
>
> [INFO] [antrun:run {execution: default}]
> project.artifactId
> [INFO] Executing tasks
> [echo] project.version = 1.0-SNAPSHOT
> [echo] antrun.version = 1.4
> [echo] localRepository = ${localRepository}
> [echo] settings.localRepository = ${settings.localRepository}
> [INFO] Executed tasks
> {code}
--
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: (MANTRUN-146) Some refactoring seems to have broken the plugin with Maven 3
[
http://jira.codehaus.org/browse/MANTRUN-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MANTRUN-146.
-
Resolution: Fixed
Fixed in [r959858|http://svn.apache.org/viewvc?view=revision&revision=959858].
> Some refactoring seems to have broken the plugin with Maven 3
> -
>
> Key: MANTRUN-146
> URL: http://jira.codehaus.org/browse/MANTRUN-146
> Project: Maven 2.x Antrun Plugin
> Issue Type: Improvement
>Reporter: Paul Gier
>Assignee: Paul Gier
>Priority: Blocker
> Fix For: 1.5
>
>
> After some refactoring done in MANTRUN-142, the plugin no longer works in
> Maven 3.
> {quote}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:1.5-SNAPSHOT:run (default-cli)
> on project antrun-plugin-test: Execution default-cli of goal
> org.apache.maven.plugins:maven-antrun-plugin:1.5-SNAPSHOT:run failed: An API
> incompatibility was encountered while executing
> org.apache.maven.plugins:maven-antrun-plugin:1.5-SNAPSHOT:run:
> java.lang.NoSuchMethodError:
> org.codehaus.plexus.configuration.xml.XmlPlexusConfiguration.getXpp3Dom()Lorg/codehaus/plexus/util/xml/Xpp3Dom;
> {quote}
--
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: (MANTRUN-132) Allow the antrun plugin to set the namespace for the built in tasks.
[ http://jira.codehaus.org/browse/MANTRUN-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MANTRUN-132: -- Description: The antrun plugin should allow the user to configure the xml namespace used for the built in custom tasks. This will allow the user to avoid potential task name conflicts. (was: The antrun plugin should allow the user to configure the xml namespace to be used for the tasks, so that task name conflicts can be avoided. This may involve some refactoring of the way the antrun plugin currently builds the Ant project and the tasks from the plugin configuration.) Fix Version/s: 1.5 Assignee: Paul Gier > Allow the antrun plugin to set the namespace for the built in tasks. > > > Key: MANTRUN-132 > URL: http://jira.codehaus.org/browse/MANTRUN-132 > Project: Maven 2.x Antrun Plugin > Issue Type: Improvement >Reporter: Paul Gier >Assignee: Paul Gier >Priority: Minor > Fix For: 1.5 > > > The antrun plugin should allow the user to configure the xml namespace used > for the built in custom tasks. This will allow the user to avoid potential > task name conflicts. -- 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: (MANTRUN-119) copy task does not respect failonerror=false
[
http://jira.codehaus.org/browse/MANTRUN-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MANTRUN-119:
--
Fix Version/s: 1.5
Assignee: Paul Gier
> copy task does not respect failonerror=false
>
>
> Key: MANTRUN-119
> URL: http://jira.codehaus.org/browse/MANTRUN-119
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.3
> Environment: Maven 2.2.1,
> jRockit (Java 6)
>Reporter: René Zanner
>Assignee: Paul Gier
>Priority: Blocker
> Fix For: 1.5
>
>
> When defining a copy task, the antrun plugin propagates it's failure although
> "failonerror" is set to true: the maven build stops.
> In my case I try to copy a file which does not exist in some maven build
> situations. The build should not fail but try to copy a different file
> instead. With antrun 1.2 it still works (the build continues with the next
> copy task), but with the current version the build fails.
>
>
>
> tofile="${project.build.directory}/model.xml" overwrite="true" verbose="true"
> failonerror="false" />
>
>file="${project.build.directory}/dependency/model-${project.version}.xmi"
> tofile="${project.build.directory}/model.xml" overwrite="true" verbose="true"
> failonerror="false" />
>
>
--
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: (MANTRUN-119) copy task does not respect failonerror=false
[
http://jira.codehaus.org/browse/MANTRUN-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MANTRUN-119.
-
Resolution: Cannot Reproduce
I wasn't able to reproduce this using antrun 1.3 or the current trunk.
I added an integration test in
[r959863|http://svn.apache.org/viewvc?view=revision&revision=959863].
> copy task does not respect failonerror=false
>
>
> Key: MANTRUN-119
> URL: http://jira.codehaus.org/browse/MANTRUN-119
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.3
> Environment: Maven 2.2.1,
> jRockit (Java 6)
>Reporter: René Zanner
>Assignee: Paul Gier
>Priority: Blocker
> Fix For: 1.5
>
>
> When defining a copy task, the antrun plugin propagates it's failure although
> "failonerror" is set to true: the maven build stops.
> In my case I try to copy a file which does not exist in some maven build
> situations. The build should not fail but try to copy a different file
> instead. With antrun 1.2 it still works (the build continues with the next
> copy task), but with the current version the build fails.
>
>
>
> tofile="${project.build.directory}/model.xml" overwrite="true" verbose="true"
> failonerror="false" />
>
>file="${project.build.directory}/dependency/model-${project.version}.xmi"
> tofile="${project.build.directory}/model.xml" overwrite="true" verbose="true"
> failonerror="false" />
>
>
--
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: (MANT-62) Prevent passwords (or any 'secret' data) to go into maven-build.properties
[ http://jira.codehaus.org/browse/MANT-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier moved MANTRUN-134 to MANT-62: --- Affects Version/s: (was: 1.4) (was: 1.3) (was: 1.2) (was: 1.1) (was: 1.0) Key: MANT-62 (was: MANTRUN-134) Project: Maven 2.x Ant Plugin (was: Maven 2.x Antrun Plugin) > Prevent passwords (or any 'secret' data) to go into maven-build.properties > -- > > Key: MANT-62 > URL: http://jira.codehaus.org/browse/MANT-62 > Project: Maven 2.x Ant Plugin > Issue Type: Wish > Environment: NA > (FYI: eclipse, maven 2, windows) >Reporter: Etienne > > Hi, > I'm the main developper of jupload, an open-source project hosted on > sourceforge. (FYI: an applet, which helps sending files to the server). > This applet needs to be signed, thus I need to store on the local > configuration two properties: the file containing the keystore, and its > password. In my case, these properties are stored in a specific profilen > named 'jupload', in the settings.xml. > These properties must remain secret. > I currently want to use your (nice!) ant plugin, to allow non mavenized > users to work on the applet. > But ... > ... when using the ant:ant goal, all available properties are stored into the > maven-build.properties file. So I must be careful, not to through my keystore > password away. > So, my wish is: have a way to hide 'secret' properties. > I see several way to do this, without knowing what is feasible: > 1) Prevent the ant:ant goal to capture properties. These properties could be > managed like the build.xml file: have a maven-build.properties (with maven > and project properties), and another properties file. This last file would be > created once, like the build.properties, and would be overriden only with a > specific configuration parameter, like the build.xml file. > 2) Disallow the profile 'jupload', which contain the password. Would be the > better, as it would also work if I create additionnaly properties there. > 3) Allow to undefine properties. A message could be add into the > maven-build.properties, to list the properties that must be defined locally, > as an ant property for instance. > 4) Have a way to filter properties, based on their name or by a regular > expression (like jupload.* for instance) > Etienne -- 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: (MANTRUN-112) Two different kind of copy tasks lead to an error
[ http://jira.codehaus.org/browse/MANTRUN-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=226992#action_226992 ] Paul Gier commented on MANTRUN-112: --- I wasn't able to reproduce this, are you still having this error? Which version of Maven and the antrun plugin are you using? > Two different kind of copy tasks lead to an error > - > > Key: MANTRUN-112 > URL: http://jira.codehaus.org/browse/MANTRUN-112 > Project: Maven 2.x Antrun Plugin > Issue Type: Bug > Environment: Windows Vista, Java 6 >Reporter: Linda van der Pal > Attachments: ProfilesFromPOM.txt, stacktrace.txt > > > If I use both a copy task that copies a file and renames it: > > AND a copy task that copies a bunch of files to another directory: > > > > I get an exception that tells me I can't use both tofile and todir. Since I > don't use them both in the same task, this should not happen. I'll include > both the stacktrace and the profile that I've put in my POM to test this in > attachments. -- 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
