[jira] Commented: (SCM-483) Update SCM Perforce Provider to use P4Java
[ http://jira.codehaus.org/browse/SCM-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231275#action_231275 ] Brian Jackson commented on SCM-483: --- Actually, I had to release it so Sonatype could review it before they turn on the auto-sync to Central. Its now available at the following link before its on its way to Central. https://oss.sonatype.org/content/groups/public/com/perforce/p4java/2009.3/ > Update SCM Perforce Provider to use P4Java > -- > > Key: SCM-483 > URL: http://jira.codehaus.org/browse/SCM-483 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-perforce >Affects Versions: 1.2 >Reporter: Tom Rodriguez > Fix For: future > > Attachments: maven-scm-perforce-p4java.jar > > > Perforce has developed a new Java Native API for access to perforce called > P4Java. You can access it here: > ftp://ftp.perforce.com/perforce/r09.1/bin.java/p4java.zip. This completely > reworked API does not require that the p4 client be installed on the system. > The SCM Perforce Provider should be modified to use this new native java API > to eliminate the many issues involved with depending on the p4 executable. -- 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: (SCM-483) Update SCM Perforce Provider to use P4Java
[ http://jira.codehaus.org/browse/SCM-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231274#action_231274 ] Brian Jackson commented on SCM-483: --- I've got the p4java jar staged. Aaron can you take a look and sanity check that everything is in order before I release it to Central? https://oss.sonatype.org/content/repositories/comperforce-362/ Since its closed source, but the sources jar is a requirement, I've staged an empty sources jar on purpose. I spoke with Jason van Zyl and he state that as long as the license allows for redistribution of binaries then its not a problem. The conversation ended here: http://twitter.com/jaxzin/status/20516410745 > Update SCM Perforce Provider to use P4Java > -- > > Key: SCM-483 > URL: http://jira.codehaus.org/browse/SCM-483 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-perforce >Affects Versions: 1.2 >Reporter: Tom Rodriguez > Fix For: future > > Attachments: maven-scm-perforce-p4java.jar > > > Perforce has developed a new Java Native API for access to perforce called > P4Java. You can access it here: > ftp://ftp.perforce.com/perforce/r09.1/bin.java/p4java.zip. This completely > reworked API does not require that the p4 client be installed on the system. > The SCM Perforce Provider should be modified to use this new native java API > to eliminate the many issues involved with depending on the p4 executable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4752) endorsed
[
http://jira.codehaus.org/browse/MNG-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231271#action_231271
]
Brett Porter commented on MNG-4752:
---
I can't find a corresponding JIRA issue, but there was significant discussion
on this last year: http://markmail.org/message/nzzwg4tt6w4n42wm
> endorsed
> ---
>
> Key: MNG-4752
> URL: http://jira.codehaus.org/browse/MNG-4752
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Dependencies
>Affects Versions: 2.2.1
> Environment: An issue in 2.2.1 but I think the same issue applies
> also to 3.0.
>Reporter: Jesse Glick
>
> There appears to be no official way to request usage of a particular Java
> library (such as a new release of JAXB) using the Java "endorsed" mechanism.
> The semantics would be very similar to provided scope except that the library
> is expected to override the JRE's boot classpath, both at compile time (main
> or test) and runtime ({{exec:exec}} and Surefire).
> As investigated in https://netbeans.org/bugzilla/show_bug.cgi?id=185139#c8
> there are various ways you can get this functionality to work in current
> Maven releases if you Google long enough, but all seem hackish. Prepending
> arguments to the bootclasspath directly is generally discouraged.
> Manually configuring {{-endorseddirs}} (for {{javac}}) or
> {{-Djava.endorsed.dirs}} (for {{java}} incl. Surefire) seems to work, but you
> have to first download the endorsed libraries into some subdirectory of
> target, where they could consume considerable disk space.
> You could fix the disk space issue by passing dirs in the local repository,
> but this requires hardcoding details of the {{~/.m2/repository/}} structure
> in the POM which is very ugly, and also means duplicating information about
> {{groupId}}, {{artifactId}}, and {{version}} (you still need to have
> artifacts declared elsewhere so they will get downloaded if not initially
> present).
> Anyway all these tricks obscure the relatively simple intent of the
> developer, which is to use a given artifact in the project in preference to
> any equivalent in the current JRE. It is important to have a standardized way
> of declaring such dependencies, not just to make it easy to write and
> maintain {{pom.xml}}, but so that IDEs and other tools know what you intend
> to do and can (for example) offer appropriate code completion without reverse
> engineering various idioms.
> Much preferable would be to simply declare these dependencies in the normal
> POM section, but with {{endorsed}}. Then
> {{maven-compiler-plugin}}, {{maven-exec-plugin}}, {{maven-surefire-plugin}},
> etc. would need to be modified to understand these dependencies and use them
> appropriately when calling JDK tools. Plugin code could be smart enough to
> work optimally in the available environment; for example, if an artifact has
> only a single JAR in the local repository (no extra classifiers), the
> containing directory could be passed directly to JDK tools as an endorsed
> dir, but in other cases a {{target/endorsed}} dir could be generated and used
> instead.
> One concern is that the notion of an endorsed library is quite specific to
> the JVM; Maven projects targeted at other platforms would presumably have no
> use for this scope. Perhaps this is not an issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4754) long name and password combination fail upon authentication with maven repository with mvn 2.2.1
long name and password combination fail upon authentication with maven
repository with mvn 2.2.1
Key: MNG-4754
URL: http://jira.codehaus.org/browse/MNG-4754
Project: Maven 2 & 3
Issue Type: Bug
Affects Versions: 2.2.1
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
Java version: 1.6.0_20
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
Reporter: Nikos Michalakis
The problem seems to be with the wagon package or the module that calls wagon
but I'm not a maven developer so I didn't look at what version of wagon is
used. The only fix I could find was to revert to 2.2.0 which works.
This is an anonymized version of my repository credentials. I kept the length
the same in both username and password
repo
nmichala...@.com
\{DESede\}xx==
Here is the exception I get (hiding the auth info):
java.lang.RuntimeException: java.lang.IllegalArgumentException: Illegal
character(s) in message header value: Basic bm1ppelN3
PT0=
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1014)
at
sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:2211)
at
java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:382)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
at
org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:115)
at
org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116)
at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88)
at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61)
at
org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:546)
at
org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(DefaultWagonManager.java:443)
at
org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolve(DefaultRepositoryMetadataManager.java:97)
at
org.apache.maven.artifact.transform.AbstractVersionTransformation.resolveVersion(AbstractVersionTransformation.java:65)
at
org.apache.maven.artifact.transform.LatestArtifactTransformation.transformForResolve(LatestArtifactTransformation.java:41)
at
org.apache.maven.artifact.transform.DefaultArtifactTransformationManager.transformForResolve(DefaultArtifactTransformationManager.java:55)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:145)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:90)
at
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:558)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:251)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:163)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:299)
at
org.apache.maven.plugin.version.DefaultPluginVersionManager.resolveMetaVersion(DefaultPluginVersionManager.java:673)
at
org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersionManager.java:187)
at
org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersionManager.java:91)
at
org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:179)
at
org.apache.maven.plugin.DefaultPluginManager.loadPluginDescriptor(DefaultPluginManager.java:1642)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1540)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(DefaultLifecycleExecutor.java:1503)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:1282)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:534)
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.ja
[jira] Updated: (MRELEASE-159) Support a pattern to generate the release tag
[ http://jira.codehaus.org/browse/MRELEASE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Skjonsby updated MRELEASE-159: --- Attachment: release-manager(updated).patch Here's an updated patch that fixes a couple issues in the first patch. This patch has been working well in our internal release process. > Support a pattern to generate the release tag > - > > Key: MRELEASE-159 > URL: http://jira.codehaus.org/browse/MRELEASE-159 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: prepare >Affects Versions: 2.0-beta-4 >Reporter: Joerg Schaible > Attachments: MRELEASE-159-PATCH-update.diff.gz, > MRELEASE-159-PATCH.diff.gz, release-manager(updated).patch, > release-manager-patch.patch > > > The release-plugin uses currently the pattern "-" to > create the version tag. A configuration element would be fine to support > different requirements for release tags (in our case "v_", since > with svn the module is already part of the path). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4749) Move from Plexus to Guice as IoC container
[ http://jira.codehaus.org/browse/MNG-4749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-4749: --- Attachment: MAVEN_3_GUICE_POMS.patch Updated patch with recent version of Plexus shim > Move from Plexus to Guice as IoC container > -- > > Key: MNG-4749 > URL: http://jira.codehaus.org/browse/MNG-4749 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: General >Reporter: Benjamin Bentmann > Attachments: MAVEN_3_GUICE_POMS.patch, MAVEN_3_GUICE_POMS.patch > > > Plexus is dead, the new king is called Guice. Stuart McCulloch created a > Plexus-shim on top of Guice that makes existing Plexus components (e.g. Maven > plugins) work in Guice. For Maven, the transition is as simple as flipping > dependencies. Attached is the required patch from Stuart. -- 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: (MEV-669) ftpserver-parent pom contains invalid character preventing parsing with Maven 3
ftpserver-parent pom contains invalid character preventing parsing with Maven 3 --- Key: MEV-669 URL: http://jira.codehaus.org/browse/MEV-669 Project: Maven Evangelism Issue Type: Bug Components: Invalid POM Reporter: Basil James Whitehouse III This affects all current 1.0.x versions. I've filed https://issues.apache.org/jira/browse/FTPSERVER-382 for an upstream fix and there is a workaround but fixing the data in central would be nice for new downloads (or those that want to refresh their internal repos). -- 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-4753) BAD SIGNATURE (again)
[ http://jira.codehaus.org/browse/MNG-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hall closed MNG-4753. -- Resolution: Not A Bug The URL http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-2.2.1-bin.tar.gz links to a HTML webpage where actual download links may be found; e.g. http://www.alliedquotes.com/mirrors/apache/maven/binaries/apache-maven-2.2.1-bin.tar.gz These worked properly. > BAD SIGNATURE (again) > - > > Key: MNG-4753 > URL: http://jira.codehaus.org/browse/MNG-4753 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.2.1 > Environment: Linux Fedora Core 8 >Reporter: Rick Hall > Attachments: apache-maven-2.2.1-bin.tar.gz, > apache-maven-2.2.1-bin.tar.gz.asc, KEYS > > > Signature of apache-maven-2.2.1-bin.tar.gz failed with message "gpg: BAD > signature from John Dennis Casey ". > DETAILS: > $ wget > http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-2.2.1-bin.tar.gz > $ wget http://www.apache.org/dist/maven/KEYS > $ gpg --import KEYS > $ gpg --verify apache-maven-2.2.1-bin.tar.gz.asc > gpg: Signature made Thu 06 Aug 2009 03:18:49 PM EDT using DSA key ID 34A72A7F > gpg: BAD signature from "John Dennis Casey " > Same bug as MNG 4650 (April 28th), which appears to have been closed too > quickly. > Files attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4753) BAD SIGNATURE (again)
[ http://jira.codehaus.org/browse/MNG-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231228#action_231228 ] Rick Hall commented on MNG-4753: Never mind... The URL http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-2.2.1-bin.tar.gz links to an HTML page, not a *.tar.gz file. Please close this bug. > BAD SIGNATURE (again) > - > > Key: MNG-4753 > URL: http://jira.codehaus.org/browse/MNG-4753 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.2.1 > Environment: Linux Fedora Core 8 >Reporter: Rick Hall > Attachments: apache-maven-2.2.1-bin.tar.gz, > apache-maven-2.2.1-bin.tar.gz.asc, KEYS > > > Signature of apache-maven-2.2.1-bin.tar.gz failed with message "gpg: BAD > signature from John Dennis Casey ". > DETAILS: > $ wget > http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-2.2.1-bin.tar.gz > $ wget http://www.apache.org/dist/maven/KEYS > $ gpg --import KEYS > $ gpg --verify apache-maven-2.2.1-bin.tar.gz.asc > gpg: Signature made Thu 06 Aug 2009 03:18:49 PM EDT using DSA key ID 34A72A7F > gpg: BAD signature from "John Dennis Casey " > Same bug as MNG 4650 (April 28th), which appears to have been closed too > quickly. > Files attached. -- 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: (MSHADE-84) added support for minijar'ing
[ http://jira.codehaus.org/browse/MSHADE-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231227#action_231227 ] Torsten Curdt commented on MSHADE-84: - Well, spotted with the input streams ...they were first closed inside jdependency but I changed this as this is the more expected behavior (obviously ;) Style I just applied through eclipse which also fixed a couple of unrelated style issues. > added support for minijar'ing > - > > Key: MSHADE-84 > URL: http://jira.codehaus.org/browse/MSHADE-84 > Project: Maven 2.x Shade Plugin > Issue Type: Improvement >Affects Versions: 1.3.4 >Reporter: Torsten Curdt > Attachments: minijar.diff, minijar.diff > > > http://github.com/tcurdt/maven-plugins/commit/5ac23b358b15ed315c871a3b8cb3301a86802a8d > just set "minimizeJar" to "true" in the configuration to strip unused classes -- 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: (MSHADE-84) added support for minijar'ing
[ http://jira.codehaus.org/browse/MSHADE-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Torsten Curdt updated MSHADE-84: Attachment: minijar.diff close inputstreams and style > added support for minijar'ing > - > > Key: MSHADE-84 > URL: http://jira.codehaus.org/browse/MSHADE-84 > Project: Maven 2.x Shade Plugin > Issue Type: Improvement >Affects Versions: 1.3.4 >Reporter: Torsten Curdt > Attachments: minijar.diff, minijar.diff > > > http://github.com/tcurdt/maven-plugins/commit/5ac23b358b15ed315c871a3b8cb3301a86802a8d > just set "minimizeJar" to "true" in the configuration to strip unused classes -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4753) BAD SIGNATURE (again)
[ http://jira.codehaus.org/browse/MNG-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231225#action_231225 ] Rick Hall commented on MNG-4753: Two additional comments: 1) Left out one step in the DETAILS; i.e. $ wget http://www.apache.org/dist/maven/binaries/apache-maven-2.2.1-bin.tar.gz.asc 2) I repeated all these steps a second time with the same result. I've attached MD5 checksums of the files I downloaded (I used these to verify that the files downloaded a second time matched the files downloaded the first time.) MD5 sums: e8e7a4d6e2d88df920606592d6b9a8b8 apache-maven-2.2.1-bin.tar.gz d424f6f412c972ba2ba48a66ef77be7b apache-maven-2.2.1-bin.tar.gz.asc ab3f28113d3cb13a113346182506f028 KEYS > BAD SIGNATURE (again) > - > > Key: MNG-4753 > URL: http://jira.codehaus.org/browse/MNG-4753 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.2.1 > Environment: Linux Fedora Core 8 >Reporter: Rick Hall > Attachments: apache-maven-2.2.1-bin.tar.gz, > apache-maven-2.2.1-bin.tar.gz.asc, KEYS > > > Signature of apache-maven-2.2.1-bin.tar.gz failed with message "gpg: BAD > signature from John Dennis Casey ". > DETAILS: > $ wget > http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-2.2.1-bin.tar.gz > $ wget http://www.apache.org/dist/maven/KEYS > $ gpg --import KEYS > $ gpg --verify apache-maven-2.2.1-bin.tar.gz.asc > gpg: Signature made Thu 06 Aug 2009 03:18:49 PM EDT using DSA key ID 34A72A7F > gpg: BAD signature from "John Dennis Casey " > Same bug as MNG 4650 (April 28th), which appears to have been closed too > quickly. > Files attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4753) BAD SIGNATURE (again)
BAD SIGNATURE (again) - Key: MNG-4753 URL: http://jira.codehaus.org/browse/MNG-4753 Project: Maven 2 & 3 Issue Type: Bug Affects Versions: 2.2.1 Environment: Linux Fedora Core 8 Reporter: Rick Hall Attachments: apache-maven-2.2.1-bin.tar.gz, apache-maven-2.2.1-bin.tar.gz.asc, KEYS Signature of apache-maven-2.2.1-bin.tar.gz failed with message "gpg: BAD signature from John Dennis Casey ". DETAILS: $ wget http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-2.2.1-bin.tar.gz $ wget http://www.apache.org/dist/maven/KEYS $ gpg --import KEYS $ gpg --verify apache-maven-2.2.1-bin.tar.gz.asc gpg: Signature made Thu 06 Aug 2009 03:18:49 PM EDT using DSA key ID 34A72A7F gpg: BAD signature from "John Dennis Casey " Same bug as MNG 4650 (April 28th), which appears to have been closed too quickly. Files attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4752) endorsed
endorsed
---
Key: MNG-4752
URL: http://jira.codehaus.org/browse/MNG-4752
Project: Maven 2 & 3
Issue Type: New Feature
Components: Dependencies
Affects Versions: 2.2.1
Environment: An issue in 2.2.1 but I think the same issue applies also
to 3.0.
Reporter: Jesse Glick
There appears to be no official way to request usage of a particular Java
library (such as a new release of JAXB) using the Java "endorsed" mechanism.
The semantics would be very similar to provided scope except that the library
is expected to override the JRE's boot classpath, both at compile time (main or
test) and runtime ({{exec:exec}} and Surefire).
As investigated in https://netbeans.org/bugzilla/show_bug.cgi?id=185139#c8
there are various ways you can get this functionality to work in current Maven
releases if you Google long enough, but all seem hackish. Prepending arguments
to the bootclasspath directly is generally discouraged.
Manually configuring {{-endorseddirs}} (for {{javac}}) or
{{-Djava.endorsed.dirs}} (for {{java}} incl. Surefire) seems to work, but you
have to first download the endorsed libraries into some subdirectory of target,
where they could consume considerable disk space.
You could fix the disk space issue by passing dirs in the local repository, but
this requires hardcoding details of the {{~/.m2/repository/}} structure in the
POM which is very ugly, and also means duplicating information about
{{groupId}}, {{artifactId}}, and {{version}} (you still need to have artifacts
declared elsewhere so they will get downloaded if not initially present).
Anyway all these tricks obscure the relatively simple intent of the developer,
which is to use a given artifact in the project in preference to any equivalent
in the current JRE. It is important to have a standardized way of declaring
such dependencies, not just to make it easy to write and maintain {{pom.xml}},
but so that IDEs and other tools know what you intend to do and can (for
example) offer appropriate code completion without reverse engineering various
idioms.
Much preferable would be to simply declare these dependencies in the normal POM
section, but with {{endorsed}}. Then {{maven-compiler-plugin}},
{{maven-exec-plugin}}, {{maven-surefire-plugin}}, etc. would need to be
modified to understand these dependencies and use them appropriately when
calling JDK tools. Plugin code could be smart enough to work optimally in the
available environment; for example, if an artifact has only a single JAR in the
local repository (no extra classifiers), the containing directory could be
passed directly to JDK tools as an endorsed dir, but in other cases a
{{target/endorsed}} dir could be generated and used instead.
One concern is that the notion of an endorsed library is quite specific to the
JVM; Maven projects targeted at other platforms would presumably have no use
for this scope. Perhaps this is not an issue.
--
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-4615) [regression] @required plugin parameters are not validated
[
http://jira.codehaus.org/browse/MNG-4615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4615.
--
Resolution: Fixed
Fix Version/s: (was: Issues to be reviewed for 3.x)
3.0-beta-2
Assignee: Benjamin Bentmann
Fixed in [r983050|http://svn.apache.org/viewvc?view=revision&revision=983050].
> [regression] @required plugin parameters are not validated
> --
>
> Key: MNG-4615
> URL: http://jira.codehaus.org/browse/MNG-4615
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0-alpha-7
> Environment: OS X, not in a pom directory
>Reporter: Nigel Magnay
>Assignee: Benjamin Bentmann
>Priority: Critical
> Fix For: 3.0-beta-2
>
>
> Executing
> mvn -X install:install-file -DgroupId=com.adobe.flex.framework
> -DartifactId=halo -Dversion=4.0.0.14159 -Dpackaging=swc /Applications/Adobe\
> Flash\ Builder\ 4/sdks/4.0.0/frameworks/themes/Halo/halo.swc
> Yields:
> pache Maven 3.0-alpha-7 (r921173; 2010-03-09 22:31:07+)
> Java version: 1.6.0_17
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.3" arch: "x86_64" Family: "mac"
> [INFO] Error stacktraces are turned on.
> [DEBUG] Reading user settings from /Users/magnayn/.m2/settings.xml
> [DEBUG] Reading global settings from /usr/share/maven/conf/settings.xml
> [DEBUG] Using local repository at /Users/magnayn/.m2/repository
> [INFO] Scanning for projects...
> [DEBUG] Extension realms for project org.apache.maven:standalone-pom:pom:1:
> (none)
> [DEBUG] Looking up lifecyle mappings for packaging pom from
> ClassRealm[plexus.core, parent: null]
> [DEBUG] Resolving plugin prefix install from [org.jvnet.hudson.tools,
> org.apache.maven.plugins, org.codehaus.mojo]
> [DEBUG] Resolved plugin prefix install to
> org.apache.maven.plugins:maven-install-plugin from POM
> org.apache.maven:standalone-pom:pom:1
> [DEBUG] === REACTOR BUILD PLAN
>
> [DEBUG] Project: org.apache.maven:standalone-pom:pom:1
> [DEBUG] Tasks:
> [org.apache.maven.plugins:maven-install-plugin:2.3:install-file]
> [DEBUG] Style: Aggregating
> [DEBUG]
> ---
> [DEBUG] Project: org.apache.maven:standalone-pom:pom:1
> [DEBUG] Tasks: [/Applications/Adobe Flash Builder
> 4/sdks/4.0.0/frameworks/themes/Halo/halo.swc]
> [DEBUG] Style: Regular
> [DEBUG]
> ===
> [INFO]
>
> [INFO]
>
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO]
>
> [DEBUG] === PROJECT BUILD PLAN
>
> [DEBUG] Project: org.apache.maven:standalone-pom:1
> [DEBUG] Dependencies (collect): []
> [DEBUG] Dependencies (resolve): []
> [DEBUG]
> ---
> [DEBUG] Goal:
> org.apache.maven.plugins:maven-install-plugin:2.3:install-file (default-cli)
> [DEBUG] Style: Aggregating
> [DEBUG] Configuration:
>
> ${artifactId}
> ${classifier}
> ${createChecksum}
> ${file}
> ${generatePom}
> ${groupId}
> ${javadoc}
> ${localRepository}
> ${localRepositoryPath}
> ${packaging}
> ${pomFile}
>default-value="default">${repositoryLayout}
> ${sources}
>default-value="false">${updateReleaseInfo}
> ${version}
>
> [DEBUG]
> ===
> [INFO]
> [INFO] --- maven-install-plugin:2.3:install-file (default-cli) @
> standalone-pom ---
> [DEBUG] Created new class realm
> plugin>org.apache.maven.plugins:maven-install-plugin:2.3
> [DEBUG] Populating class realm
> plugin>org.apache.maven.plugins:maven-install-plugin:2.3
> [DEBUG] Included:
> org.apache.maven.plugins:maven-install-plugin:maven-plugin:2.3
> [DEBUG] Included: org.codehaus.plexus:plexus-utils:jar:1.5.6
> [DEBUG] Included: junit:junit:jar:3.8.1
> [DEBUG] Included: org.codehaus.plexus:plexus-digest:jar:1.0
> [DEBUG] Excluded: org.apache.maven:maven-plugin-api:jar:2.0.6
> [DEBUG] Excluded: org.apache.maven:maven-project:jar:2.0.6
> [DEBUG] Excluded: org.apache.maven:maven-settings:jar:2.0.6
> [DEBUG] Excluded: org.apache.maven:maven-model:jar:2.0.6
> [DEBUG] Excluded:
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1
> [DEBUG] Excluded: classworlds:classworlds:jar:1
[jira] Updated: (SUREFIRE-85) java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/NestedCheckedException
[ http://jira.codehaus.org/browse/SUREFIRE-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated SUREFIRE-85: - Fix Version/s: (was: 2.6) Backlog Moving to backlog until we are provided with a sample test case > java.lang.NoClassDefFoundError: > org/apache/maven/surefire/util/NestedCheckedException > - > > Key: SUREFIRE-85 > URL: http://jira.codehaus.org/browse/SUREFIRE-85 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.0 (2.2 plugin) > Environment: Windows XP / Sun JDK 1.5.0_06 >Reporter: David J. M. Karlsen > Fix For: Backlog > > Attachments: log.txt > > > java.lang.NoClassDefFoundError: > org/apache/maven/surefire/util/NestedCheckedException > Exception in thread "main" > is thrown during execution of the maven-surefire-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] Closed: (SUREFIRE-615) Surefire providers shouldn't need to download old versions of the library
[ http://jira.codehaus.org/browse/SUREFIRE-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed SUREFIRE-615. - Resolution: Fixed Assignee: Stephen Connolly r982995 unless the CI build fails and I have to revert back > Surefire providers shouldn't need to download old versions of the library > - > > Key: SUREFIRE-615 > URL: http://jira.codehaus.org/browse/SUREFIRE-615 > Project: Maven Surefire > Issue Type: Improvement > Components: JUnit 3.x support, Junit 4.x support, Maven Surefire > Plugin, TestNG support >Affects Versions: 2.5 >Reporter: Brett Porter >Assignee: Stephen Connolly > Fix For: 2.6 > > > currently, the Surefire plugin uses resolveTransitively to obtain the > Surefire provider (junit, junit4, junit47, testng). Each of these has a > compile time dependency on the library itself to interact with their API. > This results in downloading older versions as well as the newer one requested > by the project (TestNG 5.7, JUnit 4.0, JUnit 3.8.1). There are two possible > solutions to this: > - alter the resolveTranstively method to exclude the artifact that is already > available from the project > - set the dependency to 'provided' in the providers POM -- 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: (MANTTASKS-201) artifact:mvn generates "org.apache.tools.ant.ExitException: Permission (java.lang.RuntimePermission exitVM) was not granted" when fork=false
artifact:mvn generates "org.apache.tools.ant.ExitException: Permission (java.lang.RuntimePermission exitVM) was not granted" when fork=false Key: MANTTASKS-201 URL: http://jira.codehaus.org/browse/MANTTASKS-201 Project: Maven 2.x Ant Tasks Issue Type: Bug Components: mvn task Affects Versions: 2.1.1 Reporter: Matt McHenry Priority: Minor Using this simple ant target: I get the correct behaviour: $ M2_HOME=`cygpath -w "$M2_HOME"` ant -Dmvn.goal=-version mvn.invoke Searching for build.xml ... Buildfile: c:\Users\mmchenry\svn\cli\trunk\runtime\maven\build.xml mvn.setversion: mvn.invoke: [artifact:mvn] Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400) [artifact:mvn] Java version: 1.6.0_17 [artifact:mvn] Java home: c:\Program Files\Java\jdk1.6.0_17\jre [artifact:mvn] Default locale: en_US, platform encoding: Cp1252 [artifact:mvn] OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows" BUILD SUCCESSFUL Total time: 0 seconds But if I set fork="false", then I get: [artifact:mvn] Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400) [artifact:mvn] Java version: 1.6.0_17 [artifact:mvn] Java home: c:\Program Files\Java\jdk1.6.0_17\jre [artifact:mvn] Default locale: en_US, platform encoding: Cp1252 [artifact:mvn] OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows" [artifact:mvn] org.apache.tools.ant.ExitException: Permission (java.lang.RuntimePermission exitVM) was not granted. [artifact:mvn] at org.apache.tools.ant.types.Permissions$MySM.checkExit(Permissions.java:196) [artifact:mvn] at java.lang.Runtime.exit(Runtime.java:88) [artifact:mvn] at java.lang.System.exit(System.java:904) [artifact:mvn] at org.codehaus.classworlds.Launcher.main(Launcher.java:376) [artifact:mvn] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [artifact:mvn] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [artifact:mvn] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [artifact:mvn] at java.lang.reflect.Method.invoke(Method.java:597) [artifact:mvn] at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217) [artifact:mvn] at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152) [artifact:mvn] at org.apache.tools.ant.taskdefs.Java.run(Java.java:764) [artifact:mvn] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:218) [artifact:mvn] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:132) [artifact:mvn] at org.apache.tools.ant.taskdefs.Java.execute(Java.java:105) [artifact:mvn] at org.apache.maven.artifact.ant.Mvn.execute(Mvn.java:81) [artifact:mvn] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) [artifact:mvn] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [artifact:mvn] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [artifact:mvn] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [artifact:mvn] at java.lang.reflect.Method.invoke(Method.java:597) [artifact:mvn] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) [artifact:mvn] at org.apache.tools.ant.Task.perform(Task.java:348) [artifact:mvn] at org.apache.tools.ant.Target.execute(Target.java:357) [artifact:mvn] at org.apache.tools.ant.Target.performTasks(Target.java:385) [artifact:mvn] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) [artifact:mvn] at org.apache.tools.ant.Project.executeTarget(Project.java:1306) [artifact:mvn] at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) [artifact:mvn] at org.apache.tools.ant.Project.executeTargets(Project.java:1189) [artifact:mvn] at org.apache.tools.ant.Main.runBuild(Main.java:758) [artifact:mvn] at org.apache.tools.ant.Main.startAnt(Main.java:217) [artifact:mvn] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) [artifact:mvn] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) [artifact:mvn] Java Result: 100 BUILD SUCCESSFUL Total time: 0 seconds -- 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: (MPDF-40) When using findbugs-maven-plugin pdf report generation fails with afatal error
[ http://jira.codehaus.org/browse/MPDF-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231179#action_231179 ] Lukas Theussl commented on MPDF-40: --- bq. According to the documentation page http://maven.apache.org/plugins/maven-pdf-plugin/examples/configuring-reports.html one should file a bug in your issue tracker if I use a SNAPSHOT plugin which fails with the PDF plugin. Sure but this is meant to apply only for plugins maintained by the maven project. We can't fix plugins outside. bq. I have also raised an issue on the findbug project. Can you post the link here? I will leave this issue open for reference. > When using findbugs-maven-plugin pdf report generation fails with afatal error > -- > > Key: MPDF-40 > URL: http://jira.codehaus.org/browse/MPDF-40 > Project: Maven 2.x PDF Plugin > Issue Type: Bug >Affects Versions: 1.2 > Environment: Windows XP Java 1.6 >Reporter: Espen Skogen > Attachments: error.log > > > When using findbugs-maven-plugin v 2.3.2-SNAPSHOT a fatal error occurs when > attempting PDF generation. -- 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: (MRELEASE-457) Non sparse-checkout SCM support
[ http://jira.codehaus.org/browse/MRELEASE-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MRELEASE-457: -- Fix Version/s: 2.1 Assignee: Olivier Lamy temporary move set fix version to 2.1. > Non sparse-checkout SCM support > --- > > Key: MRELEASE-457 > URL: http://jira.codehaus.org/browse/MRELEASE-457 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: perform, scm >Affects Versions: 2.0 >Reporter: Mark Struberg >Assignee: Olivier Lamy > Fix For: 2.1 > > > Some SCMs like GIT, Mercurial, Bazaar, BitKeeper, Darcs, and Monotone doesn't > support sparse checkouts (checkout of a single subdirectory). > So while doing a mvn release:perform in a sub-module, we will always get the > _whole_ project checked out into target/checkout! > For doing the clean build from this checkout, we have to implement a > functionality to find the right submodule first. -- 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: (MPDF-40) When using findbugs-maven-plugin pdf report generation fails with afatal error
[ http://jira.codehaus.org/browse/MPDF-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231176#action_231176 ] Espen Skogen commented on MPDF-40: -- According to the documentation page http://maven.apache.org/plugins/maven-pdf-plugin/examples/configuring-reports.html one should file a bug in your issue tracker if I use a SNAPSHOT plugin which fails with teh PDF plugin. I have also raised an issue on the findbug project. > When using findbugs-maven-plugin pdf report generation fails with afatal error > -- > > Key: MPDF-40 > URL: http://jira.codehaus.org/browse/MPDF-40 > Project: Maven 2.x PDF Plugin > Issue Type: Bug >Affects Versions: 1.2 > Environment: Windows XP Java 1.6 >Reporter: Espen Skogen > Attachments: error.log > > > When using findbugs-maven-plugin v 2.3.2-SNAPSHOT a fatal error occurs when > attempting PDF generation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MPDF-40) When using findbugs-maven-plugin pdf report generation fails with afatal error
[ http://jira.codehaus.org/browse/MPDF-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231176#action_231176 ] Espen Skogen edited comment on MPDF-40 at 8/6/10 4:51 AM: -- According to the documentation page http://maven.apache.org/plugins/maven-pdf-plugin/examples/configuring-reports.html one should file a bug in your issue tracker if I use a SNAPSHOT plugin which fails with the PDF plugin. I have also raised an issue on the findbug project. was (Author: espenskogen): According to the documentation page http://maven.apache.org/plugins/maven-pdf-plugin/examples/configuring-reports.html one should file a bug in your issue tracker if I use a SNAPSHOT plugin which fails with teh PDF plugin. I have also raised an issue on the findbug project. > When using findbugs-maven-plugin pdf report generation fails with afatal error > -- > > Key: MPDF-40 > URL: http://jira.codehaus.org/browse/MPDF-40 > Project: Maven 2.x PDF Plugin > Issue Type: Bug >Affects Versions: 1.2 > Environment: Windows XP Java 1.6 >Reporter: Espen Skogen > Attachments: error.log > > > When using findbugs-maven-plugin v 2.3.2-SNAPSHOT a fatal error occurs when > attempting PDF generation. -- 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: (MPDF-40) When using findbugs-maven-plugin pdf report generation fails with afatal error
[ http://jira.codehaus.org/browse/MPDF-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231175#action_231175 ] Lukas Theussl commented on MPDF-40: --- This should be filed at the findbugs-plugin. > When using findbugs-maven-plugin pdf report generation fails with afatal error > -- > > Key: MPDF-40 > URL: http://jira.codehaus.org/browse/MPDF-40 > Project: Maven 2.x PDF Plugin > Issue Type: Bug >Affects Versions: 1.2 > Environment: Windows XP Java 1.6 >Reporter: Espen Skogen > Attachments: error.log > > > When using findbugs-maven-plugin v 2.3.2-SNAPSHOT a fatal error occurs when > attempting PDF generation. -- 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: (MSHADE-84) added support for minijar'ing
[ http://jira.codehaus.org/browse/MSHADE-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231172#action_231172 ] Benjamin Bentmann commented on MSHADE-84: - Nice, some comments/questions: * Can you reformat the code to follow the [Maven code style|http://maven.apache.org/developers/conventions/code.html]? * When/where are the file input streams opened by the new filter closed? > added support for minijar'ing > - > > Key: MSHADE-84 > URL: http://jira.codehaus.org/browse/MSHADE-84 > Project: Maven 2.x Shade Plugin > Issue Type: Improvement >Affects Versions: 1.3.4 >Reporter: Torsten Curdt > Attachments: minijar.diff > > > http://github.com/tcurdt/maven-plugins/commit/5ac23b358b15ed315c871a3b8cb3301a86802a8d > just set "minimizeJar" to "true" in the configuration to strip unused classes -- 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: (MPDF-40) When using findbugs-maven-plugin pdf report generation fails with afatal error
When using findbugs-maven-plugin pdf report generation fails with afatal error -- Key: MPDF-40 URL: http://jira.codehaus.org/browse/MPDF-40 Project: Maven 2.x PDF Plugin Issue Type: Bug Affects Versions: 1.2 Environment: Windows XP Java 1.6 Reporter: Espen Skogen Attachments: error.log When using findbugs-maven-plugin v 2.3.2-SNAPSHOT a fatal error occurs when attempting PDF generation. -- 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-tabpanel&focusedCommentId=231166#action_231166 ] Petter Måhlén commented on MDEP-275: By the way, to make it easier for other people who are interested in using this feature, I have created a couple of repositories with the code. The repositories are: http://github.com/pettermahlen/maven-dependency-analyzer-fork http://github.com/pettermahlen/maven-dependency-plugin-fork For instructions on how to start using it, see http://pettermahlen.com/2010/08/05/finding-duplicate-class-definitions-using-maven/. > 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
[jira] Closed: (MRELEASE-492) The svn tag command failed
[
http://jira.codehaus.org/browse/MRELEASE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MRELEASE-492.
-
Resolution: Not A Bug
Assignee: Olivier Lamy
> The svn tag command failed
> --
>
> Key: MRELEASE-492
> URL: http://jira.codehaus.org/browse/MRELEASE-492
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-9
> Environment: ubuntu 9.04 ,
> Apache Maven 2.1.0 (r755702; 2009-03-19 00:40:27+0530)
> Java version: 1.6.0_13
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.13/jre
> Default locale: en_IN, platform encoding: UTF-8
> OS name: "linux" version: "2.6.28-15-server" arch: "i386" Family: "unix"
>Reporter: Sridher Jakku
>Assignee: Olivier Lamy
>
> when i run the mvn release:prepare this error comming
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.584
> sec
> [INFO] Running com.ipleanty.accure.module.orm.AppTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018
> sec
> [INFO]
> [INFO] Results :
> [INFO]
> [INFO] Tests run: 27, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO] [INFO] [antrun:run {execution: default}]
> [INFO] [INFO] Executing tasks
> [INFO] [echo]
>
> [INFO] [echo] r2093 | js | 2009-10-13 20:02:29 +0530 (Tue, 13 Oct 2009)
> [INFO] [echo]
>
> [INFO] [echo] Your orm Revision number : 2073
> [INFO] [INFO] Executed tasks
> [INFO] [INFO] [jar:jar]
> [INFO] [INFO] Building jar: /home/sridher/maven/svn/orm/target/orm-0.7.jar
> [INFO] [INFO]
>
> [INFO] [INFO] BUILD SUCCESSFUL
> [INFO] [INFO]
>
> [INFO] [INFO] Total time: 26 seconds
> [INFO] [INFO] Finished at: Tue Oct 13 20:03:30 IST 2009
> [INFO] [INFO] Final Memory: 25M/114M
> [INFO] [INFO]
>
> [INFO] Checking in modified POMs...
> [INFO] Executing: /bin/sh -c cd /home/sridher/maven/svn/orm && svn --username
> js --password '*' --non-interactive commit --file
> /tmp/maven-scm-327676631.commit --targets
> /tmp/maven-scm-7485856893453511468-targets
> [INFO] Working directory: /home/sridher/maven/svn/orm
> [INFO] Tagging release with the label orm-0.7...
> [INFO] Executing: /bin/sh -c cd /home/sridher/maven/svn/orm && svn --username
> js --password '*' --non-interactive copy --file
> /tmp/maven-scm-895863680.commit .
> scm:svn:svn://192.168.1.10/Accure/orm/tags/orm-0.7
> [INFO] Working directory: /home/sridher/maven/svn/orm
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Unable to tag SCM
> Provider message:
> The svn tag command failed.
> Command output:
> svn: Local, non-commit operations do not take a log message or revision
> properties
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 41 seconds
> [INFO] Finished at: Tue Oct 13 20:03:32 IST 2009
> [INFO] Final Memory: 12M/119M
> [INFO]
>
--
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
