[jira] Commented: (SUREFIRE-61) Incorrect classpath ordering
[ http://jira.codehaus.org/browse/SUREFIRE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102928 ] Matt Read commented on SUREFIRE-61: --- I've checked out the surefire code and SurefirePlugin.java - line 649 says: // no need to add classes/test classes directory here - they are in the classpath elements already I'm having major problems digging out exactly what is putting these directories on the classpath in the first place - it doesn't seem to be the responsibility of the SureFire plugin but perhaps passed in from Plexus? Can anyone point me in the right direction? This issue is blocking a major release for me and I'm looking for as much help as possible. i'll certainly supply the patch if I get to the bottom of this! > Incorrect classpath ordering > > > Key: SUREFIRE-61 > URL: http://jira.codehaus.org/browse/SUREFIRE-61 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 3.x support >Affects Versions: 2.0 (2.2 plugin) > Environment: maven2.0.4, sun-jdk-1.5.0.09, maven-surefire-plugin 2.2, > surefire 2.0, gentoo linux x86 >Reporter: Martin Vysny >Priority: Critical > Fix For: 2.4 > > Attachments: my-app.zip, output.log, > SUREFIRE61_barrettas_surefire_surefire-booter_for_rev_489098.patch > > > Surefire incorrectly interprets classpath ordering. > Steps to reproduce: > 1. unzip my-app.zip - it's a simple mvn project created with > mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app > and lightly patched > 2. mvn test > in my case, it prints out > jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties > jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties > which is incorrect. log4j.properties is located both in jxta.jar and > src/test/resources, but I think that src/test/resources takes precedence over > jxta. This ordering is set correctly in surefire36745tmp file I think, but > surefire seems to ignore the ordering. -- This message is automatically 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: (DOXIA-140) Review the Doxia site documentation
Review the Doxia site documentation --- Key: DOXIA-140 URL: http://jira.codehaus.org/browse/DOXIA-140 Project: Maven Doxia Issue Type: Task Components: Documentation Affects Versions: 1.0-alpha-9 Reporter: Vincent Siveton Fix For: 1.0-beta-1 -- This message is automatically 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: (DOXIA-141) Add missing references for FML XDOC
Add missing references for FML XDOC --- Key: DOXIA-141 URL: http://jira.codehaus.org/browse/DOXIA-141 Project: Maven Doxia Issue Type: Sub-task Components: Documentation Affects Versions: 1.0-alpha-9 Reporter: Vincent Siveton Fix For: 1.0-beta-1 -- This message is automatically 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] Reopened: (MECLIPSE-292) Behaviour for sources and Javadoc attachement for dependencies should be consistent
[ http://jira.codehaus.org/browse/MECLIPSE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Cabasson reopened MECLIPSE-292: - @Brian : Your updated version of the patch seems to have broken the caching mecanism. > Behaviour for sources and Javadoc attachement for dependencies should be > consistent > --- > > Key: MECLIPSE-292 > URL: http://jira.codehaus.org/browse/MECLIPSE-292 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: dependency resolution >Affects Versions: 2.4 > Environment: Windows XP, Maven 2.0.6, maven-eclipse-plugin > 2.4-20070628.215652-24 >Reporter: Denis Cabasson >Assignee: Brian Fox >Priority: Minor > Fix For: 2.4 > > Attachments: MECLIPSE-292-updated.patch, MECLIPSE-292.patch > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > Why couldn't we have a consistent behaviour for javadoc and sources jar > attachment? > Why not adding a downloadJavadoc property, which, when set to true, would > download and attach the javadoc to the dependency. > I don't really see why javadoc should be a fallback if sources are not > available. > Some developpers might prefer to have javadoc linked, some sources linked and > some both. Shouldn't the eclipse plugin allow for all the possiblities > instead of stating that the preferred option is always to get the sources > instead of the Javadoc? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-292) Behaviour for sources and Javadoc attachement for dependencies should be consistent
[ http://jira.codehaus.org/browse/MECLIPSE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Cabasson updated MECLIPSE-292: Attachment: MECLIPSE-292-fixbug.patch Parenthesis was wrongly placed. Submitted patch should get the caching mecanism up and working. > Behaviour for sources and Javadoc attachement for dependencies should be > consistent > --- > > Key: MECLIPSE-292 > URL: http://jira.codehaus.org/browse/MECLIPSE-292 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: dependency resolution >Affects Versions: 2.4 > Environment: Windows XP, Maven 2.0.6, maven-eclipse-plugin > 2.4-20070628.215652-24 >Reporter: Denis Cabasson >Assignee: Brian Fox >Priority: Minor > Fix For: 2.4 > > Attachments: MECLIPSE-292-fixbug.patch, MECLIPSE-292-updated.patch, > MECLIPSE-292.patch > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > Why couldn't we have a consistent behaviour for javadoc and sources jar > attachment? > Why not adding a downloadJavadoc property, which, when set to true, would > download and attach the javadoc to the dependency. > I don't really see why javadoc should be a fallback if sources are not > available. > Some developpers might prefer to have javadoc linked, some sources linked and > some both. Shouldn't the eclipse plugin allow for all the possiblities > instead of stating that the preferred option is always to get the sources > instead of the Javadoc? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-23) Possibility to create real multiple modules with Java sources
[ http://jira.codehaus.org/browse/ARCHETYPE-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102949 ] Casey Butterworth commented on ARCHETYPE-23: I see that ARCHETYPE-33 is said to supercede this issue, but I can't see whether it has been released as the new archetype plugin. Any idea when this might happen? I'd love to provide a multi module maven archetype for our projects and at this stage am unable to. > Possibility to create real multiple modules with Java sources > - > > Key: ARCHETYPE-23 > URL: http://jira.codehaus.org/browse/ARCHETYPE-23 > Project: Maven Archetype > Issue Type: Improvement > Components: Plugin >Reporter: Johannes Carlén >Assignee: Jason van Zyl > Attachments: archetype.mdo, DefaultArchetype.java, > MavenArchetypeMojo.java > > > I'm lacking the possibility to be able to generate a real multimodule > application i.e. an ear containing both a web module and an ejb module with > java sources. > I know it is possible to list all classes as a , however when doing > so I can't get the packageName to automatically be prepended to the java > files path (src/main/java//.../App.java). > What it means is that I'd like to be able to mark the java files as source > files also when doing multiple modules generations. -- This message is automatically 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-33) Better Archetype template processing support
[ http://jira.codehaus.org/browse/ARCHETYPE-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102950 ] Casey Butterworth commented on ARCHETYPE-33: Any idea when this might happen? I'd love to provide a multi module maven archetype for our projects and at this stage am unable to. > Better Archetype template processing support > > > Key: ARCHETYPE-33 > URL: http://jira.codehaus.org/browse/ARCHETYPE-33 > Project: Maven Archetype > Issue Type: Improvement >Reporter: Aaron Anderson >Assignee: Jason van Zyl >Priority: Trivial > Attachments: new-archetype.zip > > > I really love the maven 2 archetype concept and have developed an enhanced > version that utilizes the velocity templating engine to a greater degree. > While the code is fully functionality it needs to be cleaned up and the > documentation enhanced. Please feel to incorporate any part of this back into > maven 2 if any of it is appealing. If desired I could also enhance the code > to make it a better contribution as well. > To test out the archetype functionallity, run mvn install in both archetype > (new plugin) and jbi-component (sample archetype) > to execute the new archetype, run > C:\temp\maventest> mvn > com.javaforge.bobber:bobber-archetype:1.0-SNAPSHOT:create > -DarchetypeGroupId=com.javaforge.bobber > -DarchetypeArtifactId=maven-archetype-jbi-component > -DarchetypeVersion=1.0-SNAPSHOT -DgroupId=com.newarchetype -DartifactId=test > in the same way the default archeype functionality works. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-307) "target" for deploy-path shouldnt be a constant
[ http://jira.codehaus.org/browse/MECLIPSE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102951 ] Denis Cabasson commented on MECLIPSE-307: - The only valid path to deploy your compiled source in a web application is "WEB-INF/classes", so this path should certainly be hardcoded. The outputDirectory is a maven parameter telling maven where to put compiled sources. Eclipse Java project is taking this path into account, but I don't think it would be good for Eclipse WTP to have a custom folder other than "WEB-INF/classes". See [Java Servlet 2.2 Specifications|http://java.sun.com/products/servlet/2.2/], spécifications paper, point 9.4 > "target" for deploy-path shouldnt be a constant > --- > > Key: MECLIPSE-307 > URL: http://jira.codehaus.org/browse/MECLIPSE-307 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.4, 2.5 > Environment: Windows 2003 >Reporter: Auston McReynolds > Attachments: patch.txt > > > If specified in the POM: > > JavaSource > AnotherFolder/WEB-INF/classes > > > maven-eclipse-plugin > ... > .settings/org.eclipse.wst.common.component has > > Instead of > source-path="JavaSource"/> > This is due to String target being set to the literal "/WEB-INF/classes" > under the block: > if ( "war".equalsIgnoreCase( packaging ) ) > Instead it seems to me that it should be: > target = IdeUtils.toRelativeAndFixSeparator( > config.getProject().getBasedir(), buildOutputDirectory, false ); > Thanks to Dan and others for assistance received previously! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-304) Removing @execute phase="generate-resources"
[ http://jira.codehaus.org/browse/MECLIPSE-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102952 ] Denis Cabasson commented on MECLIPSE-304: - the @execute tag shouldn't be removed. It is here to ensure the generate-resources phase is executed prior to the call to eclipse:eclipse mojo. Why would you want to have it removed? For projects with source code generation (projects using modello or castor), this ensure aditionnal java sources have been generated and attached as source resources to the project before generation of the eclipse descriptor. Changing @execute by @phase would only bind the eclipse:eclipse mojo to the phase, without ensuring it has been executed. > Removing @execute phase="generate-resources" > > > Key: MECLIPSE-304 > URL: http://jira.codehaus.org/browse/MECLIPSE-304 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.4 > Environment: Windows 2003 >Reporter: Auston McReynolds >Priority: Minor > > eclipse:m2eclipse and eclipse:eclipse shouldn't have to @execute > phase="generate-resources". > By removing this line and adding @phase generate-resources I can now run > eclipse:eclipse at the parent POM level as well as at the module level, with > ONE CATCH: > In org.apache.maven.plugin.eclipse.EclipsePlugin theres a TODO: > // TODO: Why are we using project in some places, and executedProject in > others?? > Well, once you remove the @execute you receive a barrage of NPE's. > However if within org.apache.maven.plugin.eclipse.EclipsePlugin @ validate() > I add > executedProject = this.project; to the top, everything works like a charm. > Can a configuration or flag be added that allows no @execution with the above > modification? > Regards, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-294) Sort items in the generated .classpath
[ http://jira.codehaus.org/browse/MECLIPSE-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102953 ] Denis Cabasson commented on MECLIPSE-294: - Would definitly be a good idea and that shouldn't break anything. > Sort items in the generated .classpath > -- > > Key: MECLIPSE-294 > URL: http://jira.codehaus.org/browse/MECLIPSE-294 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Max Bowsher > Attachments: eclipse-sort.patch > > > Currently, the ordering of items on the generated .classpath is controlled by > the JVM's HashSet ordering. > One effect of this is that the project-07 and project-33 tests are currently > commented out, because it's impossible to write an expected/.classpath file > that works everywhere. > More generally, it's bad that the classpath ordering can vary between > platforms and JVM orderings. > Therefore, I think it would be a good idea to sort the classpath. This would > be done by invoking Collections.sort in > AbstractIdeSupportMojo.doDependencyResolution. IdeDependency already > implements Comparable, on the basis of groupId+artifactId+type. Classifier > should be added to the properties considered in compareTo. > Patch attached as described above. -- This message is automatically 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: (MAVENUPLOAD-1651) junit 4.4
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomislav Stojcevich updated MAVENUPLOAD-1651: - Attachment: junit-4.4-bundle.jar Updated bundle that contains updated source jar with additional org/hamcrest class files included in the junit jar. > junit 4.4 > - > > Key: MAVENUPLOAD-1651 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1651 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Tomislav Stojcevich > Attachments: junit-4.4-bundle.jar, junit-4.4-bundle.jar > > > Upload new 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
[jira] Updated: (DOXIA-134) Apt parser issues
[ http://jira.codehaus.org/browse/DOXIA-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Cabasson updated DOXIA-134: - Attachment: DOXIA-134-headerCell.patch submitted patch should correct (at least to some extend) point 5, handling headerCells in AptSink. Point 1 looks sensible to me (stripping non significant EOL). Could you attach a full test case so I can try to re-play it? > Apt parser issues > - > > Key: DOXIA-134 > URL: http://jira.codehaus.org/browse/DOXIA-134 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Apt >Affects Versions: 1.0-alpha-8 >Reporter: Lukas Theussl > Fix For: 1.0-beta-1 > > Attachments: actual.txt, DOXIA-134-headerCell.patch, expected.txt > > > I did the following experiment: using the SinkTestDocument that I attached at > DOXIA-101 I generated two text documents, one by dumping the model directly > into a text sink, the other by piping it through the current apt sink, > parsing the result with the apt parser and dumping it into the same text sink > as before. The results should be the same since the second chain corresponds > to the 'identity transformation', ie piping a document through a parser and > sink should give you the original document. I attach the two text files for > comparison, here are the differences: > # the parser swallows newlines between text elements > # a paragraph within a list item is swallowed > # verbatim text within a definition list item is not processed correctly > # the closing of a definition list is not processed correctly > # table header cells are not recognized and newlines within table cells are > not processed correctly > Point 1 is not severe by itself because newlines are not significant in apt > source documents, however, two newlines are, so I am not sure if it doesn't > have consequences (eg within table cells). > Point 5 has partially been fixed by the patch Vincent attached at DOXIA-50. -- This message is automatically 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-1651) junit 4.4
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102956 ] Tomislav Stojcevich commented on MAVENUPLOAD-1651: -- A question about this particular upload. For the first time junit has included files from another project in their distributed jar. The files under the org/hamcrest package. The maven way would be not to include those files and just add a dependency to the org/hamcrest jar which is in the repo (version 1, although version 1.1 is available at http://code.google.com/p/hamcrest/downloads/list and I think that is what they used based on what's in their scm http://junit.cvs.sourceforge.net/junit/junit/lib). So, should I redo this and remove the org/hamcrest class files from the junit.jar that was obtained directly from the junit download site http://sourceforge.net/project/showfiles.php?group_id=15278 and add a maven dependency to the hamcrest 1.1 jar(which would also need to be uploaded), or leave it as is since they include those class files in their distribution? > junit 4.4 > - > > Key: MAVENUPLOAD-1651 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1651 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Tomislav Stojcevich > Attachments: junit-4.4-bundle.jar, junit-4.4-bundle.jar > > > Upload new 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
[jira] Commented: (CONTINUUM-1350) Documentation on Build profiles
[ http://jira.codehaus.org/browse/CONTINUUM-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102961 ] Emmanuel Venisse commented on CONTINUUM-1350: - Cqn you convert your xdoc file to APT? > Documentation on Build profiles > --- > > Key: CONTINUUM-1350 > URL: http://jira.codehaus.org/browse/CONTINUUM-1350 > Project: Continuum > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.1-beta-1 >Reporter: Olivier Lamy > Attachments: add-installation.png, add-profile.png, > CONTINUUM-1350.patch, setup-build-profile.png, setup-jdk-profile.png > > > Adding some documentation/screenshot on the build profile feature. -- This message is automatically 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-3118) Test-classes should come before classes in the classpath
[ http://jira.codehaus.org/browse/MNG-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MNG-3118: --- Attachment: MNG-3118-maven-project-r558713.patch Simple patch that reverses the classpath ordering of classes and test-classes. > Test-classes should come before classes in the classpath > > > Key: MNG-3118 > URL: http://jira.codehaus.org/browse/MNG-3118 > Project: Maven 2 > Issue Type: Improvement > Components: General >Affects Versions: 2.0.7 >Reporter: Paul Gier > Attachments: MNG-3118-maven-project-r558713.patch > > > Currently maven-project creates the test classpath in the order: classes, > tests-classes, dependencies. > It would be better if test-classes came first because sometimes it is useful > for a test class to replace a main class during testing. The opposite case > is not normally true (i.e. one would not want to override a test class with > one of the main classes). -- This message is automatically 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-3118) Test-classes should come before classes in the classpath
Test-classes should come before classes in the classpath Key: MNG-3118 URL: http://jira.codehaus.org/browse/MNG-3118 Project: Maven 2 Issue Type: Improvement Components: General Affects Versions: 2.0.7 Reporter: Paul Gier Currently maven-project creates the test classpath in the order: classes, tests-classes, dependencies. It would be better if test-classes came first because sometimes it is useful for a test class to replace a main class during testing. The opposite case is not normally true (i.e. one would not want to override a test class with one of the main classes). -- This message is automatically 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: (SUREFIRE-61) Incorrect classpath ordering
[ http://jira.codehaus.org/browse/SUREFIRE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102980 ] Paul Gier commented on SUREFIRE-61: --- The issue can be seen mainly when the fork mode is set to never. Because if the surefire plugin forks, then the ordering gets rearranged similar to what Barrett described. However, I think this is caused by loading the paths into the properties object and then using an enumeration to iterate through them. The Properties object doesn't retain the order of the loaded props, so they really could come out in any order, not just the sorted order that is shown above. So I think that Barrett's approach is the right one. The classpath elements really need to be sorted after they are loaded from properties file. Hopefully someone will apply his patch or something similar to it soon :) > Incorrect classpath ordering > > > Key: SUREFIRE-61 > URL: http://jira.codehaus.org/browse/SUREFIRE-61 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 3.x support >Affects Versions: 2.0 (2.2 plugin) > Environment: maven2.0.4, sun-jdk-1.5.0.09, maven-surefire-plugin 2.2, > surefire 2.0, gentoo linux x86 >Reporter: Martin Vysny >Priority: Critical > Fix For: 2.4 > > Attachments: my-app.zip, output.log, > SUREFIRE61_barrettas_surefire_surefire-booter_for_rev_489098.patch > > > Surefire incorrectly interprets classpath ordering. > Steps to reproduce: > 1. unzip my-app.zip - it's a simple mvn project created with > mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app > and lightly patched > 2. mvn test > in my case, it prints out > jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties > jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties > which is incorrect. log4j.properties is located both in jxta.jar and > src/test/resources, but I think that src/test/resources takes precedence over > jxta. This ordering is set correctly in surefire36745tmp file I think, but > surefire seems to ignore the ordering. -- This message is automatically 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: (MSITE-177) Docs are not updated if only site.xml changed
[ http://jira.codehaus.org/browse/MSITE-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102985 ] John Allen commented on MSITE-177: -- Same here, the logic is obviously broken in regards to what requires a rebuild. if site.xml has changed then everything bar external reports needs to be recreated. > Docs are not updated if only site.xml changed > - > > Key: MSITE-177 > URL: http://jira.codehaus.org/browse/MSITE-177 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 >Reporter: Jörg Hohwiller > Fix For: 2.0-beta-7 > > > If I update site.xml (e.g. add new menu-items) and regenerate my existing > site, the index gets updated but other existing pages are not rebuild and > therefore show the menus in the state before the site.xml has changed (so new > menus are missing). This causes a confusing site where menus appear and > disappear while surfing. > I only use xdos (and they are in a subfolder) so I can not tell if this > happens with apt as well. I reproduced the problem with "mvn site" and "mvn > site:stage". > As a workaround I can delete the old site before building. Since I stage the > site directly to the final destination on the local machine where it is > served this is not very suitable because then the site is broken until it is > completely rebuild. > If you consider to fix this issue please beware that site.xml can inherit > stuff in multiproject envronments. > So it is unclear if the optimization to only re-generate if something has > changed makes sense at all. It might be quite complicated to determine this - > the question is how much time is saved by this at all. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-61) Incorrect classpath ordering
[ http://jira.codehaus.org/browse/SUREFIRE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated SUREFIRE-61: -- Attachment: SUREFIRE61-surefire-booter-r558713.patch Attaching a slightly cleaned up patch. > Incorrect classpath ordering > > > Key: SUREFIRE-61 > URL: http://jira.codehaus.org/browse/SUREFIRE-61 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 3.x support >Affects Versions: 2.0 (2.2 plugin) > Environment: maven2.0.4, sun-jdk-1.5.0.09, maven-surefire-plugin 2.2, > surefire 2.0, gentoo linux x86 >Reporter: Martin Vysny >Priority: Critical > Fix For: 2.4 > > Attachments: my-app.zip, output.log, > SUREFIRE61-surefire-booter-r558713.patch, > SUREFIRE61_barrettas_surefire_surefire-booter_for_rev_489098.patch > > > Surefire incorrectly interprets classpath ordering. > Steps to reproduce: > 1. unzip my-app.zip - it's a simple mvn project created with > mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app > and lightly patched > 2. mvn test > in my case, it prints out > jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties > jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties > which is incorrect. log4j.properties is located both in jxta.jar and > src/test/resources, but I think that src/test/resources takes precedence over > jxta. This ordering is set correctly in surefire36745tmp file I think, but > surefire seems to ignore the ordering. -- This message is automatically 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] Work stopped: (MRM-426) Search does not work for snapshots because of different version values in index and database when the snapshot version is unique
[ http://jira.codehaus.org/browse/MRM-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-426 stopped by Maria Odea Ching. > Search does not work for snapshots because of different version values in > index and database when the snapshot version is unique > > > Key: MRM-426 > URL: http://jira.codehaus.org/browse/MRM-426 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-2 >Reporter: Maria Odea Ching >Assignee: Maria Odea Ching > > When an artifact with unique snapshots is searched from Archiva, the search > result would contain different hits for that artifact which has the same > version but when you click the version to browse the artifact.. an > ObjectNotFound error is returned. Below is an example of this behavior. > The artifact to be searched is castor-anttasks. Let's say it has 3 SNAPSHOT > versions 1.1.2-20070427.065136-1, 1.1.2-20070506.163513-2 and > 1.1.2-20070506.163513-3 in the repository, and the path to this artifact is > [REPO]/org/codehaus/castor/castor-anttasks/1.1.2-SNAPSHOT. > The search results would then look like this: > Hits: 3 of 3 > castor-anttasks > org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT > castor-anttasks > org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT > castor-anttasks > org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT > When you click either of the versions to browse the artifact, what you would > get is this error: > 'Unable to find project model for > [org.codehaus.castor:castor-anttasks:1.1.2-SNAPSHOT]' -- This message is automatically 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: (MSITE-79) mechanism for local preview of a multiproject site tree
[ http://jira.codehaus.org/browse/MSITE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102990 ] John Allen commented on MSITE-79: - stage was supposed to be a peer of deploy, ie a 'deploy to local directory' function - then we added the 'deploy to remote directory' so we could properly stage our sites. But anyways my point is that consistency is best and as deploy doesnt generate stuff then neither should stage. Plus I absolutely hate it when plugins get too clever and start forking off lifecycles as this 'atomic' build behaviour is hardly ever what you want in a complex build. > mechanism for local preview of a multiproject site tree > --- > > Key: MSITE-79 > URL: http://jira.codehaus.org/browse/MSITE-79 > Project: Maven 2.x Site Plugin > Issue Type: New Feature >Reporter: Brett Porter > Fix For: 2.0-beta-7 > > > currently difficult as they are in target/site/*, where the links rely on ./ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRM-426) Search does not work for snapshots because of different version values in index and database when the snapshot version is unique
[ http://jira.codehaus.org/browse/MRM-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-426. Resolution: Fixed Fixed in -r558795 Fix: - Added and modified code for handling snapshots (if the versions of a specific artifact snapshot are only timestamped versions, add a generic snapshot which is pointing to the latest timestamp version) in DefaultRepositoryBrowsing and ProjectModelToDatabaseConsumer. - Updated pom validations in ProjectModelToDatabaseConsumer - handling of timestamped versions were considered - Added isUniqueSnapshot(..) and isGenericSnapshot(..) in VersionUtil - Added new attribute 'modelVersion' in DependencyTreeTag to get the in-pom version. Did not use the version attribute so as to retain the actual version being browsed. Also updated DependencyTree - Updated the ff. pages for the version to be displayed: artifactInfo.jspf, showArtifact.jsp, dependencyTree.jsp and artifactDecorator.jsp - Updated the version in SearchResultHit > Search does not work for snapshots because of different version values in > index and database when the snapshot version is unique > > > Key: MRM-426 > URL: http://jira.codehaus.org/browse/MRM-426 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-2 >Reporter: Maria Odea Ching >Assignee: Maria Odea Ching > > When an artifact with unique snapshots is searched from Archiva, the search > result would contain different hits for that artifact which has the same > version but when you click the version to browse the artifact.. an > ObjectNotFound error is returned. Below is an example of this behavior. > The artifact to be searched is castor-anttasks. Let's say it has 3 SNAPSHOT > versions 1.1.2-20070427.065136-1, 1.1.2-20070506.163513-2 and > 1.1.2-20070506.163513-3 in the repository, and the path to this artifact is > [REPO]/org/codehaus/castor/castor-anttasks/1.1.2-SNAPSHOT. > The search results would then look like this: > Hits: 3 of 3 > castor-anttasks > org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT > castor-anttasks > org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT > castor-anttasks > org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT > When you click either of the versions to browse the artifact, what you would > get is this error: > 'Unable to find project model for > [org.codehaus.castor:castor-anttasks:1.1.2-SNAPSHOT]' -- This message is automatically 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: (MRM-425) Search and Browse do not work for snapshots
[ http://jira.codehaus.org/browse/MRM-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-425. Resolution: Fixed Fixed in -r558795. See comments in MRM-426 for the fix. > Search and Browse do not work for snapshots > --- > > Key: MRM-425 > URL: http://jira.codehaus.org/browse/MRM-425 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-alpha-2 >Reporter: John Didion >Assignee: Maria Odea Ching > > When I to browse or search an artifact with snapshots, I usually get an error > when I try to go to the artifact info page. Looking at the logs, Archiva is > complaining that the version (x.y.z-SNAPSHOT) does not match the pom file's > version (x.y.z-timestamp-buildno). > Ideally, sequence for browse would be group->artifact->base version->snapshot > version. In other words, I would first browse to the base version, under > which would be listed all the snapshot versions. The pom snippet on the base > version page would have x.y.z-SNAPSHOT and the pom snippet > on the snapshot version page would have > x.y.z-timestamp-buildno. I think this would be a lot more > clear than how it currently works - mixing base versions and snapshot > versions on the same page. -- This message is automatically 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: (MSITE-129) modules list empty if modules don't use this project as parent in reactor build
[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103004
]
John Allen commented on MSITE-129:
--
I'm curious should a site be displaying a project's modules or a project's
children (i.e. 'inherited from' projects)? I know I am more interested in the
later when I'm browsing sub-systems, as, as with any design effort, one divides
and conquers, layering common behaviour and semantics as you decompose. But I
would then expect those children to be part of this natural aggregated scope -
if something is a child then it is an ordered relationship with its parent and
it should be possible to view/navigate/build following those relationships in
both directions.
It's worth noting that the dual behaviour re how to find parents/modules comes
the attempt to support generating a site for a project that has modules and or
a parent but is not running in the reactor. If one says that modules are not
children but simply an aggregation, and thus parent's can not know of their
children in a declarative way, then the only way to deduce children of a
project is to have a reactor and to re-build the inheritance hierarchy from the
the edges up, thus discovering the true project ancestry.
Without a declarative way for a parent to specify its children then the parent
site will never be able to list its children without a reactor and inferencing.
Maybe we should add a new semantic to help us here that differentiates from a
project's children (inheritance) and modules (collection)?
> modules list empty if modules don't use this project as parent in reactor
> build
> ---
>
> Key: MSITE-129
> URL: http://jira.codehaus.org/browse/MSITE-129
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-5
>Reporter: Kenney Westerhof
>Assignee: Kenney Westerhof
>Priority: Minor
> Fix For: 2.0-beta-7
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor
> projects) it scans all
> projects to see if it's parent project equals the current project. If so,
> it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted
> and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as
> modules so that I can easily
> built everything and generate a site. However, this fake root pom is never
> used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site
> layouts are implemented:
> - a physical layout where the modules match the section of the pom,
> reflecting filesystem layout,
> - a project hierarchy layout based on
> and one or the other is used depending on wheter the build contains more than
> 1 project or not.
> My first feeling is that since the tag is called ${modules} (or ref="modules"/>) that
> the site should use the , not the .
> It should also take into consideration, that IF a reactor build is running,
> it should only use the modules that are also
> in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a
> site with not all projects in it).
> Thoughts?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MSITE-129) modules list empty if modules don't use this project as parent in reactor build
[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103004
]
John Allen edited comment on MSITE-129 at 7/23/07 12:30 PM:
I'm curious should a site be displaying a project's modules or a project's
children (i.e. 'inherited from' projects)? I know I am more interested in the
later when I'm browsing sub-systems, as, as with any design effort, one divides
and conquers, layering common behaviour and semantics as you decompose. But I
would then expect those children to be part of this natural aggregated scope -
if something is a child then it is an ordered relationship with its parent and
it should be possible to view/navigate/build following those relationships in
both directions.
It's worth noting that the dual behaviour re how to find parents/modules comes
from the attempt to support generating a site for a project that has modules
and or a parent but is not running in the reactor. If one says that modules are
not children but simply an aggregation, and thus parent's can not know of their
children in a declarative way, then the only way to deduce children of a
project is to have a reactor and to re-build the inheritance hierarchy from the
the edges up, thus discovering the true project ancestry.
Without a declarative way for a parent to specify its children then the parent
site will never be able to list its children without a reactor and inferencing.
Maybe we should add a new semantic to help us here that differentiates from a
project's children (inheritance) and modules (collection)?
was:
I'm curious should a site be displaying a project's modules or a project's
children (i.e. 'inherited from' projects)? I know I am more interested in the
later when I'm browsing sub-systems, as, as with any design effort, one divides
and conquers, layering common behaviour and semantics as you decompose. But I
would then expect those children to be part of this natural aggregated scope -
if something is a child then it is an ordered relationship with its parent and
it should be possible to view/navigate/build following those relationships in
both directions.
It's worth noting that the dual behaviour re how to find parents/modules comes
the attempt to support generating a site for a project that has modules and or
a parent but is not running in the reactor. If one says that modules are not
children but simply an aggregation, and thus parent's can not know of their
children in a declarative way, then the only way to deduce children of a
project is to have a reactor and to re-build the inheritance hierarchy from the
the edges up, thus discovering the true project ancestry.
Without a declarative way for a parent to specify its children then the parent
site will never be able to list its children without a reactor and inferencing.
Maybe we should add a new semantic to help us here that differentiates from a
project's children (inheritance) and modules (collection)?
> modules list empty if modules don't use this project as parent in reactor
> build
> ---
>
> Key: MSITE-129
> URL: http://jira.codehaus.org/browse/MSITE-129
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-5
>Reporter: Kenney Westerhof
>Assignee: Kenney Westerhof
>Priority: Minor
> Fix For: 2.0-beta-7
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor
> projects) it scans all
> projects to see if it's parent project equals the current project. If so,
> it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted
> and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as
> modules so that I can easily
> built everything and generate a site. However, this fake root pom is never
> used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site
> layouts are implemented:
> - a physical layout where the modules match the section of the pom,
> reflecting filesystem layout,
> - a project hierarchy layout based on
> and one or the other is used depending on wheter the build contains more than
> 1 project or not.
> My first feeling is that since the tag is called ${modules} (or ref="modules"/>) that
> the site should use the , not the .
> It should also take into consideration, that IF a reactor build is running,
> it should only use the modules that are also
> in the reactor (so you
[jira] Commented: (MSITE-180) Missing url tag in (parent) pom make it ignore the site inheritence system
[ http://jira.codehaus.org/browse/MSITE-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103007 ] John Allen commented on MSITE-180: -- I would expect that something else is going wrong here as site.xml inheritance doesnt use a project's URL to define its identity. > Missing url tag in (parent) pom make it ignore the site inheritence system > -- > > Key: MSITE-180 > URL: http://jira.codehaus.org/browse/MSITE-180 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 >Reporter: Geoffrey De Smet > > IF none of the poms (module or parent) don't have an url tag, like this: > > ... > ... > ... > > (It doesn't matter if they have url tags in scm, distribution etc) > THEN site inheritence quitely isn't applied, for example in the parent's > site.xml > > http://www.mavenblogs.org/"/> > > isn't inherited in the childe module's site. > proposed solutions: > - or fix it :) > - or document this wanted behaviour in the site plugin's documentation at > http://maven.apache.org/plugins/maven-site-plugin/howto.html > with something like > "Site inheritence only works if you have a url tag in your parent pom." > because this can cost people many hours - it did for me > But once site inheritence works, it's very nice though :) -- This message is automatically 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: (MSITE-188) Execution order of report plugins is arbitrary if inheritance is involved
[ http://jira.codehaus.org/browse/MSITE-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103010 ] John Allen commented on MSITE-188: -- Execution order of plugin's is something that has had quite a bit of discussion about but I'm afraid I have no specific URLs to let you catch up with the current thinking re this. > Execution order of report plugins is arbitrary if inheritance is involved > - > > Key: MSITE-188 > URL: http://jira.codehaus.org/browse/MSITE-188 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 > Environment: maven 2.0.4, windows 2000 >Reporter: David Vicente >Priority: Critical > > I have created a maven 2 report : Dashboard report which aggregate all > reports results in one report. > My plugin must be executed as the last one even if i can't bind the > "post-site" phase or use the "aggregator" annotation. > I declare my report plugin as the last one in the reporting section of my POM. > When i run mvn site on a single project, it's ok, my plugin has been > executed as the last one. > The reports list has been ordered as declared in my POM. > But if i run "mvn site" on a multi-project POM, the reports list isn't > ordered as before. > I think, it's the same problem as > http://jira.codehaus.org/browse/MNG-1994?page=all -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-159) Absolute URI rendered as relative URI if absolute URI related to domain of POM URI
[ http://jira.codehaus.org/browse/MSITE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103012 ] John Allen commented on MSITE-159: -- Re isnt that why you define them as absolute? Well yes but also not really, a project's URL is absolute as it is its published external web address accessible from anywhere. I can depend on your project and will want to link to it and will need this to see your site. If you made your sub-modules use explicitly defined relative URLs then they would never be accessible to anyone other than your related site pages (ie parent/children). We find it easier to generate our offline docs using relatives as well via the site:stage mojo - this lets us create a completely self referential site without having the browser try and jump online all the time. I expect the real answer to these 'i dont like', 'i do like' issues with relative URLs is to make it a configuration option :) > Absolute URI rendered as relative URI if absolute URI related to domain of > POM URI > -- > > Key: MSITE-159 > URL: http://jira.codehaus.org/browse/MSITE-159 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Ted Husted > > Under site-beta5 > if the POM references a URI like > http://struts.apache.org > absolute URLs used in the site.xml file are converted to relative references. > For example a reference to to "http://struts.apache.org/1.x"; becomes "1.x", > and a reference to > just "http://struts.apache.org"; becomes an empty string. > If the documentation is being used offline, there are many cases when we want > to refer people back to the website, to be sure the current information is > used. The best use case is a download page that determines the mirror via > CGI. > Another use case is referring to a sister site in the domain, that might > refer to another version. If used locally, the other site might not be in the > relative location. > Switching back to beta4 cures the behavior, and absolute URIs remain > absolute, as expected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MSITE-159) Absolute URI rendered as relative URI if absolute URI related to domain of POM URI
[ http://jira.codehaus.org/browse/MSITE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103012 ] John Allen edited comment on MSITE-159 at 7/23/07 12:48 PM: IMHO a project.URL is supposed to point to the web accessible location for that project and thus yes there is tight coupling between the distroManagement.site.url and the project.URL. If one wants to redirect/map via web mechanism the project.URL to some other web location then that's fine too. (i.e. redirect your htdocs requests to htdocs/site) Re isnt that why you define them as absolute? Well yes but also not really, a project's URL is absolute as it is its published external web address accessible from anywhere for that artifact. I can depend on your project and will want to link to its web materials. If you made your sub-modules use explicitly defined relative URLs then they would never be accessible to anyone other than your related site pages (ie parent/children). Re offline - We find it easier to generate our offline docs using these auto-generated relative URLs, we get a sompletely self referential site and the browser doesnt try and jump online all the time. I expect the real answer to these 'i dont like', 'i do like' issues with relative URLs is to make it a configuration option :) was: Re isnt that why you define them as absolute? Well yes but also not really, a project's URL is absolute as it is its published external web address accessible from anywhere. I can depend on your project and will want to link to it and will need this to see your site. If you made your sub-modules use explicitly defined relative URLs then they would never be accessible to anyone other than your related site pages (ie parent/children). We find it easier to generate our offline docs using relatives as well via the site:stage mojo - this lets us create a completely self referential site without having the browser try and jump online all the time. I expect the real answer to these 'i dont like', 'i do like' issues with relative URLs is to make it a configuration option :) > Absolute URI rendered as relative URI if absolute URI related to domain of > POM URI > -- > > Key: MSITE-159 > URL: http://jira.codehaus.org/browse/MSITE-159 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Ted Husted > > Under site-beta5 > if the POM references a URI like > http://struts.apache.org > absolute URLs used in the site.xml file are converted to relative references. > For example a reference to to "http://struts.apache.org/1.x"; becomes "1.x", > and a reference to > just "http://struts.apache.org"; becomes an empty string. > If the documentation is being used offline, there are many cases when we want > to refer people back to the website, to be sure the current information is > used. The best use case is a download page that determines the mirror via > CGI. > Another use case is referring to a sister site in the domain, that might > refer to another version. If used locally, the other site might not be in the > relative location. > Switching back to beta4 cures the behavior, and absolute URIs remain > absolute, as expected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-132) Use instead of for directories
[ http://jira.codehaus.org/browse/MSITE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103013 ] John Allen commented on MSITE-132: -- There are indeed some gotchas re the naming of artifactIds and directories in Maven. for instance the release plugin assumes artifactId == directory name (or at least it used to) and thus most people have those being the same. Note that lets you jump into any directory for a module project but i didnt think that a project's name was ever used in any form of path construction. > Use instead of for directories > -- > > Key: MSITE-132 > URL: http://jira.codehaus.org/browse/MSITE-132 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Environment: maven-2.0.4 on any operating system with the latests > released plugins (after the doxia-1.0-alpha-8.pom bug) >Reporter: Jörg Hohwiller > > The of a project in the POM may contain characters that cause trouble > when used in directory names. > E.g. my open-source project: > http://svn.projxpert.com/mmm/trunk/ > Uses names such as "MMM::Configuration". Now when I stage the site of the > entire project, the relative link "MMM::Configuration" causes mozilla to say > something like "Unknown protocol 'mmm:'". > Could you please use the artefactId instead. > I think personally think that this is a lot better anyways. > BTW - Thanks for your greate work. M2 is awesome!!! -- This message is automatically 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: (MSITE-236) multi module reporting - main page doesn't show links to contained modules
[ http://jira.codehaus.org/browse/MSITE-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103014 ] John Allen commented on MSITE-236: -- If you mean modules menu, in the top LHS (using the default site.xml) then yes they should be links and if they're not something else is afoot. Note that those module links should be on every generated page, not just the index.html one. > multi module reporting - main page doesn't show links to contained modules > -- > > Key: MSITE-236 > URL: http://jira.codehaus.org/browse/MSITE-236 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Jan Vissers > > In a multi module project, the "site" generates a main page index.html, which > has the contained modules on the upper left hand corner in bold face. These > should be hyperlinks to the actual module's index.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: (MSITE-169) links to modules where not working if a modules dir is used
[ http://jira.codehaus.org/browse/MSITE-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103015 ] John Allen commented on MSITE-169: -- By default maven assumes that modules live under the parent project's directory. And Jason is dead right, simply redeclare the correct URL and distroManagement.site.utl info in all the projects to avoid this, in your case, invalid assumption > links to modules where not working if a modules dir is used > --- > > Key: MSITE-169 > URL: http://jira.codehaus.org/browse/MSITE-169 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4, 2.0-beta-5, 2.0-beta-6 >Reporter: Mathias Brökelmann > Attachments: MNG-MSITE-169-maven-site-plugin.patch > > > I've to place the modules into a separate directory: > root/ > ..pom.xml > ..modules/ > module1 > module2 > this is supported by maven through > > modules/module1 > modules/module2 > > in pom. > but the site generation seems to be broken: > if mvn site-deploy is used the links to the modules contain > modules/module1/index.html which is ok but unfortunately the generated site > structure will be generated as follows: > root/ > ..module1 > ..module2 > The result is that the links do not work. > If I run mvn site-stage everything looks ok. The links doesn't contain > modules dir anymore and eveything is working. -- This message is automatically 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: (MSITE-238) multi project default URL is wrong
[ http://jira.codehaus.org/browse/MSITE-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103017 ] John Allen commented on MSITE-238: -- You should not be including any 'target' stuff in URLs - The URLs will resolve properly when the project has been either staged (site:stage) or deployed (site:deploy). Referential addressing never works until the entities in question have been placed in the correct namespace (in this case deployed) > multi project default URL is wrong > -- > > Key: MSITE-238 > URL: http://jira.codehaus.org/browse/MSITE-238 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Paul Sundling >Priority: Trivial > > In multi module projects the default URL if non is included is > //target/site//index.html , but it > should be ///target/site/index.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: (MSITE-195) Module navigation entries point to index.html not /index.html
[ http://jira.codehaus.org/browse/MSITE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103018 ] John Allen commented on MSITE-195: -- Probably related to the way the modules have been found (ie via reactor, via filesystem or via the repository). > Module navigation entries point to index.html not /index.html > - > > Key: MSITE-195 > URL: http://jira.codehaus.org/browse/MSITE-195 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Environment: Intel box running Windows XP >Reporter: Dale Chapman >Priority: Minor > > I am using Maven version 2.0.4 > I am experimenting with Maven to see if it will suit my organizations needs > and I have created a simple example that looks like the following: > App1Pom > + App1Ear > + App1Jar > (pom.xml snippet) > > App1Ear > App1Jar > > When I generate the site using mvn site, the "About" page for App1Pom shows > the two modules in the module section of the navigation, but neither has an > anchor. When I navigate to another section, both module entries will now > contain an anchor that points to index.html. > (index.html snippet) > Modules > > > > App1Ear > > > > App1Jar > > > (project-info.html snippet) > Modules > > > > App1Ear > > > > App1Jar > > > When I generate the site using mvn site:stage, the navigation section > contains the correct entries of App1Ear/index.html and App1Jar/index.html. > (index.html snippet) > Modules > > > > App1Ear > > > > App1Jar > > > I have tried to review the current bug list to see if this problem has > already been reported, but I was not able to see an entry that describes this > situation. If I have a usage problem please point me to some documentation > that can help me understand. > Thanks. > Dale Chapman. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MSITE-195) Module navigation entries point to index.html not /index.html
[ http://jira.codehaus.org/browse/MSITE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103018 ] John Allen edited comment on MSITE-195 at 7/23/07 1:06 PM: --- Probably related to the way the modules have been found (ie via reactor, via filesystem or via the repository). In some cases (namely non-reactor) a module project wont be fully interpolated (and indeed inheritance composition may not have occured either, cant remember). Best to explicitly define URLs (and thus distroManagement.site.url) for all your projects if you do non-reactor based site builds was: Probably related to the way the modules have been found (ie via reactor, via filesystem or via the repository). > Module navigation entries point to index.html not /index.html > - > > Key: MSITE-195 > URL: http://jira.codehaus.org/browse/MSITE-195 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Environment: Intel box running Windows XP >Reporter: Dale Chapman >Priority: Minor > > I am using Maven version 2.0.4 > I am experimenting with Maven to see if it will suit my organizations needs > and I have created a simple example that looks like the following: > App1Pom > + App1Ear > + App1Jar > (pom.xml snippet) > > App1Ear > App1Jar > > When I generate the site using mvn site, the "About" page for App1Pom shows > the two modules in the module section of the navigation, but neither has an > anchor. When I navigate to another section, both module entries will now > contain an anchor that points to index.html. > (index.html snippet) > Modules > > > > App1Ear > > > > App1Jar > > > (project-info.html snippet) > Modules > > > > App1Ear > > > > App1Jar > > > When I generate the site using mvn site:stage, the navigation section > contains the correct entries of App1Ear/index.html and App1Jar/index.html. > (index.html snippet) > Modules > > > > App1Ear > > > > App1Jar > > > I have tried to review the current bug list to see if this problem has > already been reported, but I was not able to see an entry that describes this > situation. If I have a usage problem please point me to some documentation > that can help me understand. > Thanks. > Dale Chapman. -- This message is automatically 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-116) Impossible to aggregate javadoc if snapshot never built
[
http://jira.codehaus.org/browse/MJAVADOC-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Petrelli updated MJAVADOC-116:
--
Attachment: javadoc-plugin-test-case.zip
Attached a small test case.
I noticed that the bug is triggered if a module depends on another, even if in
correct order.
This bug is still present in the 2.3 version of the plugin.
> Impossible to aggregate javadoc if snapshot never built
> ---
>
> Key: MJAVADOC-116
> URL: http://jira.codehaus.org/browse/MJAVADOC-116
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Damien Lecan
> Attachments: javadoc-plugin-test-case.zip
>
>
> In a multi-module projet, I build an aggregated Javadoc for the site.
> The project is built with "mvn clean deploy site-deploy"
> When I add a new project, the next build always fails because the javadoc
> plugin can't find at least one snapshot for the new added module
> In the following example, I added a new module tele.persistance:pers-commons,
> which have never been built before.
> Maven tries to download it but it can't find it (never build before).
> {noformat} [INFO] [site:site]
> [WARNING] Unable to load parent project from repository: Could not find the
> model file '/continuum-folders/working-directory/116/../pom.xml'.
> [INFO] Skipped "About" report, file "index.html" already exists for the
> English version.
> [ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0
> [ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0
> [INFO] Generate "JavaDocs" report.
> [INFO] snapshot tele:commons:1.2.0-alpha-1-SNAPSHOT: checking for updates
> from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-data:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-api:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-commons:1.2.0-alpha-1-SNAPSHOT:
> checking for updates from mirror.snapshots
> Downloading:
> http://proxy/maven2-snapshots/repository/tele/persistance/pers-commons/1.2.0-alpha-1-SNAPSHOT/pers-commons-1.2.0-alpha-1-SNAPSHOT.jar
> [WARNING] Unable to get resource
> 'tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT' from repository
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=tele.persistance
> -DartifactId=pers-commons \
> -Dversion=1.2.0-alpha-1-SNAPSHOT -Dpackaging=jar
> -Dfile=/path/to/file
> Path to dependency:
> 1) tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> 2) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> {noformat}
> If I make an intermediate "install", everything works fine
--
This message is automatically 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: (DOXIA-134) Apt parser issues
[ http://jira.codehaus.org/browse/DOXIA-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103027 ] Lukas Theussl commented on DOXIA-134: - Patch applied, thanks! I need to do some house cleaning but I will soon attach a more complete patch to DOXIA-101, that will allow you to re-produce my results. > Apt parser issues > - > > Key: DOXIA-134 > URL: http://jira.codehaus.org/browse/DOXIA-134 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Apt >Affects Versions: 1.0-alpha-8 >Reporter: Lukas Theussl > Fix For: 1.0-beta-1 > > Attachments: actual.txt, DOXIA-134-headerCell.patch, expected.txt > > > I did the following experiment: using the SinkTestDocument that I attached at > DOXIA-101 I generated two text documents, one by dumping the model directly > into a text sink, the other by piping it through the current apt sink, > parsing the result with the apt parser and dumping it into the same text sink > as before. The results should be the same since the second chain corresponds > to the 'identity transformation', ie piping a document through a parser and > sink should give you the original document. I attach the two text files for > comparison, here are the differences: > # the parser swallows newlines between text elements > # a paragraph within a list item is swallowed > # verbatim text within a definition list item is not processed correctly > # the closing of a definition list is not processed correctly > # table header cells are not recognized and newlines within table cells are > not processed correctly > Point 1 is not severe by itself because newlines are not significant in apt > source documents, however, two newlines are, so I am not sure if it doesn't > have consequences (eg within table cells). > Point 5 has partially been fixed by the patch Vincent attached at DOXIA-50. -- This message is automatically 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: (MEV-541) The jaxrpc-impl/1.1.3_01 project has an incorrect reference for the FastInfoSet dependency
The jaxrpc-impl/1.1.3_01 project has an incorrect reference for the FastInfoSet dependency -- Key: MEV-541 URL: http://jira.codehaus.org/browse/MEV-541 Project: Maven Evangelism Issue Type: Bug Components: Invalid POM Reporter: Marc Chung The jaxrpc-impl pom references a dependency that *appears* to be incorrect. Specifically, it's looking for FastInfoSet in org.jvnet.fastinfoset.FasInfoSet, but the dependency is really located in com.sun.xml.fastinfoset.FastInfoSet. See: http://repo1.maven.org/maven2/com/sun/xml/rpc/jaxrpc-impl/1.1.3_01/jaxrpc-impl-1.1.3_01.pom See: http://repo1.maven.org/maven2/com/sun/xml/fastinfoset/FastInfoset/1.0.2/FastInfoset-1.0.2.pom Solution: A) Either correct the FastInfoSet dependency in the jaxrpc-impl project Change this: org.jvnet.fastinfoset FastInfoset 1.0.2 To this: com.sun.xml.fastinfoset FastInfoset 1.0.2 B) Or add a org.jvnet.fastinfoset dependency and use a relocation (which may look something like this) org.jvnet.fastinfoset FastInfoSet 1.0.2 com.sun.xml.fastinfoset I'd personally go for the first approach. Thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-94) Allow eclipse:eclipse to work on pom (and other) projects
[ http://jira.codehaus.org/browse/MECLIPSE-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103033 ] Vincent Massol commented on MECLIPSE-94: Project files for POM project could be generated automatically at least for leaf projects (i.e. with no children). > Allow eclipse:eclipse to work on pom (and other) projects > - > > Key: MECLIPSE-94 > URL: http://jira.codehaus.org/browse/MECLIPSE-94 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Felipe Leme > > I'm creating a Java EE project based on the m2book (which I was reviewing; > it's not available yet...) and one of the projects is a pom-packaging project > used for integration tests. According to Vincent, currently this project must > be a pom (in fact, I tried to set it as jar, but then the test phase would be > run anyway, which would cause the tests to fail), as it doesn't produces a > jar. But as it has java files (on the src/main/it/java directory), I tried to > call eclipse:eclipse but it fails, saying that "Not running eclipse plugin > goal for pom project". > For these scenarios, I think a propery would be enough. At first I thought > something about a 'force' or 'forceGeneration' property, would enough, which > the code change being from: > if ( "pom".equals( packaging ) && eclipseProjectDir == null ) > to: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > Then I realized there is other place where the pom nature is checked: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > So, I think a better name for the property would be 'javaProject' and the > change would be: > final boolean isJavaProjectProperty = // read property; defaults to false... > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !isJavaProjectProperty ) > isJavaProject = isJavaProjectProperty || !"ear".equals( packaging ) && > !"pom".equals( packaging ); > If nobody objects and someone is willing to apply the changes, I can provide > such patch (with the proper test cases). > -- Felipe > PS: I'm assigning it to Vincent for now, as he 'dreamed' that such features > already existed :-) -- This message is automatically 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: (MSITE-159) Absolute URI rendered as relative URI if absolute URI related to domain of POM URI
[ http://jira.codehaus.org/browse/MSITE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103036 ] Ted Husted commented on MSITE-159: -- If the configuration option said "render absolute URLs absolute," then yes, that would be helpful. > Absolute URI rendered as relative URI if absolute URI related to domain of > POM URI > -- > > Key: MSITE-159 > URL: http://jira.codehaus.org/browse/MSITE-159 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Ted Husted > > Under site-beta5 > if the POM references a URI like > http://struts.apache.org > absolute URLs used in the site.xml file are converted to relative references. > For example a reference to to "http://struts.apache.org/1.x"; becomes "1.x", > and a reference to > just "http://struts.apache.org"; becomes an empty string. > If the documentation is being used offline, there are many cases when we want > to refer people back to the website, to be sure the current information is > used. The best use case is a download page that determines the mirror via > CGI. > Another use case is referring to a sister site in the domain, that might > refer to another version. If used locally, the other site might not be in the > relative location. > Switching back to beta4 cures the behavior, and absolute URIs remain > absolute, as expected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3119) Duplicate attached artifacts should not be allowed.
Duplicate attached artifacts should not be allowed. --- Key: MNG-3119 URL: http://jira.codehaus.org/browse/MNG-3119 Project: Maven 2 Issue Type: Improvement Components: General Affects Versions: 2.0.7 Reporter: Paul Gier Currently, a project allows duplicate artifacts to be attached. This causes the second and other additional artifacts to overwrite the first attached artifact. This occurs during the package, install, and deploy phases. This can be reproduced by adding three instances of the source plugin (with different ids) to a project build configuration. The 2nd plugin will overwrite the first, and the third will overwrite the second. The desired behaviour is that the user should receive a warning or error when this happens. -- This message is automatically 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-3119) Duplicate attached artifacts should not be allowed.
[ http://jira.codehaus.org/browse/MNG-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MNG-3119: --- Attachment: MNG-3119-maven-project-r558713.patch Adding a patch that displays a warning message if an attempt is made to attach a duplicate artifact. I didn't see any existing exception classes that fit this scenario, so I created a new exception class. The exception does not propagate any further than the MavenProjectHelper in this case because I didn't want to break any existing code (plugins, etc.) that may depend on the helper attach artifact methods not throwing an exception. > Duplicate attached artifacts should not be allowed. > --- > > Key: MNG-3119 > URL: http://jira.codehaus.org/browse/MNG-3119 > Project: Maven 2 > Issue Type: Improvement > Components: General >Affects Versions: 2.0.7 >Reporter: Paul Gier > Attachments: MNG-3119-maven-project-r558713.patch > > > Currently, a project allows duplicate artifacts to be attached. This causes > the second and other additional artifacts to overwrite the first attached > artifact. This occurs during the package, install, and deploy phases. > This can be reproduced by adding three instances of the source plugin (with > different ids) to a project build configuration. The 2nd plugin will > overwrite the first, and the third will overwrite the second. > The desired behaviour is that the user should receive a warning or error when > this happens. -- This message is automatically 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: (MPIR-70) NullPointerException when generating Dependencies report
[ http://jira.codehaus.org/browse/MPIR-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103039 ] Joel Wiegman commented on MPIR-70: -- I'm using Maven 2.0.7 and the newest maven-project-info-reports-plugin 2.1-20070714.172404-8. I am still seeing the problem. Let me know if there is any more information I can provide. > NullPointerException when generating Dependencies report > > > Key: MPIR-70 > URL: http://jira.codehaus.org/browse/MPIR-70 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Windows, JDK 1.5 >Reporter: Joel Wiegman > Attachments: MPIR-70-minimal.patch, MPIR-70-test-case.zip, > MPIR70-20070716-exec-206.txt, MPIR70-20070716-exec-207.txt > > > The stack trace is attached below. Please note that this is NOT a duplicate > of MPIR-2 (I was told to create a separate issue). Let me know if there's > any other information I can provide. Thanks! > [INFO] Generating "Dependencies" report. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:991) > at java.lang.Double.parseDouble(Double.java:482) > at > org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:375) > at > org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:165) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65) > at > org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:140) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:101) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:266) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:99) > at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:130) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:97) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-745) Uploading pom file does not support projects with modules
[ http://jira.codehaus.org/browse/CONTINUUM-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103040 ] Olivier Lamy commented on CONTINUUM-745: Do not apply this unit failed in core (MavenTwoContinuumProjectBuilderTest). I have tested with the gui but I need to change some asserts because now continuum can download modules when reading a pom :-) . > Uploading pom file does not support projects with modules > - > > Key: CONTINUUM-745 > URL: http://jira.codehaus.org/browse/CONTINUUM-745 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.0.3 > Environment: debian linux / ubuntu linux >Reporter: Andrew Williams >Priority: Critical > Fix For: Future > > Attachments: CONTINUUM-745 > > > Uploaded pom files cannot contain sub modules. > I see in issue CONTINUUM-425 that this is known, but it really should be > possible to fix. > Can we not just read the scm and download _before_ trying to read the child > poms? -- This message is automatically 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-1351) Acnnot checkout sources - perforce.
Acnnot checkout sources - perforce. --- Key: CONTINUUM-1351 URL: http://jira.codehaus.org/browse/CONTINUUM-1351 Project: Continuum Issue Type: Bug Affects Versions: 1.1-beta-1 Environment: Linux Reporter: Duncan McNaught The pom files work in 1.1-alpha-2 but after creating a new 1.1-beta-1 release I get the following build error: Exception: Cannot checkout sources. Index: 0, Size: 0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MAVENUPLOAD-1617) Upload cobertura 1.9 to central
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt reopened MAVENUPLOAD-1617: - Assignee: (was: Henri Yandell) Reopening. Uploaded Artifact is not official 1.9 binary. (origin unknown) http://joakim.erdfelt.com/maven/cobertura-1.9-bundle.jar Bundle at URL above has been verified as correct. Correct bundle has following sha1sum ... c5d057b940a843e484f696b8c4c35e4bbe5e947a cobertura-1.9-bundle.jar Official binary - cobertura-1.9.jar should have the following sha1 and md5 hashcodes ... sha1: fe3dd9ef4bc8ce13a6c69c22f9d92aca1cec33a8 md5: f3d25c4ed63bfc7241407ed211a9b527 > Upload cobertura 1.9 to central > --- > > Key: MAVENUPLOAD-1617 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1617 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Joakim Erdfelt > > Upload cobertura-1.9 to central. > (Look for related cobertura-runtime 1.9 MAVENUPLOAD request 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] Updated: (MNG-3118) Test-classes should come before classes in the classpath
[ http://jira.codehaus.org/browse/MNG-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3118: -- Fix Version/s: 2.0.8 Makes sense. One thing I want to review is how this is used - might be better to externalise this from maven-project into surefire. > Test-classes should come before classes in the classpath > > > Key: MNG-3118 > URL: http://jira.codehaus.org/browse/MNG-3118 > Project: Maven 2 > Issue Type: Improvement > Components: General >Affects Versions: 2.0.7 >Reporter: Paul Gier > Fix For: 2.0.8 > > Attachments: MNG-3118-maven-project-r558713.patch > > > Currently maven-project creates the test classpath in the order: classes, > tests-classes, dependencies. > It would be better if test-classes came first because sometimes it is useful > for a test class to replace a main class during testing. The opposite case > is not normally true (i.e. one would not want to override a test class with > one of the main classes). -- This message is automatically 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: (SUREFIRE-61) Incorrect classpath ordering
[ http://jira.codehaus.org/browse/SUREFIRE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-61: - Fix Version/s: (was: 2.4) 2.3.1 Patch Submitted: [Yes] will review patch for 2.3.1 > Incorrect classpath ordering > > > Key: SUREFIRE-61 > URL: http://jira.codehaus.org/browse/SUREFIRE-61 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 3.x support >Affects Versions: 2.0 (2.2 plugin) > Environment: maven2.0.4, sun-jdk-1.5.0.09, maven-surefire-plugin 2.2, > surefire 2.0, gentoo linux x86 >Reporter: Martin Vysny >Priority: Critical > Fix For: 2.3.1 > > Attachments: my-app.zip, output.log, > SUREFIRE61-surefire-booter-r558713.patch, > SUREFIRE61_barrettas_surefire_surefire-booter_for_rev_489098.patch > > > Surefire incorrectly interprets classpath ordering. > Steps to reproduce: > 1. unzip my-app.zip - it's a simple mvn project created with > mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app > and lightly patched > 2. mvn test > in my case, it prints out > jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties > jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties > which is incorrect. log4j.properties is located both in jxta.jar and > src/test/resources, but I think that src/test/resources takes precedence over > jxta. This ordering is set correctly in surefire36745tmp file I think, but > surefire seems to ignore the ordering. -- This message is automatically 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-2795) Classloader problem loading a resource from a build extension Jar : difference between 2.0.4 and (future) 2.0.5
[ http://jira.codehaus.org/browse/MNG-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103055 ] Tom Guyette commented on MNG-2795: -- It's not clear why this bug was closed. We're seeing this exact issue -- checkstyle failing when a parent pom defines a dependency on a jar that contains the configuration xml file. We see it in Maven 2.0.5 and still in Maven 2.0.7. Works fine in Maven 2.0.4. > Classloader problem loading a resource from a build extension Jar : > difference between 2.0.4 and (future) 2.0.5 > --- > > Key: MNG-2795 > URL: http://jira.codehaus.org/browse/MNG-2795 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.5 >Reporter: Fabrice BELLINGARD >Assignee: Jason van Zyl > Fix For: 2.0.5 > > Attachments: Checkstyle-2.0.4.txt, Checkstyle-2.0.5.txt, > Test-BuildExtension.zip > > > I had a problem when executing the Checkstyle plugin (version 2.1) with the > pre-release of Maven 2.0.5. So I dug a bit to see if this could be related to > maven core or not, and here is what I found. > I isolated the code that breaks the build in the checkstyle plugin: it > happens when the plugin tries to load my Checkstyle configuration file, which > is actually located in a JAR that is specified in the build extensions. The > code lies in the Locator#resolveLocation() method: > // Attempt a Resource. > URL url = this.getClass().getClassLoader().getResource( > location ); > This code returns null for the "url" variable, which in turns breaks the > plugin because it doesn't find any configuration file. > I haven't had the time to dig more into it, but I found the following issue > that might be related to this problem: "MNG-2228 : Classloader problem > loading jars from build extensions". Brett and Carlos worked on it and fixed > it, so maybe they could tell more about it. > I attached the logs of the execution with Maven 2.0.4 (which works fine) and > Maven 2.0.5 (which breaks). I haven't had the time yet to dig further into > that problem. -- This message is automatically 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: (MRM-326) Adding/Editing repositories doesn't have validation
[ http://jira.codehaus.org/browse/MRM-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-326. Resolution: Fixed Applied patch in trunk, -r558904. Thanks! :) > Adding/Editing repositories doesn't have validation > --- > > Key: MRM-326 > URL: http://jira.codehaus.org/browse/MRM-326 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-alpha-1 >Reporter: Napoleon Esmundo C. Ramirez >Assignee: Maria Odea Ching > Fix For: 1.0.x > > Attachments: MRM-326-archiva-webapp.patch > > > To replicate: > A. Adding a repository > 1. Click the Repositories link in the left navigation menu > 2. Click the Add Repository link in the upper right part of the page > 3. Enter invalid values in Identifier, Name, Directory or URL, empty Strings > 4. Click the Add Repository button > Result: Repositories Administration page is displayed, no repository is added > Expected Result: Validation errors > B. Editing a repository > 1. Click the Repositories link in the left navigation menu > 2. Click the Edit Repository link in the same row as the repository's header > 3. Enter invalid values in Name, Directory or URL, empty Strings and using > default values for Type and Cron > 4. Click the Update Repository button > Result: Repositories Administration page displayed, repository is updated > Expected Result: Validation errors -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MRM-294) Repository purge feature for snapshots
[ http://jira.codehaus.org/browse/MRM-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-294 started by Maria Odea Ching. > Repository purge feature for snapshots > -- > > Key: MRM-294 > URL: http://jira.codehaus.org/browse/MRM-294 > Project: Archiva > Issue Type: New Feature >Affects Versions: 1.0-alpha-1 >Reporter: Wendy Smoak >Assignee: Maria Odea Ching > Fix For: 1.0.x > > > We need a way to purge a repository of snapshots older than a certain date, > (optionally retaining the most recent one) and fixing the metadata. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-213) Need ability to access values gathered by maven-release-plugin in Mojos executed as part of preparationGoals element
[ http://jira.codehaus.org/browse/MRELEASE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Ferguson closed MRELEASE-213. - Resolution: Won't Fix I got around this issue by retrieving the information from Subversion directly. But this has meant that the plugin which does so needs to be executed as a precise point in the release which is NOT the prepareGoals phase - which makes http://jira.codehaus.org/browse/MRELEASE-213 all the more important. > Need ability to access values gathered by maven-release-plugin in Mojos > executed as part of preparationGoals element > > > Key: MRELEASE-213 > URL: http://jira.codehaus.org/browse/MRELEASE-213 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-4 >Reporter: William Ferguson > > I have a plugin containing a Mojo that needs to be executed as part of the > maven-release-plugin's preparationGoals phase. > The Mojo needs access to some of the information gathered by the > maven-release-plugin. > Namely it needs access to the SCM release tag specified by the user. > The aim of the plugin is to update the subclipse:tags property of the project > being released in a similar manner that the Eclipse/Subversion Subclipse > plugin does. So the information that I need to gather from the > maven-release-plugin is > 1) SCM release tag specified by the user. > 2) Any other SCM details that have been modified for the release plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-212) Mojo executed using preparationGoals does not get its parameters populated on execution
[
http://jira.codehaus.org/browse/MRELEASE-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Ferguson closed MRELEASE-212.
-
Resolution: Won't Fix
I got around this issue by retrieving the information from Subversion directly.
But this has meant that the plugin which does so needs to be executed as a
precise point in the release which is NOT the
prepareGoals phase - which makes http://jira.codehaus.org/browse/MRELEASE-213
all the more important.
> Mojo executed using preparationGoals does not get its parameters populated on
> execution
> ---
>
> Key: MRELEASE-212
> URL: http://jira.codehaus.org/browse/MRELEASE-212
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-4
>Reporter: William Ferguson
>
> I have a Mojo with a single String parameter
> /**
>* @parameter expression="${myProp}"
>*/
> private String myProp;
> If this Mojo is executed directly, eg
> mvn myplugin:mygoal -DmyProp=foo
> then the Mojo receives the value of myProp at runtime.
> If my Mojo is executed via maven-release-plugin preparationGoals eg
>
> org.apache.maven.plugins
> maven-release-plugin
>
>
> clean integration-test
> myplugin:mygoal
>
>
>
> the the Mojo is not injected with the value of MyProp at runtime.
> Now this could just be because there is some extra config that I need to do
> that I have missed. I am a Maven newbie.
> But I've followed all the doco for maven-release-plugin as well as anything I
> could find on building plugins.
> So if its my bad, please point me in the right direction.
--
This message is automatically 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-977) Create web UI tests for "Add m1 & m2 projects" pages
[ http://jira.codehaus.org/browse/CONTINUUM-977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103061 ] Maria Odea Ching commented on CONTINUUM-977: I've checked the svn logs again, but I seem to not have committed the second patch. I must've just applied it in my local copy of continuum-webapp-test but not commit it, I'm so sorry I thought I committed it on trunk.. Anyway, I'll apply the patch again. > Create web UI tests for "Add m1 & m2 projects" pages > > > Key: CONTINUUM-977 > URL: http://jira.codehaus.org/browse/CONTINUUM-977 > Project: Continuum > Issue Type: Task > Components: Testing >Affects Versions: 1.1-alpha-1 >Reporter: Maria Odea Ching >Assignee: Maria Odea Ching > Fix For: 1.1-beta-2 > > Attachments: CONTINUUM-977-continuum-webapp-test.patch, > continuum-webapp-test-4.patch > > -- This message is automatically 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: (MRELEASE-270) release:prepare doesn't fail when the project it is building fails to compile
[ http://jira.codehaus.org/browse/MRELEASE-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103062 ] William Ferguson commented on MRELEASE-270: --- NB the attached zip contains a project with uncompilable source. > release:prepare doesn't fail when the project it is building fails to compile > - > > Key: MRELEASE-270 > URL: http://jira.codehaus.org/browse/MRELEASE-270 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: William Ferguson > Attachments: MRELEASE-XXX.zip > > > Unusual situation on our build server, where one of the dependent libraries > had been corrupted in its local repository. > 'mvn compile' would fail with compilation errors - it couldn't find the > classes from the corrupt jar. > 'mvn release:prepare' would note compilation errors and indicate build > failure, but would continue on with the release, modify the POMs, tag the > source and finally complete indicating success. > I noted that the same thing can happen if uncompilable source is checked in, > though at least then you would get the compilation failure on your local > machine too. > I think release:prepare should clearly fail (it wasn't clear in this instance > unless you scrolled back through the build output) if any part of the > release:prepare fails. > To replicate either > a) Attempt top release uncompilable code. > b) Replace a dependent jar with a renamed text file and attempt to release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-270) release:prepare doesn't fail when the project it is building fails to compile
release:prepare doesn't fail when the project it is building fails to compile - Key: MRELEASE-270 URL: http://jira.codehaus.org/browse/MRELEASE-270 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Reporter: William Ferguson Attachments: MRELEASE-XXX.zip Unusual situation on our build server, where one of the dependent libraries had been corrupted in its local repository. 'mvn compile' would fail with compilation errors - it couldn't find the classes from the corrupt jar. 'mvn release:prepare' would note compilation errors and indicate build failure, but would continue on with the release, modify the POMs, tag the source and finally complete indicating success. I noted that the same thing can happen if uncompilable source is checked in, though at least then you would get the compilation failure on your local machine too. I think release:prepare should clearly fail (it wasn't clear in this instance unless you scrolled back through the build output) if any part of the release:prepare fails. To replicate either a) Attempt top release uncompilable code. b) Replace a dependent jar with a renamed text file and attempt to release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MIDEA-101) mvn idea:idea ignores the custom webResources configuration from war-plugin
mvn idea:idea ignores the custom webResources configuration from war-plugin
---
Key: MIDEA-101
URL: http://jira.codehaus.org/browse/MIDEA-101
Project: Maven 2.x IDEA Plugin
Issue Type: Bug
Reporter: Fabio Kung
The plugin must generate the web module resources from custom war-plugin
webResources:
org.apache.maven.plugins
maven-war-plugin
${basedir}/resources
The generated web module should have two web resources: resources/ and
src/main/webapp/
--
This message is automatically 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
