[jira] Commented: (MJAVADOC-101) Embedded error: Error rendering Maven report
[ http://jira.codehaus.org/browse/MJAVADOC-101?page=comments#action_81701 ] Samuel Langlois commented on MJAVADOC-101: -- I have the same error with maven-javadoc-plugin version 2.1 I attach the result of mvn javadoc:javadoc -X Is there any workaround? Thanks Embedded error: Error rendering Maven report Key: MJAVADOC-101 URL: http://jira.codehaus.org/browse/MJAVADOC-101 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Environment: XP java version 1.4.2_10 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_10-b03) Java HotSpot(TM) Client VM (build 1.4.2_10-b03, mixed mode) Reporter: Bose Daggubati Attachments: javadoc-2.1.log, Maven Site issue.txt, pom.xml, pom.xml 2 errors 1 warning [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error during page generation Embedded error: Error rendering Maven report: Exit code: 1 - C:/ExpressContact/StandAlone/RandomizationEngine/src/main/java/com/express_scripts/imms/randeng/domain/Client.java:21: warning: as of release 1.4, assert is a keyword, and may not be used as an identifier assert (planTypeId == null) || (bplId == null) : A Client (from a Randomization Standpoint) should not have both a PLAN TYPE ID and BPL ID; ^ C:/ExpressContact/StandAlone/RandomizationEngine/src/main/java/com/express_scripts/imms/randeng/domain/Client.java:21: not a statement assert (planTypeId == null) || (bplId == null) : A Client (from a Randomization Standpoint) should not have both a PLAN TYPE ID and BPL ID; ^ C:/ExpressContact/StandAlone/RandomizationEngine/src/main/java/com/express_scripts/imms/randeng/domain/Client.java:21: ';' expected assert (planTypeId == null) || (bplId == null) : A Client (from a Randomization Standpoint) should not have both a PLAN TYPE ID and BPL ID; ^ [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error during page generation at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error during page generation at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:97) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error rendering Maven report: Exit code: 1 - C:/ExpressContact/StandAlone/RandomizationEngine/src/main/java/com/express_scripts/imms/randeng/domain/C lient.java:21: warning: as of release 1.4, assert is a keyword, and may not be used as an identifier assert (planTypeId == null) || (bplId == null) : A Client (from a Randomization Standpoint) should not have both a PLAN TYPE ID and BPL ID; ^ C:/ExpressContact/StandAlone/RandomizationEngine/src/main/java/com/express_scripts/imms/randeng/domain/Client.java:21: not a statement assert
[jira] Updated: (MJAVADOC-101) Embedded error: Error rendering Maven report
[ http://jira.codehaus.org/browse/MJAVADOC-101?page=all ] Samuel Langlois updated MJAVADOC-101: - Attachment: javadoc-2.1.log Embedded error: Error rendering Maven report Key: MJAVADOC-101 URL: http://jira.codehaus.org/browse/MJAVADOC-101 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Environment: XP java version 1.4.2_10 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_10-b03) Java HotSpot(TM) Client VM (build 1.4.2_10-b03, mixed mode) Reporter: Bose Daggubati Attachments: javadoc-2.1.log, Maven Site issue.txt, pom.xml, pom.xml 2 errors 1 warning [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error during page generation Embedded error: Error rendering Maven report: Exit code: 1 - C:/ExpressContact/StandAlone/RandomizationEngine/src/main/java/com/express_scripts/imms/randeng/domain/Client.java:21: warning: as of release 1.4, assert is a keyword, and may not be used as an identifier assert (planTypeId == null) || (bplId == null) : A Client (from a Randomization Standpoint) should not have both a PLAN TYPE ID and BPL ID; ^ C:/ExpressContact/StandAlone/RandomizationEngine/src/main/java/com/express_scripts/imms/randeng/domain/Client.java:21: not a statement assert (planTypeId == null) || (bplId == null) : A Client (from a Randomization Standpoint) should not have both a PLAN TYPE ID and BPL ID; ^ C:/ExpressContact/StandAlone/RandomizationEngine/src/main/java/com/express_scripts/imms/randeng/domain/Client.java:21: ';' expected assert (planTypeId == null) || (bplId == null) : A Client (from a Randomization Standpoint) should not have both a PLAN TYPE ID and BPL ID; ^ [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error during page generation at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error during page generation at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:97) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error rendering Maven report: Exit code: 1 - C:/ExpressContact/StandAlone/RandomizationEngine/src/main/java/com/express_scripts/imms/randeng/domain/C lient.java:21: warning: as of release 1.4, assert is a keyword, and may not be used as an identifier assert (planTypeId == null) || (bplId == null) : A Client (from a Randomization Standpoint) should not have both a PLAN TYPE ID and BPL ID; ^ C:/ExpressContact/StandAlone/RandomizationEngine/src/main/java/com/express_scripts/imms/randeng/domain/Client.java:21: not a statement assert (planTypeId == null) || (bplId == null) : A Client (from a Randomization Standpoint) should not have both a PLAN TYPE ID and BPL ID;
[jira] Created: (CONTINUUM-1025) Project Group Actions sometimes cannot be found in the Projects Group Page
Project Group Actions sometimes cannot be found in the Projects Group Page -- Key: CONTINUUM-1025 URL: http://jira.codehaus.org/browse/CONTINUUM-1025 Project: Continuum Issue Type: Bug Components: Web - UI Reporter: Franz Allan Valencia See A workaround is to add a project first to the project group and the project group actions will appear (note: even after removing the project from the project groups, the project group actions will remain. furthermore, even if you remove that project group, and add another with the same name, the project group actions for that would still be visible). -- 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-2097) adding a phase called prepare-package
[ http://jira.codehaus.org/browse/MNG-2097?page=comments#action_81704 ] Mark Hobson commented on MNG-2097: -- Couple more related threads needing this new phase: http://www.mail-archive.com/dev@maven.apache.org/msg62286.html http://www.mail-archive.com/dev@maven.apache.org/msg62255.html adding a phase called prepare-package - Key: MNG-2097 URL: http://jira.codehaus.org/browse/MNG-2097 Project: Maven 2 Issue Type: New Feature Components: Plugins and Lifecycle Affects Versions: 2.0.2 Environment: all Reporter: Olivier Lamy Fix For: 2.1 Attachments: MNG-2097.diff Hi, I have an artifact (packaging war). I have some jobs to do (xdoclet-maven-plugin others internal plugin) which are only needed for included materials in the war : - web.xml - automatic generated pages (about page etc..) Actually I attached it tho the phase process-classes or test. But when I just want to try a simple the simple : mvn -Dtest=something clean test. All of my .java are parsed by the plugin and all other jobs made whereas this should be done in a phase just before packaging. I really need a phase just before package to place all this jobs. Probably this can be extends to phase deploy. Olivier -- 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-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=comments#action_81706 ] Martin Gilday commented on SUREFIRE-31: --- Is anything official being worked on for this at the moment? It seems to be blocking many people from migrating to JUnit 4. I too am considering using TestNG now instead. support junit 4.0 - Key: SUREFIRE-31 URL: http://jira.codehaus.org/browse/SUREFIRE-31 Project: surefire Issue Type: Improvement Components: Junit 4.x support Reporter: John Didion Fix For: 2.1 Attachments: SUREFIRE-31-maven-surefire-plugin.patch, SUREFIRE-31-surefire-trunk.patch, surefire-junit4.zip, SUREFIRE31_karl_maven-surefire-plugin.patch, SUREFIRE31_karl_surefire_surefire-providers_surefire-junit.patch, SUREFIRE31_karl_surefire_surefire-providers_surefire-junit_2ndMethod.patch I know this is a pretty sizable task. I just wanted to get it in the system now that 4.0 has officially been released. Hopefully this will generate some discussion about how 4.0 will be handled - mainly if it will require a completely seperate implemenation of surefire (keeping the same API so it can easily be used by the maven plugin), or if use of 4.0 will be made a configurable option of the current surefire. Here's some additional features I'd like to see: 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an @Category annotation, or make category a parameter of @Test. However, the filtering mechanism provided by 4.0 is sufficent to support categories given the presense of such an annotation. I recommend putting the @Category annotation in a seperate module (surefire-annotations?) and build support for it into surefire. Hopefully the junit guys could be convinced to incorporate it in a later version. 2. Similarly, support repeated tests via an @Repeated annotation. I'm not sure how easy this would be to do external to junit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-245) scm:edit doesn't work with perforce as it refers the file without depot path
[ http://jira.codehaus.org/browse/SCM-245?page=comments#action_81710 ] Bugittaa Pahasti commented on SCM-245: -- Clientspec is set correctly, but actually the problem seems to be cygwin related. Everything works fine when run from WinXP command prompt with both p4 or maven-scm, but it fails in both cases when run under cygwin. So there are two issues: - scm:edit doesn't work with cygwin - scm:edit consumes errors, and reports Build successful even the command failed. Not sure if this applies to other commands too. scm:edit doesn't work with perforce as it refers the file without depot path Key: SCM-245 URL: http://jira.codehaus.org/browse/SCM-245 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-perforce Affects Versions: 1.0-beta-3 Environment: WinXP with Cygwin, Perforce 2006.1 Reporter: Bugittaa Pahasti Both of the commands fail to actually checkout the file for edit: mvn scm:edit -Dincludes=pom.xml [DEBUG] Executing p4 edit pom.xml mvn scm:edit -Dincludes=//depot/main/java/pom.xml [DEBUG] Executing p4 edit The error is consumed and there's no indication of any error, even the command fails. The command that would work would be p4 edit //depot/main/java/pom.xml. I suspect at least the former command is supposed to work, but the provider fails to add the depot path to it. If the command the plugin tries to use in run on the command line, it fails: $ p4 edit pom.xml Path 'xyz/main/java\pom.xml' is not under client's root '/rootpath'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-245) scm:edit doesn't work with perforce as it refers the file without depot path
[ http://jira.codehaus.org/browse/SCM-245?page=comments#action_81715 ] Bugittaa Pahasti commented on SCM-245: -- The latter one seems to be already reported: http://jira.codehaus.org/browse/SCM-246 Could the first one be related to this: http://jira.codehaus.org/browse/SCM-209 scm:edit doesn't work with perforce as it refers the file without depot path Key: SCM-245 URL: http://jira.codehaus.org/browse/SCM-245 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-perforce Affects Versions: 1.0-beta-3 Environment: WinXP with Cygwin, Perforce 2006.1 Reporter: Bugittaa Pahasti Both of the commands fail to actually checkout the file for edit: mvn scm:edit -Dincludes=pom.xml [DEBUG] Executing p4 edit pom.xml mvn scm:edit -Dincludes=//depot/main/java/pom.xml [DEBUG] Executing p4 edit The error is consumed and there's no indication of any error, even the command fails. The command that would work would be p4 edit //depot/main/java/pom.xml. I suspect at least the former command is supposed to work, but the provider fails to add the depot path to it. If the command the plugin tries to use in run on the command line, it fails: $ p4 edit pom.xml Path 'xyz/main/java\pom.xml' is not under client's root '/rootpath'. -- 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: (MRM-244) Mirror/Proxy functionality is broken in Archiva
Mirror/Proxy functionality is broken in Archiva --- Key: MRM-244 URL: http://jira.codehaus.org/browse/MRM-244 Project: Archiva Issue Type: Bug Components: remote proxy Reporter: Aaron Digulla Priority: Critical Currently, the archiva admin has to specify which sites Archiva should proxy/mirror and in which managed repository the downloaded artefacts should end up. This approach has several drawbacks: - Resources with a similar name but from different sites can end up in the same managed repository. This is deadly if there is a bug in the resource which is fixed on site A but archiva downloads it from B. Since the resource exists, Archiva will not download it again even after the problem is fixed and the maven mirrors re-synchronized. - Since every POM can define their own repositories, it's very hard to maintain the list of proxied repositories. The situation gets worse when you download a new plugin which in turn wants artefacts from other sites which are not yet in the list. Maven will not use Archiva for these which means every developer downloads those resources. This also means I have to configure maven to be able to access the internet directly while I would prefer to be able to force it to make all connections via archiva. This way, I can fix all broken POMs inhouse, for example. - In maven's settings, I have to specify which mirrors exist. The key for the decision is the ID of the repository. Unfortunately, the ID is just an arbitrary string. Many projects use different IDs for the same repository. Some use codehaus.org, some use codehaus. I've seen POMs which think codehaus.org is for snapshots while they use codehaus for the releases. In the end, there is no way to map repository IDs to mirrors which will work for all maven projects out there. Therefore, I suggest that you change the handling of proxied repositories. Instead of using mirror settings, I would prefer to use the proxy settings of maven to integrate Archiva. Archiva should keep a blacklist of repositories which are to be ignored but everything else should be downloaded into a mirror directory which contains the hostnames of the sites as first level. This means artefacts from http://people.apache.org/maven-snapshot-repository/; would end up in C:\archiva\mirror\people.apache.org\maven-snapshot-repository\... If the port number is != 80, you can add another level for the port. This should allow us to force maven to download everything through Archiva. We would be able to control which plugins and which versions are used and we could fix broken POMs. We could even put patched versions of plugins into the mirror directory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-259) Running scm:changelog after scm:update should be made configurable
Running scm:changelog after scm:update should be made configurable -- Key: SCM-259 URL: http://jira.codehaus.org/browse/SCM-259 Project: Maven SCM Issue Type: New Feature Components: maven-scm-api Reporter: Jan Hoeve Priority: Minor I do have a environment with cruisecontrol as a buildserver and clearcase as SCM provider. One entire build loop takes half an hour to complete. This is because the scm:update command fires an changelog command to get the changed files. This changelog process takes about 20 minutes to complete. My clearcase view has some 8500 files in it. (note: changelog is fired without the startDate, bad for performance on clearcase). It would be very nice if there was an option i could pass to mvn scm:update which skips the changelog process. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1020) Insert the project group summary tab into the normal project view to allow easy navigation back to project group level
[ http://jira.codehaus.org/browse/CONTINUUM-1020?page=all ] Emmanuel Venisse closed CONTINUUM-1020. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.1 Done. Insert the project group summary tab into the normal project view to allow easy navigation back to project group level Key: CONTINUUM-1020 URL: http://jira.codehaus.org/browse/CONTINUUM-1020 Project: Continuum Issue Type: Improvement Components: Web - UI Affects Versions: 1.1 Reporter: Christian Gruber Assigned To: Emmanuel Venisse Priority: Minor Fix For: 1.1 As a simple bread-crumb for easy navigation, can we insert the project group summary tab into the normal project view, so that you get ... -- |Project Group Summary|Project Information|Builds|Working Copy| ...as the tabs, leaving it easy to return to the project group level? -- 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-2686) POM dependency scope auto-downgrades from provided to test
POM dependency scope auto-downgrades from provided to test -- Key: MNG-2686 URL: http://jira.codehaus.org/browse/MNG-2686 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Reporter: Frank Cornelis Priority: Critical My project has a dependency on: XXX:YYY:jar:1.0-SNAPSHOT (selected for null) with transitive dependency: commons-logging:commons-logging:jar:1.1:test and again triggering a transitive dependency on: javax.servlet:servlet-api:jar:2.3:test (selected for test) Later on the project also has a dependency: AAA:BBB-container:pom:1.0-SNAPSHOT:provided (selected for provided) I use this to represent the dependencies provided by the J2EE container in which the application will be deployed. This triggers via: tomcat:catalina:jar:5.5.15:provided (selected for provided) the following funny thing: javax.servlet:servlet-api:jar:2.4:provided (removed - nearer found: 2.3) Leaving me without servlet-api for the compile scope. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-443) Several projects have maven-metadata.xml files that are missing released versions
[ http://jira.codehaus.org/browse/MEV-443?page=comments#action_81727 ] Nathan Beyer (Cerner) commented on MEV-443: --- What's a pragmatic time frame for Archiva being used by the central repo and having these issues resolved? The last comment on this issue was 3 months ago. Is it still practical to postpone these metadata fixes? What can the community do to help? If we posted updated metadata files, could these be uploaded? What can we do to push Archiva over the line? Several projects have maven-metadata.xml files that are missing released versions - Key: MEV-443 URL: http://jira.codehaus.org/browse/MEV-443 Project: Maven Evangelism Issue Type: Bug Reporter: Patrick Moore Attachments: maven-metadata.xml I am trying to use the version range feature that is talked about in Better builds with Maven. I am specifying the commons-httpclient dependency as dependency groupIdcommons-httpclient/groupId artifactIdcommons-httpclient/artifactId version[3.1-alpha1,)/version /dependency Unfortunately, the usefulness of this feature is being sabotaged because the latest version of artificat is not listed in the maven-metadata.xml. Please update the maven-metadata.xml in this project and others. In particular hsqldb, commons-*, rhino/js htmlunit When updating those files, please do not list the versions using dates as their version id as it screws up the maven feature that allows dependencies to specify a version range. -- 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-189) Coordinate the efforts of several users to write a Dashboard Plugin for Maven 2
[ http://jira.codehaus.org/browse/MSITE-189?page=comments#action_81728 ] David vicente commented on MSITE-189: - I have submited my dashboard plugin http://jira.codehaus.org/browse/MOJO-575 I hope you enjoy it Coordinate the efforts of several users to write a Dashboard Plugin for Maven 2 --- Key: MSITE-189 URL: http://jira.codehaus.org/browse/MSITE-189 Project: Maven 2.x Site Plugin Issue Type: Task Reporter: Gisbert Amm Attachments: dashboard.zip, screenshot-1.jpg Coordinate the efforts of several users to write a Dashboard Plugin for Maven 2 Several people started their own Dashboard plugins (see http://jira.codehaus.org/browse/MSITE-188 and discussions on the users mailing list). It would be better, if one of those implementations would be adopted by the Maven team and the various development efforts would be coordinated and focused to that one. -- 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-1026) Remove the work-around for the Project Group Actions
Remove the work-around for the Project Group Actions Key: CONTINUUM-1026 URL: http://jira.codehaus.org/browse/CONTINUUM-1026 Project: Continuum Issue Type: Bug Components: Web - UI Reporter: Franz Allan Valencia See Attachments: CONTINUUM-1026-continuum-webapp-test.patch The workaround in CONTINUUM-1025 was introduced when the Project Group Actions feature was implemented. it should be removed. -- 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-1027) Create tearDown for the continuum-webapp-test
Create tearDown for the continuum-webapp-test - Key: CONTINUUM-1027 URL: http://jira.codehaus.org/browse/CONTINUUM-1027 Project: Continuum Issue Type: Improvement Components: Web - UI Reporter: Franz Allan Valencia See Some of the tests do not clean themselves. Also, some tests may require identical tearDown()'s ( or at least, part of it ). It would be nice if things are reverted back to the default every after tests, and that this be done in AbstractContinuumTestCase ( to prevent tearDown() duplication ). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1026) Remove the work-around for the Project Group Actions
[ http://jira.codehaus.org/browse/CONTINUUM-1026?page=all ] Emmanuel Venisse closed CONTINUUM-1026. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.1 Applied. Thanks. Remove the work-around for the Project Group Actions Key: CONTINUUM-1026 URL: http://jira.codehaus.org/browse/CONTINUUM-1026 Project: Continuum Issue Type: Bug Components: Web - UI Reporter: Franz Allan Valencia See Assigned To: Emmanuel Venisse Fix For: 1.1 Attachments: CONTINUUM-1026-continuum-webapp-test.patch The workaround in CONTINUUM-1025 was introduced when the Project Group Actions feature was implemented. it should be removed. -- 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-1262) Add sources to commons-validator 1.3.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1262?page=all ] Tomislav Stojcevich updated MAVENUPLOAD-1262: - Attachment: commons-validator-1.3.1-bundle.jar Add sources to commons-validator 1.3.1 -- Key: MAVENUPLOAD-1262 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1262 Project: maven-upload-requests Issue Type: Bug Reporter: Tomislav Stojcevich Attachments: commons-validator-1.3.1-bundle.jar Add sources only. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1262) Add sources to commons-validator 1.3.1
Add sources to commons-validator 1.3.1 -- Key: MAVENUPLOAD-1262 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1262 Project: maven-upload-requests Issue Type: Bug Reporter: Tomislav Stojcevich Attachments: commons-validator-1.3.1-bundle.jar Add sources only. -- 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-2545) [maven-plugin-testing-harness-1.0-beta-1] AbstractMojoTestCase.extractPluginConfiguration expects plugin configuration directly under plugin (configuration under execution
[ http://jira.codehaus.org/browse/MNG-2545?page=comments#action_81733 ]
iosif commented on MNG-2545:
AbstractMojoTestCase seems to look up mojos/plugins listed in the build
section only. Mojo lookup does not check the configuration section in
reporting.
[maven-plugin-testing-harness-1.0-beta-1]
AbstractMojoTestCase.extractPluginConfiguration expects plugin configuration
directly under plugin (configuration under executions/execution doesn't work)
Key: MNG-2545
URL: http://jira.codehaus.org/browse/MNG-2545
Project: Maven 2
Issue Type: Bug
Components: Plugin Creation Tools
Affects Versions: 2.0.4
Environment: Maven 2.0.4
maven-plugin-testing-harness-1.0-beta-1
Reporter: Jimisola Laursen
Priority: Minor
AbstractMojoTestCase.extractPluginConfiguration expects plugin configuration
directly under plugin. configuration section under executions/execution
doesn't work.
Exception is thrown on line 209 since pluginConfigurationElement == null
which is due to
pluginConfigurationElement = pluginElement.getChild( configuration )
A fix should check for configuration section under plugin/configuration and
then plugin/executions/execution/configuration.
AbstractMojoTestCase.extractPluginConfiguration:201
for ( int i = 0; i pluginElements.length; i++ )
{
Xpp3Dom pluginElement = pluginElements[i];
String pluginElementArtifactId = pluginElement.getChild(
artifactId ).getValue();
if ( pluginElementArtifactId.equals( artifactId ) )
{
pluginConfigurationElement = pluginElement.getChild(
configuration );
break;
}
}
if ( pluginConfigurationElement == null )
{
throw new ConfigurationException( Cannot find a configuration
element for a plugin with an artifactId of + artifactId + . );
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MIDEA-71) Sources are not consistently attached to dependencies
[ http://jira.codehaus.org/browse/MIDEA-71?page=all ] Jan Thomae closed MIDEA-71. --- Resolution: Cannot Reproduce Weird,i have updated the plugin from the Snapshot Repo, this seems to work now. Cannot reproduce this anymore, so this can be closed. Sources are not consistently attached to dependencies - Key: MIDEA-71 URL: http://jira.codehaus.org/browse/MIDEA-71 Project: Maven 2.x Idea Plugin Issue Type: Bug Reporter: Jan Thomae Attachments: admin-pom.xml, module1.jpg, module2.jpg, root-pom.xml, server-pom.xml I have a multimodule project, where all submodules depend on commons-logging (and other modules). When i run idea:idea with downloadSources enabled, the sources for commons logging are correctly downloaded, and commons logging is added to the dependency list of all modules. However, the sources are only added to some of the modules, not all of them. I wasnt able yet, to find out some reason for this. I have attached two shots of one module with attached source and one without, plus the root pom and the module 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] Updated: (MIDEA-71) Sources are not consistently attached to dependencies
[ http://jira.codehaus.org/browse/MIDEA-71?page=all ] Dennis Lundberg updated MIDEA-71: - Fix Version/s: 2.1 Sources are not consistently attached to dependencies - Key: MIDEA-71 URL: http://jira.codehaus.org/browse/MIDEA-71 Project: Maven 2.x Idea Plugin Issue Type: Bug Reporter: Jan Thomae Fix For: 2.1 Attachments: admin-pom.xml, module1.jpg, module2.jpg, root-pom.xml, server-pom.xml I have a multimodule project, where all submodules depend on commons-logging (and other modules). When i run idea:idea with downloadSources enabled, the sources for commons logging are correctly downloaded, and commons logging is added to the dependency list of all modules. However, the sources are only added to some of the modules, not all of them. I wasnt able yet, to find out some reason for this. I have attached two shots of one module with attached source and one without, plus the root pom and the module 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] Commented: (MNG-2646) [PATCH] MavenProjectBuilder.buildFromRepository(...) does not support profiles
[ http://jira.codehaus.org/browse/MNG-2646?page=comments#action_81737 ] Carlos Sanchez commented on MNG-2646: - Comment about the patch, you're changing signature of public methods which is not acceptable, we have to maintain backwards compatibility. Deprecate and add new methods. [PATCH] MavenProjectBuilder.buildFromRepository(...) does not support profiles -- Key: MNG-2646 URL: http://jira.codehaus.org/browse/MNG-2646 Project: Maven 2 Issue Type: Bug Components: Profiles Affects Versions: 2.0.4 Reporter: Christian Schulte Fix For: 2.0.5 Attachments: profile.patch Currently profiles are not injected into models retrieved from a repository. The attached patch was written against /tags/maven-2.0.4 and should apply cleanly. It adds a ProfileManager parameter to the corresponding MavenProjectBuilder.buildFromRepository(...) methods so that profiles are also injected into models build from a repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MIDEA-79) Sources for SNAPSHOT-dependencies are not downloaded correctly.
Sources for SNAPSHOT-dependencies are not downloaded correctly. --- Key: MIDEA-79 URL: http://jira.codehaus.org/browse/MIDEA-79 Project: Maven 2.x Idea Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Jan Thomae When downloading sources for SNAPSHOT dependencies, the plugin uses the wrong path. Instead of downloading http://repository.insomnia-hq.de/de/insomniahq/icc/1.0-SNAPSHOT/icc-1.0-20061202.231038-59-sources.jar it tries to download http://repository.insomnia-hq.de/de/insomniahq/icc/icc-1.0-20061202.231038-59/icc-1.0-20061202.231038-59-sources.jar Also sometimes it tries to download http://repository.insomnia-hq.de/de/insomniahq/icc/1.0-SNAPSHOT/icc-1.0-SNAPSHOT-sources.jar instead of replacing the SNAPSHOT with the actual snapshot 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] Closed: (MAVENUPLOAD-1263) Add sources to commons-dbutils-1.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1263?page=all ] Carlos Sanchez closed MAVENUPLOAD-1263. --- Assignee: Carlos Sanchez Resolution: Won't Fix We sync from apache, so you have to ask them directly to put it in the apache repo Add sources to commons-dbutils-1.1 -- Key: MAVENUPLOAD-1263 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1263 Project: maven-upload-requests Issue Type: Bug Reporter: Tomislav Stojcevich Assigned To: Carlos Sanchez Attachments: commons-dbutils-1.1-bundle.jar Add sources only from bundle -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MEV-469) jaxb-api available with two different groupIds
[ http://jira.codehaus.org/browse/MEV-469?page=all ] fabrizio giustina updated MEV-469: -- Attachment: javax.xml.zip jaxb-api dirs were pretty a mess, the attached archive contains the cleaned up javax.xml.jaxb-api and javax.xml.bind.jaxb-api dirs. javax.xml:jaxb-api has been relocated and versions missing in javax.xml.bind:jaxb-api have been added. New poms in javax.xml.bind have dependencies (that were missing from the ones in javax.xml). md5 and sha1 files are included. Hope this is ok: I don't know how to help without providing a zip, there were several poms that needed relocation and a few jars that had to be moved between folders. jaxb-api available with two different groupIds -- Key: MEV-469 URL: http://jira.codehaus.org/browse/MEV-469 Project: Maven Evangelism Issue Type: Bug Reporter: fabrizio giustina Assigned To: fabrizio giustina Attachments: javax.xml.zip jaxb has been uploaded twice with different groupIds: javax.xml and javax.xml.bind. See for example: http://repo1.maven.org/maven2/javax/xml/jaxb-api/2.0/ http://repo1.maven.org/maven2/javax/xml/bind/jaxb-api/2.0/ one of those should be removed and replaced with a relocation. The dev.java.net repository actually list these jars with the javax.xml.bind groupId so probably that should be the right one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVEN-1820) Maven 1.0.2 installlation
[ http://jira.codehaus.org/browse/MAVEN-1820?page=comments#action_81755 ] Carlos Sanchez commented on MAVEN-1820: --- use the user mailing list for questions http://maven.apache.org/mail-lists.html Maven 1.0.2 installlation - Key: MAVEN-1820 URL: http://jira.codehaus.org/browse/MAVEN-1820 Project: Maven 1.x Issue Type: Bug Environment: SUSE Linux 10 Reporter: Elly Yeung Assigned To: Carlos Sanchez After installed maven and have encountered the following MavenException. #maven -e __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 org.apache.maven.MavenException: Parent POM is equal to the current POM at org.apache.maven.MavenUtils.getNonJellyProject(MavenUtils.java:236) at org.apache.maven.MavenUtils.getProject(MavenUtils.java:143) at org.apache.maven.MavenUtils.getProject(MavenUtils.java:122) at org.apache.maven.MavenSession.initializeRootProject(MavenSession.java:232) at org.apache.maven.MavenSession.initialize(MavenSession.java:172) at org.apache.maven.cli.App.doMain(App.java:475) at org.apache.maven.cli.App.main(App.java:1239) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Any helps would be appreciated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-469) jaxb-api available with two different groupIds
[ http://jira.codehaus.org/browse/MEV-469?page=comments#action_81762 ] Carlos Sanchez commented on MEV-469: i did the easiest changes. Some of the other ones can't be done I think, because they are in the two places with different dependencies that could break the build if changes (unless the dependencies checksums match) jaxb-api available with two different groupIds -- Key: MEV-469 URL: http://jira.codehaus.org/browse/MEV-469 Project: Maven Evangelism Issue Type: Bug Reporter: fabrizio giustina Assigned To: Carlos Sanchez Attachments: javax.xml.zip jaxb has been uploaded twice with different groupIds: javax.xml and javax.xml.bind. See for example: http://repo1.maven.org/maven2/javax/xml/jaxb-api/2.0/ http://repo1.maven.org/maven2/javax/xml/bind/jaxb-api/2.0/ one of those should be removed and replaced with a relocation. The dev.java.net repository actually list these jars with the javax.xml.bind groupId so probably that should be the right one. -- 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-2661) add an achetype index, and add the webtide webapp archetypes
[ http://jira.codehaus.org/browse/MNG-2661?page=comments#action_81767 ] Wendy Smoak commented on MNG-2661: -- See http://docs.codehaus.org/display/MAVENUSER/Archetypes+List add an achetype index, and add the webtide webapp archetypes Key: MNG-2661 URL: http://jira.codehaus.org/browse/MNG-2661 Project: Maven 2 Issue Type: Task Components: Documentation: General Reporter: Brett Porter we need a list of archetypes like the plugins list. Also, there is a list of some nice looking archetypes over here to add: http://www.webtide.com/resources.jsp -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-242) Replace the proxy url of the Download link into the absolute url
[ http://jira.codehaus.org/browse/MRM-242?page=comments#action_81770 ] Carlos Sanchez commented on MRM-242: why is that? acegi regardless of the auth method stores in the session (or any configured place) the authentication values, so it's shared across any auth methods used Replace the proxy url of the Download link into the absolute url Key: MRM-242 URL: http://jira.codehaus.org/browse/MRM-242 Project: Archiva Issue Type: Improvement Components: web application Environment: Linux FC4, JDK1.5, Maven2.0.4 Reporter: Napoleon Esmundo C. Ramirez Fix For: 1.0-beta-1 Attachments: MRM-242-archiva.patch When browsing for artifacts in archiva, the Download link uses the proxy url. Since the artifacts are cached into archiva's managed repositories, the absolute url must be used at all times. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-242) Replace the proxy url of the Download link into the absolute url
[ http://jira.codehaus.org/browse/MRM-242?page=comments#action_81771 ] Carlos Sanchez commented on MRM-242: btw still better to be asked for the password that don't work at all Replace the proxy url of the Download link into the absolute url Key: MRM-242 URL: http://jira.codehaus.org/browse/MRM-242 Project: Archiva Issue Type: Improvement Components: web application Environment: Linux FC4, JDK1.5, Maven2.0.4 Reporter: Napoleon Esmundo C. Ramirez Fix For: 1.0-beta-1 Attachments: MRM-242-archiva.patch When browsing for artifacts in archiva, the Download link uses the proxy url. Since the artifacts are cached into archiva's managed repositories, the absolute url must be used at all times. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-242) Replace the proxy url of the Download link into the absolute url
[ http://jira.codehaus.org/browse/MRM-242?page=comments#action_81774 ] Jesse McConnell commented on MRM-242: - they are set in the session, just not sure if they are available to the security system in that proxy url or not...but anyway authn and authz are completely different operations and the webwork action or at least an interceptor on the stack would be way to go I think, with my meager knowledge of the problem domain here the way things are setup now, if you have a principal available and the user is authenticated then the authz operations would check the principals permission set based on some operation 'archiva-deploy-artifact' for instance, and then some resource, perhaps the groupId here, or the global * resource if it applies to the entire repo. if a permission matches the operation and resource up then its authz. the other approach is to grant those permissions to a role that the guest user has assigned, then it is available to anyone through the authz system. Replace the proxy url of the Download link into the absolute url Key: MRM-242 URL: http://jira.codehaus.org/browse/MRM-242 Project: Archiva Issue Type: Improvement Components: web application Environment: Linux FC4, JDK1.5, Maven2.0.4 Reporter: Napoleon Esmundo C. Ramirez Fix For: 1.0-beta-1 Attachments: MRM-242-archiva.patch When browsing for artifacts in archiva, the Download link uses the proxy url. Since the artifacts are cached into archiva's managed repositories, the absolute url must be used at all times. -- 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: (WAGONFTP-7) site:deploy (deploying with FTP) Wagon protocol 'ftp' doesn't support directory copying
[ http://jira.codehaus.org/browse/WAGONFTP-7?page=comments#action_81776 ] Carlos Sanchez commented on WAGONFTP-7: --- Comments about your patch: - you can't change the API, which means you can't remove public methods - don't use tabs - don't change format of sources, causes more differencies in patch than intented See http://maven.apache.org/guides/development/guide-m2-development.html#Maven%20Code%20Style site:deploy (deploying with FTP) Wagon protocol 'ftp' doesn't support directory copying Key: WAGONFTP-7 URL: http://jira.codehaus.org/browse/WAGONFTP-7 Project: wagon-ftp Issue Type: Improvement Affects Versions: 1.0-alpha-4 Environment: windows Reporter: pinghe Attachments: putDirectory-impl.patch Wagon protocol 'ftp' doesn't support directory copying -- 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
