[jira] Commented: (MNGECLIPSE-77) Add support for WSAD specifics on a J2EE project.
[ http://jira.codehaus.org/browse/MNGECLIPSE-77?page=comments#action_71343 ] Nicolas Peeters commented on MNGECLIPSE-77: --- Are you guys aware of that? http://jira.codehaus.org/browse/MECLIPSE-137 It looks pretty promising! Add support for WSAD specifics on a J2EE project. - Key: MNGECLIPSE-77 URL: http://jira.codehaus.org/browse/MNGECLIPSE-77 Project: Maven 2.x Extension for Eclipse Issue Type: New Feature Reporter: Joakim Erdfelt Priority: Minor Attachments: sample-projects-wsad6.x.tar.bz2 Need the ability to support the WSAD / J2EE specific configurations. The Eclipse extension needs to either ... # map the WSAD / J2EE project directory structure to a Maven pom. This way allows the user to use the WSAD J2EE wizards. # map a Maven J2EE pom to the WSAD / J2EE project configuration. This way makes Maven the start of all J2EE applications. This could be done by Eclipse extension specifics, or with the use of pre-defined Archetypes that show up on the New Project / Maven Archetype Wizards within 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: (MCHANGELOG-40) Review and revise plugin documentation
[ http://jira.codehaus.org/browse/MCHANGELOG-40?page=comments#action_71348 ] Maria Odea Ching commented on MCHANGELOG-40: The plugin docs have been revised and the staging site has been updated (http://people.apache.org/~oching/maven-changelog-plugin). Thanks :) Review and revise plugin documentation -- Key: MCHANGELOG-40 URL: http://jira.codehaus.org/browse/MCHANGELOG-40 Project: Maven 2.x Changelog Plugin Issue Type: Task Reporter: Maria Odea Ching Assigned To: Maria Odea Ching Fix For: 2.0 Original Estimate: 20 hours Time Spent: 10 hours Remaining Estimate: 10 hours -- 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: (MPMULTIPROJECT-69) report failed throwing NullPointerException invoking getProjects
report failed throwing NullPointerException invoking getProjects Key: MPMULTIPROJECT-69 URL: http://jira.codehaus.org/browse/MPMULTIPROJECT-69 Project: maven-multiproject-plugin Issue Type: Bug Affects Versions: 1.5 Environment: maven 1.1-beta-3-SNAPSHOT (20060729), windows 2000 Reporter: Piotr Kania Priority: Blocker running command maven site for project containing report maven-multiproject-plugin following error occurs: multiproject:dependency-convergence-report: BUILD FAILED org.apache.velocity.exception.MethodInvocationException: Invocation of method 'getProjects' in clas s org.apache.maven.multiproject.harmonizer.MultiDependency threw exception class java.lang.NullPoint erException : null at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:246) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:175) at org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:327) at org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:131) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:114) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:55) at org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:166) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:114) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:55) at org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:166) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:114) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:230) at org.apache.velocity.Template.merge(Template.java:256) at org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:450) at org.apache.commons.jelly.tags.velocity.MergeTag.mergeTemplate(MergeTag.java:186) at org.apache.commons.jelly.tags.velocity.MergeTag.doTag(MergeTag.java:68) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag .java:115) at org.apache.maven.werkz.Goal.fire(Goal.java:647) at org.apache.maven.werkz.Goal.attain(Goal.java:582) at org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:208) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:114) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag .java:115) at org.apache.maven.werkz.Goal.fire(Goal.java:647) at org.apache.maven.werkz.Goal.attain(Goal.java:582) at org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:208) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:114) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:42) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[jira] Created: (MPXDOC-197) report fails if repository is not defined
report fails if repository is not defined
-
Key: MPXDOC-197
URL: http://jira.codehaus.org/browse/MPXDOC-197
Project: maven-xdoc-plugin
Issue Type: Bug
Affects Versions: 1.10
Environment: maven 1.1-beta-3-SNAPSHOT(20060729), Operating system
Windows 2000
Reporter: Piotr Kania
If project definition contain empty repository tag then report fails:
Project definition
?xml version=1.0 encoding=UTF-8?
project
pomVersion3/pomVersion
artifactIdrfl-project-main/artifactId
nameRFL Project Main/name
groupId${groupId}/groupId
currentVersion${version}/currentVersion
repository
/repository
reports
reportmaven-faq-plugin/report
reportmaven-multiproject-plugin/report
reportmaven-dashboard-plugin/report
/reports
/project
xdoc:register-reports:
faq:init:
maven-faq-plugin:register:
xdoc:generate-from-pom:
[echo] Generating xdocs from POM ...
BUILD FAILED
org.apache.velocity.exception.ResourceNotFoundException: Unable to find
resource 'scm/${connscm}.xml
'
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl
.java:458)
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.
java:341)
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:831)
at org.apache.velocity.runtime.directive.Parse.render(Parse.java:141)
at
org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:114)
at
org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:55)
at
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:230)
at
org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:89)
at
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:230)
at org.apache.velocity.Template.merge(Template.java:256)
at
org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:450)
at
org.apache.commons.jelly.tags.velocity.MergeTag.mergeTemplate(MergeTag.java:186)
at
org.apache.commons.jelly.tags.velocity.MergeTag.doTag(MergeTag.java:68)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag
.java:115)
at org.apache.maven.werkz.Goal.fire(Goal.java:647)
at org.apache.maven.werkz.Goal.attain(Goal.java:582)
at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:494)
at org.apache.maven.werkz.Goal.attain(Goal.java:580)
at org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:208)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:114)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag
.java:115)
at org.apache.maven.werkz.Goal.fire(Goal.java:647)
at org.apache.maven.werkz.Goal.attain(Goal.java:582)
at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:709)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:264)
at org.apache.maven.cli.App.doMain(App.java:546)
at org.apache.maven.cli.App.main(App.java:1390)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
[jira] Commented: (MNG-2471) Add search box to the index page
[ http://jira.codehaus.org/browse/MNG-2471?page=comments#action_71353 ] Marvin King commented on MNG-2471: -- the search box will only search within the maven site. Add search box to the index page Key: MNG-2471 URL: http://jira.codehaus.org/browse/MNG-2471 Project: Maven 2 Issue Type: Improvement Components: Documentation: General Reporter: Marvin King Assigned To: Marvin King Attachments: index.html, MNG-2471-site.patch - google for now -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2471) Add search box to the index page
[ http://jira.codehaus.org/browse/MNG-2471?page=comments#action_71361 ] Denis Cabasson commented on MNG-2471: - Now, that is a big box!!! Isn't there a way to make the Google logo a bit smaller? (I guess there are legals considerations there). For the design part, I would prefer 2 separate boxes for search and download. Would it be possible to add a radio button to include search in the mojo.codehaus.org domain (in addition to maven.apache.org) (maybe legal considerations there too)? Add search box to the index page Key: MNG-2471 URL: http://jira.codehaus.org/browse/MNG-2471 Project: Maven 2 Issue Type: Improvement Components: Documentation: General Reporter: Marvin King Assigned To: Marvin King Attachments: index.html, MNG-2471-site.patch - google for now -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-137) Developed RAD-6 Plugin Extention
[ http://jira.codehaus.org/browse/MECLIPSE-137?page=all ] Richard van Nieuwenhoven updated MECLIPSE-137: -- Attachment: maven-rad-plugin.tar.gz sorry that it took so long but i was not at work... this is the tarball with the plugin. some hints for RAD6 users - do not use java classes in a war project, put all java classes in dependent projects - best thing to do is to make all jars in the war project provided and put them in the ear dependencys - there will be a classpath directory included in ejb projects here you can put your generated ejb classes for nor i use the websphere-ant jobs in the project-pom to generate them. (in the package phase overwiting the jar and the client-jar and copieing the classes to the classes-folder included by this plugin, the ant-job does not generate the java files...) - the META-INF of the ejb project MUST!!! be a toplevel folder so include this top-level-folder in your resources list of the pom (the java files can stay in src/main/java - don't forget to fill the .cvsignore files especialy the jar's and wars in the ear-project's and the war-project's regards, Ritchie 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] Updated: (MANTRUN-55) Review Plugin Documentation
[ http://jira.codehaus.org/browse/MANTRUN-55?page=all ] Franz Allan Valencia See updated MANTRUN-55: Attachment: MANTRUN-55-maven-antrun-plugin-3.patch Changes with MANTRUN-55-maven-antrun-plugin-3.patch In usage.html * maven.dependency.classpath (Reported by Vincent Siveton) * Review inheritRefs (Reported by Vincent Siveton) - it seems that there is bug here (from what i can dig up in the maven user's mailing list) such that referencing maven.xxx.classpath's within the build.xml does not work. thus, i changed the example to a workaround (assigning the maven.xxx.classpath's value to an ant property). Furthermore, this page may not be needed in the future once Vincent Siventon's submits his example of using external build.xml * changed maven-dependencies-plugin to maven-dependency-plugin In FAQ.html * Maven for Ant Users is for Maven1 and it's link is wrong (Reported by Vincent Siventon) - thus, i removed this link Review Plugin Documentation --- Key: MANTRUN-55 URL: http://jira.codehaus.org/browse/MANTRUN-55 Project: Maven 2.x Antrun Plugin Issue Type: Task Reporter: Allan Ramirez Assigned To: Allan Ramirez Attachments: MANTRUN-55-maven-antrun-plugin-2.patch, MANTRUN-55-maven-antrun-plugin-3.patch, MANTRUN-55-maven-antrun-plugin.patch Original Estimate: 12 hours Remaining Estimate: 12 hours -- 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: (MAVEN-1755) Backward Incompability : Usage of xml entities in the POM doesn't work in maven 1.1 beta 1 2
[ http://jira.codehaus.org/browse/MAVEN-1755?page=comments#action_71367 ] Arnaud Heritier commented on MAVEN-1755: I'll try them. Thx for the idea. Backward Incompability : Usage of xml entities in the POM doesn't work in maven 1.1 beta 1 2 -- Key: MAVEN-1755 URL: http://jira.codehaus.org/browse/MAVEN-1755 Project: Maven Issue Type: Bug Components: core Affects Versions: 1.1-beta-2, 1.1-beta-1, 1.1-beta-3 Reporter: Arnaud Heritier Assigned To: Arnaud Heritier Priority: Critical Attachments: project-entities.zip In maven 1.0.X it was possible to use entities in the POM. It was used for example to share some elements like the organization, ... -- 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: (MAVEN-1125) ant:java fork issues
[ http://jira.codehaus.org/browse/MAVEN-1125?page=comments#action_71366 ] Arnaud Heritier commented on MAVEN-1125: I 'll have a look at this issue ant:java fork issues Key: MAVEN-1125 URL: http://jira.codehaus.org/browse/MAVEN-1125 Project: Maven Issue Type: Bug Affects Versions: 1.0-rc2 Environment: Linux, JDK1.4.2 Reporter: Andy Jefferson Assigned To: Arnaud Heritier Attachments: maven-console-test.jar I have a Java app that I want to invoke via Maven. The Java app uses stdin and stdout. If I invoke using ant:java using fork=true then stdin doesn not respond correctly. That is, the app prompts, but the user can type to their hearts content and nothing reaches the app. If I invoke using ant:java using fork=false then I get strange XML related errors about unresolved references org/w3c/dom/Node, org/w3c/dom/Document -- 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-1027) Upload Rhino 1.6R3 to ibiblio
Upload Rhino 1.6R3 to ibiblio - Key: MAVENUPLOAD-1027 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1027 Project: maven-upload-requests Issue Type: Task Reporter: Matt Whitlock http://www.mattwhitlock.com/js-1.6R3-bundle.jar http://www.mozilla.org/rhino/ Rhino is an open-source implementation of JavaScript written entirely in Java. It is typically embedded into Java applications to provide scripting to end users. The web site has not yet been updated to reflect the 1.6R3 release, but it is available at the download site: ftp://ftp.mozilla.org/pub/mozilla.org/js/ The 1.6R3 download on that FTP site has a modification date of 24 July 2006. -- 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: (MSITE-158) Review and revise plugin documentation
[ http://jira.codehaus.org/browse/MSITE-158?page=all ] Maria Odea Ching closed MSITE-158. -- Resolution: Fixed Review and revise plugin documentation -- Key: MSITE-158 URL: http://jira.codehaus.org/browse/MSITE-158 Project: Maven 2.x Site Plugin Issue Type: Task Reporter: Maria Odea Ching Assigned To: Maria Odea Ching Original Estimate: 1 day, 9 hours Time Spent: 1 day, 6 hours Remaining Estimate: 3 hours -- 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-79) Review plugin documentation
[ http://jira.codehaus.org/browse/MJAVADOC-79?page=all ] Maria Odea Ching closed MJAVADOC-79. Resolution: Fixed Review plugin documentation --- Key: MJAVADOC-79 URL: http://jira.codehaus.org/browse/MJAVADOC-79 Project: Maven 2.x Javadoc Plugin Issue Type: Task Reporter: Maria Odea Ching Assigned To: Maria Odea Ching Attachments: MJAVADOC-79-alternate-doclet-wsmoak.diff Time Spent: 1 day, 10 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] Commented: (MAVENUPLOAD-1024) sigh.. another upload of testng 5.0.1 (please)
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1024?page=comments#action_71372 ] Carlos Sanchez commented on MAVENUPLOAD-1024: - actually it's better a zip with the contents of the folder eg. the contents of http://www.ibiblio.org/maven2/org/testng/testng/5.0.1/ The script we have doesn't handle the classifiers sigh.. another upload of testng 5.0.1 (please) -- Key: MAVENUPLOAD-1024 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1024 Project: maven-upload-requests Issue Type: Task Reporter: Jesse Kuhnert Assigned To: Carlos Sanchez Attachments: testng-5.0.1-jdk14.jar, testng-5.0.1-jdk15.jar, testng.zip I screwed up the last 5.0.1 set of jars by not including the testng dtd file in the jars. These two attached jars should resolve that issue. (if ibiblio allows overwrites) -- 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: (MRAR-12) Review Plugin Documentation
[ http://jira.codehaus.org/browse/MRAR-12?page=all ] Allan Ramirez closed MRAR-12. - Resolution: Fixed Applied Patch. Thanks! Review Plugin Documentation --- Key: MRAR-12 URL: http://jira.codehaus.org/browse/MRAR-12 Project: Maven 2.x Rar Plugin Issue Type: Task Reporter: Allan Ramirez Assigned To: Allan Ramirez Attachments: MRAR-12-maven-rar-plugin.patch Original Estimate: 14 hours Time Spent: 19 hours, 30 minutes 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] Created: (MDEP-31) ERROR: Cannot override read-only parameter: scope in goal: dependency:copy-dependencies
ERROR: Cannot override read-only parameter: scope in goal:
dependency:copy-dependencies
Key: MDEP-31
URL: http://jira.codehaus.org/browse/MDEP-31
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Reporter: David J. M. Karlsen
http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html
states that scope is a valid (and writable) configuration element, but the
following configuration:
plugins
plugin
artifactIdmaven-dependency-plugin/artifactId
version2.0-SNAPSHOT/version
executions
execution
idcopy-dependencies/id
phasepackage/phase
goals
goalcopy-dependencies/goal
/goals
configuration
excludeTransitivetrue/excludeTransitive
scopecompile/scope
/configuration
/execution
/executions
/plugin
/plugins
will fail with:
[snip...]
Building index for all classes...
Generating
C:/dnbnorapi/kildekode/utvikling/dnbnorapi-client/target/site/apidocs\allclasses-frame.html...
Generating
C:/dnbnorapi/kildekode/utvikling/dnbnorapi-client/target/site/apidocs\allclasses-noframe.html...
Generating
C:/dnbnorapi/kildekode/utvikling/dnbnorapi-client/target/site/apidocs\index.html...
Generating
C:/dnbnorapi/kildekode/utvikling/dnbnorapi-client/target/site/apidocs\help-doc.html...
Generating
C:/dnbnorapi/kildekode/utvikling/dnbnorapi-client/target/site/apidocs\stylesheet.css...
[INFO] Building jar:
C:\dnbnorapi\kildekode\utvikling\dnbnorapi-client\target\dnbnorapi-client-1.0-SNAPSHOT-javadoc.jar
[INFO] [jar:test-jar {execution: default}]
[INFO] Building jar:
C:\dnbnorapi\kildekode\utvikling\dnbnorapi-client\target\dnbnorapi-client-1.0-SNAPSHOT-tests.jar
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error configuring: org.apache.maven.plugins:maven-dependency-plugin.
Reason: ERROR: Cannot override read-only par
ameter: scope in goal: dependency:copy-dependencies
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 minute 3 seconds
[INFO] Finished at: Wed Aug 02 13:09:21 CEST 2006
[INFO] Final Memory: 13M/27M
[INFO]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPJAR-55) possibility to add arbitrary elements to the manifest classpath
possibility to add arbitrary elements to the manifest classpath --- Key: MPJAR-55 URL: http://jira.codehaus.org/browse/MPJAR-55 Project: maven-jar-plugin Issue Type: Improvement Reporter: Michel Verbist Priority: Minor I want to add '.' (the current directory) to the classpath. The main reason for this is to be able to access files like log4j.properties hibernate.cfg.xml ... outside the jar, so I don't have to rebuild my jar if, e.g., I want to increase the log4j level for a particular class. Or ask my client over the phone to increase the level and send me the log file. The only thing I came up with was this possible improvement: current config of the manifest: configuration archive manifest addClasspathtrue/addClasspath mainClassbe.brail.b38c.loadtester.AppLoadTester/mainClass /manifest /archive /configuration possible extension of manifest config configuration archive manifest addClasspathtrue/addClasspath additionalClasspathEntries classpathEntry.//classpathEntry classpathEntryhelp//classpathEntry classpathEntryresources//classpathEntry /additionalClasspathEntries mainClassbe.brail.b38c.loadtester.AppLoadTester/mainClass /manifest /archive /configuration By adding public List org.apache.maven.archiver.ManifestConfiguration.getAdditionalClasspathEntries() people could be allowed to add not only the dependent jars to the classpath but also any arbitrary 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
[jira] Commented: (CONTINUUM-618) Refresh after Build Now create multiple builds
[ http://jira.codehaus.org/browse/CONTINUUM-618?page=comments#action_71383 ] Bugittaa Pahasti commented on CONTINUUM-618: I'll get two builds every time I do a forced build, even without refresh. The log has many warnings or errors, like: [defaultScheduler_Worker-13] WARN Continuum - Cycle detected while sorting projects for building, falling back to unsorted build. [SocketListener0-3] WARN SQL- Object with id 0 not found ! [SocketListener0-3] WARN ViewContextPopulator - Cannot find a value for the expression getProject(#id)in [EMAIL PROTECTED] [SocketListener0-3] ERROR VelocityComponent - Method addPathInfo threw exception for reference $link in template screens/ProjectBuilds.vm at [14,26] [SocketListener0-3] ERROR Renderer:velocity - Error rendering template: INFO | jvm 1| 2006/08/02 14:46:39 | java.lang.NullPointerException INFO | jvm 1| 2006/08/02 14:46:39 | at org.codehaus.plexus.summit.util.UriBuilder.addPathInfo(UriBuilder.java:263) Don't know if this is related to this refresh bug. Happens with Continuum 1.0.3 and Firefox 1.5.0.x (all minor versions including the latest 1.5.0.5). Refresh after Build Now create multiple builds Key: CONTINUUM-618 URL: http://jira.codehaus.org/browse/CONTINUUM-618 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.0.3 Environment: xp Reporter: Dan Tran Fix For: 1.1 After hitting build now, the browser pauses for sometime and user loses patient by hitting multiple refreshes creating multiple forced builds For a long build, it can be very annoyed. Worst, we user put up a daily release build in Continuum, it will cause multiple release builds -- 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-153) Ability to add additions to classpath
[ http://jira.codehaus.org/browse/MSUREFIRE-153?page=all ] David J. M. Karlsen updated MSUREFIRE-153: -- Attachment: SurefirePlugin.java-diff Patch which appends arbritary elements to the surefire classpaths Ability to add additions to classpath - Key: MSUREFIRE-153 URL: http://jira.codehaus.org/browse/MSUREFIRE-153 Project: Maven 2.x Surefire Plugin Issue Type: Improvement Environment: N/A Reporter: David J. M. Karlsen Attachments: SurefirePlugin.java-diff There should be a possibility to add arbritary resources to the classpath while executing the tests. These resources would only be available while executing the tests, so they won't be added in the archive. i suggest a configuration element extendedClasspaths extendedClasspathsome/path/extendedClasspath extendedClasspath/some/other/path/extendedClasspath /extendedClasspaths This issue somewhat related to http://jira.codehaus.org/browse/MJAR-13 / ability to exclude/include filtering in archiver/jar-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: (MNGECLIPSE-77) Add support for WSAD specifics on a J2EE project.
[ http://jira.codehaus.org/browse/MNGECLIPSE-77?page=comments#action_71394 ] Andrew Perepelytsya commented on MNGECLIPSE-77: --- Well, I have the WSAD extensions in the works. You know, it's different from RAD or Eclipse ;) Just a preview of what is already available: * Generates .project, .classpath files from the pom.xml model with WSAD natures and builders * Enables WebSphere AS 5.1 J2EE targeting for projects * Enables EJB Client module preference by default * Adds M2_REPO classpath variable to WSAD workspace (it's different from what Eclipse 3.x plugin does) * Configures JDK compliance to be 1.4 level * Enables multiple output paths for the compiler to accomodate m2 folder layout * Switches the workspace to JDK 1.4 (IBM one), and ensures all projects use it, and not 1.3 (the default one) I will check the MECLIPSE-137 to see if some logic can be reused. Add support for WSAD specifics on a J2EE project. - Key: MNGECLIPSE-77 URL: http://jira.codehaus.org/browse/MNGECLIPSE-77 Project: Maven 2.x Extension for Eclipse Issue Type: New Feature Reporter: Joakim Erdfelt Priority: Minor Attachments: sample-projects-wsad6.x.tar.bz2 Need the ability to support the WSAD / J2EE specific configurations. The Eclipse extension needs to either ... # map the WSAD / J2EE project directory structure to a Maven pom. This way allows the user to use the WSAD J2EE wizards. # map a Maven J2EE pom to the WSAD / J2EE project configuration. This way makes Maven the start of all J2EE applications. This could be done by Eclipse extension specifics, or with the use of pre-defined Archetypes that show up on the New Project / Maven Archetype Wizards within 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] Updated: (MNG-2471) Add search box to the index page
[ http://jira.codehaus.org/browse/MNG-2471?page=all ] Marvin King updated MNG-2471: - Attachment: index-without-logo-with-mojocodehausoption.html - applied dennis's suggestion Add search box to the index page Key: MNG-2471 URL: http://jira.codehaus.org/browse/MNG-2471 Project: Maven 2 Issue Type: Improvement Components: Documentation: General Reporter: Marvin King Assigned To: Marvin King Attachments: index-without-logo-with-mojocodehausoption.html, index.html, MNG-2471-site.patch - google for now -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2471) Add search box to the index page
[ http://jira.codehaus.org/browse/MNG-2471?page=all ] Marvin King updated MNG-2471: - Attachment: site-without-logo-with-mojocodehausoption.css Add search box to the index page Key: MNG-2471 URL: http://jira.codehaus.org/browse/MNG-2471 Project: Maven 2 Issue Type: Improvement Components: Documentation: General Reporter: Marvin King Assigned To: Marvin King Attachments: index-without-logo-with-mojocodehausoption.html, index.html, MNG-2471-site.patch, site-without-logo-with-mojocodehausoption.css - google for now -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2471) Add search box to the index page
[ http://jira.codehaus.org/browse/MNG-2471?page=all ] Marvin King updated MNG-2471: - Attachment: (was: index-without-logo-with-mojocodehausoption.html) Add search box to the index page Key: MNG-2471 URL: http://jira.codehaus.org/browse/MNG-2471 Project: Maven 2 Issue Type: Improvement Components: Documentation: General Reporter: Marvin King Assigned To: Marvin King Attachments: index-without-logo-with-mojocodehausoption.html, index.html, MNG-2471-site.patch, site-without-logo-with-mojocodehausoption.css - google for now -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1026) JHighlight 1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1026?page=all ] Carlos Sanchez closed MAVENUPLOAD-1026. --- Assignee: Carlos Sanchez Resolution: Fixed JHighlight 1.0 -- Key: MAVENUPLOAD-1026 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1026 Project: maven-upload-requests Issue Type: Task Reporter: Hervé BOUTEMY Assigned To: Carlos Sanchez stable version 1.0 of the library -- 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: (MPMULTIPROJECT-69) report failed throwing NullPointerException invoking getProjects
[ http://jira.codehaus.org/browse/MPMULTIPROJECT-69?page=comments#action_71400 ] Lukas Theussl commented on MPMULTIPROJECT-69: - We'll need more information to reproduce this (eg what's in the parent pom?). Please try to attach a small test project that demonstrates the problem. report failed throwing NullPointerException invoking getProjects Key: MPMULTIPROJECT-69 URL: http://jira.codehaus.org/browse/MPMULTIPROJECT-69 Project: maven-multiproject-plugin Issue Type: Bug Affects Versions: 1.5 Environment: maven 1.1-beta-3-SNAPSHOT (20060729), windows 2000 Reporter: Piotr Kania Priority: Blocker running command maven site for project containing report maven-multiproject-plugin following error occurs: multiproject:dependency-convergence-report: BUILD FAILED org.apache.velocity.exception.MethodInvocationException: Invocation of method 'getProjects' in clas s org.apache.maven.multiproject.harmonizer.MultiDependency threw exception class java.lang.NullPoint erException : null at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:246) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:175) at org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:327) at org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:131) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:114) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:55) at org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:166) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:114) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:55) at org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:166) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:114) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:230) at org.apache.velocity.Template.merge(Template.java:256) at org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:450) at org.apache.commons.jelly.tags.velocity.MergeTag.mergeTemplate(MergeTag.java:186) at org.apache.commons.jelly.tags.velocity.MergeTag.doTag(MergeTag.java:68) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag .java:115) at org.apache.maven.werkz.Goal.fire(Goal.java:647) at org.apache.maven.werkz.Goal.attain(Goal.java:582) at org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:208) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:114) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag .java:115) at org.apache.maven.werkz.Goal.fire(Goal.java:647) at org.apache.maven.werkz.Goal.attain(Goal.java:582) at org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:208) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:114) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:42) at
[jira] Updated: (MPXDOC-197) report fails if repository is not defined
[ http://jira.codehaus.org/browse/MPXDOC-197?page=all ]
Lukas Theussl updated MPXDOC-197:
-
Assignee: Lukas Theussl
Fix Version/s: 1.10.1
report fails if repository is not defined
-
Key: MPXDOC-197
URL: http://jira.codehaus.org/browse/MPXDOC-197
Project: maven-xdoc-plugin
Issue Type: Bug
Affects Versions: 1.10
Environment: maven 1.1-beta-3-SNAPSHOT(20060729), Operating system
Windows 2000
Reporter: Piotr Kania
Assigned To: Lukas Theussl
Fix For: 1.10.1
If project definition contain empty repository tag then report fails:
Project definition
?xml version=1.0 encoding=UTF-8?
project
pomVersion3/pomVersion
artifactIdrfl-project-main/artifactId
nameRFL Project Main/name
groupId${groupId}/groupId
currentVersion${version}/currentVersion
repository
/repository
reports
reportmaven-faq-plugin/report
reportmaven-multiproject-plugin/report
reportmaven-dashboard-plugin/report
/reports
/project
xdoc:register-reports:
faq:init:
maven-faq-plugin:register:
xdoc:generate-from-pom:
[echo] Generating xdocs from POM ...
BUILD FAILED
org.apache.velocity.exception.ResourceNotFoundException: Unable to find
resource 'scm/${connscm}.xml
'
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl
.java:458)
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.
java:341)
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:831)
at org.apache.velocity.runtime.directive.Parse.render(Parse.java:141)
at
org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:114)
at
org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:55)
at
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:230)
at
org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:89)
at
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:230)
at org.apache.velocity.Template.merge(Template.java:256)
at
org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:450)
at
org.apache.commons.jelly.tags.velocity.MergeTag.mergeTemplate(MergeTag.java:186)
at
org.apache.commons.jelly.tags.velocity.MergeTag.doTag(MergeTag.java:68)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
at
org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag
.java:115)
at org.apache.maven.werkz.Goal.fire(Goal.java:647)
at org.apache.maven.werkz.Goal.attain(Goal.java:582)
at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:494)
at org.apache.maven.werkz.Goal.attain(Goal.java:580)
at
org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:208)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:114)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag
.java:115)
at org.apache.maven.werkz.Goal.fire(Goal.java:647)
at org.apache.maven.werkz.Goal.attain(Goal.java:582)
at
[jira] Commented: (MPWAR-62) maven-war-plugin doesn't compile java sources when used with maven-test-plugin 1.8
[ http://jira.codehaus.org/browse/MPWAR-62?page=comments#action_71417 ] nicolas de loof commented on MPWAR-62: -- Latest patch should also solve this. I'll try it ASAP. maven-war-plugin doesn't compile java sources when used with maven-test-plugin 1.8 --- Key: MPWAR-62 URL: http://jira.codehaus.org/browse/MPWAR-62 Project: maven-war-plugin Issue Type: Bug Affects Versions: 1.6.2 Reporter: nicolas de loof Assigned To: Lukas Theussl Fix For: 1.6.3 Attachments: MPWAR-62, MPWAR-62.patch I've found an issue when using latest versions of maven-test-plugin (1.8) : when maven.test.skip=true is set, the test:compile goal is not executed. This sounds good, BUT the maven-war-plugin use test:test goal to attain the java:compile goal, so the generated war has no classes ! The war:resources plugin should have prereqs=war:war-resources,*java:compile*,test:test. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-801) Maven2: Add Project Homepage URL to the project info page and build result page.
Maven2: Add Project Homepage URL to the project info page and build result page. Key: CONTINUUM-801 URL: http://jira.codehaus.org/browse/CONTINUUM-801 Project: Continuum Issue Type: Improvement Components: Web interface Affects Versions: 1.0.3 Reporter: Sharmarke Aden Priority: Minor Attachments: continuum_webinterface_homepage.patch In maven 2 you can specify a URL for your project's homepage in the pom.xml. It would be nice if a link to this URL could be show on the project info page and the build result page of continuum web interface. Attached is a patch that adds a row containing project homepage to both View.vm and ProjectBuild.vm if the property $project.url exists. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-137) proposed SCM release tag or label in multiproject
[ http://jira.codehaus.org/browse/MRELEASE-137?page=all ]
Matthew Beermann updated MRELEASE-137:
--
Attachment: patch.txt
This seems like a relatively straightforward fix - the root project is last on
the list, not first. Could someone get this checked in?
proposed SCM release tag or label in multiproject
-
Key: MRELEASE-137
URL: http://jira.codehaus.org/browse/MRELEASE-137
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-4
Reporter: Gilles Scokart
Priority: Minor
Attachments: patch.txt
If we have
- pom.xml (name : root)
--- module1
pom.xml (name : module1)
--- module2
pom.xml (name : module1)
and we prepare a release at the root level, the name proposed for the tag is
module1-${version} instead root-${version}.
Note that except the name, everything is stored as expected with SVN.
NB: I don't know if it has an impact, but the pom in module1 and module
doesn't inherit from the root (no parent tags).
--
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: (MPDIST-29) src distribution archive has incorrect directory structure
src distribution archive has incorrect directory structure
--
Key: MPDIST-29
URL: http://jira.codehaus.org/browse/MPDIST-29
Project: maven-dist-plugin
Issue Type: Bug
Affects Versions: 1.7
Reporter: Jarkko Viinamäki
With Maven 1.1-beta-2 and maven-dist-plugin-1.7:
if my project.xml defines:
build
sourceDirectorysrc/main/java/sourceDirectory
...
Then the dist:build-src target generates an incorrect src distribution file
since the source files are packaged to path src/foo/bar/MyClass.java instead of
src/main/java/foo/bar/MyClass.java
-
To fix this, change the dist:prepare-src-filesystem goal in
maven-dist-plugin-1.7 to read:
util:available file=src
ant:copy todir=${maven.dist.src.assembly.dir}/src
ant:fileset dir=src /
/ant:copy
/util:available
This will preserve the actual directory structure.
--
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: (MAVEN-1768) wrong directory structure in src distribution package (maven-dist-plugin-1.7)
[ http://jira.codehaus.org/browse/MAVEN-1768?page=comments#action_71421 ]
Jarkko Viinamäki commented on MAVEN-1768:
-
Ah sorry. I didn't notice that there are separate Jira areas for all plugins.
Reported this to the maven-dist-plugin subproject. This issue can be
closed/deleted.
wrong directory structure in src distribution package (maven-dist-plugin-1.7)
-
Key: MAVEN-1768
URL: http://jira.codehaus.org/browse/MAVEN-1768
Project: Maven
Issue Type: Bug
Components: core
Affects Versions: 1.1-beta-2
Reporter: Jarkko Viinamäki
With Maven 1.1-beta-2 and maven-dist-plugin-1.7:
if my project.xml defines:
build
sourceDirectorysrc/main/java/sourceDirectory
...
Then the dist:build-src target generates an incorrect src distribution file
since the source files are packaged to path src/foo/bar/MyClass.java instead
of src/main/java/foo/bar/MyClass.java
--
To fix this, change the dist:prepare-src-filesystem goal in
maven-dist-plugin-1.7 to read:
util:available file=src
ant:copy todir=${maven.dist.src.assembly.dir}/src
ant:fileset dir=src /
/ant:copy
/util:available
This will preserve the actual directory structure.
--
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: (MDEP-32) -Sibling Dependency Not Included in copy-dependencies output during multi-project build
-Sibling Dependency Not Included in copy-dependencies output during multi-project build --- Key: MDEP-32 URL: http://jira.codehaus.org/browse/MDEP-32 Project: Maven 2.x Dependency Plugin Issue Type: Bug Reporter: Matt Brozowski Assigned To: Kenney Westerhof Fix For: 1.1 Using the following structure dependency-test - module1 - module2 I have the dependency-maven-plugin:copy-dependencies goal attached the package phase of the module2 module. module2 has a dependency on module1. When I run mvn package from the module2 folder, it correctly includes the module1 jar in the target/dependency folder. When I run mvn package from the dependency-test folder, the module1 jar is not included in the impl/target/dependency folder. A simple example of the problem is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-32) -Sibling Dependency Not Included in copy-dependencies output during multi-project build
[ http://jira.codehaus.org/browse/MDEP-32?page=comments#action_71422 ] Matt Brozowski commented on MDEP-32: I have reopened this because it doesn't appear to be fixed in maven-dependency-plugin. I have revised the original test to use the maven-dependency-plugin and am attaching it. Matt Brozowski -Sibling Dependency Not Included in copy-dependencies output during multi-project build --- Key: MDEP-32 URL: http://jira.codehaus.org/browse/MDEP-32 Project: Maven 2.x Dependency Plugin Issue Type: Bug Reporter: Matt Brozowski Assigned To: Kenney Westerhof Fix For: 1.1 Attachments: dependency-revised.zip Using the following structure dependency-test - module1 - module2 I have the dependency-maven-plugin:copy-dependencies goal attached the package phase of the module2 module. module2 has a dependency on module1. When I run mvn package from the module2 folder, it correctly includes the module1 jar in the target/dependency folder. When I run mvn package from the dependency-test folder, the module1 jar is not included in the impl/target/dependency folder. A simple example of the problem is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEP-32) -Sibling Dependency Not Included in copy-dependencies output during multi-project build
[ http://jira.codehaus.org/browse/MDEP-32?page=all ] Matt Brozowski updated MDEP-32: --- Attachment: dependency-revised.zip -Sibling Dependency Not Included in copy-dependencies output during multi-project build --- Key: MDEP-32 URL: http://jira.codehaus.org/browse/MDEP-32 Project: Maven 2.x Dependency Plugin Issue Type: Bug Reporter: Matt Brozowski Assigned To: Kenney Westerhof Fix For: 1.1 Attachments: dependency-revised.zip Using the following structure dependency-test - module1 - module2 I have the dependency-maven-plugin:copy-dependencies goal attached the package phase of the module2 module. module2 has a dependency on module1. When I run mvn package from the module2 folder, it correctly includes the module1 jar in the target/dependency folder. When I run mvn package from the dependency-test folder, the module1 jar is not included in the impl/target/dependency folder. A simple example of the problem is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2471) Add search box to the index page
[ http://jira.codehaus.org/browse/MNG-2471?page=all ] Dennis Lundberg updated MNG-2471: - Attachment: index-with-focus.html Using the original proposal, I added a small javascript that sets focus to the searchbox so that you can start typing right away. I also moved the image outside of the form and removed a paragraph to minimize the space above the image. Add search box to the index page Key: MNG-2471 URL: http://jira.codehaus.org/browse/MNG-2471 Project: Maven 2 Issue Type: Improvement Components: Documentation: General Reporter: Marvin King Assigned To: Marvin King Attachments: index-with-focus.html, index-without-logo-with-mojocodehausoption.html, index.html, MNG-2471-site.patch, site-without-logo-with-mojocodehausoption.css - google for now -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-29) EAR:generate-application-xml : Ability to deactivate context-root generation to be compliant with portlet deployment
[ http://jira.codehaus.org/browse/MEAR-29?page=comments#action_71426 ] Stephane Nicoll commented on MEAR-29: - which portlet container are you using? This problem sounds weird to me and is maybe a limitation of the container you are using. EAR:generate-application-xml : Ability to deactivate context-root generation to be compliant with portlet deployment -- Key: MEAR-29 URL: http://jira.codehaus.org/browse/MEAR-29 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.1 Environment: OS: WIN2K (likely any platform) Application Server: JBOSS 4.0.3 (likely not relevant) Reporter: Thierry Barnier Assigned To: Stephane Nicoll Fix For: 2.3 Attachments: no-context-root for Maven-EARplugin.patch I embed a WAR portlet module inside an EAR module I configure the EAR module as follows plugin groupId org.apache.maven.plugins/groupId artifactIdmaven-ear-plugin/artifactId version2.1/version configuration displayNamePortlet/displayName descriptionJBOSS portlet/description modules webModule groupIdmyApp/groupId artifactIdJBPortlet1-war/artifactId !--contextRoot/portlet/contextRoot My problem goes here -- /webModule /modules /configuration /plugin The maven-EAR-module generates an application.xml of the following form: application display-nameThierry Portlet/display-name descriptionJBOSS portlet/description module web web-uri JBPortlet1-war-1.0.war/web-uri context-root/portlet/context-root I would like to remove automatically this line /web /module /application The problem is: In case of a portlet deployment, the context-root element must be omitted, or the application server reject the EAR package. There is no way today to disable context-root generation in application.xml If i comment / remove the contextroot line in the POM file , it takes the WAR filename as context-root in the application.xml I would like to remove automatically the context-root line. what could be the strategy? =a noContextRoot tag added to the ear plugin config webModule groupIdtutorials/groupId artifactIdJBPortlet1-war/artifactId noContextRoot/ /webModule =a way to specify that application-xml has to be generated regarding portlet constraints? (isPortlet property) webModule groupIdtutorials/groupId artifactIdJBPortlet1-war/artifactId isPortlettrue/isPortlet /webModule -- 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: (MEAR-29) EAR:generate-application-xml : Ability to deactivate context-root generation to be compliant with portlet deployment
[ http://jira.codehaus.org/browse/MEAR-29?page=all ] Stephane Nicoll closed MEAR-29. --- Resolution: Fixed Fixed. set noContextRoottrue/noContextRoot for the related web module. EAR:generate-application-xml : Ability to deactivate context-root generation to be compliant with portlet deployment -- Key: MEAR-29 URL: http://jira.codehaus.org/browse/MEAR-29 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.1 Environment: OS: WIN2K (likely any platform) Application Server: JBOSS 4.0.3 (likely not relevant) Reporter: Thierry Barnier Assigned To: Stephane Nicoll Fix For: 2.3 Attachments: no-context-root for Maven-EARplugin.patch I embed a WAR portlet module inside an EAR module I configure the EAR module as follows plugin groupId org.apache.maven.plugins/groupId artifactIdmaven-ear-plugin/artifactId version2.1/version configuration displayNamePortlet/displayName descriptionJBOSS portlet/description modules webModule groupIdmyApp/groupId artifactIdJBPortlet1-war/artifactId !--contextRoot/portlet/contextRoot My problem goes here -- /webModule /modules /configuration /plugin The maven-EAR-module generates an application.xml of the following form: application display-nameThierry Portlet/display-name descriptionJBOSS portlet/description module web web-uri JBPortlet1-war-1.0.war/web-uri context-root/portlet/context-root I would like to remove automatically this line /web /module /application The problem is: In case of a portlet deployment, the context-root element must be omitted, or the application server reject the EAR package. There is no way today to disable context-root generation in application.xml If i comment / remove the contextroot line in the POM file , it takes the WAR filename as context-root in the application.xml I would like to remove automatically the context-root line. what could be the strategy? =a noContextRoot tag added to the ear plugin config webModule groupIdtutorials/groupId artifactIdJBPortlet1-war/artifactId noContextRoot/ /webModule =a way to specify that application-xml has to be generated regarding portlet constraints? (isPortlet property) webModule groupIdtutorials/groupId artifactIdJBPortlet1-war/artifactId isPortlettrue/isPortlet /webModule -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2479) add support for optional 'packagingName' element in dependency blocks
add support for optional 'packagingName' element in dependency blocks - Key: MNG-2479 URL: http://jira.codehaus.org/browse/MNG-2479 Project: Maven 2 Issue Type: New Feature Components: Dependencies Affects Versions: 2.0.4 Reporter: Ian Springer The various deployment artifact types (war, ear, sar, etc.) package their dependencies within the target archive during the package phase. For example, the war plugin includes jar dependencies within WEB-INF/lib, and the ear plugin includes jar and J2EE dependencies at the top level. Sometimes it is not desirable to package the dependencies with their full Maven-repo-style names (i.e. artifactName-version.xar). In particular, the version component is often not desired. Currently, some plugins provide a way to rename these dependency artifacts when they are packaged (e.g. the ear plugin), and others do not (e.g. the war plugin), making it necessary to use an antrun or dependency plugin hack to rename the artifacts as desired. I think it would be much nicer if there was a standard way to specify a packaging name (or whatever other name makes sense) for a dependency in its dependency block in the pom. Then all plugins that package their dependencies could leverage this standard setting. Here is an example of a war dependency declared in an ear pom: dependency groupIdorg.jboss.on/groupId artifactIdon-enterprise-gui-portal/artifactId version2.0-SNAPSHOT/version typewar/type packagingNameon-portal/packagingName /dependency This would cause the war to be bundled in the ear with the filename on-portal.war, instead of the default on-enterprise-gui-portal-2.0-SNAPSHOT.war. -- 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: (CONTINUUM-771) Add user management screens
[ http://jira.codehaus.org/browse/CONTINUUM-771?page=comments#action_71428 ] Carlos Sanchez commented on CONTINUUM-771: -- Applied patches but the last one that doesn't apply correctly. Also the solution goes through using maven-user as stated in CONTINUUM-800 Add user management screens --- Key: CONTINUUM-771 URL: http://jira.codehaus.org/browse/CONTINUUM-771 Project: Continuum Issue Type: Sub-task Components: Web interface Reporter: Carlos Sanchez Assigned To: Henry S. Isidro Fix For: 1.1 Attachments: CONTINUUM-771-continuum-webapp-menu.patch, CONTINUUM-771-continuum-webapp-refactored_user_management_actions.patch, CONTINUUM-771-continuum-webapp-using-PlexusActionSupport.patch, CONTINUUM-771-continuum-webapp-with-improved-logging.patch, CONTINUUM-771-continuum-webapp.patch, CONTINUUM-771-continuum-webapp.patch Add a page for listing the users, with options to add/edit/delete user Users can have an unlimited number of roles (Continuum Permission) like addProject, addUser,... they are already created by the ContinuumInitializer and are static (no new roles/permissions can be added) -- 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: (MEV-426) Quartz 1.5.2 missing pom and jar. Has source.
[ http://jira.codehaus.org/browse/MEV-426?page=all ] Lee Meador updated MEV-426: --- Attachment: pom.xml Here is a better pom. I had the previous one totally messed up. What I forgot was that when dealing with transitive dependencies maven2 will convert the scopes in the pom for the direct dependency to something different for the transitive ones. So, to fix the problem, I added some scopes and optionals to the pom I used to build Quartz 1.5.2 on my machine. I haven't removed each dependency to make sure this is the smalled list that will work but I did add the se one by one and when I got to this list it started compiling. Quartz 1.5.2 missing pom and jar. Has source. - Key: MEV-426 URL: http://jira.codehaus.org/browse/MEV-426 Project: Maven Evangelism Issue Type: Improvement Reporter: Lee Meador Attachments: maven-repo-quartz-1.5.2.zip, pom.xml The pom and jar are missing but the source jar, etc are there. Quartz 1.5.1 has a pom with no dependencies. The supplied file has a pom with all the dependencies needed to compile quartz EXCEPT ejb.jar and servlet.jar (or servlet-api.jar) JTA and MAIL are marked optional. The others are things like beanutils and such that are already in the repository. Here's what I did: 1) Download 1.5.2 from http://www.opensymphony.com/quartz/download.action 2) Unzip and take the jar from the lib directory of what unzipped.. 3) Build an Eclipse project with a the maven 2 plugin, using the maven layout. 4) Copy all the unzipped source into src/main/java from the src/java directory of what unzipped. 5) Create a pom by turning on the maven2 eclipse plugin for the project. 5) Add dependencies to the pom based on what wouldn't compile in eclipse. 6) Repeat step 5 and building with mvn compile until there were no errors. Then I copied the pom to quartz-1.5.2.pom and edited it a bit more: 1) I removed ejb.jar and servlet.jar since I figured those would be around if needed in quartz. 2) I added optionaltrue/optional to jta and java mail since those jars are Sun's and aren't in the repo 3) I added scoperuntime/scope to everything else. That is what I am sending you. -- 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: (MEAR-31) add ability to configure JBoss-specific deployment options in plugin configuration that will result in a jboss-app.xml descriptor being generated
[ http://jira.codehaus.org/browse/MEAR-31?page=comments#action_71431 ] Stephane Nicoll commented on MEAR-31: - also we need to disable the connector stuff when the jboss-app.xml is generated add ability to configure JBoss-specific deployment options in plugin configuration that will result in a jboss-app.xml descriptor being generated - Key: MEAR-31 URL: http://jira.codehaus.org/browse/MEAR-31 Project: Maven 2.x Ear Plugin Issue Type: New Feature Affects Versions: 2.2 Reporter: Ian Springer Assigned To: Stephane Nicoll Fix For: 2.3 The correct way to configure a SAR bundled in an EAR is not via a connector module, but by adding a service module entry in META-INF/jboss-app.xml, e.g.: !DOCTYPE jboss-app PUBLIC -//JBoss//DTD J2EE Application 1.4//EN http://www.jboss.org/j2ee/dtd/jboss-app_4_0.dtd; jboss-app module servicemy.sar/service /module /jboss-app This tells JBoss to load the JBoss service from the file my.sar located in the root directory of the EAR. I suggest adding a JBoss-specfic section in the EAR plugin's configuration for configuring stuff that needs to be written to jboss-app.xml, e.g.: configuration jboss jbossVersion4/jbossVersion ... /jboss /configuration The jbossVersion would tell the plugin which version of JBoss is being targeted, which would determine the docType of the file (a bunch of new elements were added in JBoss 4.x - for example, the ability to deploy Hibernate archives (HARs). We could sgtart out with just the ability to deploy SARs and perhaps HARs and eventually add support for the other items in jboss-app.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-426) Quartz 1.5.2 missing pom and jar. Has source.
[ http://jira.codehaus.org/browse/MEV-426?page=comments#action_71432 ] Carlos Sanchez commented on MEV-426: as is said, ejb and servlet must have optionaltrue/optional Quartz 1.5.2 missing pom and jar. Has source. - Key: MEV-426 URL: http://jira.codehaus.org/browse/MEV-426 Project: Maven Evangelism Issue Type: Improvement Reporter: Lee Meador Attachments: maven-repo-quartz-1.5.2.zip, pom.xml The pom and jar are missing but the source jar, etc are there. Quartz 1.5.1 has a pom with no dependencies. The supplied file has a pom with all the dependencies needed to compile quartz EXCEPT ejb.jar and servlet.jar (or servlet-api.jar) JTA and MAIL are marked optional. The others are things like beanutils and such that are already in the repository. Here's what I did: 1) Download 1.5.2 from http://www.opensymphony.com/quartz/download.action 2) Unzip and take the jar from the lib directory of what unzipped.. 3) Build an Eclipse project with a the maven 2 plugin, using the maven layout. 4) Copy all the unzipped source into src/main/java from the src/java directory of what unzipped. 5) Create a pom by turning on the maven2 eclipse plugin for the project. 5) Add dependencies to the pom based on what wouldn't compile in eclipse. 6) Repeat step 5 and building with mvn compile until there were no errors. Then I copied the pom to quartz-1.5.2.pom and edited it a bit more: 1) I removed ejb.jar and servlet.jar since I figured those would be around if needed in quartz. 2) I added optionaltrue/optional to jta and java mail since those jars are Sun's and aren't in the repo 3) I added scoperuntime/scope to everything else. That is what I am sending you. -- 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: (MJAR-55) possibility to add arbitrary elements to the manifest classpath
[ http://jira.codehaus.org/browse/MJAR-55?page=all ] Brett Porter closed MJAR-55. Assignee: Brett Porter Resolution: Duplicate possibility to add arbitrary elements to the manifest classpath --- Key: MJAR-55 URL: http://jira.codehaus.org/browse/MJAR-55 Project: Maven 2.x Jar Plugin Issue Type: Improvement Reporter: Michel Verbist Assigned To: Brett Porter Priority: Minor I want to add '.' (the current directory) to the classpath. The main reason for this is to be able to access files like log4j.properties hibernate.cfg.xml ... outside the jar, so I don't have to rebuild my jar if, e.g., I want to increase the log4j level for a particular class. Or ask my client over the phone to increase the level and send me the log file. The only thing I came up with was this possible improvement: current config of the manifest: configuration archive manifest addClasspathtrue/addClasspath mainClassbe.brail.b38c.loadtester.AppLoadTester/mainClass /manifest /archive /configuration possible extension of manifest config configuration archive manifest addClasspathtrue/addClasspath additionalClasspathEntries classpathEntry.//classpathEntry classpathEntryhelp//classpathEntry classpathEntryresources//classpathEntry /additionalClasspathEntries mainClassbe.brail.b38c.loadtester.AppLoadTester/mainClass /manifest /archive /configuration By adding public List org.apache.maven.archiver.ManifestConfiguration.getAdditionalClasspathEntries() people could be allowed to add not only the dependent jars to the classpath but also any arbitrary 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
[jira] Created: (MNG-2480) Support for different types of version ranges in dependencies
Support for different types of version ranges in dependencies - Key: MNG-2480 URL: http://jira.codehaus.org/browse/MNG-2480 Project: Maven 2 Issue Type: Improvement Components: Dependencies Affects Versions: 2.0.4 Environment: n/a Reporter: Peter Monks G'day, It would be ideal if Maven supported different types of dependency version ranges, to allow for more flexible dependency version resolution. For example, if I was the provider of an open source library I might like to be able to state that my code is dependent on some other library, and in the dependency version section be able to say that it's been tested with one or two specific versions (say [1.1,1.2]), but should theoretically work over a range of versions (say [1.1,2.0) ). In this example the two version ranges might be called the soft range and the hard range (or certified and uncertified or whatever - the idea is what's important, not the terminology). Currently many of the poms for open source libraries in the public Maven repositories specify precise version numbers which invariably causes version mismatches (which then tickles bug MNG-2123, but that's another story...). I suspect that one of the reasons that open source teams do this is because they've only tested their code against one version of each library they're dependent upon, so it's understandable that they don't want to put a wider range of version numbers in their poms. But this increases the changes of a version number mismatch which forces the ultimate consumer of the library (and its dependencies) to manually fiddle with poms until the various version number ranges overlap. If it were possible to specify hard vs soft version number ranges in the poms directly, then open source providers may have more incentive to be more permissive in their version number ranges, while still making it clear which versions of their dependencies they've actually tested against. Cheers, Peter -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-122) Versionless Extension causes NullPointerException in release:prepare
[ http://jira.codehaus.org/browse/MRELEASE-122?page=all ] Matthew Beermann updated MRELEASE-122: -- Attachment: patch.txt It's a very simple fix - the other functions in the class have this logic, but it got missed for extensions. Versionless Extension causes NullPointerException in release:prepare Key: MRELEASE-122 URL: http://jira.codehaus.org/browse/MRELEASE-122 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-4 Reporter: Stefan Hübner Attachments: patch.txt I'm getting a NullPointerException when invoking mvn release:prepare -DdryRun=true (don't know, if the dryRun-parameter makes any difference). See the stack trace below. My POM does make use of the wagon-ssh-extension, but without declaring a certain version of that extension - which is not necessary, as far as I know. A workaround to this is to declare a version to the extension. See this mail thread for a discussion on this issue: http://www.nabble.com/NullPointerException+in+Release+Plugin+2.0-beta-4-t1637385.html#a4434481 Stefan ava.lang.NullPointerException at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.updateDomVersion(AbstractRewritePomsPhase.java:388) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.rewriteExtensions(AbstractRewritePomsPhase.java:352) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:230) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:165) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:102) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.simulate(AbstractRewritePomsPhase.java:529) at org.apache.maven.plugins.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:135) -- 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-2479) add support for optional 'packagingName' element in dependency blocks
[ http://jira.codehaus.org/browse/MNG-2479?page=all ] Brett Porter closed MNG-2479. - Assignee: Brett Porter Resolution: Won't Fix this should be available as plugin configuration for the various packaging plugins already - if not it should be requested for each, both on an artifact by artifact basis and to be able to map all names using a mapper. A generic solution in the dependency element is not desired since it will not work with transitive dependencies (W, a WAR depends on B with depends on A - B's dependency on A doesn't know to specify this element because it doesn't know it will later be used in a WAR). add support for optional 'packagingName' element in dependency blocks - Key: MNG-2479 URL: http://jira.codehaus.org/browse/MNG-2479 Project: Maven 2 Issue Type: New Feature Components: Dependencies Affects Versions: 2.0.4 Reporter: Ian Springer Assigned To: Brett Porter The various deployment artifact types (war, ear, sar, etc.) package their dependencies within the target archive during the package phase. For example, the war plugin includes jar dependencies within WEB-INF/lib, and the ear plugin includes jar and J2EE dependencies at the top level. Sometimes it is not desirable to package the dependencies with their full Maven-repo-style names (i.e. artifactName-version.xar). In particular, the version component is often not desired. Currently, some plugins provide a way to rename these dependency artifacts when they are packaged (e.g. the ear plugin), and others do not (e.g. the war plugin), making it necessary to use an antrun or dependency plugin hack to rename the artifacts as desired. I think it would be much nicer if there was a standard way to specify a packaging name (or whatever other name makes sense) for a dependency in its dependency block in the pom. Then all plugins that package their dependencies could leverage this standard setting. Here is an example of a war dependency declared in an ear pom: dependency groupIdorg.jboss.on/groupId artifactIdon-enterprise-gui-portal/artifactId version2.0-SNAPSHOT/version typewar/type packagingNameon-portal/packagingName /dependency This would cause the war to be bundled in the ear with the filename on-portal.war, instead of the default on-enterprise-gui-portal-2.0-SNAPSHOT.war. -- 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-2479) add support for optional 'packagingName' element in dependency blocks
[ http://jira.codehaus.org/browse/MNG-2479?page=comments#action_71435 ] Ian Springer commented on MNG-2479: --- Hmm, I'm not sure I agree with this. If it was desired to override the default filename for transitive deps, this could be achieved by explicitly declaring the transitive deps in the J2EE pom. In your example, W's pom could explicitly declare A, in addition to B, in order to specify packaging names for both. The same thing would basically be true for plugin-by-plugin defined configuration schemes. That is, transitive artifacts would only need to be explicitly defined if you needed to override the packaging name or some other setting specific to that artifact. For me, one of the biggest pros of Maven is consistency in how things are done. By not having a central way of specifying packaging filenames (and packaging target directories), you end up with ten different plugins doing it ten different ways, or not doing it at all. add support for optional 'packagingName' element in dependency blocks - Key: MNG-2479 URL: http://jira.codehaus.org/browse/MNG-2479 Project: Maven 2 Issue Type: New Feature Components: Dependencies Affects Versions: 2.0.4 Reporter: Ian Springer Assigned To: Brett Porter The various deployment artifact types (war, ear, sar, etc.) package their dependencies within the target archive during the package phase. For example, the war plugin includes jar dependencies within WEB-INF/lib, and the ear plugin includes jar and J2EE dependencies at the top level. Sometimes it is not desirable to package the dependencies with their full Maven-repo-style names (i.e. artifactName-version.xar). In particular, the version component is often not desired. Currently, some plugins provide a way to rename these dependency artifacts when they are packaged (e.g. the ear plugin), and others do not (e.g. the war plugin), making it necessary to use an antrun or dependency plugin hack to rename the artifacts as desired. I think it would be much nicer if there was a standard way to specify a packaging name (or whatever other name makes sense) for a dependency in its dependency block in the pom. Then all plugins that package their dependencies could leverage this standard setting. Here is an example of a war dependency declared in an ear pom: dependency groupIdorg.jboss.on/groupId artifactIdon-enterprise-gui-portal/artifactId version2.0-SNAPSHOT/version typewar/type packagingNameon-portal/packagingName /dependency This would cause the war to be bundled in the ear with the filename on-portal.war, instead of the default on-enterprise-gui-portal-2.0-SNAPSHOT.war. -- 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: (MEV-426) Quartz 1.5.2 missing pom and jar. Has source.
[ http://jira.codehaus.org/browse/MEV-426?page=all ] Lee Meador updated MEV-426: --- Attachment: pom.xml I seem to have lost a couple of optional true lines in the previous version. Now they are in the pom. Quartz 1.5.2 missing pom and jar. Has source. - Key: MEV-426 URL: http://jira.codehaus.org/browse/MEV-426 Project: Maven Evangelism Issue Type: Improvement Reporter: Lee Meador Attachments: maven-repo-quartz-1.5.2.zip, pom.xml, pom.xml The pom and jar are missing but the source jar, etc are there. Quartz 1.5.1 has a pom with no dependencies. The supplied file has a pom with all the dependencies needed to compile quartz EXCEPT ejb.jar and servlet.jar (or servlet-api.jar) JTA and MAIL are marked optional. The others are things like beanutils and such that are already in the repository. Here's what I did: 1) Download 1.5.2 from http://www.opensymphony.com/quartz/download.action 2) Unzip and take the jar from the lib directory of what unzipped.. 3) Build an Eclipse project with a the maven 2 plugin, using the maven layout. 4) Copy all the unzipped source into src/main/java from the src/java directory of what unzipped. 5) Create a pom by turning on the maven2 eclipse plugin for the project. 5) Add dependencies to the pom based on what wouldn't compile in eclipse. 6) Repeat step 5 and building with mvn compile until there were no errors. Then I copied the pom to quartz-1.5.2.pom and edited it a bit more: 1) I removed ejb.jar and servlet.jar since I figured those would be around if needed in quartz. 2) I added optionaltrue/optional to jta and java mail since those jars are Sun's and aren't in the repo 3) I added scoperuntime/scope to everything else. That is what I am sending you. -- 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: (MEAR-31) add ability to configure JBoss-specific deployment options in plugin configuration that will result in a jboss-app.xml descriptor being generated
[ http://jira.codehaus.org/browse/MEAR-31?page=comments#action_71439 ] Stephane Nicoll commented on MEAR-31: - jboss app is now generated. I need to bind it to the lifecycle + disable application.xml inclusion as a connector when it makes sense. add ability to configure JBoss-specific deployment options in plugin configuration that will result in a jboss-app.xml descriptor being generated - Key: MEAR-31 URL: http://jira.codehaus.org/browse/MEAR-31 Project: Maven 2.x Ear Plugin Issue Type: New Feature Affects Versions: 2.2 Reporter: Ian Springer Assigned To: Stephane Nicoll Fix For: 2.3 The correct way to configure a SAR bundled in an EAR is not via a connector module, but by adding a service module entry in META-INF/jboss-app.xml, e.g.: !DOCTYPE jboss-app PUBLIC -//JBoss//DTD J2EE Application 1.4//EN http://www.jboss.org/j2ee/dtd/jboss-app_4_0.dtd; jboss-app module servicemy.sar/service /module /jboss-app This tells JBoss to load the JBoss service from the file my.sar located in the root directory of the EAR. I suggest adding a JBoss-specfic section in the EAR plugin's configuration for configuring stuff that needs to be written to jboss-app.xml, e.g.: configuration jboss jbossVersion4/jbossVersion ... /jboss /configuration The jbossVersion would tell the plugin which version of JBoss is being targeted, which would determine the docType of the file (a bunch of new elements were added in JBoss 4.x - for example, the ability to deploy Hibernate archives (HARs). We could sgtart out with just the ability to deploy SARs and perhaps HARs and eventually add support for the other items in jboss-app.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1028) Upload Joda-Time 1.3
Upload Joda-Time 1.3 Key: MAVENUPLOAD-1028 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1028 Project: maven-upload-requests Issue Type: Task Reporter: Stephen Colebourne http://joda-time.sourceforge.net/joda-time-1.3-bundle.jar http://joda-time.sourceforge.net http://joda-time.sourceforge.net/team-list.html Please upload joda-time 1.3 -- 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: (MAVEN-1768) wrong directory structure in src distribution package (maven-dist-plugin-1.7)
[ http://jira.codehaus.org/browse/MAVEN-1768?page=all ]
Lukas Theussl closed MAVEN-1768.
Resolution: Won't Fix
It's not necessary to open the same issue again under another project as we can
just move it there.
wrong directory structure in src distribution package (maven-dist-plugin-1.7)
-
Key: MAVEN-1768
URL: http://jira.codehaus.org/browse/MAVEN-1768
Project: Maven
Issue Type: Bug
Components: core
Affects Versions: 1.1-beta-2
Reporter: Jarkko Viinamäki
With Maven 1.1-beta-2 and maven-dist-plugin-1.7:
if my project.xml defines:
build
sourceDirectorysrc/main/java/sourceDirectory
...
Then the dist:build-src target generates an incorrect src distribution file
since the source files are packaged to path src/foo/bar/MyClass.java instead
of src/main/java/foo/bar/MyClass.java
--
To fix this, change the dist:prepare-src-filesystem goal in
maven-dist-plugin-1.7 to read:
util:available file=src
ant:copy todir=${maven.dist.src.assembly.dir}/src
ant:fileset dir=src /
/ant:copy
/util:available
This will preserve the actual directory structure.
--
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: (MRM-142) possible memory leak
[ http://jira.codehaus.org/browse/MRM-142?page=comments#action_71442 ] Brett Porter commented on MRM-142: -- this simply seems to be the size of the processedProjectCache in the project builder. We should probably restrict the size of that in general, but for the MRM we should flush it whenever the index is (for now, just at the end will do) possible memory leak Key: MRM-142 URL: http://jira.codehaus.org/browse/MRM-142 Project: Maven Repository Manager Issue Type: Bug Components: indexing Reporter: Brett Porter Assigned To: Brett Porter Fix For: 1.0-beta-1 Original Estimate: 1 hour Remaining Estimate: 1 hour need to investigate if there is a memory leak, since the server received an OOME some time after successfully completing a full index with 1Gb heap with just some browsing/searching. It is most likely in the indexing itself, but there may be some in the browse/search interface 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: (MRM-142) possible memory leak
[ http://jira.codehaus.org/browse/MRM-142?page=comments#action_71445 ] Brett Porter commented on MRM-142: -- did some performance analysis while I was there. It appears that indexing the JAR files is not the time consuming operation, but rather the indexing, checksumming and reading the POMs: discovery: 7% (mostly the directory scanner - a total of 6%) indexing records: 53% reading records: 32% Breaking down the last one: reading pom: 16% reading checksum: 14% Breaking down reading the POM: resolving: 3% (these are all local) building: 13% Breaking down building: interpolation: 5% This was with no existing index. It may be more skewed towards indexing if it has to delete all the records as it goes. possible memory leak Key: MRM-142 URL: http://jira.codehaus.org/browse/MRM-142 Project: Maven Repository Manager Issue Type: Bug Components: indexing Reporter: Brett Porter Assigned To: Brett Porter Fix For: 1.0-beta-1 Original Estimate: 1 hour Remaining Estimate: 1 hour need to investigate if there is a memory leak, since the server received an OOME some time after successfully completing a full index with 1Gb heap with just some browsing/searching. It is most likely in the indexing itself, but there may be some in the browse/search interface 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: (MJAVADOC-81) Additional doclets do not run.
Additional doclets do not run. -- Key: MJAVADOC-81 URL: http://jira.codehaus.org/browse/MJAVADOC-81 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Shinobu Kawai Priority: Critical Although it is stated in the docs [1] that you can generate alternate doclet in addition to the project javadocs, only the first reportSet is run. This is due to the fact that JavadocReport#getOutputName(...) returns a fixed value, apidocs/index. This should be configurable per reportSet. [1] http://maven.apache.org/plugins/maven-javadoc-plugin/configuration.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-81) Additional doclets do not run.
[ http://jira.codehaus.org/browse/MJAVADOC-81?page=comments#action_71448 ] Wendy Smoak commented on MJAVADOC-81: - Can you post the config that is not working? I was able to run the UmlGraph doclet in addition to the normal Javadoc doclet by: 1. assigning an id to each reportSet 2. Using destDir to direct the output of the second doclet somewhere else. Additional doclets do not run. -- Key: MJAVADOC-81 URL: http://jira.codehaus.org/browse/MJAVADOC-81 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Shinobu Kawai Priority: Critical Although it is stated in the docs [1] that you can generate alternate doclet in addition to the project javadocs, only the first reportSet is run. This is due to the fact that JavadocReport#getOutputName(...) returns a fixed value, apidocs/index. This should be configurable per reportSet. [1] http://maven.apache.org/plugins/maven-javadoc-plugin/configuration.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-142) possible memory leak
[ http://jira.codehaus.org/browse/MRM-142?page=comments#action_71447 ] Brett Porter commented on MRM-142: -- the comment above seems a bit misleading. reading the files/classes inside a JAR is not time consuming. Indexing data (both jars and poms) is the most, followed by checksumming jars and by reading POMs (as the breakdown indicates) possible memory leak Key: MRM-142 URL: http://jira.codehaus.org/browse/MRM-142 Project: Maven Repository Manager Issue Type: Bug Components: indexing Reporter: Brett Porter Assigned To: Brett Porter Fix For: 1.0-beta-1 Original Estimate: 1 hour Time Spent: 30 minutes Remaining Estimate: 30 minutes need to investigate if there is a memory leak, since the server received an OOME some time after successfully completing a full index with 1Gb heap with just some browsing/searching. It is most likely in the indexing itself, but there may be some in the browse/search interface 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: (ARCHETYPE-42) Update the mojo archetype to be compliant with the plugin documentation standard
[ http://jira.codehaus.org/browse/ARCHETYPE-42?page=comments#action_71454 ] Edwin Punzalan commented on ARCHETYPE-42: - I've just found out that I have commit access in archetypes... I'm not committing this bec I don't know if the plugin-parent of the apache plugins should be setup as its parent too? This needs some work also as its a bit outdated against the plugin documentation standards. Update the mojo archetype to be compliant with the plugin documentation standard Key: ARCHETYPE-42 URL: http://jira.codehaus.org/browse/ARCHETYPE-42 Project: Maven Archetype Issue Type: Task Components: Archetypes Reporter: Edwin Punzalan Assigned To: Edwin Punzalan Attachments: ARCHETYPE-42-maven-archetype-mojo.patch Original Estimate: 4 hours Time Spent: 3 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] Updated: (MJAVADOC-81) Additional doclets do not run.
[ http://jira.codehaus.org/browse/MJAVADOC-81?page=all ] Shinobu Kawai updated MJAVADOC-81: -- Attachment: pom.xml The pom that doesn't work. I get the following in the log: [INFO] Skipped JavaDocs report, file apidocs/index.html already exists for the English version. Additional doclets do not run. -- Key: MJAVADOC-81 URL: http://jira.codehaus.org/browse/MJAVADOC-81 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Shinobu Kawai Priority: Critical Attachments: pom.xml Although it is stated in the docs [1] that you can generate alternate doclet in addition to the project javadocs, only the first reportSet is run. This is due to the fact that JavadocReport#getOutputName(...) returns a fixed value, apidocs/index. This should be configurable per reportSet. [1] http://maven.apache.org/plugins/maven-javadoc-plugin/configuration.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MJAVADOC-81) Additional doclets do not run.
[ http://jira.codehaus.org/browse/MJAVADOC-81?page=all ] Shinobu Kawai updated MJAVADOC-81: -- Attachment: MJAVADOC-81 Patch to expose name, description, and outputName. Applied, I can add the following to my pom to make it work: ... configuration nameDocCheck/name descriptionDocCheck documentation/description outputNamedoccheck/index/outputName ... Additional doclets do not run. -- Key: MJAVADOC-81 URL: http://jira.codehaus.org/browse/MJAVADOC-81 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Shinobu Kawai Priority: Critical Attachments: MJAVADOC-81, pom.xml Although it is stated in the docs [1] that you can generate alternate doclet in addition to the project javadocs, only the first reportSet is run. This is due to the fact that JavadocReport#getOutputName(...) returns a fixed value, apidocs/index. This should be configurable per reportSet. [1] http://maven.apache.org/plugins/maven-javadoc-plugin/configuration.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-142) possible memory leak
[ http://jira.codehaus.org/browse/MRM-142?page=all ] Brett Porter updated MRM-142: - Fix Version/s: (was: 1.0-beta-1) possible memory leak Key: MRM-142 URL: http://jira.codehaus.org/browse/MRM-142 Project: Maven Repository Manager Issue Type: Bug Components: indexing Reporter: Brett Porter Assigned To: Brett Porter Original Estimate: 1 hour Time Spent: 30 minutes Remaining Estimate: 30 minutes need to investigate if there is a memory leak, since the server received an OOME some time after successfully completing a full index with 1Gb heap with just some browsing/searching. It is most likely in the indexing itself, but there may be some in the browse/search interface 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-2481) project builder should make the processed project cache configurable
[ http://jira.codehaus.org/browse/MNG-2481?page=comments#action_71461 ] Brett Porter commented on MNG-2481: --- another thought - perhaps the cachability of poms that were accessed as parents or have been identified as dependencies could get a higher weighting since they are more likely to be reused later. project builder should make the processed project cache configurable Key: MNG-2481 URL: http://jira.codehaus.org/browse/MNG-2481 Project: Maven 2 Issue Type: Bug Components: POM, Performance Affects Versions: 2.0.4 Reporter: Brett Porter the cache in the project builder is a simple map. This is usually fine for Maven, but in long lived processes (Continuum, MRM, and I imagine the IDE plugins as it gets used more) it can chew up quite some memory. I'd suggest we make it configurable: - can turn it on or off using plexus configuration - can limit its size using plexus configuration - can change other options, such as adding expiry ages to items regardless of size Rather than implementing something in the project builder itself, I suggest having a cache plexus component that does everything we need it to (this could be reused in the webapps as well). I'm not sure of any existing caching solutions (I know OSCache has a general Java cache but don't know how suitable it is). One alterantive might be to round out commons-cache with some features and plexus descriptors. -- 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: (MRM-132) browse interface should accept URL paths
[ http://jira.codehaus.org/browse/MRM-132?page=all ] Brett Porter updated MRM-132: - Remaining Estimate: 30 minutes Original Estimate: 30 minutes browse interface should accept URL paths Key: MRM-132 URL: http://jira.codehaus.org/browse/MRM-132 Project: Maven Repository Manager Issue Type: Improvement Reporter: Brett Porter Assigned To: Brett Porter Fix For: 1.0-beta-1 Original Estimate: 30 minutes Remaining Estimate: 30 minutes currently browsing the repository uses inconvenient URLs: - browse.action - browseGroup.action?groupId=... - browseArtifact.action?artifactId=...groupId= - showArtifact.action?artifactId=...groupId=...version=... Instead, the following paths should be used: /browse/[groupId[/artifactId[/version]]] -- 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
