[jira] Commented: (MSITE-547) Links to child modules do not work when using flat structure
[ http://jira.codehaus.org/browse/MSITE-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253299#action_253299 ] Lukas Theussl commented on MSITE-547: - Did you specify tags in *all* your poms? See http://maven.apache.org/plugins/maven-site-plugin-3.0-beta-3/faq.html#Use_of_url > Links to child modules do not work when using flat structure > - > > Key: MSITE-547 > URL: http://jira.codehaus.org/browse/MSITE-547 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 3.0-beta-3 > Environment: Maven 3.0.1, Windows XP SP3 >Reporter: Martin Ackermann > Attachments: trial-maven.zip > > > trial-maven-child-module has trial-maven-product as parent. When they are > both in the same directory (flat structure), "mvn site-deploy" does not > generate working links for the site. See attached example project. > If trial-maven-child-module is a sub-directory of trial-maven-product (deep > structure), "mvn site-deploy" generates working links. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MENFORCER-114) Typo in Require Plugin Versions Documentation
Typo in Require Plugin Versions Documentation - Key: MENFORCER-114 URL: http://jira.codehaus.org/browse/MENFORCER-114 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Components: Standard Rules Reporter: Conny Kreyßel Priority: Minor In the http://maven.apache.org/enforcer/enforcer-rules/requirePluginVersions.html is a typo for the property unCheckedPluginList. In the list and the example you write "unCheckedPluginsList" - the 's' is too much - it should be "unCheckedPluginList". Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3321) Skip plugin and/or execution
[
http://jira.codehaus.org/browse/MNG-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253297#action_253297
]
Kristian Rosenvold commented on MNG-3321:
-
Kalyan; thanks for the patch, which I think looks very good, the unit tests
were good. I have a few comments:
1. License headers must be added to all the new files.
2. Any features added to core also have corresponding integration tests, which
are in a separate project
(https://svn.apache.org/repos/asf/maven/core-integration-testing/trunk). In
this case I believe the tests should cover skipping plugin and execution and
demonstrate end-to-end effect of the feature. We do not commit new features
such as this without such tests.
3. Documentation. This needs to be added to the documentation, somewhere ;)
4. Code style. This is only a minor issue but if you use the ide-templates at
http://maven.apache.org/developers/committer-environment.html while making
patches, your patch will
follow maven code style. In general this makes the patch easier to apply and
reduce the risk of patch rot.
> Skip plugin and/or execution
>
>
> Key: MNG-3321
> URL: http://jira.codehaus.org/browse/MNG-3321
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 2.0.8
>Reporter: Paul Gier
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: MNG-3321-maven-core.patch
>
>
> Add ability to skip the execution of certain plugins. From the command line
> this could look something like:
> {code} mvn -Dskip.plugin:org.apache.maven.plugins:maven-surefire-plugin
> install {code}
> Also useful would be the ability to skip individual executions of a plugin.
> For example, if the surefire plugin had two executions defined as "ex1" and
> "ex2", you could do something like this:
> {code} mvn -Dskip.plugin:org.apache.maven.plugins:maven-surefire-plugin:ex1
> install {code}
> This would skip ex1 but still run ex2.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3321) Skip plugin and/or execution
[
http://jira.codehaus.org/browse/MNG-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalyan C. Akella updated MNG-3321:
--
Attachment: MNG-3321-maven-core.patch
Attaching the patch that implements this feature. The patch modifies execution
plan calculation algorithm to eliminate plugins & their executions that need to
be skipped.
> Skip plugin and/or execution
>
>
> Key: MNG-3321
> URL: http://jira.codehaus.org/browse/MNG-3321
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 2.0.8
>Reporter: Paul Gier
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: MNG-3321-maven-core.patch
>
>
> Add ability to skip the execution of certain plugins. From the command line
> this could look something like:
> {code} mvn -Dskip.plugin:org.apache.maven.plugins:maven-surefire-plugin
> install {code}
> Also useful would be the ability to skip individual executions of a plugin.
> For example, if the surefire plugin had two executions defined as "ex1" and
> "ex2", you could do something like this:
> {code} mvn -Dskip.plugin:org.apache.maven.plugins:maven-surefire-plugin:ex1
> install {code}
> This would skip ex1 but still run ex2.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1823) dependencies with classifier mask transitive dependencies of same dependency without classifier
[ http://jira.codehaus.org/browse/MNG-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253259#action_253259 ] Stefan Alfons Tzeggai commented on MNG-1823: So there will never be transitive test/classifier dependencies in maven? > dependencies with classifier mask transitive dependencies of same dependency > without classifier > --- > > Key: MNG-1823 > URL: http://jira.codehaus.org/browse/MNG-1823 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.1 >Reporter: Jorg Heymans >Assignee: Benjamin Bentmann > > A module in cocoon has following dependencies : > > org.apache.cocoon > cocoon-core > 2.2.0-SNAPSHOT > tests > test > > > org.apache.cocoon > cocoon-core > 2.2.0-SNAPSHOT > > The first dependency is created by the core module using : > > maven-jar-plugin > > > > test-jar > > > > > Now i would like the module to depend on the jar with classifier "tests" > during the testing phase ie cocoon-core-2.2.0-SNAPSHOT-tests.jar, and during > the normal compilation phase it should just use > cocoon-core-2.2.0-SNAPSHOT.jar. IMO above dependencies express exactly this. > The problem is that maven somehow removes all transitive dependencies from > cocoon-core-2.2.0-SNAPSHOT.jar when both dependencies are in place, breaking > compilation. When i remove the dependency with the classifier, then all is > fine (but ofcourse my tests can't run) > I hope above is clear, otherwise just ping me on irc -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJAR-141) manifestEntry seems not to work correctly
[
http://jira.codehaus.org/browse/MJAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MJAR-141.
--
Resolution: Not A Bug
> manifestEntry seems not to work correctly
> -
>
> Key: MJAR-141
> URL: http://jira.codehaus.org/browse/MJAR-141
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.3.1
> Environment: linux 32 bit, Eclipse 3.5
>Reporter: Rolf Schumacher
>Priority: Blocker
> Attachments: pom.xml
>
>
> using in pom.xml the maven-jar-plugin ...
> {{xxyy}}
> breaks the generation of MANIFEST.MF while
> {{value}} works as expected.
> attached you find the complete pom.xml
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MJAR-141) manifestEntry seems not to work correctly
[
http://jira.codehaus.org/browse/MJAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann reopened MJAR-141:
> manifestEntry seems not to work correctly
> -
>
> Key: MJAR-141
> URL: http://jira.codehaus.org/browse/MJAR-141
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.3.1
> Environment: linux 32 bit, Eclipse 3.5
>Reporter: Rolf Schumacher
>Priority: Blocker
> Attachments: pom.xml
>
>
> using in pom.xml the maven-jar-plugin ...
> {{xxyy}}
> breaks the generation of MANIFEST.MF while
> {{value}} works as expected.
> attached you find the complete pom.xml
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJAR-141) manifestEntry seems not to work correctly
[
http://jira.codehaus.org/browse/MJAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rolf Schumacher closed MJAR-141.
Resolution: Fixed
This was not a bug.
> manifestEntry seems not to work correctly
> -
>
> Key: MJAR-141
> URL: http://jira.codehaus.org/browse/MJAR-141
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.3.1
> Environment: linux 32 bit, Eclipse 3.5
>Reporter: Rolf Schumacher
>Priority: Blocker
> Attachments: pom.xml
>
>
> using in pom.xml the maven-jar-plugin ...
> {{xxyy}}
> breaks the generation of MANIFEST.MF while
> {{value}} works as expected.
> attached you find the complete pom.xml
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-141) manifestEntry seems not to work correctly
[
http://jira.codehaus.org/browse/MJAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253245#action_253245
]
Rolf Schumacher commented on MJAR-141:
--
ok, found a solution:
do not use the key=name, instead use a concept called "section" (for what ever):
rewriting the code did the trick:
{code:xml}
font/BOMBLOGO.TTF
application/x-font
{code}
> manifestEntry seems not to work correctly
> -
>
> Key: MJAR-141
> URL: http://jira.codehaus.org/browse/MJAR-141
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.3.1
> Environment: linux 32 bit, Eclipse 3.5
>Reporter: Rolf Schumacher
>Priority: Blocker
> Attachments: pom.xml
>
>
> using in pom.xml the maven-jar-plugin ...
> {{xxyy}}
> breaks the generation of MANIFEST.MF while
> {{value}} works as expected.
> attached you find the complete pom.xml
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-546) "container" field of SiteDeployMojo not populated correctly -> NPE with servers containing configuration
[ http://jira.codehaus.org/browse/MSITE-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253243#action_253243 ] Olivier Lamy commented on MSITE-546: more details here http://s.apache.org/QRQ > "container" field of SiteDeployMojo not populated correctly -> NPE with > servers containing configuration > > > Key: MSITE-546 > URL: http://jira.codehaus.org/browse/MSITE-546 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: Maven 3, site:deploy >Affects Versions: 3.0-beta-3 >Reporter: Carl Wilund >Assignee: Olivier Lamy > > In SiteDeployMojo, the field "container" is not populated correctly (version > skew with @Requirement?). When configureWagon is subsequently called, IFF the > site deploy server has an entry in settings.xml AND contains a > "configuration" subelement, there will be a NullPointerException thrown (line > 474) when container.lookup is called. > Simple repro: > settings.xml: > ... > > bogus > bogus > bogus > > > > ... > pom.xml: > ... > > > > org.apache.maven.plugins > maven-site-plugin > 3.0-beta-3 > > > > > > bogus > Bogus > sftp://bogus.bogus.org/bogus > > > ... > While this should obviously not work, it should not NPE at line 474. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4997) Plugin @Parameter alias does not work for Maps
Plugin @Parameter alias does not work for Maps -- Key: MNG-4997 URL: http://jira.codehaus.org/browse/MNG-4997 Project: Maven 2 & 3 Issue Type: Bug Components: Plugin API Affects Versions: 2.2.1 Reporter: Gili It looks like MNG-674 fixed @parameter aliasing for simple types, but not for Map. I declare this in the plugin: /** * The environment variables. * * @parameter alias="environment" * @required */ private Map environmentVariables; and this in the POM: bar This fails, but using a simple type works: /** * The environment variables. * * @parameter alias="environment" * @required */ private String environmentVariables; [...] bar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSHARED-182) manifestEntry seems not to work correctly
[
http://jira.codehaus.org/browse/MSHARED-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MSHARED-182:
Component/s: maven-archiver
Description:
hope this is the correct place ot file an issue about maven-jar-plugin
{code:xml}
org.apache.maven.plugins
maven-jar-plugin
2.3.1
true
eu.ngong.xslt.App
/usr/share/java/
xxx
yyy
{code}
does not work: silently neither a classpass is generated nor the requested
entries Name and Content-Type.
If I exchange the manifestEntries by
{code:xml}
value
{code}
it works: the classpath is generated in MANIFEST.MF as well as the "key: value"
line.
If I exchange the manifestEntries by
{code:xml}
value
{code}
it does not work: the classpath is generated but not the "Key: value" line.
was:
hope this is the correct place ot file an issue about maven-jar-plugin
org.apache.maven.plugins
maven-jar-plugin
2.3.1
true
eu.ngong.xslt.App
/usr/share/java/
xxx
yyy
does not work: silently neither a classpass is generated nor the requested
entries Name and Content-Type.
If I exchange the manifestEntries by
value
it works: the classpath is generated in MANIFEST.MF as well as the "key: value"
line.
If I exchange the manifestEntries by
value
it does not work: the classpath is generated but not the "Key: value" line.
> manifestEntry seems not to work correctly
> -
>
> Key: MSHARED-182
> URL: http://jira.codehaus.org/browse/MSHARED-182
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-archiver
> Environment: maven-jar-plugin 2.3.1
>Reporter: Rolf Schumacher
>Priority: Blocker
>
> hope this is the correct place ot file an issue about maven-jar-plugin
> {code:xml}
>
> org.apache.maven.plugins
> maven-jar-plugin
> 2.3.1
>
>
>
>
> true
>
> eu.ngong.xslt.App
>
> /usr/share/java/
>
>
> xxx
>
> yyy
>
>
>
>
> {code}
> does not work: silently neither a classpass is generated nor th
[jira] Created: (MSITE-547) Links to child modules do not work when using flat structure
Links to child modules do not work when using flat structure - Key: MSITE-547 URL: http://jira.codehaus.org/browse/MSITE-547 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 3.0-beta-3 Environment: Maven 3.0.1, Windows XP SP3 Reporter: Martin Ackermann Attachments: trial-maven.zip trial-maven-child-module has trial-maven-product as parent. When they are both in the same directory (flat structure), "mvn site-deploy" does not generate working links for the site. See attached example project. If trial-maven-child-module is a sub-directory of trial-maven-product (deep structure), "mvn site-deploy" generates working links. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRELEASE-511) release:prepare "Error parsing version, cannot determine next version: Unable to parse the version string" when running in batch mode.
[
http://jira.codehaus.org/browse/MRELEASE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253203#action_253203
]
David Sklar edited comment on MRELEASE-511 at 1/27/11 10:56 AM:
FWIW, I am using the following ruby/expect script to run release:prepare to
work around this problem:
{code}
#!/usr/bin/env ruby
require 'pty'
require 'expect'
require 'rexml/document'
base_dir = "/path/to/my/project"
pom_file = base_dir + "/pom.xml"
raise "Can't read #{pom_file}" unless File.readable? pom_file
pom = REXML::Document.new(File.new(pom_file))
raise "Can't find project version in #{pom_file}" unless
pom.elements['project/version']
version = pom.elements['project/version'].text
release_version = version.gsub(/-SNAPSHOT/,'')
scm_tag = "project-" + release_version
# Write a make_new_development_version() function appropriate to
# whatever format you're using for your version strings
development_version = make_new_development_version(release_version)
# $expect_verbose = true
PTY.spawn("mvn -Dresume=false release:prepare") do |reader, writer, pid|
reader.expect(/What is the release version for.+: :/)
writer.puts(release_version)
reader.expect(/What is SCM release tag or label for.+: :/)
writer.puts(scm_tag)
reader.expect(/What is the new development version for.+: :/)
writer.puts(development_version)
reader.each { |line| print line }
end
{code}
was (Author: davidsklar):
FWIW, I am using the following ruby/expect script to run release:prepare to
work around this problem:
#!/usr/bin/env ruby
require 'pty'
require 'expect'
require 'rexml/document'
base_dir = "/path/to/my/project"
pom_file = base_dir + "/pom.xml"
raise "Can't read #{pom_file}" unless File.readable? pom_file
pom = REXML::Document.new(File.new(pom_file))
raise "Can't find project version in #{pom_file}" unless
pom.elements['project/version']
version = pom.elements['project/version'].text
release_version = version.gsub(/-SNAPSHOT/,'')
scm_tag = "project-" + release_version
# Write a make_new_development_version() function appropriate to
# whatever format you're using for your version strings
development_version = make_new_development_version(release_version)
# $expect_verbose = true
PTY.spawn("mvn -Dresume=false release:prepare") do |reader, writer, pid|
reader.expect(/What is the release version for.+: :/)
writer.puts(release_version)
reader.expect(/What is SCM release tag or label for.+: :/)
writer.puts(scm_tag)
reader.expect(/What is the new development version for.+: :/)
writer.puts(development_version)
reader.each { |line| print line }
end
> release:prepare "Error parsing version, cannot determine next version: Unable
> to parse the version string" when running in batch mode.
> --
>
> Key: MRELEASE-511
> URL: http://jira.codehaus.org/browse/MRELEASE-511
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-9
> Environment: Win Xp Pro 64bit Java 1.6
>Reporter: David Cloutier
>Priority: Critical
> Attachments: patch_release_version_patterns.txt
>
>
> When I try to run release:prepare in batch mode, I get the error below (can't
> parse version string) even though I supply the version number by argument. If
> I do the same thing with the same versions in interactive mode, it works fine.
> Here is the output:
>
> C:\workspaces\head\MyClient>mvn -B -e -Dresume=false -Dtag=PPX
> -DdevelopmentVersion=MYB_200909-SNAPSHOT -DreleaseVersion=PPX release:prepare
> release:perform
> + Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Unnamed - com.mycie:MyClient:jar:MYB_200909-SNAPSHOT
> [INFO]task-segment: [release:prepare, release:perform] (aggregator-style)
> [INFO]
>
> Downloading:
> http://myrepo.int.mycie.com:8081/artifactory/repo/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository libs-releases (http://myrepo.int.mycie.com:8081/artifactory/repo)
> Downloading:
> http://myrepo.int.mycie.com/artifactory/libs-releases-local/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository libs-releases-local
> (http://myrepo.int.mycie.com/artifactory/libs-releases-local)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/ws/security/wss4j/1.5.3/wss4j-1
[jira] Commented: (MRELEASE-511) release:prepare "Error parsing version, cannot determine next version: Unable to parse the version string" when running in batch mode.
[
http://jira.codehaus.org/browse/MRELEASE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253203#action_253203
]
David Sklar commented on MRELEASE-511:
--
FWIW, I am using the following ruby/expect script to run release:prepare to
work around this problem:
#!/usr/bin/env ruby
require 'pty'
require 'expect'
require 'rexml/document'
base_dir = "/path/to/my/project"
pom_file = base_dir + "/pom.xml"
raise "Can't read #{pom_file}" unless File.readable? pom_file
pom = REXML::Document.new(File.new(pom_file))
raise "Can't find project version in #{pom_file}" unless
pom.elements['project/version']
version = pom.elements['project/version'].text
release_version = version.gsub(/-SNAPSHOT/,'')
scm_tag = "project-" + release_version
# Write a make_new_development_version() function appropriate to
# whatever format you're using for your version strings
development_version = make_new_development_version(release_version)
# $expect_verbose = true
PTY.spawn("mvn -Dresume=false release:prepare") do |reader, writer, pid|
reader.expect(/What is the release version for.+: :/)
writer.puts(release_version)
reader.expect(/What is SCM release tag or label for.+: :/)
writer.puts(scm_tag)
reader.expect(/What is the new development version for.+: :/)
writer.puts(development_version)
reader.each { |line| print line }
end
> release:prepare "Error parsing version, cannot determine next version: Unable
> to parse the version string" when running in batch mode.
> --
>
> Key: MRELEASE-511
> URL: http://jira.codehaus.org/browse/MRELEASE-511
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-9
> Environment: Win Xp Pro 64bit Java 1.6
>Reporter: David Cloutier
>Priority: Critical
> Attachments: patch_release_version_patterns.txt
>
>
> When I try to run release:prepare in batch mode, I get the error below (can't
> parse version string) even though I supply the version number by argument. If
> I do the same thing with the same versions in interactive mode, it works fine.
> Here is the output:
>
> C:\workspaces\head\MyClient>mvn -B -e -Dresume=false -Dtag=PPX
> -DdevelopmentVersion=MYB_200909-SNAPSHOT -DreleaseVersion=PPX release:prepare
> release:perform
> + Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Unnamed - com.mycie:MyClient:jar:MYB_200909-SNAPSHOT
> [INFO]task-segment: [release:prepare, release:perform] (aggregator-style)
> [INFO]
>
> Downloading:
> http://myrepo.int.mycie.com:8081/artifactory/repo/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository libs-releases (http://myrepo.int.mycie.com:8081/artifactory/repo)
> Downloading:
> http://myrepo.int.mycie.com/artifactory/libs-releases-local/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository libs-releases-local
> (http://myrepo.int.mycie.com/artifactory/libs-releases-local)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository central (http://repo1.maven.org/maven2)
> [INFO] [release:prepare {execution: default-cli}]
> [INFO] Verifying that there are no local modifications...
> [INFO] Executing: cmd.exe /X /C "cvs -z3 -f -t -d
> :pserver:usrbuild@mycvshost:/data/cvs/libcvs_web -n -q update -d"
> [INFO] Working directory: C:\workspaces\head\MyClient
> [INFO] Checking dependencies and plugins for snapshots ...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error parsing version, cannot determine next version: Unable to parse
> the version string: "MYB_200909-SNAPSHOT"
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error parsing
> version, cannot determine next version: Unable to parse the version string:
> "MYB_200909-SNAPSHOT"
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(Defa
[jira] Created: (MRELEASE-639) Anthill Pro build server expects to be logged into Perforce. Using the release plugin, a perforce login is invoked continuously.
Anthill Pro build server expects to be logged into Perforce. Using the release plugin, a perforce login is invoked continuously. - Key: MRELEASE-639 URL: http://jira.codehaus.org/browse/MRELEASE-639 Project: Maven 2.x Release Plugin Issue Type: New Feature Affects Versions: 2.1 Environment: Anthill Pro/Perforce, maven-scm-provider-perforce Reporter: gary fry Attachments: PerforceLoginCommand.java, PerforceLoginCommandTest.java Currently we have a build system that relies on a Perforce client to be continuously logged in. We have taken a fork of the release plugin to make it work this way. ie we've commented out the login code. A better solution is to make this available for others with similar problems. If a property was provided, it would enable bypassing the Perforce login command. Attached suggested fix. if -Dmaven.scm.perforce.perform.login is not coded, default behaviour occurs (ie p4 login) if -Dmaven.scm.perforce.perform.login=true is coded, default behaviour occurs (ie p4 login) if -Dmaven.scm.perforce.perform.login=false is coded, no Perforce login occurs and a warning is logged. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MINDEXER-9) Improve non-Exact search mode and Query parser by adding support for fuzzy searches
Improve non-Exact search mode and Query parser by adding support for fuzzy searches --- Key: MINDEXER-9 URL: http://jira.codehaus.org/browse/MINDEXER-9 Project: Maven Indexer Issue Type: Improvement Reporter: Tamás Cservenák Improve non-Exact search mode and Query parser by adding support for fuzzy searches -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4639) Be able to profile a maven build
[
http://jira.codehaus.org/browse/MNG-4639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253165#action_253165
]
Jerome Lacoste commented on MNG-4639:
-
For those who are interested in this feature:
* hudson already does this for you (at least in the maven3 support). the time
for the mojos is stored in the build.xml (Search for ExecutedMojo). There's
also a per module page summary on hudson that will display time used per mojo
* you can implement the same in maven by looking at
http://maven.apache.org/ref/3.0.2/maven-core/apidocs/org/apache/maven/execution/AbstractExecutionListener.html.
This is used in and
./maven-embedder/src/main/java/org/apache/maven/cli/ExecutionEventLogger.java
and instantiated by
maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
You might for example want to add a new 'profiling' option. Not to confuse
with maven profiles..
* if you are interested by the downloads time, you might want to look at
./maven-embedder/src/main/java/org/apache/maven/cli/AbstractMavenTransferListener.java
but as downloads might happen in parallel, I am not sure you will get the
information you want (i.e. user time spent waiting for download to complete)
Hope that helps.
> Be able to profile a maven build
>
>
> Key: MNG-4639
> URL: http://jira.codehaus.org/browse/MNG-4639
> Project: Maven 2 & 3
> Issue Type: New Feature
>Reporter: Baptiste MATHUS
> Fix For: Issues to be reviewed for 3.x
>
>
> A common problem with builds is that they can become quite long to run. As it
> is a know anti-pattern for CI for example, one has the need to try and
> optimize their builds.
> The thing is: the current granularity isn't sufficiently precise. In fact,
> you only only the time spent to build each module. This is a good start,
> though.
> Maven currently displays something like the following (let's speak only about
> maven 3):
> {quote}
> [INFO] Reactor Summary:
> [INFO]
>
> [INFO] p1 SUCCESS [1:12.938s]
> [INFO] p2 SUCCESS [5.750s]
> [INFO] p3 SUCCESS [3:58.488s]
> [INFO] p4 SUCCESS [24.437s]
> [INFO] p5 SUCCESS [1.563s]
> [INFO]
>
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> [INFO] Total time: 5 minutes 46 seconds
> {quote}
> What would be great would be adding an option that would higher the details.
> Something like -A/--analyze (--profile would be too close to -P/profile
> option) would add detailed analysis, would print something like.
> {quote}
> [INFO] Reactor Summary:
> [INFO]
>
> [INFO] p1 SUCCESS [1:12.938s]
> clean:clean (somepkg.CleanMojo) : 10.3s
> compiler:compile (...) : 50s
> ...
> and so on
> {quote}
> I'm not very well aware the level of details maven 3 API could provide. So
> the printing above could become irrelevant. In this case, printing a
> dedicated html or so report might be a better choice.
> Cheers
> PS : Though I'm really not introduced into maven code, if you think it's not
> too complicated, I could try and contribute on this field if I'm given some
> hints or good starting points.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-302) Classpath cleared after maven-javadoc-plugin:javadoc
[ http://jira.codehaus.org/browse/MJAVADOC-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253164#action_253164 ] Bryon Jacob commented on MJAVADOC-302: -- a workaround, which might help indicate the source of the problem, is to use the "aggregate" goal instead of the "javadoc" goal. it appears that the two goals do essentially the same thing, except that the aggregate goal is run as an aggregator plugin: http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html http://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html http://docs.codehaus.org/display/MAVEN/Aggregator+Plugins which has the benefit that the execution is always forked, so the classpath munging doesn't affect the rest of your lifecycle. Looking at the source, you can see that the "aggregate" goal simply extends the "javadoc" goal and turns on the "aggregator" bit: http://maven.apache.org/plugins/maven-javadoc-plugin/xref/org/apache/maven/plugin/javadoc/AggregatorJavadocReport.html Looking at the wiki on Aggregator Plugins, I don't see any reason why it should be dangerous to use that on a non-aggregate project, and empirically, this seems to work around the issues Bryan mentions above. > Classpath cleared after maven-javadoc-plugin:javadoc > > > Key: MJAVADOC-302 > URL: http://jira.codehaus.org/browse/MJAVADOC-302 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.5, 2.6, 2.6.1, 2.7 > Environment: mac OSX 10.6.4 >Reporter: Bryan Campbell >Priority: Blocker > > Repro Case: > - I have a war based maven configuration with the maven-javadoc-plugin as > copied below. > - > mvn jetty:run > Result: > - When jetty loads, every servlet fails to load, the first is always > java.lang.ClassNotFoundException: > org.springframework.web.context.ContextLoaderListener followed by null > pointers and CNFE's on every servlet. > When i take out the execution of the maven-javadoc-plugin everything works?! > My only guess is that when the javadoc plugin runs, it does something with > the classpath such that when jetty runs it doesn't have what it needs to find > all the classes correctly. > My javadoc configuration is as follows: > > org.apache.maven.plugins > maven-javadoc-plugin > > > > javadoc > > generate-resources > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-505) Feature Request: useStrictFiltering option for FileSets
[ http://jira.codehaus.org/browse/MASSEMBLY-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253156#action_253156 ] R.M.Morrien commented on MASSEMBLY-505: --- With 2.2-beta-5 I have the problem as described. With 2.2 I run into: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.2:single (make-assembly) on project testassembly: Error reading assemblies: Error reading descriptor: /src/main/resources/assemblies/assembly.xml: Unrecognised tag: 'useStrictFiltering' (position: START _TAG seen ...\r\n... @11:33) -> [Help 1] For me useStrictFiltering is mandatory to ensure correct release build assemblies. > Feature Request: useStrictFiltering option for FileSets > --- > > Key: MASSEMBLY-505 > URL: http://jira.codehaus.org/browse/MASSEMBLY-505 > Project: Maven 2.x Assembly Plugin > Issue Type: New Feature >Affects Versions: 2.2 > Environment: Maven 2.2.1, RHEL4 >Reporter: John Casey > Attachments: fail_strictfiltering.zip > > > *NOTE:* This is a clone of MASSEMBLY-488. The original issue will be closed > Won't Fix, since the plexus-utils class DirectoryScanner, which is the core > of the FileSet functionality, doesn't support strict include/exclude > filtering. > This issue is a feature request to have that added. > - > I'm trying to turn on useStrictFiltering in a fileSet in an assembly > descriptor, but maven doesn't fail when the file does not exist. Here > is an example of what the assembly descriptor looks like: > > > tar.gz > > > > true > src/main > > nonexistant.txt* > > > > > Running "mvn package" happily produces a tarball with no indication that > anything is wrong. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPDF-11) Improve warning message for invalid links
[ http://jira.codehaus.org/browse/MPDF-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MPDF-11. - Resolution: Won't Fix Assignee: Lukas Theussl Should be fixed in doxia. > Improve warning message for invalid links > - > > Key: MPDF-11 > URL: http://jira.codehaus.org/browse/MPDF-11 > Project: Maven 2.x PDF Plugin > Issue Type: Improvement >Affects Versions: 1.0 > Environment: 1.0-SNAPSHOT r772248 >Reporter: Wendy Smoak >Assignee: Lukas Theussl >Priority: Minor > > Currently I'm getting several warnings like this: > [WARNING] Modified invalid link: notification/index.html > It would be nice if the message said why this is invalid and/or what to do to > fix it (usually, prepend ./ ). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPDF-41) with maven 3 pdf failure if reporting section is not empty
[ http://jira.codehaus.org/browse/MPDF-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MPDF-41. - Resolution: Fixed Documented: [r1064118|http://svn.apache.org/viewvc?rev=1064118&view=rev] > with maven 3 pdf failure if reporting section is not empty > -- > > Key: MPDF-41 > URL: http://jira.codehaus.org/browse/MPDF-41 > Project: Maven 2.x PDF Plugin > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 1.2 > > > The current mojo use removed methods in maven 3. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-691) Skip reports and menu link generation when it does not make sense (i.e: test results are missing)
[ http://jira.codehaus.org/browse/SUREFIRE-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcin Kuthan updated SUREFIRE-691: --- Attachment: screenshot.png The site generated for sub-module in aggregate mode. Empty Surefire report page is displayed. Javadocs, JXR and PMD reports are hidden. > Skip reports and menu link generation when it does not make sense (i.e: test > results are missing) > - > > Key: SUREFIRE-691 > URL: http://jira.codehaus.org/browse/SUREFIRE-691 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Report Plugin >Affects Versions: 2.7.3 >Reporter: Marcin Kuthan >Priority: Minor > Attachments: screenshot.png > > > Surefire report page and link in the menu are generated even if there is no > tests. It also happens for submodules when -Daggregate=true is given. > Another plugins which supports report aggregation (m-pmd-p, m-javadoc-p, > m-jxr-p) don't generate link in the menu and empty report page when report > does not make sense. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-691) Skip reports and menu link generation when it does not make sense (i.e: test results are missing)
Skip reports and menu link generation when it does not make sense (i.e: test results are missing) - Key: SUREFIRE-691 URL: http://jira.codehaus.org/browse/SUREFIRE-691 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Report Plugin Affects Versions: 2.7.3 Reporter: Marcin Kuthan Priority: Minor Surefire report page and link in the menu are generated even if there is no tests. It also happens for submodules when -Daggregate=true is given. Another plugins which supports report aggregation (m-pmd-p, m-javadoc-p, m-jxr-p) don't generate link in the menu and empty report page when report does not make sense. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
