[jira] (MRELEASE-543) prepare-with-pom : inherited dependencies exclusion are lost in release-pom.xml
[ https://jira.codehaus.org/browse/MRELEASE-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308941#comment-308941 ] Bartosz Radaczynski commented on MRELEASE-543: -- Is this issue fixed in any version of the release plugin? prepare-with-pom : inherited dependencies exclusion are lost in release-pom.xml --- Key: MRELEASE-543 URL: https://jira.codehaus.org/browse/MRELEASE-543 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare-with-pom Affects Versions: 2.0 Environment: Maven 2.2.1 Reporter: Thomas Sauzedde Attachments: sample-projects.tgz Like in the provided sample projects, I have the following scenario : 3 modules (sibling) with the following inheritage graph : grandfather === father === child - grandfather (pom module) has - a dependencyManagement block with some exclusions - a pluginManagement block - father (pom module) adds a plugins block to configure the compiler plugin - child is a basic (empty) jar module when mvn release:prepare-with-pom is performed on child the checked-in (svn) release-pom.xml has all the dependencies resolved BUT my exclusions defined in grandfather are lost :-( To reproduce this with the provided sample projects : - perform a mvn:install on grandfather father - import child in your svn repo - change the scm block on child in order to checkout/in from your svn - perform a mvn release:prepare-with-pom You will see that in your tagged release-pom.xml the exclusions are lost. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-543) prepare-with-pom : inherited dependencies exclusion are lost in release-pom.xml
[ https://jira.codehaus.org/browse/MRELEASE-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308943#comment-308943 ] Bartosz Radaczynski commented on MRELEASE-543: -- Does this also impact transitive exclusions or just inherited ones? prepare-with-pom : inherited dependencies exclusion are lost in release-pom.xml --- Key: MRELEASE-543 URL: https://jira.codehaus.org/browse/MRELEASE-543 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare-with-pom Affects Versions: 2.0 Environment: Maven 2.2.1 Reporter: Thomas Sauzedde Attachments: sample-projects.tgz Like in the provided sample projects, I have the following scenario : 3 modules (sibling) with the following inheritage graph : grandfather === father === child - grandfather (pom module) has - a dependencyManagement block with some exclusions - a pluginManagement block - father (pom module) adds a plugins block to configure the compiler plugin - child is a basic (empty) jar module when mvn release:prepare-with-pom is performed on child the checked-in (svn) release-pom.xml has all the dependencies resolved BUT my exclusions defined in grandfather are lost :-( To reproduce this with the provided sample projects : - perform a mvn:install on grandfather father - import child in your svn repo - change the scm block on child in order to checkout/in from your svn - perform a mvn release:prepare-with-pom You will see that in your tagged release-pom.xml the exclusions are lost. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2199) Version ranges not supported for parent artifacts
[
https://jira.codehaus.org/browse/MNG-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-2199:
---
Attachment: MNG-2199.patch
Updated the patch to additionally validate a 'version' to not use expressions.
{code}
Script started on Wed Sep 19 08:32:30 2012
$ cat pom.xml
project
parent
groupIdorg.apache/groupId
artifactIdapache/artifactId
version[,11]/version
/parent
modelVersion4.0.0/modelVersion
artifactIdmng2199/artifactId
packagingjar/packaging
/project
$ mvn clean
[INFO] Scanning for projects...
[ERROR] The build could not read 1 project - [Help 1]
[ERROR]
[ERROR] The project org.apache:mng2199:11 (/tmp/mng2199/pom.xml) has 1 error
[ERROR] 'version' must be a constant. @
org.apache:mng2199:[unknown-version], /tmp/mng2199/pom.xml, line 2, column 11
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
$ ^D
Script done on Wed Sep 19 08:32:42 2012
{code}
{code}
Script started on Wed Sep 19 08:33:36 2012
$ cat pom.xml
project
parent
groupIdorg.apache/groupId
artifactIdapache/artifactId
version[,11]/version
/parent
modelVersion4.0.0/modelVersion
artifactIdmng2199/artifactId
packagingjar/packaging
version1.0-${expression}-SNAPSHOT/version
/project
$ mvn clean
[INFO] Scanning for projects...
[ERROR] The build could not read 1 project - [Help 1]
[ERROR]
[ERROR] The project org.apache:mng2199:1.0-${expression}-SNAPSHOT
(/tmp/mng2199/pom.xml) has 1 error
[ERROR] 'version' contains an expression but must be a constant. @ line 2,
column 11
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
$ ^D
Script done on Wed Sep 19 08:33:47 2012
{code}
Version ranges not supported for parent artifacts
-
Key: MNG-2199
URL: https://jira.codehaus.org/browse/MNG-2199
Project: Maven 2 3
Issue Type: Wish
Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 2.0.3
Reporter: Christian Schulte
Fix For: Issues to be reviewed for 3.x
Attachments: MNG-2199.patch, MNG-2199.patch, MNG-2199.patch,
MNG-2199.patch
It would be great if Maven supports version ranges when specifying parent
artifacts in a multi-module build. Currently this does not work.
parent
artifactIdartifactId/artifactId
groupIdgroupId/groupId
version[2.0, 2.0.1]/version
/parent
[INFO] Scanning for projects...
Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0,
2.0.1]/artifactId-[2.0, 2.0.1].pom
Additionally it would be great if this
parent
artifactIdartifactId/artifactId
groupIdgroupId/groupId
version[2.0, ${pom.version}]/version
/parent
[INFO] Scanning for projects...
Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0,
${pom.version}]/artifactId-[2.0, ${pom.version}].pom
would also work, if the version is specified in the same pom.xml which
defines this parent definition.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-92) Docs says the skip param is required, which it isn't
Anders Hammar created MINSTALL-92: - Summary: Docs says the skip param is required, which it isn't Key: MINSTALL-92 URL: https://jira.codehaus.org/browse/MINSTALL-92 Project: Maven 2.x Install Plugin Issue Type: Bug Components: install:install Affects Versions: 2.4 Environment: on-line docs Reporter: Anders Hammar Priority: Minor The install goal docs lists the skip parameter as a required param, which it isn't (there's a default value). It should be listed as an optional param (as it is for deploy:deploy). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-92) Docs says the skip param is required, which it isn't
[ https://jira.codehaus.org/browse/MINSTALL-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar reassigned MINSTALL-92: - Assignee: Anders Hammar Docs says the skip param is required, which it isn't Key: MINSTALL-92 URL: https://jira.codehaus.org/browse/MINSTALL-92 Project: Maven 2.x Install Plugin Issue Type: Bug Components: install:install Affects Versions: 2.4 Environment: on-line docs Reporter: Anders Hammar Assignee: Anders Hammar Priority: Minor The install goal docs lists the skip parameter as a required param, which it isn't (there's a default value). It should be listed as an optional param (as it is for deploy:deploy). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-92) Docs says the skip param is required, which it isn't
[ https://jira.codehaus.org/browse/MINSTALL-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar closed MINSTALL-92. - Resolution: Fixed Fix Version/s: 2.5 Fixed in r1387470 Docs says the skip param is required, which it isn't Key: MINSTALL-92 URL: https://jira.codehaus.org/browse/MINSTALL-92 Project: Maven 2.x Install Plugin Issue Type: Bug Components: install:install Affects Versions: 2.4 Environment: on-line docs Reporter: Anders Hammar Assignee: Anders Hammar Priority: Minor Fix For: 2.5 The install goal docs lists the skip parameter as a required param, which it isn't (there's a default value). It should be listed as an optional param (as it is for deploy:deploy). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-253) Http proxy does not work any more
[ https://jira.codehaus.org/browse/MJAVADOC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308960#comment-308960 ] Anders Hammar commented on MJAVADOC-253: +1 Anything pre 2.2.1 should have very little priority IMHO. Http proxy does not work any more - Key: MJAVADOC-253 URL: https://jira.codehaus.org/browse/MJAVADOC-253 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.6, 2.7 Environment: Maven 2.0.9 JDK5 (Sun) Reporter: Mohan K It appears the update of Wagon Provider in 2.6 is not compatible with Maven 2.0.x. Here is the email snippet as posted to maven users group (no responses) I am using Maven 2.0.9 and maven-javadoc-plugin 2.6. I have the links configured in my plugin config. Now all resolution of external links fail (we are behind a proxy *not* NTLM) with this: Aug 12, 2009 12:02:31 AM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme INFO: ntlm authentication scheme selected Aug 12, 2009 12:02:31 AM org.apache.commons.httpclient.HttpMethodDirector authenticate The wagon provider appears to have been upgraded to 1.0-beta-6 in the maven-javadoc-plugin 2.6 (as opposed to 1.0-beta-2 in 2.5). I seem to remember that (maybe it is wrong) that wagon 1.0-beta-6 requires Maven 2.1.x and above? If that is the case, I don't understand how the plugin was released with prerequisite of 2.0.9? Is there a workaround to disable the default ntlm auth scheme via a magical system property? TIA -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-270) NTLM Authentication doesn't seem to work
[ https://jira.codehaus.org/browse/MJAVADOC-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar updated MJAVADOC-270: --- Affects Version/s: 2.7 NTLM Authentication doesn't seem to work Key: MJAVADOC-270 URL: https://jira.codehaus.org/browse/MJAVADOC-270 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.6, 2.7 Reporter: Martijn Verburg Priority: Minor plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId configuration additionalJOption-J-Dhttp.auth.ntlm.domain=MIP-LONDON/additionalJOption /configuration /plugin Stack Trace: --- [INFO] Generating JavaDocs report. [WARNING] Source files encoding has not been set, using platform encoding ISO-8859-1, i.e. build is platform dependent! Oct 21, 2009 1:55:22 PM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme INFO: ntlm authentication scheme selected Oct 21, 2009 1:55:22 PM org.apache.commons.httpclient.HttpMethodDirector authenticate SEVERE: Credentials cannot be used for NTLM authentication: org.apache.commons.httpclient.UsernamePasswordCredentials org.apache.commons.httpclient.auth.InvalidCredentialsException: Credentials cannot be used for NTLM authentication: org.apache.commons.httpclient.UsernamePasswordCredentials at org.apache.commons.httpclient.auth.NTLMScheme.authenticate(NTLMScheme.java:332) at org.apache.commons.httpclient.HttpMethodDirector.authenticateProxy(HttpMethodDirector.java:320) at org.apache.commons.httpclient.HttpMethodDirector.authenticate(HttpMethodDirector.java:232) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323) at org.apache.maven.plugin.javadoc.JavadocUtil.fetchURL(JavadocUtil.java:773) at org.apache.maven.plugin.javadoc.AbstractJavadocMojo.isValidJavadocLink(AbstractJavadocMojo.java:4680) at org.apache.maven.plugin.javadoc.AbstractJavadocMojo.addLinkArguments(AbstractJavadocMojo.java:3229) at org.apache.maven.plugin.javadoc.AbstractJavadocMojo.addStandardDocletOptions(AbstractJavadocMojo.java:3885) at org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1761) at org.apache.maven.plugin.javadoc.JavadocReport.generate(JavadocReport.java:122) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:133) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:100) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at
[jira] (MNG-5316) Build Extension not resolved from reactor
[ https://jira.codehaus.org/browse/MNG-5316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308966#comment-308966 ] Adrian Shum commented on MNG-5316: -- Any comments or update on this issue? I am a bit worried that this issue tracker is not actually in use, is it? Build Extension not resolved from reactor - Key: MNG-5316 URL: https://jira.codehaus.org/browse/MNG-5316 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0.4 Environment: Windows XP, JDK 1.6.0_30 Reporter: Adrian Shum Attachments: exttest.zip This seems to be what described in another bug MNG-1323. I encountered this issue when I am trying out what described in FindBugs multi-module configuration: http://mojo.codehaus.org/findbugs-maven-plugin/examples/multi-module-config.html Attached please find a sample project which I skimmed from my existing project. exttest is a multi-module project exttest-qa module is the module aimed to be included as extension. This module is not having any dependency, and it is intentionally not inheriting from exttest-parent to avoid cyclic dependency exttest-parent is the parent POM for the whole project, and it add exttest-qa as a build extension. exttest-main did nothing in this test. I put it in just to make the whole project looks more reasonable :) Simply mvn clean will shows the error of : [ERROR] Unresolveable build extension: Plugin com.foo:exttest-qa:1.0-SNAPSHOT or one of its dependencies could not be resolved: Failure to find com.foo:exttest-qa:jar:1.0-SNAPSHOT in However I expect exttest-qa should be resolved from the reactor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRRESOURCES-65) Plugin not thread safe (java.util.ConcurrentModificationException)
Olivier Lamy created MRRESOURCES-65:
---
Summary: Plugin not thread safe
(java.util.ConcurrentModificationException)
Key: MRRESOURCES-65
URL: https://jira.codehaus.org/browse/MRRESOURCES-65
Project: Maven 2.x Remote Resources Plugin
Issue Type: Bug
Affects Versions: 1.3
Reporter: Olivier Lamy
Priority: Critical
stack trace
{code}
Execution default of goal
org.apache.maven.plugins:maven-remote-resources-plugin:1.3:process failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default
of goal org.apache.maven.plugins:maven-remote-resources-plugin:1.3:process
failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 13 more
Caused by: java.util.ConcurrentModificationException
at java.util.Hashtable$Enumerator.next(Hashtable.java:1031)
at java.util.Hashtable.putAll(Hashtable.java:465)
at
org.apache.maven.project.DefaultProjectBuildingRequest.setSystemProperties(DefaultProjectBuildingRequest.java:166)
at
org.apache.maven.project.DefaultMavenProjectBuilder.toRequest(DefaultMavenProjectBuilder.java:79)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:229)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:251)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:258)
at
org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.getProjects(ProcessRemoteResourcesMojo.java:663)
at
org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.configureVelocityContext(ProcessRemoteResourcesMojo.java:997)
at
org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.execute(ProcessRemoteResourcesMojo.java:511)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 14 more
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5347) Support expressions for plugin parameters
Mickael Istria created MNG-5347:
---
Summary: Support expressions for plugin parameters
Key: MNG-5347
URL: https://jira.codehaus.org/browse/MNG-5347
Project: Maven 2 3
Issue Type: Wish
Components: General
Affects Versions: 3.0.4
Environment: mistria@mistria--rh:~$ mvn -version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /home/mistria/apps/apache-maven-3.0.4
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux, version: 3.2.0-30-generic, arch: amd64, family: unix
Reporter: Mickael Istria
Use-case:
I want to give as input of my surefire-plugin
{code}
configuration
skip${skipTests} || ${skipDownloadRuntimes}/skip
configuration
{code}
This won't work because the expressions are not evaluated. Boolean arguments in
plugin are set to something like Boolean.parseBoolean, which is quite limited.
Instead, we could think of introducing an expression language, such as Groovy,
that would allow expressions as parameters for plugins.
Then let's say skipTests=false and skipDownloadRuntimes=true, Maven would first
replace ${skipTests} || ${skipDownloadRuntimes} by false || true and then
this evaluator would evaluate that to false, and skip will receive the value
false.
This would for sure make maven less verbose in some cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5230) Command line option to exclude modules from reactor
[
https://jira.codehaus.org/browse/MNG-5230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308997#comment-308997
]
Stephan Pauxberger commented on MNG-5230:
-
Just to add my two cents:
This would be especially useful for automated ci-builds, i.e. to exclude
archives from the build, which usually take a long time to build but do not
offer any value to a ci build. Right now, I use the profile axis model
described in
http://www.blackbuild.com/how-to-really-use-maven-profiles-without-endangering-your-karma/
using a separate profile for ci jobs (which i would continue to use, but
differently).
Another option would be to be able to exclude modules not only in the command
line, but in a profile as well, something like:
profile
idci/id
modules
module!ear/module
/modules
/profile
or (perhaps better, but requiring a change of the model)
profile
idci/id
excludedModules
excludedModule!ear/excludedModule
/excludedModules
/profile
Command line option to exclude modules from reactor
---
Key: MNG-5230
URL: https://jira.codehaus.org/browse/MNG-5230
Project: Maven 2 3
Issue Type: New Feature
Components: Command Line
Affects Versions: 3.0.3
Reporter: Falko Modler
Every now and then I want to exclude one or more modules from a rather large
reactor build.
One reason for this can be: The respective module has tests that take long
time to execute and I know that I don't need to execute them.
Introducing yet another profile for this is not desirable for various reasons.
So, something like an opposite to -pl would come in handy. Let's say -el
for exclude list.
Example:
{code}
root
+ module a
+ module a1
+ module a2
+ module b
+ module b1
+ module c
{code}
Calling _mvn -el a1,c_ would build all modules execpt a1 and c.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5348) possibility for Interpolation just on runtime?!
Hannes Kogler created MNG-5348: -- Summary: possibility for Interpolation just on runtime?! Key: MNG-5348 URL: https://jira.codehaus.org/browse/MNG-5348 Project: Maven 2 3 Issue Type: Bug Components: Inheritance and Interpolation Affects Versions: 3.0.4 Reporter: Hannes Kogler Is there a possibility in Maven, especially when using the release-plugin, to interpolate properties just in runtime so that the files stay originally without replaced variables!? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-232) Avoid version numbers in unpacked artifact directory names
[
https://jira.codehaus.org/browse/MDEP-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=309001#comment-309001
]
Anders Hammar commented on MDEP-232:
dependency:unpack-dependencies has a stripVersion parameter.
Avoid version numbers in unpacked artifact directory names
--
Key: MDEP-232
URL: https://jira.codehaus.org/browse/MDEP-232
Project: Maven 2.x Dependency Plugin
Issue Type: Improvement
Components: unpack, unpack-dependencies
Reporter: Marc Rohlfs
Assignee: Brian Fox
Priority: Minor
It might be easier and more convenient to (re-)use the resources, that are
unpacked using the {{unpack}} or {{unpack-dependencies}} goal, with another
plugin (e.g. re-package them with the Assembly plugin), if the directory name
of the unpacked artifact doesn't include the version number.
I'd suggest 2 possible solutions:
# Those two mojos should respect the {{stripVersion}} parameter.
# Introduce another parameter like {{outputDirNameMapping}} or
{{outputFileNameMapping}} (this might be applied to the {{copy*}} mojos, too).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-379) useSubDirectoryPerArtifact creates folder with wrong format
Anders Hammar created MDEP-379: -- Summary: useSubDirectoryPerArtifact creates folder with wrong format Key: MDEP-379 URL: https://jira.codehaus.org/browse/MDEP-379 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: unpack-dependencies Affects Versions: 2.5 Environment: WinXP 32-bit, Oracle JDK 1.6.0_35, Maven 3.0.4 Reporter: Anders Hammar Priority: Minor When useSubDirectoryPerArtifact is enabled, dependency:unpack-dependencies seems to create folder acoording to the format artifactId-classifier-version-type which is not aligned with the normal artifactId-version-classifier scheme. classifier and version should switch places. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MECLIPSE-732) Remove items marked Issue: from Maven Eclipse plugin guide
Glen Mazza created MECLIPSE-732: --- Summary: Remove items marked Issue: from Maven Eclipse plugin guide Key: MECLIPSE-732 URL: https://jira.codehaus.org/browse/MECLIPSE-732 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Components: Plugin Documentation Affects Versions: 2.9 Reporter: Glen Mazza Priority: Minor Hello, on this page: http://maven.apache.org/guides/mini/guide-ide-eclipse.html#Maven_2_repository, there are several Issue: comments where people have added in things that they would like to have changed with the Maven Eclipse Plugin. I think those should be removed. If anyone finds a bug in or has enhancement suggestions for the Maven Eclipse plugin, JIRAs should be entered instead. System documentation shouldn't be used as a holder for JIRA items. At the very least, I'd like the statement: The command does not work. at the top of this page (describing the mvn eclipse:add-maven-repo command) removed. I just tested it with Eclipse Juno and JDK7 and it works fine--we don't want to scare readers that commands don't work when they actually do. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MECLIPSE-732) Remove items marked Issue: from Maven Eclipse plugin guide
[ https://jira.codehaus.org/browse/MECLIPSE-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=309017#comment-309017 ] Glen Mazza commented on MECLIPSE-732: - Also, on the page linked to above, in the Maven 2 Repository section at the top, it would be good to add a sentence letting people know that if they run mvn eclipse:add-maven-repo they will need to restart their Eclipse IDE for the M2_REPO variable to be picked up/read in. Remove items marked Issue: from Maven Eclipse plugin guide Key: MECLIPSE-732 URL: https://jira.codehaus.org/browse/MECLIPSE-732 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Components: Plugin Documentation Affects Versions: 2.9 Reporter: Glen Mazza Priority: Minor Hello, on this page: http://maven.apache.org/guides/mini/guide-ide-eclipse.html#Maven_2_repository, there are several Issue: comments where people have added in things that they would like to have changed with the Maven Eclipse Plugin. I think those should be removed. If anyone finds a bug in or has enhancement suggestions for the Maven Eclipse plugin, JIRAs should be entered instead. System documentation shouldn't be used as a holder for JIRA items. At the very least, I'd like the statement: The command does not work. at the top of this page (describing the mvn eclipse:add-maven-repo command) removed. I just tested it with Eclipse Juno and JDK7 and it works fine--we don't want to scare readers that commands don't work when they actually do. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-795) Wrong level when using release:branch
Yves Langisch created MRELEASE-795: -- Summary: Wrong level when using release:branch Key: MRELEASE-795 URL: https://jira.codehaus.org/browse/MRELEASE-795 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.3.2 Reporter: Yves Langisch Attachments: Align_baseUrl_.patch My project has different modules that reference a parent which is in its own folder. SCM part is as follows: scm connectionscm:svn:http://blabla.com/trunk/parent/connection developerConnectionscm:svn:http://blabla.com/trunk/parent/developerConnection urlhttp://blabla.com/trunk/parent/url /scm When using the release:branch goal I then only see the parent folder in my SVN-branch instead of all modules one level higher. Releasing works fine though. I've compared the classes ScmBranchPhase and ScmTagPhase. It looks like the baseDir is not aligned in the case of ScmBranchPhase. After patching the class the branch goal worked as expected. Patch attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-800) redirectTestOutputToFile is not taken into account in all cases with JUnit47 provider
[
https://jira.codehaus.org/browse/SUREFIRE-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=309041#comment-309041
]
nkeywal edited comment on SUREFIRE-800 at 9/19/12 8:05 AM:
---
2.12.3: cat target/surefire-reports/junit47ConsoleOutput.Test0-output.txt
{noformat}
Constructor
setUp
testT0
tearDown
Constructor
setUp
testT1
tearDown
{noformat}
2.13-SNAPSHOT with 800 cat
target/surefire-reports/junit47ConsoleOutput.Test0-output.txt
{noformat}
setUpBeforeClass
Constructor
setUp
testT0
tearDown
Constructor
setUp
testT1
tearDown
tearDownAfterClass
{noformat}
setUpBeforeClass / tearDownAfterClass are in the output when using the version
#800 (as expected).
But may be I misunderstood your point?
was (Author: nkeywal):
2.12.3: cat target/surefire-reports/junit47ConsoleOutput.Test0-output.txt
{noformat}
Constructor
setUp
testT0
tearDown
Constructor
setUp
testT1
tearDown
{noformat}
2.13-SNAPSHOT with 800 cat
target/surefire-reports/junit47ConsoleOutput.Test0-output.txt
{noformat}
setUpBeforeClass
Constructor
setUp
testT0
tearDown
Constructor
setUp
testT1
tearDown
tearDownAfterClass
{noformat}
setUpBeforeClass / tearDownAfterClass are in the output when using the version
#800 (as expected).
But may be I misunderstood you point?
redirectTestOutputToFile is not taken into account in all cases with JUnit47
provider
-
Key: SUREFIRE-800
URL: https://jira.codehaus.org/browse/SUREFIRE-800
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.7+ (parallel) support
Affects Versions: 2.10
Environment: all
Reporter: nkeywal
Assignee: Kristian Rosenvold
Fix For: 2.13
Attachments: 800.v1.patch
With the following class:
{noformat}
public class Test0 {
public Test0(){
System.out.println(Constructor);
}
@Test
public void testT0() throws Exception {
System.out.println(testT0);
}
@Test
public void testT1() throws Exception {
System.out.println(testT1);
}
@BeforeClass
public static void setUpBeforeClass() throws Exception {
System.out.println(setUpBeforeClass);
}
@AfterClass
public static void tearDownAfterClass() throws Exception {
System.out.println(tearDownAfterClass);
}
@Before
public void setUp() throws Exception {
System.out.println(setUp);
}
@After
public void tearDown() throws Exception {
System.out.println(tearDown);
}
}
{noformat}
Some elements of the output are not redirected with JUNit47.
{noformat}
Concurrency config is parallel='none', perCoreThreadCount=true,
threadCount=2, useUnlimitedThreads=false
setUpBeforeClass
Constructor
Constructor
tearDownAfterClass
Running Test0
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
{noformat}
While it's ok with with JUNit4:
{noformat}
---
T E S T S
---
Running Test0
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-800) redirectTestOutputToFile is not taken into account in all cases with JUnit47 provider
[
https://jira.codehaus.org/browse/SUREFIRE-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=309041#comment-309041
]
nkeywal commented on SUREFIRE-800:
--
2.12.3: cat target/surefire-reports/junit47ConsoleOutput.Test0-output.txt
{noformat}
Constructor
setUp
testT0
tearDown
Constructor
setUp
testT1
tearDown
{noformat}
2.13-SNAPSHOT with 800 cat
target/surefire-reports/junit47ConsoleOutput.Test0-output.txt
{noformat}
setUpBeforeClass
Constructor
setUp
testT0
tearDown
Constructor
setUp
testT1
tearDown
tearDownAfterClass
{noformat}
setUpBeforeClass / tearDownAfterClass are in the output when using the version
#800 (as expected).
But may be I misunderstood you point?
redirectTestOutputToFile is not taken into account in all cases with JUnit47
provider
-
Key: SUREFIRE-800
URL: https://jira.codehaus.org/browse/SUREFIRE-800
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.7+ (parallel) support
Affects Versions: 2.10
Environment: all
Reporter: nkeywal
Assignee: Kristian Rosenvold
Fix For: 2.13
Attachments: 800.v1.patch
With the following class:
{noformat}
public class Test0 {
public Test0(){
System.out.println(Constructor);
}
@Test
public void testT0() throws Exception {
System.out.println(testT0);
}
@Test
public void testT1() throws Exception {
System.out.println(testT1);
}
@BeforeClass
public static void setUpBeforeClass() throws Exception {
System.out.println(setUpBeforeClass);
}
@AfterClass
public static void tearDownAfterClass() throws Exception {
System.out.println(tearDownAfterClass);
}
@Before
public void setUp() throws Exception {
System.out.println(setUp);
}
@After
public void tearDown() throws Exception {
System.out.println(tearDown);
}
}
{noformat}
Some elements of the output are not redirected with JUNit47.
{noformat}
Concurrency config is parallel='none', perCoreThreadCount=true,
threadCount=2, useUnlimitedThreads=false
setUpBeforeClass
Constructor
Constructor
tearDownAfterClass
Running Test0
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
{noformat}
While it's ok with with JUNit4:
{noformat}
---
T E S T S
---
Running Test0
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-227) HelpMojo javadoc generated in unnamed package
Herve Boutemy created MPLUGIN-227: - Summary: HelpMojo javadoc generated in unnamed package Key: MPLUGIN-227 URL: https://jira.codehaus.org/browse/MPLUGIN-227 Project: Maven 2.x Plugin Tools Issue Type: Bug Affects Versions: 3.1, 3.0 Reporter: Herve Boutemy see http://maven.apache.org/plugins/maven-javadoc-plugin-2.9/apidocs/package-summary.html or http://maven.apache.org/plugins/maven-ear-plugin/apidocs/package-summary.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-226) Plugin documentation suggests an incorrect goal for generating descriptor
[
https://jira.codehaus.org/browse/MPLUGIN-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=309109#comment-309109
]
Herve Boutemy commented on MPLUGIN-226:
---
where precisely?
can you provide a patch?
source is here:
http://svn.apache.org/repos/asf/maven/plugin-tools/trunk/maven-plugin-plugin/src/site/apt/examples/generate-descriptor.apt.vm
Plugin documentation suggests an incorrect goal for generating descriptor
-
Key: MPLUGIN-226
URL: https://jira.codehaus.org/browse/MPLUGIN-226
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Affects Versions: 3.1
Reporter: Anthony Whitford
Priority: Minor
On this
[page|http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/generate-descriptor.html],
the goal says {{plugin}} instead of {{descriptor}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-909) Wrong elapsed time calculation
[ https://jira.codehaus.org/browse/SUREFIRE-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-909. --- Resolution: Fixed Assignee: Kristian Rosenvold Wrong elapsed time calculation --- Key: SUREFIRE-909 URL: https://jira.codehaus.org/browse/SUREFIRE-909 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.12.3 Environment: linux, likely others Reporter: nkeywal Assignee: Kristian Rosenvold Fix For: 2.13 It's a regression in 2.12.3 vs. the previous versions. See Time elapsed: 251992 sec 2.12.3 Running my.Test Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 252.358 sec FAILURE! test(my.Test) Time elapsed: 251992 sec FAILURE! java.lang.AssertionError: expected array was null 2.10 or 2.11 or 2.12.1 or 2.12.2 Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 252.444 sec FAILURE! test(my.Test) Time elapsed: 252.194 sec FAILURE! java.lang.AssertionError: expected array was null -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MANTTASKS-157) Manven-ant-tasks do not use servers list from maven conf
[
https://jira.codehaus.org/browse/MANTTASKS-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=309116#comment-309116
]
Travis Crawford commented on MANTTASKS-157:
---
I'm experiencing this same issue, where building a project that resolves
dependencies with maven-ant-tasks does not use mirrors in {{settings.xml}}. It
would be great if the solution Nikolay proposes was incorporated.
Manven-ant-tasks do not use servers list from maven conf
Key: MANTTASKS-157
URL: https://jira.codehaus.org/browse/MANTTASKS-157
Project: Maven 2.x Ant Tasks
Issue Type: Bug
Affects Versions: 2.0.10
Reporter: Krashan Brahmanjara
Attachments: manttasks-157.diff, manttasks-157.diff
I got simply ant and pom project. Settings file for maven 2.1 contains list
of mirror servers.
If I compile project by mvn package everything works ok - artifacts are
downloaded
if I compile the same project by ant and maven-ant-tasks some artifacts are
not downloaded. it looks like the mirrors list are sometimes ignored.
Current workaroud is add to pom.xml repository entries which are duplicate of
mirrors from maven configuration.
maven settings
mirrors
mirror
idkrokodylowy3/id
urlhttp://krokodylowy3.webpark.pl/maven/m2/repository/url
mirrorOfcentral/mirrorOf
/mirror
mirror
idApache.releases/id
urlhttps://repository.apache.org/content/repositories/releases//url
mirrorOfcentral/mirrorOf
/mirror
mirror
idApache.snapshots/id
urlhttps://repository.apache.org/content/repositories/snapshots//url
mirrorOfcentral/mirrorOf
/mirror
mirror
idrepository.jboss.org/id
urlhttp://repository.jboss.org/maven2/url
mirrorOfcentral/mirrorOf
/mirror
mirror
idrepo1.maven.org/id
urlhttp://repo1.maven.org/maven2/url
mirrorOf*/mirrorOf
/mirror
/mirrors
workaround
repositories
repository
idthirdparty/id
namekrokodylowy3 thirdparty/name
urlhttp://krokodylowy3.webpark.pl/maven/m2/repository/url
/repository
repository
idjboss/id
namejboss thirdparty/name
urlhttp://repository.jboss.org/maven2/url
/repository
/repositories
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHANGELOG-130) NullPointerException when no SCM url is defined
Gabriel Belingueres created MCHANGELOG-130: -- Summary: NullPointerException when no SCM url is defined Key: MCHANGELOG-130 URL: https://jira.codehaus.org/browse/MCHANGELOG-130 Project: Maven 2.x Changelog Plugin Issue Type: Bug Affects Versions: 2.2 Environment: Win 7, Java 6, Maven 3.0.4 Reporter: Gabriel Belingueres Priority: Minor A NullPointerException occurs on line 1495 of class ChangeLogReport, when the pom.xml file does not specify a scm url tag, even if the displayFileDetailUrl is specified. From what I saw in the code, the offending line is (in generateLinks() method): if ( !scmUrl.equals( linkFile ) ) reversing the comparison should be sufficient (I think): if ( !linkFile.equals( scmUrl ) ) Regards, Gabriel -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHANGELOG-131) Resource bundle for Spanish Argentina
Gabriel Belingueres created MCHANGELOG-131: -- Summary: Resource bundle for Spanish Argentina Key: MCHANGELOG-131 URL: https://jira.codehaus.org/browse/MCHANGELOG-131 Project: Maven 2.x Changelog Plugin Issue Type: Improvement Affects Versions: 2.2 Reporter: Gabriel Belingueres Priority: Minor Attachments: scm-activity_es_AR.properties I created an scm-activity_es_AR.properties file to support Spanish Argentina, which I attach to this issue. Regards, Gabriel -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-141) Show correct version of the enforcer api / plugin in example
Karl Heinz Marbaise created MENFORCER-141: - Summary: Show correct version of the enforcer api / plugin in example Key: MENFORCER-141 URL: https://jira.codehaus.org/browse/MENFORCER-141 Project: Maven 2.x Enforcer Plugin Issue Type: Improvement Components: Rule API Affects Versions: 1.1.1 Reporter: Karl Heinz Marbaise Priority: Minor I have observed that the version of the maven-enforcer-plugin in the [example|http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html] is not correctly shown. Currently the 1.0-beta-1 is shown which should be changed to the current one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5349) NullPointerException if missing id in org.apache.maven.lifecycle.Lifecycle
John Riedl created MNG-5349: --- Summary: NullPointerException if missing id in org.apache.maven.lifecycle.Lifecycle Key: MNG-5349 URL: https://jira.codehaus.org/browse/MNG-5349 Project: Maven 2 3 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 3.0.4 Environment: Ubuntu Precise, Maven 3.0.4 Reporter: John Riedl Priority: Minor Attachments: components.xml, lifecycles.xml, phase-test.tar, pom.xml I've been working with custom lifecycles, and accidentally left the id out of one of them. You can see it in this example where I commented out the key line (everything works fine if this line is uncommented): component-set components component roleorg.apache.maven.lifecycle.mapping.LifecycleMapping/role role-hintphase-test/role-hint implementation org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping /implementation /component component roleorg.apache.maven.lifecycle.Lifecycle/role role-hintphase-test/role-hint implementationorg.apache.maven.lifecycle.Lifecycle/implementation configuration !-- idphase-test/id -- phases phasetp-pre-new-phase/phase phasetp-new-phase/phase phasetp-post-new-phase/phase /phases default-phases tp-new-phaseorg.riedl:phase-test-maven-plugin:greet/tp-new-phase /default-phases /configuration /component /components /component-set ~ Here's most of the stack trace: (macro: ~/Src/lenskit-projects/tryout-phase-test-plugin) mvn tp-post-new-phase [INFO] Scanning for projects... [ERROR] Internal error: java.lang.NullPointerException - [Help 1] org.apache.maven.InternalErrorException: Internal error: java.lang.NullPointerException at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: java.lang.NullPointerException at java.lang.String.compareTo(String.java:1167) at org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer$1.compare(DefaultLifecyclePluginAnalyzer.java:144) at org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer$1.compare(DefaultLifecyclePluginAnalyzer.java:140) at java.util.Arrays.mergeSort(Arrays.java:1270) at java.util.Arrays.sort(Arrays.java:1210) at java.util.Collections.sort(Collections.java:159) at org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer.getOrderedLifecycles(DefaultLifecyclePluginAnalyzer.java:139) at org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer.getPluginsBoundByDefaultToAllLifecycles(DefaultLifecyclePluginAnalyzer.java:96) at org.apache.maven.model.plugin.DefaultLifecycleBindingsInjector.injectLifecycleBindings(DefaultLifecycleBindingsInjector.java:63) at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:397) at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:371) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:560) The NullPointerException happens with most attempts to run the project, such as mvn foo. I've attached the pom.xml, lifecycles.xml, components.xml, and the Java for the plugin. I think only components.xml is relevant. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-141) Show correct version of the enforcer api / plugin in example
[ https://jira.codehaus.org/browse/MENFORCER-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MENFORCER-141: -- Attachment: patch-MENFORCER-144.patch Patch file for the appropriate issue. Show correct version of the enforcer api / plugin in example Key: MENFORCER-141 URL: https://jira.codehaus.org/browse/MENFORCER-141 Project: Maven 2.x Enforcer Plugin Issue Type: Improvement Components: Rule API Affects Versions: 1.1.1 Reporter: Karl Heinz Marbaise Priority: Minor Attachments: patch-MENFORCER-144.patch I have observed that the version of the maven-enforcer-plugin in the [example|http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html] is not correctly shown. Currently the 1.0-beta-1 is shown which should be changed to the current one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-602) Multiple Assemblies Causes Infinite Loop\Recursion
[ https://jira.codehaus.org/browse/MASSEMBLY-602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MASSEMBLY-602. Resolution: Fixed Fix Version/s: 2.4 Assignee: Kristian Rosenvold Fixed in r1387716 Multiple Assemblies Causes Infinite Loop\Recursion -- Key: MASSEMBLY-602 URL: https://jira.codehaus.org/browse/MASSEMBLY-602 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-3, 2.2-beta-5, 2.2, 2.2.1, 2.2.2, 2.3 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800) Java version: 1.6.0_29, vendor: Sun Microsystems Inc. Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: x86, family: windows [also, maven 2] Reporter: Shaun Assignee: Kristian Rosenvold Fix For: 2.4 I have a custom assembly.xml on a project that also has a parent pom. In the parent pom, we specify: appendAssemblyIdtrue/appendAssemblyId As the default assembly (jar-with-dependencies-and-sources) is fine for 99% of our projects, however, in this instance, I need the custom assembly. However, the parent pom dicates: appendAssemblyIdfalse/appendAssemblyId Causing this error: Exception in thread main java.lang.StackOverflowError at sun.nio.cs.SingleByteEncoder.encodeArrayLoop(SingleByteEncoder.java:91) at sun.nio.cs.SingleByteEncoder.encodeLoop(SingleByteEncoder.java:130) at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:544) at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:252) at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106) at java.io.OutputStreamWriter.write(OutputStreamWriter.java:190) at java.io.BufferedWriter.flushBuffer(BufferedWriter.java:111) at java.io.PrintStream.write(PrintStream.java:476) at java.io.PrintStream.print(PrintStream.java:619) at org.apache.maven.cli.PrintStreamLogger.info(PrintStreamLogger.java:110) at org.codehaus.plexus.logging.AbstractLogger.info(AbstractLogger.java:51) at org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:464) at org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:467) at org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:467) I believe this error to be related to PLXUTILS-148 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSKINS-70) external.png is used in css but not present in code base
Eric Barboni created MSKINS-70: -- Summary: external.png is used in css but not present in code base Key: MSKINS-70 URL: https://jira.codehaus.org/browse/MSKINS-70 Project: Maven Skins Issue Type: Bug Components: Fluido Skin Affects Versions: fluido-1.3.1 Reporter: Eric Barboni Priority: Trivial Attachments: maven-theme.css.patch Proposed patch is to remove reference in css. But can be the other way around adding external.png to code base. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
