[jira] (MSHADE-121) Default value of parameter 'dependencyReducedPomLocation' broken.
Christian Schulte created MSHADE-121:
Summary: Default value of parameter 'dependencyReducedPomLocation'
broken.
Key: MSHADE-121
URL: https://jira.codehaus.org/browse/MSHADE-121
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.7
Reporter: Christian Schulte
Priority: Critical
Upgrading the shade plugin from '1.6' to '1.7' breaks relative paths similar to
MSHADE-23. This is due to an incorrect/missing default value for parameter
'dependencyReducedPomLocation'.
{code}
/**
* @parameter expression="${dependencyReducedPomLocation}"
defaultValue="${basedir}/dependency-reduced-pom.xml"
*/
private File dependencyReducedPomLocation;
{code}
Should read 'default-value' instead of 'defaultValue'. Manually specifying
{xml}
${basedir}/dependency-reduced-pom.xml
{xml}
solves this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-208) HelpMojo class generated by helpmojo goal uses deprecated annotations
Martin Ellis created MPLUGIN-208:
Summary: HelpMojo class generated by helpmojo goal uses deprecated
annotations
Key: MPLUGIN-208
URL: https://jira.codehaus.org/browse/MPLUGIN-208
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Affects Versions: 3.0
Reporter: Martin Ellis
Attachments: annots-test.tar.gz
The helpmojo goal generates a HelpMojo class that uses 'expression' annotations
on parameter fields rather than 'property' annotations. This results in a lots
of output at warning level when building a plugin that uses the helpmojo goal
for documentation.
This issue refers to javadoc/qdox style annotations generated by the
maven-plugin-plugin 3.0 helpmojo. This version of the 'plugin' plugin does
output Java 5 style annotations too but they are commented out.
Sample project attached. Running {{mvn package}} on the project will show the
warnings.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIASITETOOLS-74) use plexus java 5 annotations instead of old-style javadoc annotations
[ https://jira.codehaus.org/browse/DOXIASITETOOLS-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed DOXIASITETOOLS-74. --- Resolution: Fixed Fix Version/s: 1.4 Assignee: Herve Boutemy done in [r1345598|http://svn.apache.org/viewvc?rev=1345598&view=rev] > use plexus java 5 annotations instead of old-style javadoc annotations > -- > > Key: DOXIASITETOOLS-74 > URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-74 > Project: Maven Doxia Sitetools > Issue Type: Task > Components: Decoration model, Doc renderer, Site renderer >Affects Versions: 1.3 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: 1.4 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIASITETOOLS-74) use plexus java 5 annotations instead of old-style javadoc annotations
Herve Boutemy created DOXIASITETOOLS-74: --- Summary: use plexus java 5 annotations instead of old-style javadoc annotations Key: DOXIASITETOOLS-74 URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-74 Project: Maven Doxia Sitetools Issue Type: Task Components: Decoration model, Doc renderer, Site renderer Affects Versions: 1.3 Reporter: Herve Boutemy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIATOOLS-37) use plexus java 5 annotations instead of old-style javadoc annotations
[ https://jira.codehaus.org/browse/DOXIATOOLS-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed DOXIATOOLS-37. --- Resolution: Fixed Fix Version/s: doxia-book-1.3 doxia-linkcheck-1.3 doxia-integration-tools-1.5 Assignee: Herve Boutemy done in [r1345596|http://svn.apache.org/viewvc?rev=1345596&view=rev] > use plexus java 5 annotations instead of old-style javadoc annotations > -- > > Key: DOXIATOOLS-37 > URL: https://jira.codehaus.org/browse/DOXIATOOLS-37 > Project: Maven Doxia Tools > Issue Type: Task >Affects Versions: doxia-integration-tools-1.4, doxia-linkcheck-1.2, > doxia-book-1.2 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: doxia-integration-tools-1.5, doxia-linkcheck-1.3, > doxia-book-1.3 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIATOOLS-37) use plexus java 5 annotations instead of old-style javadoc annotations
Herve Boutemy created DOXIATOOLS-37: --- Summary: use plexus java 5 annotations instead of old-style javadoc annotations Key: DOXIATOOLS-37 URL: https://jira.codehaus.org/browse/DOXIATOOLS-37 Project: Maven Doxia Tools Issue Type: Task Affects Versions: doxia-book-1.2, doxia-linkcheck-1.2, doxia-integration-tools-1.4 Reporter: Herve Boutemy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-469) use plexus java 5 annotations instead of old-style javadoc annotations
[ https://jira.codehaus.org/browse/DOXIA-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed DOXIA-469. --- Resolution: Fixed Fix Version/s: 1.4 Assignee: Herve Boutemy done in [r1345590|http://svn.apache.org/viewvc?rev=1345590&view=rev] > use plexus java 5 annotations instead of old-style javadoc annotations > -- > > Key: DOXIA-469 > URL: https://jira.codehaus.org/browse/DOXIA-469 > Project: Maven Doxia > Issue Type: Task >Affects Versions: 1.3 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: 1.4 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-469) use plexus java 5 annotations instead of old-style javadoc annotations
Herve Boutemy created DOXIA-469: --- Summary: use plexus java 5 annotations instead of old-style javadoc annotations Key: DOXIA-469 URL: https://jira.codehaus.org/browse/DOXIA-469 Project: Maven Doxia Issue Type: Task Affects Versions: 1.3 Reporter: Herve Boutemy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-714) Prevent snapshot version bumping does not seem to work
[
https://jira.codehaus.org/browse/MRELEASE-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=300233#comment-300233
]
Robert Scholte commented on MRELEASE-714:
-
Looks related to MRELEASE-760 and should be fixed by now. Can you confirm this?
About your off topic issue: Looks related to MRELEASE-241.
If child1 and child2 are subfolders of parent then you don't want to have
version-numbers in the module names.
You must be able to check out the code by tag and run {{mvn install}}.
To find child1-1.0.0 you always have to find tags/parent-1.0.0 first, so the
information will be redundant.
> Prevent snapshot version bumping does not seem to work
> --
>
> Key: MRELEASE-714
> URL: https://jira.codehaus.org/browse/MRELEASE-714
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Paul S
>
> I want to use the release plugin within our company, and I want to create a
> tags for multi-module projects, such as the following example:
> {noformat}
> tags/parent-1.0.0
> - child1 (1.0.0)
> - child2 (1.0.0)
> {noformat}
> When I do "{{release:prepare}}", snapshots with an increased version are
> created and committed for every parent/child module, so:
> {{parent-1.0.0-SNAPSHOT, child1-1.0.0-SNAPSHOT, child2-1.0.0-SNAPSHOT}}
> becomes:
> {{parent-1.0.1-SNAPSHOT, child1-1.0.1-SNAPSHOT, child2-1.0.1-SNAPSHOT}}
> However, when I create a release I don't want to automatically create
> snapshot versions for every child module, so I'd like to bump the version
> number to 1.0.1-SNAPSHOT manually. Sometimes we create a new release in which
> for instance 3 of the 10 child modules have actually been updated, so we want
> to just set those 3 version numbers to an increased SNAPSHOT version. I tried
> accomplishing this by setting the following properties to false:
> {code:xml}
> false
> false
> {code}
> However, whatever I try, it doesn't work. The 1.0.0-SNAPSHOT versions keep
> getting bumped to 1.0.1-SNAPSHOT.
> Furthermore, a little off topic, but is it possible to have version numbers
> created for sub modules? E.g.:
> {noformat}
> tags/parent-1.0.0
> - child1-1.0.0
> - child2-1.0.0)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-714) Prevent snapshot version bumping does not seem to work
[
https://jira.codehaus.org/browse/MRELEASE-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-714:
Description:
I want to use the release plugin within our company, and I want to create a
tags for multi-module projects, such as the following example:
{noformat}
tags/parent-1.0.0
- child1 (1.0.0)
- child2 (1.0.0)
{noformat}
When I do "{{release:prepare}}", snapshots with an increased version are
created and committed for every parent/child module, so:
{{parent-1.0.0-SNAPSHOT, child1-1.0.0-SNAPSHOT, child2-1.0.0-SNAPSHOT}}
becomes:
{{parent-1.0.1-SNAPSHOT, child1-1.0.1-SNAPSHOT, child2-1.0.1-SNAPSHOT}}
However, when I create a release I don't want to automatically create snapshot
versions for every child module, so I'd like to bump the version number to
1.0.1-SNAPSHOT manually. Sometimes we create a new release in which for
instance 3 of the 10 child modules have actually been updated, so we want to
just set those 3 version numbers to an increased SNAPSHOT version. I tried
accomplishing this by setting the following properties to false:
{code:xml}
false
false
{code}
However, whatever I try, it doesn't work. The 1.0.0-SNAPSHOT versions keep
getting bumped to 1.0.1-SNAPSHOT.
Furthermore, a little off topic, but is it possible to have version numbers
created for sub modules? E.g.:
{noformat}
tags/parent-1.0.0
- child1-1.0.0
- child2-1.0.0)
{noformat}
was:
I want to use the release plugin within our company, and I want to create a
tags for multi-module projects, such as the following example:
tags/parent-1.0.0
- child1 (1.0.0)
- child2 (1.0.0)
When I do "release: prepare", snapshots with an increased version are created
and committed for every parent/child module, so:
parent-1.0.0-SNAPSHOT, child1-1.0.0-SNAPSHOT, child2-1.0.0-SNAPSHOT
becomes:
parent-1.0.1-SNAPSHOT, child1-1.0.1-SNAPSHOT, child2-1.0.1-SNAPSHOT
However, when I create a release I don't want to automatically create snapshot
versions for every child module, so I'd like to bump the version number to
1.0.1-SNAPSHOT manually. Sometimes we create a new release in which for
instance 3 of the 10 child modules have actually been updated, so we want to
just set those 3 version numbers to an increased SNAPSHOT version. I tried
accomplishing this by setting the following properties to false:
false
false
However, whatever I try, it doesn't work. The 1.0.0-SNAPSHOT versions keep
getting bumped to 1.0.1-SNAPSHOT.
Furthermore, a little off topic, but is it possible to have version numbers
created for sub modules? E.g.:
tags/parent-1.0.0
- child1-1.0.0
- child2-1.0.0)
> Prevent snapshot version bumping does not seem to work
> --
>
> Key: MRELEASE-714
> URL: https://jira.codehaus.org/browse/MRELEASE-714
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Paul S
>
> I want to use the release plugin within our company, and I want to create a
> tags for multi-module projects, such as the following example:
> {noformat}
> tags/parent-1.0.0
> - child1 (1.0.0)
> - child2 (1.0.0)
> {noformat}
> When I do "{{release:prepare}}", snapshots with an increased version are
> created and committed for every parent/child module, so:
> {{parent-1.0.0-SNAPSHOT, child1-1.0.0-SNAPSHOT, child2-1.0.0-SNAPSHOT}}
> becomes:
> {{parent-1.0.1-SNAPSHOT, child1-1.0.1-SNAPSHOT, child2-1.0.1-SNAPSHOT}}
> However, when I create a release I don't want to automatically create
> snapshot versions for every child module, so I'd like to bump the version
> number to 1.0.1-SNAPSHOT manually. Sometimes we create a new release in which
> for instance 3 of the 10 child modules have actually been updated, so we want
> to just set those 3 version numbers to an increased SNAPSHOT version. I tried
> accomplishing this by setting the following properties to false:
> {code:xml}
> false
> false
> {code}
> However, whatever I try, it doesn't work. The 1.0.0-SNAPSHOT versions keep
> getting bumped to 1.0.1-SNAPSHOT.
> Furthermore, a little off topic, but is it possible to have version numbers
> created for sub modules? E.g.:
> {noformat}
> tags/parent-1.0.0
> - child1-1.0.0
> - child2-1.0.0)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-352) Record Maven version and java version used during release.
[
https://jira.codehaus.org/browse/MRELEASE-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=300232#comment-300232
]
Robert Scholte commented on MRELEASE-352:
-
Is it a problem if the {{release:perform}} is executed with a different Maven
version, Java version or OS then {{release:prepare}}? I think it is much more
important to know with which environment the final/release version was built.
Recently we've been able to add the Maven-version to the Manifest file.
I'd prefer to store this kind of information in that file, so that you should
be able rebuild a project somewhere in the future with the same settings.
> Record Maven version and java version used during release.
> --
>
> Key: MRELEASE-352
> URL: https://jira.codehaus.org/browse/MRELEASE-352
> Project: Maven 2.x Release Plugin
> Issue Type: New Feature
> Components: perform
>Reporter: Paul Gier
>
> The release plugin should be able to record the version of Maven and the
> version of the JDK that were used when the release was done.
> For example, the prepare phase could write a file called
> environment-settings.xml that contains the version of Maven and of Java that
> were used during the prepare step. This file could look something like this:
> {code:xml}
>
>
> 2.0.8
>
>
> 1.4.2_15
> sun
>
>
> windows
> ...
>
>
> {code}
> The perform part of the release would then make sure that these settings
> match when the project is re-built and deployed. There could also be another
> goal in the release plugin, like "check-environment" that would check that
> the environment settings match. That goal could be used when trying to
> rebuild an old release.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-339) Exception AuthenticationException during release:prepare phase when committing versioned POMs
[ https://jira.codehaus.org/browse/MRELEASE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-339. --- Resolution: Won't Fix Assignee: Robert Scholte Like you discovered yourself: it doesn't seem to be a maven-release-plugin bug. There doesn't seem to exist a newer version (http://search.maven.org/#search%7Cga%7C1%7Ccvsclient). If there was a newer version, it should be fixed in the [SCM Project#cvs|https://jira.codehaus.org/browse/SCM/component/11190]. So there's nothing we can do here. > Exception AuthenticationException during release:prepare phase when > committing versioned POMs > - > > Key: MRELEASE-339 > URL: https://jira.codehaus.org/browse/MRELEASE-339 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm > Environment: Windows XP > CVS hosted on linux fedora > maven 2.0.8 >Reporter: Gervais Mickaël >Assignee: Robert Scholte >Priority: Blocker > > I try to use release:prepare plugin. > 1st phase: changing pom version is ok > 2nd phase: building and deploying new version is ok > 3rd phase: commiting POMs fails with this exception: > org.netbeans.lib.cvsclient.connection.AuthenticationException: Authentication > failed. Response from server was: "error 0 :/c". > at > org.netbeans.lib.cvsclient.connection.PServerConnection.openConnection(PServerConnection.java:238) > at > org.netbeans.lib.cvsclient.connection.PServerConnection.open(PServerConnection.java:326) > at > org.apache.maven.scm.provider.cvslib.cvsjava.util.CvsConnection.connect(CvsConnection.java:164) > at > org.apache.maven.scm.provider.cvslib.cvsjava.util.CvsConnection.processCommand(CvsConnection.java:475) > I didn't find cvsclient-20060125.jar (which is a netbean API) sources with > are used in the maven plugin. So I've download the lastest from netbean web > site, I've packaged the new version and replace the cvsclient-20060125.jar > with the new one. > I've relaunched release:prepare and everything is ok... > Is this a bug? Did I do something wrong? > Thanks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-726) mvn release:prepare-with-pom not honouring the commitByProject parameter.
[
https://jira.codehaus.org/browse/MRELEASE-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=300227#comment-300227
]
Robert Scholte commented on MRELEASE-726:
-
Is this still happening with version 2.3.1?
A quick scan over the code tells me that a {{pom.xml}} and optional
{{release-pom.xml}} should be committed at once when {{commitByProject}} is
activated.
I can't see during which release-phase this commit is happening, so could you
add more (debug)-logging?
> mvn release:prepare-with-pom not honouring the commitByProject parameter.
> -
>
> Key: MRELEASE-726
> URL: https://jira.codehaus.org/browse/MRELEASE-726
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: Git, prepare-with-pom
>Affects Versions: 2.2.2
> Environment: Linux 64bit (Ubuntu).
>Reporter: Dave Fennell
>Priority: Blocker
>
> Using this in my pom file:
> {code:xml}
>
> org.apache.maven.plugins
> maven-release-plugin
> 2.2.2
>
> deploy
> false
> true
> true
>
>
> {code}
> Running this command:
> {{mvn release:prepare}}
> Correctly goes into each directory to make changes, e.g.
> {noformat}
> [INFO] Checking in modified POMs...
> [INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel && git add --
> pom.xml
> [INFO] Working directory: /usr/local/src/whitelabel
> [INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel && git status
> [INFO] Working directory: /usr/local/src/whitelabel
> [INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel && git commit
> --verbose -F /tmp/maven-scm-561169862.commit pom.xml
> [INFO] Working directory: /usr/local/src/whitelabel
> [INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel/foundation && git
> add -- pom.xml
> [INFO] Working directory: /usr/local/src/whitelabel/foundation
> [INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel/foundation && git
> status
> [INFO] Working directory: /usr/local/src/whitelabel/foundation
> [INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel/foundation && git
> commit --verbose -F /tmp/maven-scm-2018482909.commit pom.xml
> {noformat}
> etc ...
> However running this command:
> {{mvn release:prepare-with-pom}}
> So that I can generate a release-pom.xml file errors because it attempts to
> do all the checkins on one line:
> {noformat}
> [INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel && git add --
> release-pom.xml foundation/release-pom.xml module/release-pom.xml
> module/advertising/release-pom.xml module/buttonconfig/release-pom.xml
> module/core/release-pom.xml module/film/release-pom.xml
> module/profile/release-pom.xml module/proxy/release-pom.xml
> module/rental/release-pom.xml module/service/release-pom.xml
> module/smartcard/release-pom.xml module/telephony/release-pom.xml
> module/terminalui/release-pom.xml module/tv/release-pom.xml
> module/upsell/release-pom.xml module/urlconfig/release-pom.xml
> mule/release-pom.xml mule/advertising/release-pom.xml
> mule/button-config/release-pom.xml mule/film/release-pom.xml
> mule/hospediacard/release-pom.xml mule/location/release-pom.xml
> mule/profile/release-pom.xml mule/proxy/release-pom.xml
> mule/rental/release-pom.xml mule/service/release-pom.xml
> mule/smartcard/release-pom.xml mule/startup/release-pom.xml
> mule/terminaluimenu/release-pom.xml mule/tv/release-pom.xml
> mule/upsell/release-pom.xml mule/urlconfig/release-pom.xml
> {noformat}
> This doesn't work for my setup because each directory is a git submodule so
> must be run separately, it looks to me like it's simply ignoring the
> {{commitByProject}} setting, but the docs
> (http://maven.apache.org/plugins/maven-release-plugin/prepare-with-pom-mojo.html)
> list it as being a supported property since {{2.0-beta5}}. I've marked this
> as a blocker because I wanted to use the release-pom.xml and I have no way to
> generate them now (since the {{-DgenerateReleasePoms}} option on the
> {{release:prepare}} goal seems to have been deprecated).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-468) upgrade plexus-maven-plugin 1.3.x to plexus-component-metadata 1.5.5
[ https://jira.codehaus.org/browse/DOXIA-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed DOXIA-468. --- Resolution: Fixed Fix Version/s: 1.4 Assignee: Herve Boutemy done in [r1345503|http://svn.apache.org/viewvc?rev=1345503&view=rev] > upgrade plexus-maven-plugin 1.3.x to plexus-component-metadata 1.5.5 > > > Key: DOXIA-468 > URL: https://jira.codehaus.org/browse/DOXIA-468 > Project: Maven Doxia > Issue Type: Task >Affects Versions: 1.3 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: 1.4 > > > [plexus-component-metadata|http://plexus.codehaus.org/plexus-containers/plexus-component-metadata/] > supercedes > [plexus-maven-plugin|http://plexus.codehaus.org/plexus-maven-plugin/] and > supports > [plexus-component-annotations|http://plexus.codehaus.org/plexus-containers/plexus-component-annotations/] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-468) upgrade plexus-maven-plugin 1.3.x to plexus-component-metadata 1.5.5
Herve Boutemy created DOXIA-468: --- Summary: upgrade plexus-maven-plugin 1.3.x to plexus-component-metadata 1.5.5 Key: DOXIA-468 URL: https://jira.codehaus.org/browse/DOXIA-468 Project: Maven Doxia Issue Type: Task Affects Versions: 1.3 Reporter: Herve Boutemy [plexus-component-metadata|http://plexus.codehaus.org/plexus-containers/plexus-component-metadata/] supercedes [plexus-maven-plugin|http://plexus.codehaus.org/plexus-maven-plugin/] and supports [plexus-component-annotations|http://plexus.codehaus.org/plexus-containers/plexus-component-annotations/] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-616) release:rollback does not honor -DcommitByProject
[
https://jira.codehaus.org/browse/MRELEASE-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-616.
---
Resolution: Fixed
Fix Version/s: 2.4
Assignee: Robert Scholte
Fixed in [r1345488| http://svn.apache.org/viewvc?rev=1345488&view=rev]
{{commitByProject}} is now stored in the {{release.properties}}, so the
{{rollback}}-goal should be able to pick it up.
> release:rollback does not honor -DcommitByProject
> -
>
> Key: MRELEASE-616
> URL: https://jira.codehaus.org/browse/MRELEASE-616
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: rollback
>Affects Versions: 2.1
>Reporter: Steven Schlansker
>Assignee: Robert Scholte
> Fix For: 2.4
>
>
> 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, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-151) Use canonical paths for the file list / Unit test failures on builds.apache.org
Andreas Dangel created MPMD-151: --- Summary: Use canonical paths for the file list / Unit test failures on builds.apache.org Key: MPMD-151 URL: https://jira.codehaus.org/browse/MPMD-151 Project: Maven 2.x PMD Plugin Issue Type: Improvement Components: PMD Affects Versions: 2.8 Reporter: Andreas Dangel Attachments: canonical-files.patch On the CI server, some unit tests are failing for maven-pmd-plugin (https://builds.apache.org/job/maven-plugins/). It seems that the tests run fine on the slave "ubuntu2" but not on "ubuntu3". ubuntu2 workspace path: /home/hudson/hudson-slave/workspace/maven-plugins ubuntu3 workspace path: /home/jenkins/jenkins-slave/workspace/maven-plugins However, PMD found violations in the following file: /x1/jenkins/jenkins-slave/workspace/maven-plugins/maven-pmd-plugin/src/test/resources/unit/default-configuration/def/configuration/App.java This could indicate the /x1 is actually a sym-link to /home. Maven-pmd-plugin sees /home/... and PMD sees /x1/ PMD reports violations against /x1 but the maven-pmd-plugin doesn't know about this (it requested to process files under /home) - so the internal PmdFileInfo object couldn't not be determined. Assuming the above is correct, then the attached patch *could* solve this problem. It determines the canonical paths of the files to be processed, hoping that the filenames are unique then. However, I could not reproduce this problem locally (I started maven from commandline instead letting Jenkins start it, maybe that's the difference?). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-635) perform does not honor updateWorkingCopiesVersion setting
[ https://jira.codehaus.org/browse/MRELEASE-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-635. --- Resolution: Duplicate Assignee: Robert Scholte Superseded by MRELEASE-760, which will be part of the next release. > perform does not honor updateWorkingCopiesVersion setting > - > > Key: MRELEASE-635 > URL: https://jira.codehaus.org/browse/MRELEASE-635 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.1 >Reporter: Scott Carey >Assignee: Robert Scholte > > release:perform modifies the working copies version when configured not to. > This was a tag directly from trunk. > > true > false > true > true > true > false > > Happens in both dryRun mode and normal. > After a non-dryRun pom.xml.releaseBackup files are left behind as well. > The desired behavior is to leave the working copy alone and only modify the > tag. Currently, with suppressCommitBeforeTag true, this is possible by > reverting the local changes left behind by running release:perform. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-635) perform does not honor updateWorkingCopiesVersion setting
[ https://jira.codehaus.org/browse/MRELEASE-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MRELEASE-635: Component/s: (was: perform) prepare > perform does not honor updateWorkingCopiesVersion setting > - > > Key: MRELEASE-635 > URL: https://jira.codehaus.org/browse/MRELEASE-635 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.1 >Reporter: Scott Carey > > release:perform modifies the working copies version when configured not to. > This was a tag directly from trunk. > > true > false > true > true > true > false > > Happens in both dryRun mode and normal. > After a non-dryRun pom.xml.releaseBackup files are left behind as well. > The desired behavior is to leave the working copy alone and only modify the > tag. Currently, with suppressCommitBeforeTag true, this is possible by > reverting the local changes left behind by running release:perform. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
