[jira] Commented: (MRELEASE-457) Non sparse-checkout SCM support
[ http://jira.codehaus.org/browse/MRELEASE-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=243380#action_243380 ] Mark Struberg commented on MRELEASE-457: Hi Olivier! Please also check Grants comment with the projectPath. Hi is right that I (mis-?) used an existing parameter for passing the information about the found child pom. Otoh I think changing the project path is also not the correct way. To be completely clean, we probably need to introduce a new parameter. But not sure if this is really needed - that's why I didn't commit it myself but asked for reviews ;) LieGrue, strub Non sparse-checkout SCM support --- Key: MRELEASE-457 URL: http://jira.codehaus.org/browse/MRELEASE-457 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: perform, scm Affects Versions: 2.0 Reporter: Mark Struberg Assignee: Olivier Lamy Fix For: 2.2 Attachments: MRELEASE-457.2.patch, MRELEASE-457.patch Some SCMs like GIT, Mercurial, Bazaar, BitKeeper, Darcs, and Monotone doesn't support sparse checkouts (checkout of a single subdirectory). So while doing a mvn release:perform in a sub-module, we will always get the _whole_ project checked out into target/checkout! For doing the clean build from this checkout, we have to implement a functionality to find the right submodule first. -- 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: (MDOCCK-20) Make the plugin understand Maven 3.x style configuration of reporting plugins
Make the plugin understand Maven 3.x style configuration of reporting plugins
-
Key: MDOCCK-20
URL: http://jira.codehaus.org/browse/MDOCCK-20
Project: Maven 2.x Documentation Checker Plugin
Issue Type: Improvement
Affects Versions: 1.0
Reporter: Andreas Sewe
Currently, the {{maven-docck-plugin}} searches only the {{reporting}} section
for reporting plugins. As of Maven 3.x, however, this is no longer the proper
place to look for such plugins (like the {{maven-javadoc-plugin}} or the
{{maven-jxr-plugin}}. Rather, the plugin needs to understand the
{{reportPlugins}} configuration of the {{maven-site-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: (MPIR-206) Generalize configuration for text reports
[ http://jira.codehaus.org/browse/MPIR-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MPIR-206: - Component/s: summary scm project-team plugin-management license issue-tracking index dependency-management dependency-convergence dependencies cim Summary: Generalize configuration for text reports (was: Improve configuration of mailing list header text.) Generalize configuration for text reports - Key: MPIR-206 URL: http://jira.codehaus.org/browse/MPIR-206 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Components: cim, dependencies, dependency-convergence, dependency-management, index, issue-tracking, license, mailing-list, plugin-management, project-team, scm, summary Reporter: Olivier Lamy Fix For: 2.2 Attachments: MPIR-206.txt The generated mailing list report has a header which provides basic info on the page. However, in some cases this information is not enough. For example, some lists may not allow posting; it would be useful to be able to explain why. In the case of Apache Commons, the lists are shared, so users need to add a prefix to the subject line. There are no doubt other use cases. It would be useful to be able to override the introduction. -- 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-459) releaseProfiles has no effect without passing profiles in the command line
[
http://jira.codehaus.org/browse/MRELEASE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=243393#action_243393
]
Torsten Reinhard commented on MRELEASE-459:
---
I ran into a comparable problem:
I´ve had a 'local' profile, which was activated by default.
At mvn release:perform I want the profile 'release' to be activated - but what
happened was that both profiles ('local' and 'release') were activated, trying
to set the same variable.
My solution was, to remove the 'local' profile, which was activated by default
before.
but then, at mvn release:perform no more profiles got activated:
[DEBUG] Executing: cmd.exe /X /C C:\eap\apache-maven-2.2.1\bin\mvn.bat -X -D
maven.repo.local=D:\mavenrepo -f maven-release-test -D performRelease=true
deploy site-deploy
= So i now added a 'dummy' profile that is activated by default, but does
nothing:
[DEBUG] Executing: cmd.exe /X /C C:\eap\apache-maven-2.2.1\bin\mvn.bat -X -D
maven.repo.local=D:\mavenrepo -f maven-release-test -D performRelease=true -P
dummy,release deploy site-deploy
using this workaround, I got my 'release' profile to work - after spending some
hours with this issuePlease, fix that in one of the next releases or give a
hint in the documentation.
Thanx, Torsten
releaseProfiles has no effect without passing profiles in the command line
---
Key: MRELEASE-459
URL: http://jira.codehaus.org/browse/MRELEASE-459
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.0-beta-8, 2.0-beta-9
Reporter: Andreas Christoforides
Attachments: patch.txt
The releaseProfiles parameter on the perform goal is not taken into
consideration when no other profiles are passed in the command line. In other
words, the current code only uses the value of the parameter if you have
additional profiles passed in.
Example:
mvn release:perform -P someProfile (uses releaseProfiles value)
mvn release:perform (does NOT use releaseProfiles value)
The plugin should use the parameter even if no other profiles are passed. It
should actually encourage release profiles configured in your POM as opposed
to arbitrary profiles passed in the command line.
I have included a patch that uses the releaseProfiles parameter regardless of
any profiles passed in the command line.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPIR-206) Generalize configuration for text reports
[ http://jira.codehaus.org/browse/MPIR-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPIR-206. Resolution: Fixed Fix Version/s: (was: 2.2) 2.3 Assignee: Vincent Siveton fixed in r1035985, snapshot deployed Generalize configuration for text reports - Key: MPIR-206 URL: http://jira.codehaus.org/browse/MPIR-206 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Components: cim, dependencies, dependency-convergence, dependency-management, index, issue-tracking, license, mailing-list, plugin-management, project-team, scm, summary Reporter: Olivier Lamy Assignee: Vincent Siveton Fix For: 2.3 Attachments: MPIR-206.txt The generated mailing list report has a header which provides basic info on the page. However, in some cases this information is not enough. For example, some lists may not allow posting; it would be useful to be able to explain why. In the case of Apache Commons, the lists are shared, so users need to add a prefix to the subject line. There are no doubt other use cases. It would be useful to be able to override the introduction. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-614) releaseProfiles works only if at least one (default) profile is activated in the same pom.xml
releaseProfiles works only if at least one (default) profile is activated in
the same pom.xml
-
Key: MRELEASE-614
URL: http://jira.codehaus.org/browse/MRELEASE-614
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.0
Environment: WindowsXP, Maven-2.2.1
Reporter: Torsten Reinhard
related to MRELEASE-459 I decided to define an empty dummy profile, which is
activated by default instead of passing -P... at the command line at mvn
release:perform.
I´ve put this into our company parent pom.xml, next to the release profile that
might be enabled during mvn release:perform:
profiles
!-- default profile is needed, because otherwise mvn release:perform
will not activate the release profile --
!-- see http://jira.codehaus.org/browse/MRELEASE-459 for details--
profile
iddummy/id
activation
activeByDefaulttrue/activeByDefault
/activation
/profile
profile
idrelease/id
properties
!-- could be used at mvn release:perform --
!-- will set productVersion to the current
(released)project.scm.tag --
productVersion${project.scm.tag}/productVersion
/properties
/profile
Than, in one child module I configured the maven-release-plugin as:
configuration
workingDirectoryc:\LocalViewsRelease\${project.artifactId}-${project.version}/workingDirectory
preparationGoalsclean install/preparationGoals
releaseProfilesrelease/releaseProfiles
/configuration
= this should activate the dummy profile (which is activated by default) and
the release profile - but it does NOT !
[DEBUG] Executing: cmd.exe /X /C C:\eap\apache-maven-2.2.1\bin\mvn.bat -X -D
maven.repo.local=D:\mavenrepo -D performRelease=true deploy site-deploy
I could only get this to work copying the dummy profile again into the child
pom.xml.
[DEBUG] Executing: cmd.exe /X /C C:\eap\apache-maven-2.2.1\bin\mvn.bat -X -D
maven.repo.local=D:\mavenrepo -D performRelease=true -P dummy,release deploy
site-deploy
The fix should:
- fix MRELEASE-459 first, so no more default profile is needed to get
releaseProfiles to work
- fix the inheritance of (default) profiles during mvn release:perform
--
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-4899) strange behavior during the dependency resolution
strange behavior during the dependency resolution - Key: MNG-4899 URL: http://jira.codehaus.org/browse/MNG-4899 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Reporter: Raffaele Verre Running mvn compile I have this error: Couldn't find a version in [2.0.0-alpha-14, 2.0.0-alpha-15, 2.0.0-alpha-16] to match range [2.0.0-alpha-1,) Is correct? Look strange 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] Closed: (MNG-4899) strange behavior during the dependency resolution
[ http://jira.codehaus.org/browse/MNG-4899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4899. -- Resolution: Duplicate Assignee: Benjamin Bentmann strange behavior during the dependency resolution - Key: MNG-4899 URL: http://jira.codehaus.org/browse/MNG-4899 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Reporter: Raffaele Verre Assignee: Benjamin Bentmann Running mvn compile I have this error: Couldn't find a version in [2.0.0-alpha-14, 2.0.0-alpha-15, 2.0.0-alpha-16] to match range [2.0.0-alpha-1,) Is correct? Look strange 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] Created: (MRELEASE-615) release:branch and release:perform overwrites existing branch/version
release:branch and release:perform overwrites existing branch/version -- Key: MRELEASE-615 URL: http://jira.codehaus.org/browse/MRELEASE-615 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Reporter: Chaitanya Gogineni Create a branch from the trunk using command mvn -DdevelopmentVersion=0.0.3-SNAPSHOT -DbranchName=testBranch release:branch The above command creates a branch under svn/branches/testBranch. then perform a release mvn release:prepare release:perform with release version 1.0.0 Creates artifacts with version 1.0.0 and uploads them to the repository. I run the same command again the next day mvn -DdevelopmentVersion=0.0.3-SNAPSHOT -DbranchName=testBranch release:branch mvn release:prepare release:perform It overwrites the files in the existing branch svn/branches/testBranch and also overwrites the existing released artifacts in the repository. The release:branch should thrown an error saying branch with the name already exists or there should be an overwrite parameter (with default false) to indicate if we want to overwrite. Error should be thrown if the release version for artifacts already exists in the repository. This check should happen under release:prepare phase. -- 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] Reopened: (MNG-4899) strange behavior during the dependency resolution
[ http://jira.codehaus.org/browse/MNG-4899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raffaele Verre reopened MNG-4899: - Sorry David Julian says: Maven recognizes versions that match the following pattern: A.B.C-D or A.B.C-foo where: A is the Major Version, B is the Minor Version, C is the Incremental Version (also known as Bug Fix), D is the Build Number, and 'foo' is the Qualifier. A, B, C, and D, are compared numerically and the qualifier is a string compare. A version may only have a build number or a qualifier, not both. The numbers are considered zero if not present i.e., 1.1 is the same as 1.1.0 and 1.1-0. in http://docs.codehaus.org/display/MAVEN/Versioning: 1.0-alpha-10 ==? 1.0-alpha-2: 10 2, so '1.0-alpha-10' is newer 1.0 and 1.0.0 for Maven are the same so 1.0.0-alpha-10 is newer than 1.0.0-alpha-2 so I don't understand why I have this error: Couldn't find a version in [2.0.0-alpha-14, 2.0.0-alpha-15, 2.0.0-alpha-16] to match range [2.0.0-alpha-1,) Why 2.0.0-alpha-16 is not newer than 2.0.0-alpha-1? strange behavior during the dependency resolution - Key: MNG-4899 URL: http://jira.codehaus.org/browse/MNG-4899 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Reporter: Raffaele Verre Assignee: Benjamin Bentmann Running mvn compile I have this error: Couldn't find a version in [2.0.0-alpha-14, 2.0.0-alpha-15, 2.0.0-alpha-16] to match range [2.0.0-alpha-1,) Is correct? Look strange 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] Closed: (MNG-4899) strange behavior during the dependency resolution
[ http://jira.codehaus.org/browse/MNG-4899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4899. -- Resolution: Duplicate It's known bug, see the linked issue. strange behavior during the dependency resolution - Key: MNG-4899 URL: http://jira.codehaus.org/browse/MNG-4899 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Reporter: Raffaele Verre Assignee: Benjamin Bentmann Running mvn compile I have this error: Couldn't find a version in [2.0.0-alpha-14, 2.0.0-alpha-15, 2.0.0-alpha-16] to match range [2.0.0-alpha-1,) Is correct? Look strange 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] Updated: (SCM-508) Wrong scm url validation for mercurial provider
[
http://jira.codehaus.org/browse/SCM-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laurent Perez updated SCM-508:
--
Attachment: SCM-508-maven-scm-provider-hg.patch
Please find an attached path with the file:// fix, this will allow Windows
users to release on local repositories like :
{code}
scm
connectionscm:hg:file://c/devhome/projects/maven/repo//connection
developerConnectionscm:hg:file://c/devhome/projects/maven/repo//developerConnection
/scm
{code}
Wrong scm url validation for mercurial provider
---
Key: SCM-508
URL: http://jira.codehaus.org/browse/SCM-508
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-mercurial (hg)
Reporter: Alexander Nemish
Attachments: SCM-508-maven-scm-provider-hg.patch
According to documentation (http://maven.apache.org/scm/mercurial.html) scm
url can be of this form:
scm:hg:file://C:/dev/project/v3
but it doesn't work due to a bug in
https://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.2/maven-scm-providers/maven-scm-provider-hg/src/main/java/org/apache/maven/scm/provider/hg/HgScmProvider.java
private HgUrlParserResult parseScmUrl( String scmSpecificUrl )
line 104: if ( !url.startsWith( file:/// ) !url.startsWith(
file://localhost/ ) )
The fix might be the following (like in svn provider)
line 104: if ( !url.startsWith( file:// ) !url.startsWith(
file://localhost/ ) )
--
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: (DOXIA-418) Inject the Doxia version from the POM into AbstractXmlParser
Inject the Doxia version from the POM into AbstractXmlParser Key: DOXIA-418 URL: http://jira.codehaus.org/browse/DOXIA-418 Project: Maven Doxia Issue Type: Improvement Components: Core Affects Versions: 1.1.4 Reporter: Dennis Lundberg Quoting Brett: bq. No need to re-roll the release, but I'd set the version by extracting it from the pom.properties file (if it exists) instead of hardcoding it. -- 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-508) Wrong scm url validation for mercurial provider
[ http://jira.codehaus.org/browse/SCM-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=243434#action_243434 ] Dennis Lundberg commented on SCM-508: - It is the documentation that is wrong. The correct URL for a local Windows path should be: scm:hg:file:///C:/dev/project/v3 Note the 3 slashes after file: instead of 2. Wrong scm url validation for mercurial provider --- Key: SCM-508 URL: http://jira.codehaus.org/browse/SCM-508 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-mercurial (hg) Reporter: Alexander Nemish Attachments: SCM-508-maven-scm-provider-hg.patch According to documentation (http://maven.apache.org/scm/mercurial.html) scm url can be of this form: scm:hg:file://C:/dev/project/v3 but it doesn't work due to a bug in https://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.2/maven-scm-providers/maven-scm-provider-hg/src/main/java/org/apache/maven/scm/provider/hg/HgScmProvider.java private HgUrlParserResult parseScmUrl( String scmSpecificUrl ) line 104: if ( !url.startsWith( file:/// ) !url.startsWith( file://localhost/ ) ) The fix might be the following (like in svn provider) line 104: if ( !url.startsWith( file:// ) !url.startsWith( file://localhost/ ) ) -- 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-4900) Unresolveable build extension when using shade plugin and repositories in profile
Unresolveable build extension when using shade plugin and repositories in
profile
---
Key: MNG-4900
URL: http://jira.codehaus.org/browse/MNG-4900
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies, Settings
Affects Versions: 3.0
Environment: This problem does not occur in Maven 3.0-beta-2 and
earlier. It only occurs in Maven 3.0-beta-3 and Maven 3.0
Reporter: Paul Gier
Attachments: build.log, pom.xml
There seems to be a problem when the shade plugin tries to resolve plugin
extensions using a repository specified in a profile (either in the pom or
settings.xml). It only tries to resolve from central. I attached a sample pom
to reproduce the problem, and the build output.
The problem can be seen by running the package goal in Maven 3.0.
{noformat}mvn clean package -Pjboss-public{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-616) release:rollback does not honor -DcommitByProject
release:rollback does not honor -DcommitByProject - Key: MRELEASE-616 URL: http://jira.codehaus.org/browse/MRELEASE-616 Project: Maven 2.x Release Plugin Issue Type: Bug Components: rollback Affects Versions: 2.1 Reporter: Steven Schlansker MRELEASE-168 added a commitByProject flag to release:prepare for situations where you have a project layout proj/ mod1/ mod2/ where proj, mod1, mod2 are all different SCM repositories. Effectively, instead of doing commit proj/pom.xml proj/mod1/pom.xml proj/mod2/pom.xml it will run commit proj/pom.xml commit proj/mod1/pom.xml commit proj/mod2/pom.xml This works great, but release:rollback doesn't know about this and still tries to commit them all in one go, which fails if they are different source repositories. -- 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: (SCM-508) Wrong scm url validation for mercurial provider
[ http://jira.codehaus.org/browse/SCM-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-508: - Fix Version/s: 1.5 Wrong scm url validation for mercurial provider --- Key: SCM-508 URL: http://jira.codehaus.org/browse/SCM-508 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-mercurial (hg) Reporter: Alexander Nemish Fix For: 1.5 Attachments: SCM-508-maven-scm-provider-hg.patch According to documentation (http://maven.apache.org/scm/mercurial.html) scm url can be of this form: scm:hg:file://C:/dev/project/v3 but it doesn't work due to a bug in https://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.2/maven-scm-providers/maven-scm-provider-hg/src/main/java/org/apache/maven/scm/provider/hg/HgScmProvider.java private HgUrlParserResult parseScmUrl( String scmSpecificUrl ) line 104: if ( !url.startsWith( file:/// ) !url.startsWith( file://localhost/ ) ) The fix might be the following (like in svn provider) line 104: if ( !url.startsWith( file:// ) !url.startsWith( file://localhost/ ) ) -- 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: (MANTTASKS-204) Version 2.1.1 of mvn task without maven install still uses Maven 2.0.10
Version 2.1.1 of mvn task without maven install still uses Maven 2.0.10 --- Key: MANTTASKS-204 URL: http://jira.codehaus.org/browse/MANTTASKS-204 Project: Maven 2.x Ant Tasks Issue Type: Bug Components: mvn task Affects Versions: 2.1.1 Environment: Mac OSX 10.6.4 Reporter: Kelly Davis I am running the mvn task and it appears that version 2.1.1 of the Maven Ant Tasks is still using version 2.0.10 of Maven when you don't specify a local installation. artifact:mvn pom=pom.xml arg value=--version/ /artifact:mvn results in: [artifact:mvn] Maven version: 2.0.10 [artifact:mvn] Java version: 1.6.0_22 [artifact:mvn] OS name: mac os x version: 10.6.4 arch: x86_64 Family: mac The current docs indicate that it should be using 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-207) Add a distribution management report
Add a distribution management report Key: MPIR-207 URL: http://jira.codehaus.org/browse/MPIR-207 Project: Maven 2.x Project Info Reports Plugin Issue Type: New Feature Reporter: Vincent Siveton -- 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: (MPIR-207) Add a distribution management report
[ http://jira.codehaus.org/browse/MPIR-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPIR-207. Resolution: Fixed Fix Version/s: 2.3 Assignee: Vincent Siveton fixed in r1036268, snapshot deployed. Add a distribution management report Key: MPIR-207 URL: http://jira.codehaus.org/browse/MPIR-207 Project: Maven 2.x Project Info Reports Plugin Issue Type: New Feature Reporter: Vincent Siveton Assignee: Vincent Siveton Fix For: 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] Closed: (MPIR-198) introduction does not allow HTML markup
[ http://jira.codehaus.org/browse/MPIR-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPIR-198. Resolution: Fixed Fix Version/s: 2.3 should be fixed with MPIR-206 introduction does not allow HTML markup --- Key: MPIR-198 URL: http://jira.codehaus.org/browse/MPIR-198 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: mailing-list Affects Versions: 2.2 Reporter: SebbASF Fix For: 2.3 Further to http://jira.codehaus.org/browse/MPIR-189 the property does not seem to allow any markup. This is very limiting. HTML markup ought to be allowed, e.g. to allow a link to a page describing the e-mail etiquette etc. In particular for ASF projects there really needs to be a link to the Forum Archive Policy http://www.apache.org/foundation/public-archives.html The string can be specified with embedded markup if one uses the ![CDATA[ tag. But something in the code then escapes theso they appear as text in the generated page. -- 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: (MPIR-128) Add a link to a repository location in Project Summary
[ http://jira.codehaus.org/browse/MPIR-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPIR-128. Resolution: Fixed Fix Version/s: 2.3 Assignee: Vincent Siveton fixed in r1036275, snapshot deployed Add a link to a repository location in Project Summary -- Key: MPIR-128 URL: http://jira.codehaus.org/browse/MPIR-128 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: summary Affects Versions: 2.1 Reporter: Vincent Siveton Assignee: Vincent Siveton Fix For: 2.3 Similar to the dependencies report but for the current 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: (MPIR-196) Add a DateBuilt field to the Build Information section of the Project Summary page
[ http://jira.codehaus.org/browse/MPIR-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPIR-196. Resolution: Won't Fix The date is display using the site plugin (see the Last Published info), yes we could duplicate this information in the summary report but I don't think it is a necessary requirement. Add a DateBuilt field to the Build Information section of the Project Summary page -- Key: MPIR-196 URL: http://jira.codehaus.org/browse/MPIR-196 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Affects Versions: 2.2 Reporter: William Ferguson One of the biggest problems (IMHO) when looking at project documentation is the inability to readily determine the age of a component or the age age of the documentation. Such information is often sued to make a decision on how relevant a new component might be. The Project Summary page generated by the Site plugin contains a Build Information section. This section identifies the GroupId, ArtifactId, Version, and Type. If it also published the DateTime at which a component was built then it solve the problem above. -- 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: (MPIR-203) Missing info leads to ArrayIndexOutOfBounds
[ http://jira.codehaus.org/browse/MPIR-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPIR-203. Resolution: Cannot Reproduce using the latest MPIR I cannot reproduce it. Missing info leads to ArrayIndexOutOfBounds --- Key: MPIR-203 URL: http://jira.codehaus.org/browse/MPIR-203 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Environment: Apache Maven 2.2.1 (rdebian-1) Java version: 1.6.0_20 Java home: /usr/lib/jvm/java-6-sun-1.6.0.20/jre Default locale: en_GB, platform encoding: UTF-8 OS name: linux version: 2.6.32-24-generic arch: amd64 Family: unix Reporter: Tim Pizey [INFO] [ERROR] FATAL ERROR [INFO] [INFO] 1 [INFO] [INFO] Trace java.lang.ArrayIndexOutOfBoundsException: 1 at org.apache.maven.doxia.module.xhtml.XhtmlSink.tableCell(XhtmlSink.java:791) at org.apache.maven.doxia.module.xhtml.XhtmlSink.tableHeaderCell(XhtmlSink.java:777) at org.apache.maven.reporting.AbstractMavenReportRenderer.tableHeaderCell(AbstractMavenReportRenderer.java:267) at org.apache.maven.reporting.AbstractMavenReportRenderer.tableHeader(AbstractMavenReportRenderer.java:356) at org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderDependenciesForScope(DependenciesRenderer.java:787) at org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderDependenciesForAllScopes(DependenciesRenderer.java:452) at org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionProjectDependencies(DependenciesRenderer.java:436) at org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:253) at org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79) at org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:215) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:144) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:303) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:133) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:100) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- 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:
