[maven2 build trunk - SUCCESS - update] Sat Mar 4 07:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060304.073001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060304.073001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MJAVADOC-47) Javadoc plugin ignores destDir when used in reporting section
[ http://jira.codehaus.org/browse/MJAVADOC-47?page=all ]
Allan Ramirez closed MJAVADOC-47:
-
Resolution: Fixed
Applied Patch. Thanks
> Javadoc plugin ignores destDir when used in reporting section
> -
>
> Key: MJAVADOC-47
> URL: http://jira.codehaus.org/browse/MJAVADOC-47
> Project: Maven 2.x Javadoc Plugin
> Type: Bug
> Reporter: Wendy Smoak
> Assignee: Maria Odea Ching
> Fix For: 2.0-beta-4
> Attachments: MJAVADOC-47-maven-javadoc-plugin.patch
>
>
> When used in the reporting section of the pom and 'mvn site', output always
> goes to target/apidocs, even if you specify an outputDir.
> Having outputDir work correctly would by useful with alternate doclets, for
> example sending the output of the UMLGraph doclet to target/uml so that it
> can be further transformed.
> This seems to be the code that's doing it:
> if ( !javadocDirectory.getAbsolutePath().equals( getOutputDirectory()
> ) )
> {
> // we're in site-embedded report mode, so Doxia has set the
> // reportOutputDirectory to the basedir of the site.
> // Append 'apidocs'.
> javadocDirectory = new File( javadocDirectory, "apidocs" );
> }
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MSUREFIRE-51) Add a configuration element which allows artifact exclusions
[ http://jira.codehaus.org/browse/MSUREFIRE-51?page=all ] Brett Porter closed MSUREFIRE-51: - Assign To: Brett Porter Resolution: Won't Fix this was a problem in cobertura, which has been fixed. > Add a configuration element which allows artifact exclusions > > > Key: MSUREFIRE-51 > URL: http://jira.codehaus.org/browse/MSUREFIRE-51 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Jason van Zyl > Assignee: Brett Porter > > > Taken from the message on the users mailing list: > This smells like a scoping problem. ASM is not required for test execution > (runtime) by Cobertura, ASM is only needed for swizzling the class files and > that part is run during the process-classes phase. Cobertura itself needs it > to compile and to instrument but ASM shouldn't end up in the test or runtime > scopes/classpaths. I think this points to a tool scope or something akin to > it. > If that proves to be the case it's probably not going to be fixed for 2.0.3. > A solution might be to add an artifact exclusion configuration to surefire > (possibly only for forking mode). Then the lifecycle.xml for the Cobertura > plug-in which controls the execution of surefire could exclude ASM during > test runs. That could probably make it into the surefire plug-in's next > release if that solution works. That's all I can think of off the top of my > head. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MSUREFIRE-59) JUnitBattery dies when TestSuite has an anonymous inner class
[ http://jira.codehaus.org/browse/MSUREFIRE-59?page=all ]
Brett Porter closed MSUREFIRE-59:
-
Assign To: Brett Porter
Resolution: Fixed
This may have been fixed in 2.1.3. I can't reproduce using the supplied class
under iether 2.1.3 or 2.2
> JUnitBattery dies when TestSuite has an anonymous inner class
> -
>
> Key: MSUREFIRE-59
> URL: http://jira.codehaus.org/browse/MSUREFIRE-59
> Project: Maven 2.x Surefire Plugin
> Type: Bug
> Versions: 2.1.2
> Reporter: Mike Perham
> Assignee: Brett Porter
> Fix For: 2.1.3
> Attachments: SimpleTestSuite.java
>
>
> I have this method in my test suite:
> {code}
> private static File[] getWSDLFiles() {
> URL directoryURL =
> WSDLImportTestSuite.class.getResource("/com/webify/wsf/studio/core/wsdl/wsdls");
> if (directoryURL != null) {
> File directory = new File(directoryURL.getPath());
> FilenameFilter filter = new FilenameFilter() {
> public boolean accept(File dir, String name) {
> return name.endsWith(".wsdl");
> }
> };
> return directory.listFiles(filter);
> }
> else {
> return null;
> }
> }
> {code}
> And surefire fails with this exception:
> java.lang.NoSuchMethodException:
> com.webify.wsf.studio.core.wsdl.WSDLImportTestSuite$1.()
> at java.lang.Class.getConstructor0(Class.java:1937)
> at java.lang.Class.getConstructor(Class.java:1027)
> at
> org.apache.maven.surefire.battery.JUnitBattery.getTestConstructor(JUnitBattery.java:307)
> at
> org.apache.maven.surefire.battery.JUnitBattery.processTestClass(JUnitBattery.java:150)
> at
> org.apache.maven.surefire.battery.JUnitBattery.(JUnitBattery.java:81)
> at
> org.apache.maven.surefire.SurefireUtils.instantiateBattery(SurefireUtils.java:63)
> at
> org.apache.maven.surefire.Surefire.instantiateBatteries(Surefire.java:262)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:140)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MIDEA-20) Configurable excluded directories for less synchronizing
[ http://jira.codehaus.org/browse/MIDEA-20?page=all ] Edwin Punzalan closed MIDEA-20: --- Assign To: Edwin Punzalan Resolution: Duplicate A patch provided for MIDEA-26 includes this feature. > Configurable excluded directories for less synchronizing > > > Key: MIDEA-20 > URL: http://jira.codehaus.org/browse/MIDEA-20 > Project: Maven 2.x Idea Plugin > Type: Improvement > Reporter: Geoffrey De Smet > Assignee: Edwin Punzalan > Fix For: 2.0 > > > When you switch from the maven console to IntelliJ, it synchronizes (most > people prefer to set it automatically, but it can be set to do it manually). > This synchornizing take up minutes if you 've just build you 're maven site > and included javadocs, > because IntelliJ indexes every single html file. > If you choose not to synchronized, then you can't edit anythign outside of > IntelliJ, including images using the gimp, xdoc files using a WYSWYG editor > or even the intellij configuration files using "mvn idea:idea". > There is a simple solution: exclude the site directory. > But of course there is more then the site that gets generated: everything in > the target directory. > Maven1 offered the option to exclude the entire target directory. > For most cases this would work perfectly, except for projects using generated > code in the target directory. > So I believe it should be configurable and a good default should exclude the > site directory too. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MSUREFIRE-35) Improved errors in console
[ http://jira.codehaus.org/browse/MSUREFIRE-35?page=all ] Brett Porter closed MSUREFIRE-35: - Assign To: Brett Porter (was: Jason van Zyl) Resolution: Cannot Reproduce Fix Version: (was: 2.2) this has changed in 2.2, so probably works or reports better. Let me know. I tried to test it myself, but the code your presented doesn't compile. > Improved errors in console > -- > > Key: MSUREFIRE-35 > URL: http://jira.codehaus.org/browse/MSUREFIRE-35 > Project: Maven 2.x Surefire Plugin > Type: Improvement > Reporter: Vincent Massol > Assignee: Brett Porter > > > Here's what I get: > C:\dev\cargo\trunk\samples\java>mvn clean install > [...] > [INFO] [surefire:test] > [INFO] forkMode: pertest > [INFO] Setting reports dir: > C:\dev\cargo\trunk\samples\java\target/surefire-reports > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at > org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:678) > Caused by: java.lang.reflect.InvocationTargetException > 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:274) > at > org.apache.maven.surefire.Surefire.instantiateBatteries(Surefire.java:292) > at org.apache.maven.surefire.Surefire.run(Surefire.java:91) > at org.apache.maven.surefire.Surefire.run(Surefire.java:85) > at org.apache.maven.surefire.Surefire.run(Surefire.java:61) > ... 5 more > Caused by: java.lang.InstantiationException: > org.codehaus.cargo.sample.java.AllContainerTest > at java.lang.Class.newInstance0(Class.java:293) > at java.lang.Class.newInstance(Class.java:261) > at > org.apache.maven.surefire.battery.SingleTestBattery.(SingleTestBattery.java:42) > ... 13 more > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at > org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:678) > Caused by: java.lang.reflect.InvocationTargetException > 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:274) > at > org.apache.maven.surefire.Surefire.instantiateBatteries(Surefire.java:292) > at org.apache.maven.surefire.Surefire.run(Surefire.java:91) > at org.apache.maven.surefire.Surefire.run(Surefire.java:85) > at org.apache.maven.surefire.Surefire.run(Surefire.java:61) > ... 5 more > Caused by: java.lang.InstantiationException: > org.codehaus.cargo.sample.java.EarCapabilityContainerTest > at java.lang.Class.newInstance0(Class.java:293) > at java.lang.Class.newInstance(Class.java:261) > at > org.apache.maven.surefire.battery.SingleTestBattery.(SingleTestBattery.java:42) > ... 13 more > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at > org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:678) > Caused by: java.lang.reflect.InvocationTargetException > 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:274) > at > org.apache.maven.surefi
[jira] Updated: (MJAVADOC-47) Javadoc plugin ignores destDir when used in reporting section
[ http://jira.codehaus.org/browse/MJAVADOC-47?page=all ]
Maria Odea Ching updated MJAVADOC-47:
-
Attachment: MJAVADOC-47-maven-javadoc-plugin.patch
> Javadoc plugin ignores destDir when used in reporting section
> -
>
> Key: MJAVADOC-47
> URL: http://jira.codehaus.org/browse/MJAVADOC-47
> Project: Maven 2.x Javadoc Plugin
> Type: Bug
> Reporter: Wendy Smoak
> Assignee: Maria Odea Ching
> Fix For: 2.0-beta-4
> Attachments: MJAVADOC-47-maven-javadoc-plugin.patch
>
>
> When used in the reporting section of the pom and 'mvn site', output always
> goes to target/apidocs, even if you specify an outputDir.
> Having outputDir work correctly would by useful with alternate doclets, for
> example sending the output of the UMLGraph doclet to target/uml so that it
> can be further transformed.
> This seems to be the code that's doing it:
> if ( !javadocDirectory.getAbsolutePath().equals( getOutputDirectory()
> ) )
> {
> // we're in site-embedded report mode, so Doxia has set the
> // reportOutputDirectory to the basedir of the site.
> // Append 'apidocs'.
> javadocDirectory = new File( javadocDirectory, "apidocs" );
> }
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-761) Upload tomcat poms and commons-modeler-1.1.jar to maven2 repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-761?page=comments#action_60045 ] Brett Porter commented on MAVENUPLOAD-761: -- Jeff, not sure what you mean about using legacy at cvs.apcahe.org, but you have to make sure that's not a part of the final build. Since commons-modeler isn't interested in doing this, I suggest we should just pull in their last release and the project.xml from the build. > Upload tomcat poms and commons-modeler-1.1.jar to maven2 repository > > > Key: MAVENUPLOAD-761 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-761 > Project: maven-upload-requests > Type: Task > Reporter: Anita Kulshreshtha > Attachments: m2.jar, m2pos.zip > > > 1. Upload the poms contained in the zip to these urls - >http://www.ibiblio.org/maven2/tomcat/tomcat-ajp/5.5.15/ >http://www.ibiblio.org/maven2/tomcat/catalina-cluster/5.5.15/ >http://www.ibiblio.org/maven2/tomcat/catalina/5.5.15/ > 2. Upload commons-modeler-1.1.jar from the url below and the pom from the > zip file to > http://www.ibiblio.org/maven2/commons-modeler/commons-modeler/ -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MECLIPSE-71) eclipse:clean delets too much
[ http://jira.codehaus.org/browse/MECLIPSE-71?page=comments#action_60044 ] Rahul Thakur commented on MECLIPSE-71: -- I think the eclipse:clean goal should delete any artifacts the maven-eclipse-plugin generates (+1 on Fabrizio's comment above), so stuff under .settings should be cleaned up! Perhaps a better way to re-create the config/prefs under .settings would be to write a small Mojo specific to your dev environment that can take care of re-creating required files consistently rather than having to control and share them via SVN. One another solution could be to have an "ignore" list (comma-separated list of paths to resources under the project) that indicates to the eclipse:clean goal which resources to skip when running a 'clean' goal. What do others think? > eclipse:clean delets too much > - > > Key: MECLIPSE-71 > URL: http://jira.codehaus.org/browse/MECLIPSE-71 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.1 > Reporter: Reinhard Poetz > > > If I call eclipse:clean, the complete ".settings" directory is deleted. In my > projects we share some Eclipse settings in our team by adding the .settings > directory to SVN. > This behaviour is unpractical for us as SVN gets confused by the missing > ./settings/.svn directory. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MSUREFIRE-63) Surefire temporary files should be put in target rather than in the main project directory
[ http://jira.codehaus.org/browse/MSUREFIRE-63?page=all ] Brett Porter closed MSUREFIRE-63: - Assign To: Brett Porter Resolution: Fixed Fix Version: 2.2 > Surefire temporary files should be put in target rather than in the main > project directory > -- > > Key: MSUREFIRE-63 > URL: http://jira.codehaus.org/browse/MSUREFIRE-63 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.1.3 > Reporter: Vincent Massol > Assignee: Brett Porter > Priority: Minor > Fix For: 2.2 > > > The following 3 files are cretaed in the main project directory. > surefire.properties > surefire-classloader.properties > surefire-system.properties > They should go in target/ > Thus if the build is stopped they're not left over in the main tree. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=all ] Brett Porter closed MSUREFIRE-23: - Resolution: Fixed > Support TestNG > -- > > Key: MSUREFIRE-23 > URL: http://jira.codehaus.org/browse/MSUREFIRE-23 > Project: Maven 2.x Surefire Plugin > Type: New Feature > Reporter: Mike Perham > Assignee: Brett Porter > Fix For: 2.2 > Attachments: maven-patches.tgz, maven-surefire-plugin-patch.txt, > maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, > surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, > surefire-report-maven-plugin-patch.txt, testng-4.4.5-jdk14.jar, > testng-4.4.5-jdk15.jar > > > Add support for running unit tests with TestNG. > http://www.testng.org -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-58) Cannot override read-only parameter: classpathElements
[ http://jira.codehaus.org/browse/MSUREFIRE-58?page=comments#action_60043 ] Brett Porter commented on MSUREFIRE-58: --- what part of the site is failing? surefire-report, or cobertura, or something else? > Cannot override read-only parameter: classpathElements > -- > > Key: MSUREFIRE-58 > URL: http://jira.codehaus.org/browse/MSUREFIRE-58 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.1.2 > Reporter: Jesper Zedlitz > Priority: Minor > > > When calling "mvn site" on a multi-module project the goal "surefire:test" > fails for the second project: > Error configuring: org.apache.maven.plugins:maven-surefire-plugin. Reason: > ERROR: Cannot override read-only parameter: classpathElements in goal: > surefire:test > "mvn test" works and runs the tests on all modules. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Sat Mar 4 05:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060304.053000.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060304.053000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Sat Mar 4 05:15:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060304.051500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060304.051500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MJAVADOC-40) javadoc:jar doesn't work if destDir was changed in javadoc:javadoc
[ http://jira.codehaus.org/browse/MJAVADOC-40?page=all ]
Allan Ramirez closed MJAVADOC-40:
-
Resolution: Fixed
Applied patch. Thanks
> javadoc:jar doesn't work if destDir was changed in javadoc:javadoc
> --
>
> Key: MJAVADOC-40
> URL: http://jira.codehaus.org/browse/MJAVADOC-40
> Project: Maven 2.x Javadoc Plugin
> Type: Bug
> Reporter: Brian Fox
> Assignee: Maria Odea Ching
> Fix For: 2.0-beta-4
> Attachments: MJAVADOC-40-maven-javadoc-plugin.patch, javadoc-jar.patch
>
>
> The following configuration will cause jar to fail. This is major because it
> stops release:perform from completing on what otherwise should be a valid
> config
>
>
>
> maven-javadoc-plugin
>
> 1.4
> ${project.build.directory}/site/javadoc
>
>
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Sat Mar 4 05:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060304.050001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060304.050001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MIDEA-26) Library support and template overrides
[ http://jira.codehaus.org/browse/MIDEA-26?page=all ] Edwin Punzalan closed MIDEA-26: --- Assign To: Edwin Punzalan Resolution: Fixed Patch applied. Thanks. > Library support and template overrides > -- > > Key: MIDEA-26 > URL: http://jira.codehaus.org/browse/MIDEA-26 > Project: Maven 2.x Idea Plugin > Type: New Feature > Reporter: Patrick Lightbody > Assignee: Edwin Punzalan > Attachments: idea.diff, idea.diff, idea.diff, idea.diff, idea.diff, > idea.patch > > > The supplied patch provides two features: > 1) If the files workspace.xml, module.xml, or project.xml are found in > src/main/idea, they will be used in place of those found in the plugin jar. > That is, they will be used for creating new config files (Rather than > updating existing ones). > 2) You may specify a element that can allow you to tweak how the > library is defined in the module: > * exclude: prevents the library from being configured - great for times when > you wish to instead link in a module as a dependency > * sources: a comma separated list of source paths to bind to the library > * classes: a comma separated list of class paths to use in place of the > typical jar found in ~/.m2 -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-761) Upload tomcat poms and commons-modeler-1.1.jar to maven2 repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-761?page=comments#action_60040 ] Jeff Genender commented on MAVENUPLOAD-761: --- Hi Carlos...no big deal...go ahead an close this out. Geronimo will use legacy at cvs.apache.org. Thanks for the help. > Upload tomcat poms and commons-modeler-1.1.jar to maven2 repository > > > Key: MAVENUPLOAD-761 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-761 > Project: maven-upload-requests > Type: Task > Reporter: Anita Kulshreshtha > Attachments: m2.jar, m2pos.zip > > > 1. Upload the poms contained in the zip to these urls - >http://www.ibiblio.org/maven2/tomcat/tomcat-ajp/5.5.15/ >http://www.ibiblio.org/maven2/tomcat/catalina-cluster/5.5.15/ >http://www.ibiblio.org/maven2/tomcat/catalina/5.5.15/ > 2. Upload commons-modeler-1.1.jar from the url below and the pom from the > zip file to > http://www.ibiblio.org/maven2/commons-modeler/commons-modeler/ -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MSUREFIRE-48) Enable assertions for underlying jvm
[ http://jira.codehaus.org/browse/MSUREFIRE-48?page=all ] Brett Porter closed MSUREFIRE-48: - Assign To: Brett Porter Resolution: Fixed Fix Version: (was: 2.1.3) 2.2 enabled, though I'm not sure why I need to use -ea to do it in forked mode > Enable assertions for underlying jvm > > > Key: MSUREFIRE-48 > URL: http://jira.codehaus.org/browse/MSUREFIRE-48 > Project: Maven 2.x Surefire Plugin > Type: Sub-task > Environment: jre 1.5 > > Reporter: Jesse Kuhnert > Assignee: Brett Porter > Fix For: 2.2 > > > Some jre's don't have assertions enabled by default and require a runtime > parameter of "-ea" in order to use them. Since TestNG supports assertions and > it would be nice to use the short hand method occassionally, determine > feasability of either enabling them in the currently running jvm, or adding > the command line params to the bootloader. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MJAVADOC-40) javadoc:jar doesn't work if destDir was changed in javadoc:javadoc
[ http://jira.codehaus.org/browse/MJAVADOC-40?page=all ]
Maria Odea Ching updated MJAVADOC-40:
-
Attachment: MJAVADOC-40-maven-javadoc-plugin.patch
> javadoc:jar doesn't work if destDir was changed in javadoc:javadoc
> --
>
> Key: MJAVADOC-40
> URL: http://jira.codehaus.org/browse/MJAVADOC-40
> Project: Maven 2.x Javadoc Plugin
> Type: Bug
> Reporter: Brian Fox
> Assignee: Maria Odea Ching
> Fix For: 2.0-beta-4
> Attachments: MJAVADOC-40-maven-javadoc-plugin.patch, javadoc-jar.patch
>
>
> The following configuration will cause jar to fail. This is major because it
> stops release:perform from completing on what otherwise should be a valid
> config
>
>
>
> maven-javadoc-plugin
>
> 1.4
> ${project.build.directory}/site/javadoc
>
>
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MJAVADOC-40) javadoc:jar doesn't work if destDir was changed in javadoc:javadoc
[ http://jira.codehaus.org/browse/MJAVADOC-40?page=all ]
Maria Odea Ching updated MJAVADOC-40:
-
Attachment: (was: MJAVADOC-40-maven-javadoc-plugin.patch)
> javadoc:jar doesn't work if destDir was changed in javadoc:javadoc
> --
>
> Key: MJAVADOC-40
> URL: http://jira.codehaus.org/browse/MJAVADOC-40
> Project: Maven 2.x Javadoc Plugin
> Type: Bug
> Reporter: Brian Fox
> Assignee: Maria Odea Ching
> Fix For: 2.0-beta-4
> Attachments: javadoc-jar.patch
>
>
> The following configuration will cause jar to fail. This is major because it
> stops release:perform from completing on what otherwise should be a valid
> config
>
>
>
> maven-javadoc-plugin
>
> 1.4
> ${project.build.directory}/site/javadoc
>
>
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Sat Mar 4 03:15:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060304.031500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060304.031500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Sat Mar 4 03:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060304.030001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060304.030001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MJAVADOC-46) Allow -docletpath to be specified as an artifact
[ http://jira.codehaus.org/browse/MJAVADOC-46?page=all ] Allan Ramirez closed MJAVADOC-46: - Resolution: Fixed Applied Patch.. Thanks Wendy and Odea > Allow -docletpath to be specified as an artifact > > > Key: MJAVADOC-46 > URL: http://jira.codehaus.org/browse/MJAVADOC-46 > Project: Maven 2.x Javadoc Plugin > Type: New Feature > Reporter: Wendy Smoak > Assignee: Allan Ramirez > Priority: Minor > Fix For: 2.0-beta-4 > Attachments: javadoc-docletArtifact.diff > > > As suggested (and written!) by Brett Porter on [EMAIL PROTECTED], in this > thread: >http://marc.theaimsgroup.com/?l=turbine-maven-dev&m=113694865002748&w=2 > Allow the doclet path to be specified as an artifact with . > Currently the only option is which must be the local path to the > jar file and is not portable. > Comments welcome, I'm happy to rework it if necessary. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MJAVADOC-46) Allow -docletpath to be specified as an artifact
[ http://jira.codehaus.org/browse/MJAVADOC-46?page=comments#action_60036 ] Maria Odea Ching commented on MJAVADOC-46: -- Tested and verified the submitted patch. > Allow -docletpath to be specified as an artifact > > > Key: MJAVADOC-46 > URL: http://jira.codehaus.org/browse/MJAVADOC-46 > Project: Maven 2.x Javadoc Plugin > Type: New Feature > Reporter: Wendy Smoak > Priority: Minor > Fix For: 2.0-beta-4 > Attachments: javadoc-docletArtifact.diff > > > As suggested (and written!) by Brett Porter on [EMAIL PROTECTED], in this > thread: >http://marc.theaimsgroup.com/?l=turbine-maven-dev&m=113694865002748&w=2 > Allow the doclet path to be specified as an artifact with . > Currently the only option is which must be the local path to the > jar file and is not portable. > Comments welcome, I'm happy to rework it if necessary. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build branches/continuum-1.0.x - SUCCESS - checkout] Sat Mar 4 02:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/branches/continuum-1.0.x/continuum-20060304.02.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060304.02.txt
[maven2 build trunk - SUCCESS - update] Sat Mar 4 01:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060304.010001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060304.010001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build trunk - SUCCESS - checkout] Sat Mar 4 01:00:01 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/trunk/continuum-20060304.010001.war Log: http://maven.zones.apache.org/~continuum/logs/trunk/continuum-build-log-20060304.010001.txt
[maven2 build branches/maven-2.0.x - SUCCESS - checkout] Sat Mar 4 00:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060304.003001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060304.003001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - checkout] Sat Mar 4 00:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060304.00.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060304.00.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Can the site plugin be told to exclude some files?
Sounds good. - Brett Dennis Lundberg wrote: > In jakarta-commons we would like to keep our existing (m1) xdocs which > reside in /xdocs/ if we move to m2. The m2 site plugin picks up these > xdocs even though the are not in the preferred m2 directory, which is good. > > We use xml entities in our navigation.xml file for various reasons. We > would like to keep this to preserve our existing m1 site build. At the > same time we need to exclude this file from m2, because the m2 site > plugin chokes on the xml entities. > > I was not able to find a way to do this. Should I file a JIRA about it? > Perhaps a new parameter excludeFiles in SiteMojo? > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Can the site plugin be told to exclude some files?
In jakarta-commons we would like to keep our existing (m1) xdocs which reside in /xdocs/ if we move to m2. The m2 site plugin picks up these xdocs even though the are not in the preferred m2 directory, which is good. We use xml entities in our navigation.xml file for various reasons. We would like to keep this to preserve our existing m1 site build. At the same time we need to exclude this file from m2, because the m2 site plugin chokes on the xml entities. I was not able to find a way to do this. Should I file a JIRA about it? Perhaps a new parameter excludeFiles in SiteMojo? -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-2049) Timeouts in POM downloads cause the build to fail
[ http://jira.codehaus.org/browse/MNG-2049?page=all ] Carlos Sanchez updated MNG-2049: Summary: Timeouts in POM downloads cause the build to fail (was: Dependencies without POMs cause intermittent failures) > Timeouts in POM downloads cause the build to fail > - > > Key: MNG-2049 > URL: http://jira.codehaus.org/browse/MNG-2049 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories > Versions: 2.0.2 > Reporter: Matthew Beermann > > > We have a number of jars in our repository that don't have POMs, e.g. > third-party libraries, etc. Maven happily downloads the jar anyway, and > issues a warning that there's no POM - except, sometimes, it just fails > instead. See the build log below. If I were to rerun Maven again, it might > fail on a different jar, or it might succeed. I can't seem to find any rhyme > or reason to it... > I agree that a missing POM merits a warning, but if the jar is there, it > shouldn't be failing the build! > Downloading: http://prdwebdev11/repository/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom > [WARNING] Unable to get resource from repository prdwebdev11 > (http://prdwebdev11/repository) > Downloading: http://repo1.maven.org/maven2/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error building POM (may not be this project's POM). > Project ID: j2ee:j2ee > Reason: Error getting POM for 'j2ee:j2ee' from the repository: Error > transferring file > j2ee:j2ee:pom:1.3.1 > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > prdwebdev11 (http://prdwebdev11/repository) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r382849 - /maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java
Brett Porter wrote: Can we get unit tests for these types of changes? I think we decided coverage should not go down. How about we activate coverage testing and get the build to fail when it drops. We all need the reminder because we've all let it drop. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-2049) Dependencies without POMs cause intermittent failures
[ http://jira.codehaus.org/browse/MNG-2049?page=comments#action_60023 ] Matthew Beermann commented on MNG-2049: --- Except that it _does_. That's the entire point of both the tracebacks I posted... [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: dependency-of-my-project Reason: Error getting POM for 'dependency-of-my-project' from the repository: Error transferring file > Dependencies without POMs cause intermittent failures > - > > Key: MNG-2049 > URL: http://jira.codehaus.org/browse/MNG-2049 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories > Versions: 2.0.2 > Reporter: Matthew Beermann > > > We have a number of jars in our repository that don't have POMs, e.g. > third-party libraries, etc. Maven happily downloads the jar anyway, and > issues a warning that there's no POM - except, sometimes, it just fails > instead. See the build log below. If I were to rerun Maven again, it might > fail on a different jar, or it might succeed. I can't seem to find any rhyme > or reason to it... > I agree that a missing POM merits a warning, but if the jar is there, it > shouldn't be failing the build! > Downloading: http://prdwebdev11/repository/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom > [WARNING] Unable to get resource from repository prdwebdev11 > (http://prdwebdev11/repository) > Downloading: http://repo1.maven.org/maven2/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error building POM (may not be this project's POM). > Project ID: j2ee:j2ee > Reason: Error getting POM for 'j2ee:j2ee' from the repository: Error > transferring file > j2ee:j2ee:pom:1.3.1 > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > prdwebdev11 (http://prdwebdev11/repository) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-2049) Dependencies without POMs cause intermittent failures
[ http://jira.codehaus.org/browse/MNG-2049?page=comments#action_60022 ] Carlos Sanchez commented on MNG-2049: - a failure to get poms doesn't fail the build, unless it's a parent pom > Dependencies without POMs cause intermittent failures > - > > Key: MNG-2049 > URL: http://jira.codehaus.org/browse/MNG-2049 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories > Versions: 2.0.2 > Reporter: Matthew Beermann > > > We have a number of jars in our repository that don't have POMs, e.g. > third-party libraries, etc. Maven happily downloads the jar anyway, and > issues a warning that there's no POM - except, sometimes, it just fails > instead. See the build log below. If I were to rerun Maven again, it might > fail on a different jar, or it might succeed. I can't seem to find any rhyme > or reason to it... > I agree that a missing POM merits a warning, but if the jar is there, it > shouldn't be failing the build! > Downloading: http://prdwebdev11/repository/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom > [WARNING] Unable to get resource from repository prdwebdev11 > (http://prdwebdev11/repository) > Downloading: http://repo1.maven.org/maven2/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error building POM (may not be this project's POM). > Project ID: j2ee:j2ee > Reason: Error getting POM for 'j2ee:j2ee' from the repository: Error > transferring file > j2ee:j2ee:pom:1.3.1 > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > prdwebdev11 (http://prdwebdev11/repository) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-2120) [REGRESSION] local plugin metadata files are being deleted when remote repository transfer fails
[ http://jira.codehaus.org/browse/MNG-2120?page=all ] Brett Porter updated MNG-2120: -- Fix Version: (was: 2.0.3) > [REGRESSION] local plugin metadata files are being deleted when remote > repository transfer fails > > > Key: MNG-2120 > URL: http://jira.codehaus.org/browse/MNG-2120 > Project: Maven 2 > Type: Bug > Versions: 2.0.2 > Reporter: John Casey > Assignee: John Casey > Priority: Blocker > > > when a plugin repository transfer results in a TransferFailedException, any > locally install plugin metadata gets obliterated. > I'll add more info as I find it out. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-2049) Dependencies without POMs cause intermittent failures
[ http://jira.codehaus.org/browse/MNG-2049?page=comments#action_60020 ] Matthew Beermann commented on MNG-2049: --- Right... but I think there's still a bug here: a failure (for any reason) to find a given artifact on one repository should not fail the build, so long as the artifact is found on /some/ repository. Further, a failure to load the POM should never fail the build, so long as the actual artifact was retrieved successfully. > Dependencies without POMs cause intermittent failures > - > > Key: MNG-2049 > URL: http://jira.codehaus.org/browse/MNG-2049 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories > Versions: 2.0.2 > Reporter: Matthew Beermann > > > We have a number of jars in our repository that don't have POMs, e.g. > third-party libraries, etc. Maven happily downloads the jar anyway, and > issues a warning that there's no POM - except, sometimes, it just fails > instead. See the build log below. If I were to rerun Maven again, it might > fail on a different jar, or it might succeed. I can't seem to find any rhyme > or reason to it... > I agree that a missing POM merits a warning, but if the jar is there, it > shouldn't be failing the build! > Downloading: http://prdwebdev11/repository/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom > [WARNING] Unable to get resource from repository prdwebdev11 > (http://prdwebdev11/repository) > Downloading: http://repo1.maven.org/maven2/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error building POM (may not be this project's POM). > Project ID: j2ee:j2ee > Reason: Error getting POM for 'j2ee:j2ee' from the repository: Error > transferring file > j2ee:j2ee:pom:1.3.1 > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > prdwebdev11 (http://prdwebdev11/repository) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r382889 - in /maven/plugins/trunk/maven-idea-plugin: pom.xml src/main/java/org/apache/maven/plugin/idea/AbstractIdeaMojo.java
You need to add 2.0.1 then. - Brett [EMAIL PROTECTED] wrote: > Author: epunzalan > Date: Fri Mar 3 09:12:31 2006 > New Revision: 382889 > > URL: http://svn.apache.org/viewcvs?rev=382889&view=rev > Log: > Brought back maven deps to 2.0.1 since the parent have depMngt set to > 2.0.1... which allowed me to use a better method available in 2.0.1 > > Modified: > maven/plugins/trunk/maven-idea-plugin/pom.xml > > maven/plugins/trunk/maven-idea-plugin/src/main/java/org/apache/maven/plugin/idea/AbstractIdeaMojo.java > > Modified: maven/plugins/trunk/maven-idea-plugin/pom.xml > URL: > http://svn.apache.org/viewcvs/maven/plugins/trunk/maven-idea-plugin/pom.xml?rev=382889&r1=382888&r2=382889&view=diff > == > --- maven/plugins/trunk/maven-idea-plugin/pom.xml (original) > +++ maven/plugins/trunk/maven-idea-plugin/pom.xml Fri Mar 3 09:12:31 2006 > @@ -17,17 +17,17 @@ > >org.apache.maven >maven-artifact > - 2.0 > + 2.0.1 > > >org.apache.maven >maven-artifact-manager > - 2.0 > + 2.0.1 > > >org.apache.maven >maven-model > - 2.0 > + 2.0.1 > > >org.codehaus.plexus > > Modified: > maven/plugins/trunk/maven-idea-plugin/src/main/java/org/apache/maven/plugin/idea/AbstractIdeaMojo.java > URL: > http://svn.apache.org/viewcvs/maven/plugins/trunk/maven-idea-plugin/src/main/java/org/apache/maven/plugin/idea/AbstractIdeaMojo.java?rev=382889&r1=382888&r2=382889&view=diff > == > --- > maven/plugins/trunk/maven-idea-plugin/src/main/java/org/apache/maven/plugin/idea/AbstractIdeaMojo.java > (original) > +++ > maven/plugins/trunk/maven-idea-plugin/src/main/java/org/apache/maven/plugin/idea/AbstractIdeaMojo.java > Fri Mar 3 09:12:31 2006 > @@ -278,7 +278,8 @@ > VersionRange versionRange = > VersionRange.createFromVersionSpec( d.getVersion() ); > Artifact artifact = > artifactFactory.createDependencyArtifact( d.getGroupId(), d.getArtifactId(), > > versionRange, d.getType(), > - > d.getClassifier(), d.getScope() ); > + > d.getClassifier(), d.getScope(), > + > d.isOptional() ); > map.put( d.getManagementKey(), artifact ); > } > catch ( InvalidVersionSpecificationException e ) > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r382849 - /maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java
Can we get unit tests for these types of changes?
- Brett
[EMAIL PROTECTED] wrote:
> Author: jdcasey
> Date: Fri Mar 3 07:08:31 2006
> New Revision: 382849
>
> URL: http://svn.apache.org/viewcvs?rev=382849&view=rev
> Log:
> Fixing NPE in appendPath(..) when calculating '..' path adjustments.
>
> Modified:
>
> maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java
>
> Modified:
> maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java
> URL:
> http://svn.apache.org/viewcvs/maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java?rev=382849&r1=382848&r2=382849&view=diff
> ==
> ---
> maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java
> (original)
> +++
> maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java
> Fri Mar 3 07:08:31 2006
> @@ -538,10 +538,16 @@
> lastToken = currentToken;
> currentToken = tokens.nextToken();
>
> -if ( "..".equals( currentToken ) )
> +if ( "..".equals( currentToken ) && lastToken != null )
> {
> -// trim the previous path part off...
> -cleanedPath.setLength( cleanedPath.length() - (
> lastToken.length() + 1 ) );
> +int cleanedPathLen = cleanedPath.length();
> +int lastTokenLen = lastToken.length();
> +
> +if ( cleanedPathLen > lastTokenLen )
> +{
> +// trim the previous path part off...
> +cleanedPath.setLength( cleanedPath.length() - (
> lastToken.length() + 1 ) );
> +}
> }
> else if ( !".".equals( currentToken ) )
> {
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven 2.0.3 (second attempt)
On Fri, 3 Mar 2006, John Casey wrote: +1 (2nd time :)) > This is the newest RC binary, including Kenney's fixes for MNG-1317 and > MNG-1318, along with the fix for the NPE noted earlier in > DefaultModelInheritanceAssembler. > > http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060303.193236.tar.gz > > Enjoy, > > John > > John Casey wrote: > > Hello everyone, > > > > If you've been tracking the thread calling for the release of Maven > > 2.0.3, you'll know that several issues came up which have delayed any > > decision on the release. The full discussion can be found here: > > > > http://www.nabble.com/-vote-Release-Maven-2.0.3-t1166489.html#a3063584 > > > > At any rate, I wanted to report that the last issue I have the ability > > to debug is fixed - MNG-1415. The only outstanding issue from the > > previous discussion is MNG-1317, which Kenney has graciously agreed to > > debug and (hopefully) fix tomorrow. There are also two other open issues > > pending in JIRA, but these are tasks that will be executed during the > > release process, so shouldn't hold up the vote. > > > > Regardless of whether MNG-1317 is fixed, I think we've got plenty of > > reason to release 2.0.3 now. We've got two critical fixes for the SSH > > network transport, improved quoted-argument handling for *nix > > environments, plus all of the fixes mentioned in the previous vote > > message. All in all, 24-25 issues will be fixed for this release. > > > > I'm calling this re-vote to ensure that everyone has had a chance to > > look over the work we've done in the past week or so. This release > > shouldn't come out of the blue sky for anyone at this point. :-) > > > > Here's a binary we can use as the most current RC (RC2?). I'll send > > another message with a new link if/when Kenney gets MNG-1317 fixed. > > > > http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060302.181503.tar.gz > > > > > > Let's do the customary 72h vote, +1/0/-1. > > > > Here's my +1. > > > > Thanks, > > > > John > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven 2.0.3 (second attempt)
This is the newest RC binary, including Kenney's fixes for MNG-1317 and MNG-1318, along with the fix for the NPE noted earlier in DefaultModelInheritanceAssembler. http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060303.193236.tar.gz Enjoy, John John Casey wrote: Hello everyone, If you've been tracking the thread calling for the release of Maven 2.0.3, you'll know that several issues came up which have delayed any decision on the release. The full discussion can be found here: http://www.nabble.com/-vote-Release-Maven-2.0.3-t1166489.html#a3063584 At any rate, I wanted to report that the last issue I have the ability to debug is fixed - MNG-1415. The only outstanding issue from the previous discussion is MNG-1317, which Kenney has graciously agreed to debug and (hopefully) fix tomorrow. There are also two other open issues pending in JIRA, but these are tasks that will be executed during the release process, so shouldn't hold up the vote. Regardless of whether MNG-1317 is fixed, I think we've got plenty of reason to release 2.0.3 now. We've got two critical fixes for the SSH network transport, improved quoted-argument handling for *nix environments, plus all of the fixes mentioned in the previous vote message. All in all, 24-25 issues will be fixed for this release. I'm calling this re-vote to ensure that everyone has had a chance to look over the work we've done in the past week or so. This release shouldn't come out of the blue sky for anyone at this point. :-) Here's a binary we can use as the most current RC (RC2?). I'll send another message with a new link if/when Kenney gets MNG-1317 fixed. http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060302.181503.tar.gz Let's do the customary 72h vote, +1/0/-1. Here's my +1. Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-2049) Dependencies without POMs cause intermittent failures
[ http://jira.codehaus.org/browse/MNG-2049?page=comments#action_60017 ] Carlos Sanchez commented on MNG-2049: - Caused by: java.net.ConnectException: Connection timed out: connect It's unrelated to missing poms, only that it'll try to get them everytime you run maven, making the time out problem worse > Dependencies without POMs cause intermittent failures > - > > Key: MNG-2049 > URL: http://jira.codehaus.org/browse/MNG-2049 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories > Versions: 2.0.2 > Reporter: Matthew Beermann > > > We have a number of jars in our repository that don't have POMs, e.g. > third-party libraries, etc. Maven happily downloads the jar anyway, and > issues a warning that there's no POM - except, sometimes, it just fails > instead. See the build log below. If I were to rerun Maven again, it might > fail on a different jar, or it might succeed. I can't seem to find any rhyme > or reason to it... > I agree that a missing POM merits a warning, but if the jar is there, it > shouldn't be failing the build! > Downloading: http://prdwebdev11/repository/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom > [WARNING] Unable to get resource from repository prdwebdev11 > (http://prdwebdev11/repository) > Downloading: http://repo1.maven.org/maven2/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error building POM (may not be this project's POM). > Project ID: j2ee:j2ee > Reason: Error getting POM for 'j2ee:j2ee' from the repository: Error > transferring file > j2ee:j2ee:pom:1.3.1 > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > prdwebdev11 (http://prdwebdev11/repository) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-2049) Dependencies without POMs cause intermittent failures
[ http://jira.codehaus.org/browse/MNG-2049?page=comments#action_60013 ] Matthew Beermann commented on MNG-2049: --- Sorry for the slowness; I finally managed to capture this one in the act. The artifactIds are snipped out, as the project is proprietary. It seems to happen when the central repository is down or overloaded... org.apache.maven.lifecycle.LifecycleExecutionException: Unable to get dependency information: Unable to read the metadata file at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:548) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java: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.artifact.resolver.ArtifactResolutionException: Unable to get dependency information at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:304) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:67) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:223) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1120) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:369) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) ... 16 more Caused by: org.apache.maven.artifact.metadata.ArtifactMetadataRetrievalException: Unable to read the metadata file at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:131) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:282) ... 23 more Caused by: org.apache.maven.project.ProjectBuildingException: Error getting POM at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:417) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:351) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:102) ... 24 more Caused by: org.apache.maven.artifact.resolver.ArtifactResolutionException: Error transferring file at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:140) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:386) ... 26 more Caused by: org.apache.maven.wagon.TransferFailedException: Error transferring file at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:99) at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:68) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:369) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:282) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:244) at org.apache.ma
[jira] Created: (MNG-2121) mvn launch script should use jpackage.org config if available
mvn launch script should use jpackage.org config if available - Key: MNG-2121 URL: http://jira.codehaus.org/browse/MNG-2121 Project: Maven 2 Type: Improvement Components: Command Line Versions: 2.0.2 Environment: GNU/Linux Reporter: Chris Hubick Priority: Minor Attachments: maven_jpp.patch I am attempting to install and use Maven for the first time... so excuse me if I'm off base here :) It is my understanding that a single global classpath (and JVM) is generally deprecated, so I trivially modified my version of the command line 'mvn' script to automatically utilize my existing jpackage.org configuration (patch attached). Also, the installation instructions at http://maven.apache.org/download.html say to unpack it to /usr/local/maven-2.0.2/, yet the mvn script looks for the existance of /opt/m2/ when attempting to automatically set $M2_HOME. I symlinked /usr/local/maven to /usr/local/maven-2.0.2, and also trivially patched my mvn script to look for /usr/local/maven/ when setting $M2_HOME. Instead of adding $M2_HOME/bin to my global path, I just symlinked /usr/local/bin/mvn -> /usr/local/maven/bin/mvn. In this way, I have a working Maven (I hope) without having to modify any global configuration on my machine - meaning the install should be side effect free. I can also upgrade to a new release without having to modify any configuration. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-2118) Listing central repo in pluginRepositories confuses Maven
[ http://jira.codehaus.org/browse/MNG-2118?page=comments#action_60011 ]
Jason Dillon commented on MNG-2118:
---
I also noticed yesterday, that if you do not list central for
and at least one of the listed fail, that Maven 2.0.2 will fail to
find artifacts from the inherited "central"
> Listing central repo in pluginRepositories confuses Maven
> -
>
> Key: MNG-2118
> URL: http://jira.codehaus.org/browse/MNG-2118
> Project: Maven 2
> Type: Bug
> Components: POM, Plugins and Lifecycle
> Versions: 2.0.2
> Reporter: Jason Dillon
> Priority: Critical
>
>
> It appears that if you list the central repository in the pluginRepositories,
> that it may cause Maven to incorrectly check the central repository for
> plugin data.
> Specifically, I found this when using the maven-clean-plugin 2.1. I did not
> have this plugin in my local repository, and when running {{mvn clean}} it
> causes the build to fail:
> {noformat}
> + Error stacktraces are turned on.
> [DEBUG] Building Maven user-level plugin registry from:
> '/Users/jason/.m2/plugin-registry.xml'
> [DEBUG] Building Maven global-level plugin registry from:
> '/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/conf/plugin-registry.xml'
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] Paycore
> [INFO] Paycore :: Merchant
> [INFO] Paycore :: Merchant :: Core
> [INFO] Paycore :: Merchant :: Services
> [INFO]
>
> [INFO] Building Paycore
> [INFO]task-segment: [clean]
> [INFO]
>
> [DEBUG] maven-clean-plugin: resolved to version 2.1 from repository
> maven-snapshots
> [DEBUG] Trying repository maven-snapshots
> Downloading:
> http://snapshots.maven.codehaus.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.1/maven-clean-plugin-2.1.pom
> [DEBUG] Artifact not found - using stub model: Unable to locate resource in
> repository
> org.apache.maven.plugins:maven-clean-plugin:pom:2.1
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> maven-snapshots (http://snapshots.maven.codehaus.org/maven2),
> paybytouch-legacy (http://repository.paybytouch.com/m1/repository)
> [DEBUG] Using defaults for missing POM
> org.apache.maven.plugins:maven-clean-plugin:pom:2.1
> [DEBUG] maven-surefire-plugin: resolved to version 2.1.3-SNAPSHOT from
> repository maven-snapshots
> [DEBUG] maven-surefire-plugin: resolved to version 2.1.3-20060228.012944-10
> from repository maven-snapshots
> [DEBUG] Retrieving parent-POM from the repository for project:
> null:maven-surefire-plugin:maven-plugin:2.1.3-20060228.012944-10
> [DEBUG] maven-one-plugin: resolved to version 1.0-20060213.011019-4 from
> repository maven-snapshots
> [DEBUG] maven-one-plugin: resolved to version 1.0-20060213.011019-4 from
> repository maven-snapshots
> [DEBUG] org.apache.maven.plugins:maven-clean-plugin:maven-plugin:2.1
> (selected for runtime)
> -
> this realm = app0.child-container[org.apache.maven.plugins:maven-clean-plugin]
> urls[0] =
> file:/Users/jason/.m2/repository/org/apache/maven/plugins/maven-clean-plugin/2.1/maven-clean-plugin-2.1.jar
> Number of imports: 0
> this realm = plexus.core.maven
> urls[0] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/commons-cli-1.0.jar
> urls[1] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/doxia-sink-api-1.0-alpha-7.jar
> urls[2] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/jsch-0.1.24.jar
> urls[3] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-artifact-2.0.2.jar
> urls[4] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-artifact-manager-2.0.2.jar
> urls[5] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-core-2.0.2-javadoc.jar
> urls[6] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-core-2.0.2.jar
> urls[7] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-error-diagnostics-2.0.2.jar
> urls[8] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-model-2.0.2.jar
> urls[9] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-monitor-2.0.2.jar
> urls[10] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-plugin-api-2.0.2.jar
> urls[11] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-plugin-descriptor-2.0.2.jar
> urls[12] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-plugin-parameter-documenter-2.0.2.jar
> urls[13] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-plugin-reg
What M2 groupId should we use in Jakarta-commons?
Hi all Discussions on commons-dev@jakarta.apache.org have started regarding a migration from Maven 1 to Maven 2. One topic [1] that we need your assistance with is what the correct M2 groupId for Jakarta-commons is. Two suggestions have been made: - org.apache.commons corresponds to the java package structure - org.apache.jakarta.commons corresponds to the "organization path" within the ASF Which one is correct and why? The "Guide to naming conventions on groupId" [2] says to use package names and has "org.apache.jakarta.commons" as an example. But the source code for a Jakarta commons component is in the package org.apache.commons. not in org.apache.jakarta.commons. I hope you can help us out here. [1]http://www.nabble.com/-daemon-Deploying-maven-2-pom-for-release-1.0.1-t1190137.html#a3136295 [2]http://maven.apache.org/guides/mini/guide-naming-conventions.html -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] separate mailings lists for humans/JIRA/CI/commits
+1 (non-binding) -- Dennis Lundberg Jason van Zyl wrote: Hi, I just wanted to close this up as I think it's a good idea and anything that let's people manage their mail better IMO is a good thing. +1 In this type of vote it is non-technical so simple majority wins, but if it's close we can continue the discussion but I think a majority wanted preferred the separation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - checkout] Fri Mar 3 19:32:36 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060303.193236.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.193236.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Fri Mar 3 19:15:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060303.191500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.191500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] M2 Dependency Resolution Improvements
John, Thanks for the feedback. My responses are now inline: On Mar 3, 2006, at 7:57 AM, John Casey wrote: Comments inline. Cheers, John Garrett Conaty wrote: I've been working quite a bit with Maven2 transitive dependencies at work, and think that they're one of the best strengths of M2. In the course of building quite a number of artifacts through build, deployment, and update I've found that there are number of improvements that can be made. So with the use cases that I've seen at work and listening to what other devs in the community have experienced, I'm proposing some enhancements. These points are only an overview, and some are a variation or enhancement on features in the Maven 2.1 design docs. I've gone into more depth on the rationale and the features themselves on the MavenUser Wiki at http://docs.codehaus.org/display/MAVENUSER/ Improving+Maven2+Dependency+Resolution : * Virtual Dependencies (also know as spec jars) This is something we've been discussing for some time now. We just need to have a concrete discussion about what's involved in implementing it. For instance, we have to provide a portable way to resolve spec -> implementation mappings. This might take a form similar to the plugin-prefix -> implementation metadata file. Once we have that in place, we need some consistent mechanism for choosing one implementation over another. The corresponding mechanisms for plugin selection based on prefix are somewhat crude... How about putting a new in the stanzas of the POM? Of course, it would still need someway to resolve this map (perhaps by putting them in profiles or something). * Environmental Context - Use the JDK environment and deploy environment as part of the resolution phase. As an example, you don't need to get JAXP API classes from a repository if compiling with JDK 1.4 If you can represent pieces like the JDK as a repository with an alternate layout, I don't see why we couldn't tie this into the spec dependencies bit above and make it work. Yeah, I definitely see these being very related. So you could define a JDK 1.4 environment or Geronimo 1.0 environment (profile?) that would be contain the list of the spec JARS. This would be really helpful for building some of the Apache Commons packages that require different JARs (currently) depending on what JDK they're using. I'd love it if the build files for these would be able to list all the spec JARs that they require and then when you build, Maven could have the knowledge of your environment. Though I'm not sure they'd actually be POMs themselves (like for JDK 1.4) that would list artifacts. It might be viewed something more like how Eclipse shows you library entries for JDK or app servers (like Tomcat in the Eclipse WebToolsProject) * Pinning Dependencies (Overrides) - If you have a fixed dependency tree for a given release, it's important to be able to provided patches that can override a node of the tree. only appears to handle this for parent- child projects. I suspect an elegant way to handle this might be with an alternative dependency selection implementation that uses some authoritative set of "approved" versions when resolving artifacts... That makes some sense from an 'approved' perspective, though the use case I'm describing is actually a specific patch (e.g. you've built your application with a certain release of dependencies, and then your vendor tells you you need to slot in this security fix). This is slightly different than having a compliant or standard set of dependencies. Questions I have WRT this are: 1. will this set of blessed versions be portable (i.e. travel with the POM)? The simplest scoping would be to have it be an element of your application's POM. I could also see it in /.m2/ specific settings for a build machine, though this would be less portable. A fancy solution might be to point to a central server and download updates, but this is probably overkill. 2. how will developers in a team setting share this info? It seems like implementing this would be an exercise in walking a tightrope between portability and centralized declaration for versions. (see previous answer) * Filtering Parameters - Let the dependency resolution be able to pick artifacts based on things like required JDK version, license, signed/unsigned, tags,etc. Is this a dependency selection technique? It seems like it's just a matter of "approving" a given dependency as a candidate for selection using POM attributes and possibly attributes of the jar itself (which could be a bit more involved), before allowing artifact version selection to proceed. Much of this could probably be factored out of the DefaultArtifactCollector, into some sort of pluggable component. Exactly, I think these filters are additional parameters to the ArtifactCollector. So just like ve
[maven2 build trunk - SUCCESS - update] Fri Mar 3 19:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060303.190001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.190001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - FAILED - update] Fri Mar 3 18:45:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.184500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - FAILED - update] Fri Mar 3 18:30:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.183001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - FAILED - update] Fri Mar 3 18:15:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.181500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - FAILED - update] Fri Mar 3 18:00:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.180001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - FAILED - update] Fri Mar 3 17:45:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.174501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MWAR-21) Need a way to include limited set of webapp's dependencies
[ http://jira.codehaus.org/browse/MWAR-21?page=comments#action_60005 ] Grzegorz Slowikowski commented on MWAR-21: -- I made a test and they were included in the war. A deleted my local repository war plugin and a) made a test, 2.0-beta-2 version was used - everything ok b) built trunk version (2.0-beta-3-SNAPSHOT) - everything ok too. I don't know what version I had in my repository. I know only that is was a snapshot. Try to delete maven-war-plugin from your local repo and try again. > Need a way to include limited set of webapp's dependencies > -- > > Key: MWAR-21 > URL: http://jira.codehaus.org/browse/MWAR-21 > Project: Maven 2.x War Plugin > Type: Improvement > Environment: M2.0.1 > Reporter: Dirk Olmes > Priority: Blocker > Fix For: 2.0 > Attachments: AbstractWarMojo.diff > > > I need a way to pack a war that includes only a limited set of the webapp's > dependencies. We're deploying in mainly two different environments: for > testing, the webapp runs standalone and thus needs to include all its > dependencies in the war. For production we deploy the webapp into a JBoss > server that has all the dependencies already installed. > I've modified AbstractWarMojo in the following way: 1) allow to specify > dependencyIncludes an dependencyExcludes (as lists) 2) upon building the war, > each dependency is checked against the excludes and the includes and will be > added to the war accordingly. > While this patch may not be the best way to to it, it clearly shows my > requirements. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - FAILED - update] Fri Mar 3 17:30:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.173000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-2120) [REGRESSION] local plugin metadata files are being deleted when remote repository transfer fails
[ http://jira.codehaus.org/browse/MNG-2120?page=comments#action_60004 ] John Casey commented on MNG-2120: - the problem was manifesting itself in the maven-core-it process, which I had to remind myself was actually executing a delete of the local plugin installation in a pre-build hook. *UGH* > [REGRESSION] local plugin metadata files are being deleted when remote > repository transfer fails > > > Key: MNG-2120 > URL: http://jira.codehaus.org/browse/MNG-2120 > Project: Maven 2 > Type: Bug > Versions: 2.0.2 > Reporter: John Casey > Assignee: John Casey > Priority: Blocker > Fix For: 2.0.3 > > > when a plugin repository transfer results in a TransferFailedException, any > locally install plugin metadata gets obliterated. > I'll add more info as I find it out. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-2120) [REGRESSION] local plugin metadata files are being deleted when remote repository transfer fails
[ http://jira.codehaus.org/browse/MNG-2120?page=all ] John Casey closed MNG-2120: --- Resolution: Cannot Reproduce ...and now I cannot reproduce it. This is VERY strange. > [REGRESSION] local plugin metadata files are being deleted when remote > repository transfer fails > > > Key: MNG-2120 > URL: http://jira.codehaus.org/browse/MNG-2120 > Project: Maven 2 > Type: Bug > Versions: 2.0.2 > Reporter: John Casey > Assignee: John Casey > Priority: Blocker > Fix For: 2.0.3 > > > when a plugin repository transfer results in a TransferFailedException, any > locally install plugin metadata gets obliterated. > I'll add more info as I find it out. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - FAILED - update] Fri Mar 3 17:15:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.171500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-2120) [REGRESSION] local plugin metadata files are being deleted when remote repository transfer fails
[ http://jira.codehaus.org/browse/MNG-2120?page=all ] John Casey updated MNG-2120: Assign To: John Casey Fix Version: 2.0.3 > [REGRESSION] local plugin metadata files are being deleted when remote > repository transfer fails > > > Key: MNG-2120 > URL: http://jira.codehaus.org/browse/MNG-2120 > Project: Maven 2 > Type: Bug > Versions: 2.0.2 > Reporter: John Casey > Assignee: John Casey > Priority: Blocker > Fix For: 2.0.3 > > > when a plugin repository transfer results in a TransferFailedException, any > locally install plugin metadata gets obliterated. > I'll add more info as I find it out. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2120) [REGRESSION] local plugin metadata files are being deleted when remote repository transfer fails
[REGRESSION] local plugin metadata files are being deleted when remote repository transfer fails Key: MNG-2120 URL: http://jira.codehaus.org/browse/MNG-2120 Project: Maven 2 Type: Bug Versions: 2.0.2 Reporter: John Casey Priority: Blocker Fix For: 2.0.3 when a plugin repository transfer results in a TransferFailedException, any locally install plugin metadata gets obliterated. I'll add more info as I find it out. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - FAILED - update] Fri Mar 3 17:00:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.170001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - FAILED - update] Fri Mar 3 16:30:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.163000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - FAILED - update] Fri Mar 3 16:15:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.161500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - FAILED - update] Fri Mar 3 16:00:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.16.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MIDEA-26) Library support and template overrides
[ http://jira.codehaus.org/browse/MIDEA-26?page=all ] Patrick Lightbody updated MIDEA-26: --- Attachment: idea.diff > Library support and template overrides > -- > > Key: MIDEA-26 > URL: http://jira.codehaus.org/browse/MIDEA-26 > Project: Maven 2.x Idea Plugin > Type: New Feature > Reporter: Patrick Lightbody > Attachments: idea.diff, idea.diff, idea.diff, idea.diff, idea.diff, > idea.patch > > > The supplied patch provides two features: > 1) If the files workspace.xml, module.xml, or project.xml are found in > src/main/idea, they will be used in place of those found in the plugin jar. > That is, they will be used for creating new config files (Rather than > updating existing ones). > 2) You may specify a element that can allow you to tweak how the > library is defined in the module: > * exclude: prevents the library from being configured - great for times when > you wish to instead link in a module as a dependency > * sources: a comma separated list of source paths to bind to the library > * classes: a comma separated list of class paths to use in place of the > typical jar found in ~/.m2 -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - FAILED - update] Fri Mar 3 15:45:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.154500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about Clearcase, Starteam and Perforce
StartTeam does have it but completely hidden and undocumented. -D On 3/3/06, Mike Perham <[EMAIL PROTECTED]> wrote: And I believe ClearCase is the same. No idea about StarTeam.-Original Message-From: Jeff Jensen [mailto: [EMAIL PROTECTED]]Sent: Friday, March 03, 2006 8:20 AMTo: scm-dev@maven.apache.orgSubject: Re: Question about Clearcase, Starteam and Perforce Perforce does not use local disk for storage of info like CVS and svn.Quoting Emmanuel Venisse <[EMAIL PROTECTED]>:> Hi,>> I added a new method in SCMProvider (String getScmSpecificFilename()) > This method returns the name of reserved filename/directory use by scm> like CVS or .svn>> Do we have a similar file for Clearcase/Starteam/Perforce ?>> Emmanuel> >
Re: [PROPOSAL] M2 Dependency Resolution Improvements
Comments inline. Cheers, John Garrett Conaty wrote: I've been working quite a bit with Maven2 transitive dependencies at work, and think that they're one of the best strengths of M2. In the course of building quite a number of artifacts through build, deployment, and update I've found that there are number of improvements that can be made. So with the use cases that I've seen at work and listening to what other devs in the community have experienced, I'm proposing some enhancements. These points are only an overview, and some are a variation or enhancement on features in the Maven 2.1 design docs. I've gone into more depth on the rationale and the features themselves on the MavenUser Wiki at http://docs.codehaus.org/display/MAVENUSER/Improving+Maven2+Dependency+Resolution : * Virtual Dependencies (also know as spec jars) This is something we've been discussing for some time now. We just need to have a concrete discussion about what's involved in implementing it. For instance, we have to provide a portable way to resolve spec -> implementation mappings. This might take a form similar to the plugin-prefix -> implementation metadata file. Once we have that in place, we need some consistent mechanism for choosing one implementation over another. The corresponding mechanisms for plugin selection based on prefix are somewhat crude... * Environmental Context - Use the JDK environment and deploy environment as part of the resolution phase. As an example, you don't need to get JAXP API classes from a repository if compiling with JDK 1.4 If you can represent pieces like the JDK as a repository with an alternate layout, I don't see why we couldn't tie this into the spec dependencies bit above and make it work. * Pinning Dependencies (Overrides) - If you have a fixed dependency tree for a given release, it's important to be able to provided patches that can override a node of the tree. only appears to handle this for parent-child projects. I suspect an elegant way to handle this might be with an alternative dependency selection implementation that uses some authoritative set of "approved" versions when resolving artifacts... Questions I have WRT this are: 1. will this set of blessed versions be portable (i.e. travel with the POM)? 2. how will developers in a team setting share this info? It seems like implementing this would be an exercise in walking a tightrope between portability and centralized declaration for versions. * Filtering Parameters - Let the dependency resolution be able to pick artifacts based on things like required JDK version, license, signed/unsigned, tags,etc. Is this a dependency selection technique? It seems like it's just a matter of "approving" a given dependency as a candidate for selection using POM attributes and possibly attributes of the jar itself (which could be a bit more involved), before allowing artifact version selection to proceed. Much of this could probably be factored out of the DefaultArtifactCollector, into some sort of pluggable component. * Blacklisting artifacts - Not just repositories. This is appropriate if you don't control the POM that's using the artifact to be blacklisted. ...so you're talking about a global exclusions list? Again, my questions about this center on dissemination of that list. Otherwise, can't you do this with dependency exclusions now? * License Acknowledgment - Some commercial vendors (Sun) require a clickthrough license before downloading. Also a user getting an artifact under an Apache license with an LGPL dependency would need to be notified that they are not only accepting the Apache License but LGPL. This might be another thing that gets added to the dependency selection process, when we're gathering candidate artifact/versions. If you combine it with spec dependencies, the selection algorithm might be able to select an alternate [set of] deps to satisfy the spec dependency you specify (when the user refuses to traverse the click-through)... Also, any click-through implementation will have to completely satisfy the legal requirements of people like Sun, which could mean finding a way to embed/interact with a full-featured browser. I don't know of any cross-platform way to do this, without embedding a browser...and I'm not aware of any mature embeddable browser implementations, personally. * Expose dependency resolution to client tools - Provide APIs so that clients can pass in different artifacts with different filters to see not only the multiple artifacts and paths that can resolve a dependency, but also which one would be selected. This would be very helpful for debugging and also to let UI tools visualize the dependency graphs. We can undoubtedly go further in making this accessible, but it should be possible to do what you describe even now. It's just a matter of knowing the APIs... I don't think these features have easy work
[maven2 build branches/maven-2.0.x - FAILED - checkout] Fri Mar 3 15:25:19 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.152520.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SKIPPED - checkout] Fri Mar 3 15:24:49 GMT 2006
ci.sh already running... exiting maven 16670 16667 0 15:24:50 pts/4 0:00 /bin/sh ./ci.sh checkout maven 16671 16667 0 15:24:50 pts/4 0:00 /bin/sh ./ci.sh checkout - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven 2.0.3 (second attempt)
I'm on it. It'll be fixed in a few minutes, and I'll republish the next CI binary that comes out as a new RC. Thanks for catching this. -john Fabrizio Giustina wrote: mh, I got a NPE from maven-project using this build (multiproject build, flat structure, any goal that requires dependency resolution). Looks like a problem with the changes for MNG-2006 , worths a check fabrizio [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.appendPath(DefaultModelInheritanceAssembler.java:544) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleDistributionInheritence(DefaultModelInheritanceAssembler.java:433) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:110) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.copyModel(DefaultModelInheritanceAssembler.java:52) at org.apache.maven.project.ModelUtils.cloneModel(ModelUtils.java:435) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:667) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:225) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:102) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:275) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:67) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:223) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1117) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:366) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) On 3/2/06, Fabrizio Giustina <[EMAIL PROTECTED]> wrote: big +1 this time fabrizio On 3/2/06, John Casey <[EMAIL PROTECTED]> wrote: Hello everyone, If you've been tracking the thread calling for the release of Maven 2.0.3, you'll know that several issues came up which have delayed any decision on the release. The full discussion can be found here: http://www.nabble.com/-vote-Release-Maven-2.0.3-t1166489.html#a3063584 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] separate mailings lists for humans/JIRA/CI/commits
+1 fabrizio On 3/1/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: > Hi, > > I just wanted to close this up as I think it's a good idea and anything > that let's people manage their mail better IMO is a good thing. > > +1 > > In this type of vote it is non-technical so simple majority wins, but if > it's close we can continue the discussion but I think a majority wanted > preferred the separation. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven 2.0.3 (second attempt)
On 3/3/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: > Do you have a sample project that reproduce the problem? You can checking out http://svn.magnolia.info/svn/magnolia/trunk/ (the root project is magnolia-project). You will still get this error when trying to run a mvn install from the root project (and sorry, I still didn't had the time to debug the cause properly). fabrizio > > Emmanuel > > Fabrizio Giustina a écrit : > > mh, I got a NPE from maven-project using this build (multiproject > > build, flat structure, any goal that requires dependency resolution). > > Looks like a problem with the changes for MNG-2006 , worths a check > > > > fabrizio > > > > > > [ERROR] FATAL ERROR > > [INFO] > > > > [INFO] null > > [INFO] > > > > [INFO] Trace > > java.lang.NullPointerException > > at > > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.appendPath(DefaultModelInheritanceAssembler.java:544) > > at > > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleDistributionInheritence(DefaultModelInheritanceAssembler.java:433) > > at > > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:110) > > at > > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.copyModel(DefaultModelInheritanceAssembler.java:52) > > at > > org.apache.maven.project.ModelUtils.cloneModel(ModelUtils.java:435) > > at > > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:667) > > at > > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:225) > > at > > org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:102) > > at > > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:275) > > at > > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:67) > > at > > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:223) > > at > > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211) > > at > > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182) > > at > > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1117) > > at > > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:366) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > > > > > > > > On 3/2/06, Fabrizio Giustina <[EMAIL PROTECTED]> wrote: > > > >>big +1 this time > >> > >>fabrizio > >> > >>On 3/2/06, John Casey <[EMAIL PROTECTED]> wrote: > >> > >>>Hello everyone, > >>> > >>>If you've been tracking the thread calling for the release of Maven > >>>2.0.3, you'll know that several issues came up which have delayed any > >>>decision on the release. The full discussion can be found here: > >>> > >>>http://www.nabble.com/-vote-Release-Maven-2.0.3-t1166489.html#a3063584 > >> > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Fri Mar 3 14:30:01 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060303.143001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.143001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems w/ Webapps in Triplesec
On Fri, 3 Mar 2006, Alex Karasulu wrote: I think you CC'd the wrong dev list. This list is for Apache Maven design discussions only. -- Kenney > Dariush Behboudi wrote: > > Hi Alex, > > > Hope you don't mind but I CC'd the dev list. Let's keep this on that list. > > I was able to build triplesec as suggested. > > > > I have some errors and some questions about the webapps, I'd glad if you can > > help. > > > > > All these webapps are a work in progress D. They are not even complete > yet. The admin btw is experimental. A fellow by the name of serdar is > working on it. Perhaps he can chime in on his progress. > > First of all, the webapp-admin project generated triplesec-webapp-config.war > > war file; this war is created also by the webapp-config project. > > Which webapp I must deploy with tomcat? > > > So it generates the same webapp hmmm that's not good. I just fixed this > btw so you'll want to svn up your wkdir. Incidentally you have to have > an instance of the server running for these to work since they connect > to the triplsec server. > > Hey if you want to skype me for help you can ... my handle is akarasulu. > > Laters, > Alex > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Question about Clearcase, Starteam and Perforce
And I believe ClearCase is the same. No idea about StarTeam. -Original Message- From: Jeff Jensen [mailto:[EMAIL PROTECTED] Sent: Friday, March 03, 2006 8:20 AM To: scm-dev@maven.apache.org Subject: Re: Question about Clearcase, Starteam and Perforce Perforce does not use local disk for storage of info like CVS and svn. Quoting Emmanuel Venisse <[EMAIL PROTECTED]>: > Hi, > > I added a new method in SCMProvider (String getScmSpecificFilename()) > This method returns the name of reserved filename/directory use by scm > like CVS or .svn > > Do we have a similar file for Clearcase/Starteam/Perforce ? > > Emmanuel > >
Problems w/ Webapps in Triplesec
Dariush Behboudi wrote: Hi Alex, Hope you don't mind but I CC'd the dev list. Let's keep this on that list. I was able to build triplesec as suggested. I have some errors and some questions about the webapps, I'd glad if you can help. All these webapps are a work in progress D. They are not even complete yet. The admin btw is experimental. A fellow by the name of serdar is working on it. Perhaps he can chime in on his progress. First of all, the webapp-admin project generated triplesec-webapp-config.war war file; this war is created also by the webapp-config project. Which webapp I must deploy with tomcat? So it generates the same webapp hmmm that's not good. I just fixed this btw so you'll want to svn up your wkdir. Incidentally you have to have an instance of the server running for these to work since they connect to the triplsec server. Hey if you want to skype me for help you can ... my handle is akarasulu. Laters, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Fri Mar 3 14:15:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060303.141500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.141500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about Clearcase, Starteam and Perforce
Perforce does not use local disk for storage of info like CVS and svn. Quoting Emmanuel Venisse <[EMAIL PROTECTED]>: > Hi, > > I added a new method in SCMProvider (String getScmSpecificFilename()) > This method returns the name of reserved filename/directory use by scm like > CVS or .svn > > Do we have a similar file for Clearcase/Starteam/Perforce ? > > Emmanuel > >
[maven2 build trunk - SUCCESS - update] Fri Mar 3 14:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060303.140001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.140001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (ARCHETYPE-32) including png in site resources breaks an archetype (stacktrace+archetype.xml included)
including png in site resources breaks an archetype (stacktrace+archetype.xml included) --- Key: ARCHETYPE-32 URL: http://jira.codehaus.org/browse/ARCHETYPE-32 Project: Maven Archetype Type: Bug Components: maven-archetype-plugin Reporter: Jurgen De Landsheer Assigned to: Jason van Zyl if I drop the png: creation is correct but it seems it wants to parse a png or something? maven-ugent-plugin-archetype src/main/java/org/codehaus/mojo/test/TestMojo.java src/test/java/org/codehaus/mojo/test/TestMojoTestSuite.java src/main/resources/jalopy.xml src/main/resources/plugin.properties src/test/resources/test.properties src/site/site.xml src/site/apt/usage.apt src/site/resources/images/logobalk_small.png C:\JAVA\maven-plugins>mvn -e archetype:create -DarchetypeGroupId=be.ugent.dict -DarchetypeArtifactId=maven-ugent-plugin-archetype -DgroupId= -DartifactId=test C:\JAVA\maven-plugins>set MAVEN_OPTS=-Xmx32m -Xmx200m + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] maven-ugent-plugin-archetype [INFO] maven-mojo-report-plugin [INFO] maven-lint4j-plugin [INFO] maven-juge-plugin [INFO] maven-project-info-plugin [INFO] maven-spring-beandoc-plugin [INFO] maven-linguine-maps-plugin [INFO] maven-hibernate-tools-plugin [INFO] Searching repository for plugin with prefix: 'archetype'. [INFO] org.apache.maven.plugins: checking for updates from missing-plugins [INFO] org.apache.maven.plugins: checking for updates from ugent-plugins [INFO] org.codehaus.mojo: checking for updates from missing-plugins [INFO] org.codehaus.mojo: checking for updates from ugent-plugins [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for updates from missing-plugins [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for updates from ugent-plugins [INFO] artifact org.apache.maven.plugins:maven-site-plugin: checking for updates from missing-plugins [INFO] artifact org.apache.maven.plugins:maven-site-plugin: checking for updates from ugent-plugins [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking for updates from missing-plugins [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking for updates from ugent-plugins [INFO] artifact org.apache.maven.plugins:maven-archetype-plugin: checking for updates from missing-plugins [INFO] artifact org.apache.maven.plugins:maven-archetype-plugin: checking for updates from ugent-plugins [INFO] [INFO] Building maven-mojo-report-plugin [INFO]task-segment: [archetype:create] (aggregator-style) [INFO] [INFO] Setting property: classpath.resource.loader.class => 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. [INFO] Setting property: resource.loader => 'classpath'. [INFO] ** [INFO] Starting Jakarta Velocity v1.4 [INFO] RuntimeInstance initializing. [INFO] Default Properties File: org\apache\velocity\runtime\defaults\velocity.properties [INFO] Default ResourceManager initializing. (class org.apache.velocity.runtime.resource.ResourceManagerImpl) [INFO] Resource Loader Instantiated: org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader [INFO] ClasspathResourceLoader : initialization starting. [INFO] ClasspathResourceLoader : initialization complete. [INFO] ResourceCache : initialized. (class org.apache.velocity.runtime.resource.ResourceCacheImpl) [INFO] Default ResourceManager initialization complete. [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach [INFO] Created: 20 parsers. [INFO] Velocimacro : initialization starting. [INFO] Velocimacro : adding VMs from VM library template : VM_global_library.vm [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'VM_global_library.vm' [INFO] Velocimacro : VM library template macro registration
Question about Clearcase, Starteam and Perforce
Hi, I added a new method in SCMProvider (String getScmSpecificFilename()) This method returns the name of reserved filename/directory use by scm like CVS or .svn Do we have a similar file for Clearcase/Starteam/Perforce ? Emmanuel
Re: [vote] Release Maven 2.0.3 (second attempt)
On Fri, 3 Mar 2006, Emmanuel Venisse wrote:
Looking at the source, the only way this can go wrong
is if the 'parent path' has no tokens, i.e. is an empty
string, or has the value "http://"; or "file:///". The parent path
in question here is the site url.
This, in combination with '..' in the child path (which is strange,
since the artifactId is used there, and that should not contain '..')
Maybe if the was not specified in the parent (or ancestor),
it now defaults to an empty string?
What would be needed hereis a check for too many '..'
(i.e. parent = "/tmp/", child="../../test" -> /../test/, or
parent = "/", child = "../test" in the current case).
Either we ignore the '..' in this case, or thow an exception
(but that would require changes to the method signature).
Proposed fix: ignore for now, instead of an NPE?
(btw, the code is rather complex. A simple 'new File( parent, child
).getAbsolutePath().replace('\\','/') seems simpler to me.. :)
-- Kenney
> Do you have a sample project that reproduce the problem?
>
> Emmanuel
>
> Fabrizio Giustina a �crit :
> > mh, I got a NPE from maven-project using this build (multiproject
> > build, flat structure, any goal that requires dependency resolution).
> > Looks like a problem with the changes for MNG-2006 , worths a check
> >
> > fabrizio
> >
> >
> > [ERROR] FATAL ERROR
> > [INFO]
> >
> > [INFO] null
> > [INFO]
> >
> > [INFO] Trace
> > java.lang.NullPointerException
> > at
> > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.appendPath(DefaultModelInheritanceAssembler.java:544)
> > at
> > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleDistributionInheritence(DefaultModelInheritanceAssembler.java:433)
> > at
> > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:110)
> > at
> > org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.copyModel(DefaultModelInheritanceAssembler.java:52)
> > at
> > org.apache.maven.project.ModelUtils.cloneModel(ModelUtils.java:435)
> > at
> > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:667)
> > at
> > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:225)
> > at
> > org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:102)
> > at
> > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:275)
> > at
> > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:67)
> > at
> > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:223)
> > at
> > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211)
> > at
> > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182)
> > at
> > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1117)
> > at
> > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:366)
> > at
> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> > at
> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
> > at
> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
> > at
> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
> > at
> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
> >
> >
> >
> > On 3/2/06, Fabrizio Giustina <[EMAIL PROTECTED]> wrote:
> >
> >>big +1 this time
> >>
> >>fabrizio
> >>
> >>On 3/2/06, John Casey <[EMAIL PROTECTED]> wrote:
> >>
> >>>Hello everyone,
> >>>
> >>>If you've been tracking the thread calling for the release of Maven
> >>>2.0.3, you'll know that several issues came up which have delayed any
> >>>decision on the release. The full discussion can be found here:
> >>>
> >>>http://www.nabble.com/-vote-Release-Maven-2.0.3-t1166489.html#a3063584
> >>
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Fri Mar 3 13:15:01 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060303.131501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.131501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1317) m2.bat doesn't work on Windows 2000
[ http://jira.codehaus.org/browse/MNG-1317?page=all ] Kenney Westerhof closed MNG-1317: - Assign To: Kenney Westerhof Resolution: Fixed Fix Version: (was: 2.0.4) 2.0.3 Fixed in revision 382797. Use ~dp0 instead of ~dps0 (which works correctly, but produces long filenames), and add double quotes so the long filenames work. > m2.bat doesn't work on Windows 2000 > --- > > Key: MNG-1317 > URL: http://jira.codehaus.org/browse/MNG-1317 > Project: Maven 2 > Type: Bug > Components: Command Line > Versions: 2.0 > Environment: Windows 2000/SP4 Maven 2.0 > Reporter: ajbanck > Assignee: Kenney Westerhof > Fix For: 2.0.3 > > > the m2.bat doesn't work on Windows 2000. > This batch uses '%~dps0\mvn %*' to call the mvn batch file. %~dps0 expands > to the path including the batch name, resulting in an incorrect path. > Looking at another batch (cruisecontrol.bat) uses %~dp0 instead of %~dps0 > Current Output with echo turned on: > C:\cc_stg\Hercules_nl\MetadataRepository\shared\util>m2 compile > >echo. > >echo THE m2 COMMMAND IS DEPRECATED - PLEASE RUN mvn INSTEAD > THE m2 COMMMAND IS DEPRECATED - PLEASE RUN mvn INSTEAD > C:\cc_stg\Hercules_nl\MetadataRepository\shared\util>echo. > >C:\cc_stg\HERCUL~1\METADA~1\external\maven\maven-2.0\bin\m2.bat\mvn compile > The directory name is invalid. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1318) mvn.bat sets incorrect value to M2_HOME [Windows 2000]
[ http://jira.codehaus.org/browse/MNG-1318?page=comments#action_59989 ] Kenney Westerhof commented on MNG-1318: --- Sorry, I messed up 1317 and 1318. This issue is fixed in revision 382801. > mvn.bat sets incorrect value to M2_HOME [Windows 2000] > -- > > Key: MNG-1318 > URL: http://jira.codehaus.org/browse/MNG-1318 > Project: Maven 2 > Type: Bug > Components: Command Line > Versions: 2.0 > Environment: Windows 2000 SP4 / Maven 2.0 > Reporter: ajbanck > Assignee: Kenney Westerhof > Fix For: 2.0.3 > > > When running Maven 2 by calling mvn.bat on Windows 2000 (SP4) the batch file > sets M2_HOME to a value including the name of the batch file itself. > This results in an error: > ERROR: M2_HOME is set to an invalid directory. > M2_HOME = C:\maven\maven-2.0\bin\mvn.bat\.. > Please set the M2_HOME variable in your environment to match the location of > the Maven installation > When changing line 72 of mvn.bat to use %~dp0 instead of %~dps0 it works > correctly: > if "%OS%"=="Windows_NT" SET M2_HOME=%~dp0\.. > Looking at the SVN history, this was changed to %~dps0 to work with spaces > http://svn.apache.org/viewcvs.cgi?rev=163778&view=rev -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1318) mvn.bat sets incorrect value to M2_HOME [Windows 2000]
[ http://jira.codehaus.org/browse/MNG-1318?page=all ] Kenney Westerhof closed MNG-1318: - Assign To: Kenney Westerhof Resolution: Fixed Fix Version: (was: 2.0.4) 2.0.3 Fixed in svn revision 382797. Changed the fix/version to 2.0.3 as discussed. > mvn.bat sets incorrect value to M2_HOME [Windows 2000] > -- > > Key: MNG-1318 > URL: http://jira.codehaus.org/browse/MNG-1318 > Project: Maven 2 > Type: Bug > Components: Command Line > Versions: 2.0 > Environment: Windows 2000 SP4 / Maven 2.0 > Reporter: ajbanck > Assignee: Kenney Westerhof > Fix For: 2.0.3 > > > When running Maven 2 by calling mvn.bat on Windows 2000 (SP4) the batch file > sets M2_HOME to a value including the name of the batch file itself. > This results in an error: > ERROR: M2_HOME is set to an invalid directory. > M2_HOME = C:\maven\maven-2.0\bin\mvn.bat\.. > Please set the M2_HOME variable in your environment to match the location of > the Maven installation > When changing line 72 of mvn.bat to use %~dp0 instead of %~dps0 it works > correctly: > if "%OS%"=="Windows_NT" SET M2_HOME=%~dp0\.. > Looking at the SVN history, this was changed to %~dps0 to work with spaces > http://svn.apache.org/viewcvs.cgi?rev=163778&view=rev -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Fri Mar 3 12:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060303.123001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060303.123001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] separate mailings lists for humans/JIRA/CI/commits
On Wed, 1 Mar 2006, Jason van Zyl wrote: +1 (duh! :)) > Hi, > > I just wanted to close this up as I think it's a good idea and anything > that let's people manage their mail better IMO is a good thing. > > +1 > > In this type of vote it is non-technical so simple majority wins, but if > it's close we can continue the discussion but I think a majority wanted > preferred the separation. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MJAR-33) Jarsigner shows password on command line
Jarsigner shows password on command line Key: MJAR-33 URL: http://jira.codehaus.org/browse/MJAR-33 Project: Maven 2.x Jar Plugin Type: Bug Versions: 2.1 Reporter: Hes Siemelink When I sign a jar I see the password of the keystore in the debug output: [debug] jarsigner executable=[C:\Program Files\Java\jdk1.5.0_05\jre\..\bin\jarsigner.exe] [debug] Executing: "C:\Program Files\Java\jdk1.5.0_05\jre\..\bin\jarsigner.exe" -keystore my-keystore.pfx -storepas s SECRET_PASSPHRASE!! -storetype PKCS12 E:\Temp\jbossall-client-jboss-4.0.3.jar mykey It would be nice if this could be masked. I get this using the webstart plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MECLIPSE-75) Automatically add project to the workspace
Automatically add project to the workspace -- Key: MECLIPSE-75 URL: http://jira.codehaus.org/browse/MECLIPSE-75 Project: Maven 2.x Eclipse Plugin Type: Improvement Versions: 2.1 Reporter: Gilles Scokart Priority: Minor When eclipse.workspace is specified, the project should automatically be added to the workspace. The current workaround is : With eclipse 3.1, it is quiet easy to import multiple project. With previous version, the plugin http://eclipse-tools.sourceforge.net/projecttransfer could be used. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Timestamp plugin
Hi Jason,
Not much work has been done yet. I have created a really minimal version
of the plugin. Thats 7 lines of real code. Have a look at the plugin if
you want to, its attached to
https://issues.apache.org/jira/browse/GERONIMO-1659 . It may not be the
best way of doing it, but doubt there is any simpler way.
/Anders
Jason van Zyl wrote:
Anders Hessellund Jensen wrote:
I would like to be able to substitute timestamps with the build time
into a resource file. As I understand it, there is currently no plugin
to to this, so I consider writing one.
Sorry for not responding to this earlier, and I know that you've started
working on this plugin and I'd like to harness the work you've done but
I think what you are doing should be an extension to the resources
plugin. We should figure out how to augment filtering of resources. I
think the easiest way to do this is to filter the resources using Velocity.
This way additional tools can be created for swizzling resources and
this can all happen in one pass through velocity instead of having N
plugins which need to make N passes over the resources to filter them.
So I don't want to discourage you at all. Work on the plugin and I will
try to integrate your code into the resources plugin when you are done.
The other advantage of using Velocity in the resources plugin will allow
you to use Velocity directives in your resources so you can do any sort
of conditional logic you may want to have instead of simple
substitution. So I think we would benefit in two ways using Velocity
here: scalable addition of tools that can be used to swizzle resources
(a timestamp tool is a perfect example) and conditional logic which can
sometimes be useful like looking at a property introduced by a profile
and behave a certain way for example.
The plugin should leverage the existing resource filtering mechanism
of M2. The plugin would take a configuration like this:
build.date
.MM.dd
Running the plugin with this configuration would define the M2
property build.date, and any filtered resource file would get
${build.date} substituted with 2006.02.28 or whatever the date at
build time is.
WDYT?
Best regards,
Anders
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MECLIPSE-74) Workspace inspection when adding a project
Workspace inspection when adding a project -- Key: MECLIPSE-74 URL: http://jira.codehaus.org/browse/MECLIPSE-74 Project: Maven 2.x Eclipse Plugin Type: New Feature Versions: 2.1 Reporter: Gilles Scokart The eclipse plugin should lookup which project is present in a workspace and update/create the project in function of what is already present. *Scénario 1* : Module A use module B. Module B is already present as a project in the workspace. When adding A, the created project A should be dependent of the project B instead of dependent of the jar in the repository. *Scénario 2* : idem, but A is first added, then B. When B is added, the project A is updated in order to be dependent of B instead of the jar in the repository. *Scénario 3* : Add a goal to remove a project (and update dependencies accordingly). Of curse all those scenario should take into account the version numbers present in the poms inside the project. This is an alternative to MECLIPSE-32 . -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2119) SVN password in clear text
SVN password in clear text -- Key: MNG-2119 URL: http://jira.codehaus.org/browse/MNG-2119 Project: Maven 2 Type: Wish Components: POM Versions: 2.0.2 Environment: wintel Reporter: Borut Bolčina Priority: Minor Password in clear text, but it works. QUESTION: If SVN username is the same as system login username (windows), is there a way not to put password on display in pom.xml? org.codehaus.mojo changelog-maven-plugin 2.0-beta-2-SNAPSHOT scm:svn:http://acme.com/svn/repository/project/trunk PASSWORD -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven 1.0.1 fails tests that rely on signed jar files
Hi. I tried this on the users list, but on second thought, it's more likely that someone on the dev list knows about this bug. I have a test case that uses a signed jar file (bouncy castle JCE provider). This test case works fine from the command line, but fails when run via Maven: Testcase: testFunctionality(crypto.BCImplTest): Caused an ERROR The provider BC may not be signed by a trusted party java.lang.SecurityException: The provider BC may not be signed by a trusted party at javax.crypto.SunJCE_b.a(DashoA12275) at javax.crypto.Cipher.a(DashoA12275) at javax.crypto.Cipher.getInstance(DashoA12275) at crypto.BCImpl.encrypt(BCImpl.java:29) The application works as expected during normal runtime also, ie. this is a Maven only problem. Can anyone really insightful elaborate to me what's going on? This works for Maven only if I place the jar file in jre/lib/ext, so I'm guessing that this is a class loading issue of some sorts. Morten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Fri Mar 3 08:15:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060303.081501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060303.081501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
