[jira] Created: (MNG-5066) Unable to customize Dependencies version ordering while using range in dependency version tag
Unable to customize Dependencies version ordering while using range in
dependency version tag
--
Key: MNG-5066
URL: http://jira.codehaus.org/browse/MNG-5066
Project: Maven 2 3
Issue Type: Improvement
Components: Artifacts and Repositories, Dependencies
Affects Versions: 2.2.1
Reporter: Aziz Joumady
Priority: Minor
Hi all,
Currently, Maven fails to properly resolve dependencies while version follow
this pattern :
[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*-[alpha|beta|rc]-[0-9][0-9]*
e.g.
1.0.0-alpha-2
1.0.0-alpha-10
1.0.0-beta-3
etc.
As described in following link
http://www.sonatype.com/books/maven-book/reference/pom-relationships-sect-pom-syntax.html
{quote}
One gotcha for release version numbers is the ordering of the qualifiers. Take
the version release numbers 1.2.3-alpha-2 and 1.2.3-alpha-10, where the
alpha-2 build corresponds to the 2nd alpha build, and the alpha-10 build
corresponds to the 10th alpha build. Even though alpha-10 should be
considered more recent than alpha-2, Maven is going to sort alpha-10 before
alpha-2 due to a known issue in the way Maven handles version numbers.
Maven is supposed to treat the number after the qualifier as a build number. In
other words, the qualifier should be alpha, and the build number should be 2.
Even though Maven has been designed to separate the build number from the
qualifier, this parsing is currently broken. As a result, alpha-2 and
alpha-10 are compared using a String comparison, and alpha-10 comes before
alpha-2 alphabetically. To get around this limitation, you will need to
left-pad your qualified build numbers. If you use alpha-02 and alpha-10
this problem will go away, and it will continue to work once Maven properly
parses the version build number.
{quote}
Is it possible to add a new feature enabling to customize the way Maven
compares version resolution?
Adding for example a regular expression pattern.
Kind regards,
Aziz
--
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: (MNG-5066) Unable to customize Dependencies version ordering while using range in dependency version tag
[
http://jira.codehaus.org/browse/MNG-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-5066.
--
Resolution: Duplicate
Assignee: Benjamin Bentmann
Unable to customize Dependencies version ordering while using range in
dependency version tag
--
Key: MNG-5066
URL: http://jira.codehaus.org/browse/MNG-5066
Project: Maven 2 3
Issue Type: Improvement
Components: Artifacts and Repositories, Dependencies
Affects Versions: 2.2.1
Reporter: Aziz Joumady
Assignee: Benjamin Bentmann
Priority: Minor
Hi all,
Currently, Maven fails to properly resolve dependencies while version follow
this pattern :
[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*-[alpha|beta|rc]-[0-9][0-9]*
e.g.
1.0.0-alpha-2
1.0.0-alpha-10
1.0.0-beta-3
etc.
As described in following link
http://www.sonatype.com/books/maven-book/reference/pom-relationships-sect-pom-syntax.html
{quote}
One gotcha for release version numbers is the ordering of the qualifiers.
Take the version release numbers 1.2.3-alpha-2 and 1.2.3-alpha-10, where
the alpha-2 build corresponds to the 2nd alpha build, and the alpha-10
build corresponds to the 10th alpha build. Even though alpha-10 should be
considered more recent than alpha-2, Maven is going to sort alpha-10
before alpha-2 due to a known issue in the way Maven handles version
numbers.
Maven is supposed to treat the number after the qualifier as a build number.
In other words, the qualifier should be alpha, and the build number should
be 2. Even though Maven has been designed to separate the build number from
the qualifier, this parsing is currently broken. As a result, alpha-2 and
alpha-10 are compared using a String comparison, and alpha-10 comes
before alpha-2 alphabetically. To get around this limitation, you will need
to left-pad your qualified build numbers. If you use alpha-02 and
alpha-10 this problem will go away, and it will continue to work once Maven
properly parses the version build number.
{quote}
Is it possible to add a new feature enabling to customize the way Maven
compares version resolution?
Adding for example a regular expression pattern.
Kind regards,
Aziz
--
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: (MCHANGES-233) Add option to skip announcement if there are no changes or changes.xml file is missing
Add option to skip announcement if there are no changes or changes.xml file is missing -- Key: MCHANGES-233 URL: http://jira.codehaus.org/browse/MCHANGES-233 Project: Maven 2.x Changes Plugin Issue Type: Improvement Affects Versions: 2.4 Reporter: Ivan Khalopik It will be good to have some option to skip announcement generation if there are no changes for artifact. Now if there are no changes build fails with error: No releases found in any of the configured issue management systems. -- 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: (MCHANGES-234) Add GitHub issue template
Add GitHub issue template - Key: MCHANGES-234 URL: http://jira.codehaus.org/browse/MCHANGES-234 Project: Maven 2.x Changes Plugin Issue Type: New Feature Components: other issue-trackers Affects Versions: 2.4 Reporter: Ivan Khalopik There are an issue tracker on GitHub. It has the same configuration as JIRA. Issue management section can be configure as following: issueManagement systemGitHub/system urlhttps://github.com/sody/greatage/issues//url /issueManagement NOTE: Ending slash is mandatory. Changes plugin configuration will look like this: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-changes-plugin/artifactId version2.4/version configuration issueLinkTemplatePerSystem GitHub%URL%/%ISSUE%/GitHub /issueLinkTemplatePerSystem /configuration /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] Created: (MCHANGES-235) Add some kind of aggregated report
Add some kind of aggregated report -- Key: MCHANGES-235 URL: http://jira.codehaus.org/browse/MCHANGES-235 Project: Maven 2.x Changes Plugin Issue Type: New Feature Affects Versions: 2.4 Reporter: Ivan Khalopik Actually report mojos generate report for the project it executed for. It will be a nice feature if this plugin could generate an aggregate report that will look up for changes in child modules (e.g like in javadoc plugin http://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html). -- 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
package org.apache.xpath does not exist
I am able to build project in eclipse. When i am trying to compile the project with compiler:compile goal I am getting this error [ERROR] package org.apache.xpath does not exist This package is not available in central repository. After installing from 3rd party jar file maven still shows org.apace.xpath does not exist. -- View this message in context: http://maven.40175.n5.nabble.com/package-org-apache-xpath-does-not-exist-tp4310704p4310704.html Sent from the Maven - Issues mailing list archive at Nabble.com.
[jira] Created: (SUREFIRE-727) Classpath too long on windows with useManifestOnlyJar=false
Classpath too long on windows with useManifestOnlyJar=false
---
Key: SUREFIRE-727
URL: http://jira.codehaus.org/browse/SUREFIRE-727
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.8.1
Reporter: kevin aloisi
Priority: Critical
If the useMandifestOnlyJar=false, then then jnuit won't run on windows because
the classpath is to long. The better way to fork a java process is to set the
CLASSPATH env variable instead of passing it on the command line.
This patch fixes the issue.
Index:
src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkConfiguration.java
===
---
src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkConfiguration.java
(revision 1092789)
+++
src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkConfiguration.java
(working copy)
@@ -221,13 +221,13 @@
}
else
{
-cli.createArg().setValue( -classpath );
-
-cli.createArg().setValue( StringUtils.join( classPath.iterator(),
File.pathSeparator ) );
+//cli.createArg().setValue( -classpath );
+//cli.createArg().setValue( StringUtils.join(
classPath.iterator(), File.pathSeparator ) );
+ cli.addEnvironment(CLASSPATH,StringUtils.join(
classPath.iterator(), File.pathSeparator ));
+
+ final String forkedBooter = ForkedBooter.class.getName();
-final String forkedBooter = ForkedBooter.class.getName();
-
-cli.createArg().setValue( shadefire ? new Relocator( ).relocate(
forkedBooter ) : forkedBooter);
+ cli.createArg().setValue( shadefire ? new Relocator( ).relocate(
forkedBooter ) : forkedBooter);
}
cli.setWorkingDirectory( workingDirectory.getAbsolutePath() );
--
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: (MASSEMBLY-556) mvn assembly:assembly NPEs with install:install-file'd artifacts
[
http://jira.codehaus.org/browse/MASSEMBLY-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-556:
-
Fix Version/s: 2.3
Assignee: John Casey
mvn assembly:assembly NPEs with install:install-file'd artifacts
Key: MASSEMBLY-556
URL: http://jira.codehaus.org/browse/MASSEMBLY-556
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-5
Environment: Maven 3.0.3 (r1075438; 2011-02-28 17:31:09+) on Win
7 x64, Sun Java 6u24 x64.
Reporter: Chris West (Faux)
Assignee: John Casey
Fix For: 2.3
Attachments: build.log, pom.xml, repository.xml
I have 3rd-party jars installed via. {{mvn install:install-file}}. This
causes {{mvn assembly:assembly}} to NPE around:
{code}
Caused by: java.lang.NullPointerException
at
org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.getLocalFilename(AbstractRepositoryMetadata.java:61)
at
org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOfLocalRepositoryMetadata(DefaultRepositoryLayout.java:72)
...
{code}
To reproduce, first, install:install-file a random file:
{code}
mvn install:install-file -Dfile=pom.xml -DgroupId=com.goeswhere.test
-DartifactId=a -Dversion=0 -Dpackaging=jar
{code}
Then, create pom.xml (attached):
{code:xml}
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.goeswhere.test/groupId
artifactIdb/artifactId
version1.0-SNAPSHOT/version
packagingjar/packaging
dependencies
dependency
groupIdcom.goeswhere.test/groupId
artifactIda/artifactId
version0/version
/dependency
/dependencies
build
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
configuration
descriptors
descriptor./repository.xml/descriptor
/descriptors
/configuration
/plugin
/plugins
/build
/project
{code}
and repository.xml (attached):
{code:xml}
assembly
xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd;
idrepository/id
formats
formatjar/format
/formats
repositories
repository
includeMetadatatrue/includeMetadata
outputDirectorymaven2/outputDirectory
/repository
/repositories
/assembly
{code}
And run {{mvn assembly:assembly}}. See attached build.log.
--
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: (MCHANGES-233) Add option to skip announcement if there are no changes or changes.xml file is missing
[ http://jira.codehaus.org/browse/MCHANGES-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263862#action_263862 ] Dennis Lundberg commented on MCHANGES-233: -- Hi How could we determine that there are no changes? Are you using only a changes.xml file? Add option to skip announcement if there are no changes or changes.xml file is missing -- Key: MCHANGES-233 URL: http://jira.codehaus.org/browse/MCHANGES-233 Project: Maven 2.x Changes Plugin Issue Type: Improvement Affects Versions: 2.4 Reporter: Ivan Khalopik It will be good to have some option to skip announcement generation if there are no changes for artifact. Now if there are no changes build fails with error: No releases found in any of the configured issue management systems. -- 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: (MCHANGES-235) Add some kind of aggregated report
[ http://jira.codehaus.org/browse/MCHANGES-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-235. Resolution: Duplicate Add some kind of aggregated report -- Key: MCHANGES-235 URL: http://jira.codehaus.org/browse/MCHANGES-235 Project: Maven 2.x Changes Plugin Issue Type: New Feature Affects Versions: 2.4 Reporter: Ivan Khalopik Actually report mojos generate report for the project it executed for. It will be a nice feature if this plugin could generate an aggregate report that will look up for changes in child modules (e.g like in javadoc plugin http://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html). -- 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: (MDEP-275) Figuring out duplicate class definitions using the Analyze goal
[ http://jira.codehaus.org/browse/MDEP-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263872#action_263872 ] Stephen Connolly commented on MDEP-275: --- See https://svn.codehaus.org/mojo/trunk/sandbox/extra-enforcer-rules/src/main/java/org/codehaus/mojo/enforcer/rule/BanDuplicateClassesRule.java@13945 Figuring out duplicate class definitions using the Analyze goal --- Key: MDEP-275 URL: http://jira.codehaus.org/browse/MDEP-275 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: analyze Affects Versions: 2.1 Reporter: Petter Måhlén Assignee: Brian Fox Attachments: dependency-analyzer.diff, dependency-plugin.diff Hi, I've pretty frequently run into issues where changes to the library structure of some product (that is, changing the way that classes are grouped into libraries) leads to the same classes being defined in more than one place. This can lead to system-dependent problems, because different versions of the same class are being loaded by different systems. I was going to create a new goal for the dependency plugin to check for duplicate classes, but when I looked a bit closer at the analyze goal, it already had all the information needed to do that check as well, so I came up with some changes that add this functionality. The intended usage is something like: mvn dependency:analyze -DcheckDuplicateClasses I get the feeling that I might want to add the ability to exclude certain packages (that I might be comfortable are safe to have duplicates of), so I added this option too: mvn dependency:analyze -DcheckDuplicateClasses -DexcludePrefixes=org., net.sf.cglib, javax.xml, junit. The output looks something like: [WARNING] Duplicate class definitions found: [WARNING]com.shopzilla.common.data.ObjectFactory defined in: [WARNING] com.shopzilla.site.url.c14n:model:jar:1.4:compile [WARNING] com.shopzilla.common.data:data-model-schema:jar:1.11:compile [WARNING]com.shopzilla.site.category.CategoryProvider defined in: [WARNING] com.shopzilla.site2.sasClient:sas-client-core:jar:5.47:compile [WARNING] com.shopzilla.site2.service:common-web:jar:5.50:compile A couple of notes: - I was unable to get configuration (setting checkDuplicateClasses, etc.) using the pom to work, but I think that might be due to lack of understanding on my part. - I don't fully understand the effect of calling compileProject() during unit tests, but I think it may be sufficient to call it only once for the duplicateClasses project, during setUp(). That would speed up the unit tests. - I haven't added duplicate class definition checking to the AnalyzeReportMojo, because I wanted to get some feedback on whether this addition was felt to be valuable before spending any time on that. - A lot of the unit test dummy code in the attached diff files needs cleaning up, but again I wanted to wait with that until hearing whether this might be useful to others. - I made an API change in the ProjectDependencyAnalyzer interface, which might be an issue if there are other implementations than the default one. That change was only needed to support the 'exclude package' feature, which might not be super-important. Cheers, Petter -- 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
