[jira] (MCHANGES-98) Add paging capatibility to changes report
[ https://jira.codehaus.org/browse/MCHANGES-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Marti updated MCHANGES-98: Attachment: screenshot-1.jpg changes-report sample with pagination Add paging capatibility to changes report - Key: MCHANGES-98 URL: https://jira.codehaus.org/browse/MCHANGES-98 Project: Maven Changes Plugin Issue Type: Improvement Components: changes.xml Affects Versions: 2.0-beta-3 Reporter: Benjamin Bentmann Attachments: footable-pagination.zip, screenshot-1.jpg The current report generation does not scale well for projects with a large release history because one ends up with a very long HTML page. Preferable would be to introduce a configuration parameter like releasesPerPage that the mojo could use to split up the change log onto several web pages. Usually, such paging should only apply to web content and not something like PDF or other print-related formats. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPLUGIN-266) Incorrect warning comment about deprecated @component usage for maven objects
Tony Chemit created MPLUGIN-266:
---
Summary: Incorrect warning comment about deprecated @component
usage for maven objects
Key: MPLUGIN-266
URL: https://jira.codehaus.org/browse/MPLUGIN-266
Project: Maven Plugin Tools
Issue Type: Bug
Components: maven-plugin-annotations
Affects Versions: 3.3
Reporter: Tony Chemit
The warning says for example
{noformat}
@parameter name=${settings} @readonly
{noformat}
but the correct message is
{noformat}
@parameter default-value=${settings} @readonly
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPLUGIN-266) Incorrect warning comment about deprecated @component usage for maven objects
[
https://jira.codehaus.org/browse/MPLUGIN-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tony Chemit updated MPLUGIN-266:
Assignee: Tony Chemit
Incorrect warning comment about deprecated @component usage for maven objects
-
Key: MPLUGIN-266
URL: https://jira.codehaus.org/browse/MPLUGIN-266
Project: Maven Plugin Tools
Issue Type: Bug
Components: maven-plugin-annotations
Affects Versions: 3.3
Reporter: Tony Chemit
Assignee: Tony Chemit
The warning says for example
{noformat}
@parameter name=${settings} @readonly
{noformat}
but the correct message is
{noformat}
@parameter default-value=${settings} @readonly
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPLUGIN-266) Incorrect warning comment about deprecated @component usage for maven objects
[
https://jira.codehaus.org/browse/MPLUGIN-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=347364#comment-347364
]
Tony Chemit commented on MPLUGIN-266:
-
Moreover, I am currently using java 5 annotations, so it is strange to get back
warnings in javadoc annotation style.
Incorrect warning comment about deprecated @component usage for maven objects
-
Key: MPLUGIN-266
URL: https://jira.codehaus.org/browse/MPLUGIN-266
Project: Maven Plugin Tools
Issue Type: Bug
Components: maven-plugin-annotations
Affects Versions: 3.3
Reporter: Tony Chemit
The warning says for example
{noformat}
@parameter name=${settings} @readonly
{noformat}
but the correct message is
{noformat}
@parameter default-value=${settings} @readonly
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPLUGIN-266) Incorrect warning comment about deprecated @component usage for maven objects
[
https://jira.codehaus.org/browse/MPLUGIN-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tony Chemit closed MPLUGIN-266.
---
Resolution: Fixed
Fix Version/s: 3.4
Incorrect warning comment about deprecated @component usage for maven objects
-
Key: MPLUGIN-266
URL: https://jira.codehaus.org/browse/MPLUGIN-266
Project: Maven Plugin Tools
Issue Type: Bug
Components: maven-plugin-annotations
Affects Versions: 3.3
Reporter: Tony Chemit
Assignee: Tony Chemit
Fix For: 3.4
The warning says for example
{noformat}
@parameter name=${settings} @readonly
{noformat}
but the correct message is
{noformat}
@parameter default-value=${settings} @readonly
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPLUGIN-266) Incorrect warning comment about deprecated @component usage for maven objects
[
https://jira.codehaus.org/browse/MPLUGIN-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=347371#comment-347371
]
Tony Chemit commented on MPLUGIN-266:
-
Done in [1599146|http://svn.apache.org/1599146]
Incorrect warning comment about deprecated @component usage for maven objects
-
Key: MPLUGIN-266
URL: https://jira.codehaus.org/browse/MPLUGIN-266
Project: Maven Plugin Tools
Issue Type: Bug
Components: maven-plugin-annotations
Affects Versions: 3.3
Reporter: Tony Chemit
Assignee: Tony Chemit
Fix For: 3.4
The warning says for example
{noformat}
@parameter name=${settings} @readonly
{noformat}
but the correct message is
{noformat}
@parameter default-value=${settings} @readonly
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5305) Deprecate relativePath
[ https://jira.codehaus.org/browse/MNG-5305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reto Bachmann-Gmür reopened MNG-5305: - Deprecate relativePath -- Key: MNG-5305 URL: https://jira.codehaus.org/browse/MNG-5305 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Reto Bachmann-Gmür The concept of relativePath is alien to the overall Maven design of having project directory that only depends on entities in the repositories. With relative-paths the build might yield to different results depending on were a project folder is located in the local filesystem. The parent POM resolution was changed in Maven 3. Because of this explicit relativePaths need to be specified more often for reactor builds to be built in the correct order. The reason for this (according to Maven 3.x compatibility note) is to improve consistency: In Maven 2, building the child project in isolation could fail while the reactor build would succeed to resolve the parent.. However this behaviour is inconsistent with the resolution of the other dependencies, in fact the above is true for any Maven version when a dependency that is part of the reactor is not available in a suitable versions in the repository: in this case the build of the individual project fails while the build of the whole reactor succeeds. Because of this relativePath should be marked as deprecated and the parent should be treated like a dependency when computing the build order of reactor projects. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-636) Flat Layout branching not correctly supported - CONTAINS PATCH FOR 2.1 version of plugin - please apply
[
https://jira.codehaus.org/browse/MRELEASE-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=347379#comment-347379
]
Nico De Groote commented on MRELEASE-636:
-
This issue was partly based on the issue MRELEASE-619. This issue has been
fixed.
When will this issue be taken care of?
Flat Layout branching not correctly supported - CONTAINS PATCH FOR 2.1
version of plugin - please apply
---
Key: MRELEASE-636
URL: https://jira.codehaus.org/browse/MRELEASE-636
Project: Maven Release Plugin
Issue Type: Bug
Components: branch
Affects Versions: 2.1
Environment: Maven 2.2.1/maven3.0.X JDK6/7
Reporter: Nico De Groote
Priority: Blocker
Attachments: Maven Release Plugin - Trunk.patch, release.patch
When trying to create a branch with the {{commitByProject=true}} value, it is
not taken into account.
So I created a patch on for the 2.1 version.
The attached patch consist of the following:
in the maven-release-manager
# the MRELEASE-619
# some extra logging concerning the use of commitByProject property in the
AbstractScmCommitPhase.java
in the maven-release-plugin
# I've put the {{commitByProject}} in the {{AbstractReleaseMojo}}, and used
it in both the {{BranchReleaseMojo}} and {{PrepareReleaseMojo}} in similar
way.
Can you guys create a version {{2.1.1}} fix with this patch. There seem to be
a lot of people out there having troublwe releasing a Flat Layout multimodule.
I do it in the following way...
{noformat}
/PARENT/pom.xml
/MODULE1/POM.XML
...
{noformat}
and in the parent {{pom.xml}}
{code:xml}
modules
module../MODULE1/pom.xml/modules
...
/modules
{code}
and in SVN
{noformat}
project/trunk/PARENT (0.0.10-SNAPSHOT)
/trunk/MODULE1 (0.0.10-SNAPSHOT)
/trunk/ (0.0.10-SNAPSHOT)
{noformat}
When releasing this application we perform the following commands
First checkout the application... and run the following command to release a
{{0.0.10-SNAPSHOT}} version on the trunk.
Also make sure you did fill in the SCM information.
# {{release:clean}} {{release:branch}} with the following values set
{{username=username -Dpassword=password -DcommitByProject=true
-DautoVersionSubmodules=true -DreleaseVersion=0.0.10RC1
-DdevelopmentVersion=0.0.11-SNAPSHOT -DupdateBranchVersions=true
-DbranchName=project-0.0.10_branch}}
This will update your trunk value to {{0.11-SNAPSHOT}} and create a branch
with version {{0.0.10RC1-SNAPSHOT}}
Svn will look like this
{noformat}
project/trunk/PARENT (0.0.11-SNAPSHOT)
/trunk/MODULE1 (0.0.11-SNAPSHOT)
/trunk/
/branches/project-0.0.10_branch/PARENT (0.0.10RC1-SNAPSHOT)
/branches/project-0.0.10_branch/MODULE1 (0.0.10RC1-SNAPSHOT)
/branches/project-0.0.10_branch/...
{noformat}
Now, when this is done checkout this newly created branch
and perform the following
# {{release:clean release:prepare release:perform}} with the following values
{{-Dusername=username -Dpassword=password -DcommitByProject=true
-DautoVersionSubmodules=true}}
This will release your {{0.0.10RC1-SNAPSHOT}} as {{0.0.10RC1}}, creates a tag
for it and an upgrade the version number on the branch to
{{0.0.11RC2-SNAPSHOT}}
Svn will look like this
{noformat}
project/trunk/PARENT (0.0.11-SNAPSHOT)
/trunk/MODULE1 (0.0.11-SNAPSHOT)
/trunk/
/branches/project-0.0.10_branch/PARENT (0.0.10RC2-SNAPSHOT)
/branches/project-0.0.10_branch/MODULE1 (0.0.10RC2-SNAPSHOT)
/branches/project-0.0.10_branch/...
/tags/project-0.0.10RC1/PARENT (0.0.10RC1)
/tags/project-0.0.10RC1/MODULE1 (0.0.10RC1)
/tags/project-0.0.10RC1/...
{noformat}
Hope this helps...
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-261) release:prepare should support flat directory multi-module projects
[ https://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=347380#comment-347380 ] Nico De Groote commented on MRELEASE-261: - see my issue MRELEASE-636. I'm also waiting for the patch to be applied. release:prepare should support flat directory multi-module projects --- Key: MRELEASE-261 URL: https://jira.codehaus.org/browse/MRELEASE-261 Project: Maven Release Plugin Issue Type: Improvement Components: prepare Environment: linux / maven2 / svn Reporter: paul.whe...@gmail.com Assignee: Maria Odea Ching Fix For: 2.0 Attachments: flatProject.main.patch, flatProject.test.patch, maven-release-issue.tar.gz, maven-release-issue.zip, MRELEASE-261.patch, MRELEASE-261-sample-project.zip, MRELEASE-261-with-its.patch, MRELEASE-261-with-its-v3.patch, odd-tags.png, PrepareReleaseMojo.patch What I mean by flat file structure firstly. parent/pom.xml module1/pom.xml module2/pom.xml . . . module15/pom.xml the parent references the modules like so modules module../module1/module module../module2/module . . . module../module15/module /modules When i release:prepare only the parent project is tagged the modules projects versions are incremented etc but the modules are not tagged in svn. I use this structure as i use eclipse as my IDE. I would love to see a fix for the issue marked as closed here http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand each submodule of the projects but it would be so nice to have the release plugin do this for me. forgive my english. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-710) Maven 3.0.3, Release Plugin 2.2.1 fails running release;perform
[
https://jira.codehaus.org/browse/MRELEASE-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=334174#comment-334174
]
Nico De Groote edited comment on MRELEASE-710 at 6/2/14 8:50 AM:
-
Had some trouble in the past with the flat layout and the Release plugin.
This is what I did
http://jira.codehaus.org/browse/MRELEASE-636
@Robert
Our structure is like you suggest... and it does not work correctly
was (Author: ndg):
Had some trouble in the past with the flat layout and the Release plugin.
This is what I did
http://jira.codehaus.org/browse/MRELEASE-636
Maven 3.0.3, Release Plugin 2.2.1 fails running release;perform
---
Key: MRELEASE-710
URL: https://jira.codehaus.org/browse/MRELEASE-710
Project: Maven Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.2.1
Environment: Windows 7 x64, Java HotSpot(TM) 64-Bit Server VM (build
20.2-b06, mixed mode), Apache Maven 3.0.3 (r1075438; 2011-02-28
17:31:09+), Maven Release Plugin 2.2.1
Reporter: Délio Filipe Russo Guerra
Assignee: Robert Scholte
Attachments: projects.zip
I have a flat structured multi-module project as follows:
on SVN:
{noformat}
base-project/trunk/pom.xml
test-lib/trunk/pom.xml
test-ejb/trunk/pom.xml
{noformat}
on Eclipse:
{noformat}
base-project/pom.xml
test-lib/pom.xml
test-ejb/pom.xml
{noformat}
pom.xml files follows as attachments, but basically base-project's pom.xml
references both test-lib and test-ejb projects like this:
{code:xml}
modules
module../test-ejb/module
module../test-lib/module
/modules
{code}
When running mvn release:prepare only base-project get tagged:
{noformat}
D:\timwe\workspace\workspace-test\base-projectmvn release:prepare
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model
for com.mindergy.gim.test:test-ejb:ejb:1.0.4
-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-ejb-plugin is missing. @ line 34, column 12
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] base-project
[INFO] test-lib
[INFO] test-ejb
[INFO]
[INFO]
[INFO] Building base-project 1.0.4-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-release-plugin:2.2.1:prepare (default-cli) @ base-project ---
[INFO] Verifying that there are no local modifications...
[INFO] ignoring changes on: pom.xml.next, release.properties,
pom.xml.releaseBackup, pom.xml.backup, pom.xml.branch, pom.xml.tag
[INFO] Executing: cmd.exe /X /C svn --username delio.guerra --password *
--no-auth-cache --non-interactive status
[INFO] Working directory: D:\timwe\workspace\workspace-test\base-project
[INFO] Checking dependencies and plugins for snapshots ...
What is the release version for base-project?
(com.mindergy.gim.test:base-project) 1.0.4: :
What is the release version for test-lib? (com.mindergy.gim.test:test-lib)
1.0.4: :
What is the release version for test-ejb? (com.mindergy.gim.test:test-ejb)
1.0.4: :
What is SCM release tag or label for base-project?
(com.mindergy.gim.test:base-project) base-project-1.0.4: :
What is the new development version for base-project?
(com.mindergy.gim.test:base-project) 1.0.5-SNAPSHOT: :
What is the new development version for test-lib?
(com.mindergy.gim.test:test-lib) 1.0.5-SNAPSHOT: :
What is the new development version for test-ejb?
(com.mindergy.gim.test:test-ejb) 1.0.5-SNAPSHOT: :
[INFO] Transforming 'base-project'...
[INFO] Transforming 'test-lib'...
[INFO] Transforming 'test-ejb'...
[INFO] Updating test-lib to 1.0.4
[INFO] Not generating release POMs
[INFO] Executing goals 'clean install'...
[WARNING] Maven will be executed in interactive mode, but no input stream has
been configured for this MavenInvoker instance.
[INFO] [INFO] Scanning for projects...
[INFO] [WARNING]
[INFO] [WARNING] Some problems were encountered while building the effective
model for com.mindergy.gim.test:test-ejb:ejb:1.0.4
[INFO] [WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-ejb-plugin is missing. @ line 34, column 12
[INFO] [WARNING]
[INFO] [WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[INFO]
[jira] (MPLUGIN-267) document how to change desriptor phase instead of running it twice with skipErrorNoDescriptorsFound
Herve Boutemy created MPLUGIN-267:
-
Summary: document how to change desriptor phase instead of running
it twice with skipErrorNoDescriptorsFound
Key: MPLUGIN-267
URL: https://jira.codehaus.org/browse/MPLUGIN-267
Project: Maven Plugin Tools
Issue Type: Improvement
Components: Plugin Plugin
Affects Versions: 3.3
Reporter: Herve Boutemy
actual example says:
{code:xml} build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version3.3/version
configuration
!-- see http://jira.codehaus.org/browse/MNG-5346 --
skipErrorNoDescriptorsFoundtrue/skipErrorNoDescriptorsFound
/configuration
executions
execution
idmojo-descriptor/id
goals
goaldescriptor/goal
/goals
/execution{code:xml}
this skipErrorNoDescriptorsFound configuration is not really good, since it
does never check if mojo descriptors can be found.
A recent idea permits to avoid this: simply changing the phase of the actual
goal, instead of configuring a second run:
{code:xml} build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version3.3/version
executions
execution
iddefault-descriptor/id
phaseprocess-classes/phase
/execution{code}
the default-descriptor execution id instead of mojo-descriptor is the key
change...
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-710) Maven 3.0.3, Release Plugin 2.2.1 fails running release;perform
[
https://jira.codehaus.org/browse/MRELEASE-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=347393#comment-347393
]
Robert Scholte commented on MRELEASE-710:
-
First confirm that you're using the latest version, please, i.e. 2.5
Maven 3.0.3, Release Plugin 2.2.1 fails running release;perform
---
Key: MRELEASE-710
URL: https://jira.codehaus.org/browse/MRELEASE-710
Project: Maven Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.2.1
Environment: Windows 7 x64, Java HotSpot(TM) 64-Bit Server VM (build
20.2-b06, mixed mode), Apache Maven 3.0.3 (r1075438; 2011-02-28
17:31:09+), Maven Release Plugin 2.2.1
Reporter: Délio Filipe Russo Guerra
Assignee: Robert Scholte
Attachments: projects.zip
I have a flat structured multi-module project as follows:
on SVN:
{noformat}
base-project/trunk/pom.xml
test-lib/trunk/pom.xml
test-ejb/trunk/pom.xml
{noformat}
on Eclipse:
{noformat}
base-project/pom.xml
test-lib/pom.xml
test-ejb/pom.xml
{noformat}
pom.xml files follows as attachments, but basically base-project's pom.xml
references both test-lib and test-ejb projects like this:
{code:xml}
modules
module../test-ejb/module
module../test-lib/module
/modules
{code}
When running mvn release:prepare only base-project get tagged:
{noformat}
D:\timwe\workspace\workspace-test\base-projectmvn release:prepare
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model
for com.mindergy.gim.test:test-ejb:ejb:1.0.4
-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-ejb-plugin is missing. @ line 34, column 12
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] base-project
[INFO] test-lib
[INFO] test-ejb
[INFO]
[INFO]
[INFO] Building base-project 1.0.4-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-release-plugin:2.2.1:prepare (default-cli) @ base-project ---
[INFO] Verifying that there are no local modifications...
[INFO] ignoring changes on: pom.xml.next, release.properties,
pom.xml.releaseBackup, pom.xml.backup, pom.xml.branch, pom.xml.tag
[INFO] Executing: cmd.exe /X /C svn --username delio.guerra --password *
--no-auth-cache --non-interactive status
[INFO] Working directory: D:\timwe\workspace\workspace-test\base-project
[INFO] Checking dependencies and plugins for snapshots ...
What is the release version for base-project?
(com.mindergy.gim.test:base-project) 1.0.4: :
What is the release version for test-lib? (com.mindergy.gim.test:test-lib)
1.0.4: :
What is the release version for test-ejb? (com.mindergy.gim.test:test-ejb)
1.0.4: :
What is SCM release tag or label for base-project?
(com.mindergy.gim.test:base-project) base-project-1.0.4: :
What is the new development version for base-project?
(com.mindergy.gim.test:base-project) 1.0.5-SNAPSHOT: :
What is the new development version for test-lib?
(com.mindergy.gim.test:test-lib) 1.0.5-SNAPSHOT: :
What is the new development version for test-ejb?
(com.mindergy.gim.test:test-ejb) 1.0.5-SNAPSHOT: :
[INFO] Transforming 'base-project'...
[INFO] Transforming 'test-lib'...
[INFO] Transforming 'test-ejb'...
[INFO] Updating test-lib to 1.0.4
[INFO] Not generating release POMs
[INFO] Executing goals 'clean install'...
[WARNING] Maven will be executed in interactive mode, but no input stream has
been configured for this MavenInvoker instance.
[INFO] [INFO] Scanning for projects...
[INFO] [WARNING]
[INFO] [WARNING] Some problems were encountered while building the effective
model for com.mindergy.gim.test:test-ejb:ejb:1.0.4
[INFO] [WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-ejb-plugin is missing. @ line 34, column 12
[INFO] [WARNING]
[INFO] [WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[INFO] [WARNING]
[INFO] [WARNING] For this reason, future Maven versions might no longer
support building such malformed projects.
[INFO] [WARNING]
[INFO] [INFO]
[INFO] [INFO] Reactor Build Order:
[INFO] [INFO]
[INFO] [INFO] base-project
[INFO] [INFO] test-lib
[INFO] [INFO] test-ejb
[jira] (MRELEASE-710) Maven 3.0.3, Release Plugin 2.2.1 fails running release;perform
[
https://jira.codehaus.org/browse/MRELEASE-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=347394#comment-347394
]
Nico De Groote commented on MRELEASE-710:
-
Will try to find some time this week!
Maven 3.0.3, Release Plugin 2.2.1 fails running release;perform
---
Key: MRELEASE-710
URL: https://jira.codehaus.org/browse/MRELEASE-710
Project: Maven Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.2.1
Environment: Windows 7 x64, Java HotSpot(TM) 64-Bit Server VM (build
20.2-b06, mixed mode), Apache Maven 3.0.3 (r1075438; 2011-02-28
17:31:09+), Maven Release Plugin 2.2.1
Reporter: Délio Filipe Russo Guerra
Assignee: Robert Scholte
Attachments: projects.zip
I have a flat structured multi-module project as follows:
on SVN:
{noformat}
base-project/trunk/pom.xml
test-lib/trunk/pom.xml
test-ejb/trunk/pom.xml
{noformat}
on Eclipse:
{noformat}
base-project/pom.xml
test-lib/pom.xml
test-ejb/pom.xml
{noformat}
pom.xml files follows as attachments, but basically base-project's pom.xml
references both test-lib and test-ejb projects like this:
{code:xml}
modules
module../test-ejb/module
module../test-lib/module
/modules
{code}
When running mvn release:prepare only base-project get tagged:
{noformat}
D:\timwe\workspace\workspace-test\base-projectmvn release:prepare
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model
for com.mindergy.gim.test:test-ejb:ejb:1.0.4
-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-ejb-plugin is missing. @ line 34, column 12
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] base-project
[INFO] test-lib
[INFO] test-ejb
[INFO]
[INFO]
[INFO] Building base-project 1.0.4-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-release-plugin:2.2.1:prepare (default-cli) @ base-project ---
[INFO] Verifying that there are no local modifications...
[INFO] ignoring changes on: pom.xml.next, release.properties,
pom.xml.releaseBackup, pom.xml.backup, pom.xml.branch, pom.xml.tag
[INFO] Executing: cmd.exe /X /C svn --username delio.guerra --password *
--no-auth-cache --non-interactive status
[INFO] Working directory: D:\timwe\workspace\workspace-test\base-project
[INFO] Checking dependencies and plugins for snapshots ...
What is the release version for base-project?
(com.mindergy.gim.test:base-project) 1.0.4: :
What is the release version for test-lib? (com.mindergy.gim.test:test-lib)
1.0.4: :
What is the release version for test-ejb? (com.mindergy.gim.test:test-ejb)
1.0.4: :
What is SCM release tag or label for base-project?
(com.mindergy.gim.test:base-project) base-project-1.0.4: :
What is the new development version for base-project?
(com.mindergy.gim.test:base-project) 1.0.5-SNAPSHOT: :
What is the new development version for test-lib?
(com.mindergy.gim.test:test-lib) 1.0.5-SNAPSHOT: :
What is the new development version for test-ejb?
(com.mindergy.gim.test:test-ejb) 1.0.5-SNAPSHOT: :
[INFO] Transforming 'base-project'...
[INFO] Transforming 'test-lib'...
[INFO] Transforming 'test-ejb'...
[INFO] Updating test-lib to 1.0.4
[INFO] Not generating release POMs
[INFO] Executing goals 'clean install'...
[WARNING] Maven will be executed in interactive mode, but no input stream has
been configured for this MavenInvoker instance.
[INFO] [INFO] Scanning for projects...
[INFO] [WARNING]
[INFO] [WARNING] Some problems were encountered while building the effective
model for com.mindergy.gim.test:test-ejb:ejb:1.0.4
[INFO] [WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-ejb-plugin is missing. @ line 34, column 12
[INFO] [WARNING]
[INFO] [WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[INFO] [WARNING]
[INFO] [WARNING] For this reason, future Maven versions might no longer
support building such malformed projects.
[INFO] [WARNING]
[INFO] [INFO]
[INFO] [INFO] Reactor Build Order:
[INFO] [INFO]
[INFO] [INFO] base-project
[INFO] [INFO] test-lib
[INFO] [INFO] test-ejb
[INFO] [INFO]
[INFO] [INFO]
[jira] (MARCHETYPES-45) Use more up-to-date JUnit version
Karl-Heinz Marbaise created MARCHETYPES-45: -- Summary: Use more up-to-date JUnit version Key: MARCHETYPES-45 URL: https://jira.codehaus.org/browse/MARCHETYPES-45 Project: Maven Archetype Bundles Issue Type: Improvement Components: Maven Simple Project Archetype Reporter: Karl-Heinz Marbaise Priority: Minor Currently we are using junit 3.8 in the meantime we are at 4.11 and at annotations. This should be updated. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MARCHETYPES-45) Use more up-to-date JUnit version
[ https://jira.codehaus.org/browse/MARCHETYPES-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MARCHETYPES-45: --- Description: Currently we are using junit 3.8 in the meantime we are at 4.11 and we should use annotations. (was: Currently we are using junit 3.8 in the meantime we are at 4.11 and at annotations. This should be updated.) Use more up-to-date JUnit version - Key: MARCHETYPES-45 URL: https://jira.codehaus.org/browse/MARCHETYPES-45 Project: Maven Archetype Bundles Issue Type: Improvement Components: Maven Simple Project Archetype Reporter: Karl-Heinz Marbaise Priority: Minor Currently we are using junit 3.8 in the meantime we are at 4.11 and we should use annotations. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-636) Flat Layout branching not correctly supported - CONTAINS PATCH FOR 2.1 version of plugin - please apply
[
https://jira.codehaus.org/browse/MRELEASE-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=347395#comment-347395
]
Robert Scholte commented on MRELEASE-636:
-
IMHO unlike tagging I think branching should be a single action, not a
per-project one.
Flat Layout branching not correctly supported - CONTAINS PATCH FOR 2.1
version of plugin - please apply
---
Key: MRELEASE-636
URL: https://jira.codehaus.org/browse/MRELEASE-636
Project: Maven Release Plugin
Issue Type: Bug
Components: branch
Affects Versions: 2.1
Environment: Maven 2.2.1/maven3.0.X JDK6/7
Reporter: Nico De Groote
Priority: Blocker
Attachments: Maven Release Plugin - Trunk.patch, release.patch
When trying to create a branch with the {{commitByProject=true}} value, it is
not taken into account.
So I created a patch on for the 2.1 version.
The attached patch consist of the following:
in the maven-release-manager
# the MRELEASE-619
# some extra logging concerning the use of commitByProject property in the
AbstractScmCommitPhase.java
in the maven-release-plugin
# I've put the {{commitByProject}} in the {{AbstractReleaseMojo}}, and used
it in both the {{BranchReleaseMojo}} and {{PrepareReleaseMojo}} in similar
way.
Can you guys create a version {{2.1.1}} fix with this patch. There seem to be
a lot of people out there having troublwe releasing a Flat Layout multimodule.
I do it in the following way...
{noformat}
/PARENT/pom.xml
/MODULE1/POM.XML
...
{noformat}
and in the parent {{pom.xml}}
{code:xml}
modules
module../MODULE1/pom.xml/modules
...
/modules
{code}
and in SVN
{noformat}
project/trunk/PARENT (0.0.10-SNAPSHOT)
/trunk/MODULE1 (0.0.10-SNAPSHOT)
/trunk/ (0.0.10-SNAPSHOT)
{noformat}
When releasing this application we perform the following commands
First checkout the application... and run the following command to release a
{{0.0.10-SNAPSHOT}} version on the trunk.
Also make sure you did fill in the SCM information.
# {{release:clean}} {{release:branch}} with the following values set
{{username=username -Dpassword=password -DcommitByProject=true
-DautoVersionSubmodules=true -DreleaseVersion=0.0.10RC1
-DdevelopmentVersion=0.0.11-SNAPSHOT -DupdateBranchVersions=true
-DbranchName=project-0.0.10_branch}}
This will update your trunk value to {{0.11-SNAPSHOT}} and create a branch
with version {{0.0.10RC1-SNAPSHOT}}
Svn will look like this
{noformat}
project/trunk/PARENT (0.0.11-SNAPSHOT)
/trunk/MODULE1 (0.0.11-SNAPSHOT)
/trunk/
/branches/project-0.0.10_branch/PARENT (0.0.10RC1-SNAPSHOT)
/branches/project-0.0.10_branch/MODULE1 (0.0.10RC1-SNAPSHOT)
/branches/project-0.0.10_branch/...
{noformat}
Now, when this is done checkout this newly created branch
and perform the following
# {{release:clean release:prepare release:perform}} with the following values
{{-Dusername=username -Dpassword=password -DcommitByProject=true
-DautoVersionSubmodules=true}}
This will release your {{0.0.10RC1-SNAPSHOT}} as {{0.0.10RC1}}, creates a tag
for it and an upgrade the version number on the branch to
{{0.0.11RC2-SNAPSHOT}}
Svn will look like this
{noformat}
project/trunk/PARENT (0.0.11-SNAPSHOT)
/trunk/MODULE1 (0.0.11-SNAPSHOT)
/trunk/
/branches/project-0.0.10_branch/PARENT (0.0.10RC2-SNAPSHOT)
/branches/project-0.0.10_branch/MODULE1 (0.0.10RC2-SNAPSHOT)
/branches/project-0.0.10_branch/...
/tags/project-0.0.10RC1/PARENT (0.0.10RC1)
/tags/project-0.0.10RC1/MODULE1 (0.0.10RC1)
/tags/project-0.0.10RC1/...
{noformat}
Hope this helps...
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MARCHETYPES-45) Use more up-to-date JUnit version
[ https://jira.codehaus.org/browse/MARCHETYPES-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MARCHETYPES-45: --- Component/s: Maven Webapp Archetype Maven Quickstart Archetype Use more up-to-date JUnit version - Key: MARCHETYPES-45 URL: https://jira.codehaus.org/browse/MARCHETYPES-45 Project: Maven Archetype Bundles Issue Type: Improvement Components: Maven Quickstart Archetype, Maven Simple Project Archetype, Maven Webapp Archetype Reporter: Karl-Heinz Marbaise Priority: Minor Currently we are using junit 3.8 in the meantime we are at 4.11 and we should use annotations. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MARCHETYPES-45) Use more up-to-date JUnit version
[ https://jira.codehaus.org/browse/MARCHETYPES-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MARCHETYPES-45. -- Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed in [r1599333|http://svn.apache.org/r1599333] Use more up-to-date JUnit version - Key: MARCHETYPES-45 URL: https://jira.codehaus.org/browse/MARCHETYPES-45 Project: Maven Archetype Bundles Issue Type: Improvement Components: Maven Quickstart Archetype, Maven Simple Project Archetype, Maven Webapp Archetype Reporter: Karl-Heinz Marbaise Assignee: Karl-Heinz Marbaise Priority: Minor Currently we are using junit 3.8 in the meantime we are at 4.11 and we should use annotations. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MARCHETYPES-46) Remove superfluous packaging
[ https://jira.codehaus.org/browse/MARCHETYPES-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MARCHETYPES-46. -- Resolution: Fixed Fixed in [r1599339|http://svn.apache.org/r1599339] Remove superfluous packaging Key: MARCHETYPES-46 URL: https://jira.codehaus.org/browse/MARCHETYPES-46 Project: Maven Archetype Bundles Issue Type: Improvement Components: Maven Quickstart Archetype Affects Versions: maven-archetype-quickstart-1.2 Reporter: Karl-Heinz Marbaise Assignee: Karl-Heinz Marbaise Using a packaging type jar which is default so not necessary. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MARCHETYPES-46) Remove superfluous packaging
Karl-Heinz Marbaise created MARCHETYPES-46: -- Summary: Remove superfluous packaging Key: MARCHETYPES-46 URL: https://jira.codehaus.org/browse/MARCHETYPES-46 Project: Maven Archetype Bundles Issue Type: Improvement Components: Maven Quickstart Archetype Affects Versions: maven-archetype-quickstart-1.2 Reporter: Karl-Heinz Marbaise Using a packaging type jar which is default so not necessary. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MARCHETYPES-46) Remove superfluous packaging
[ https://jira.codehaus.org/browse/MARCHETYPES-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MARCHETYPES-46: --- Fix Version/s: maven-archetype-quickstart-1.2 Remove superfluous packaging Key: MARCHETYPES-46 URL: https://jira.codehaus.org/browse/MARCHETYPES-46 Project: Maven Archetype Bundles Issue Type: Improvement Components: Maven Quickstart Archetype Affects Versions: maven-archetype-quickstart-1.2 Reporter: Karl-Heinz Marbaise Assignee: Karl-Heinz Marbaise Fix For: maven-archetype-quickstart-1.2 Using a packaging type jar which is default so not necessary. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MARCHETYPES-46) Remove superfluous packaging
[ https://jira.codehaus.org/browse/MARCHETYPES-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise reassigned MARCHETYPES-46: -- Assignee: Karl-Heinz Marbaise Remove superfluous packaging Key: MARCHETYPES-46 URL: https://jira.codehaus.org/browse/MARCHETYPES-46 Project: Maven Archetype Bundles Issue Type: Improvement Components: Maven Quickstart Archetype Affects Versions: maven-archetype-quickstart-1.2 Reporter: Karl-Heinz Marbaise Assignee: Karl-Heinz Marbaise Fix For: maven-archetype-quickstart-1.2 Using a packaging type jar which is default so not necessary. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-182) upgrade to last 5.1.0
[ https://jira.codehaus.org/browse/MPMD-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=347400#comment-347400 ] Zlika commented on MPMD-182: Java 8 support was added to PMD 5.1.1, so it would be great to have a new release of maven-pmd-plugin with PMD 5.1.1 for Java 8 projects. Is it planned anytime soon? upgrade to last 5.1.0 - Key: MPMD-182 URL: https://jira.codehaus.org/browse/MPMD-182 Project: Maven PMD Plugin Issue Type: Improvement Reporter: Olivier Lamy Fix For: 3.2 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPLUGIN-267) document how to change desriptor phase instead of running it twice with skipErrorNoDescriptorsFound
[
https://jira.codehaus.org/browse/MPLUGIN-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MPLUGIN-267:
--
Description:
actual example says:
{code:xml} build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version3.3/version
configuration
!-- see http://jira.codehaus.org/browse/MNG-5346 --
skipErrorNoDescriptorsFoundtrue/skipErrorNoDescriptorsFound
/configuration
executions
execution
idmojo-descriptor/id
goals
goaldescriptor/goal
/goals
/execution{code}
this skipErrorNoDescriptorsFound configuration is not really good, since it
does never check if mojo descriptors can be found.
A recent idea permits to avoid this: simply changing the phase of the actual
goal, instead of configuring a second run:
{code:xml} build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version3.3/version
executions
execution
iddefault-descriptor/id
phaseprocess-classes/phase
/execution{code}
the default-descriptor execution id instead of mojo-descriptor is the key
change...
was:
actual example says:
{code:xml} build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version3.3/version
configuration
!-- see http://jira.codehaus.org/browse/MNG-5346 --
skipErrorNoDescriptorsFoundtrue/skipErrorNoDescriptorsFound
/configuration
executions
execution
idmojo-descriptor/id
goals
goaldescriptor/goal
/goals
/execution{code:xml}
this skipErrorNoDescriptorsFound configuration is not really good, since it
does never check if mojo descriptors can be found.
A recent idea permits to avoid this: simply changing the phase of the actual
goal, instead of configuring a second run:
{code:xml} build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version3.3/version
executions
execution
iddefault-descriptor/id
phaseprocess-classes/phase
/execution{code}
the default-descriptor execution id instead of mojo-descriptor is the key
change...
document how to change desriptor phase instead of running it twice with
skipErrorNoDescriptorsFound
---
Key: MPLUGIN-267
URL: https://jira.codehaus.org/browse/MPLUGIN-267
Project: Maven Plugin Tools
Issue Type: Improvement
Components: Plugin Plugin
Affects Versions: 3.3
Reporter: Herve Boutemy
actual example says:
{code:xml} build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version3.3/version
configuration
!-- see http://jira.codehaus.org/browse/MNG-5346 --
skipErrorNoDescriptorsFoundtrue/skipErrorNoDescriptorsFound
/configuration
executions
execution
idmojo-descriptor/id
goals
goaldescriptor/goal
/goals
/execution{code}
this skipErrorNoDescriptorsFound configuration is not really good, since it
does never check if mojo descriptors can be found.
A recent idea permits to avoid this: simply changing the phase of the actual
goal, instead of configuring a second run:
{code:xml} build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version3.3/version
executions
execution
iddefault-descriptor/id
phaseprocess-classes/phase
/execution{code}
the default-descriptor execution id instead of mojo-descriptor is the key
change...
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPLUGIN-267) document how to change desriptor phase instead of running it twice with skipErrorNoDescriptorsFound
[
https://jira.codehaus.org/browse/MPLUGIN-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MPLUGIN-267:
--
Description:
actual example says:
{code:xml} build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version3.3/version
configuration
!-- see http://jira.codehaus.org/browse/MNG-5346 --
skipErrorNoDescriptorsFoundtrue/skipErrorNoDescriptorsFound
/configuration
executions
execution
idmojo-descriptor/id
goals
goaldescriptor/goal
/goals
/execution{code}
this skipErrorNoDescriptorsFound configuration is not really good, since it
does never check if mojo descriptors can be found.
A recent idea permits to avoid this: simply changing the phase of the actual
goal, instead of configuring a second run:
{code:xml} build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version3.3/version
executions
execution
iddefault-descriptor/id
phaseprocess-classes/phase
/execution{code}
the key change is the default-descriptor execution id instead of
mojo-descriptor.
Notice: it works with Maven 3 but not with Maven 2...
was:
actual example says:
{code:xml} build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version3.3/version
configuration
!-- see http://jira.codehaus.org/browse/MNG-5346 --
skipErrorNoDescriptorsFoundtrue/skipErrorNoDescriptorsFound
/configuration
executions
execution
idmojo-descriptor/id
goals
goaldescriptor/goal
/goals
/execution{code}
this skipErrorNoDescriptorsFound configuration is not really good, since it
does never check if mojo descriptors can be found.
A recent idea permits to avoid this: simply changing the phase of the actual
goal, instead of configuring a second run:
{code:xml} build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version3.3/version
executions
execution
iddefault-descriptor/id
phaseprocess-classes/phase
/execution{code}
the default-descriptor execution id instead of mojo-descriptor is the key
change...
document how to change desriptor phase instead of running it twice with
skipErrorNoDescriptorsFound
---
Key: MPLUGIN-267
URL: https://jira.codehaus.org/browse/MPLUGIN-267
Project: Maven Plugin Tools
Issue Type: Improvement
Components: Plugin Plugin
Affects Versions: 3.3
Reporter: Herve Boutemy
actual example says:
{code:xml} build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version3.3/version
configuration
!-- see http://jira.codehaus.org/browse/MNG-5346 --
skipErrorNoDescriptorsFoundtrue/skipErrorNoDescriptorsFound
/configuration
executions
execution
idmojo-descriptor/id
goals
goaldescriptor/goal
/goals
/execution{code}
this skipErrorNoDescriptorsFound configuration is not really good, since it
does never check if mojo descriptors can be found.
A recent idea permits to avoid this: simply changing the phase of the actual
goal, instead of configuring a second run:
{code:xml} build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version3.3/version
executions
execution
iddefault-descriptor/id
phaseprocess-classes/phase
/execution{code}
the key change is the default-descriptor execution id instead of
mojo-descriptor.
Notice: it works with Maven 3 but not with Maven 2...
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPLUGIN-267) document how to change descriptor phase instead of running it twice with skipErrorNoDescriptorsFound
[
https://jira.codehaus.org/browse/MPLUGIN-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MPLUGIN-267:
--
Summary: document how to change descriptor phase instead of running it
twice with skipErrorNoDescriptorsFound (was: document how to change desriptor
phase instead of running it twice with skipErrorNoDescriptorsFound)
document how to change descriptor phase instead of running it twice with
skipErrorNoDescriptorsFound
Key: MPLUGIN-267
URL: https://jira.codehaus.org/browse/MPLUGIN-267
Project: Maven Plugin Tools
Issue Type: Improvement
Components: Plugin Plugin
Affects Versions: 3.3
Reporter: Herve Boutemy
actual example says:
{code:xml} build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version3.3/version
configuration
!-- see http://jira.codehaus.org/browse/MNG-5346 --
skipErrorNoDescriptorsFoundtrue/skipErrorNoDescriptorsFound
/configuration
executions
execution
idmojo-descriptor/id
goals
goaldescriptor/goal
/goals
/execution{code}
this skipErrorNoDescriptorsFound configuration is not really good, since it
does never check if mojo descriptors can be found.
A recent idea permits to avoid this: simply changing the phase of the actual
goal, instead of configuring a second run:
{code:xml} build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version3.3/version
executions
execution
iddefault-descriptor/id
phaseprocess-classes/phase
/execution{code}
the key change is the default-descriptor execution id instead of
mojo-descriptor.
Notice: it works with Maven 3 but not with Maven 2...
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPLUGIN-267) document how to change descriptor phase instead of running it twice with skipErrorNoDescriptorsFound
[
https://jira.codehaus.org/browse/MPLUGIN-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MPLUGIN-267.
-
Resolution: Fixed
Fix Version/s: 3.4
Assignee: Herve Boutemy
documented in [r1599273|http://svn.apache.org/r1599273], with Maven 2 specific
documentation in [r1599392|http://svn.apache.org/r1599392]
document how to change descriptor phase instead of running it twice with
skipErrorNoDescriptorsFound
Key: MPLUGIN-267
URL: https://jira.codehaus.org/browse/MPLUGIN-267
Project: Maven Plugin Tools
Issue Type: Improvement
Components: Plugin Plugin
Affects Versions: 3.3
Reporter: Herve Boutemy
Assignee: Herve Boutemy
Fix For: 3.4
actual example says:
{code:xml} build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version3.3/version
configuration
!-- see http://jira.codehaus.org/browse/MNG-5346 --
skipErrorNoDescriptorsFoundtrue/skipErrorNoDescriptorsFound
/configuration
executions
execution
idmojo-descriptor/id
goals
goaldescriptor/goal
/goals
/execution{code}
this skipErrorNoDescriptorsFound configuration is not really good, since it
does never check if mojo descriptors can be found.
A recent idea permits to avoid this: simply changing the phase of the actual
goal, instead of configuring a second run:
{code:xml} build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version3.3/version
executions
execution
iddefault-descriptor/id
phaseprocess-classes/phase
/execution{code}
the key change is the default-descriptor execution id instead of
mojo-descriptor.
Notice: it works with Maven 3 but not with Maven 2...
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-447) Add option to native tar to unpack
Dan Tran created MDEP-447: - Summary: Add option to native tar to unpack Key: MDEP-447 URL: https://jira.codehaus.org/browse/MDEP-447 Project: Maven Dependency Plugin Issue Type: Improvement Components: unpack, unpack-dependencies Affects Versions: 2.8 Reporter: Dan Tran This method is faster and reserve softlinks -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-447) Add option to use native tar executable to unpack
[ https://jira.codehaus.org/browse/MDEP-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated MDEP-447: -- Summary: Add option to use native tar executable to unpack (was: Add option to native tar to unpack) Add option to use native tar executable to unpack - Key: MDEP-447 URL: https://jira.codehaus.org/browse/MDEP-447 Project: Maven Dependency Plugin Issue Type: Improvement Components: unpack, unpack-dependencies Affects Versions: 2.8 Reporter: Dan Tran This method is faster and reserve softlinks -- This message was sent by Atlassian JIRA (v6.1.6#6162)
