[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. configuration autoVersionSubmodulestrue/autoVersionSubmodules remoteTaggingfalse/remoteTagging suppressCommitBeforeTagtrue/suppressCommitBeforeTag suppressCommitBeforeBranchtrue/suppressCommitBeforeBranch updateBranchVersionstrue/updateBranchVersions updateWorkingCopyVersionsfalse/updateWorkingCopyVersions /configuration 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 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. configuration autoVersionSubmodulestrue/autoVersionSubmodules remoteTaggingfalse/remoteTagging suppressCommitBeforeTagtrue/suppressCommitBeforeTag suppressCommitBeforeBranchtrue/suppressCommitBeforeBranch updateBranchVersionstrue/updateBranchVersions updateWorkingCopyVersionsfalse/updateWorkingCopyVersions /configuration 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] (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-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=1345488view=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] (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] (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=1345503view=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] (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-tabpanelfocusedCommentId=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}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.2.2/version
configuration
goalsdeploy/goals
pushChangesfalse/pushChanges
localCheckouttrue/localCheckout
commitByProjecttrue/commitByProject
/configuration
/plugin
{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] (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-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-tabpanelfocusedCommentId=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}
environment
maven
version2.0.8/version
/maven
java
version1.4.2_15/version
vendorsun/vendor
/java
os
namewindows/name
...
/os
/environment
{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-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}
updateWorkingCopyVersionsfalse/updateWorkingCopyVersions
updateDependenciesfalse/updateDependencies
{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:
updateWorkingCopyVersionsfalse/updateWorkingCopyVersions
updateDependenciesfalse/updateDependencies
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}
updateWorkingCopyVersionsfalse/updateWorkingCopyVersions
updateDependenciesfalse/updateDependencies
{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:comment-tabpanelfocusedCommentId=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}
updateWorkingCopyVersionsfalse/updateWorkingCopyVersions
updateDependenciesfalse/updateDependencies
{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] (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] (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=1345590view=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] (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] (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=1345596view=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] (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] (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=1345598view=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] (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] (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}
dependencyReducedPomLocation${basedir}/dependency-reduced-pom.xml/dependencyReducedPomLocation
{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
