[jira] [Commented] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors
[ https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1676#comment-1676 ] Brian Fox commented on WAGON-541: - A system property isn't a great solution. For companies trying to roll out a repo framework that does provide useful information, requiring all systems to set that property is essentially a non-starter. It seems like the main thrust of your concern was originally that so much of the message was repetitive information. What if you instead simply truncated the output and only showed the first 80 chars of the phrase? > Command Line Not Showing ReasonPhrase for Errors > > > Key: WAGON-541 > URL: https://issues.apache.org/jira/browse/WAGON-541 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 3.2.0 > Environment: Windows 10 >Reporter: Aurelie Pluche >Priority: Minor > Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG, > MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG > > > Hi, > I work in the Azure DevOps Artifacts Packaging team at Microsoft where we > provide a Maven service to our customers. We often use a Reason-Phrase to > return information on failed requests to customers. This functionality was > available in previous versions of maven but seems to have disappeared in > Maven 3.6.0. Was this intentional? > I have included screenshots of the cmd line response using two different > maven versions (3.3.9 and 3.6.0). I intentionally made a call that would > return a 405 error to be able to get an error response. I also used the same > package. > Thanks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors
[ https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox reopened WAGON-541: - We've also experienced this as a regression. When the server chooses to provide additional context, it is not helpful to the user that we squash it. Maven should pass this information on in the error so someone has a chance of understanding what happened. > Command Line Not Showing ReasonPhrase for Errors > > > Key: WAGON-541 > URL: https://issues.apache.org/jira/browse/WAGON-541 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 3.2.0 > Environment: Windows 10 >Reporter: Aurelie Pluche >Priority: Minor > Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG, > MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG > > > Hi, > I work in the Azure DevOps Artifacts Packaging team at Microsoft where we > provide a Maven service to our customers. We often use a Reason-Phrase to > return information on failed requests to customers. This functionality was > available in previous versions of maven but seems to have disappeared in > Maven 3.6.0. Was this intentional? > I have included screenshots of the cmd line response using two different > maven versions (3.3.9 and 3.6.0). I intentionally made a call that would > return a 405 error to be able to get an error response. I also used the same > package. > Thanks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors
[
https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734730#comment-16734730
]
Brian Fox edited comment on WAGON-541 at 1/5/19 1:59 AM:
-
We've also experienced this as a regression. When the server chooses to provide
additional context, it is not helpful to the user that we squash it. Maven
should pass this information on in the error so someone has a chance of
understanding what happened.
Here is a more salient example of how this handling regressed:
Maven build failures due to firewalled component before Maven 3.6.0 printed a
message like
{quote}
Access denied to: , ReasonPhrase:*Requested item is
quarantined*
{quote}
With Wagon release 3.2.0 ( Maven 3.6.0 ), the reason phrase is no longer
printed - it now looks simply like this:
{quote}
Access denied to:
{quote}
was (Author: brianf):
We've also experienced this as a regression. When the server chooses to provide
additional context, it is not helpful to the user that we squash it. Maven
should pass this information on in the error so someone has a chance of
understanding what happened.
> Command Line Not Showing ReasonPhrase for Errors
>
>
> Key: WAGON-541
> URL: https://issues.apache.org/jira/browse/WAGON-541
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.2.0
> Environment: Windows 10
>Reporter: Aurelie Pluche
>Priority: Minor
> Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG,
> MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG
>
>
> Hi,
> I work in the Azure DevOps Artifacts Packaging team at Microsoft where we
> provide a Maven service to our customers. We often use a Reason-Phrase to
> return information on failed requests to customers. This functionality was
> available in previous versions of maven but seems to have disappeared in
> Maven 3.6.0. Was this intentional?
> I have included screenshots of the cmd line response using two different
> maven versions (3.3.9 and 3.6.0). I intentionally made a call that would
> return a 405 error to be able to get an error response. I also used the same
> package.
> Thanks
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6216) ArrayIndexOutOfBoundsException when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070348#comment-16070348 ] Brian Fox commented on MNG-6216: I'm bumping into this on Mac with 3.5.0 and https://github.com/jeremylong/DependencyCheck/blob/master/pom.xml > ArrayIndexOutOfBoundsException when parsing POM > > > Key: MNG-6216 > URL: https://issues.apache.org/jira/browse/MNG-6216 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Marc Savy > Fix For: 3.5.1 > > Attachments: log > > > When building apiman https://github.com/apiman/apiman.git on Maven 3.5.0 the > XML parser seems to have some issues parsing the apiman-test-common module. > If you want to reproduce, you can simply use mvn clean install, no profiles > needed. > Log: https://gist.github.com/msavy/a1b4307fb238a543dfd6af426b42d446 > Also attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MPH-10) NPE when -Dplugin value can not find specified plugin
[ https://issues.apache.org/jira/browse/MPH-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MPH-10: - Reporter: Barrie Treloar (was: Barrie Treloar) NPE when -Dplugin value can not find specified plugin - Key: MPH-10 URL: https://issues.apache.org/jira/browse/MPH-10 Project: Maven Help Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Barrie Treloar Assignee: Brett Porter Fix For: 2.0.1 Original Estimate: 0.25h Time Spent: 0.25h Remaining Estimate: 0h specifying -Dplugin where help can not find the plugin causes an NPE. mvn help:describe -Dfull=true -Dplugin=eclipse [INFO] Scanning for projects... ...del... [INFO] Searching repository for plugin with prefix: 'help'. [INFO] [INFO] Building Mobile Computing Project [INFO]task-segment: [help:describe] (aggregator-style) [INFO] [INFO] [help:describe] [INFO] Searching repository for plugin with prefix: 'eclipse'. [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugins.help.DescribeMojo.describePlugin(DescribeMojo.java:404) at org.apache.maven.plugins.help.DescribeMojo.execute(DescribeMojo.java:222) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:485) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:455) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav a:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:216) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Jan 25 12:11:03 CST 2006 [INFO] Final Memory: 2M/5M [INFO] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (MDEP-391) Unpack fails on linux with large archives
[ https://jira.codehaus.org/browse/MDEP-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=321555#comment-321555 ] Brian Fox commented on MDEP-391: changed the default permission back to false for backwards compat Unpack fails on linux with large archives - Key: MDEP-391 URL: https://jira.codehaus.org/browse/MDEP-391 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: unpack Affects Versions: 2.6 Environment: Ubuntu 10.04 LTS Reporter: Benoit Montuelle Attachments: lsof.txt When unpacking large archives with numerous files (more than 1024 on this os) I got the following error trace [INFO] Expanding /var/lib/deploy/.m2/repository/com/aprilwaf/wafservice/ihm-packaging-ecg/3.9-finsouscription-SNAPSHOT/ihm-packaging-ecg-3.9-finsouscription-SNAPSHOT-distribution-php.tar.gz to /tmp/tmp5620480517649479513.tar [INFO] Expanding: /tmp/tmp5620480517649479513.tar into /var/lib/deploy/build-deploy/ecg/target/classes org.codehaus.plexus.archiver.ArchiverException: Error while executing chmod. at org.codehaus.plexus.archiver.util.ArchiveEntryUtils.chmod(ArchiveEntryUtils.java:64) at org.codehaus.plexus.archiver.zip.AbstractZipUnArchiver.extractFile(AbstractZipUnArchiver.java:236) at org.codehaus.plexus.archiver.tar.TarUnArchiver.execute(TarUnArchiver.java:92) at org.codehaus.plexus.archiver.tar.TarGZipUnArchiver.execute(TarGZipUnArchiver.java:76) at org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:108) at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:260) at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.unpackArtifact(UnpackMojo.java:122) at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.execute(UnpackMojo.java:95) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while executing process. at org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:652) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:102) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89) at org.codehaus.plexus.archiver.util.ArchiveEntryUtils.chmod(ArchiveEntryUtils.java:45) ... 26 more Caused by: java.io.IOException: Cannot run program /bin/sh (in directory /var/lib/deploy/build-deploy/ecg/target/classes/symfony-1.4/lib/plugins/sfDoctrinePlugin/test/unit/record): java.io.IOException: error=24, Too many open files at java.lang.ProcessBuilder.start(ProcessBuilder.java:460) at java.lang.Runtime.exec(Runtime.java:593) at org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:647) ... 29 more Caused by: java.io.IOException: java.io.IOException: error=24, Too many open files at java.lang.UNIXProcess.init(UNIXProcess.java:148) at java.lang.ProcessImpl.start(ProcessImpl.java:65) at
[jira] (MDEP-403) add a skip configuration option to the dependency plugin
[ https://jira.codehaus.org/browse/MDEP-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MDEP-403: --- Fix Version/s: 2.7 Assignee: Brian Fox add a skip configuration option to the dependency plugin -- Key: MDEP-403 URL: https://jira.codehaus.org/browse/MDEP-403 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: analyze Affects Versions: 2.6 Reporter: Henning Schmiedehausen Assignee: Brian Fox Fix For: 2.7 Attachments: maven-dependency-plugin-skip.patch Most of the maven plugins have a skip configuration option that allows skipping the execution. The dependency plugin has not. This patch adds this configuration property. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-403) add a skip configuration option to the dependency plugin
[ https://jira.codehaus.org/browse/MDEP-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-403. -- Resolution: Fixed patch applied add a skip configuration option to the dependency plugin -- Key: MDEP-403 URL: https://jira.codehaus.org/browse/MDEP-403 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: analyze Affects Versions: 2.6 Reporter: Henning Schmiedehausen Assignee: Brian Fox Fix For: 2.7 Attachments: maven-dependency-plugin-skip.patch Most of the maven plugins have a skip configuration option that allows skipping the execution. The dependency plugin has not. This patch adds this configuration property. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-276) analyzer ignores project directories in a multi-module build
[ https://jira.codehaus.org/browse/MSHARED-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MSHARED-276. - Resolution: Fixed Fix Version/s: maven-dependency-analyzer-1.4 Assignee: Brian Fox analyzer ignores project directories in a multi-module build Key: MSHARED-276 URL: https://jira.codehaus.org/browse/MSHARED-276 Project: Maven Shared Components Issue Type: Bug Components: maven-dependency-analyzer Affects Versions: maven-dependency-analyzer-1.2, maven-dependency-analyzer-1.3 Reporter: Henning Schmiedehausen Assignee: Brian Fox Fix For: maven-dependency-analyzer-1.4 Attachments: DEP-399.patch The dependency analyzer had a patch for MDEP-72 applied a long time ago which in turn makes it ignore the local folders for a multimodule build. This change restores this behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-399) Multi-module dependencies incorrectly marked as unused
[
https://jira.codehaus.org/browse/MDEP-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MDEP-399.
--
Resolution: Fixed
Fix Version/s: 2.7
Assignee: Brian Fox
Multi-module dependencies incorrectly marked as unused
--
Key: MDEP-399
URL: https://jira.codehaus.org/browse/MDEP-399
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: analyze
Affects Versions: 2.0-alpha-4, 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.5.1, 2.6
Reporter: Tim Williamson
Assignee: Brian Fox
Fix For: 2.7
Attachments: DEP-399.patch, mda-test.tar
MDEP-72 made DefaultProjectDependencyAnalyzer.buildArtifactClassMap() only
consider jar files, i.e.:
{code}if ( file != null file.getName().endsWith( .jar ) ){code}
This causes it to ignore all classes defined in a submodule of a multi-module
project. See the attached example. It has two submodules:
- a, which defines an interface Foo
- b, which defines a class FooImpl that implements Foo
Running mvn dependency:analyze results in:
{code}
[WARNING] Unused declared dependencies found:
[WARNING]com.example:a:jar:0.0.1-SNAPSHOT:compile
{code}
The following change fixes the issue:
{code}if ( file != null (file.getName().endsWith( .jar ) ||
file.isDirectory()) ){code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5181) New resolution from local repository is very confusing
[ https://jira.codehaus.org/browse/MNG-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318665#comment-318665 ] Brian Fox commented on MNG-5181: i'm on the fence about if this is good or not, but I think the option if provided should be simple-local-repository without the manager part. People already get confused about what's a local repo vs what's a repository manager and the mixing of these concepts here will make that worse. New resolution from local repository is very confusing -- Key: MNG-5181 URL: https://jira.codehaus.org/browse/MNG-5181 Project: Maven 2 3 Issue Type: Improvement Components: Dependencies Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3 Reporter: Arnaud Heritier Assignee: Olivier Lamy Fix For: 3.1.0 I just discover the change introduced in Maven 3.x to try to improve the resolution mechanism and to avoid to use a local artifact which may not be available in its remote repository : https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository Even if the feature is interesting it has several problems : # When an artifact isn't accessible from its remote repository it isn't used by maven which replies a classical dependency not found error. It is really annoying for a user with some Maven 2 skills which will have a look at his local repo, will find the artifact and won't understand why Maven doesn't use it. At least the error reported by Maven should be clear that even if the dependency is available locally, it isn't used because it's remote repository isn't available. # This behavior cannot be configured to be only a warning for example. It is really annoying because it doesn't take care of some context and constraints we may have in a development team. Let's imagine that the remote artifact is really removed. Cool Maven broke the build to warn us. But it brakes the build of all the team whereas perhaps only one of them may try to solve the issue (and it can be a long resolution). Thus having the ability to configure if this control is blocker or warning may allow the team to configure it as blocker on the CI server and as warning on the development environment. # This behavior may introduce some bad practices for example when we are using a staging feature on a repository manager. In our case my teams have a dedicated profile to activate a staging repository when we are validating a release. I recommend to not have this profile always activated but to do it only on-demand to avoid them to DL staging stuffs they don't need. With this new feature they need for all builds they run to activate this staging profile while binaries are stored in it. When you have to do it 20 times per day minimum let's imagine what the developer does : It adds it as an alwaysActive profile and then forget to remove it when the release is ended. For all these reason I would like we improve this feature to make it more usable and before all bet understandable for ours users. -- 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-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-624: -- Comment: was deleted (was: Change By:Olivier Lamy (22/Oct/12 2:39 PM) Deleted Comment:Voters and Watchers: I registered this issue in the kickstarting section on FreedomSponsors. This means that if you need this issue that bad, you can go to http://www.freedomsponsors.org/core/issue/54/automatic-parent-versioning and offer a few bucks for it. Hey Olivier, just curious, why did you delete that comment? Seems like a good idea...) automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311989#comment-311989 ] Brian Fox commented on MNG-624: --- Tim, Tony, Jira shouldn't be used for advertising of services. The merit of the idea is moot. automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.2 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-5102) Mixin POM fragments
[ https://jira.codehaus.org/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-5102: --- Comment: was deleted (was: I registered this issue in the kickstarting section on FreedomSponsors. This means that if you need this issue that bad, you can go to http://www.freedomsponsors.org/core/issue/35/mixin-pom-fragments and throw in a few bucks for it.) Mixin POM fragments --- Key: MNG-5102 URL: https://jira.codehaus.org/browse/MNG-5102 Project: Maven 2 3 Issue Type: Wish Components: POM Affects Versions: 2.2.1 Reporter: Anthony Whitford Fix For: 3.2 Attachments: daddy3.zip, maven-tiles.zip I am looking for a way to _mixin_ POM fragments into POMs. Note that this idea is beyond parent pom inheritance because all projects inherit from a corporate parent pom. The problem that I am running into is that the corporate parent pom is turning into an _everything but the kitchen sink_ POM and I'd like to dissect it into POM fragments relevant for individual modules. For example, I would like to have mixins for: * Java projects (that include static code analysis plugins, javadoc, etc.) * JPA projects (that include DDL generation) * Flex projects (that include flexmojos, asdoc, etc.) * Scala projects (that include the maven-scala-compiler plugin, scaladoc, etc.) * JavaScript projects (that include build plugins like maven-yuicompressor-plugin with jslint and compress goals) Hopefully, you get the idea. Without the ability to factor pom logic, we are left with two symptoms: # copy/paste duplication # complex _it does it all_ parent poms (which slow down builds because more plugins are loaded even though they might not do anything material) Note that a project may include multiple mixins as I could have a project that contains Java code, Scala code, and JavaScript. Another idea is that the mixins could be parameterized, so that the ultimate pom can be customized based on the parameters (like tokens). I recall reading about Mixins coming in Maven 3.1, but could not find any such issue to watch, so am creating one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4565) Multiple profile activation conditions does not work
[ https://jira.codehaus.org/browse/MNG-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-4565: --- Comment: was deleted (was: From the looks of the details (assignee, fix version), doesn't look very promising. Maybe this issue needs some [sponsoring|http://www.freedomsponsors.org//core/issue/sponsor?trackerURL=http://jira.codehaus.org/browse/MNG-4565] :-) Have anyone tried Eric's github fork? ) Multiple profile activation conditions does not work Key: MNG-4565 URL: https://jira.codehaus.org/browse/MNG-4565 Project: Maven 2 3 Issue Type: Bug Components: Profiles Affects Versions: 2.2.1 Environment: All platforms. Reporter: Nicholas Allen Fix For: Issues to be reviewed for 3.x According to the documentation at http://www.sonatype.com/books/mvnref-book/reference/profiles-sect-activation.html a profile is activated when all activation conditions are met (which makes sense of course). But when I try to use this it does not work. It seems maven does an OR instead of an AND (which is not rearly as useful and is the opposite of what the documentation says at the previous link). For example, if I have one profile that is activated like this: activation activeByDefaultfalse/activeByDefault os namelinux/name /os /activation and another profile that is activated like this: activation activeByDefaultfalse/activeByDefault os namelinux/name /os property namerelease/name valuetrue/value /property /activation Then I would expect the second profile to only be activated if the OS is linux and the release property is defined. When I run 'mvn help:active-profiles' however, maven shows that both profiles are active even though the release property is not defined. -- 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-4565) Multiple profile activation conditions does not work
[ https://jira.codehaus.org/browse/MNG-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox reassigned MNG-4565: -- Assignee: Brian Fox Multiple profile activation conditions does not work Key: MNG-4565 URL: https://jira.codehaus.org/browse/MNG-4565 Project: Maven 2 3 Issue Type: Bug Components: Profiles Affects Versions: 2.2.1 Environment: All platforms. Reporter: Nicholas Allen Assignee: Brian Fox Fix For: Issues to be reviewed for 3.x According to the documentation at http://www.sonatype.com/books/mvnref-book/reference/profiles-sect-activation.html a profile is activated when all activation conditions are met (which makes sense of course). But when I try to use this it does not work. It seems maven does an OR instead of an AND (which is not rearly as useful and is the opposite of what the documentation says at the previous link). For example, if I have one profile that is activated like this: activation activeByDefaultfalse/activeByDefault os namelinux/name /os /activation and another profile that is activated like this: activation activeByDefaultfalse/activeByDefault os namelinux/name /os property namerelease/name valuetrue/value /property /activation Then I would expect the second profile to only be activated if the OS is linux and the release property is defined. When I run 'mvn help:active-profiles' however, maven shows that both profiles are active even though the release property is not defined. -- 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] Closed: (MDEP-231) Create a single dependency resolution plugin
[ https://jira.codehaus.org/browse/MDEP-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-231. -- Resolution: Won't Fix Use the get goal Create a single dependency resolution plugin Key: MDEP-231 URL: https://jira.codehaus.org/browse/MDEP-231 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Components: resolve Affects Versions: 2.1, 2.2 Reporter: Marvin Froeder Assignee: John Casey Fix For: 2.4 Attachments: maven-dependency-plugin.patch, maven-dependency-plugin.patch, maven-dependency-plugin.patch The attached patch has a new goal that allows a single dependency to be resolved, like this: mvn org.apache.maven.plugins:maven-dependency-plugin:2.2-SNAPSHOT:resolve-single -DgroupId=com.acme -DartifactId=dummy -Dversion=1.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEP-166) runtime-scoped dependencies should be specially handled
[ http://jira.codehaus.org/browse/MDEP-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MDEP-166: --- Fix Version/s: (was: 2.2) 2.3 runtime-scoped dependencies should be specially handled --- Key: MDEP-166 URL: http://jira.codehaus.org/browse/MDEP-166 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: analyze Affects Versions: 2.0 Reporter: Max Bowsher Assignee: Brian Fox Fix For: 2.3 Currently the plugin warns that runtime-scope dependencies are unused. It should understand that the correct status for a runtime-scoped dependency is to *not* be discoverable in the bytecode. -- 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: (MDEP-231) Create a single dependency resolution plugin
[ http://jira.codehaus.org/browse/MDEP-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MDEP-231: --- Fix Version/s: (was: 2.2) 2.3 Create a single dependency resolution plugin Key: MDEP-231 URL: http://jira.codehaus.org/browse/MDEP-231 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Components: resolve Affects Versions: 2.1, 2.2 Reporter: Marvin Froeder Assignee: John Casey Fix For: 2.3 Attachments: maven-dependency-plugin.patch, maven-dependency-plugin.patch, maven-dependency-plugin.patch The attached patch has a new goal that allows a single dependency to be resolved, like this: mvn org.apache.maven.plugins:maven-dependency-plugin:2.2-SNAPSHOT:resolve-single -DgroupId=com.acme -DartifactId=dummy -Dversion=1.0 -- 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: (MDEP-265) Add classifier option for dependency:get
[ http://jira.codehaus.org/browse/MDEP-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MDEP-265: --- Fix Version/s: (was: 2.2) 2.3 Add classifier option for dependency:get Key: MDEP-265 URL: http://jira.codehaus.org/browse/MDEP-265 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Andreas Kohn Assignee: Brian Fox Fix For: 2.3 Attachments: MDEP-265-include-artifact-string.diff, MDEP-265.diff The dependency:get mojo is really helpful, but it currently seems to be unable to get an artifact that uses a non-default classifier. Please add a classifier configuration option for the get mojo. -- 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: (MDEP-145) Outputting dependency resolution/tree in a well known _machine readable_ output format
[
http://jira.codehaus.org/browse/MDEP-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MDEP-145:
---
Fix Version/s: (was: 2.2)
2.3
Outputting dependency resolution/tree in a well known _machine readable_
output format
--
Key: MDEP-145
URL: http://jira.codehaus.org/browse/MDEP-145
Project: Maven 2.x Dependency Plugin
Issue Type: Improvement
Components: resolve, tree
Affects Versions: 2.0
Reporter: Samuel Le Berrigaud
Assignee: Brian Fox
Fix For: 2.3
Attachments: MDEP-145-velocity.patch, MDEP-145.zip, treegraph.patch
Currently (at least on trunk) one can output the dependencies in a file.
However the file output doesn't follow any specific format, except from being
the exact same output than on the console.
I would be nice to have an easily parse-able, format so that tools could
leverage the dependency resolution/tree. I am thinking for example of
continuous integration tools that could report on added/removed/updated
dependencies on modules.
The format could be xml, json or something else. I've been playing with the
current output to make it so that:
* the first line describes the current module for which dependency resolution
is done, formatted as such: {{groupId:artifactId:packaging:version}}
* every following line is a dependency (indented by 2 or more spaces),
formatted as such: {{groupId:artifactId:packaging:version:scope}}
This already is easy to parse.
What do you think?
--
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: (MDEP-124) Dependency incorrectly reported as Unused declared
[
http://jira.codehaus.org/browse/MDEP-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MDEP-124:
---
Fix Version/s: (was: 2.2)
2.3
Dependency incorrectly reported as Unused declared
Key: MDEP-124
URL: http://jira.codehaus.org/browse/MDEP-124
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: analyze
Reporter: Olivier Dehon
Assignee: Brian Fox
Fix For: 2.3
When a dependency is only required for a constant in a JAR,
dependency:analyze incorrectly reports the dependency as Unused declared.
Example:
Constants.jar has 1 class called Constants.java:
{code}
package com.myco.util;
public class Constants
{
private Constants() {};
public static final double PI = 3.14159;
}
{code}
Then App jar has App.java as:
{code}
package com.myco.app;
public class App
{
public static void main( String[] args )
{
System.out.println( com.myco.util.Constants.PI );
}
}
{code}
Since the constant gets optimized away in the generated {{App.class}}, the
dependency is not detected, even though the project won't compile without it.
--
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] Assigned: (MPOM-1) apache-release does unwanted things in the prepare goal
[ https://issues.apache.org/jira/browse/MPOM-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox reassigned MPOM-1: Assignee: Brian Fox (was: Olivier Lamy) apache-release does unwanted things in the prepare goal --- Key: MPOM-1 URL: https://issues.apache.org/jira/browse/MPOM-1 Project: Maven POM Issue Type: Bug Reporter: Olivier Lamy Assignee: Brian Fox Fix For: ASF-9 Release 7 of the org.apache:apache use -P to turn on an 'apache-release' profile in the release plugin. By using -P, this profile is turned on in prepare as well as perform. This may turn into a contest of opinion, and you all may just tell me to jump in a lake, but I think this is a bad idea. At prepare time, we're just looking to get the versions setup and the tag made. Having to deal with gpg signing, and source archiving seems out of place. At very least, I'd request that this the arguments/ element be left out of the release plugin spec. If some project wants to use that particular collection of functions, fine. For the rest of us, who just want to get distribution management and other universals, you we wouldn't have to worry about it. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPOM-1) apache-release does unwanted things in the prepare goal
[ https://issues.apache.org/jira/browse/MPOM-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12993143#comment-12993143 ] Brian Fox commented on MPOM-1: -- A little history on this setup: It was moved to the ASF pom from the Maven pom when we tried to provide correct defaults for all ASF projects built with Maven after a lengthy discussion on legal about minimal release requirements. The conclusion was to encapsulate best practices so projects that aren't maven experts can still get meet the release requirements. This particular configuration of the release plugin dates back to the very first setup of the release profiles in the Maven pom, specifically added here: http://svn.apache.org/viewvc?view=revisionrevision=502422 a little over 4 years ago. apache-release does unwanted things in the prepare goal --- Key: MPOM-1 URL: https://issues.apache.org/jira/browse/MPOM-1 Project: Maven POM Issue Type: Bug Reporter: Olivier Lamy Assignee: Brian Fox Fix For: ASF-9 Release 7 of the org.apache:apache use -P to turn on an 'apache-release' profile in the release plugin. By using -P, this profile is turned on in prepare as well as perform. This may turn into a contest of opinion, and you all may just tell me to jump in a lake, but I think this is a bad idea. At prepare time, we're just looking to get the versions setup and the tag made. Having to deal with gpg signing, and source archiving seems out of place. At very least, I'd request that this the arguments/ element be left out of the release plugin spec. If some project wants to use that particular collection of functions, fine. For the rest of us, who just want to get distribution management and other universals, you we wouldn't have to worry about it. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MPOM-1) apache-release does unwanted things in the prepare goal
[ https://issues.apache.org/jira/browse/MPOM-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox reopened MPOM-1: -- This needs a different approach. If people don't want to use the profile by default, then lets put the profile argument into a property that can easily be overridden. It is very important though that we have proper release proceedures embodied by default in the ASF pom. People shouldn't have to customize sections of their poms to get proper releases. As it was done in the previous release, it just works apache-release does unwanted things in the prepare goal --- Key: MPOM-1 URL: https://issues.apache.org/jira/browse/MPOM-1 Project: Maven POM Issue Type: Bug Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: ASF-9 Release 7 of the org.apache:apache use -P to turn on an 'apache-release' profile in the release plugin. By using -P, this profile is turned on in prepare as well as perform. This may turn into a contest of opinion, and you all may just tell me to jump in a lake, but I think this is a bad idea. At prepare time, we're just looking to get the versions setup and the tag made. Having to deal with gpg signing, and source archiving seems out of place. At very least, I'd request that this the arguments/ element be left out of the release plugin spec. If some project wants to use that particular collection of functions, fine. For the rest of us, who just want to get distribution management and other universals, you we wouldn't have to worry about it. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEP-225) Dependency plugin seems to unpack archive even, if it is already unpacked
[ http://jira.codehaus.org/browse/MDEP-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MDEP-225: --- Fix Version/s: 2.2 Dependency plugin seems to unpack archive even, if it is already unpacked - Key: MDEP-225 URL: http://jira.codehaus.org/browse/MDEP-225 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: unpack Affects Versions: 2.1 Reporter: Jason Chaffee Assignee: Brian Fox Fix For: 2.2 Attachments: MDEP-225-plh.patch, MDEP-225-plh2.patch, MDEP-225.patch, MDEP-225.patch The plugin used to be smart about not unpacking archives if it found the archive was already unpacked (maybe I was doing something different than..not sure). However, now it unpacks the archive every time, no matter what I try to keep it from doing it, including using overwriteIfNewer. I would like to be able to run the build once to extract the archive, then not have it extracted again, unless I clean the target directory because the archive takes several minutes to unpack. Here are the steps. 1) configure unpack in pom 2) run mvn clean install -- expect unpacking 3) run mvn install -- do not expect unpacking as it is still unpaced from step (2) -- 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: (MDEP-225) Dependency plugin seems to unpack archive even, if it is already unpacked
[ http://jira.codehaus.org/browse/MDEP-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-225. -- Resolution: Fixed patch applied, thanks. Dependency plugin seems to unpack archive even, if it is already unpacked - Key: MDEP-225 URL: http://jira.codehaus.org/browse/MDEP-225 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: unpack Affects Versions: 2.1 Reporter: Jason Chaffee Assignee: Brian Fox Attachments: MDEP-225-plh.patch, MDEP-225-plh2.patch, MDEP-225.patch, MDEP-225.patch The plugin used to be smart about not unpacking archives if it found the archive was already unpacked (maybe I was doing something different than..not sure). However, now it unpacks the archive every time, no matter what I try to keep it from doing it, including using overwriteIfNewer. I would like to be able to run the build once to extract the archive, then not have it extracted again, unless I clean the target directory because the archive takes several minutes to unpack. Here are the steps. 1) configure unpack in pom 2) run mvn clean install -- expect unpacking 3) run mvn install -- do not expect unpacking as it is still unpaced from step (2) -- 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: (MAVENUPLOAD-2806) Upload jsch-0.1.43 to Central
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2806. -- Resolution: Won't Fix Please see here:https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+Maven+Central Upload jsch-0.1.43 to Central - Key: MAVENUPLOAD-2806 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2806 Project: Maven Upload Requests Issue Type: Task Reporter: Martin Todorov Attachments: jsch-0.1.43.jar, jsch-0.1.43.pom Hi, A newer version of jsch already exists. It would be very much appreciated, if you could upload it to Maven Central. This library is used by many projects and Maven plugins. Our current workaround is to upload the jar manually to our own Nexus, but I am sure that a lot of other people would benefit from the newer version in Central as well. I am attaching both the artifact and a pom file for it. Thanks in advance, Regards, Martin Todorov -- 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: (MAVENUPLOAD-2807) Please upload mysql connector/mxj 5.0.12 to maven cental
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2807. -- Resolution: Won't Fix Please see https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+Maven+Central Please upload mysql connector/mxj 5.0.12 to maven cental Key: MAVENUPLOAD-2807 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2807 Project: Maven Upload Requests Issue Type: Wish Reporter: Thomas Dudziak Attachments: pom-dbfiles.xml, pom.xml The tar.gz or zip bundle available at the bundle url contain two jars: mysql-connector-mxj-gpl-5-0-11.jar mysql-connector-mxj-gpl-5-0-11-db-files.jar Please find attached the pom.xml files for these. The proposed group and artifact ids are com.mysql:management com.mysql:management-dbfiles to be in line with an older version of it uploaded via MAVENUPLOAD-938. -- 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: (MAVENUPLOAD-2811) upload new release 2.0.0 to org.mentaframework
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2811. -- Resolution: Won't Fix Please see:https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+Maven+Central upload new release 2.0.0 to org.mentaframework --- Key: MAVENUPLOAD-2811 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2811 Project: Maven Upload Requests Issue Type: Task Reporter: Fernando Boaglio The Mentawai goal is to be a simple, flexible, joyful and productive Java web framework. This is a new release with a lot of improvements . TIA -- 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: (MAVENUPLOAD-2810) Please Upload Metastopheles 1.2 Release
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2810. -- Resolution: Won't Fix Please see https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+Maven+Central Please Upload Metastopheles 1.2 Release --- Key: MAVENUPLOAD-2810 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2810 Project: Maven Upload Requests Issue Type: Task Reporter: James Carman To import my PGP key: gpg --keyserver hkp://pgp.mit.edu --recv-keys 63B732A8 -- 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-294) copy-dependencies goal doesn't properly respect classifier when creating base version of snapshots
[ http://jira.codehaus.org/browse/MDEP-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=245691#action_245691 ] Brian Fox commented on MDEP-294: Can you add a test? copy-dependencies goal doesn't properly respect classifier when creating base version of snapshots -- Key: MDEP-294 URL: http://jira.codehaus.org/browse/MDEP-294 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: copy-dependencies Affects Versions: 2.1 Reporter: Tim Downey Assignee: Brian Fox Attachments: CopyDependenciesMojo.java, CopyDependenciesMojo.java.diff CopyDependenciesMojo ignores any classifier on the artifact being copied when creating the base version of a snapshot. It works correctly for the non-base (timestamped) version. This leads to a mismatch in the copied dependencies where the timestamped version correctly keeps the classifier, but the base -SNAPSHOT version has the classifier completely dropped. The fix is simple, although a bit ugly. In the installBaseSnapshot method, a check must be made for the presence of a classifier on the artifact being copied before using the ArtifactFactory to create a copy of the base version. Ideally, the ArtifactFactory would expose a single method that takes all parameters, but unfortunately it does not. This requires a separate 'if' check for the presence of a classifier. Another potential issue is that the method ArtifactFactory#createArtifactWithClassifier has no parameter for scope. I don't think that causes any issue in this case, but is another reason why there should be a single method createArtifact that takes all combinations of parameters including classifier. I've attached a patch that will fix the issue, but not a test case since it looks like the maven-plugin-testing-tools-harness would need to be updated as well. It doesn't appear to expose any artifacts that both have a classifier and are snapshots from the ArtifactStubFactory. If deemed important, I can produce a patch for that as well along with a test. -- 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-273) Analyze Dependency Versions Mojo
[ http://jira.codehaus.org/browse/MDEP-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=243252#action_243252 ] Brian Fox commented on MDEP-273: We usually add a small section to the usage page describing the new goal and how it's used. Analyze Dependency Versions Mojo Key: MDEP-273 URL: http://jira.codehaus.org/browse/MDEP-273 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Affects Versions: 2.2 Reporter: Cole Mickens Assignee: Brian Fox Attachments: analyze-dep-versions.patch, core.PNG, script-ant.PNG This is a patch that adds a new mojo and a report class to maven-dependency-plugin trunk (2.2). The goal `dependency:analyze-dep-versions` lists dependencies that are either resolved at a lower version than needed by a dependency farther from the project root or are being overridden by the dependencyManagement section. In some sense it is complimentary to `dependency:analyze-dep-mgt`. I checked out trunk today, added my new files, `svn add`ed them, then performed an `svn diff`. The patches applied correctly with a rechecked out copy of trunk with `cd apache-maven-dependency-plugin; patch -p0 ../analyze-dep-versions.patch`. After patching, it built, installed and passed IT tests (including the 6 new ones that I've added) properly. -- 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-4893) [regression] Version x.y.z.SNAPSHOT does not deploy correctly
[
http://jira.codehaus.org/browse/MNG-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242791#action_242791
]
Brian Fox commented on MNG-4893:
I think we should stick with the x.y.z-SNAPSHOT form for both expanded and
non-expanded forms. Widening that pattern in Maven is just bound to cause
additional problems in all the ecosystem tools that need to interpret snapshot
v release
[regression] Version x.y.z.SNAPSHOT does not deploy correctly
-
Key: MNG-4893
URL: http://jira.codehaus.org/browse/MNG-4893
Project: Maven 2 3
Issue Type: Bug
Components: Deployment
Affects Versions: 3.0
Reporter: Paul Gier
Priority: Critical
Fix For: 3.0.1
When using a version that ends with .SNAPSHOT instead of the usual
-SNAPSHOT, Maven 3.0 changes the project version to the timestamped
version. So 5.2.0.SNAPSHOT becomes something like
5.2.0.20101109.215833-1. A Nexus snapshot repository will reject this
deployment because the version in the directory name does not end with
SNAPSHOT.
I tested that this works in Maven 2.2.1 and Maven 3.0-beta-1, but does not
work in Maven 3.0. The build returns an HTTP 400 error when deploying to
Nexus.
Error from Nexus log
{noformat}
2010-11-09 22:02:23 INFO [1298122354-2147] - o.s.n.p.m.m.M2Repos~ - Storing
of item snapshots:/org/drools
/drools/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom is
forbidden by Maven Repository
policy. Because snapshots is a SNAPSHOT repository
2010-11-09 22:02:23 ERROR [1298122354-2147] - o.s.n.r.ContentPlex~ - Got
exception during processing
request PUT
http://repository.jboss.org/nexus/content/repositories/snapshots/org/drools/drools
/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom: Storing of
item snapshots:/org/drools
/drools/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom is
forbidden by Maven Repository
policy. Because snapshots is a SNAPSHOT repository
{noformat}
--
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: (MDEP-262) Add support for custom ProjectDependencyAnalyzer implementations
[ http://jira.codehaus.org/browse/MDEP-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-262. -- Resolution: Fixed Fix Version/s: 2.2 Add support for custom ProjectDependencyAnalyzer implementations Key: MDEP-262 URL: http://jira.codehaus.org/browse/MDEP-262 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: analyze Reporter: Tobias Gierke Assignee: Brian Fox Fix For: 2.2 Attachments: maven-dependency-analyzer_1.2.patch, maven-dependency-analyzer_1.2.patch, maven-dependency-plugin_2.2.patch, maven-dependency-plugin_2.2.patch I've written a customized ProjectDependencyAnalyzer (includes dependencies from Spring XMLs) that I'd like to be able to use with the maven-dependency-plugin. The current plugin implementation only supports a single ProjectDependencyAnalyzer component on the classpath (otherwise plexus will fail) and has no way of specifying which analyzer to use at runtime. The appended patches add support for custom ProjectDependencyAnalyzer components to the plugin. The basic idea is to assign ProjectDependencyAnalyzer components a unique role-hint and let the plugin dynamically look-up the implementation to use by specifying the role-hint as configuration parameter. 1. maven-dependency-analyzer_1.2.patch Patch against maven-dependency-analyzer 1.2-SNAPSHOT (trunk / r942613) To apply patch: patch -p1 maven-dependency-analyzer_1.2.patch CHANGES: - DefaultProjectDependencyAnalyzer component now has an additonal role-hint 'default' so plexus won't complain when multiple ProjectDependencyAnalyzer components are one the classpath - changes the visibility of buildDependencyClasses() and findArtifactForClassName() from private to protected to allow subclassing - buildDependencyClasses() now takes the artifact map as additional parameter so subclasses can call findArtifactForClassName() with it 2. maven-dependency-plugin_2.2.patch Patch against maven-dependency-plugin 2.2-SNAPSHOT (trunk / r942613) To apply patch: patch -p1 maven-dependency-plugin_2.2.patch CHANGES: - AbstractDependencyMojo now has a new 'analyzer' parameter that is the role hint to use when looking up the ProjectDependencyAnalyzer from the container ( the default value is set to 'default' and thus references DefaultProjectDependencyAnalyzer) - AbstractDependencyMojo now implements Contextualizable and dynamically looks up the ProjectDependencyAnalyzer component to use from the plexus container - Integration test added that first buids and installs a custom dummy ProjectDependencyAnalyzer component and then runs dependency:analyze with this analyzer -- 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: (MDEP-211) Possibility to prepend groupId to dependencies
[ http://jira.codehaus.org/browse/MDEP-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-211. -- Resolution: Fixed Fix Version/s: 2.2 Possibility to prepend groupId to dependencies -- Key: MDEP-211 URL: http://jira.codehaus.org/browse/MDEP-211 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: build-classpath, copy-dependencies Affects Versions: 2.2 Reporter: Oumar Aziz OUATTARA Assignee: Brian Fox Fix For: 2.2 Attachments: add_parameter_prepend_groupId.patch Hi, I would like to use the dependency plugin to copy dependencies including the groupId in the destination filename. This is to be able afterward to classify the plugins based on their groupId. It can also avoid a scenario like two dependencies with different groupIds and the same ArtifactId to collide when doing the copy. For this I propose a new configuration parameter prependGroupId. See attached patch for more details. -- 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-231) Create a single dependency resolution plugin
[ http://jira.codehaus.org/browse/MDEP-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242249#action_242249 ] Brian Fox commented on MDEP-231: no tests, no docs/site updates for the new goal Create a single dependency resolution plugin Key: MDEP-231 URL: http://jira.codehaus.org/browse/MDEP-231 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Components: resolve Affects Versions: 2.1, 2.2 Reporter: Marvin Froeder Assignee: John Casey Fix For: 2.2 Attachments: maven-dependency-plugin.patch, maven-dependency-plugin.patch, maven-dependency-plugin.patch The attached patch has a new goal that allows a single dependency to be resolved, like this: mvn org.apache.maven.plugins:maven-dependency-plugin:2.2-SNAPSHOT:resolve-single -DgroupId=com.acme -DartifactId=dummy -Dversion=1.0 -- 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-273) Analyze Dependency Versions Mojo
[ http://jira.codehaus.org/browse/MDEP-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242250#action_242250 ] Brian Fox commented on MDEP-273: can you provide a patch to add proper site updates for your new goal? Analyze Dependency Versions Mojo Key: MDEP-273 URL: http://jira.codehaus.org/browse/MDEP-273 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Affects Versions: 2.2 Reporter: Cole Mickens Assignee: Brian Fox Attachments: analyze-dep-versions.patch, core.PNG, script-ant.PNG This is a patch that adds a new mojo and a report class to maven-dependency-plugin trunk (2.2). The goal `dependency:analyze-dep-versions` lists dependencies that are either resolved at a lower version than needed by a dependency farther from the project root or are being overridden by the dependencyManagement section. In some sense it is complimentary to `dependency:analyze-dep-mgt`. I checked out trunk today, added my new files, `svn add`ed them, then performed an `svn diff`. The patches applied correctly with a rechecked out copy of trunk with `cd apache-maven-dependency-plugin; patch -p0 ../analyze-dep-versions.patch`. After patching, it built, installed and passed IT tests (including the 6 new ones that I've added) properly. -- 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: (MDEP-149) Field accesses and method invocations cause bogus dependencies
[
http://jira.codehaus.org/browse/MDEP-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MDEP-149.
--
Resolution: Fixed
Fix Version/s: 2.2
Field accesses and method invocations cause bogus dependencies
--
Key: MDEP-149
URL: http://jira.codehaus.org/browse/MDEP-149
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: analyze
Affects Versions: 2.0
Reporter: Benjamin Bentmann
Assignee: Brian Fox
Priority: Trivial
Fix For: 2.2
Attachments: bogus-dependencies.patch, MDEP-149.zip
When hunting down some Used undeclared dependencies warnings, I found the
plugin lying. For example, the line
{code:java}
java.lang.Object var = bean.field;
{code}
does not impose a direct dependency on the field's type, whatever it may be.
Likewise, the line
{code:java}
bean.method(null);
{code}
does not directly depend on the method's return type nor parameter types.
Unless I explicitly code a reference to a type by means of variable
declarations, type checks/casts etc., there is no need to declare
dependencies that are already brought in via transitivity, that's what Maven
was invented for, isn't is ;-)
--
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: (MDEP-215) copy-dependencies -- useSubDirectoryPerScope [patch]
[ http://jira.codehaus.org/browse/MDEP-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-215. -- Resolution: Fixed Fix Version/s: 2.2 copy-dependencies -- useSubDirectoryPerScope [patch] Key: MDEP-215 URL: http://jira.codehaus.org/browse/MDEP-215 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Components: copy-dependencies Affects Versions: 2.1 Reporter: Jo Odland Assignee: Brian Fox Fix For: 2.2 Attachments: useSubDirectoryPerScope-rev771391.diff I have added a useSubDirectoryPerScope configuration setting. This will copy all artefacts into folders based on scope (like /outputDirectory/test/junit-3.8.1-jar) -- 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: (MDEP-292) When selecting groupId fuzziness, exclude all artifacts based on groupId.
[ http://jira.codehaus.org/browse/MDEP-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-292. -- Resolution: Fixed Fix Version/s: 2.2 When selecting groupId fuzziness, exclude all artifacts based on groupId. - Key: MDEP-292 URL: http://jira.codehaus.org/browse/MDEP-292 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: purge-local-repository Affects Versions: 2.1 Reporter: Greg Vanore Assignee: Brian Fox Fix For: 2.2 Attachments: use-groupId-sensitivity-when-building-exclusions.diff This patch includes a simple change to the PurgeLocalRepositoryMojo class so that when the resolutionFuzziness is set to 'groupId,' the exclusions are treated by groupId. This is because if I have two dependencies, such as 'org.slf4j:slf4j-api' and 'org.slf4j:slf4j-log4j' and I only list one of them in my exclusions and set the fuzziness to groupId, the entire group will still be deleted. It seemed more natural to me that if the fuzziness is at the groupId level, that the exclusions should be based on which groupIds have been excluded. -- 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-253) Purge does not purge released artifacts
[ http://jira.codehaus.org/browse/MDEP-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242145#action_242145 ] Brian Fox commented on MDEP-253: Is there any configuration in your pom that could alter the behavior? I just tried it here and it did what I expected. Purge does not purge released artifacts --- Key: MDEP-253 URL: http://jira.codehaus.org/browse/MDEP-253 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: purge-local-repository Affects Versions: 2.0 Environment: Linux, JDK 1.5, Maven 2.0.10 Reporter: James Lorenzen Assignee: Brian Fox I am running into a problem when running mvn dependency:purge-local-repository in that it does not remove any local artifacts for a large multi-module project. I run it from the parent directory and it reports the following for all my sub modules [INFO] Nothing to do for project: ... I expect the goal to examine all my dependencies, including transitive dependencies, and remove them from the local repository. -- 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: (MDEP-281) An option to append outputs at the end of output file
[ http://jira.codehaus.org/browse/MDEP-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-281. -- Resolution: Fixed Fix Version/s: 2.2 An option to append outputs at the end of output file - Key: MDEP-281 URL: http://jira.codehaus.org/browse/MDEP-281 Project: Maven 2.x Dependency Plugin Issue Type: Wish Components: resolve, tree Affects Versions: 2.1 Reporter: Selim Ok Assignee: Brian Fox Fix For: 2.2 Attachments: appendOutput.patch It would be nice to have a command line switch to decide, whether the output file will be overwritten or not. Currently the output file is completely overwritten each time. This behavior has a drawback, espceially if i try to get all dependencies of a multi module project. The output file is overwritten for each module and so I get at the end the dependency tree of the last module. For this whish i have prepared a little patch. I'll be very happy, if you accept my commitment. P.S.: Sorry for my bad english. :/ P.S.2: I'm not very sure, if this issue is a feature or wish , please forgive me if i'm wrong. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-192) generated classpath should match what maven produces
[
http://jira.codehaus.org/browse/MDEP-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MDEP-192.
--
Resolution: Fixed
Fix Version/s: 2.2
generated classpath should match what maven produces
Key: MDEP-192
URL: http://jira.codehaus.org/browse/MDEP-192
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: build-classpath
Affects Versions: 2.0, 2.1
Environment: all
Reporter: deckrider
Assignee: Brian Fox
Fix For: 2.2
Attachments: build-classpath.patch
The generated classpath should be what maven produces, but appears to be in
some other order when the following configuration is used for both version
2.0 and today's (Dec 12, 2008) latest trunk:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idclasspathUnix/id
phasegenerate-sources/phase
goals
goalbuild-classpath/goal
/goals
configuration
pathSeparator:/pathSeparator
prefix${project.artifactId}/prefix
outputFile${project.build.directory}/${project.artifactId}-unix.classpath/outputFile
/configuration
/execution
/executions
/plugin
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEP-284) Get Mojo ignores the transitive attribute because of a typo in the parameter declaration
[
http://jira.codehaus.org/browse/MDEP-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MDEP-284:
---
Attachment: mdep-284.patch
Updated patch, but the tests keep failing for me. Moving to the next patch for
now.
Get Mojo ignores the transitive attribute because of a typo in the parameter
declaration
Key: MDEP-284
URL: http://jira.codehaus.org/browse/MDEP-284
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Baptiste MATHUS
Assignee: Brian Fox
Attachments: maven-dependency-get-transitive.patch, mdep-284.patch
[Note : get is missing as a component for MDEP jira.]
Due to a typo in the GetMojo code, transitive resolution doesn't work.
@parameter was set to {$transitive} instead of ${transitive}.
Thanks a lot.
PS : I tried providing the corresponding ITs, but didn't really manage to
cope with configuring the (stub) environment. I'm providing the unfinished
code anyway, since I think it might be missing not much. Feel free to wipe
all ITs I tried to initiate if it's simpler. I think I'll have a look at how
you do it, if you find time for that.
--
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: (MENFORCER-109) Error in logged output message from dependency-convergence rule, make the rule less usable
[ http://jira.codehaus.org/browse/MENFORCER-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MENFORCER-109. --- Resolution: Fixed Fix Version/s: 1.0 Error in logged output message from dependency-convergence rule, make the rule less usable -- Key: MENFORCER-109 URL: http://jira.codehaus.org/browse/MENFORCER-109 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Components: Standard Rules Affects Versions: 1.0 Environment: all Reporter: Rex Hoffman Fix For: 1.0 Attachments: fix_output_message.txt The error message showing the path to the failed dependency convergence only prints the the leaf node artifact name at each level of message, instead of the nodes leading to the dependency. Nodes paths that did not converge would be printed like this: +-org.slf4j:slf4j-api1.6.0 +-org.slf4j:slf4j-api1.6.0 +-org.slf4j:slf4j-api1.6.0 Instead of like this: +-org.myorg:my-project:1.0.0-SNAPSHOT +-org.slf4j:slf4j-nop:1.6.0 +-org.slf4j:slf4j-api:1.6.0 assuming I must have submitted the patch with this bug... Here is a fix, which cleans up the output message, and updates the site to show a correct example. This is a tiny fix, and I would like to see it in before the 1.0 release. -- 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: (MENFORCER-108) Documentation/Typo : 'unCheckedPluginsList' is written instead of 'unCheckedPluginList'
[ http://jira.codehaus.org/browse/MENFORCER-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MENFORCER-108. --- Resolution: Fixed Fix Version/s: 1.0 Documentation/Typo : 'unCheckedPluginsList' is written instead of 'unCheckedPluginList' --- Key: MENFORCER-108 URL: http://jira.codehaus.org/browse/MENFORCER-108 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Components: Standard Rules Affects Versions: 1.0-beta-1 Reporter: Jonathan Perret Priority: Minor Fix For: 1.0 The documentation at http://maven.apache.org/enforcer/enforcer-rules/requirePluginVersions.html uses the element name 'unCheckedPluginsList', both in the parameter list and in the sample, where it should use 'unCheckedPluginList' (note singular 'Plugin'). See http://svn.apache.org/viewvc/maven/enforcer/tags/enforcer-1.0-beta-1/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequirePluginVersions.java?r1=729232r2=746626diff_format=h#l122 for proof that the rule expects 'unCheckedPluginList'. -- 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: (MENFORCER-98) requirePluginVersions rule is not compatible with maven 3.0-beta-1
[ http://jira.codehaus.org/browse/MENFORCER-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=241242#action_241242 ] Brian Fox commented on MENFORCER-98: The warning is changed to info and the message is updated in 1.0 requirePluginVersions rule is not compatible with maven 3.0-beta-1 -- Key: MENFORCER-98 URL: http://jira.codehaus.org/browse/MENFORCER-98 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Components: Standard Rules Affects Versions: 1.0-beta-1 Environment: Windows XP Sun JDK 1.6.0_18 Maven 3.0-beta-1 Reporter: Anders Hammar When using the requirePluginVersions rule, I get a message saying This rule is not compatible with the current version of Maven. The rule is not able to perform any checks. -- 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: (MENFORCER-105) requirePluginVersions rule doesn't work with POM named other than pom.xml
[ http://jira.codehaus.org/browse/MENFORCER-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MENFORCER-105. --- Resolution: Fixed Fix Version/s: 1.0 requirePluginVersions rule doesn't work with POM named other than pom.xml - Key: MENFORCER-105 URL: http://jira.codehaus.org/browse/MENFORCER-105 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Components: Standard Rules Affects Versions: 1.0-beta-2 Environment: RH-EL 5, java 1.6.0_14, maven 2.2.1 Reporter: Uriel Volovich Fix For: 1.0 My POM file have name NOT pom.xml. When I runs build enforcer failed with exception: org.apache.maven.enforcer.rule.api.EnforcerRuleException: Unable to download the artifact from any repository The stacktrace of the cause exception: [DEBUG] Unable to locate resource in repository org.apache.maven.wagon.ResourceDoesNotExistException: Unable to locate resource in repository at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:139) 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.getArtifact(DefaultWagonManager.java:427) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:382) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:216) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:90) at org.apache.maven.plugins.enforcer.utils.EnforcerRuleUtils.getPomModel(EnforcerRuleUtils.java:210) at org.apache.maven.plugins.enforcer.utils.EnforcerRuleUtils.getModelsRecursively(EnforcerRuleUtils.java:237) at org.apache.maven.plugins.enforcer.RequirePluginVersions.getAllPluginEntries(RequirePluginVersions.java:1014) at org.apache.maven.plugins.enforcer.RequirePluginVersions.execute(RequirePluginVersions.java:219) at org.apache.maven.plugins.enforcer.EnforceMojo.execute(EnforceMojo.java:185) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) ... It seems, that bug in the file enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequirePluginVersions.java at line 1014: List models = utils.getModelsRecursively( project.getGroupId(), project.getArtifactId(), project.getVersion(), new File( project.getBasedir(), pom.xml ) ); POM name is hardcoded as pom.xml!!! So it should be replaced with: List models = utils.getModelsRecursively( project.getGroupId(), project.getArtifactId(), project.getVersion(), new File( project.getBasedir(), project.getFile().getName() ) ); -- 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: (MENFORCER-107) An enforcer rule that demands developers ensure all dependency (and transitive dependency) version numbers converge
[ http://jira.codehaus.org/browse/MENFORCER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MENFORCER-107. --- Resolution: Fixed Fix Version/s: 1.0-beta-2 Assignee: Brian Fox An enforcer rule that demands developers ensure all dependency (and transitive dependency) version numbers converge --- Key: MENFORCER-107 URL: http://jira.codehaus.org/browse/MENFORCER-107 Project: Maven 2.x Enforcer Plugin Issue Type: Improvement Components: Standard Rules Affects Versions: 1.0-beta-2 Reporter: Rex Hoffman Assignee: Brian Fox Fix For: 1.0-beta-2 Attachments: noconflicts.tar.gz Includes it cases. Currently formatted as it's own maven project. No tricks used in the maven compilation, so it should be trivial to merge. Copy the class and src/it cases, though the dependencies will change slightly (don't hard code the enforcer rule version) and remove the other dependency. Included an apt page that explains the rule. Should also be be almost a cut and past. Will have to do the same artifact fixes to the usage section. Marked as major as there is no good existing workaround Marking as a patch, because it's close. If you want me to prep it as a straight patch, please point me to the best branch... All probably between 15 and 30 minutes. -- 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: (MENFORCER-101) Enforcer does not allow to restrict based on SNAPSHOT version as version comparison uses artifact.getVersion() instead of artifact.getBaseVersion()
[
http://jira.codehaus.org/browse/MENFORCER-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MENFORCER-101.
---
Resolution: Fixed
Fix Version/s: 1.0-beta-2
Enforcer does not allow to restrict based on SNAPSHOT version as version
comparison uses artifact.getVersion() instead of artifact.getBaseVersion()
---
Key: MENFORCER-101
URL: http://jira.codehaus.org/browse/MENFORCER-101
Project: Maven 2.x Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 1.0-beta-1
Environment: Any
Reporter: Prashant Bhate
Fix For: 1.0-beta-2
When following restriction is given to banned dependency rule, comparison
fails as it compare with actual snapshot version in the repository (which
includes timestamp 1.0-20100715.155142-18 ) instead of base version ( which
has 1.0-SNAPSHOT )
{code:xml}
build
plugins
plugin
artifactIdmaven-enforcer-plugin/artifactId
executions
execution
idenforce-snapshot-ver/id
goals
goalenforce/goal
/goals
configuration
rules
bannedDependencies
searchTransitivetrue/searchTransitive
excludes
excludeorg.apache.maven.enforcer:enforcer-rules/exclude
/excludes
includes
includeorg.apache.maven.enforcer:enforcer-rules:[1.0-beta-2-SNAPSHOT]/include
/includes
/bannedDependencies
/rules
failtrue/fail
/configuration
/execution
/executions
/plugin
/plugins
..
..
..
dependencies
dependency
groupIdorg.apache.maven.enforcer/groupId
artifactIdenforcer-rules/artifactId
version1.0-beta-2-SNAPSHOT/version
/dependency
/dependencies
{code}
See code snippet below
{code:title=BannedDependencies.java|borderStyle=solid}
try
{
result = AbstractVersionEnforcer.containsVersion(
VersionRange.createFromVersionSpec( pattern[2] ),
new DefaultArtifactVersion( artifact.getVersion() )
);
}
catch ( InvalidVersionSpecificationException e )
{
throw new EnforcerRuleException( Invalid Version Range: , e );
}
{code}
replace
{code}
new DefaultArtifactVersion( artifact.getVersion() )
{code}
with
{code}
new DefaultArtifactVersion( artifact.getBaseVersion() )
{code}
will solve this 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] Commented: (MASSEMBLY-517) Assembly fails with empty id element now
[
http://jira.codehaus.org/browse/MASSEMBLY-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240972#action_240972
]
Brian Fox commented on MASSEMBLY-517:
-
From my POV this was a good change. Each pom can produce one artifact with a
null classifier and that type should be described by the packaging type.
Having an artifact like a zip deployed with a null classifier from a
packagingpom/packaging pom causes tons of problems with other tools trying
to understand the artifact. The fact is packaging pom means it is a pom and
that's it.
Assembly fails with empty id element now
Key: MASSEMBLY-517
URL: http://jira.codehaus.org/browse/MASSEMBLY-517
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Eric Haszlakiewicz
Priority: Critical
There is a serious regression in behaviour between version 2.2-beta-5 and
2.2. With version 2.2, assembly descriptors that have an empty id element no
longer work. i.e.:
assembly
id/id
formatsformattar.gz/format/formats
/assembly
The error message is:
[INFO] [assembly:single {execution: assemble-tar-gzip}]
[INFO] Reading assembly descriptor: src/main/assembly/assembly.xml
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] : org.apache.maven.plugin.assembly.model.assem...@15fddb33
Assembly is incorrectly configured:
Assembly: is not configured correctly: Assembly ID must be present and
non-empty.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-517) Assembly fails with empty id element now
[
http://jira.codehaus.org/browse/MASSEMBLY-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240973#action_240973
]
Brian Fox commented on MASSEMBLY-517:
-
This was intentionally introduced by MASSEMBLY-464
Assembly fails with empty id element now
Key: MASSEMBLY-517
URL: http://jira.codehaus.org/browse/MASSEMBLY-517
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Eric Haszlakiewicz
Priority: Critical
There is a serious regression in behaviour between version 2.2-beta-5 and
2.2. With version 2.2, assembly descriptors that have an empty id element no
longer work. i.e.:
assembly
id/id
formatsformattar.gz/format/formats
/assembly
The error message is:
[INFO] [assembly:single {execution: assemble-tar-gzip}]
[INFO] Reading assembly descriptor: src/main/assembly/assembly.xml
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] : org.apache.maven.plugin.assembly.model.assem...@15fddb33
Assembly is incorrectly configured:
Assembly: is not configured correctly: Assembly ID must be present and
non-empty.
--
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: (MAVENUPLOAD-2804) Sync org.patterntesting repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2804. -- Resolution: Won't Fix As the project description says, the rsyncs are no longer supported. You can see here for information about how to get stuff into central: http://maven.apache.org/guides/mini/guide-central-repository-upload.html Sync org.patterntesting repository -- Key: MAVENUPLOAD-2804 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2804 Project: Maven Upload Requests Issue Type: Task Reporter: Oliver Boehm Attachments: org.patterntesting.sh Please synchronize http://patterntesting.sourceforge.net/m2/repository/ to the central maven repository. (http://jira.codehaus.org/browse/MAVENUPLOAD-1911 is obsolete now) -- 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: (MAVENUPLOAD-2781) jt400-7.0-bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2781. -- Resolution: Fixed This form of bundle upload isn't supported anymore. See the documentation here for how you can self-serve and get the artifacts into central within a day: http://maven.apache.org/guides/mini/guide-central-repository-upload.html jt400-7.0-bundle Key: MAVENUPLOAD-2781 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2781 Project: Maven Upload Requests Issue Type: Wish Reporter: Jeff Lee Attachments: javadoc-7.0.zip, jt400-7.0-bundle.jar, jt400-7.0.jar The IBM Toolbox for Java (also known as JTOpen) is a library of Java classes supporting the client/server and internet programming models to a system running OS/400, i5/OS, or IBM i. The classes can be used by Java applets, servlets, and applications to easily access OS/400, i5/OS, and IBM i data and resources. -- 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: (MAVENUPLOAD-2780) I am DynamicJasper's project leader, please upload.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2780. -- Resolution: Won't Fix This form of bundle upload isn't supported anymore. See the documentation here for how you can self-serve and get the artifacts into central within a day: http://maven.apache.org/guides/mini/guide-central-repository-upload.html I am DynamicJasper's project leader, please upload. --- Key: MAVENUPLOAD-2780 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2780 Project: Maven Upload Requests Issue Type: Task Reporter: Juan Manuel Alvarez I am DynamicJasper's project leader, please upload. DynamicJasper (DJ) is an API that hides the complexity of Jasper Reports, it helps developers to save time when designing simple/medium complexity reports generating the layout of the report elements automatically. It creates reports dynamically, defining at runtime the columns, column width (auto width), groups, variables, fonts, charts, crosstabs, sub reports (that can also be dynamic), page size and everything else that you can define at design time. -- 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: (MAVENUPLOAD-2782) Please upload objectify-led 1.1.0 to Maven repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2782. -- Resolution: Won't Fix This form of bundle upload isn't supported anymore. See the documentation here for how you can self-serve and get the artifacts into central within a day: http://maven.apache.org/guides/mini/guide-central-repository-upload.html Please upload objectify-led 1.1.0 to Maven repository - Key: MAVENUPLOAD-2782 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2782 Project: Maven Upload Requests Issue Type: Wish Reporter: Steve Chaloner I'm a developer in objectify, and want to use the be.objectify groupId - you can find my details at http://www.objectify.be/objectify-led/team-list.html Thanks! - Steve -- 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: (MAVENUPLOAD-2785) Please add project JODRepors to the central repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2785. -- Resolution: Won't Fix This form of bundle upload isn't supported anymore. See the documentation here for how you can self-serve and get the artifacts into central within a day: http://maven.apache.org/guides/mini/guide-central-repository-upload.html Please add project JODRepors to the central repo -- Key: MAVENUPLOAD-2785 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2785 Project: Maven Upload Requests Issue Type: Wish Reporter: Terry Liang Document Page: http://jodreports.sourceforge.net/docs/ Team-list: http://jodreports.sourceforge.net/docs/team-list.html http://sourceforge.net/projects/jodreports/develop Pom: http://jodreports.svn.sourceforge.net/viewvc/jodreports/trunk/jodreports/pom.xml?view=markup http://sourceforge.net/projects/jodreports/files/JODReports%202.2/2.2.1/jodreports-2.2.1.pom/download Jar: http://sourceforge.net/projects/jodreports/files/JODReports%202.2/2.2.1/jodreports-2.2.1.jar/download I'm a developer and project admin in JODReports, please upload. -- 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: (MAVENUPLOAD-2786) ICOReader 1.04
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2786. -- Resolution: Won't Fix This form of bundle upload isn't supported anymore. See the documentation here for how you can self-serve and get the artifacts into central within a day: http://maven.apache.org/guides/mini/guide-central-repository-upload.html ICOReader 1.04 -- Key: MAVENUPLOAD-2786 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2786 Project: Maven Upload Requests Issue Type: Wish Reporter: fabrizio giustina -- 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: (MAVENUPLOAD-2784) com.browseengine.bobo:bobo-browse 2.0.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2784. -- Resolution: Fixed This form of bundle upload isn't supported anymore. See the documentation here for how you can self-serve and get the artifacts into central within a day: http://maven.apache.org/guides/mini/guide-central-repository-upload.html com.browseengine.bobo:bobo-browse 2.0.7 --- Key: MAVENUPLOAD-2784 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2784 Project: Maven Upload Requests Issue Type: Wish Reporter: fabrizio giustina bundle contains binary jar, sources and javadoc -- 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: (MAVENUPLOAD-2787) JdbcHelper 0.3.1 Upload Request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2787. -- Resolution: Won't Fix This form of bundle upload isn't supported anymore. See the documentation here for how you can self-serve and get the artifacts into central within a day: http://maven.apache.org/guides/mini/guide-central-repository-upload.html JdbcHelper 0.3.1 Upload Request --- Key: MAVENUPLOAD-2787 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2787 Project: Maven Upload Requests Issue Type: Wish Reporter: Erdinc YILMAZEL Attachments: jdbc-helper-0.3.1-bundle.jar Inspired by Spring Jdbctemplate and Commons Dbutils projects, JdbcHelper? is a very small library for helping the developers code common jdbc operations. JdbcHelper? is very lightweight. It is only ~70K and it has no external dependencies. -- 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: (MAVENUPLOAD-2792) Upload JSend NSCA
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2792. -- Resolution: Won't Fix This form of bundle upload isn't supported anymore. See the documentation here for how you can self-serve and get the artifacts into central within a day: http://maven.apache.org/guides/mini/guide-central-repository-upload.html Upload JSend NSCA - Key: MAVENUPLOAD-2792 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2792 Project: Maven Upload Requests Issue Type: Wish Reporter: Raj Patel http://jsendnsca.googlecode.com/files/jsendnsca-2.0.0-bundle.jar http://code.google.com/p/jsendnsca/ http://code.google.com/p/jsendnsca/people/list Can you please upload to the central repo, many thanks Raj -- 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: (MAVENUPLOAD-2796) The RSA host key for brap.tornado.no has changed, please accept the new one
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2796. -- Resolution: Won't Fix The rsync upload isn't supported anymore. See the documentation here for how you can get your project into a forge: http://maven.apache.org/guides/mini/guide-central-repository-upload.html The RSA host key for brap.tornado.no has changed, please accept the new one --- Key: MAVENUPLOAD-2796 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2796 Project: Maven Upload Requests Issue Type: Improvement Reporter: Edvin Syse brap.tornado.no was moved to a new machine, with a new RSA host key. Please accept this so sync can be restored. -- 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: (MAVENUPLOAD-2799) please upload maven-precheck-plugin to the maven repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2799. -- Resolution: Won't Fix This form of bundle upload isn't supported anymore. See the documentation here for how you can self-serve and get the artifacts into central within a day: http://maven.apache.org/guides/mini/guide-central-repository-upload.html please upload maven-precheck-plugin to the maven repository --- Key: MAVENUPLOAD-2799 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2799 Project: Maven Upload Requests Issue Type: Wish Reporter: Jaehyeon Nam Attachments: maven-precheck-plugin-1.0-bundle.jar http://maven-precheck-plugin.googlecode.com/files/maven-precheck-plugin-1.0-bundle.jar http://code.google.com/p/maven-precheck-plugin http://code.google.com/p/maven-precheck-plugin/people/list I'm a developer in maven-precheck-plugin, and want to use the org.openwebtop.maven.plugins groupId. I own openwebtop.org domain, you can see my email address(dotol...@gmail.com) in http://reports.internic.net/cgi/whois?whois_nic=openwebtop.orgtype=domain -- 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: (MAVENUPLOAD-2800) New version of XINS for Maven2 repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2800. -- Resolution: Won't Fix This form of bundle upload isn't supported anymore. See the documentation here for how you can self-serve and get the artifacts into central within a day: http://maven.apache.org/guides/mini/guide-central-repository-upload.html New version of XINS for Maven2 repository - Key: MAVENUPLOAD-2800 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2800 Project: Maven Upload Requests Issue Type: Task Reporter: Anthony Goubard Hi, Here are new JAR file that I'd like to have uploaded in Maven: http://www.xins.org/maven/xins-server-2.3.jar http://www.xins.org/maven/xins-common-2.3.jar http://www.xins.org/maven/xins-client-2.3.jar http://www.xins.org/maven/logdoc-2.3.jar Kind regards, Anthony Goubard -- 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: (MAVENUPLOAD-2797) Java library which allows you to serialize classes with non serializable fields, like input streams. It's very useful when you are using input streams or blobs with E
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2797. -- Resolution: Won't Fix This form of bundle upload isn't supported anymore. See the documentation here for how you can self-serve and get the artifacts into central within a day: http://maven.apache.org/guides/mini/guide-central-repository-upload.html Java library which allows you to serialize classes with non serializable fields, like input streams. It's very useful when you are using input streams or blobs with EJB Key: MAVENUPLOAD-2797 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2797 Project: Maven Upload Requests Issue Type: Wish Reporter: Yaroslav Klymko I'm a developer, please upload! -- 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: (MAVENUPLOAD-2801) TableT - simple collection, allowing multiple custom fast searchable indexes.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2801. -- Resolution: Won't Fix This form of bundle upload isn't supported anymore. See the documentation here for how you can self-serve and get the artifacts into central within a day: http://maven.apache.org/guides/mini/guide-central-repository-upload.html TableT - simple collection, allowing multiple custom fast searchable indexes. --- Key: MAVENUPLOAD-2801 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2801 Project: Maven Upload Requests Issue Type: Wish Reporter: Illarion Kovalchuk Attachments: tablej-0.1.0-SNAPSHOT-bundle.jar http://code.google.com/p/tablej/ Could you please upload this artifact? -- 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: (MAVENUPLOAD-2795) Please upload Nomin mapping engine
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2795. -- Resolution: Fixed Please upload Nomin mapping engine -- Key: MAVENUPLOAD-2795 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2795 Project: Maven Upload Requests Issue Type: Wish Reporter: Dmitry Dobrynin https://sourceforge.net/projects/nomin/files/nomin-1.0.0-bundle.jar/download http://nomin.sourceforge.net http://nomin.sourceforge.net/team-list.html I'm a developer in nomin, please upload -- 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: (MAVENUPLOAD-2802) MarkdownPapers artifacts upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2802. -- Resolution: Won't Fix This form of bundle upload isn't supported anymore. See the documentation here for how you can self-serve and get the artifacts into central within a day: http://maven.apache.org/guides/mini/guide-central-repository-upload.html MarkdownPapers artifacts upload --- Key: MAVENUPLOAD-2802 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2802 Project: Maven Upload Requests Issue Type: Wish Reporter: Larry Ruiz http://github.com/downloads/lruiz/MarkdownPapers/markdownpapers-core-0.3.0-bundle.jar http://github.com/downloads/lruiz/MarkdownPapers/markdownpapers-parent-0.3.0-bundle.jar http://github.com/lruiz/MarkdownPapers I am a developer in MarkdownPapers, please upload -- 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: (MAVENUPLOAD-2778) upload request for jaxb ri 2.1.13, jaxb-api 2.2.1 and jaxb ri 2.2.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2778. -- Resolution: Won't Fix This form of bundle upload isn't supported anymore. See the documentation here for how you can self-serve and get the artifacts into central within a day: http://maven.apache.org/guides/mini/guide-central-repository-upload.html upload request for jaxb ri 2.1.13, jaxb-api 2.2.1 and jaxb ri 2.2.1 --- Key: MAVENUPLOAD-2778 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2778 Project: Maven Upload Requests Issue Type: Wish Reporter: Pavel Bucek Hello, can you please upload following artifacts to maven central? https://jaxb.dev.java.net/2.1.13/bundles2mavenCentral-signed/jaxb-impl-2.1.13-bundle.jar https://jaxb.dev.java.net/2.1.13/bundles2mavenCentral-signed/jaxb1-impl-2.1.13-bundle.jar https://jaxb.dev.java.net/2.1.13/bundles2mavenCentral-signed/jaxb-xjc-2.1.13-bundle.jar https://jaxb.dev.java.net/2.2.1/bundles2mavenCentral-signed/jaxb-api-2.2.1-bundle.jar https://jaxb.dev.java.net/2.2.1/bundles2mavenCentral-signed/jaxb-api-osgi-2.2.1-bundle.jar https://jaxb.dev.java.net/2.2.1/bundles2mavenCentral-signed/jaxb-impl-2.2.1-bundle.jar https://jaxb.dev.java.net/2.2.1/bundles2mavenCentral-signed/jaxb1-impl-2.2.1-bundle.jar https://jaxb.dev.java.net/2.2.1/bundles2mavenCentral-signed/jaxb-xjc-2.2.1-bundle.jar https://jaxb.dev.java.net/2.2.1/bundles2mavenCentral-signed/jaxb-osgi-2.2.1-bundle.jar Thanks, Pavel -- 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: (MAVENUPLOAD-2789) OSGi 4.2.0 Enterprise API
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2789. -- Resolution: Won't Fix This form of bundle upload isn't supported anymore. See the documentation here for how you can self-serve and get the artifacts into central within a day: http://maven.apache.org/guides/mini/guide-central-repository-upload.html OSGi 4.2.0 Enterprise API - Key: MAVENUPLOAD-2789 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2789 Project: Maven Upload Requests Issue Type: Wish Reporter: Thomas Diesler Attachments: org.osgi.enterprise-4.2.0.jar, osgi.enterprise.jar This is the recently released OSGi 4.2.0 Enterprise API in bundle form. I have manually created sha1 checksums for all artifacts; the pom is maven-generated. -- 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: (MAVENUPLOAD-2805) jt400-7.1-bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2805. -- Resolution: Won't Fix This form of bundle upload isn't supported anymore. See the documentation here for how you can self-serve and get the artifacts into central within a day: http://maven.apache.org/guides/mini/guide-central-repository-upload.html jt400-7.1-bundle Key: MAVENUPLOAD-2805 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2805 Project: Maven Upload Requests Issue Type: Wish Reporter: Jeff Lee Attachments: jt400-7.1-bundle.jar, jt400-7.1-javadoc-bundle.jar, jt400-7.1-source-bundle.jar https://sourceforge.net/projects/jt400 http://jt400.sourceforge.net/ http://jt400.sourceforge.net/team.html The IBM Toolbox for Java is a library of Java classes supporting the client/server and internet programming models to a system running OS/400 or i5/OS. The classes can be used by Java applets, servlets, and applications to easily access OS/400 and i5/OS data and resources. -- 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: (MAVENUPLOAD-2773) Upload jTDS 1.2.5
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2773. -- Resolution: Won't Fix Upload jTDS 1.2.5 - Key: MAVENUPLOAD-2773 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2773 Project: Maven Upload Requests Issue Type: Wish Reporter: Holger Rehn Assignee: Juven Xu I'm a jTDS developer (at sourceforge I'm registered under the pseudonym ickzon). http://sourceforge.net/projects/jtds/ -- 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: (MAVENUPLOAD-2774) I am DynamicJasper's project leader, please upload.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2774. -- Resolution: Won't Fix I am DynamicJasper's project leader, please upload. --- Key: MAVENUPLOAD-2774 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2774 Project: Maven Upload Requests Issue Type: Task Reporter: Juan Manuel Alvarez Assignee: Juven Xu DynamicJasper (DJ) is an API that hides the complexity of Jasper Reports, it helps developers to save time when designing simple/medium complexity reports generating the layout of the report elements automatically. It creates reports dynamically, defining at runtime the columns, column width (auto width), groups, variables, fonts, charts, crosstabs, sub reports (that can also be dynamic), page size and everything else that you can define at design time. -- 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: (MAVENUPLOAD-2777) Version 2.3-jdk16 of UISpec4J
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2777. -- Resolution: Won't Fix This form of bundle upload isn't supported anymore. See the documentation here for how you can self-serve and get the artifacts into central within a day: http://maven.apache.org/guides/mini/guide-central-repository-upload.html Version 2.3-jdk16 of UISpec4J - Key: MAVENUPLOAD-2777 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2777 Project: Maven Upload Requests Issue Type: New Feature Reporter: Pascal Pratmarty UISpec4J is an Open Source functional and/or unit testing library for Swing-based Java applications, built on top of the JUnit and TestNG test harnesses. -- 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: (MAVENUPLOAD-2776) Version 2.3-jdk15 of UISpec4J
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2776. -- Resolution: Won't Fix This form of bundle upload isn't supported anymore. See the documentation here for how you can self-serve and get the artifacts into central within a day: http://maven.apache.org/guides/mini/guide-central-repository-upload.html Version 2.3-jdk15 of UISpec4J - Key: MAVENUPLOAD-2776 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2776 Project: Maven Upload Requests Issue Type: New Feature Reporter: Pascal Pratmarty UISpec4J is an Open Source functional and/or unit testing library for Swing-based Java applications, built on top of the JUnit and TestNG test harnesses. -- 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-4817) Unable to use gwt-maven-plugin 1.3-SNAPSHOT
[
http://jira.codehaus.org/browse/MNG-4817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=235621#action_235621
]
Brian Fox commented on MNG-4817:
use http://nexus.codehaus.org/snapshots as the repo and you'll avoid all the
redirects
Unable to use gwt-maven-plugin 1.3-SNAPSHOT
---
Key: MNG-4817
URL: http://jira.codehaus.org/browse/MNG-4817
Project: Maven 2 3
Issue Type: Bug
Components: POM
Affects Versions: 3.0
Environment: Ubuntu 10.10
Reporter: Jacek Furmankiewicz
Assignee: Benjamin Bentmann
Tried to create a project using the gwt-maven plugin. After generating the
archetype using the current 1.2 version I attempted to update it to
1.3-SNAPSHOT
{code:xml}
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdgwt-maven-plugin/artifactId
version1.3-SNAPSHOT/version
executions
execution
goals
goalcompile/goal
goalgenerateAsync/goal
goaltest/goal
/goals
/execution
/executions
configuration
runTargetcom.rp.portal.campaign.Application/Application.html/runTarget
/configuration
/plugin
{code}
Added the repo for the plugin:
{code:xml}
pluginRepositories
pluginRepository
idCodehaus/id
nameCodehaus Maven Plugin Repository/name
urlhttp://repository.codehaus.org/org/codehaus/mojo/url
snapshots
enabledtrue/enabled
/snapshots
/pluginRepository
/pluginRepositories
[code}
Got this repeatedly:
{code}
jac...@jacekf:~/src/tmp/portal-campaign$ mvn eclipse:eclipse
[INFO] Scanning for projects...
[WARNING] Failed to retrieve plugin descriptor for
org.codehaus.mojo:gwt-maven-plugin:1.3-SNAPSHOT: Failed to parse plugin
descriptor for org.codehaus.mojo:gwt-maven-plugin:1.3-SNAPSHOT
(/home/jacekf/.m2/repository/org/codehaus/mojo/gwt-maven-plugin/1.3-SNAPSHOT/gwt-maven-plugin-1.3-SNAPSHOT.jar):
error in opening zip file
[WARNING] Error reading plugin group metadata: end tag name /body must
match start tag name hr from line 7 (position: TEXT seen
.../address\n/body... @9:8)
Downloading:
http://repository.codehaus.org/org/codehaus/mojo/org/apache/maven/plugins/maven-eclipse-plugin/maven-metadata.xml
Downloaded:
http://repository.codehaus.org/org/codehaus/mojo/org/apache/maven/plugins/maven-eclipse-plugin/maven-metadata.xml
(437 B at 1.6 KB/sec)
[WARNING] Failed to read metadata
/home/jacekf/.m2/repository/org/apache/maven/plugins/maven-eclipse-plugin/maven-metadata-Codehaus.xml:
end tag name /body must match start tag name hr from line 7 (position:
TEXT seen .../address\n/body... @9:8)
{code}
--
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=235022#action_235022 ] Brian Fox commented on MDEP-275: Raymond: Any chance you can write some unit/it tests for this new code? Currently it has none, and if you look at the mdep plugin, it is currently very thoroughly tested. 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] Commented: (MDEP-259) copy-dependencies fails with Error copying artifact from .../target/classes to .../classes
[
http://jira.codehaus.org/browse/MDEP-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=235023#action_235023
]
Brian Fox commented on MDEP-259:
Andreas, can you provide some tests for your patch?
copy-dependencies fails with Error copying artifact from .../target/classes
to .../classes
Key: MDEP-259
URL: http://jira.codehaus.org/browse/MDEP-259
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: copy-dependencies
Affects Versions: 2.0, 2.1
Environment: Maven 2.0.9
maven-dependency-plugin 2.0, 2.1 or 2.2-SNAPSHOT (r922616)
Reporter: Andreas Veithen
Assignee: Brian Fox
Attachments: patch.txt, test-project.zip
Scenario:
* dependency:copy-dependencies is used to copy a dependency artifact that is
part of the same multi-module build.
* The compile phase is executed, but not the package phase.
An example of this scenario is using maven-eclipse-plugin to import a Maven
project with generated test (re)sources. In this case, one would execute mvn
generate-test-resources eclipse:eclipse to make sure that the generated
(re)sources are imported into the workspace (by default, maven-eclipse-plugin
executes generate-sources and generate-resources, but not
generate-test-sources and generate-test-resources).
Result: The build fails with the following error:
[INFO] [dependency:copy-dependencies {execution: default}]
[INFO] Copying classes to
/Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error copying artifact from
/Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes to
/Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
Embedded error:
/Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes (No
such file or directory)
Steps to reproduce:
* Unpack the attached test project and build the entire project once with
mvn install.
* Execute mvn generate-resources from the root project - success (because
the compile phase is not executed)
* Execute mvn package from the root project - success (because the package
phase is executed)
* Execute mvn generate-test-resources from the root project - fails
(because the compile phase is executed, but not the package phase)
* Execute mvn generate-test-resources in project2 - success (because the
dependency is not part of the same build)
Root cause analysis: In the scenario described above (compile phase executed,
package phase not executed), Artifact#getFile() points to the target/classes
directory instead of the output artifact. dependency:copy-dependencies
doesn't detect this situation and blindly attempts to execute the copy
operation. This fails with the error message shown above. Note that even if
the operation didn't fail, it would produce an unexpected result.
Proposed fix (see attached patch): Change maven-dependency-plugin to detect
this situation and let it replace the original Artifact object by a new one
resolved from the repository (which would then refer to the artifact
generated by a previous build, exactly as in the mvn generate-resources case).
--
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-124) Dependency incorrectly reported as Unused declared
[
http://jira.codehaus.org/browse/MDEP-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=235024#action_235024
]
Brian Fox commented on MDEP-124:
The analyzer walks all classes and collects the list of imports essentially and
then tries to mark dependencies when it finds an imported class in that
dependency. There is no processing of the annotations or constants in the
analyzer since it's looking purely at the bytecode. The best we can do here is
allow you to annotate the configuration with a list of artifacts that should be
ignored.
Dependency incorrectly reported as Unused declared
Key: MDEP-124
URL: http://jira.codehaus.org/browse/MDEP-124
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: analyze
Reporter: Olivier Dehon
Assignee: Brian Fox
When a dependency is only required for a constant in a JAR,
dependency:analyze incorrectly reports the dependency as Unused declared.
Example:
Constants.jar has 1 class called Constants.java:
{code}
package com.myco.util;
public class Constants
{
private Constants() {};
public static final double PI = 3.14159;
}
{code}
Then App jar has App.java as:
{code}
package com.myco.app;
public class App
{
public static void main( String[] args )
{
System.out.println( com.myco.util.Constants.PI );
}
}
{code}
Since the constant gets optimized away in the generated {{App.class}}, the
dependency is not detected, even though the project won't compile without it.
--
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: (MDEP-124) Dependency incorrectly reported as Unused declared
[
http://jira.codehaus.org/browse/MDEP-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MDEP-124:
---
Fix Version/s: 2.2
Dependency incorrectly reported as Unused declared
Key: MDEP-124
URL: http://jira.codehaus.org/browse/MDEP-124
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: analyze
Reporter: Olivier Dehon
Assignee: Brian Fox
Fix For: 2.2
When a dependency is only required for a constant in a JAR,
dependency:analyze incorrectly reports the dependency as Unused declared.
Example:
Constants.jar has 1 class called Constants.java:
{code}
package com.myco.util;
public class Constants
{
private Constants() {};
public static final double PI = 3.14159;
}
{code}
Then App jar has App.java as:
{code}
package com.myco.app;
public class App
{
public static void main( String[] args )
{
System.out.println( com.myco.util.Constants.PI );
}
}
{code}
Since the constant gets optimized away in the generated {{App.class}}, the
dependency is not detected, even though the project won't compile without it.
--
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: (MDEP-166) runtime-scoped dependencies should be specially handled
[ http://jira.codehaus.org/browse/MDEP-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MDEP-166: --- Fix Version/s: 2.2 runtime-scoped dependencies should be specially handled --- Key: MDEP-166 URL: http://jira.codehaus.org/browse/MDEP-166 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: analyze Affects Versions: 2.0 Reporter: Max Bowsher Assignee: Brian Fox Fix For: 2.2 Currently the plugin warns that runtime-scope dependencies are unused. It should understand that the correct status for a runtime-scoped dependency is to *not* be discoverable in the bytecode. -- 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: (MDEP-265) Add classifier option for dependency:get
[ http://jira.codehaus.org/browse/MDEP-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MDEP-265: --- Fix Version/s: 2.2 Add classifier option for dependency:get Key: MDEP-265 URL: http://jira.codehaus.org/browse/MDEP-265 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Andreas Kohn Assignee: Brian Fox Fix For: 2.2 Attachments: MDEP-265-include-artifact-string.diff, MDEP-265.diff The dependency:get mojo is really helpful, but it currently seems to be unable to get an artifact that uses a non-default classifier. Please add a classifier configuration option for the get mojo. -- 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: (MENFORCER-96) 'requirePluginVersions' recognizises some released maven-plugins as SNAPSHOTS
[
http://jira.codehaus.org/browse/MENFORCER-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MENFORCER-96.
--
Resolution: Not A Bug
The message says that the versions are not locked down, and adds additional
info that snapshots are not allowed (even if they are explicitly defined). IE
this rule is intended to check that you have defined your preferred versions
somewhere in your pom hierarchy and that you haven't just allowed the defaults
from the super pom to fall through.
'requirePluginVersions' recognizises some released maven-plugins as SNAPSHOTS
-
Key: MENFORCER-96
URL: http://jira.codehaus.org/browse/MENFORCER-96
Project: Maven 2.x Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 1.0-beta-1
Reporter: Lars Corneliussen
Have a look at this log. 2.4 can't be a snapshot, can it?
{noformat}
[INFO] [enforcer:enforce {execution: default-cli}]
[WARNING] Rule 2: org.apache.maven.plugins.enforcer.RequirePluginVersions
failed with message:
Some plugins are missing valid versions:(SNAPSHOT are not allowed )
org.apache.maven.plugins:maven-clean-plugin.The version currently in use
is 2.4
org.apache.maven.plugins:maven-deploy-plugin. The version currently in use
is 2.5
org.apache.maven.plugins:maven-install-plugin. The version currently in use
is 2.3
org.apache.maven.plugins:maven-site-plugin. The version currently in use
is 2.1
{noformat}
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-enforcer-plugin/artifactId
version1.0-beta-1/version
configuration
rules
requireReleaseVersion /
requireReleaseDeps
messageAll dependencies must be released!/message
failWhenParentIsSnapshottrue/failWhenParentIsSnapshot
/requireReleaseDeps
requirePluginVersions
banReleasefalse/banRelease
banLatestfalse/banLatest
banSnapshotstrue/banSnapshots
banTimestampsfalse/banTimestamps
!-- unCheckedPlugins
unCheckedPluginorg.apache.maven.plugins:maven-clean-plugin/unCheckedPlugin
unCheckedPluginorg.apache.maven.plugins:maven-deploy-plugin/unCheckedPlugin
unCheckedPluginorg.apache.maven.plugins:maven-install-plugin/unCheckedPlugin
unCheckedPluginorg.apache.maven.plugins:maven-site-plugin/unCheckedPlugin
/unCheckedPlugins --
/requirePluginVersions
/rules
failtrue/fail
/configuration
/plugin
{code}
When I list the plugins as unChecked, it passes.
--
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: (MDEP-259) copy-dependencies fails with Error copying artifact from .../target/classes to .../classes
[
http://jira.codehaus.org/browse/MDEP-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MDEP-259.
--
Resolution: Won't Fix
This is a problem with Maven Core, not the dependency plugin. It will only
happen if you are doing just mvn compile or maybe mvn test on the multimodule
build, because those modules haven't been packaged yet. When this happens, the
core hands the plugin a reference to the classes folder, but we expect a jar.
Instead of running mvn compile/test just always use mvn install and you'll be
fine. Alternatively, bind the dependency plugin to the package phase and it
won't run unless you do at least mvn package in which case all of the modules
will be jar'd already.
The _only_ workaround we could do in the plugin is to cause the dependency
plugin to detect that it has a folder and either:
1) ignore this dependency
2) go and attempt to create a jar from the classes
Neither of these is a correct fix because in 1, the resulting folder/archive
would be incomplete and 2 we have no way of reliably constructing the jar
exactly as it would be done in its own pom.
copy-dependencies fails with Error copying artifact from .../target/classes
to .../classes
Key: MDEP-259
URL: http://jira.codehaus.org/browse/MDEP-259
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: copy-dependencies
Affects Versions: 2.0, 2.1
Environment: Maven 2.0.9
maven-dependency-plugin 2.0, 2.1 or 2.2-SNAPSHOT (r922616)
Reporter: Andreas Veithen
Assignee: Brian Fox
Attachments: patch.txt, test-project.zip
Scenario:
* dependency:copy-dependencies is used to copy a dependency artifact that is
part of the same multi-module build.
* The compile phase is executed, but not the package phase.
An example of this scenario is using maven-eclipse-plugin to import a Maven
project with generated test (re)sources. In this case, one would execute mvn
generate-test-resources eclipse:eclipse to make sure that the generated
(re)sources are imported into the workspace (by default, maven-eclipse-plugin
executes generate-sources and generate-resources, but not
generate-test-sources and generate-test-resources).
Result: The build fails with the following error:
[INFO] [dependency:copy-dependencies {execution: default}]
[INFO] Copying classes to
/Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error copying artifact from
/Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes to
/Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
Embedded error:
/Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes (No
such file or directory)
Steps to reproduce:
* Unpack the attached test project and build the entire project once with
mvn install.
* Execute mvn generate-resources from the root project - success (because
the compile phase is not executed)
* Execute mvn package from the root project - success (because the package
phase is executed)
* Execute mvn generate-test-resources from the root project - fails
(because the compile phase is executed, but not the package phase)
* Execute mvn generate-test-resources in project2 - success (because the
dependency is not part of the same build)
Root cause analysis: In the scenario described above (compile phase executed,
package phase not executed), Artifact#getFile() points to the target/classes
directory instead of the output artifact. dependency:copy-dependencies
doesn't detect this situation and blindly attempts to execute the copy
operation. This fails with the error message shown above. Note that even if
the operation didn't fail, it would produce an unexpected result.
Proposed fix (see attached patch): Change maven-dependency-plugin to detect
this situation and let it replace the original Artifact object by a new one
resolved from the repository (which would then refer to the artifact
generated by a previous build, exactly as in the mvn generate-resources case).
--
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=231536#action_231536 ] Brian Fox commented on MDEP-275: Your timing couldn't have been better. We were just discussing the need for this the other day to help diagnose potential conflicts when switching from Maven 2.x to Maven 3.x. I'll take a look and get this merged in. 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] Commented: (MNG-4301) Invalid checksums on deploy when using webdav without extension
[ http://jira.codehaus.org/browse/MNG-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=229883#action_229883 ] Brian Fox commented on MNG-4301: See the trick is that maven is producing these junk checksums upon upload. Even if you fix it, until you repair the checksums in the repo, you will continue to get the checksum errors whenever someone downloads those artifacts. The workaround for this bug is to stop producing bad checksums, and then repair the ones that are broken. Stop producing bad checksums by: Not using Maven 2.2.0 or not using a wagon with httpclient against an authenticated repo unless you disable preemptive authentication. If you're using Nexus, it can repair the checksums simply by doing a Rebuild Maven Metadata on the subfolder of the repo where your busted checksums are. Invalid checksums on deploy when using webdav without extension --- Key: MNG-4301 URL: http://jira.codehaus.org/browse/MNG-4301 Project: Maven 2 3 Issue Type: Bug Components: Deployment Affects Versions: 2.2.1 Environment: n/a Reporter: Kevin Shekleton Priority: Blocker With maven 2.2.1, our deployments via webdav are producing invalid checksums, similar to the issue reported in MNG-4235. From maven 2.0.8 and previous, the following build extension was required to deploy via webdav: extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-webdav/artifactId version1.0-beta-2/version /extension /extensions Starting with maven 2.0.9 (see MNG-3418), webdav was included by default and the aforementioned build extension must be removed from the project. If it was included in the project the deployment would fail as Maven would report multiple versions of wagon-webdav present. With maven 2.2.0, our deployment suffered from invalid checksums reported in MNG-4235. With maven 2.2.1, we still see the invalid checksums on deployment as reported in MNG-4235. However, I've found that if you add the above build extension into the project, we don't experience this issue (of generating invalid checksums). Is this workaround an intentional change brought about by the fix of MNG-4235? -- 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-2553) Maven Local Settings Model should allow configuration of distributions (distributionManagement)
[
http://jira.codehaus.org/browse/MNG-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=225871#action_225871
]
Brian Fox commented on MNG-2553:
This is simply not how it was designed to work, and there is a perfectly valid
use case for this already, that's why it's marked won't fix. If you want to see
an example, take a look at the Maven and Apache parent poms:
http://svn.apache.org/repos/asf/maven/pom/trunk/
{code}
distributionManagement
!-- Site omitted - each project must provide their own --
repository
idapache.releases.https/id
nameApache Release Distribution Repository/name
urlhttps://repository.apache.org/service/local/staging/deploy/maven2/url
/repository
snapshotRepository
idapache.snapshots.https/id
name${distMgmtSnapshotsName}/name
url${distMgmtSnapshotsUrl}/url
/snapshotRepository
/distributionManagement
properties
distMgmtSnapshotsNameApache Development Snapshot
Repository/distMgmtSnapshotsName
distMgmtSnapshotsUrlhttps://repository.apache.org/content/repositories/snapshots/distMgmtSnapshotsUrl
/properties
{code}
Here we use a property in the distributionManagement section, and define a
default value for the property in the same pom so that it's always complete.
However for CI systems, we define a new value for the property in the settings
that that overrides the pom. We have done this intentionally only for snapshots
in our case as we don't want people to accidentally release somewhere else.
This is what you want to do and it can already be done in the current design.
Maven Local Settings Model should allow configuration of distributions
(distributionManagement)
---
Key: MNG-2553
URL: http://jira.codehaus.org/browse/MNG-2553
Project: Maven 2 3
Issue Type: Improvement
Components: Settings
Affects Versions: 2.0.4
Reporter: Jimisola Laursen
There is a good use case where this would be very useful.
E.g. I develop a plugin in mojo-sandbox and want to test it in an environment
other than the one that I developed it on (e.g. a computer at work). I check
out the plugin to this, build and then want to deploy to another repository
(e..g a company's internal repository). I don't want to fiddle with the
pom.xml of the plugin, just refer to a profile in settings.xml.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-106) Unpacking primary artifact from sibling module uses repository rather than reactor
[
http://jira.codehaus.org/browse/MDEP-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=223853#action_223853
]
Brian Fox commented on MDEP-106:
It conceivably could be fixed in the plugin to check the reactor, but I'm
unlikely to do it since M3 solves this for us. If someone wants to attach a
patch then I'll take a look
Unpacking primary artifact from sibling module uses repository rather than
reactor
--
Key: MDEP-106
URL: http://jira.codehaus.org/browse/MDEP-106
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack
Affects Versions: 2.0-alpha-4
Reporter: Matt Ryall
Assignee: Brian Fox
Running dependency:unpack referencing a project in the reactor has the
following output which shows it is scanning for repository artifacts rather
than the artifact in the reactor:
{quote}
[INFO] [dependency:unpack \{execution: unpack-tests}]
[INFO] Configured Artifact:
com.example.app:app-acceptance-test:2.6-SNAPSHOT:jar
[INFO] snapshot com.example.app:app-acceptance-test:2.6-SNAPSHOT: checking
for updates from snapshots
[INFO] snapshot com.example.app:app-acceptance-test:2.6-SNAPSHOT: checking
for updates from m1-repo
Downloading:
http://m2proxy:8081/artifactory/repo/com/example/app/app-acceptance-test/2.6-SNAPSHOT/app-acceptance-test-2.6-20070829.025709-409.jar
9125K downloaded
[INFO] Expanding:
/Users/mryall/.m2/repository/com/example/app/app-acceptance-test/2.6-SNAPSHOT/app-acceptance-test-2.6-SNAPSHOT.jar
into /Users/mryall/src/example/app/app-webapp/target/it-classes
{quote}
To explain the scenario: to build reusable acceptance tests, I have the
following sub-modules of my project:
- app-core (jar)
- app-acceptance-tests (jar)
- app-webapp (war)
The acceptance tests are packaged this way for further use in testing, and
also run against the webapp in the integration-test phase. This is where the
problem arises.
Running 'mvn clean integration-test' does the following relevant tasks:
- in the app-acceptance-test module, compiles and packages a JAR of tests
- in the app-webapp module, uses the dependency:unpack goal to extract the
tests into target/it-classes in the pre-integration-test phase, and test:test
to run them in the integration test phase.
I don't think this is caused by the snapshot version, because the release
plugin also fails because it is unable to find the 2.6 version when it runs
'mvn clean verify'. There, it scans all the repositories for the acceptance
test artifact before failing with the usual error:
{quote}
[INFO] Failed to resolve artifact.
GroupId: com.example.app
ArtifactId: app-acceptance-test
Version: 2.6
Reason: Unable to download the artifact from any repository
{quote}
Maven details:
{noformat}
$ mvn -version
Maven version: 2.0.7
Java version: 1.4.2_12
OS name: mac os x version: 10.4.10 arch: i386
{noformat}
--
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: (MDEP-264) Dependency is copied from original source directory instead of .m2 using maven 3
[ http://jira.codehaus.org/browse/MDEP-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-264. -- Resolution: Fixed Fix Version/s: 2.2 The file name is always reconstructed now. The potential downside to this is that timestamped snapshot versions won't be copied anymore, it will use SNAPSHOT instead of the timestamp. Dependency is copied from original source directory instead of .m2 using maven 3 Key: MDEP-264 URL: http://jira.codehaus.org/browse/MDEP-264 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: copy Affects Versions: 2.1 Environment: SUSE 9 Linux, OpenJDK 1.6.0 build 11.0-b17, Maven 3.0-beta-1 Reporter: Jake Zuidema Fix For: 2.2 Attachments: mavenDepsCopyExample.tar Using Maven 2.2.1, the maven-dependency-plugin copy goal always copied the artifacts from the local .m2, which meant that they kept their full name (ex: ccad-moda-1.0.0-SNAPSHOT-system-help.pdf). Using Maven 3.0-beta-1, this is no longer always the case. If I build just the assembly sub-module, then it copies the artifact from the local .m2 and maintains the name. If I build the whole project, which includes building the module that produces the artifact being copied, then Maven 3 skips going to the local .m2 and instead goes back to the original source of the artifact and copies it from there. This results in a copied file with the short name (ex: system-help.pdf). Here are some lines from the build logs to show the difference. Maven 2.2.1 === [INFO] Configured Artifact: com.ccadllc.test1:ccad-moda:system-help:1.0.0-SNAPSHOT:pdf [DEBUG] Skipping disabled repository central [DEBUG] ccad-moda: using locally installed snapshot [INFO] Copying /home/jzuidema/.m2/repository/com/ccadllc/test1/ccad-moda/1.0.0-SNAPSHOT/ccad-moda-1.0.0-SNAPSHOT-system-help.pdf to /extra1/export/home/jzuidema/tmp2/test1/assembly/target/pdfs/ccad-moda-1.0.0-SNAPSHOT-system-help.pdf Maven 3.0-beta-1 [INFO] Configured Artifact: com.ccadllc.test1:ccad-moda:system-help:1.0.0-SNAPSHOT:pdf [INFO] Copying /extra1/export/home/jzuidema/tmp2/test1/moda/system-help.pdf to /extra1/export/home/jzuidema/tmp2/test1/assembly/target/pdfs/system-help.pdf Attached is an example project with the build logs from a maven 2.2.1 and a 3.0-beta-1 run of mvn -X clean install at the top level of the project. -- 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: (MDEP-257) includeClassifiers / seems to have no effect
[
http://jira.codehaus.org/browse/MDEP-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MDEP-257.
--
Resolution: Duplicate
MDEP-193
includeClassifiers / seems to have no effect
--
Key: MDEP-257
URL: http://jira.codehaus.org/browse/MDEP-257
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack-dependencies
Affects Versions: 2.1
Environment: Windows XP
Reporter: Patrick Aikens
Assignee: Brian Fox
I'm trying to package some installer-related files from a project for use in
a different izpack installer project. I want to unpack them into the
target/staging directory for inclusion in the izpack installer. All of the
dependencies I want to unpack have a classifier of izpack. Using the
following configuration, the dependency plugin unpacks ALL dependencies, not
just the ones with an izpack classifier.
{code:xml}
plugin
artifactIdmaven-dependency-plugin/artifactId
version2.1/version
executions
execution
idizpack/id
phasegenerate-resources/phase
goals
goalunpack-dependencies/goal
/goals
configuration
outputDirectory${project.build.directory}/staging/outputDirectory
includeClassifiersizpack/includeClassifiers
/configuration
/execution
/executions
/plugin
{code}
--
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-213) resolve dependencyManagement section with option to fail the build
[
http://jira.codehaus.org/browse/MDEP-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=222925#action_222925
]
Brian Fox commented on MDEP-213:
So you want to resolve everything in depMgt to make sure the versions exist?
resolve dependencyManagement section with option to fail the build
--
Key: MDEP-213
URL: http://jira.codehaus.org/browse/MDEP-213
Project: Maven 2.x Dependency Plugin
Issue Type: New Feature
Components: resolve
Affects Versions: 2.0
Reporter: Jim Sellers
Assignee: Brian Fox
When using the dependencyManagement section of a pom of type pom to create
a bill of materials, it's currently possible to specify an invalid version.
eg:
{code:xml}
dependencyManagement
dependencies
dependency
groupIdcommons-logging/groupId
artifactIdcommons-logging/artifactId
version9.9/version
/dependency
/dependencies
/dependencyManagement
{code}
It would be really useful for these types of pom's to be able to force all
the dependencies to be resolved when running something like install and
have that fail the build.
--
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: (MDEP-208) finalName of artifacts not in the reactor is not taken into account.
[ http://jira.codehaus.org/browse/MDEP-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-208. -- Resolution: Fixed Fix Version/s: 2.2 fixed by MDEP-264 finalName of artifacts not in the reactor is not taken into account. Key: MDEP-208 URL: http://jira.codehaus.org/browse/MDEP-208 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: copy-dependencies, unpack-dependencies Affects Versions: 2.0 Reporter: Maarten Billemont Assignee: Brian Fox Fix For: 2.2 Setting: A project where module B has a dependency on module A. Module B uses copy-dependencies to copy that dependency into a certain directory. What works: When both module A and B are in the maven reactor, module A's finalName is taken into account and the artifact that ends up copied into our directory uses the filename as given by finalName. What doesn't work: When only module B is in the maven reactor, module A is copied from the local repository where it has a different filename. Maven-dependency-plugin does not correct the filename during copy and as a result we have an artifact in our destination directory with a different name. This behavior is inconsistent and a solution should be established. I propose maven-dependency-plugin reads the dependency (A)'s POM and checks whether it has a finalName set. If so, it should modify the destination filename of the dependency copy operation accordingly. -- 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: (MDEP-240) ignoreNonCompile not available for analyze-report
[ http://jira.codehaus.org/browse/MDEP-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-240. -- Resolution: Fixed Fix Version/s: 2.2 ignoreNonCompile not available for analyze-report - Key: MDEP-240 URL: http://jira.codehaus.org/browse/MDEP-240 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: analyze Affects Versions: 2.1 Reporter: Pablo Assignee: Brian Fox Fix For: 2.2 I'd like to use the property ignoreNonCompile=true for my site report, but the goal analyze-report doesn't have this property. The doc is pretty clear about it, but I don't see any reason of not having this option for reports too. http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoreNonCompile http://maven.apache.org/plugins/maven-dependency-plugin/analyze-report-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] Moved: (MNG-4690) Transitive dependency lost when included another dependency
[ http://jira.codehaus.org/browse/MNG-4690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox moved MDEP-202 to MNG-4690: - Complexity: Intermediate Component/s: (was: resolve) Dependencies Affects Version/s: (was: 2.1) Key: MNG-4690 (was: MDEP-202) Project: Maven 2 3 (was: Maven 2.x Dependency Plugin) Transitive dependency lost when included another dependency --- Key: MNG-4690 URL: http://jira.codehaus.org/browse/MNG-4690 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Environment: maven 2.0.10 (tried with dependency plugin 2.0 and 2.1) Reporter: Michal Ropka Assignee: Brian Fox Attachments: test.zip *We added a new dependency (_velocity-tools_) and the project didn't work any more. We've found that one transitive library (_antlr_ used by _struts_ and _hibernate_) is missing in the installed WAR file.* It looks like the _antlr_ transitive dependency is ignored from _hibernate_ dependencies by plugin choosing _struts-1.2.9_ one while eventually _struts_ is replaced by _1.2.7_ version which does not have _antlr_ dependency. There is a workaround to the problem - dependencies might be rearranged to include the missing library back (e.g. by moving _struts-1.2.7_ from _parent_ to _ui_ but only before _velocity-tools_ - see the test case) however the problem is that the plugin behavior is unpredictable. *Test case:* There are root, parent, common, model, ui POM files. The purpose is to create dependency tree deep enough (_ui_ depends on _model_ and inherits from _parent_, _model_ depends on _common_). They include external dependencies (_velocity-tools_, _struts_, _hibernate_). * WAR artifact created from the root or _ui_ POM does not contain _antlr_ in WEB-INF/lib which is required by _hibernate_ * after removing _velocity-tools_ from ui/pom.xml _antlr_ library is included properly -- 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: (MDEP-263) filtering by classifier don't work
[
http://jira.codehaus.org/browse/MDEP-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MDEP-263.
--
Resolution: Fixed
Fix Version/s: 2.2
fixed by MDEP-194
filtering by classifier don't work
--
Key: MDEP-263
URL: http://jira.codehaus.org/browse/MDEP-263
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: copy, copy-dependencies
Affects Versions: 2.1
Environment: windows jdk1.6.0, maven 2.0.9
Reporter: Robert Lieb
Assignee: Brian Fox
Fix For: 2.2
Following plugin configuration ist used
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idcopy/id
phasepackage/phase
goals
goalcopy-dependencies/goal
/goals
configuration
outputDirectory${project.build.directory}/dependency/WEB-INF/lib/outputDirectory
excludeClassifiersweb/excludeClassifiers
/configuration
/execution
execution
idunpack/id
phasepackage/phase
goals
goalunpack-dependencies/goal
/goals
configuration
includeClassifiersweb/includeClassifiers
/configuration
/execution
/executions
/plugin
but in both executions all dependencies are copied, regardless of there
classifiers
--
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: (MDEP-182) Add exclude*, parameters to copy mojo (analogous to copy-dependencies mojo)
[
http://jira.codehaus.org/browse/MDEP-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MDEP-182.
--
Resolution: Won't Fix
Use the -dependencies goals for transitive resolution. The copy/unpack goals
are meant exactly to pick up just one file.
Add exclude*, parameters to copy mojo (analogous to copy-dependencies mojo)
Key: MDEP-182
URL: http://jira.codehaus.org/browse/MDEP-182
Project: Maven 2.x Dependency Plugin
Issue Type: New Feature
Components: copy
Affects Versions: 2.1
Reporter: Thorsten Möller
Assignee: Brian Fox
Today I came around a use case that I miss in the copy goal/mojo of the
dependency plugin. Currently, it is not possible (at least I could not find
any documentation) to resolve transitive dependencies when copying an
artifact nor to specify whether transitive dependencies should be included or
excluded. This should be extended analogous to the copy-dependencies mojo.
Example: Say we want to copy Retrotranslator including its dependencies.
Currently we would have to use the following declarations
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idcopy/id
phasepackage/phase
goals
goalcopy/goal
/goals
configuration
artifactItems
artifactItem
groupIdnet.sf.retrotranslator/groupId
artifactIdretrotranslator-runtime/artifactId
version${retrotranslator-version}/version
typejar/type
outputDirectory${project.build.directory}/outputDirectory
/artifactItem
!-- Transitive dependency of
Retrotranslator. Unfortunately, not automatically included. --
artifactItem
groupIdbackport-util-concurrent/groupId
artifactIdbackport-util-concurrent/artifactId
version3.1/version
typejar/type
outputDirectory${project.build.directory}/outputDirectory
/artifactItem
/artifactItems
/configuration
/execution
/executions
/plugin
This has the downside that all dependencies must be explicitly listed and
artifact versions must be kept consistent, which is unwished maintenance
work. More convenient would be a declaration as follows
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idcopy/id
phasepackage/phase
goals
goalcopy/goal
/goals
configuration
artifactItems
artifactItem
groupIdnet.sf.retrotranslator/groupId
artifactIdretrotranslator-runtime/artifactId
version${retrotranslator-version}/version
typejar/type
outputDirectory${project.build.directory}/outputDirectory
!-- Force to include *all*
transitive dependencies. They should be copied to the same output directory.
--
excludeTransitivefalse/excludeTransitive
/artifactItem
/artifactItems
/configuration
/execution
/executions
/plugin
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-260) fileSeparator\/fileSeparator causes an exception
[ http://jira.codehaus.org/browse/MDEP-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-260. -- Resolution: Fixed Fix Version/s: 2.2 patch applied, thanks. fileSeparator\/fileSeparator causes an exception Key: MDEP-260 URL: http://jira.codehaus.org/browse/MDEP-260 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: build-classpath Affects Versions: 2.1 Reporter: Sergei Ivanov Assignee: Brian Fox Fix For: 2.2 Attachments: file_separator.patch If I specify the following property in the plugin configuration: fileSeparator\/fileSeparator then the plugin crashes with an exception because a regex parser fails internally. It appears that the property needs to be escaped like this: fileSeparator\\/fileSeparator The plugin should take care of escaping the property itself. -- 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: (MDEP-250) Add a skip paramater to dependency:unpack
[ http://jira.codehaus.org/browse/MDEP-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-250. -- Resolution: Fixed Fix Version/s: 2.2 Add a skip paramater to dependency:unpack - Key: MDEP-250 URL: http://jira.codehaus.org/browse/MDEP-250 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: unpack Affects Versions: 2.1 Environment: Windows XP Reporter: Jim McCaskey Assignee: Brian Fox Fix For: 2.2 Attachments: MDEP-250-patch.txt We would like to have a skip paramater for dependency:unpack. This would cause the unpack to be skipped if true. We are currently working around the lack of this with profiles. The jetspeed plugin has a skip option that we have found some uses for, but jetspeed is not as robust as the dependency plugin (specifically with multi-module builds). We would prefer to use the core modules anyway. Here is a link to the jetspeed configuration page: http://portals.apache.org/jetspeed-2/maven/jetspeed-maven-plugins.html#Configuration_and_usage_of_the_jetspeed-unpack:unpack_Maven_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] Moved: (MNG-4691) Partially resolved artifacts in local repo trip up go-offline
[
http://jira.codehaus.org/browse/MNG-4691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox moved MDEP-247 to MNG-4691:
-
Complexity: Intermediate
Component/s: (was: resolve-plugins)
(was: go-offline)
(was: resolve)
(was: copy-dependencies)
Dependencies
Affects Version/s: (was: 2.1)
Key: MNG-4691 (was: MDEP-247)
Project: Maven 2 3 (was: Maven 2.x Dependency Plugin)
Partially resolved artifacts in local repo trip up go-offline
-
Key: MNG-4691
URL: http://jira.codehaus.org/browse/MNG-4691
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Environment: Mac/Linux
Reporter: Lee Thompson
Assignee: Brian Fox
Sometime ins my local repo, I get an artifact POM downloaded, but not the
JAR. This happens frequently enough that when I do go offline, my
development work comes to a halt.
The latest partial in my local repo is this...
{code:title=RepoListing|borderStyle=solid}
$ ls ~/.m2/repository/org/codehaus/plexus/plexus-utils/1.4.1
plexus-utils-1.4.1.pom plexus-utils-1.4.1.pom.sha1
{code}
Notice the plexus-utils jar file is not in the repo. The issue is go-offline
should detect that the packaged artifact is missing and resolve it, not just
the 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
