[jira] Created: (MJXR-16) Jxr plugin failes build if no source directory is found
Jxr plugin failes build if no source directory is found --- Key: MJXR-16 URL: http://jira.codehaus.org/browse/MJXR-16 Project: Maven 2.x JXR Plugin Issue Type: Bug Reporter: Kaare Nilsen Priority: Critical When the jxr plugin does not find a source directory e.g. "src/main/java" it failes the build. This creates some serious side effects. For my project it ment that the release of our software failed, because we have several artifacts with no src/main/java dirs. eg. xmlbeans artifacts, and aspect libraries. The plugin should just log to debug that no sources was found for processing, and then continue the build -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1153) Please upload MessAdmin 4.0
Please upload MessAdmin 4.0 --- Key: MAVENUPLOAD-1153 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1153 Project: maven-upload-requests Issue Type: Task Reporter: codehauser Attachments: MessAdmin-Bundles.zip http://messadmin.sourceforge.net/maven2/MessAdmin-Core-4.0-bundle.jar http://messadmin.sourceforge.net/maven2/MessAdmin-ClickStream-4.0-bundle.jar http://messadmin.sourceforge.net/maven2/MessAdmin-JMX-4.0-bundle.jar http://messadmin.sourceforge.net/maven2/MessAdmin-Serializable-4.0-bundle.jar http://messadmin.sourceforge.net/maven2/MessAdmin-ServletStatsGatherer-4.0-bundle.jar http://messadmin.sourceforge.net/maven2/MessAdmin-SessionKiller-4.0-bundle.jar http://messadmin.sourceforge.net/ http://messadmin.sourceforge.net/#%5B%5BLicense%20%2F%20Contact%5D%5D MessAdmin is a light-weigth and non-intrusive tool for monitoring Java HttpSession. Version 4.0 will be used in AppFuse 2, which uses maven2. Please upload! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1154) WSDL4J 1.6.1
WSDL4J 1.6.1 Key: MAVENUPLOAD-1154 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1154 Project: maven-upload-requests Issue Type: Task Reporter: maomaode http://people.apache.org/~ningjiang/m2/repository/wsdl4j/1.6.1/wsdl4j-1.6.1.jar http://wsdl4j.sourceforge.net http://sourceforge.net/project/memberlist.php?group_id=128811 The Web Services Description Language for Java Toolkit (WSDL4J) allows the creation, representation, and manipulation of WSDL documents. Is the reference implementation for JSR110 'JWSDL' (jcp.org). Post questions/bugs to [EMAIL PROTECTED] Please upload. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-468) ability to consistently apply a toolchain across plugins
[ http://jira.codehaus.org/browse/MNG-468?page=comments#action_75831 ] Jason van Zyl commented on MNG-468: --- We need to have a way to select the toolchain for a particular project, and what netbeans does is allow you to set the toolchain that you want to use but will default to the one used to start up the IDE. So we can do something similar. > ability to consistently apply a toolchain across plugins > > > Key: MNG-468 > URL: http://jira.codehaus.org/browse/MNG-468 > Project: Maven 2 > Issue Type: New Feature >Reporter: Brett Porter > Assigned To: Jason van Zyl >Priority: Minor > Fix For: 2.1 > > Attachments: build.properties, project.properties > > > for things like the JDK, it may be desirable to compile, jar etc. across the > board with a particular version of the toolchain, other than the one > currently executing. It would be good to be able to configure this location > in the settings.xml and have the plugins use it, forking the compiler, using > a particular runtime, and generating an appropriate manifest. > This is likely to be relevant to other languages 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
[jira] Created: (SCM-236) add scm:add target to scm plugin
add scm:add target to scm plugin Key: SCM-236 URL: http://jira.codehaus.org/browse/SCM-236 Project: Maven SCM Issue Type: New Feature Components: maven-plugin Reporter: Julien HENRY Attachments: addTarget.patch Please add the scm:add target to the plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-468) ability to consistently apply a toolchain across plugins
[ http://jira.codehaus.org/browse/MNG-468?page=comments#action_75832 ] Jason van Zyl commented on MNG-468: --- We also need to account for things like J2ME, where you really need to use the tools provided there so things will work at runtime. > ability to consistently apply a toolchain across plugins > > > Key: MNG-468 > URL: http://jira.codehaus.org/browse/MNG-468 > Project: Maven 2 > Issue Type: New Feature >Reporter: Brett Porter > Assigned To: Jason van Zyl >Priority: Minor > Fix For: 2.1 > > Attachments: build.properties, project.properties > > > for things like the JDK, it may be desirable to compile, jar etc. across the > board with a particular version of the toolchain, other than the one > currently executing. It would be good to be able to configure this location > in the settings.xml and have the plugins use it, forking the compiler, using > a particular runtime, and generating an appropriate manifest. > This is likely to be relevant to other languages 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
[jira] Commented: (MNG-468) ability to consistently apply a toolchain across plugins
[ http://jira.codehaus.org/browse/MNG-468?page=comments#action_75833 ] Jason van Zyl commented on MNG-468: --- We also need to account for things like .net as the Java only toolchains are obviously not going to work for .net. We also need to account for other languages in general. > ability to consistently apply a toolchain across plugins > > > Key: MNG-468 > URL: http://jira.codehaus.org/browse/MNG-468 > Project: Maven 2 > Issue Type: New Feature >Reporter: Brett Porter > Assigned To: Jason van Zyl >Priority: Minor > Fix For: 2.1 > > Attachments: build.properties, project.properties > > > for things like the JDK, it may be desirable to compile, jar etc. across the > board with a particular version of the toolchain, other than the one > currently executing. It would be good to be able to configure this location > in the settings.xml and have the plugins use it, forking the compiler, using > a particular runtime, and generating an appropriate manifest. > This is likely to be relevant to other languages 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
[jira] Created: (MAVENUPLOAD-1155) Spring modules 0.6 bundles
Spring modules 0.6 bundles -- Key: MAVENUPLOAD-1155 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1155 Project: maven-upload-requests Issue Type: Task Reporter: Costin Leau https://springmodules.dev.java.net/files/documents/2803/41276/spring-modules-aop-0.6-bundle.jar https://springmodules.dev.java.net/files/documents/2803/41277/spring-modules-cache-0.6-bundle.jar https://springmodules.dev.java.net/files/documents/2803/41278/spring-modules-flux-0.6-bundle.jar https://springmodules.dev.java.net/files/documents/2803/41279/spring-modules-hivemind-0.6-bundle.jar https://springmodules.dev.java.net/files/documents/2803/41280/spring-modules-jakarta-commons-0.6-bundle.jar https://springmodules.dev.java.net/files/documents/2803/41281/spring-modules-javaspaces-0.6-bundle.jar https://springmodules.dev.java.net/files/documents/2803/41282/spring-modules-jbpm30-0.6-bundle.jar https://springmodules.dev.java.net/files/documents/2803/41283/spring-modules-jbpm31-0.6-bundle.jar https://springmodules.dev.java.net/files/documents/2803/41284/spring-modules-jcr-0.6-bundle.jar https://springmodules.dev.java.net/files/documents/2803/41285/spring-modules-jsr94-0.6-bundle.jar https://springmodules.dev.java.net/files/documents/2803/41286/spring-modules-lucene-0.6-bundle.jar https://springmodules.dev.java.net/files/documents/2803/41287/spring-modules-ojb-0.6-bundle.jar https://springmodules.dev.java.net/files/documents/2803/41288/spring-modules-orbroker-0.6-bundle.jar https://springmodules.dev.java.net/files/documents/2803/41289/spring-modules-osworkflow-0.6-bundle.jar https://springmodules.dev.java.net/files/documents/2803/41290/spring-modules-springmvc-extra-0.6-bundle.jar https://springmodules.dev.java.net/files/documents/2803/41291/spring-modules-tapestry-0.6-bundle.jar https://springmodules.dev.java.net/files/documents/2803/41292/spring-modules-template-0.6-bundle.jar https://springmodules.dev.java.net/files/documents/2803/41293/spring-modules-validation-0.6-bundle.jar https://springmodules.dev.java.net/files/documents/2803/41294/spring-modules-xt-0.6-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-237) Fix typo in plugin documentation examples
Fix typo in plugin documentation examples - Key: SCM-237 URL: http://jira.codehaus.org/browse/SCM-237 Project: Maven SCM Issue Type: Bug Components: maven-plugin Reporter: Julien HENRY Priority: Trivial Attachments: docPlugin.patch These errors are annoying when copy/pasting example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-793) Password validation
[ http://jira.codehaus.org/browse/CONTINUUM-793?page=all ] Lester Ecarma closed CONTINUUM-793. --- Resolution: Fixed > Password validation > --- > > Key: CONTINUUM-793 > URL: http://jira.codehaus.org/browse/CONTINUUM-793 > Project: Continuum > Issue Type: Sub-task >Reporter: Carlos Sanchez > Assigned To: Lester Ecarma > Fix For: 1.1 > > > Implement a validation process to the creation of passwords, probably a > bridge to commons-validation. > Note that it may not be enough to validate at the view layer as the model can > be called through xmlrpc. It needs to be done at the model layer. > For instance: > Minimum 7 character password length > Password must contain at least 1 alpha and 1 numeric character -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-237) Fix typo in plugin documentation examples
[ http://jira.codehaus.org/browse/SCM-237?page=all ] Julien HENRY updated SCM-237: - Attachment: docPlugin2.patch I miss some typo in the first patch > Fix typo in plugin documentation examples > - > > Key: SCM-237 > URL: http://jira.codehaus.org/browse/SCM-237 > Project: Maven SCM > Issue Type: Bug > Components: maven-plugin >Reporter: Julien HENRY >Priority: Trivial > Attachments: docPlugin.patch, docPlugin2.patch > > > These errors are annoying when copy/pasting example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-237) Fix typo in plugin documentation examples
[ http://jira.codehaus.org/browse/SCM-237?page=comments#action_75841 ] Julien HENRY commented on SCM-237: -- Please ignore the first patch. > Fix typo in plugin documentation examples > - > > Key: SCM-237 > URL: http://jira.codehaus.org/browse/SCM-237 > Project: Maven SCM > Issue Type: Bug > Components: maven-plugin >Reporter: Julien HENRY >Priority: Trivial > Attachments: docPlugin.patch, docPlugin2.patch > > > These errors are annoying when copy/pasting example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-238) Fix typo in message displayed when exception is thrown
Fix typo in message displayed when exception is thrown -- Key: SCM-238 URL: http://jira.codehaus.org/browse/SCM-238 Project: Maven SCM Issue Type: Bug Components: maven-plugin Affects Versions: 1.0 Reporter: Julien HENRY Priority: Trivial Attachments: fixErrorMessage.patch Some copy/paste errors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-892) Add a description on all fields
[ http://jira.codehaus.org/browse/CONTINUUM-892?page=all ] Emmanuel Venisse closed CONTINUUM-892. -- Assignee: Emmanuel Venisse (was: Maria Odea Ching) Resolution: Fixed Fix Version/s: 1.1 Applied. Thanks. > Add a description on all fields > --- > > Key: CONTINUUM-892 > URL: http://jira.codehaus.org/browse/CONTINUUM-892 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Reporter: Marvin King > Assigned To: Emmanuel Venisse > Fix For: 1.1 > > Attachments: CONTINUUM-892-continuum-weebapp.patch > > Original Estimate: 8 hours > Time Spent: 8 hours > Remaining Estimate: 0 minutes > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJAVADOC-92) Cant find javadoc.exe on windows in specific cases
[ http://jira.codehaus.org/browse/MJAVADOC-92?page=all ] Vincent Siveton closed MJAVADOC-92. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.1 fixed > Cant find javadoc.exe on windows in specific cases > -- > > Key: MJAVADOC-92 > URL: http://jira.codehaus.org/browse/MJAVADOC-92 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: xp, trunk >Reporter: Vincent Siveton > Assigned To: Vincent Siveton > Fix For: 2.1 > > > if you have several JDK/JRE, System.getProperty( "java.home" ) = JRE_HOME > defined in the windows registry and not the env variable JAVA_HOME > So javadoc.exe could not be found with getJavadocPath() > We need to lookup env variables -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-468) ability to consistently apply a toolchain across plugins
[ http://jira.codehaus.org/browse/MNG-468?page=comments#action_75855 ] Brett Porter commented on MNG-468: -- re: j2me comment - I think that's actually the original inspiration for this in general, so agreed. re: selection - won't this be declaring available toolchains in settings.xml and declaring required toolchain(s) in pom.xml as a new element? > ability to consistently apply a toolchain across plugins > > > Key: MNG-468 > URL: http://jira.codehaus.org/browse/MNG-468 > Project: Maven 2 > Issue Type: New Feature >Reporter: Brett Porter > Assigned To: Jason van Zyl >Priority: Minor > Fix For: 2.1 > > Attachments: build.properties, project.properties > > > for things like the JDK, it may be desirable to compile, jar etc. across the > board with a particular version of the toolchain, other than the one > currently executing. It would be good to be able to configure this location > in the settings.xml and have the plugins use it, forking the compiler, using > a particular runtime, and generating an appropriate manifest. > This is likely to be relevant to other languages 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
[jira] Created: (MNGECLIPSE-199) Is repository indexing really worthy?
Is repository indexing really worthy? - Key: MNGECLIPSE-199 URL: http://jira.codehaus.org/browse/MNGECLIPSE-199 Project: Maven 2.x Extension for Eclipse Issue Type: Wish Components: Repository Management Environment: Windows Reporter: Akbarr Priority: Minor Every time I start Eclipse, it spends a long time indexing my M2 repository. I think this is done only for the "Add dependency" window, but I'm not sure. The point is that I don't use this window, but rather edit the POM file manually, and so it's a problem for me to wait several minutes every time I start Eclipse. I think it would be interesting to add an option in the preferences window for disabling the repository indexing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-145) dependencyManagement in parent poms broken in eclipse on linux
[ http://jira.codehaus.org/browse/MNGECLIPSE-145?page=comments#action_75863
]
vincenzo cerbone commented on MNGECLIPSE-145:
-
I had also the same problem on a project of my own. It happens when I specify
the ${project.version} as version on a father POM in the section
dependencyManagement for children POMs (so that children inherit it without
having to declare it again..)
> dependencyManagement in parent poms broken in eclipse on linux
> --
>
> Key: MNGECLIPSE-145
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-145
> Project: Maven 2.x Extension for Eclipse
> Issue Type: Bug
> Components: Dependency Resolver
>Affects Versions: 0.0.9
>Reporter: Scott Cytacki
> Attachments: pom.xml
>
>
> This is a weird one. I don't know if it is a maven embedder bug or an
> eclipse plugin bug. I attached a test pom.
> This pom has a single dependency on org.codehaus.xfire:xfire-java5
> From the command line I can run mvn compile and it downloads the correct
> xfire artifacts. I tried it both with maven 2.0.2 and 2.0.4
> When I enable maven on the project in eclipse using 0.0.9 maven plugin,
> eclipse 3.2RC5, linux. It fails saying it cant find:
> org.codehaus.xfire:xfire-core:jar:2.4.1
> org.codehaus.xfire:xfire-aegis:jar:2.4.1
> org.codehaus.xfire:xfire-annotations:jar:2.4.1
> When I try the same thing on maven plugin 0.0.9, eclipse 3.2RC7, intel mac.
> It works fine.
> I looked into the xfire poms, and they are using a fancy dependency setup.
> xfire-java5 dependends on xfire-core but it doesn't specifiy a version
> number. The version is supposed to be pulled from the dependency management
> in the parent pom: xfire-parent. Actually the dependency management section
> of the xfire-parent doesn't have the version for each dependency instead it
> uses: ${version}. Which I assume pulles the version from xfire-parent
> itself. So some how this double indirection of version number is confusing
> only linux. It could also be the version of eclipse.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-137) Developed RAD-6 Plugin Extention
[ http://jira.codehaus.org/browse/MECLIPSE-137?page=comments#action_75867 ] Mike Reynolds commented on MECLIPSE-137: to install this plugin (at least at the time of this post), you must first comment out all of the existing repository configurations (there are 5 I believe...just do a search for "central" in the project..) after you have it installed into your local m2 repository, you can run: at.uniqa.maven.plugin:maven-rad-plugin:clean at.uniqa.maven.plugin:maven-rad-plugin:rad6 It doesn't look like this project supports portlet development yet...can I help? I'd imagine the update would be pretty trivial (since web projects already are working) > Developed RAD-6 Plugin Extention > > > Key: MECLIPSE-137 > URL: http://jira.codehaus.org/browse/MECLIPSE-137 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Reporter: Richard van Nieuwenhoven > Attachments: maven-rad-plugin.tar.gz > > > I just finisched developing a RAD-6 (IBM Rational Application Developer 6.0) > extention to the eclipse plugin. > It supports J2EE projects with the websphere development envorment, supported > are > - EJB projects > - Web projects > - EAR- projects > all these projects are recognized by rad-6 as what they. The websphere > development enviorment including hot-deployment features funktions out of the > box. > i wrote writers for: > - the ".j2ee" files > - the "application.xml" and the "modulemaps" file > - copying the extrenal libs in the ear project root > - adapting the MANIFEST.MF of the projects (nessesary for the websphere > development enviorment) > - the ".websettings" file > - the ".websiteconfig" file > - the ".project" (only alternative project natures/builders) > do you want to include it the the eclipse plugin or sould it be an extra > plugin? i should not be complicated to include it because i did the real work > in writer-classes. > should i add a tgz with the sources? or how do you want the sources? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPSCM-87) CLONE -NPE while performing a scm:prepare-release goal
CLONE -NPE while performing a scm:prepare-release goal -- Key: MPSCM-87 URL: http://jira.codehaus.org/browse/MPSCM-87 Project: maven-scm-plugin Issue Type: Bug Environment: Mac OS X, JSDK 1.4.2 Reporter: Stefan Cordes Assigned To: Brett Porter Fix For: 1.2 NPE while performing a scm:prepare-release goal >From the trace it appears that the NPE is taking place in the >release.VersionTransformer.transformRequired(VersionTransformer.java:136) Here is the trace from running the scm:prepare-release goal: [...] What is the new tag name? release_from_maven_0_2 What is the new version? [release_from_maven_0_2] 2.5.2 Verifying valid tag name [cvs] Using cvs passfile: /Users/sebastiensahuc/.cvspass [cvs] T project.xml ASTIdentifier : java.lang.reflect.InvocationTargetException 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.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:304) at org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:56) at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:106) at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:88) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:123) at org.apache.commons.jelly.expression.jexl.JexlExpression.evaluate(JexlExpression.java:115) at org.apache.commons.jelly.expression.jexl.JexlExpressionFactory$ExpressionSupportLocal.evaluate(JexlExpressionFactory.java:168) at org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:130) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:117) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:143) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:165) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:117) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:143) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:572) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:304) at org.apache.maven.cli.App.doMain(App.java:505) at org.apache.maven.cli.App.main(App.java:1156) 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 com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Caused by: java.lang.NullPointerException at org.apache.maven.release.VersionTransformer.transformRequired(VersionTransformer.java:136) ... 44 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPSCM-87) CLONE -NPE while performing a scm:prepare-release goal
[ http://jira.codehaus.org/browse/MPSCM-87?page=comments#action_75886 ] Stefan Cordes commented on MPSCM-87: The Nullpointer happens again with scm plugin 1.5 when adding http://maven.apache.org/POM/3.0.0";> as described in http://maven.apache.org/maven-1.x/plugins/pom/validation.html -- STACKTRACE scm:prepare-release: [echo] Verifying no modifications are present [INFO] Executing: cvs -f -n -q update -d [INFO] Working directory: c:\workspaces\trend51-maven\o4-upload ASTIdentifier : java.lang.reflect.InvocationTargetException java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code)) at java.lang.reflect.Method.invoke(Method.java(Compiled Code)) at org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:304) at org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:56) at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java(Compiled Code)) at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:88) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:123) at org.apache.commons.jelly.expression.jexl.JexlExpression.evaluate(JexlExpression.java:115) at org.apache.commons.jelly.expression.jexl.JexlExpressionFactory$ExpressionSupportLocal.evaluate(JexlExpressionFactory.java:168) at org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:130) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) at org.apache.maven.cli.App.doMain(App.java:488) at org.apache.maven.cli.App.main(App.java:1239) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) at java.lang.reflect.Method.invoke(Method.java:391) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java(Inlined Compiled Code)) at java.util.ArrayList.get(ArrayList.java(Compiled Code)) at org.apache.maven.release.VersionTransformer.transformRequired(VersionTransformer.java:112) ... 41 more -- STACKTRACE > CLONE -NPE while performing a scm:prepare-release goal > -- > > Key: MPSCM-87 > URL: http://jira.codehaus.org/browse/MPSCM-87 > Project: maven-scm-plugin > Issue Type: Bug > Environment: Mac OS X, JSDK 1.4.2 >Reporter: Stefan Cordes > Assigned To: Brett Porter > Fix For: 1.2 > > > NPE while performing a scm:prepare-release goal > From the trace it appears that the NPE is taking place in the > release.VersionTransformer.transformRequired(Ve
[jira] Commented: (MPSCM-87) CLONE -NPE while performing a scm:prepare-release goal
[ http://jira.codehaus.org/browse/MPSCM-87?page=comments#action_75888 ] Stefan Cordes commented on MPSCM-87: Correction: Not a Nullpointer happens, but an IndexOutOfBoundsException on a similar line mentioned in the previous issue. > CLONE -NPE while performing a scm:prepare-release goal > -- > > Key: MPSCM-87 > URL: http://jira.codehaus.org/browse/MPSCM-87 > Project: maven-scm-plugin > Issue Type: Bug > Environment: Mac OS X, JSDK 1.4.2 >Reporter: Stefan Cordes > Assigned To: Brett Porter > Fix For: 1.2 > > > NPE while performing a scm:prepare-release goal > From the trace it appears that the NPE is taking place in the > release.VersionTransformer.transformRequired(VersionTransformer.java:136) > Here is the trace from running the scm:prepare-release goal: > [...] > What is the new tag name? > release_from_maven_0_2 > What is the new version? [release_from_maven_0_2] > 2.5.2 > Verifying valid tag name > [cvs] Using cvs passfile: /Users/sebastiensahuc/.cvspass > [cvs] T project.xml > ASTIdentifier : java.lang.reflect.InvocationTargetException > 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.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:304) > at org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:56) > at > org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:106) > at > org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:88) > at > org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:123) > at > org.apache.commons.jelly.expression.jexl.JexlExpression.evaluate(JexlExpression.java:115) > at > org.apache.commons.jelly.expression.jexl.JexlExpressionFactory$ExpressionSupportLocal.evaluate(JexlExpressionFactory.java:168) > at org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:130) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) > at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) > at > org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:117) > at > org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:143) > at com.werken.werkz.Goal.fire(Goal.java:639) > at com.werken.werkz.Goal.attain(Goal.java:575) > at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) > at > org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:165) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) > at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) > at > org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:117) > at > org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:143) > at com.werken.werkz.Goal.fire(Goal.java:639) > at com.werken.werkz.Goal.attain(Goal.java:575) > at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) > at > org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:572) > at org.apache.maven.MavenSession.attainGoals(MavenSession.java:304) > at org.apache.maven.cli.App.doMain(App.java:505) > at org.apache.maven.cli.App.main(App.java:1156) > 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 com.werken.forehead.Forehead.run(Forehead.java:551) > at com.werken.forehead.Forehead.main(Forehead.java:581) > Caused by: java.lang.NullPointer
[jira] Commented: (MSUREFIRE-58) Cannot override read-only parameter: classpathElements
[ http://jira.codehaus.org/browse/MSUREFIRE-58?page=comments#action_75898 ]
Zarar Siddiqi commented on MSUREFIRE-58:
OK, I'm trying to run StrutsTestCase with Maven 2.x and need the web.xml and
struts-config.xml to be in the classpath, which they are not by default.
So, I have the following configuration for the surefire plugin:
org.apache.maven.plugins
maven-surefire-plugin
2.2
target/${project.artifactId}-${project.version}
And this expectedly yields:
Error configuring: org.apache.maven.plugins:maven-surefire-plugin. Reason:
ERROR: Cannot override read-only parameter: classpathElements in goal:
surefire:test
The reason this is expected is because an explanation is provided here:
http://www.nabble.com/testing-webapp-with-surefire-tf519140.html#a1403158
Brett Porter has recommended requesting another element called
additionalClasspathElements to be added which would not be read-only and thus
allow for additional classpath elements to be added.
I tried that using the following but it didn't get me anywhere.
target/${project.artifactId}-${project.version}
Any ideas?
> Cannot override read-only parameter: classpathElements
> --
>
> Key: MSUREFIRE-58
> URL: http://jira.codehaus.org/browse/MSUREFIRE-58
> Project: Maven 2.x Surefire Plugin
> Issue Type: Bug
>Affects Versions: 2.1.2
>Reporter: Jesper Zedlitz
>Priority: Minor
> Fix For: 2.3
>
>
> 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
[jira] Commented: (MCHECKSTYLE-45) It should be possible to configure checkstyle:check to fail on "warnings".
[ http://jira.codehaus.org/browse/MCHECKSTYLE-45?page=comments#action_75916 ] Jacob Robertson commented on MCHECKSTYLE-45: Let me describe my situation. First off, we use one common checkstyle.xml definition hosted on an internal http server. This same checkstyle.xml is consumed by both the eclipse-cs plugin (as we develop in eclipse) and by maven both when continuum kicks it off and when we run it locally. However, we were very unhappy with using "error" on any of our checks, because in the IDE it was showing up so as to mask whether it was a true build error or just a checkstyle error. We fought with that for a while, and in the end just changed our checkstyle.xml to declare globally that all checks were just warnings. But now we would also like to explore the possibility of having maven "break the build" when the checkstyle *warnings* show up. Here is the rationale: while developing in eclipse, we want things to show up as warnings to make our IDE experience livable. However, once we go to check something in, we know that all those warnings must be cleared up or we'll break the build. This way, we get the best of both worlds. All I'm trying to do is demonstrate a practical, real-world scenario under which this feature would be useful. > It should be possible to configure checkstyle:check to fail on "warnings". > -- > > Key: MCHECKSTYLE-45 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-45 > Project: Maven 2.x Checkstyle Plugin > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: Fabian Bauschulte > Attachments: MCHECKSTYLE-45-maven-checkstyle-plugin.patch > > > As mentioned in MCHECKSTYLE-38 it should be possible to configure that > "checkstyle:check" fails on warnings or not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MIDEA-67) SCM connection URLs that use the pipe character as a delimiter are not handled
SCM connection URLs that use the pipe character as a delimiter are not handled -- Key: MIDEA-67 URL: http://jira.codehaus.org/browse/MIDEA-67 Project: Maven 2.x Idea Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Dennis Lundberg Sometimes it is necessary to use the pipe character as the delimiter in an SCM connection URL. This is allowed by maven-scm. The maven-idea-plugin does not handle this at all. So a correct SCM connection URL might be ignored and the VCS will not be set in the workspace file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MIDEA-67) SCM connection URLs that use the pipe character as a delimiter are not handled
[ http://jira.codehaus.org/browse/MIDEA-67?page=all ] Dennis Lundberg closed MIDEA-67. Resolution: Fixed Fix Version/s: 2.1 Added a test case to highlight the problem and added support for the pipe character as a delimiter in SCM connection URLs. > SCM connection URLs that use the pipe character as a delimiter are not handled > -- > > Key: MIDEA-67 > URL: http://jira.codehaus.org/browse/MIDEA-67 > Project: Maven 2.x Idea Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Dennis Lundberg > Assigned To: Dennis Lundberg > Fix For: 2.1 > > > Sometimes it is necessary to use the pipe character as the delimiter in an > SCM connection URL. This is allowed by maven-scm. The maven-idea-plugin does > not handle this at all. So a correct SCM connection URL might be ignored and > the VCS will not be set in the workspace file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MIDEA-66) CVS support wrongly configured in IWS files due to upper/lowercase mismatch
[ http://jira.codehaus.org/browse/MIDEA-66?page=all ] Dennis Lundberg closed MIDEA-66. Resolution: Fixed Fix Version/s: 2.1 o Add translations from SCM type in Maven SCM connection URLs to IDEA VCS name format, for all 5 version control systems supported by IDEA 5.1. o Add test cases. > CVS support wrongly configured in IWS files due to upper/lowercase mismatch > --- > > Key: MIDEA-66 > URL: http://jira.codehaus.org/browse/MIDEA-66 > Project: Maven 2.x Idea Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: IntelliJ 4.1 and 5.1 >Reporter: Siegfried Goeschl > Assigned To: Dennis Lundberg >Priority: Minor > Fix For: 2.1 > > > The generated IWS file contains a line > > which forces you to manually enable CVS for this project within IntelliJ > where as > > would be correct -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MIDEA-40) war module-dependencies are jarred and copied to /WEB-INF/classes
[ http://jira.codehaus.org/browse/MIDEA-40?page=all ] Dennis Lundberg closed MIDEA-40. Resolution: Fixed Fix Version/s: 2.0 Closing at reporters request. Feel free to open another issue if you feel that the property is important. > war module-dependencies are jarred and copied to /WEB-INF/classes > - > > Key: MIDEA-40 > URL: http://jira.codehaus.org/browse/MIDEA-40 > Project: Maven 2.x Idea Plugin > Issue Type: Bug >Reporter: Geoffrey De Smet > Fix For: 2.0 > > > A mulitproject with a jar module A and a war module B, where B depends on A, > will be configured so that: > In web module settings, under "Modules and libraries to package": > module A : JAR module output and copy file to: /WEB-INF/classes > This should either be > module A : copy module output to: /WEB-INF/classes > or > module A : JAR module output and copy file to: /WEB-INF/lib/jarname.jar > Both should be supported a believe, as the second one mimics maven and the > real way of doing it, but the first one is a lot faster -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MIDEA-58) Improved support for IDEA's JUnit Plugin
[ http://jira.codehaus.org/browse/MIDEA-58?page=all ]
Dennis Lundberg updated MIDEA-58:
-
Priority: Minor (was: Major)
> Improved support for IDEA's JUnit Plugin
>
>
> Key: MIDEA-58
> URL: http://jira.codehaus.org/browse/MIDEA-58
> Project: Maven 2.x Idea Plugin
> Issue Type: Improvement
>Reporter: James Talmage
>Priority: Minor
>
> I added this snippet to workspace.xml, and now IDEA's JUnit plugin behaves in
> accordance with Maven's standard directory layout.
> Clicking "create JUnit Test for this method", will now create the test file
> under src/test instead of src/main.
> {code:title=src/main/resources/templates/default/workspace.xml|borderStyle=solid}
> ...
>
>
>testClass="src/test/java/$DIRECTORY$/$CLASS$Test" />
>
>
> ...
> {code}
> I haven't tested it on a version of IDEA that doesn't have the JUnit plugin
> installed, but my understanding is that it will just be ignored.
> You can configure these settings as the default in IDEA ({color:blue}File |
> Template Project Settings{color}) . But those are global (it would affect
> non-maven projects). In lieu of making the above changes, adding a
> recommendation to change IDEA's default settings in the plugin documentation
> could be helpful to some users.
> Possible Enhancements:
> * Offer support for non standard directory layouts.
> * Allow additional patterns to be specified in the POM
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MIDEA-63) Goal 'idea' requires modules to be installed in order to generate module dependencies in the IDEA project file
[ http://jira.codehaus.org/browse/MIDEA-63?page=all ] Dennis Lundberg closed MIDEA-63. Resolution: Duplicate > Goal 'idea' requires modules to be installed in order to generate module > dependencies in the IDEA project file > -- > > Key: MIDEA-63 > URL: http://jira.codehaus.org/browse/MIDEA-63 > Project: Maven 2.x Idea Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Norman Fomferra >Priority: Minor > > The goal 'idea' requires modules in a multi-module project to be installed in > order to generate module dependencies in the IDEA project file. You must >mvn clean install idea:idea > in order to create functioning IDEA module files. Actually the should be > sufficient >mvn clean package idea:idea > as it is for the eclipse plug-in. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-64) Provided dependencies are also copied to /WEB-INF/lib
[ http://jira.codehaus.org/browse/MIDEA-64?page=comments#action_75947 ] Dennis Lundberg commented on MIDEA-64: -- Geoffrey, which version of IDEA are you using? I found a comment in the plugin source that says IDEA 5.0.2 is buggy when it comes to reading this part of the module file. > Provided dependencies are also copied to /WEB-INF/lib > - > > Key: MIDEA-64 > URL: http://jira.codehaus.org/browse/MIDEA-64 > Project: Maven 2.x Idea Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Geoffrey De Smet > Attachments: screenshot-1.jpg > > > A dependency with the scope "provided" (and probably "system" too) is also > marked as to be copied to /WEB-INF/lib for webapp 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
[jira] Commented: (MIDEA-60) Keep attached sources when replacing libraries in module
[ http://jira.codehaus.org/browse/MIDEA-60?page=comments#action_75948 ] Dennis Lundberg commented on MIDEA-60: -- Hi David I have followed the steps (1-5 + 'mvn idea:module') that you mention, but I cannot reproduce this issue. The sources are still there after running 'mvn idea:module'. I'm using the latest svn version of the maven-idea-plugin, built from source. > Keep attached sources when replacing libraries in module > > > Key: MIDEA-60 > URL: http://jira.codehaus.org/browse/MIDEA-60 > Project: Maven 2.x Idea Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: David Hay > Attachments: ideatest-after-module-rebuild.jar, ideatest-log.txt, > ideatest-with-source.jar > > > Many times, the dependencies downloaded by Maven do not have corresponding > source jars. So I download the source separately and attach it to the > dependencies in my module. However, if I regenerate the module, those source > attachments are lost. > I'd like to see the Idea plugin (perhaps optionally) keep any source or > javadoc attachments that have been made. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1156) Please upload HSQLDB 1.8.0.7
Please upload HSQLDB 1.8.0.7 Key: MAVENUPLOAD-1156 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1156 Project: maven-upload-requests Issue Type: Task Reporter: Binary42 Developers Attachments: hsqldb-1.8.0.7-ibiblio.jar Bug fixes on version 1.8.0.5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGECLIPSE-197) Shortcut key is used for two different options ("Download Artifact Sources" and "Download Artifact JavaDoc") under Windows -> Preferences -> Maven2
[ http://jira.codehaus.org/browse/MNGECLIPSE-197?page=all ]
Eugene Kuleshov closed MNGECLIPSE-197.
--
Assignee: Eugene Kuleshov
Resolution: Fixed
Fix Version/s: 0.0.10
> Shortcut key is used for two different options ("Download Artifact Sources"
> and "Download Artifact JavaDoc") under Windows -> Preferences -> Maven2
> ---
>
> Key: MNGECLIPSE-197
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-197
> Project: Maven 2.x Extension for Eclipse
> Issue Type: Bug
>Affects Versions: 0.0.9
>Reporter: Jimisola Laursen
> Assigned To: Eugene Kuleshov
>Priority: Trivial
> Fix For: 0.0.10
>
>
> Under Windows -> Preferences -> Maven2 the shortcut key "D" is used for two
> different options:
> "Download Artifact Sources"
> "Download Artifact JavaDoc"
> (a project component for configuration would be useful)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGECLIPSE-195) Error Loading Eclipse Preference page after installing Maven plugin
[ http://jira.codehaus.org/browse/MNGECLIPSE-195?page=all ] Eugene Kuleshov closed MNGECLIPSE-195. -- Resolution: Duplicate > Error Loading Eclipse Preference page after installing Maven plugin > --- > > Key: MNGECLIPSE-195 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-195 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug >Affects Versions: 0.0.9 > Environment: Windows XP, Eclipse 3.2 >Reporter: Dan > Attachments: maven_error.JPG > > > Error verifying plugin installation. See attached screenshot. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-196) Dependency with ejb type doesn't appead in classpath container at all when dependent project is located at Eclipse workspace
[ http://jira.codehaus.org/browse/MNGECLIPSE-196?page=comments#action_75963 ] Eugene Kuleshov commented on MNGECLIPSE-196: Please attach example Eclipse projects with Maven's poms required to reproduce this issue. Thanks. > Dependency with ejb type doesn't appead in classpath container at all when > dependent project is located at Eclipse workspace > > > Key: MNGECLIPSE-196 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-196 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug > Components: Dependency Resolver >Affects Versions: 0.0.10 >Reporter: Tuomas Kiviaho > > The user experience with typed dependencies differs from previous releases > that didn't include workspace resolving. I've only verified that type ejb > behaves as described below but I could imagine that other types and propably > classified dependencies as well will behave similarly. > Console contains following line: > :pom:: resolved to Eclipse workspace - found at > \\pom.xml > This leads to "The import cannot be resolved" error on every single > class reference pointing to dependent workspace project and these classes do > not compile. The whole dependent project is missing from the classpath > container. The previous version of the plugin did resolve the dependency from > repository without any problems whatsoever. > When type specification is removed the result is: > :jar:: resolved to Eclipse workspace - found at > \\pom.xml > Now references appear to be ok, but the pom.xml is of course not correct > anymore. Claspath container contains the dependent project, but since the > workspace projects do not fold open as the repository dependencies I can't > tell wether or not the hack is really working 100%. It would be great if > there is a way to make workspace project dependencies to fold open at least > as far as seeing the source folders as we do under Debug As... and on > Sources panel. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGECLIPSE-199) Is repository indexing really worthy?
[ http://jira.codehaus.org/browse/MNGECLIPSE-199?page=all ] Eugene Kuleshov closed MNGECLIPSE-199. -- Resolution: Fixed Fix Version/s: 0.0.10 > Is repository indexing really worthy? > - > > Key: MNGECLIPSE-199 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-199 > Project: Maven 2.x Extension for Eclipse > Issue Type: Wish > Components: Repository Management > Environment: Windows >Reporter: Akbarr >Priority: Minor > Fix For: 0.0.10 > > > Every time I start Eclipse, it spends a long time indexing my M2 repository. > I think this is done only for the "Add dependency" window, but I'm not sure. > The point is that I don't use this window, but rather edit the POM file > manually, and so it's a problem for me to wait several minutes every time I > start Eclipse. I think it would be interesting to add an option in the > preferences window for disabling the repository indexing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNGECLIPSE-199) Reindexing local repository on startup is slow
[ http://jira.codehaus.org/browse/MNGECLIPSE-199?page=all ] Eugene Kuleshov updated MNGECLIPSE-199: --- Summary: Reindexing local repository on startup is slow (was: Is repository indexing really worthy?) > Reindexing local repository on startup is slow > -- > > Key: MNGECLIPSE-199 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-199 > Project: Maven 2.x Extension for Eclipse > Issue Type: Wish > Components: Repository Management > Environment: Windows >Reporter: Akbarr >Priority: Minor > Fix For: 0.0.10 > > > Every time I start Eclipse, it spends a long time indexing my M2 repository. > I think this is done only for the "Add dependency" window, but I'm not sure. > The point is that I don't use this window, but rather edit the POM file > manually, and so it's a problem for me to wait several minutes every time I > start Eclipse. I think it would be interesting to add an option in the > preferences window for disabling the repository indexing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-198) resolveClasspathEntries performance bug
[ http://jira.codehaus.org/browse/MNGECLIPSE-198?page=comments#action_75964 ] Eugene Kuleshov commented on MNGECLIPSE-198: Why people are using those graphs when simple tree is just as good, byt way more compact and readable?... Anyways, I wonder how many dependencies your project has and how many of those actually have javadocs deployed? BTW, looking at your graph, slow part isn't really resolveClasspathEntries, but getMavenEmbedder(), which creates embedder every time (not sure what is underneath and you can dig into that if you want). I'll look at reusing embedder within unit of work when will be integrating new embedder build... > resolveClasspathEntries performance bug > --- > > Key: MNGECLIPSE-198 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-198 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug > Components: Dependency Resolver >Affects Versions: 0.0.10 > Environment: Eclipse 3.2 for Windows >Reporter: Marek Bieganski > Attachments: call_graph.zip > > > Most of time used by resolveClasspathEntries method is wasted for resolving > javadoc urls. > I attached call graps from jprofiler. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGECLIPSE-184) invalid relativePath references in pom causes an incorrectly handled NPE
[ http://jira.codehaus.org/browse/MNGECLIPSE-184?page=all ] Eugene Kuleshov closed MNGECLIPSE-184. -- Resolution: Cannot Reproduce Please feel free to reopen this when you can provide information to reproduce issue. Thank you. > invalid relativePath references in pom causes an incorrectly handled NPE > > > Key: MNGECLIPSE-184 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-184 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug >Reporter: Scott Cytacki > > If the project.parent.relativePath is not valid the following NPE is thrown. > The m2eclispe plugin currently handles this by displaying an error on the pom > with a descrption of NullPointerException. It seems this is a bug in the > maven embedder, but in the meantime the m2eclipse plugin could at least log > the exception better. > java.lang.NullPointerException > at > org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1075) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:676) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:418) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:194) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildWithDependencies(DefaultMavenProjectBuilder.java:305) > at > org.apache.maven.embedder.MavenEmbedder.readProjectWithDependencies(MavenEmbedder.java:330) > at > org.maven.ide.eclipse.Maven2Plugin$ReadProjectTask.run(Maven2Plugin.java:577) > at > org.maven.ide.eclipse.Maven2Plugin.executeInEmbedder(Maven2Plugin.java:185) > at > org.maven.ide.eclipse.Maven2Plugin.resolveClasspathEntries(Maven2Plugin.java:388) > at > org.maven.ide.eclipse.Maven2Plugin.resolveClasspathEntries(Maven2Plugin.java:461) > at > org.maven.ide.eclipse.container.Maven2ClasspathContainerInitializer$1.run(Maven2ClasspathContainerInitializer.java:83) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-192) Exit code 1 - 'ssh' is not recognized as an internal or external command,
[ http://jira.codehaus.org/browse/MNGECLIPSE-192?page=comments#action_75966 ] Eugene Kuleshov commented on MNGECLIPSE-192: And how do we suppose to put it all together? Please make required amount of guessing as small as possible. Thanks in advance. BTW, I am not sure if you've noticed, but settings.xml you attached here is not well formed XML... > Exit code 1 - 'ssh' is not recognized as an internal or external command, > - > > Key: MNGECLIPSE-192 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-192 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug > Components: Maven Launcher >Affects Versions: 0.0.9 > Environment: WIN XP SP2. Eclipse 3.2 Maven eclipse extension 0.0.9 >Reporter: Klingon Coder > Attachments: pom.xml, SampleMojo.java, settings.xml > > > [INFO] > > [INFO] Building Dimensions Auto Build Application > [INFO]task-segment: [deploy] > [INFO] > > [INFO] plugin:descriptor > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 2 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [INFO] resources:resources > [INFO] Using default encoding to copy filtered resources. > [INFO] compiler:compile > [INFO] Nothing to compile - all classes are up to date > [INFO] resources:testResources > [INFO] Using default encoding to copy filtered resources. > [INFO] compiler:testCompile > [INFO] No sources to compile > [INFO] surefire:test > [INFO] No tests to run. > [INFO] jar:jar > [INFO] Building jar: > C:\workspace\dimensions-maven-plugin\target\dimensions-maven-plugin-1.0.jar > [INFO] plugin:addPluginArtifactMetadata > [INFO] install:install > [INFO] Installing > C:\workspace\dimensions-maven-plugin\target\dimensions-maven-plugin-1.0.jar > to C:\Documents and > Settings\user\.m2\repository\com\AutoBuild\dimensions-maven-plugin\1.0\dimensions-maven-plugin-1.0.jar > [INFO] plugin:updateRegistry > [INFO] deploy:deploy > [ERROR] mojo-execute : deploy:deploy > Diagnosis: Error deploying artifact: Error executing command for transfer > FATAL ERROR: Error executing Maven for a project > [ERROR] project-execute : > com.AutoBuild:dimensions-maven-plugin:maven-plugin:1.0 ( task-segment: > [deploy] ) > Diagnosis: Error deploying artifact: Error executing command for transfer > FATAL ERROR: Error executing Maven for a project > org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying > artifact: Error executing command for transfer > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > 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) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:441) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:382) > at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:68) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error deploying > artifact: Error executing command for transfer > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:145) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > ... 8 more > Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: > Error deploying artifact: Error executing command for transfer > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:91) > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:133) > ... 10 more > Caused by: org.apache.maven.wagon.TransferFailedException: Error executing > command for transfer > at > org.apache.maven.wagon.providers.sshext.ScpExternalWagon.put(ScpExternalWagon.java:342) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManag
[jira] Created: (WAGONHTTP-13) Allow username and password inputs to http
Allow username and password inputs to http -- Key: WAGONHTTP-13 URL: http://jira.codehaus.org/browse/WAGONHTTP-13 Project: wagon-http Issue Type: Improvement Affects Versions: 1.0-alpha-6 Environment: Any Reporter: Todd Nine Some teams will need repositories available via the web, but will not want their repository publicly available. They can secure their repository with BASIC or DIGEST authentication. I can be configured via settings.xml in the following way. Server settings maven2 maven test01 Profile Repositories true true maven2 Maven repository http://maven.mycompany.com default If the repository Id matches a server id, then the username and password can be used in both basic and digest mode. For digest specs, see the RFC here. http://www.ietf.org/rfc/rfc2617.txt -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSUREFIRE-58) Cannot override read-only parameter: classpathElements
[ http://jira.codehaus.org/browse/MSUREFIRE-58?page=all ] Zarar Siddiqi updated MSUREFIRE-58: --- Attachment: additionalClasspaths.patch I've created a patch against revision 450675 which fixes this issue and allows you to specify additional classpaths: org.apache.maven.plugins maven-surefire-plugin path/to/additional/resources This patch does pretty much the same thing as the one supplied in MSUREFIRE-153 but I can't understand why that one hasn't been applied. I'm using this for now. > Cannot override read-only parameter: classpathElements > -- > > Key: MSUREFIRE-58 > URL: http://jira.codehaus.org/browse/MSUREFIRE-58 > Project: Maven 2.x Surefire Plugin > Issue Type: Bug >Affects Versions: 2.1.2 >Reporter: Jesper Zedlitz >Priority: Minor > Fix For: 2.3 > > Attachments: additionalClasspaths.patch > > > 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
[jira] Closed: (MNG-1827) mvn cli bash script doesn't work in mingw
[ http://jira.codehaus.org/browse/MNG-1827?page=all ] Jason van Zyl closed MNG-1827. -- Resolution: Fixed Patch applied on trunk and 2.0.x branch > mvn cli bash script doesn't work in mingw > --- > > Key: MNG-1827 > URL: http://jira.codehaus.org/browse/MNG-1827 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0, 2.0.1 > Environment: http://www.mingw.org/ under windows. >Reporter: Juan F. Codagnone > Assigned To: Jason van Zyl > Fix For: 2.2 > > Attachments: MNG-1827.diff, MNG-1827.diff > > > mvn does not work if it is lunched from the bash that comes in the msys migwn > environment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MIDEA-68) if a dependency is not found, it doesn't fail but excludes legitimate dependencies
if a dependency is not found, it doesn't fail but excludes legitimate dependencies -- Key: MIDEA-68 URL: http://jira.codehaus.org/browse/MIDEA-68 Project: Maven 2.x Idea Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Brett Porter to reproduce: - have a multiproject with a module not installed - mvn idea:idea from the root - it will succeed, but the module file for the module that depends on the missing artifact contains module dependencies, but no jar dependencies -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNGECLIPSE-196) Dependency with ejb type doesn't appead in classpath container at all when dependent project is located at Eclipse workspace
[ http://jira.codehaus.org/browse/MNGECLIPSE-196?page=all ] Tuomas Kiviaho updated MNGECLIPSE-196: -- Attachment: DudeWhereIsMyCar.pom Car.pom Attached two pom.xml that represent Eclipse workspace projects. When type ejb is removed from the depencency the dependent project starts appearing in the classpath container. > Dependency with ejb type doesn't appead in classpath container at all when > dependent project is located at Eclipse workspace > > > Key: MNGECLIPSE-196 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-196 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug > Components: Dependency Resolver >Affects Versions: 0.0.10 >Reporter: Tuomas Kiviaho > Attachments: Car.pom, DudeWhereIsMyCar.pom > > > The user experience with typed dependencies differs from previous releases > that didn't include workspace resolving. I've only verified that type ejb > behaves as described below but I could imagine that other types and propably > classified dependencies as well will behave similarly. > Console contains following line: > :pom:: resolved to Eclipse workspace - found at > \\pom.xml > This leads to "The import cannot be resolved" error on every single > class reference pointing to dependent workspace project and these classes do > not compile. The whole dependent project is missing from the classpath > container. The previous version of the plugin did resolve the dependency from > repository without any problems whatsoever. > When type specification is removed the result is: > :jar:: resolved to Eclipse workspace - found at > \\pom.xml > Now references appear to be ok, but the pom.xml is of course not correct > anymore. Claspath container contains the dependent project, but since the > workspace projects do not fold open as the repository dependencies I can't > tell wether or not the hack is really working 100%. It would be great if > there is a way to make workspace project dependencies to fold open at least > as far as seeing the source folders as we do under Debug As... and on > Sources panel. -- 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
