[jira] (MRELEASE-780) Prevent Tag from additional commits
[ https://jira.codehaus.org/browse/MRELEASE-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319663#comment-319663 ] Darryl L. Miles commented on MRELEASE-780: -- I looked at things in mid Jan 2013 but am waiting for a bunch of my own bugs with provided patches to be applied to the appropriate tree before I waste any additional time looking and helping with resolving other bugs for the Maven project suite. I use the term 'waste' since some patches attached to Apache Maven related JIRA maybe as much as ~1 year old and I think there are at least 5 or more bugs with patches on this JIRA somewhere. If the maintainers don't have time to process them I don't have time to write patches. Plenty of other open source projects exist that are in need of spare development time and expertise. Sorry if this is not the answer you were hoping for maybe you have time to petition the appropriate maintainers in my behalf to try to make progress ion this basic open source project maintenance responsibility. > Prevent Tag from additional commits > > > Key: MRELEASE-780 > URL: https://jira.codehaus.org/browse/MRELEASE-780 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: branch >Affects Versions: 2.3.2 >Reporter: W I > > If you create an release from the branch there should be no commits on the > tag-folder. -- 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-644) Exclusions in dependencySet inside moduleSet->binaries have no effect
[
https://jira.codehaus.org/browse/MASSEMBLY-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319657#comment-319657
]
Maik Riechert commented on MASSEMBLY-644:
-
Sorry, made a mistake on formatting and can't edit it. The bold parts are
surrounded by stars...
> Exclusions in dependencySet inside moduleSet->binaries have no effect
> -
>
> Key: MASSEMBLY-644
> URL: https://jira.codehaus.org/browse/MASSEMBLY-644
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Components: dependencySet, filtering, moduleSet
>Affects Versions: 2.4
>Reporter: Maik Riechert
>
> I'm trying to create a distribution assembly of a multi-module project in a
> separate distribution module which works quite nice, except that exclusions
> of dependencies of modules seem to be ignored. This is strange, as the same
> exclusions do work in an assembly inside a submodule.
> This is the problematic descriptor:
> {{
>
>
> lwjgl
>
> zip
>
> false
>
>
> true
>
> com.ardor3d:ardor3d-animation
> com.ardor3d:ardor3d-awt
> com.ardor3d:ardor3d-collada
> com.ardor3d:ardor3d-core
> com.ardor3d:ardor3d-effects
> com.ardor3d:ardor3d-extras
> com.ardor3d:ardor3d-lwjgl
> com.ardor3d:ardor3d-math
> com.ardor3d:ardor3d-savable
> com.ardor3d:ardor3d-swt
> com.ardor3d:ardor3d-terrain
> com.ardor3d:ardor3d-ui
>
>
> false
>
>
>
>
> *:lwjgl*natives-*
>
> *:jinput*natives-*
>
>
>
>
>
>
>
>
> target/natives
> natives
>
> *jogl*
> *nativewindow*
> *newt*
> *gluegen*
> META-INF/
>
>
>
>
> }}
> This assembly descriptor can be found here:
> https://github.com/neothemachine/Ardor3D/blob/assembly/ardor3d-distribution/assembly-lwjgl.xml
> It produces a zip which also contains
> "lwjgl-platform-2.8.4-natives-linux.jar" and others which should be matched
> by the filter.
> The submodule where the exclusions work can be found at:
> https://github.com/neothemachine/Ardor3D/tree/assembly/ardor3d-examples
> If you need any other information, please tell me.
--
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-644) Exclusions in dependencySet inside moduleSet->binaries have no effect
Maik Riechert created MASSEMBLY-644:
---
Summary: Exclusions in dependencySet inside moduleSet->binaries
have no effect
Key: MASSEMBLY-644
URL: https://jira.codehaus.org/browse/MASSEMBLY-644
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Components: dependencySet, filtering, moduleSet
Affects Versions: 2.4
Reporter: Maik Riechert
I'm trying to create a distribution assembly of a multi-module project in a
separate distribution module which works quite nice, except that exclusions of
dependencies of modules seem to be ignored. This is strange, as the same
exclusions do work in an assembly inside a submodule.
This is the problematic descriptor:
{{
lwjgl
zip
false
true
com.ardor3d:ardor3d-animation
com.ardor3d:ardor3d-awt
com.ardor3d:ardor3d-collada
com.ardor3d:ardor3d-core
com.ardor3d:ardor3d-effects
com.ardor3d:ardor3d-extras
com.ardor3d:ardor3d-lwjgl
com.ardor3d:ardor3d-math
com.ardor3d:ardor3d-savable
com.ardor3d:ardor3d-swt
com.ardor3d:ardor3d-terrain
com.ardor3d:ardor3d-ui
false
*:lwjgl*natives-*
*:jinput*natives-*
target/natives
natives
*jogl*
*nativewindow*
*newt*
*gluegen*
META-INF/
}}
This assembly descriptor can be found here:
https://github.com/neothemachine/Ardor3D/blob/assembly/ardor3d-distribution/assembly-lwjgl.xml
It produces a zip which also contains "lwjgl-platform-2.8.4-natives-linux.jar"
and others which should be matched by the filter.
The submodule where the exclusions work can be found at:
https://github.com/neothemachine/Ardor3D/tree/assembly/ardor3d-examples
If you need any other information, please tell me.
--
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-5434) Maven version ranges do not properly handle versions with more than four components
[ https://jira.codehaus.org/browse/MNG-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319656#comment-319656 ] Karl M. Davis commented on MNG-5434: Actually, I was incorrect about Aether: API calls are sorting artifact versions correctly. For example, org.sonatype.aether.RepositorySystem.resolveVersionRange(RepositorySystemSession, VersionRangeRequest) is working as expected. > Maven version ranges do not properly handle versions with more than four > components > --- > > Key: MNG-5434 > URL: https://jira.codehaus.org/browse/MNG-5434 > Project: Maven 2 & 3 > Issue Type: Bug > Components: General >Affects Versions: 3.0.4 > Environment: Linux 64-bit >Reporter: Karl M. Davis > > When using a version range, e.g. "[1.0-SNAPSHOT,)", versions with more than > four components are not sorted correctly. For example, "1.0.0.0" will be > sorted as greater/later than "1.0.0.0.0". However, "1.0.0" will be sorted as > greater/later than "1.0.0.0". > The behavior here is a bit odd... all of the maven-metadata-XXX.xml files in > the local repository will correctly list "1.0.0.0.0" as the "latest" and > "release" version, but running compile, dependency:tree, etc. will instead > select "1.0.0.0". Aether API calls are also exhibiting the buggy sorting > behavior, too. > I haven't yet tried any debugging to track this down, but I've trolled > through git and my best guess is that this behavior is related to the version > of maven-artifact being used. The 2.x releases > DefaultArtifactVersion.compareTo(...) method does not correctly handle > versions with more than four components, but the 3.x releases of it do [1]. > Maybe the problem is just that [the compile plugin is still using > maven-artifact:2.0.9|http://maven.apache.org/plugins/maven-compiler-plugin/dependencies.html]? > This is hurting us here. While many of our projects use versions with four or > less components, we follow the [add a version component for branches > versioning > strategy|http://janvanbesien.blogspot.com/2009/06/consistent-svn-brach-and-tag-names-for.html] > to prevent version conflicts between branches. This allows us to use version > ranges in our POMs, making life a lot easier. > [1] The following commit seems to be where this was fixed in maven-artifact: > [maven.git > beb9d731691beed1b0099a790a8ae1973f55dc0b|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=beb9d731691beed1b0099a790a8ae1973f55dc0b]. > It looks like the code is what was originally proposed in the [Improve > default support for version > schemes|http://docs.codehaus.org/display/MAVEN/Versioning] Maven wiki page. -- 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-5434) Maven version ranges do not properly handle versions with more than four components
Karl M. Davis created MNG-5434: -- Summary: Maven version ranges do not properly handle versions with more than four components Key: MNG-5434 URL: https://jira.codehaus.org/browse/MNG-5434 Project: Maven 2 & 3 Issue Type: Bug Components: General Affects Versions: 3.0.4 Environment: Linux 64-bit Reporter: Karl M. Davis When using a version range, e.g. "[1.0-SNAPSHOT,)", versions with more than four components are not sorted correctly. For example, "1.0.0.0" will be sorted as greater/later than "1.0.0.0.0". However, "1.0.0" will be sorted as greater/later than "1.0.0.0". The behavior here is a bit odd... all of the maven-metadata-XXX.xml files in the local repository will correctly list "1.0.0.0.0" as the "latest" and "release" version, but running compile, dependency:tree, etc. will instead select "1.0.0.0". Aether API calls are also exhibiting the buggy sorting behavior, too. I haven't yet tried any debugging to track this down, but I've trolled through git and my best guess is that this behavior is related to the version of maven-artifact being used. The 2.x releases DefaultArtifactVersion.compareTo(...) method does not correctly handle versions with more than four components, but the 3.x releases of it do [1]. Maybe the problem is just that [the compile plugin is still using maven-artifact:2.0.9|http://maven.apache.org/plugins/maven-compiler-plugin/dependencies.html]? This is hurting us here. While many of our projects use versions with four or less components, we follow the [add a version component for branches versioning strategy|http://janvanbesien.blogspot.com/2009/06/consistent-svn-brach-and-tag-names-for.html] to prevent version conflicts between branches. This allows us to use version ranges in our POMs, making life a lot easier. [1] The following commit seems to be where this was fixed in maven-artifact: [maven.git beb9d731691beed1b0099a790a8ae1973f55dc0b|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=beb9d731691beed1b0099a790a8ae1973f55dc0b]. It looks like the code is what was originally proposed in the [Improve default support for version schemes|http://docs.codehaus.org/display/MAVEN/Versioning] Maven wiki page. -- 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-738) NullPointerException in LinkedResource if is present in .project
Martin Böhm created MECLIPSE-738:
Summary: NullPointerException in LinkedResource if
is present in .project
Key: MECLIPSE-738
URL: https://jira.codehaus.org/browse/MECLIPSE-738
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.9
Reporter: Martin Böhm
Priority: Trivial
Attachments: linkedResourceProblem.zip
I get a reproducable NullPointerException if I call eclipse:eclipse on a
project that always has a .project-file that contains links with
-Tags.
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-eclipse-plugin:2.9:eclipse (default-cli) on
project linkedResourceProblem: Execution def
ault-cli of goal org.apache.maven.plugins:maven-eclipse-plugin:2.9:eclipse
failed. NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-eclipse-plugin:2.9:eclipse (default-cli)
on project linkedResourceProblem: Execution default-cli of goal
org.apache.maven.plugins:maven-eclipse-plugin:2.9:eclipse 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.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
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:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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: org.apache.maven.plugin.PluginExecutionException: Execution
default-cli of goal org.apache.maven.plugins:maven-eclipse-plugin:2.9:eclipse f
ailed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.NullPointerException
at
org.apache.maven.plugin.eclipse.LinkedResource.(LinkedResource.java:131)
at
org.apache.maven.plugin.eclipse.writers.EclipseProjectWriter.write(EclipseProjectWriter.java:154)
at
org.apache.maven.plugin.eclipse.EclipsePlugin.writeConfiguration(EclipsePlugin.java:1232)
at
org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:511)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
{code}
If I change the present to in .project and call
eclipse:eclipse I won't get the error. Also if I call eclipse:clean before
calling eclipse:eclipse the .project file of course gets cleaned and will be
created new, so temporary links get lost unfortunately.
I suppose it has to do with the following lines in
org.apache.maven.plugin.eclipse.LinkedResource and how the locationNode is
retrieved.
{code}
119 Xpp3Dom locationNode = node.getChild( "location" );
120 Xpp3Dom locationURINode = node.getChild( "locationURI" );
{code}
Possible workarounds:
- Call eclipse:clean before and recreate temporary links again.
- Replace all with before calling eclipse:eclipse to
preserve temporary links.
--
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] (MINVOKER-149) Possibility to have different settings.xml per IT
Anders Hammar created MINVOKER-149: -- Summary: Possibility to have different settings.xml per IT Key: MINVOKER-149 URL: https://jira.codehaus.org/browse/MINVOKER-149 Project: Maven 2.x Invoker Plugin Issue Type: Improvement Environment: n/a Reporter: Anders Hammar Today you can only specify a settings.xml that is used for all ITs. It would sometimes be good to be able to specify different settings.xml per IT. That settings should then override the "global" 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] (MENFORCER-143) 'All' propery is not handled by RequireActiveProfile rule
[
https://jira.codehaus.org/browse/MENFORCER-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319647#comment-319647
]
Matthew Adams commented on MENFORCER-143:
-
Now discussed on maven-user list:
http://maven.40175.n5.nabble.com/Why-is-the-functionality-of-the-all-attribute-of-the-RequireActiveProfile-rule-commented-out-tp5746380.html
> 'All' propery is not handled by RequireActiveProfile rule
> -
>
> Key: MENFORCER-143
> URL: https://jira.codehaus.org/browse/MENFORCER-143
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 1.1.1
>Reporter: Maciej Kwiecien
> Attachments: HandlingAllPropertyInRequireActiveProfileRule.patch,
> HandlingAllPropertyInRequireActiveProfileRuleSimplified.patch
>
>
> Although you have rules configured, as follows:
> {code}
> ...
>
>
>
> dev,selenium
> false
>
>
> true
>
> {code}
> And you run build : mvn clean install *-Pselenium*
> You still get error:
> {code}
> Supported profiles: selenium,dev
> Profile "dev" is not activated.
> {code}
> Fix is quite simple (tested on tag 1.1.1 and trunk) - please find in
> attachment.
> Best Regards,
> Maciej
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-128) Too many warnings "We have duplicates"
[ https://jira.codehaus.org/browse/MSHADE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319632#comment-319632 ] Binod Pant commented on MSHADE-128: --- I am voting for this fix too. Our logs are several MBs in size with these warnings. > Too many warnings "We have duplicates" > -- > > Key: MSHADE-128 > URL: https://jira.codehaus.org/browse/MSHADE-128 > Project: Maven 2.x Shade Plugin > Issue Type: Improvement >Affects Versions: 1.7.1 >Reporter: Raffaele >Assignee: Benson Margulies > Attachments: pom.xml, warning-we-have-duplicates.patch > > > When creating an uberjar, sometimes the same class is present in two or more > dependencies' JARs. For each class, maven-shade-plugin issues a WARNING We > have a duplicate in. > This is annoying and can muddle newcomers up (like myself), because it's not > clear how to fix. > I don't know if a programmatic solution to these warnings could exist: maybe > it will always require human interaction. However, it's better to point users > in the right direction and not spit out thousands of useless warnings. > Attached is a pom which triggers thousands of warnings and a patch with a > prettier (and hopefully more useful) output like > [WARNING] bcprov-jdk14-138.jar, bcprov-jdk14-1.38.jar define 1292 > overlappping classes: > [WARNING] - org.bouncycastle.asn1.ocsp.ResponderID > [WARNING] - org.bouncycastle.crypto.params.DSAPublicKeyParameters > [WARNING] - org.bouncycastle.crypto.engines.DESEngine > [WARNING] - org.bouncycastle.jce.provider.JCEElGamalPrivateKey > [WARNING] - org.bouncycastle.jce.provider.JCEStreamCipher$Skipjack_CFB8 > [WARNING] - org.bouncycastle.jce.provider.JCESecretKeyFactory > [WARNING] - org.bouncycastle.i18n.filter.UntrustedInput > [WARNING] - org.bouncycastle.asn1.x9.X962NamedCurves$5 > [WARNING] - org.bouncycastle.jce.X509KeyUsage > [WARNING] maven-shade-plugin has detected that some .class files > [WARNING] are present in two or more JARs. When this happens, only > [WARNING] one single version of the class is copied in the uberjar. > [WARNING] Usually this is not harmful and you can skeep these > [WARNING] warnings, otherwise try to manually exclude artifacts > [WARNING] based on mvn dependency:tree -Ddetail=true and the above > [WARNING] output > [WARNING] See http://docs.codehaus.org/display/MAVENUSER/Shade+Plugin -- 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
