[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
[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] 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=1064118view=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] 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] Commented: (MASSEMBLY-505) Feature Request: useStrictFiltering option for FileSets
[ http://jira.codehaus.org/browse/MASSEMBLY-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 ...fileSet\r\nuseStrictFiltering... @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: ?xml version=1.0 encoding=UTF-8?assembly formats formattar.gz/format /formats fileSets fileSet useStrictFilteringtrue/useStrictFiltering directorysrc/main/directory includes includenonexistant.txt*/include /includes /fileSet /fileSets /assembly 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] 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-tabpanelfocusedCommentId=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: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId executions execution goals goaljavadoc/goal /goals phasegenerate-resources/phase /execution /executions /plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] 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-tabpanelfocusedCommentId=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] 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] 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] 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-tabpanelfocusedCommentId=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\MyClientmvn -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(DefaultLifecycleExecutor.java:553)
at
[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-tabpanelfocusedCommentId=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\MyClientmvn -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
[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] 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}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
version2.3.1/version
configuration
archive
manifest
addClasspathtrue/addClasspath
mainClasseu.ngong.xslt.App/mainClass
classpathPrefix/usr/share/java//classpathPrefix
/manifest
manifestEntries
Namexxx/Name
Content-Typeyyy/Content-Type
/manifestEntries
/archive
/configuration
/plugin
{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}
manifestEntries
keyvalue/key
/manifestEntries
{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}
manifestEntries
Keyvalue/Key
/manifestEntries
{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
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
version2.3.1/version
configuration
archive
manifest
addClasspathtrue/addClasspath
mainClasseu.ngong.xslt.App/mainClass
classpathPrefix/usr/share/java//classpathPrefix
/manifest
manifestEntries
Namexxx/Name
Content-Typeyyy/Content-Type
/manifestEntries
/archive
/configuration
/plugin
does not work: silently neither a classpass is generated nor the requested
entries Name and Content-Type.
If I exchange the manifestEntries by
manifestEntries
keyvalue/key
/manifestEntries
it works: the classpath is generated in MANIFEST.MF as well as the key: value
line.
If I exchange the manifestEntries by
manifestEntries
Keyvalue/Key
/manifestEntries
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}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
version2.3.1/version
configuration
[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 MapString, String environmentVariables; and this in the POM: environment FOObar/FOO /environment This fails, but using a simple type works: /** * The environment variables. * * @parameter alias=environment * @required */ private String environmentVariables; [...] environmentbar/environment -- 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-tabpanelfocusedCommentId=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: ... server idbogus/id usernamebogus/username passwordbogus/password configuration /configuration /server ... pom.xml: ... build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-site-plugin/artifactId version3.0-beta-3/version /plugin /plugins /build distributionManagement site idbogus/id nameBogus/name urlsftp://bogus.bogus.org/bogus/url /site /distributionManagement ... 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] Commented: (MJAR-141) manifestEntry seems not to work correctly
[
http://jira.codehaus.org/browse/MJAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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}
manifestSections
manifestSection
Namefont/BOMBLOGO.TTF/Name
manifestEntries
Content-Typeapplication/x-font/Content-Type
/manifestEntries
/manifestSection
/manifestSections
{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 ...
{{manifestEntriesNamexx/NameContent-Typeyy/Content-Type/manifestEntries}}
breaks the generation of MANIFEST.MF while
{{manifestEntrieskeyvalue/key/manifestEntries}} 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 ...
{{manifestEntriesNamexx/NameContent-Typeyy/Content-Type/manifestEntries}}
breaks the generation of MANIFEST.MF while
{{manifestEntrieskeyvalue/key/manifestEntries}} 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 ...
{{manifestEntriesNamexx/NameContent-Typeyy/Content-Type/manifestEntries}}
breaks the generation of MANIFEST.MF while
{{manifestEntrieskeyvalue/key/manifestEntries}} 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
]
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 ...
{{manifestEntriesNamexx/NameContent-Typeyy/Content-Type/manifestEntries}}
breaks the generation of MANIFEST.MF while
{{manifestEntrieskeyvalue/key/manifestEntries}} 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: (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-tabpanelfocusedCommentId=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 : dependency groupIdorg.apache.cocoon/groupId artifactIdcocoon-core/artifactId version2.2.0-SNAPSHOT/version classifiertests/classifier scopetest/scope /dependency dependency groupIdorg.apache.cocoon/groupId artifactIdcocoon-core/artifactId version2.2.0-SNAPSHOT/version /dependency The first dependency is created by the core module using : plugin artifactIdmaven-jar-plugin/artifactId executions execution goals goaltest-jar/goal /goals /execution /executions /plugin 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] 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-3321) Skip plugin and/or execution
[
http://jira.codehaus.org/browse/MNG-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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: (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-tabpanelfocusedCommentId=253299#action_253299 ] Lukas Theussl commented on MSITE-547: - Did you specify url 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
