[jira] Commented: (SCM-368) Windows path length limitations can be overcome by feeding an absolute path to SVN
[ http://jira.codehaus.org/browse/SCM-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=130971#action_130971 ] Dominique Jean-Prost commented on SCM-368: -- Well I'm meeting this problem too. Let me fix the link provided by Kurt. The correct link is http://subversion.tigris.org/faq.html#long-paths. I think this problem is quite annoying and should be quite easy to fix. Can it be added to the must-fix ? > Windows path length limitations can be overcome by feeding an absolute path > to SVN > -- > > Key: SCM-368 > URL: http://jira.codehaus.org/browse/SCM-368 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api >Affects Versions: 1.0 > Environment: Any Windows machine >Reporter: Kurt Tometich >Priority: Minor > Fix For: 1.1 > > > When calling Subversion with relative paths there is a limit of 255 > characters to the path length. If you call Subversion with an absolute path > that no longer applies and you now have access to 32K chars. I have tried > this myself and it does work. Try feeding SVN a path that is relative and is > over 255 chars. It will not be able to complete the transaction. Now, try > to the same path again only as an absolute path and it will successfully > complete the transaction. Here is a link to the forum where I found this > information: http://en-us.www.mozilla.com/en-US/firefox/2.0.0.4/firstrun/. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-371) problem with long path on windows OS
problem with long path on windows OS Key: SCM-371 URL: http://jira.codehaus.org/browse/SCM-371 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-svn Affects Versions: 1.0 Environment: Windows OS Reporter: Dominique Jean-Prost This bug is raised so that a previously entered bug (SCM-368) is set in the correct component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-372) problem with long path on windows OS
problem with long path on windows OS Key: SCM-372 URL: http://jira.codehaus.org/browse/SCM-372 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-svn Affects Versions: 1.0 Reporter: Dominique Jean-Prost This bug is raised so that a previously entered bug (SCM-368) is set in the correct component. -- 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: (SCM-372) problem with long path on windows OS
[ http://jira.codehaus.org/browse/SCM-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Jean-Prost closed SCM-372. Resolution: Duplicate duplicate of SCM-371 > problem with long path on windows OS > > > Key: SCM-372 > URL: http://jira.codehaus.org/browse/SCM-372 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Affects Versions: 1.0 >Reporter: Dominique Jean-Prost > > This bug is raised so that a previously entered bug (SCM-368) is set in the > correct component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCOMPILER-71) javac compilation error for package-info.java containing package annotation
javac compilation error for package-info.java containing package annotation --- Key: MCOMPILER-71 URL: http://jira.codehaus.org/browse/MCOMPILER-71 Project: Maven 2.x Compiler Plugin Issue Type: Bug Affects Versions: 2.0.2 Environment: Windows XP SP2 JDK 1.5.0_15 Reporter: Gabriel Forro Attachments: compile_error_2.0.2.log The package-info.java files can not be compiled in Maven 2 if the 2.0.2 maven-compiler-plugin is used. package-info.java files can be compiled by earlier versions of the maven-compiler-plugin (I have tried 2.0 and 2.0.1). Newer snapshot versions does not work also and it fails in the same error (I have tried version 2.1-snapshot). This problem can be caused by an unusual behavior of the javac from jdk 1.5. This behavior is as follows: You can not use '/' file separator during compiling package-info.java (for instance "javac sk/forro/package-info.java"). You must use '\' separator (for instance "javac sk\forro\package-info.java"). If you use the '/' separator you get the the compilation error reported by this bug (package annotations should be in file package-info.java). This is javac 'feature' has been removed in jdk 6 and in jdk 6 you can use either '/' or '\' - it does not matter. It looks like the maven-compiler-plugin or one of its components (I mean plexus-x artefacts used by maven-compiler-plugin) uses '/' instead of the '\' in the MS Windows environment. I have attached a log file of an unsuccessful build (generated by mvn install -X) A possible workaround to solve this problem temporarily: The compilation successes if I use either an older version of maven-compiler-plugin or jdk 6 or do not use package-info.java files at all. -- 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: (MCHECKSTYLE-90) Checkstyle-2.2-SNAPSHOT not working with Maven 2.0.9
[ http://jira.codehaus.org/browse/MCHECKSTYLE-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=130983#action_130983 ] Ricky Hazelwood commented on MCHECKSTYLE-90: Dennis, ignore the above comment. My environment was completely screwed up. I have created a simple project which reproduces the above error. It only occurs with multi module projects. See attachment. > Checkstyle-2.2-SNAPSHOT not working with Maven 2.0.9 > > > Key: MCHECKSTYLE-90 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-90 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ricky Hazelwood > Attachments: checkstyle-bug.zip > > > The changes in Maven 2.0.9 is causing the plugin to use commons-collection > 2.0 instead of 2.1 required by checkstyle. Forcing the commons-collection > version 2.1 in the plugin config fixes this issue. > [INFO] [checkstyle:checkstyle] > [FATAL ERROR] org.apache.maven.plugin.checkstyle.CheckstyleReport#execute() > caused a linkage error (java.lang.NoClassDefFoundError) and may be > out-of-date. Check the realms: > [FATAL ERROR] Plugin realm = > app0.child-container[org.apache.maven.plugins:maven-checkstyle-plugin] > urls[0] = > file:/D:/maven2/repository/org/apache/maven/plugins/maven-checkstyle-plugin/2.2-SNAPSHOT/maven-checkstyle-plugin-2.2-SNAPSHOT.jar > urls[1] = > file:/D:/maven2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar > urls[2] = > file:/D:/maven2/repository/org/apache/maven/reporting/maven-reporting-impl/2.0/maven-reporting-impl-2.0.jar > urls[3] = > file:/D:/maven2/repository/commons-validator/commons-validator/1.1.4/commons-validator-1.1.4.jar > urls[4] = file:/D:/maven2/repository/oro/oro/2.0.7/oro-2.0.7.jar > urls[5] = > file:/D:/maven2/repository/doxia/doxia-core/1.0-alpha-4/doxia-core-1.0-alpha-4.jar > urls[6] = > file:/D:/maven2/repository/org/codehaus/plexus/plexus-resources/1.0-alpha-4/plexus-resources-1.0-alpha-4.jar > urls[7] = > file:/D:/maven2/repository/org/codehaus/plexus/plexus-velocity/1.1.2/plexus-velocity-1.1.2.jar > urls[8] = > file:/D:/maven2/repository/commons-collections/commons-collections/2.0/commons-collections-2.0.jar > urls[9] = > file:/D:/maven2/repository/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar > urls[10] = file:/D:/maven2/repository/velocity/velocity/1.4/velocity-1.4.jar > urls[11] = > file:/D:/maven2/repository/velocity/velocity-dep/1.4/velocity-dep-1.4.jar > urls[12] = > file:/D:/maven2/repository/checkstyle/checkstyle/4.4/checkstyle-4.4.jar > urls[13] = file:/D:/maven2/repository/antlr/antlr/2.7.6/antlr-2.7.6.jar > urls[14] = > file:/D:/maven2/repository/commons-beanutils/commons-beanutils-core/1.7.0/commons-beanutils-core-1.7.0.jar > urls[15] = > file:/D:/maven2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar > urls[16] = > file:/D:/maven2/repository/checkstyle/checkstyle-optional/4.4/checkstyle-optional-4.4.jar > [FATAL ERROR] Container realm = plexus.core > urls[0] = file:/C:/Program Files/Java/maven/lib/maven-2.0.9-uber.jar > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] org/apache/commons/collections/ReferenceMap > org.apache.commons.collections.ReferenceMap > [INFO] > > [INFO] Trace > java.lang.NoClassDefFoundError: org/apache/commons/collections/ReferenceMap > at > com.puppycrawl.tools.checkstyle.checks.duplicates.StrictDuplicateCodeCheck.(StrictDuplicateCodeCheck.java:191) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at java.lang.Class.newInstance0(Class.java:355) > at java.lang.Class.newInstance(Class.java:308) > at > com.puppycrawl.tools.checkstyle.PackageObjectFactory.createObject(PackageObjectFactory.java:110) > at > com.puppycrawl.tools.checkstyle.PackageObjectFactory.doMakeObject(PackageObjectFactory.java:87) > at > com.puppycrawl.tools.checkstyle.PackageObjectFactory.createModule(PackageObjectFactory.java:149) > at com.puppycrawl.tools.checkstyle.Checker.setupChild(Checker.java:140) > at > com.puppycrawl.tools.checkstyle.api.AutomaticBean.configure(AutomaticBean.java:208) > at > org.apache.maven.plugin.checkstyle.CheckstyleReport.executeCheckstyle(CheckstyleReport.java:870) >
[jira] Updated: (MCHECKSTYLE-90) Checkstyle-2.2-SNAPSHOT not working with Maven 2.0.9
[ http://jira.codehaus.org/browse/MCHECKSTYLE-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ricky Hazelwood updated MCHECKSTYLE-90: --- Attachment: checkstyle-bug.zip > Checkstyle-2.2-SNAPSHOT not working with Maven 2.0.9 > > > Key: MCHECKSTYLE-90 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-90 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ricky Hazelwood > Attachments: checkstyle-bug.zip > > > The changes in Maven 2.0.9 is causing the plugin to use commons-collection > 2.0 instead of 2.1 required by checkstyle. Forcing the commons-collection > version 2.1 in the plugin config fixes this issue. > [INFO] [checkstyle:checkstyle] > [FATAL ERROR] org.apache.maven.plugin.checkstyle.CheckstyleReport#execute() > caused a linkage error (java.lang.NoClassDefFoundError) and may be > out-of-date. Check the realms: > [FATAL ERROR] Plugin realm = > app0.child-container[org.apache.maven.plugins:maven-checkstyle-plugin] > urls[0] = > file:/D:/maven2/repository/org/apache/maven/plugins/maven-checkstyle-plugin/2.2-SNAPSHOT/maven-checkstyle-plugin-2.2-SNAPSHOT.jar > urls[1] = > file:/D:/maven2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar > urls[2] = > file:/D:/maven2/repository/org/apache/maven/reporting/maven-reporting-impl/2.0/maven-reporting-impl-2.0.jar > urls[3] = > file:/D:/maven2/repository/commons-validator/commons-validator/1.1.4/commons-validator-1.1.4.jar > urls[4] = file:/D:/maven2/repository/oro/oro/2.0.7/oro-2.0.7.jar > urls[5] = > file:/D:/maven2/repository/doxia/doxia-core/1.0-alpha-4/doxia-core-1.0-alpha-4.jar > urls[6] = > file:/D:/maven2/repository/org/codehaus/plexus/plexus-resources/1.0-alpha-4/plexus-resources-1.0-alpha-4.jar > urls[7] = > file:/D:/maven2/repository/org/codehaus/plexus/plexus-velocity/1.1.2/plexus-velocity-1.1.2.jar > urls[8] = > file:/D:/maven2/repository/commons-collections/commons-collections/2.0/commons-collections-2.0.jar > urls[9] = > file:/D:/maven2/repository/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar > urls[10] = file:/D:/maven2/repository/velocity/velocity/1.4/velocity-1.4.jar > urls[11] = > file:/D:/maven2/repository/velocity/velocity-dep/1.4/velocity-dep-1.4.jar > urls[12] = > file:/D:/maven2/repository/checkstyle/checkstyle/4.4/checkstyle-4.4.jar > urls[13] = file:/D:/maven2/repository/antlr/antlr/2.7.6/antlr-2.7.6.jar > urls[14] = > file:/D:/maven2/repository/commons-beanutils/commons-beanutils-core/1.7.0/commons-beanutils-core-1.7.0.jar > urls[15] = > file:/D:/maven2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar > urls[16] = > file:/D:/maven2/repository/checkstyle/checkstyle-optional/4.4/checkstyle-optional-4.4.jar > [FATAL ERROR] Container realm = plexus.core > urls[0] = file:/C:/Program Files/Java/maven/lib/maven-2.0.9-uber.jar > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] org/apache/commons/collections/ReferenceMap > org.apache.commons.collections.ReferenceMap > [INFO] > > [INFO] Trace > java.lang.NoClassDefFoundError: org/apache/commons/collections/ReferenceMap > at > com.puppycrawl.tools.checkstyle.checks.duplicates.StrictDuplicateCodeCheck.(StrictDuplicateCodeCheck.java:191) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at java.lang.Class.newInstance0(Class.java:355) > at java.lang.Class.newInstance(Class.java:308) > at > com.puppycrawl.tools.checkstyle.PackageObjectFactory.createObject(PackageObjectFactory.java:110) > at > com.puppycrawl.tools.checkstyle.PackageObjectFactory.doMakeObject(PackageObjectFactory.java:87) > at > com.puppycrawl.tools.checkstyle.PackageObjectFactory.createModule(PackageObjectFactory.java:149) > at com.puppycrawl.tools.checkstyle.Checker.setupChild(Checker.java:140) > at > com.puppycrawl.tools.checkstyle.api.AutomaticBean.configure(AutomaticBean.java:208) > at > org.apache.maven.plugin.checkstyle.CheckstyleReport.executeCheckstyle(CheckstyleReport.java:870) > at > org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:587) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98) > at > org
[jira] Created: (WAGON-108) HttpException deploying to webdav
HttpException deploying to webdav - Key: WAGON-108 URL: http://jira.codehaus.org/browse/WAGON-108 Project: wagon Issue Type: Bug Components: wagon-webdav Affects Versions: 1.0-beta-2 Environment: Maven version: 2.0.9 Java version: 1.5.0_12 OS name: "linux" version: "2.6.22" arch: "i386" Family: "unix" Reporter: Steffen Werner When trying to deploy to our webdav maven-repository the following exception occurs: [...] [INFO] [install:install] [INFO] Installing /home/sw/my-project/target/my-project.jar to /opt/maven/repository/my-project/1.0-SNAPSHOT/my-project-1.0-SNAPSHOT.jar [INFO] [deploy:deploy] altDeploymentRepository = null [INFO] Retrieving previous build number from maven-host Uploading: http://maven-host/maven/my-project/1.0-SNAPSHOT/my-project-1.0-20080416.104050-26.jar org.apache.commons.httpclient.HttpException: Unbuffered entity enclosing request can not be repeated. at org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:436) at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2316) at org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBase.java:2651) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1087) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:643) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:497) at org.apache.maven.wagon.providers.webdav.CorrectedWebdavResource.putMethod(CorrectedWebdavResource.java:156) at org.apache.maven.wagon.providers.webdav.WebDavWagon.put(WebDavWagon.java:287) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:244) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:160) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:162) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error deploying artifact: PUT request for: my-project/1.0-SNAPSHOT/my-project-1.0-20080416.104050-26.jar to my-project.jar failed Unbuffered entity enclosing request can not be repeated. [...] The access.log of our maven-repository show the following: [...] maven-host - [16/Apr/2008:12:44:00 +0200] "MKCOL /maven/my-project/1.0-SNAPSHOT/ HTTP/1.1" 401 401 "-" "Jakarta Commons-HttpClient/2.0.2" "-" "-" "-" "-" "-" "-" "112" maven-host devbuild [16/Apr/2008:12:44:00 +0200] "MKCOL /maven/my-project/1.0-SNAPSHOT/ HTTP/1.1" 405 236 "-" "Jakarta Commons-HttpClient/2.0.2" "-" "-" "-" "-" "-" "-" "123" maven-host - [16/Apr/2008:12:44:00 +0200] "PUT /maven/my-project/1.0-SNAPSHOT/my-project-1.0-20080416.104050-26.jar HTTP/1.1" 401 401 "-" "Jakarta Commons-HttpClient/2.0.2" "-" "-" "-" "-" "-" "-" "15853" maven-host devbuild [16/Apr/2008:12:44:00 +0200] "PUT /maven/my-project/1.0-SNAPSHOT/my-project-1.0-20080416.104050-26.jar HTTP/1.1" 20
[jira] Commented: (MECLIPSE-377) eclipse:eclipse -DdownloadSources=true shouldn't attempt download more than once in a multi-project
[ http://jira.codehaus.org/browse/MECLIPSE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=130984#action_130984 ] Julien Renaut commented on MECLIPSE-377: Sharing the mvn-eclipse-cache.properties between projects would require to have some file location configured in your settings.xml and could be probably be done. I'll try to patch this. > eclipse:eclipse -DdownloadSources=true shouldn't attempt download more than > once in a multi-project > --- > > Key: MECLIPSE-377 > URL: http://jira.codehaus.org/browse/MECLIPSE-377 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path, Core : > Multi-projects >Affects Versions: 2.4 >Reporter: Steinar Bang > > If you run "mvn eclipse:eclipse -DdownloadSources=true" it attempts to > download source jars for all projects, even when it has tried (and failed) to > download the jars in earlier projects. This slows down the goal a lot on > slow network connections. -- 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: (MECLIPSE-427) .springBeans definition throws NullPointer if BaseDir does not exist
[
http://jira.codehaus.org/browse/MECLIPSE-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Freeman updated MECLIPSE-427:
-
Attachment: MyEclipseSpringBeansWriter.java
> .springBeans definition throws NullPointer if BaseDir does not exist
>
>
> Key: MECLIPSE-427
> URL: http://jira.codehaus.org/browse/MECLIPSE-427
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: MyEclipse support
>Affects Versions: 2.5, 2.5.1
>Reporter: Joe Freeman
> Attachments: MyEclipseSpringBeansWriter.java,
> MyEclipseSpringBeansWriter.java
>
>
> This is related to the fix submitted for MECLIPSE-359
> We have an application with 40 eclipse projects in it. About half of them
> have spring beans and 1/2 don't. The top level pom describes how the eclipse
> plugin should function and includes the Spring configuration component for
> the myeclipse target. A null pointer is thrown when running
> eclipse:myeclipse when the base dir doesn't exist, in our case in one of the
> projects that doesn't have any spring components. Our pom.xml fragment looks
> like
>
> 2.0
> *.xml
> src/main/resources/conf
>
> The exception stack trace looks like
> java.lang.NullPointerException
> at
> org.apache.maven.plugin.eclipse.writers.myeclipse.MyEclipseSpringBeansWriter.getConfigurationFilesList(MyEclipseSpringBeansWriter.java:142)
> at
> org.apache.maven.plugin.eclipse.writers.myeclipse.MyEclipseSpringBeansWriter.write(MyEclipseSpringBeansWriter.java:93)
> The following code block with the problem throws NullPointer when
> directory.listFiles() returns a null into subdirs. Wrap the for() loop in a
> nullcheck
>try
> {
> File directory = new File( basedir );
> File[] subdirs = directory.listFiles( new FileFilter()
> {
> public boolean accept( File pathname )
> {
> return pathname.isDirectory();
> }
> } );
> for ( int i = 0; i < subdirs.length; i++ )
> {
> configFiles.addAll( getConfigurationFilesList(
> subdirs[i].getPath(), pattern ) );
> }
> configFiles.addAll( FileUtils.getFileNames( directory, pattern,
> null, true ) );
> }
> Testing:
> Take one of the test cases and remove the directory that is pointed to by the
> basedir attribute.
--
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: (ARCHETYPE-159) mvn archetype:generate is failing to download needed archetype artifacts
[
http://jira.codehaus.org/browse/ARCHETYPE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=130987#action_130987
]
Olivier Martin commented on ARCHETYPE-159:
--
Same error here, there is an incompatibility between the archetype plugin and
Maven 2.0.9.
I can reproduce it with any of the default catalog and with our own catalog.
The only workaround is to have a local version of the archetype, it's not
downloaded from the server.
{code}
Downloading:
http://static.appfuse.org/releases/org/appfuse/archetypes/appfuse-basic-jsf/2.0/appfuse-basic-jsf-2.0.jar
org.apache.maven.archetype.downloader.DownloadException: Error downloading.
at
org.apache.maven.archetype.downloader.DefaultDownloader.download(DefaultDownloader.java:58)
at
org.apache.maven.archetype.common.DefaultArchetypeArtifactManager.exists(DefaultArchetypeArtifactManager.java:310)
at
org.apache.maven.archetype.ui.DefaultArchetypeGenerationConfigurator.configureArchetype(DefaultArchetypeGenerationConfigurator.java:103)
{code}
For me this is a blocker.
> mvn archetype:generate is failing to download needed archetype artifacts
>
>
> Key: ARCHETYPE-159
> URL: http://jira.codehaus.org/browse/ARCHETYPE-159
> Project: Maven Archetype
> Issue Type: Bug
> Components: Archetypes
> Environment: Windows XP, Maven 2.0.9
>Reporter: Glen Mazza
>
> A fresh install of Maven 2.0.9 on Windows XP, if I issue this command:
> mvn archetype:generate -DarchetypeArtifactId=maven-archetype-quickstart
> I get this error message:
> [INFO] The desired archetype does not exist
> (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
> Partial error stack:
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'archetype'.
> [INFO]
>
> [INFO] Building Maven Default Project
> [INFO]task-segment: [archetype:generate] (aggregator-style)
> [INFO]
>
> [INFO] Preparing archetype:generate
> [INFO] No goals needed for project - skipping
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus
> .velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] [archetype:generate]
> org.apache.maven.archetype.downloader.DownloadNotFoundException: Requested
> downl
> oad does not exist.
> at
> org.apache.maven.archetype.downloader.DefaultDownloader.download(Defa
> ultDownloader.java:62)
> at
> org.apache.maven.archetype.common.DefaultArchetypeArtifactManager.exi
> sts(DefaultArchetypeArtifactManager.java:310)
> at
> org.apache.maven.archetype.ui.DefaultArchetypeGenerationConfigurator.
> configureArchetype(DefaultArchetypeGenerationConfigurator.java:103)
> The same error also happens with an archetype artifact ID of
> "maven-archetype-webapp" (and probably all the others as well).
> However, if I issue the same command but using archetype:create instead of
> :generate, not only will the archetype artifact correctly download (and the
> command work successfully), subsequent usages of archetype:generate with that
> same archetype artifact will also correctly run.
> So I think the problem is that mvn archetype:generate needs to download
> archetype artifacts just like mvn archetype:create does.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MWAR-154) documentation for overlay is incorrect
documentation for overlay is incorrect -- Key: MWAR-154 URL: http://jira.codehaus.org/browse/MWAR-154 Project: Maven 2.x War Plugin Issue Type: Task Reporter: Olaf Kittelmann The documentation on http://maven.apache.org/plugins/maven-war-plugin/overlays.html describes a feature that only works with version 2.1-alpha-1 of the plugin. yet the pom snippets on the documentation page always point to version 2.0. [...] org.apache.maven.plugins maven-war-plugin 2.0 **/IncludeME,**/images [...] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MARTIFACT-13) Make set of deployed checksums configurable
Make set of deployed checksums configurable
---
Key: MARTIFACT-13
URL: http://jira.codehaus.org/browse/MARTIFACT-13
Project: Maven Artifact
Issue Type: New Feature
Affects Versions: 3.0-alpha-1
Reporter: Benjamin Bentmann
Nothing new, just an official ticket for
{code:java}
// TODO: configure these on the repository
for ( int i = 0; i < CHECKSUM_IDS.length; i++ )
{
checksums.put( CHECKSUM_IDS[i], addChecksumObserver( wagon,
CHECKSUM_ALGORITHMS[i] ) );
}
{code}
from the
{{[DefaultWagonManager|http://svn.apache.org/viewvc/maven/artifact/trunk/src/main/java/org/apache/maven/artifact/manager/DefaultWagonManager.java?revision=647022&view=markup]}}.
Since maven-artifact:3.0 is a major release, it might be a good time to add
the required methods into the API.
Number one use case is to entirely disable checksum files, e.g. to upload EARs
directly into an app server's deployment directory via scp.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-311) Empty outputFileNameMapping creates zip entries with no name
Empty outputFileNameMapping creates zip entries with no name
Key: MASSEMBLY-311
URL: http://jira.codehaus.org/browse/MASSEMBLY-311
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-2
Environment: Maven 2.0.9
Reporter: Dirk Olmes
Attachments: assembly-with-system-dependency.zip
I'm working on a project that has system dependencies. I want to package those
dependencies with their original name into the assembly (i.e. use the same name
of the JAR as in the system path).
Leaving the outputFileNameMapping in the assembly descriptor's dependencySet
creates ZipEntries in the resulting zip file but those don't have a name.
Example:
{code}
unzip -qql target/assembly.zip
0 04-16-08 16:20 assembly/
2205737 04-07-08 18:23 assembly/lib/
2621 04-16-08 16:20 assembly/lib/
{code}
Note the second line ...
I have attached a sample project that uses Maven's uber Jar as system scope
dependency. Run the test with mvn -DMAVEN_HOME= package assembly:assembly
to create the zip.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3528) Order of executing plugins in maven 2.0.9
Order of executing plugins in maven 2.0.9
-
Key: MNG-3528
URL: http://jira.codehaus.org/browse/MNG-3528
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0.9
Environment: Maven 2.0.9
Reporter: David Bernhard
Priority: Minor
Attachments: 209test.zip
Suppose you include a plugin like this:
my.bug.test
plugin
1.0
first
compile
first
my.bug.test
plugin
1.0
second
compile
second
Then SECOND will execute before FIRST. The reason is in
ModelUtils.java:MergePluginDefinitions the new definition is passed as parent
and the old as child - and the parent comes first in the merged executions.
However, this works correctly:
my.bug.test
plugin
1.0
both
test
first
second
I have included a tiny test case that demonstrates this. Here's my output:
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [:second {execution: second}]
SECOND
[INFO] [:first {execution: first}]
FIRST
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [:first {execution: both}]
FIRST
[INFO] [:second {execution: both}]
SECOND
--
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-3528) Order of executing plugins in maven 2.0.9
[
http://jira.codehaus.org/browse/MNG-3528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131004#action_131004
]
John Casey commented on MNG-3528:
-
It should be a validation error to have two plugin entries in the build section
of your POM that reference the same plugin. Since you were able to add two
plugin entries like the above description, this is what actually needs to be
fixed. Having two plugin entries will inevitably lead to problems with users
thinking they are looking at the whole configuration for a plugin when they are
in fact looking at only part of it (and the rest is scrolled off-page).
> Order of executing plugins in maven 2.0.9
> -
>
> Key: MNG-3528
> URL: http://jira.codehaus.org/browse/MNG-3528
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.0.9
> Environment: Maven 2.0.9
>Reporter: David Bernhard
>Priority: Minor
> Attachments: 209test.zip
>
>
> Suppose you include a plugin like this:
>
> my.bug.test
> plugin
> 1.0
>
>
> first
> compile
>
> first
>
>
>
>
>
> my.bug.test
> plugin
> 1.0
>
>
> second
> compile
>
> second
>
>
>
>
> Then SECOND will execute before FIRST. The reason is in
> ModelUtils.java:MergePluginDefinitions the new definition is passed as parent
> and the old as child - and the parent comes first in the merged executions.
> However, this works correctly:
>
> my.bug.test
> plugin
> 1.0
>
>
> both
> test
>
> first
> second
>
>
>
>
> I have included a tiny test case that demonstrates this. Here's my output:
> [INFO] [compiler:compile]
> [INFO] No sources to compile
> [INFO] [:second {execution: second}]
> SECOND
> [INFO] [:first {execution: first}]
> FIRST
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> [INFO] No sources to compile
> [INFO] [surefire:test]
> [INFO] No tests to run.
> [INFO] [:first {execution: both}]
> FIRST
> [INFO] [:second {execution: both}]
> SECOND
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-311) Empty outputFileNameMapping creates zip entries with no name
[
http://jira.codehaus.org/browse/MASSEMBLY-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-311:
-
Priority: Trivial (was: Major)
Although perhaps not that helpful, this is exactly what I would expect an empty
filename mapping to do...
Sure, we need to fix it and give a warning to the user that the plugin will use
the default mapping instead of the blank one.
> Empty outputFileNameMapping creates zip entries with no name
>
>
> Key: MASSEMBLY-311
> URL: http://jira.codehaus.org/browse/MASSEMBLY-311
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: Maven 2.0.9
>Reporter: Dirk Olmes
>Priority: Trivial
> Attachments: assembly-with-system-dependency.zip
>
>
> I'm working on a project that has system dependencies. I want to package
> those dependencies with their original name into the assembly (i.e. use the
> same name of the JAR as in the system path).
> Leaving the outputFileNameMapping in the assembly descriptor's dependencySet
> creates ZipEntries in the resulting zip file but those don't have a name.
> Example:
> {code}
> unzip -qql target/assembly.zip
> 0 04-16-08 16:20 assembly/
> 2205737 04-07-08 18:23 assembly/lib/
>2621 04-16-08 16:20 assembly/lib/
> {code}
> Note the second line ...
> I have attached a sample project that uses Maven's uber Jar as system scope
> dependency. Run the test with mvn -DMAVEN_HOME= package assembly:assembly
> to create the zip.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-332) release:prepare fails if project does not contain directory src/main/java
[ http://jira.codehaus.org/browse/MRELEASE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse McConnell closed MRELEASE-332. Assignee: Jesse McConnell Resolution: Cannot Reproduce I have worked with a number of projects without java source and they release fine, this is failing because of an underlying svn issue with your setup I believe. try replicating the circumstances from the commandline to sort out whats going on cheers! > release:prepare fails if project does not contain directory src/main/java > - > > Key: MRELEASE-332 > URL: http://jira.codehaus.org/browse/MRELEASE-332 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Environment: OSX 10.5, jdk 1.5, mvn 2.0.8 >Reporter: Alphonse Bendt >Assignee: Jesse McConnell > > i'm trying to perform mvn release:prepare on a project that does not contain > any java sources (e.g. the directory src/main/java does not exist). > this seems to break build to break. > if i add the directory it seems to work. > > mvn release:prepare > [...] > [INFO] Tagging release with the label mps-webapplication-1.3... > [INFO] Executing: svn --non-interactive copy --file > /tmp/maven-scm-248675112.commit . > svn://42.42.0.23/mps/tags/mps-webapplication-1.3 > [INFO] Working directory: /Users/bendt/Projekte/MPS/mps-webapplication > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Unable to tag SCM > Provider message: > The svn tag command failed. > Command output: > svn: Commit failed (details follow): > svn: Directory '/Users/bendt/Projekte/MPS/mps-webapplication/src/main/java' > is missing > [INFO] > > [DEBUG] Trace > org.apache.maven.BuildFailureException: Unable to tag SCM > Provider message: > The svn tag command failed. > Command output: > svn: Commit failed (details follow): > svn: Directory '/Users/bendt/Projekte/MPS/mps-webapplication/src/main/java' > is missing > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:560) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoFailureException: Unable to tag SCM > Provider message: > The svn tag command failed. > Command output: > svn: Commit failed (details follow): > svn: Directory '/Users/bendt/Projekte/MPS/mps-webapplication/src/main/java' > is missing > at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:144) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > ... 16 more > [INFO] > > [INFO] Total time: 3 seconds > [INFO] Finished at: Tue Mar 11 16:29:29 CET 2008 > [INFO] Final Memory: 6M/12M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more informatio
[jira] Moved: (SCM-373) Unable to do a release with release plug-in
[ http://jira.codehaus.org/browse/SCM-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse McConnell moved MRELEASE-257 to SCM-373: -- Affects Version/s: (was: 2.0-beta-4) Complexity: Novice Key: SCM-373 (was: MRELEASE-257) Project: Maven SCM (was: Maven 2.x Release Plugin) > Unable to do a release with release plug-in > --- > > Key: SCM-373 > URL: http://jira.codehaus.org/browse/SCM-373 > Project: Maven SCM > Issue Type: Bug > Environment: Windows XP SP2, Maven 2.0.7, JDK 1.5.0_10 >Reporter: Pascal ST LAURENT > > When I try to do a release, I call the following statement : mvn > release:prepare. I received this exception, maybe caused by path too long in > the project... > [ERROR] FATAL ERROR > [INFO] > > [INFO] 60 > [INFO] > > [INFO] Trace > java.lang.ArrayIndexOutOfBoundsException: 60 > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateUrlPath(RewritePomsForReleasePhase.java:249) > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateScm(RewritePomsForReleasePhase.java:124) > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.transformScm(RewritePomsForReleasePhase.java:61) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:271) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:180) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:116) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:99) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) > at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3529) mvn -Da=" " throws an excepltion
mvn -Da=" " throws an excepltion Key: MNG-3529 URL: http://jira.codehaus.org/browse/MNG-3529 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.8 Reporter: Sean Bridges Priority: Trivial Doing, mvn -Da=" " throws, --- java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.AbstractStringBuilder.setLength(AbstractStringBuilder.java:146) at java.lang.StringBuffer.setLength(StringBuffer.java:154) at org.apache.maven.cli.MavenCli$CLIManager.cleanArgs(MavenCli.java:793) at org.apache.maven.cli.MavenCli$CLIManager.parse(MavenCli.java:746) at org.apache.maven.cli.MavenCli.main(MavenCli.java:100) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-312) outputFileNameMapping not respected when the unpack=true
outputFileNameMapping not respected when the unpack=true
Key: MASSEMBLY-312
URL: http://jira.codehaus.org/browse/MASSEMBLY-312
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-2
Reporter: Calvin Yu
If I configure a dependencySet to unpack = true, the outputFileNameMapping is
not respected, and instead the artifact is decompressed into the output
directory. Looking at the code, this looks like it'll affect moduleSets as
well.
For example:
some_directory
${artifact.artifactId}.${artifact.extension}
true
--
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: (MANTTASKS-108) Maven Ant Tasks are switching the Classloader of the Main Ant Thread
[
http://jira.codehaus.org/browse/MANTTASKS-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131012#action_131012
]
Thomas Tardy commented on MANTTASKS-108:
When is the planed release date for the maven ant tasks version 2.0.9?
> Maven Ant Tasks are switching the Classloader of the Main Ant Thread
>
>
> Key: MANTTASKS-108
> URL: http://jira.codehaus.org/browse/MANTTASKS-108
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: deploy task
>Affects Versions: 2.0.8
> Environment: I have testet it on windows as well as linux.
>Reporter: Thomas Tardy
>Assignee: Herve Boutemy
>Priority: Critical
> Fix For: 2.0.9
>
>
> There is a thread on the user mailing list which describes the problem.
> http://www.nabble.com/Using-Maven-Ant-Tasks-in-a-CI-Environment-with-IBM-Jazz-tt16556859s177.html#a16574083
> The problem can be reproduced with the following script.
> The ant build script:
>
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
>
> description
>
> classname="maven.test.task.MavenTestTask" />
>
>
>
>
>
>
> />
>
>
>
>
>
>
> The simple Ant Task:
> package maven.test.task;
> import org.apache.tools.ant.BuildException;
> import org.apache.tools.ant.Task;
> /**
> * Test task demonstrating Maven switching the class loader.
> */
> public class MavenTestTask extends Task {
> /* (non-Javadoc)
> * Intentionally not documented. See parent.
> */
> @Override
> public void execute() throws BuildException {
> log("Current Class Loader: " +
> Thread.currentThread().getContextClassLoader());
> }
>
> The output when run in Ant:
> Buildfile: C:\Maven\Test\build.xml
> default:
> [echo] Invoking test class that does nothing but echo the classloader
> [mavenTestTask] Current Class Loader: [EMAIL PROTECTED]
> [echo] Invoking maven artifact:pom task
> [echo] Invoking test class again that does nothing but echo the
> classloader
> [mavenTestTask] Current Class Loader: [EMAIL PROTECTED]
> BUILD SUCCESSFUL
> Total time: 871 milliseconds
> Thanks for your support!
--
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: (NMAVEN-119) Ability to generate pom.xml file from an existing Visual Studio solution file
[ http://jira.codehaus.org/browse/NMAVEN-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131013#action_131013 ] Shane Isbell commented on NMAVEN-119: - Just eyeballing this, it looks good. It needs the apache license headers attached to all the class files though. > Ability to generate pom.xml file from an existing Visual Studio solution file > - > > Key: NMAVEN-119 > URL: http://jira.codehaus.org/browse/NMAVEN-119 > Project: NMaven > Issue Type: New Feature >Affects Versions: 0.14 (Unreleased) >Reporter: jan ancajas > Attachments: NMaven-assemblies-119.patch > > > the pom generator utility will accept the parent solution file, parses its > corresponding csproj/vbproj files then generate the pom for every module 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] Commented: (NMAVEN-118) Errors from .NET plugins are not recognized
[ http://jira.codehaus.org/browse/NMAVEN-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131014#action_131014 ] Shane Isbell commented on NMAVEN-118: - I'll get this one in today. > Errors from .NET plugins are not recognized > --- > > Key: NMAVEN-118 > URL: http://jira.codehaus.org/browse/NMAVEN-118 > Project: NMaven > Issue Type: Bug >Affects Versions: 0.14 (Unreleased) > Environment: Windows XP SP2, VS2005, JDK 1.5, Maven 2.0.7 >Reporter: Napoleon Esmundo C. Ramirez > Attachments: NMAVEN-118.patch > > > Errors are not detected because the process isn't allowed to finish. -- 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: (MANTTASKS-108) Maven Ant Tasks are switching the Classloader of the Main Ant Thread
[
http://jira.codehaus.org/browse/MANTTASKS-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131019#action_131019
]
Benjamin Bentmann commented on MANTTASKS-108:
-
bq. When is the planed release date for the maven ant tasks version 2.0.9?
Hervé already started the [release
vote|http://www.nabble.com/-VOTE--Release-Maven-Ant-Tasks-version-2.0.9-to16689878s177.html].
> Maven Ant Tasks are switching the Classloader of the Main Ant Thread
>
>
> Key: MANTTASKS-108
> URL: http://jira.codehaus.org/browse/MANTTASKS-108
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: deploy task
>Affects Versions: 2.0.8
> Environment: I have testet it on windows as well as linux.
>Reporter: Thomas Tardy
>Assignee: Herve Boutemy
>Priority: Critical
> Fix For: 2.0.9
>
>
> There is a thread on the user mailing list which describes the problem.
> http://www.nabble.com/Using-Maven-Ant-Tasks-in-a-CI-Environment-with-IBM-Jazz-tt16556859s177.html#a16574083
> The problem can be reproduced with the following script.
> The ant build script:
>
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
>
> description
>
> classname="maven.test.task.MavenTestTask" />
>
>
>
>
>
>
> />
>
>
>
>
>
>
> The simple Ant Task:
> package maven.test.task;
> import org.apache.tools.ant.BuildException;
> import org.apache.tools.ant.Task;
> /**
> * Test task demonstrating Maven switching the class loader.
> */
> public class MavenTestTask extends Task {
> /* (non-Javadoc)
> * Intentionally not documented. See parent.
> */
> @Override
> public void execute() throws BuildException {
> log("Current Class Loader: " +
> Thread.currentThread().getContextClassLoader());
> }
>
> The output when run in Ant:
> Buildfile: C:\Maven\Test\build.xml
> default:
> [echo] Invoking test class that does nothing but echo the classloader
> [mavenTestTask] Current Class Loader: [EMAIL PROTECTED]
> [echo] Invoking maven artifact:pom task
> [echo] Invoking test class again that does nothing but echo the
> classloader
> [mavenTestTask] Current Class Loader: [EMAIL PROTECTED]
> BUILD SUCCESSFUL
> Total time: 871 milliseconds
> Thanks for your support!
--
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: (MCHECKSTYLE-90) Checkstyle-2.2-SNAPSHOT not working with Maven 2.0.9
[ http://jira.codehaus.org/browse/MCHECKSTYLE-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131022#action_131022 ] Dennis Lundberg commented on MCHECKSTYLE-90: Thanks for the project Ricky. A first check reveals that this issue has nothing to do with the Maven version being used. I get the same error as you did with Maven versions 2.0.6 -- 2.0.9. I'll investigate further... > Checkstyle-2.2-SNAPSHOT not working with Maven 2.0.9 > > > Key: MCHECKSTYLE-90 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-90 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ricky Hazelwood > Attachments: checkstyle-bug.zip > > > The changes in Maven 2.0.9 is causing the plugin to use commons-collection > 2.0 instead of 2.1 required by checkstyle. Forcing the commons-collection > version 2.1 in the plugin config fixes this issue. > [INFO] [checkstyle:checkstyle] > [FATAL ERROR] org.apache.maven.plugin.checkstyle.CheckstyleReport#execute() > caused a linkage error (java.lang.NoClassDefFoundError) and may be > out-of-date. Check the realms: > [FATAL ERROR] Plugin realm = > app0.child-container[org.apache.maven.plugins:maven-checkstyle-plugin] > urls[0] = > file:/D:/maven2/repository/org/apache/maven/plugins/maven-checkstyle-plugin/2.2-SNAPSHOT/maven-checkstyle-plugin-2.2-SNAPSHOT.jar > urls[1] = > file:/D:/maven2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar > urls[2] = > file:/D:/maven2/repository/org/apache/maven/reporting/maven-reporting-impl/2.0/maven-reporting-impl-2.0.jar > urls[3] = > file:/D:/maven2/repository/commons-validator/commons-validator/1.1.4/commons-validator-1.1.4.jar > urls[4] = file:/D:/maven2/repository/oro/oro/2.0.7/oro-2.0.7.jar > urls[5] = > file:/D:/maven2/repository/doxia/doxia-core/1.0-alpha-4/doxia-core-1.0-alpha-4.jar > urls[6] = > file:/D:/maven2/repository/org/codehaus/plexus/plexus-resources/1.0-alpha-4/plexus-resources-1.0-alpha-4.jar > urls[7] = > file:/D:/maven2/repository/org/codehaus/plexus/plexus-velocity/1.1.2/plexus-velocity-1.1.2.jar > urls[8] = > file:/D:/maven2/repository/commons-collections/commons-collections/2.0/commons-collections-2.0.jar > urls[9] = > file:/D:/maven2/repository/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar > urls[10] = file:/D:/maven2/repository/velocity/velocity/1.4/velocity-1.4.jar > urls[11] = > file:/D:/maven2/repository/velocity/velocity-dep/1.4/velocity-dep-1.4.jar > urls[12] = > file:/D:/maven2/repository/checkstyle/checkstyle/4.4/checkstyle-4.4.jar > urls[13] = file:/D:/maven2/repository/antlr/antlr/2.7.6/antlr-2.7.6.jar > urls[14] = > file:/D:/maven2/repository/commons-beanutils/commons-beanutils-core/1.7.0/commons-beanutils-core-1.7.0.jar > urls[15] = > file:/D:/maven2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar > urls[16] = > file:/D:/maven2/repository/checkstyle/checkstyle-optional/4.4/checkstyle-optional-4.4.jar > [FATAL ERROR] Container realm = plexus.core > urls[0] = file:/C:/Program Files/Java/maven/lib/maven-2.0.9-uber.jar > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] org/apache/commons/collections/ReferenceMap > org.apache.commons.collections.ReferenceMap > [INFO] > > [INFO] Trace > java.lang.NoClassDefFoundError: org/apache/commons/collections/ReferenceMap > at > com.puppycrawl.tools.checkstyle.checks.duplicates.StrictDuplicateCodeCheck.(StrictDuplicateCodeCheck.java:191) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at java.lang.Class.newInstance0(Class.java:355) > at java.lang.Class.newInstance(Class.java:308) > at > com.puppycrawl.tools.checkstyle.PackageObjectFactory.createObject(PackageObjectFactory.java:110) > at > com.puppycrawl.tools.checkstyle.PackageObjectFactory.doMakeObject(PackageObjectFactory.java:87) > at > com.puppycrawl.tools.checkstyle.PackageObjectFactory.createModule(PackageObjectFactory.java:149) > at com.puppycrawl.tools.checkstyle.Checker.setupChild(Checker.java:140) > at > com.puppycrawl.tools.checkstyle.api.AutomaticBean.configure(AutomaticBean.java:208) > at > org.apache.maven.plugin.checkstyle.CheckstyleReport.executeCheckstyle(CheckstyleRep
[jira] Commented: (MCHECKSTYLE-90) Checkstyle-2.2-SNAPSHOT not working with Maven 2.0.9
[ http://jira.codehaus.org/browse/MCHECKSTYLE-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131025#action_131025 ] Dennis Lundberg commented on MCHECKSTYLE-90: Here is the relevant part of the dependency resolution when running 'mvn checkstyle:checkstyle -X' [DEBUG] Adding managed dependencies for org.apache.maven:maven-model [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8 [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5 [DEBUG] org.apache.maven.wagon:wagon-ssh:jar:1.0-alpha-5 [DEBUG] org.apache.maven.wagon:wagon-file:jar:1.0-alpha-5 [DEBUG] org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-5 [DEBUG] org.apache.maven:maven-model:jar:2.0:runtime (selected for runtime) [DEBUG] Retrieving parent-POM: org.codehaus.plexus:plexus::1.0.11 for project: null:plexus-utils:jar:1.4.4 from the repository. [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed - nearer found: 1.4.4) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.4.4:runtime (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-velocity:jar:1.1.2:runtime (selected for runtime) [DEBUG] Retrieving parent-POM: plexus:plexus-containers::1.0.2 for project: org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-7 from the repository. [DEBUG] Retrieving parent-POM: plexus:plexus-root::1.0.3 for project: plexus:plexus-containers:pom:1.0.2 from the repository. [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-7:runtime (removed - nearer found: 1.0-alpha-9) [DEBUG] commons-collections:commons-collections:jar:2.0:runtime (selected for runtime) *<< plexus-velocity:1.1.2 wants commons-collections:2.0* [DEBUG] commons-logging:commons-logging-api:jar:1.0.4:runtime (selected for runtime) [DEBUG] velocity:velocity:jar:1.4:runtime (selected for runtime) [DEBUG] velocity:velocity-dep:jar:1.4:runtime (selected for runtime) [DEBUG] checkstyle:checkstyle:jar:4.4:runtime (selected for runtime) [DEBUG] antlr:antlr:jar:2.7.6:runtime (selected for runtime) [DEBUG] commons-beanutils:commons-beanutils-core:jar:1.7.0:runtime (selected for runtime) [DEBUG] commons-logging:commons-logging:jar:1.0:runtime (selected for runtime) [DEBUG] commons-cli:commons-cli:jar:1.0:runtime (selected for runtime) [DEBUG] commons-lang:commons-lang:jar:1.0:runtime (selected for runtime) [DEBUG] junit:junit:jar:3.7:runtime (removed - nearer found: 3.8.1) [DEBUG] commons-collections:commons-collections:jar:2.1:runtime (removed - nearer found: 2.0) *<< checkstyle:4.4 wants commons-collections:2.0* [DEBUG] commons-logging:commons-logging:jar:1.0:runtime (removed - nearer found: 1.0.3) [DEBUG] commons-logging:commons-logging:jar:1.0.3:runtime (selected for runtime) Why on earth does commons-collections 2.0 win here, when 2.1 is newer and potentially (as in this case) contains methods not included in 2.1? I suspect that this problem is in Maven core somewhere, but I'll see if I can create a workaround in this plugin somehow. > Checkstyle-2.2-SNAPSHOT not working with Maven 2.0.9 > > > Key: MCHECKSTYLE-90 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-90 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ricky Hazelwood > Attachments: checkstyle-bug.zip > > > The changes in Maven 2.0.9 is causing the plugin to use commons-collection > 2.0 instead of 2.1 required by checkstyle. Forcing the commons-collection > version 2.1 in the plugin config fixes this issue. > [INFO] [checkstyle:checkstyle] > [FATAL ERROR] org.apache.maven.plugin.checkstyle.CheckstyleReport#execute() > caused a linkage error (java.lang.NoClassDefFoundError) and may be > out-of-date. Check the realms: > [FATAL ERROR] Plugin realm = > app0.child-container[org.apache.maven.plugins:maven-checkstyle-plugin] > urls[0] = > file:/D:/maven2/repository/org/apache/maven/plugins/maven-checkstyle-plugin/2.2-SNAPSHOT/maven-checkstyle-plugin-2.2-SNAPSHOT.jar > urls[1] = > file:/D:/maven2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar > urls[2] = > file:/D:/maven2/repository/org/apache/maven/reporting/maven-reporting-impl/2.0/maven-reporting-impl-2.0.jar > urls[3] = > file:/D:/maven2/repository/commons-validator/commons-validator/1.1.4/commons-validator-1.1.4.jar > urls[4] = file:/D:/maven2/repository/oro/oro/2.0.7/oro-2.0.7.jar > urls[5] = > file:/D:/maven2/repository/doxia/doxia-core/1.0-alpha-4/doxia-core-1.0-alpha-4.jar > urls[6] = > file:/D:/maven2/repository/org/codehaus/plexus/plexus-resources/1.0-alpha-4/plexus-resources-1.0-alpha-4.jar > urls[7] = > file:/D:/maven2/repository/org/c
[jira] Updated: (MJAR-105) Regression: Build fails for an empty main jar with 2.2
[
http://jira.codehaus.org/browse/MJAR-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MJAR-105:
-
Attachment: MJAR-105.zip
I was unable to reproduce this using Maven 2.0.8 or 2.0.9.
Here's a sample project that works-for-me ^tm^
> Regression: Build fails for an empty main jar with 2.2
> --
>
> Key: MJAR-105
> URL: http://jira.codehaus.org/browse/MJAR-105
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Joerg Schaible
> Attachments: MJAR-105.zip
>
>
> We have quite some projects with integration tests that have only test code,
> but no sources (neither Java nor other resources) that are included into the
> main artifact. With jar-plugin version 2.2 these kind of projects suddenly
> fail:
> {noformat}
> [INFO]
>
> [INFO] Building eIP TempAccess Integration Tests
> [INFO]task-segment: [clean, deploy]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> D:\work\standard\eIP\TempAccess\EnterpriseArchive\integration-test-jar\target
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> [INFO] No sources to compile
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> [INFO] Compiling 1 source file to
> D:\work\standard\eIP\TempAccess\EnterpriseArchive\integration-test-jar\target\test-classes
> [INFO] [surefire:test]
> [INFO] Tests are skipped.
> [INFO] [jar:jar]
> [WARNING] JAR will be empty - no content was marked for inclusion!
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error assembling JAR
> Embedded error: You must set at least one file.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 14 minutes 44 seconds
> [INFO] Finished at: Wed Apr 16 08:18:43 CEST 2008
> [INFO] Final Memory: 111M/200M
> [INFO]
>
> {noformat}
> With 2.1 an empty main jar has been created and this behaviour was explicitly
> acknowledged in MJAR-8.
> We stumbled about this upgrading from M205 to M209 that allowed us to use
> also the newer jar-plugin version. Currently we're stuck with jar-plugin
> version 2.1 because of this.
--
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: (MIDEA-102) Module filepath is generated incorrectly for sibling parent
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131030#action_131030 ] gotama commented on MIDEA-102: -- What is the status of this issue? I'm willing to forgo the whole implementation style argument for simply getting "A" fixed version of 2.2 out the door. The current SNAPSHOT works, so I vote for releasing it, then later on revisiting the 3 different ways the paths can be corrected. The important thing is that it is fixed. In the mean time, there are people out there trying to use Maven for the first time, and they will not be impressed when 'mvn idea:idea' does not work. This is one of the cool selling points of Maven to a team of developers and its been busted for a year. Release 2.2... Thanks. > Module filepath is generated incorrectly for sibling parent > --- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCLEAN-33) Cannot Supress Default clean while still cleaning
Cannot Supress Default clean while still cleaning
-
Key: MCLEAN-33
URL: http://jira.codehaus.org/browse/MCLEAN-33
Project: Maven 2.x Clean Plugin
Issue Type: New Feature
Affects Versions: 2.1.1
Reporter: Joshua Pollak
Priority: Minor
We would like to configure clean in our parent pom to remove the log files in
logs in all our child modules. We've done that like this:
maven-clean-plugin
2.1.1
${basedir}/logs
false
**/.svn
The problem is that when we want to clean an extra directory out of a module,
say for example, generated-sources:
maven-clean-plugin
2.1.1
gensrc
clean
clean
generated-sources
false
We then see the following when we run "mvn clean":
FO] Building Generated Sources
[INFO]task-segment: [clean]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/classes
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/test-classes
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/site
[INFO] Deleting file-set:
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/logs (included: [],
excluded: [**/.svn])
[INFO] [clean:clean {execution: gensrc}]
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/classes
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/test-classes
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/site
[INFO] Deleting file-set: generated-sources (included: [], excluded: [**/.svn])
[INFO]
It would be nice to suppress cleaning target a second 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] Updated: (MCHECKSTYLE-90) Checkstyle-2.2-SNAPSHOT not working with Maven 2.0.9
[
http://jira.codehaus.org/browse/MCHECKSTYLE-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MCHECKSTYLE-90:
-
Attachment: dependency-order.patch
bq. Why on earth does commons-collections 2.0 win here, when 2.1 is newer
The [Introduction to the Dependency
Mechanism|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html]
states that for dependencies, that occur at the same depth, the one that is
encountered first wins. Versions are not considered.
For the Checkstyle plugin, the relevant parts of the current dep tree are
{noformat}
[INFO]
org.apache.maven.plugins:maven-checkstyle-plugin:maven-plugin:2.2-SNAPSHOT
[INFO] +- org.codehaus.plexus:plexus-velocity:jar:1.1.2:compile
[INFO] | +- commons-collections:commons-collections:jar:2.0:compile
[INFO] +- checkstyle:checkstyle:jar:4.4:compile
[INFO] | +- commons-collections:commons-collections:jar:2.1:compile
{noformat}
That is commons-collections:2.0 is introduced first by plexus-velocity and
hence wins. Simply putting the dependency on checkstyle before plexus-velocity
in the POM should fix it (see patch).
> Checkstyle-2.2-SNAPSHOT not working with Maven 2.0.9
>
>
> Key: MCHECKSTYLE-90
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-90
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Ricky Hazelwood
> Attachments: checkstyle-bug.zip, dependency-order.patch
>
>
> The changes in Maven 2.0.9 is causing the plugin to use commons-collection
> 2.0 instead of 2.1 required by checkstyle. Forcing the commons-collection
> version 2.1 in the plugin config fixes this issue.
> [INFO] [checkstyle:checkstyle]
> [FATAL ERROR] org.apache.maven.plugin.checkstyle.CheckstyleReport#execute()
> caused a linkage error (java.lang.NoClassDefFoundError) and may be
> out-of-date. Check the realms:
> [FATAL ERROR] Plugin realm =
> app0.child-container[org.apache.maven.plugins:maven-checkstyle-plugin]
> urls[0] =
> file:/D:/maven2/repository/org/apache/maven/plugins/maven-checkstyle-plugin/2.2-SNAPSHOT/maven-checkstyle-plugin-2.2-SNAPSHOT.jar
> urls[1] =
> file:/D:/maven2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> urls[2] =
> file:/D:/maven2/repository/org/apache/maven/reporting/maven-reporting-impl/2.0/maven-reporting-impl-2.0.jar
> urls[3] =
> file:/D:/maven2/repository/commons-validator/commons-validator/1.1.4/commons-validator-1.1.4.jar
> urls[4] = file:/D:/maven2/repository/oro/oro/2.0.7/oro-2.0.7.jar
> urls[5] =
> file:/D:/maven2/repository/doxia/doxia-core/1.0-alpha-4/doxia-core-1.0-alpha-4.jar
> urls[6] =
> file:/D:/maven2/repository/org/codehaus/plexus/plexus-resources/1.0-alpha-4/plexus-resources-1.0-alpha-4.jar
> urls[7] =
> file:/D:/maven2/repository/org/codehaus/plexus/plexus-velocity/1.1.2/plexus-velocity-1.1.2.jar
> urls[8] =
> file:/D:/maven2/repository/commons-collections/commons-collections/2.0/commons-collections-2.0.jar
> urls[9] =
> file:/D:/maven2/repository/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar
> urls[10] = file:/D:/maven2/repository/velocity/velocity/1.4/velocity-1.4.jar
> urls[11] =
> file:/D:/maven2/repository/velocity/velocity-dep/1.4/velocity-dep-1.4.jar
> urls[12] =
> file:/D:/maven2/repository/checkstyle/checkstyle/4.4/checkstyle-4.4.jar
> urls[13] = file:/D:/maven2/repository/antlr/antlr/2.7.6/antlr-2.7.6.jar
> urls[14] =
> file:/D:/maven2/repository/commons-beanutils/commons-beanutils-core/1.7.0/commons-beanutils-core-1.7.0.jar
> urls[15] =
> file:/D:/maven2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar
> urls[16] =
> file:/D:/maven2/repository/checkstyle/checkstyle-optional/4.4/checkstyle-optional-4.4.jar
> [FATAL ERROR] Container realm = plexus.core
> urls[0] = file:/C:/Program Files/Java/maven/lib/maven-2.0.9-uber.jar
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] org/apache/commons/collections/ReferenceMap
> org.apache.commons.collections.ReferenceMap
> [INFO]
>
> [INFO] Trace
> java.lang.NoClassDefFoundError: org/apache/commons/collections/ReferenceMap
> at
> com.puppycrawl.tools.checkstyle.checks.duplicates.StrictDuplicateCodeCheck.(StrictDuplicateCodeCheck.java:191)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Cons
[jira] Commented: (MIDEA-102) Module filepath is generated incorrectly for sibling parent
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131034#action_131034 ] Dennis Lundberg commented on MIDEA-102: --- The tests currently fail in Linux/Unix environments. I need to try and fix that before I can make the release. > Module filepath is generated incorrectly for sibling parent > --- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- 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: (MECLIPSE-427) .springBeans definition throws NullPointer if BaseDir does not exist
[
http://jira.codehaus.org/browse/MECLIPSE-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MECLIPSE-427:
-
Attachment: (was: MyEclipseSpringBeansWriter.java)
> .springBeans definition throws NullPointer if BaseDir does not exist
>
>
> Key: MECLIPSE-427
> URL: http://jira.codehaus.org/browse/MECLIPSE-427
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: MyEclipse support
>Affects Versions: 2.5, 2.5.1
>Reporter: Joe Freeman
>
> This is related to the fix submitted for MECLIPSE-359
> We have an application with 40 eclipse projects in it. About half of them
> have spring beans and 1/2 don't. The top level pom describes how the eclipse
> plugin should function and includes the Spring configuration component for
> the myeclipse target. A null pointer is thrown when running
> eclipse:myeclipse when the base dir doesn't exist, in our case in one of the
> projects that doesn't have any spring components. Our pom.xml fragment looks
> like
>
> 2.0
> *.xml
> src/main/resources/conf
>
> The exception stack trace looks like
> java.lang.NullPointerException
> at
> org.apache.maven.plugin.eclipse.writers.myeclipse.MyEclipseSpringBeansWriter.getConfigurationFilesList(MyEclipseSpringBeansWriter.java:142)
> at
> org.apache.maven.plugin.eclipse.writers.myeclipse.MyEclipseSpringBeansWriter.write(MyEclipseSpringBeansWriter.java:93)
> The following code block with the problem throws NullPointer when
> directory.listFiles() returns a null into subdirs. Wrap the for() loop in a
> nullcheck
>try
> {
> File directory = new File( basedir );
> File[] subdirs = directory.listFiles( new FileFilter()
> {
> public boolean accept( File pathname )
> {
> return pathname.isDirectory();
> }
> } );
> for ( int i = 0; i < subdirs.length; i++ )
> {
> configFiles.addAll( getConfigurationFilesList(
> subdirs[i].getPath(), pattern ) );
> }
> configFiles.addAll( FileUtils.getFileNames( directory, pattern,
> null, true ) );
> }
> Testing:
> Take one of the test cases and remove the directory that is pointed to by the
> basedir attribute.
--
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: (MECLIPSE-427) .springBeans definition throws NullPointer if BaseDir does not exist
[
http://jira.codehaus.org/browse/MECLIPSE-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MECLIPSE-427:
-
Attachment: (was: MyEclipseSpringBeansWriter.java)
> .springBeans definition throws NullPointer if BaseDir does not exist
>
>
> Key: MECLIPSE-427
> URL: http://jira.codehaus.org/browse/MECLIPSE-427
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: MyEclipse support
>Affects Versions: 2.5, 2.5.1
>Reporter: Joe Freeman
>
> This is related to the fix submitted for MECLIPSE-359
> We have an application with 40 eclipse projects in it. About half of them
> have spring beans and 1/2 don't. The top level pom describes how the eclipse
> plugin should function and includes the Spring configuration component for
> the myeclipse target. A null pointer is thrown when running
> eclipse:myeclipse when the base dir doesn't exist, in our case in one of the
> projects that doesn't have any spring components. Our pom.xml fragment looks
> like
>
> 2.0
> *.xml
> src/main/resources/conf
>
> The exception stack trace looks like
> java.lang.NullPointerException
> at
> org.apache.maven.plugin.eclipse.writers.myeclipse.MyEclipseSpringBeansWriter.getConfigurationFilesList(MyEclipseSpringBeansWriter.java:142)
> at
> org.apache.maven.plugin.eclipse.writers.myeclipse.MyEclipseSpringBeansWriter.write(MyEclipseSpringBeansWriter.java:93)
> The following code block with the problem throws NullPointer when
> directory.listFiles() returns a null into subdirs. Wrap the for() loop in a
> nullcheck
>try
> {
> File directory = new File( basedir );
> File[] subdirs = directory.listFiles( new FileFilter()
> {
> public boolean accept( File pathname )
> {
> return pathname.isDirectory();
> }
> } );
> for ( int i = 0; i < subdirs.length; i++ )
> {
> configFiles.addAll( getConfigurationFilesList(
> subdirs[i].getPath(), pattern ) );
> }
> configFiles.addAll( FileUtils.getFileNames( directory, pattern,
> null, true ) );
> }
> Testing:
> Take one of the test cases and remove the directory that is pointed to by the
> basedir attribute.
--
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: (MCHECKSTYLE-90) Checkstyle-2.2-SNAPSHOT not working with Maven 2.0.9
[ http://jira.codehaus.org/browse/MCHECKSTYLE-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHECKSTYLE-90. -- Assignee: Dennis Lundberg Resolution: Fixed Fix Version/s: 2.2 Changing the order of the dependencies unfortunately didn't make any difference. So I went in and excluded the commons-collections:2.0 dependency from plexus-velocity. A new 2.2-SNAPSHOT has been deployed. Please verify that it solves your problems. > Checkstyle-2.2-SNAPSHOT not working with Maven 2.0.9 > > > Key: MCHECKSTYLE-90 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-90 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ricky Hazelwood >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: checkstyle-bug.zip, dependency-order.patch > > > The changes in Maven 2.0.9 is causing the plugin to use commons-collection > 2.0 instead of 2.1 required by checkstyle. Forcing the commons-collection > version 2.1 in the plugin config fixes this issue. > [INFO] [checkstyle:checkstyle] > [FATAL ERROR] org.apache.maven.plugin.checkstyle.CheckstyleReport#execute() > caused a linkage error (java.lang.NoClassDefFoundError) and may be > out-of-date. Check the realms: > [FATAL ERROR] Plugin realm = > app0.child-container[org.apache.maven.plugins:maven-checkstyle-plugin] > urls[0] = > file:/D:/maven2/repository/org/apache/maven/plugins/maven-checkstyle-plugin/2.2-SNAPSHOT/maven-checkstyle-plugin-2.2-SNAPSHOT.jar > urls[1] = > file:/D:/maven2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar > urls[2] = > file:/D:/maven2/repository/org/apache/maven/reporting/maven-reporting-impl/2.0/maven-reporting-impl-2.0.jar > urls[3] = > file:/D:/maven2/repository/commons-validator/commons-validator/1.1.4/commons-validator-1.1.4.jar > urls[4] = file:/D:/maven2/repository/oro/oro/2.0.7/oro-2.0.7.jar > urls[5] = > file:/D:/maven2/repository/doxia/doxia-core/1.0-alpha-4/doxia-core-1.0-alpha-4.jar > urls[6] = > file:/D:/maven2/repository/org/codehaus/plexus/plexus-resources/1.0-alpha-4/plexus-resources-1.0-alpha-4.jar > urls[7] = > file:/D:/maven2/repository/org/codehaus/plexus/plexus-velocity/1.1.2/plexus-velocity-1.1.2.jar > urls[8] = > file:/D:/maven2/repository/commons-collections/commons-collections/2.0/commons-collections-2.0.jar > urls[9] = > file:/D:/maven2/repository/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar > urls[10] = file:/D:/maven2/repository/velocity/velocity/1.4/velocity-1.4.jar > urls[11] = > file:/D:/maven2/repository/velocity/velocity-dep/1.4/velocity-dep-1.4.jar > urls[12] = > file:/D:/maven2/repository/checkstyle/checkstyle/4.4/checkstyle-4.4.jar > urls[13] = file:/D:/maven2/repository/antlr/antlr/2.7.6/antlr-2.7.6.jar > urls[14] = > file:/D:/maven2/repository/commons-beanutils/commons-beanutils-core/1.7.0/commons-beanutils-core-1.7.0.jar > urls[15] = > file:/D:/maven2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar > urls[16] = > file:/D:/maven2/repository/checkstyle/checkstyle-optional/4.4/checkstyle-optional-4.4.jar > [FATAL ERROR] Container realm = plexus.core > urls[0] = file:/C:/Program Files/Java/maven/lib/maven-2.0.9-uber.jar > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] org/apache/commons/collections/ReferenceMap > org.apache.commons.collections.ReferenceMap > [INFO] > > [INFO] Trace > java.lang.NoClassDefFoundError: org/apache/commons/collections/ReferenceMap > at > com.puppycrawl.tools.checkstyle.checks.duplicates.StrictDuplicateCodeCheck.(StrictDuplicateCodeCheck.java:191) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at java.lang.Class.newInstance0(Class.java:355) > at java.lang.Class.newInstance(Class.java:308) > at > com.puppycrawl.tools.checkstyle.PackageObjectFactory.createObject(PackageObjectFactory.java:110) > at > com.puppycrawl.tools.checkstyle.PackageObjectFactory.doMakeObject(PackageObjectFactory.java:87) > at > com.puppycrawl.tools.checkstyle.PackageObjectFactory.createModule(PackageObjectFactory.java:149) > at com.puppycrawl.tools.checkstyle.Checker.setupChild(Checker.java:140) > at > com.puppycrawl.tools.chec
[jira] Commented: (MSITE-159) Absolute URI rendered as relative URI if absolute URI related to domain of POM URI
[ http://jira.codehaus.org/browse/MSITE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131051#action_131051 ] Paul Davis commented on MSITE-159: -- Best would be an option to specify. ESPECIALLY for external links. External links should never get converted to relative links, which appears to happen arbitrarily. > Absolute URI rendered as relative URI if absolute URI related to domain of > POM URI > -- > > Key: MSITE-159 > URL: http://jira.codehaus.org/browse/MSITE-159 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: relative links >Reporter: Ted Husted > > Under site-beta5 > if the POM references a URI like > http://struts.apache.org > absolute URLs used in the site.xml file are converted to relative references. > For example a reference to to "http://struts.apache.org/1.x"; becomes "1.x", > and a reference to > just "http://struts.apache.org"; becomes an empty string. > If the documentation is being used offline, there are many cases when we want > to refer people back to the website, to be sure the current information is > used. The best use case is a download page that determines the mirror via > CGI. > Another use case is referring to a sister site in the domain, that might > refer to another version. If used locally, the other site might not be in the > relative location. > Switching back to beta4 cures the behavior, and absolute URIs remain > absolute, as expected. -- 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: (MCHECKSTYLE-90) Checkstyle-2.2-SNAPSHOT not working with Maven 2.0.9
[ http://jira.codehaus.org/browse/MCHECKSTYLE-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131053#action_131053 ] Ricky Hazelwood commented on MCHECKSTYLE-90: Dennis, the new snapshot has solved the issue. Thanks. > Checkstyle-2.2-SNAPSHOT not working with Maven 2.0.9 > > > Key: MCHECKSTYLE-90 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-90 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ricky Hazelwood >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: checkstyle-bug.zip, dependency-order.patch > > > The changes in Maven 2.0.9 is causing the plugin to use commons-collection > 2.0 instead of 2.1 required by checkstyle. Forcing the commons-collection > version 2.1 in the plugin config fixes this issue. > [INFO] [checkstyle:checkstyle] > [FATAL ERROR] org.apache.maven.plugin.checkstyle.CheckstyleReport#execute() > caused a linkage error (java.lang.NoClassDefFoundError) and may be > out-of-date. Check the realms: > [FATAL ERROR] Plugin realm = > app0.child-container[org.apache.maven.plugins:maven-checkstyle-plugin] > urls[0] = > file:/D:/maven2/repository/org/apache/maven/plugins/maven-checkstyle-plugin/2.2-SNAPSHOT/maven-checkstyle-plugin-2.2-SNAPSHOT.jar > urls[1] = > file:/D:/maven2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar > urls[2] = > file:/D:/maven2/repository/org/apache/maven/reporting/maven-reporting-impl/2.0/maven-reporting-impl-2.0.jar > urls[3] = > file:/D:/maven2/repository/commons-validator/commons-validator/1.1.4/commons-validator-1.1.4.jar > urls[4] = file:/D:/maven2/repository/oro/oro/2.0.7/oro-2.0.7.jar > urls[5] = > file:/D:/maven2/repository/doxia/doxia-core/1.0-alpha-4/doxia-core-1.0-alpha-4.jar > urls[6] = > file:/D:/maven2/repository/org/codehaus/plexus/plexus-resources/1.0-alpha-4/plexus-resources-1.0-alpha-4.jar > urls[7] = > file:/D:/maven2/repository/org/codehaus/plexus/plexus-velocity/1.1.2/plexus-velocity-1.1.2.jar > urls[8] = > file:/D:/maven2/repository/commons-collections/commons-collections/2.0/commons-collections-2.0.jar > urls[9] = > file:/D:/maven2/repository/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar > urls[10] = file:/D:/maven2/repository/velocity/velocity/1.4/velocity-1.4.jar > urls[11] = > file:/D:/maven2/repository/velocity/velocity-dep/1.4/velocity-dep-1.4.jar > urls[12] = > file:/D:/maven2/repository/checkstyle/checkstyle/4.4/checkstyle-4.4.jar > urls[13] = file:/D:/maven2/repository/antlr/antlr/2.7.6/antlr-2.7.6.jar > urls[14] = > file:/D:/maven2/repository/commons-beanutils/commons-beanutils-core/1.7.0/commons-beanutils-core-1.7.0.jar > urls[15] = > file:/D:/maven2/repository/commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.jar > urls[16] = > file:/D:/maven2/repository/checkstyle/checkstyle-optional/4.4/checkstyle-optional-4.4.jar > [FATAL ERROR] Container realm = plexus.core > urls[0] = file:/C:/Program Files/Java/maven/lib/maven-2.0.9-uber.jar > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] org/apache/commons/collections/ReferenceMap > org.apache.commons.collections.ReferenceMap > [INFO] > > [INFO] Trace > java.lang.NoClassDefFoundError: org/apache/commons/collections/ReferenceMap > at > com.puppycrawl.tools.checkstyle.checks.duplicates.StrictDuplicateCodeCheck.(StrictDuplicateCodeCheck.java:191) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at java.lang.Class.newInstance0(Class.java:355) > at java.lang.Class.newInstance(Class.java:308) > at > com.puppycrawl.tools.checkstyle.PackageObjectFactory.createObject(PackageObjectFactory.java:110) > at > com.puppycrawl.tools.checkstyle.PackageObjectFactory.doMakeObject(PackageObjectFactory.java:87) > at > com.puppycrawl.tools.checkstyle.PackageObjectFactory.createModule(PackageObjectFactory.java:149) > at com.puppycrawl.tools.checkstyle.Checker.setupChild(Checker.java:140) > at > com.puppycrawl.tools.checkstyle.api.AutomaticBean.configure(AutomaticBean.java:208) > at > org.apache.maven.plugin.checkstyle.CheckstyleReport.executeCheckstyle(CheckstyleReport.java:870) > at > org.apache.maven.plugin.checkstyle.Checkstyle
[jira] Commented: (MASSEMBLY-311) Empty outputFileNameMapping creates zip entries with no name
[
http://jira.codehaus.org/browse/MASSEMBLY-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131055#action_131055
]
Dirk Olmes commented on MASSEMBLY-311:
--
If you're talking about regular dependencies I agree with you that specifying
an empty filename mapping could behave like this.
However, in the very special case of a system scoped dependency I would have
expected that the filename is left alone, resulting in a plain copy of the
dependency as is. How do I achieve this?
> Empty outputFileNameMapping creates zip entries with no name
>
>
> Key: MASSEMBLY-311
> URL: http://jira.codehaus.org/browse/MASSEMBLY-311
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: Maven 2.0.9
>Reporter: Dirk Olmes
>Priority: Trivial
> Attachments: assembly-with-system-dependency.zip
>
>
> I'm working on a project that has system dependencies. I want to package
> those dependencies with their original name into the assembly (i.e. use the
> same name of the JAR as in the system path).
> Leaving the outputFileNameMapping in the assembly descriptor's dependencySet
> creates ZipEntries in the resulting zip file but those don't have a name.
> Example:
> {code}
> unzip -qql target/assembly.zip
> 0 04-16-08 16:20 assembly/
> 2205737 04-07-08 18:23 assembly/lib/
>2621 04-16-08 16:20 assembly/lib/
> {code}
> Note the second line ...
> I have attached a sample project that uses Maven's uber Jar as system scope
> dependency. Run the test with mvn -DMAVEN_HOME= package assembly:assembly
> to create the zip.
--
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: (MJAVADOC-157) Javadoc for multi-module build executes full lifecycle for each module
[
http://jira.codehaus.org/browse/MJAVADOC-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Olmes closed MJAVADOC-157.
---
Resolution: Fixed
Fix Version/s: 2.4
Looks like this issue was fixed with version 2.4
> Javadoc for multi-module build executes full lifecycle for each module
> --
>
> Key: MJAVADOC-157
> URL: http://jira.codehaus.org/browse/MJAVADOC-157
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: jdk 1.4.2_16, linux
>Reporter: Dirk Olmes
>Priority: Critical
> Fix For: 2.4
>
> Attachments: three-level.zip
>
>
> We have a build that nests modules three levels deep. When generating
> javadoc, for each module the whole lifecylcle is repeated.
> Sample log:
> {code}
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] Toplevel
> [INFO] Second level: foo
> [INFO] mule-foo-foo1
> [INFO] Second level: bar
> [INFO] mule-bar-bar1
> [INFO]
>
> [INFO] Building Toplevel
> [INFO]task-segment: [clean, site]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Preparing javadoc:javadoc
> [INFO]
>
> [INFO] Building Toplevel
> [INFO]
>
> [INFO] No goals needed for project - skipping
> [INFO]
>
> [INFO] Building Second level: foo
> [INFO]
>
> [INFO] No goals needed for project - skipping
> [INFO]
>
> [INFO] Building mule-foo-foo1
> [INFO]
>
> [INFO] No goals needed for project - skipping
> [INFO]
>
> [INFO] Building Second level: bar
> [INFO]
>
> [INFO] No goals needed for project - skipping
> [INFO]
>
> [INFO] Building mule-bar-bar1
> [INFO]
>
> [INFO] No goals needed for project - skipping
> [INFO] Preparing javadoc:test-javadoc
> [INFO]
>
> [INFO] Building Toplevel
> [INFO]
>
> [INFO] No goals needed for project - skipping
> [INFO]
>
> [INFO] Building Second level: foo
> [INFO]
>
> [INFO] No goals needed for project - skipping
> [INFO]
>
> [INFO] Building mule-foo-foo1
> [INFO]
>
> [INFO] No goals needed for project - skipping
> [INFO]
>
> [INFO] Building Second level: bar
> [INFO]
>
> [INFO] No goals needed for project - skipping
> [INFO]
>
> [INFO] Building mule-bar-bar1
> [INFO]
>
> [INFO] No goals needed for project - skipping
> [INFO] [site:site]
> [INFO]
>
> [INFO] Building Second level: foo
> [INFO]task-segment: [clean, site]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Preparing javadoc:javadoc
> [INFO]
>
> [INFO] Building Toplevel
> [INFO]
>
> [INFO] No goals needed for project - skipping
> [INFO]
>
> [INFO] Building Second level: foo
> [INFO]
>
> [INFO] No goals needed for project - skipping
> [INFO]
> -
[jira] Created: (WAGON-109) Refactor Wagon HTTP and Wagon WebDav
Refactor Wagon HTTP and Wagon WebDav Key: WAGON-109 URL: http://jira.codehaus.org/browse/WAGON-109 Project: wagon Issue Type: Improvement Components: wagon-http, wagon-webdav Reporter: James William Dumay Attachments: webdav-http-dav-refactor.patch This patch includes the following: * Webdav wagon is now using Jackrabbits webdav client implementation over the Apache Slide client library (now defunct) * Inclusion of a commons HttpClient abstract wagon for code reuse between Wagon Http and Wagon Dav. * Improved consistency of http parameters across Wagon HTTP and Wagon Webdav methods -- 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: (WAGON-99) Make webdav support automatic
[ http://jira.codehaus.org/browse/WAGON-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James William Dumay closed WAGON-99. Resolution: Fixed Webdav support is included in Maven as of 2.0.9 > Make webdav support automatic > - > > Key: WAGON-99 > URL: http://jira.codehaus.org/browse/WAGON-99 > Project: wagon > Issue Type: Improvement > Components: wagon-webdav >Reporter: Paul Gier > > It would be helpful if projects could be deployed over webdav without > requiring the build extensions. > What is the reason why the deploy plugin can't automatically use webdav? -- 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: (WAGON-74) WebDav component references non-existant jetty pom and fails to install into maven when building.
[ http://jira.codehaus.org/browse/WAGON-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131077#action_131077 ] James William Dumay commented on WAGON-74: -- You can use plain HTTP to deploy to Archiva instead of Webdav. > WebDav component references non-existant jetty pom and fails to install into > maven when building. > - > > Key: WAGON-74 > URL: http://jira.codehaus.org/browse/WAGON-74 > Project: wagon > Issue Type: Bug > Components: wagon-webdav >Affects Versions: 1.0-beta-2 > Environment: Maven 2.0.5 >Reporter: Derek Clarkson >Priority: Blocker > > When attempt to deploy using the webdav to a local Archiva repository I get > the message: > Protocol [dav] is unsupported by the current configuration. > Turning on debug I see at the top of the log: > [DEBUG] Artifact not found - using stub model: Unable to download the > artifact from any repository > org.mortbay.jetty:jetty:pom:4.2.12 > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > aegeon-proxy (http://192.168.0.91:/proxy/aegeon) > Looking inside the repo1.maven.org/maven2 repository I can see that the > directory exists for jetty 4.2.12 but there is no pom in it. My build pom > makes reference to the following extension: > > > org.apache.maven.wagon > wagon-webdav > 1.0-beta-2 > > > Please suggest a fix as this is blocking our development because we cannot > deploy to our local Archiva server. > ciao > Derek -- 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: (WAGON-109) Refactor Wagon HTTP and Wagon WebDav
[ http://jira.codehaus.org/browse/WAGON-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James William Dumay updated WAGON-109: -- Attachment: webdav-http-dav-refactor.patch > Refactor Wagon HTTP and Wagon WebDav > > > Key: WAGON-109 > URL: http://jira.codehaus.org/browse/WAGON-109 > Project: wagon > Issue Type: Improvement > Components: wagon-http, wagon-webdav >Reporter: James William Dumay > Attachments: webdav-http-dav-refactor.patch, > webdav-http-dav-refactor.patch > > > This patch includes the following: > * Webdav wagon is now using Jackrabbits webdav client implementation over the > Apache Slide client library (now defunct) > * Inclusion of a commons HttpClient abstract wagon for code reuse between > Wagon Http and Wagon Dav. > * Improved consistency of http parameters across Wagon HTTP and Wagon Webdav > methods -- 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: (WAGON-93) Cannot deploy with using webdav: 409 error
[ http://jira.codehaus.org/browse/WAGON-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131078#action_131078 ] James William Dumay commented on WAGON-93: -- As of Maven 2.0.9, wagon-webdav is included and there is no need to define the wagon extension in your POM. > Cannot deploy with using webdav: 409 error > -- > > Key: WAGON-93 > URL: http://jira.codehaus.org/browse/WAGON-93 > Project: wagon > Issue Type: Bug > Components: wagon-webdav >Affects Versions: 1.0-beta-2 > Environment: maven 2.0.8, linux, java: 1.6.0.1 >Reporter: Alexey Kakunin >Priority: Critical > > I added followed lines into our project pom.xml: > > > emforge.repo > EmForge Repository > > dav:http://svn.emforge.org/svn/emforge/mvnrepo > > > > > > org.apache.maven.wagon > wagon-webdav > 1.0-beta-2 > > > > but - during performing mvn deploy it deployed file into server and then > returns 409 error. > Also - I tried solution, proposed in > http://docs.codehaus.org/display/MAVENUSER/Deploying+3rd+Party+Jars+With+WebDAV > - but it did not help - same error :( > Is it possible to use webdav in maven out-of-the box - without any triks with > copying libraries and so on? -- 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: (WAGON-109) Refactor Wagon HTTP and Wagon WebDav
[ http://jira.codehaus.org/browse/WAGON-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James William Dumay updated WAGON-109: -- Attachment: webdav-http-dav-refactor.patch > Refactor Wagon HTTP and Wagon WebDav > > > Key: WAGON-109 > URL: http://jira.codehaus.org/browse/WAGON-109 > Project: wagon > Issue Type: Improvement > Components: wagon-http, wagon-webdav >Reporter: James William Dumay > Attachments: webdav-http-dav-refactor.patch, > webdav-http-dav-refactor.patch, webdav-http-dav-refactor.patch > > > This patch includes the following: > * Webdav wagon is now using Jackrabbits webdav client implementation over the > Apache Slide client library (now defunct) > * Inclusion of a commons HttpClient abstract wagon for code reuse between > Wagon Http and Wagon Dav. > * Improved consistency of http parameters across Wagon HTTP and Wagon Webdav > methods -- 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-2205) "provided" scope dependencies must be transitive
[ http://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131081#action_131081 ] Bugittaa Pahasti commented on MNG-2205: --- I think distinguishing packaging and compiling would make sense here. I use compile scope as an example: - for direct dependencies it's clear that they are included in you compile time classpath and also included when packaged to a war for example. - for transitive dependencies, it's clear they should be packaged but the question is if they should be included in the compile time classpath. Ok, let's have an example: *1. Current behavior:* A -> B (compile) -> C (compile) A -> B (compile) -> D (provided) C: included in A's compile classpath, included in packaging D: not included in A's compile classpath, not packaged *2. Requested in this issue:* A -> B (compile) -> C (compile) A -> B (compile) -> D (provided) C: included in A's compile classpath, included in packaging D: *included* in A's compile classpath, not packaged *3. Preferable solution in my opinion:* A -> B (compile) -> C (compile) A -> B (compile) -> D (provided) C: *not included* in A's compile classpath, included in packaging D: not included in A's compile classpath, not packaged If I remember correctly there were some talk in the mailing list that maven 2.1 would implement option 3, but I might remember wrong. > "provided" scope dependencies must be transitive > > > Key: MNG-2205 > URL: http://jira.codehaus.org/browse/MNG-2205 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Reporter: David Boden >Priority: Critical > Fix For: 2.1 > > > A provided scope dependency can also be thought of as "compile-only". > Project A requires Sybase JConnect on the runtime classpath. Project A > declares a "provided" dependency on Sybase JConnect. > Project B depends upon Project A. Project B declares a "compile" dependency > on Project A. > Project C depends upon Project B. Project C declares a "compile" dependency > on Project B. > C > | - compile dependency > B > | - compile dependency > A > | - provided dependency > Sybase JConnect > So, does Project C transitively depend on Sybase JConnect. Yes, of course! > The "provided" dependency needs to be transitive. > Ultimately, when Project C gets deployed, Sybase JConnect needs to be > somewhere on the runtime classpath in order for the application to function. > It's valid for Project C to assume that Sybase JConnect is available and use > JDBC all over the Project C code. Project C is safe to do this because it can > happily deduce that Sybase JConnect will be there in the runtime environment > because Project A NEEDS IT. > I've got Use Cases all over my aggregated build which make it absolutely > critical and common sense that provided scope dependencies are transitive. > For the (very rare) odd case where you don't want to inherit provided > dependencies, you can them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-2205) "provided" scope dependencies must be transitive
[ http://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131081#action_131081 ] bugittaa edited comment on MNG-2205 at 4/17/08 1:55 AM: I think distinguishing packaging and compiling would make sense here. I use compile scope as an example: - for direct dependencies it's clear that they are included in you compile time classpath and also included when packaged to a war for example. - for transitive dependencies, it's clear they should be packaged but the question is if they should be included in the compile time classpath. Ok, let's have an example: *1. Current behavior:* A -> B (compile) -> C (compile) A -> B (compile) -> D (provided) C: included in A's compile classpath, included in packaging D: not included in A's compile classpath, not packaged *2. Requested in this issue:* A -> B (compile) -> C (compile) A -> B (compile) -> D (provided) C: included in A's compile classpath, included in packaging D: *included* in A's compile classpath, not packaged *3. Preferable solution in my opinion:* A -> B (compile) -> C (compile) A -> B (compile) -> D (provided) C: *not included* in A's compile classpath, included in packaging D: not included in A's compile classpath, not packaged If I remember correctly there were some talk in the mailing list that maven 2.1 would implement option 3, but I might remember wrong. edit: this seem to be bit more complicated than that: how about classpath for compiling and running tests etc. As a quick thought, classpath for compiling tests could be just the direct dependencies and for running tests same as for packaging (but how about transitive test dependencies)? was (Author: bugittaa): I think distinguishing packaging and compiling would make sense here. I use compile scope as an example: - for direct dependencies it's clear that they are included in you compile time classpath and also included when packaged to a war for example. - for transitive dependencies, it's clear they should be packaged but the question is if they should be included in the compile time classpath. Ok, let's have an example: *1. Current behavior:* A -> B (compile) -> C (compile) A -> B (compile) -> D (provided) C: included in A's compile classpath, included in packaging D: not included in A's compile classpath, not packaged *2. Requested in this issue:* A -> B (compile) -> C (compile) A -> B (compile) -> D (provided) C: included in A's compile classpath, included in packaging D: *included* in A's compile classpath, not packaged *3. Preferable solution in my opinion:* A -> B (compile) -> C (compile) A -> B (compile) -> D (provided) C: *not included* in A's compile classpath, included in packaging D: not included in A's compile classpath, not packaged If I remember correctly there were some talk in the mailing list that maven 2.1 would implement option 3, but I might remember wrong. > "provided" scope dependencies must be transitive > > > Key: MNG-2205 > URL: http://jira.codehaus.org/browse/MNG-2205 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Reporter: David Boden >Priority: Critical > Fix For: 2.1 > > > A provided scope dependency can also be thought of as "compile-only". > Project A requires Sybase JConnect on the runtime classpath. Project A > declares a "provided" dependency on Sybase JConnect. > Project B depends upon Project A. Project B declares a "compile" dependency > on Project A. > Project C depends upon Project B. Project C declares a "compile" dependency > on Project B. > C > | - compile dependency > B > | - compile dependency > A > | - provided dependency > Sybase JConnect > So, does Project C transitively depend on Sybase JConnect. Yes, of course! > The "provided" dependency needs to be transitive. > Ultimately, when Project C gets deployed, Sybase JConnect needs to be > somewhere on the runtime classpath in order for the application to function. > It's valid for Project C to assume that Sybase JConnect is available and use > JDBC all over the Project C code. Project C is safe to do this because it can > happily deduce that Sybase JConnect will be there in the runtime environment > because Project A NEEDS IT. > I've got Use Cases all over my aggregated build which make it absolutely > critical and common sense that provided scope dependencies are transitive. > For the (very rare) odd case where you don't want to inherit provided > dependencies, you can them. -- 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
