[jira] Created: (MENFORCER-82) Project site does not provide valid examples
Project site does not provide valid examples Key: MENFORCER-82 URL: http://jira.codehaus.org/browse/MENFORCER-82 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Affects Versions: 1.0-beta-1 Reporter: Stephen Connolly Priority: Minor Attachments: patch.txt The project site does not use apt.vm based pages, so that the example snippets are incorrect. The attached patch will fix the issues after the following moves (damn svn diff for not reporting copies) svn mv enforcer-rules/src/site/apt/requireFilesExist.apt enforcer-rules/src/site/apt/requireFilesExist.apt.vm svn mv enforcer-rules/src/site/apt/requireOS.apt enforcer-rules/src/site/apt/requireOS.apt.vm svn mv enforcer-rules/src/site/apt/requireProperty.apt enforcer-rules/src/site/apt/requireProperty.apt.vm svn mv enforcer-rules/src/site/apt/evaluateBeanshell.apt enforcer-rules/src/site/apt/evaluateBeanshell.apt.vm svn mv enforcer-rules/src/site/apt/alwaysPass.apt enforcer-rules/src/site/apt/alwaysPass.apt.vm svn mv enforcer-rules/src/site/apt/requireFilesSize.apt enforcer-rules/src/site/apt/requireFilesSize.apt.vm svn mv enforcer-rules/src/site/apt/alwaysFail.apt enforcer-rules/src/site/apt/alwaysFail.apt.vm svn mv enforcer-rules/src/site/apt/requireFilesDontExist.apt enforcer-rules/src/site/apt/requireFilesDontExist.apt.vm svn mv enforcer-rules/src/site/apt/noSnapshots.apt enforcer-rules/src/site/apt/noSnapshots.apt.vm svn mv enforcer-rules/src/site/apt/requireNoRepositories.apt enforcer-rules/src/site/apt/requireNoRepositories.apt.vm svn mv enforcer-rules/src/site/apt/requireReleaseVersion.apt enforcer-rules/src/site/apt/requireReleaseVersion.apt.vm svn mv enforcer-rules/src/site/apt/requireJavaVersion.apt enforcer-rules/src/site/apt/requireJavaVersion.apt.vm svn mv enforcer-rules/src/site/apt/requirePluginVersions.apt enforcer-rules/src/site/apt/requirePluginVersions.apt.vm svn mv enforcer-rules/src/site/apt/requireReleaseDeps.apt enforcer-rules/src/site/apt/requireReleaseDeps.apt.vm svn mv enforcer-rules/src/site/apt/bannedDependencies.apt enforcer-rules/src/site/apt/bannedDependencies.apt.vm svn mv enforcer-rules/src/site/apt/requireMavenVersion.apt enforcer-rules/src/site/apt/requireMavenVersion.apt.vm -- 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: (MENFORCER-82) Project site does not provide valid examples
[ http://jira.codehaus.org/browse/MENFORCER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MENFORCER-82. Resolution: Fixed Fix Version/s: 1.0-beta-2 fixed. Thx Project site does not provide valid examples Key: MENFORCER-82 URL: http://jira.codehaus.org/browse/MENFORCER-82 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Affects Versions: 1.0-beta-1 Reporter: Stephen Connolly Assignee: Arnaud Heritier Priority: Minor Fix For: 1.0-beta-2 Attachments: patch.txt The project site does not use apt.vm based pages, so that the example snippets are incorrect. The attached patch will fix the issues after the following moves (damn svn diff for not reporting copies) svn mv enforcer-rules/src/site/apt/requireFilesExist.apt enforcer-rules/src/site/apt/requireFilesExist.apt.vm svn mv enforcer-rules/src/site/apt/requireOS.apt enforcer-rules/src/site/apt/requireOS.apt.vm svn mv enforcer-rules/src/site/apt/requireProperty.apt enforcer-rules/src/site/apt/requireProperty.apt.vm svn mv enforcer-rules/src/site/apt/evaluateBeanshell.apt enforcer-rules/src/site/apt/evaluateBeanshell.apt.vm svn mv enforcer-rules/src/site/apt/alwaysPass.apt enforcer-rules/src/site/apt/alwaysPass.apt.vm svn mv enforcer-rules/src/site/apt/requireFilesSize.apt enforcer-rules/src/site/apt/requireFilesSize.apt.vm svn mv enforcer-rules/src/site/apt/alwaysFail.apt enforcer-rules/src/site/apt/alwaysFail.apt.vm svn mv enforcer-rules/src/site/apt/requireFilesDontExist.apt enforcer-rules/src/site/apt/requireFilesDontExist.apt.vm svn mv enforcer-rules/src/site/apt/noSnapshots.apt enforcer-rules/src/site/apt/noSnapshots.apt.vm svn mv enforcer-rules/src/site/apt/requireNoRepositories.apt enforcer-rules/src/site/apt/requireNoRepositories.apt.vm svn mv enforcer-rules/src/site/apt/requireReleaseVersion.apt enforcer-rules/src/site/apt/requireReleaseVersion.apt.vm svn mv enforcer-rules/src/site/apt/requireJavaVersion.apt enforcer-rules/src/site/apt/requireJavaVersion.apt.vm svn mv enforcer-rules/src/site/apt/requirePluginVersions.apt enforcer-rules/src/site/apt/requirePluginVersions.apt.vm svn mv enforcer-rules/src/site/apt/requireReleaseDeps.apt enforcer-rules/src/site/apt/requireReleaseDeps.apt.vm svn mv enforcer-rules/src/site/apt/bannedDependencies.apt enforcer-rules/src/site/apt/bannedDependencies.apt.vm svn mv enforcer-rules/src/site/apt/requireMavenVersion.apt enforcer-rules/src/site/apt/requireMavenVersion.apt.vm -- 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-120) Unable to generate single report with latest maven-reporting-impl
Unable to generate single report with latest maven-reporting-impl
-
Key: MSHARED-120
URL: http://jira.codehaus.org/browse/MSHARED-120
Project: Maven Shared Components
Issue Type: Bug
Components: maven-reporting-impl
Affects Versions: maven-reporting-impl 2.0.4.2, maven-reporting-impl 2.0.4.1
Reporter: Vincent Siveton
Priority: Blocker
Attachments: reporting.patch
Recently, I fixed several report plugins (changelog, changes etc.) to use Doxia
1.0 and latest maven-reporting-impl.
The main goal was to make reporting plugins available in PDF (see MPDF-26 and
doc [1])
I notified that running a single report doesn't work but works when coupling
with maven-site-plugin 2.0.x.
For instance, run:
{noformat}
mvn org.apache.maven.plugins:maven-changelog-plugin:2.2-SNAPSHOT:changelog
{noformat}
In Doxia 1.0, the SiteRenderSink [2] uses a StringWriter by default to use
getBody() in the renderer [3]. So running a single report doesn't write a file
with reporting-impl:2.0.4.2
In MPIR 2.1.2, we overrided the mojo.execute() to handle a default renderer [4]
so we are able to run a single report. I propose to move this logic in
AbstractMavenReport.
[1]
http://maven.apache.org/plugins/maven-pdf-plugin-1.1-SNAPSHOT/examples/configuring-reports.html#Maven_Reporting_Plugins_Issues
[2]
http://maven.apache.org/doxia/doxia-sitetools-1.0.x/xref/org/apache/maven/doxia/siterenderer/sink/SiteRendererSink.html#47
[3]
http://maven.apache.org/doxia/doxia-sitetools-1.0.x/xref/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.html#433
[4]
http://maven.apache.org/plugins/maven-project-info-reports-plugin/xref/org/apache/maven/report/projectinfo/AbstractProjectInfoReport.html#137
--
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-120) Unable to generate single report with latest maven-reporting-impl
[
http://jira.codehaus.org/browse/MSHARED-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton updated MSHARED-120:
Attachment: MSHARED-120.patch
The MSHARED-120.patch seems better and is backward compatible (only no
resources are available)
Unable to generate single report with latest maven-reporting-impl
-
Key: MSHARED-120
URL: http://jira.codehaus.org/browse/MSHARED-120
Project: Maven Shared Components
Issue Type: Bug
Components: maven-reporting-impl
Affects Versions: maven-reporting-impl 2.0.4.1, maven-reporting-impl
2.0.4.2
Reporter: Vincent Siveton
Priority: Blocker
Attachments: MSHARED-120.patch, reporting.patch
Recently, I fixed several report plugins (changelog, changes etc.) to use
Doxia 1.0 and latest maven-reporting-impl.
The main goal was to make reporting plugins available in PDF (see MPDF-26 and
doc [1])
I notified that running a single report doesn't work but works when coupling
with maven-site-plugin 2.0.x.
For instance, run:
{noformat}
mvn org.apache.maven.plugins:maven-changelog-plugin:2.2-SNAPSHOT:changelog
{noformat}
In Doxia 1.0, the SiteRenderSink [2] uses a StringWriter by default to use
getBody() in the renderer [3]. So running a single report doesn't write a
file with reporting-impl:2.0.4.2
In MPIR 2.1.2, we overrided the mojo.execute() to handle a default renderer
[4] so we are able to run a single report. I propose to move this logic in
AbstractMavenReport.
[1]
http://maven.apache.org/plugins/maven-pdf-plugin-1.1-SNAPSHOT/examples/configuring-reports.html#Maven_Reporting_Plugins_Issues
[2]
http://maven.apache.org/doxia/doxia-sitetools-1.0.x/xref/org/apache/maven/doxia/siterenderer/sink/SiteRendererSink.html#47
[3]
http://maven.apache.org/doxia/doxia-sitetools-1.0.x/xref/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.html#433
[4]
http://maven.apache.org/plugins/maven-project-info-reports-plugin/xref/org/apache/maven/report/projectinfo/AbstractProjectInfoReport.html#137
--
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: (SCM-470) includes do not work with scm:checkout
[ http://jira.codehaus.org/browse/SCM-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=187343#action_187343 ] Boguslaw Osuch commented on SCM-470: Is something gonna to be done in this matter ? Or can anybody tell where to search the bug? includes do not work with scm:checkout -- Key: SCM-470 URL: http://jira.codehaus.org/browse/SCM-470 Project: Maven SCM Issue Type: Bug Components: maven-plugin Affects Versions: 1.1 Reporter: Benson Margulies The includes setting is accepted and ignored, at least with subversion. -- 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-4304) [regression] MavenProject.getDependencyArtifacts() not set
[regression] MavenProject.getDependencyArtifacts() not set
--
Key: MNG-4304
URL: http://jira.codehaus.org/browse/MNG-4304
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories, Plugins and Lifecycle
Affects Versions: 3.0-alpha-3
Reporter: Benjamin Bentmann
While trunk properly calls {{MavenProject.setArtifacts()}},
{{MavenProject.setDependencyArtifacts()}} is never called and causes NPEs is
various plugins.
--
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-4304) [regression] MavenProject.getDependencyArtifacts() not set
[
http://jira.codehaus.org/browse/MNG-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4304.
--
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 3.0-alpha-3
Fixed in [r805008|http://svn.apache.org/viewvc?view=revrevision=805008].
[regression] MavenProject.getDependencyArtifacts() not set
--
Key: MNG-4304
URL: http://jira.codehaus.org/browse/MNG-4304
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories, Plugins and Lifecycle
Affects Versions: 3.0-alpha-3
Reporter: Benjamin Bentmann
Assignee: Benjamin Bentmann
Fix For: 3.0-alpha-3
While trunk properly calls {{MavenProject.setArtifacts()}},
{{MavenProject.setDependencyArtifacts()}} is never called and causes NPEs is
various plugins.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-568) Fork mode of pertest or always does not fork per test or always
Fork mode of pertest or always does not fork per test or always --- Key: SUREFIRE-568 URL: http://jira.codehaus.org/browse/SUREFIRE-568 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.4.3, 2.4.2, 2.4.1, 2.4, 2.3.1, 2.3, 2.0 (2.2 plugin), 2.0 Report Plugin, 1.5.3 (2.1.3 plugin), 1.5.2 (2.1.2 plugin), 1.5.1 (2.1.1 plugin), 1.5 (2.1 plugin), 1.4 (2.0 plugin), 1.3 (2.0-beta-1 plugin) Environment: Windows XP, Java 6 update 14, JUnit 4.6 Reporter: Laird Nelson Perhaps this is a misunderstanding, in which case I'd ask for a clarification in the documentation. If I specify a forkMode of always or pertest (which I understand is the same thing), Surefire will fork for each test *class*, but *not* for each @Test within the test class. The documentation led me to believe that surefire would fork once for each method annotated as @Test. (Background: I'm running OpenEJB and H2, and need to ensure that the in-memory H2 database I have set up is zapped in between each test run so that, among other things, the automated DDL generation re-runs for each test.) -- 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: (MAVENUPLOAD-2563) Please add net.sourceforge.ccxjc to sync.csv
Please add net.sourceforge.ccxjc to sync.csv Key: MAVENUPLOAD-2563 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2563 Project: Maven Upload Requests Issue Type: Task Reporter: Christian Schulte Please add the following repo to http://svn.apache.org/viewvc/maven/repository-tools/trunk/src/bin/synchronize/m2-sync/sync.csv net.sourceforge.ccxjc,mavens...@web.sourceforge.net:/home/groups/c/cc/ccxjc/htdocs/maven2/releases,rsync_ssh,The CC-XJC Project,ccxjc-notificati...@lists.sourceforge.net,, -- 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-4305) [regression] ${localRepository.basedir} is not a proper path
[regression] ${localRepository.basedir} is not a proper path
Key: MNG-4305
URL: http://jira.codehaus.org/browse/MNG-4305
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.0-alpha-3
Reporter: Benjamin Bentmann
In existing Maven versions, calling {{getBasedir()}} on the local repository
returns a proper filesystem path, i.e.
- the path uses the platform-specified file separator
- the path has no trailing separator
Trunk currently violates both of these principles. Plugins that rely on the
specific path format will fail.
--
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-4306) Jetty-client based Wagon
Jetty-client based Wagon Key: MNG-4306 URL: http://jira.codehaus.org/browse/MNG-4306 Project: Maven 2 Issue Type: New Feature Reporter: Jason van Zyl We need a new high performance Wagon that encapsulates all the features of the current HTTP wagons, but will be the single implementation we use going forward. -- 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-4306) Jetty-client based Wagon
[ http://jira.codehaus.org/browse/MNG-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-4306: --- Fix Version/s: 3.0-alpha-4 Jetty-client based Wagon Key: MNG-4306 URL: http://jira.codehaus.org/browse/MNG-4306 Project: Maven 2 Issue Type: New Feature Reporter: Jason van Zyl Fix For: 3.0-alpha-4 We need a new high performance Wagon that encapsulates all the features of the current HTTP wagons, but will be the single implementation we use going forward. -- 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-4306) Jetty-client based Wagon
[ http://jira.codehaus.org/browse/MNG-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-4306: --- Description: We need a new high performance Wagon that encapsulates all the features of the current HTTP wagons, but will be the single implementation we use going forward. Brian's comments on the features of each Wagon right now: Currently the lightweight impl handles NTLMv2 and does a better job caching the data when the repository asks for authentication (this one uses Sun code). The Sun code has bugs that interfere with uuencoding of data in the headers, specifically the passwords. The other wagon uses the httpclient, which doesn't support NTLMv2 and doesn't cache the data, screwing up the stream observers with repos that need auth. It doesn't screw up the data in the headers. So hopefully Jetty will support NTLMv2, be smart about handling authenticated repos and not screw up the data in the headers. was:We need a new high performance Wagon that encapsulates all the features of the current HTTP wagons, but will be the single implementation we use going forward. Jetty-client based Wagon Key: MNG-4306 URL: http://jira.codehaus.org/browse/MNG-4306 Project: Maven 2 Issue Type: New Feature Reporter: Jason van Zyl Assignee: Jesse McConnell Fix For: 3.0-alpha-4 We need a new high performance Wagon that encapsulates all the features of the current HTTP wagons, but will be the single implementation we use going forward. Brian's comments on the features of each Wagon right now: Currently the lightweight impl handles NTLMv2 and does a better job caching the data when the repository asks for authentication (this one uses Sun code). The Sun code has bugs that interfere with uuencoding of data in the headers, specifically the passwords. The other wagon uses the httpclient, which doesn't support NTLMv2 and doesn't cache the data, screwing up the stream observers with repos that need auth. It doesn't screw up the data in the headers. So hopefully Jetty will support NTLMv2, be smart about handling authenticated repos and not screw up the data in the headers. -- 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-4305) [regression] ${localRepository.basedir} is not a proper path
[
http://jira.codehaus.org/browse/MNG-4305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4305.
--
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 3.0-alpha-3
Fixed in [r805061|http://svn.apache.org/viewvc?view=revrevision=805061].
[regression] ${localRepository.basedir} is not a proper path
Key: MNG-4305
URL: http://jira.codehaus.org/browse/MNG-4305
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.0-alpha-3
Reporter: Benjamin Bentmann
Assignee: Benjamin Bentmann
Fix For: 3.0-alpha-3
In existing Maven versions, calling {{getBasedir()}} on the local repository
returns a proper filesystem path, i.e.
- the path uses the platform-specified file separator
- the path has no trailing separator
Trunk currently violates both of these principles. Plugins that rely on the
specific path format will fail.
--
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: (MAVENUPLOAD-2564) Please sync Hibernate Core 3.3.2.GA from JBoss
Please sync Hibernate Core 3.3.2.GA from JBoss -- Key: MAVENUPLOAD-2564 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2564 Project: Maven Upload Requests Issue Type: Bug Reporter: Max Bowsher There is a new version of Hibernate, and automatic syncs from the JBoss repository are still many months off, according to my last conversation with Paul Gier. Therefore, here is a manual sync request. Please sync the following artifactIds, (all within groupId=org.hibernate) from the JBoss repository http://repository.jboss.com/maven2/ : hibernate-parent hibernate-core hibernate-c3p0 hibernate-ehcache hibernate-jbosscache hibernate-jbosscache2 hibernate-jmx hibernate-oscache hibernate-proxool hibernate-swarmcache These artifactIds have previously been synced (all versions available at the time) in response to MAVENUPLOAD-2240 and MAVENUPLOAD-2215. There is now one additional version, 3.3.2.GA, available for all of the above artifactIds. I certify that I have verified that these artifacts have no dependencies not currently found in the central repository, with the exception of hibernate-jbosscache2 - but the versions of hibernate-jbosscache2 currently contained in the central repository do not have their dependencies satisfied either, so this is not a regression. -- 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-4162) Removal of all reporting logic from the core of Maven
[ http://jira.codehaus.org/browse/MNG-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MNG-4162: -- Attachment: MNG-4162.patch merge from branch MNG-4162 Removal of all reporting logic from the core of Maven - Key: MNG-4162 URL: http://jira.codehaus.org/browse/MNG-4162 Project: Maven 2 Issue Type: Improvement Reporter: Jason van Zyl Fix For: 3.0 Attachments: MNG-4162.patch Any reporting implementation will be implemented as a plugin. Maven will provide any information, APIs, and extension points to make this possible. But the conflation of building with reporting in the core makes it almost impossible for anyone two understand the distinction, makes it impossible to have alternate implementations and couple many tools like Doxia directly to the core which is unacceptable for Maven 3.x. -- 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-4307) Properties are not expanded in Plugin execution phase attribute when executed from child project, from parent they are.
Properties are not expanded in Plugin execution phase attribute when executed
from child project, from parent they are.
---
Key: MNG-4307
URL: http://jira.codehaus.org/browse/MNG-4307
Project: Maven 2
Issue Type: Bug
Components: Bootstrap Build
Affects Versions: 2.2.1, 2.2.0
Environment: Centos 5.3 X86
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_17-b04)
Java HotSpot(TM) Client VM (build 1.5.0_17-b04, mixed mode)
Reporter: Jason Pell
Attachments: tests-parent-bug.tar.gz
The attached tarball has the following project structure:
parent-tests/
parent-tests/test/
The parent project has a modules section only.
The tests sub project has a single plugin and execution block. The phase is
a property phase${failsafeIntegrationTestPhase}/phase
The pom has a single property:
--
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-4307) Properties are not expanded in Plugin execution phase attribute when executed from child project, from parent they are.
[
http://jira.codehaus.org/browse/MNG-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=187432#action_187432
]
Jason Pell commented on MNG-4307:
-
Apologies, must have hit the wrong key!
Anyway, the child pom has a single property:
properties
failsafeIntegrationTestPhaseintegration-test/failsafeIntegrationTestPhase
/properties
When I run:
mvn integration-test
From the child directly the failsafe plugin is not executed.
When I run the same command from the parent, the failsafe plugin is executed.
Properties are not expanded in Plugin execution phase attribute when executed
from child project, from parent they are.
---
Key: MNG-4307
URL: http://jira.codehaus.org/browse/MNG-4307
Project: Maven 2
Issue Type: Bug
Components: Bootstrap Build
Affects Versions: 2.2.0, 2.2.1
Environment: Centos 5.3 X86
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_17-b04)
Java HotSpot(TM) Client VM (build 1.5.0_17-b04, mixed mode)
Reporter: Jason Pell
Attachments: tests-parent-bug.tar.gz
The attached tarball has the following project structure:
parent-tests/
parent-tests/test/
The parent project has a modules section only.
The tests sub project has a single plugin and execution block. The phase
is a property phase${failsafeIntegrationTestPhase}/phase
The pom has a single property:
--
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: (MWAR-167) Final manifest not written to exploded location
[ http://jira.codehaus.org/browse/MWAR-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Haikal Saadh updated MWAR-167: -- Attachment: patch.diff Here's a patch that copies a user specified manifest to the correct place when you do war:war. First time working on a maven plugin, so go easy :D Final manifest not written to exploded location --- Key: MWAR-167 URL: http://jira.codehaus.org/browse/MWAR-167 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1-alpha-1 Reporter: Paul Benedict Priority: Minor Attachments: patch.diff When I open up my generated WAR file, the Manifest file contains all the entries I specified. This is correct. However, when I look into the exploded location, it's just the file I had in my project to begin with. The exploded Manifest should be updated with the final contents. -- 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: (MWAR-167) Final manifest not written to exploded location
[ http://jira.codehaus.org/browse/MWAR-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=187442#action_187442 ] Haikal Saadh edited comment on MWAR-167 at 8/17/09 11:10 PM: - Here's a patch that copies a user specified manifest to the correct place when you do war:exploded. First time working on a maven plugin, so go easy :D was (Author: tunaranch): Here's a patch that copies a user specified manifest to the correct place when you do war:war. First time working on a maven plugin, so go easy :D Final manifest not written to exploded location --- Key: MWAR-167 URL: http://jira.codehaus.org/browse/MWAR-167 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1-alpha-1 Reporter: Paul Benedict Priority: Minor Attachments: patch.diff When I open up my generated WAR file, the Manifest file contains all the entries I specified. This is correct. However, when I look into the exploded location, it's just the file I had in my project to begin with. The exploded Manifest should be updated with the final contents. -- 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: (MWAR-167) Final manifest not written to exploded location
[ http://jira.codehaus.org/browse/MWAR-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=187442#action_187442 ] Haikal Saadh edited comment on MWAR-167 at 8/17/09 11:12 PM: - Here's a patch that copies a user specified manifest to the correct place when you do war:exploded. First time working on a maven plugin, so go easy :D patch is against /tags/maven-war-plugin-2.1-beta-1 was (Author: tunaranch): Here's a patch that copies a user specified manifest to the correct place when you do war:exploded. First time working on a maven plugin, so go easy :D Final manifest not written to exploded location --- Key: MWAR-167 URL: http://jira.codehaus.org/browse/MWAR-167 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1-alpha-1 Reporter: Paul Benedict Priority: Minor Attachments: patch.diff When I open up my generated WAR file, the Manifest file contains all the entries I specified. This is correct. However, when I look into the exploded location, it's just the file I had in my project to begin with. The exploded Manifest should be updated with the final contents. -- 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
