[jira] Closed: (MPSCM-37) can't change read-only project.xml
[ http://jira.codehaus.org/browse/MPSCM-37?page=all ] Lukas Theussl closed MPSCM-37. -- Assignee: Lukas Theussl Resolution: Duplicate Fix Version/s: (was: 1.7) can't change read-only project.xml -- Key: MPSCM-37 URL: http://jira.codehaus.org/browse/MPSCM-37 Project: maven-scm-plugin Issue Type: Bug Affects Versions: 1.4.1 Environment: maven 1.0.2 + CVSNT Reporter: Emilio Jose Mena Cebrian Assigned To: Lukas Theussl Priority: Minor SCM plgin can't change project.xml when the module has watches enabled (with 'cvs watch on' command). when watches are enabled, all the files into the module are checked out read-only. So, SCM plugin can't change project.xml. Therefore prepare-release goal doesn't work properly. -- 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: (MJAR-57) Specification and Implementation details missing from manifest
[ http://jira.codehaus.org/browse/MJAR-57?page=comments#action_74085 ] Bugittaa Pahasti commented on MJAR-57: -- The solution suggested by Brett does work: configuration archive manifest addDefaultSpecificationEntriestrue/addDefaultSpecificationEntries addDefaultImplementationEntriestrue/addDefaultImplementationEntries /manifest /archive /configuration So this seems to be only documentation issue. Specification and Implementation details missing from manifest -- Key: MJAR-57 URL: http://jira.codehaus.org/browse/MJAR-57 Project: Maven 2.x Jar Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Wendy Smoak The manifest customization page claims that Specification and Implementation details will be included in the jar file manifest by default: http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html This does not happen, the default manifest contains only Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: wsmoak Build-Jdk: 1.5.0_05 On the user list, the following configuration was suggested, but it does not produce any additional entries in the manifest. configuration manifest addDefaultSpecificationEntriestrue/addDefaultSpecificationEntries addDefaultImplementationEntriestrue/addDefaultImplementationEntries /manifest /configuration -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-771) Add user management screens
[ http://jira.codehaus.org/browse/CONTINUUM-771?page=all ] Carlos Sanchez closed CONTINUUM-771. Assignee: Carlos Sanchez (was: Henry S. Isidro) Resolution: Fixed Add user management screens --- Key: CONTINUUM-771 URL: http://jira.codehaus.org/browse/CONTINUUM-771 Project: Continuum Issue Type: Sub-task Components: Web interface Reporter: Carlos Sanchez Assigned To: Carlos Sanchez Fix For: 1.1 Attachments: CONTINUUM-771-continuum-webapp-menu.patch, CONTINUUM-771-continuum-webapp-refactored_user_management_actions.patch, CONTINUUM-771-continuum-webapp-using-PlexusActionSupport.patch, CONTINUUM-771-continuum-webapp-with-improved-logging.patch, CONTINUUM-771-continuum-webapp.patch, CONTINUUM-771-continuum-webapp.patch Add a page for listing the users, with options to add/edit/delete user Users can have an unlimited number of roles (Continuum Permission) like addProject, addUser,... they are already created by the ContinuumInitializer and are static (no new roles/permissions can be added) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-843) Add user form for self editing user details
Add user form for self editing user details --- Key: CONTINUUM-843 URL: http://jira.codehaus.org/browse/CONTINUUM-843 Project: Continuum Issue Type: Sub-task Reporter: Carlos Sanchez -- 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: (CONTINUUM-843) Add user form for self editing user details
[ http://jira.codehaus.org/browse/CONTINUUM-843?page=all ] Carlos Sanchez updated CONTINUUM-843: - Assignee: Carlos Sanchez Description: Users should be able to edit its own details (like email) and change their password Of course thay can't edit their permissions or username Reuse as much as possible the edit user page already done for administrators Make sure the user id / username is not passed as argument anywhere, it must be retrieved by the UserManager object, to avoid dependency on acegi in maven-user-core i'm gonna create an interface there and add an implementation in maven-user-acegi Fix Version/s: 1.1 Component/s: Web interface Add user form for self editing user details --- Key: CONTINUUM-843 URL: http://jira.codehaus.org/browse/CONTINUUM-843 Project: Continuum Issue Type: Sub-task Components: Web interface Reporter: Carlos Sanchez Assigned To: Carlos Sanchez Fix For: 1.1 Users should be able to edit its own details (like email) and change their password Of course thay can't edit their permissions or username Reuse as much as possible the edit user page already done for administrators Make sure the user id / username is not passed as argument anywhere, it must be retrieved by the UserManager object, to avoid dependency on acegi in maven-user-core i'm gonna create an interface there and add an implementation in maven-user-acegi -- 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-844) Add user permission edit form in project group page
Add user permission edit form in project group page --- Key: CONTINUUM-844 URL: http://jira.codehaus.org/browse/CONTINUUM-844 Project: Continuum Issue Type: Sub-task Reporter: Carlos Sanchez -- 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-441) Several projects have bad maven-metadata.xml files that are screwing up dependencies with version range feature
Several projects have bad maven-metadata.xml files that are screwing up dependencies with version range feature --- Key: MEV-441 URL: http://jira.codehaus.org/browse/MEV-441 Project: Maven Evangelism Issue Type: Bug Reporter: Patrick Moore 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 in 2 ways. 1) maven-metadata.xml in the commons-httpclient directory does not list version 3.1-alpha1. This means that it will not find that version. 2) maven-metadata.xml lists a version20020423/version which is numerically the highest number version, so my build is picking up this very old version. Other projects with this problem include: commons-chain and jmock. -- 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: (CONTINUUM-844) Add user permission edit form in project group page
[ http://jira.codehaus.org/browse/CONTINUUM-844?page=all ] Carlos Sanchez updated CONTINUUM-844: - Description: In whatever page currently present for view or edit project groups, add a form to set per user and per project group permissions It needs to show the list of users and something like checkboxes for each permission Permissions are: * View * Edit * Delete * Build Affects Version/s: 1.1 Component/s: Web interface Add user permission edit form in project group page --- Key: CONTINUUM-844 URL: http://jira.codehaus.org/browse/CONTINUUM-844 Project: Continuum Issue Type: Sub-task Components: Web interface Affects Versions: 1.1 Reporter: Carlos Sanchez In whatever page currently present for view or edit project groups, add a form to set per user and per project group permissions It needs to show the list of users and something like checkboxes for each permission Permissions are: * View * Edit * Delete * Build -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MINSTALL-33) mvn install:install-file should create appropriate entries so that dependencies with version ranges will use installed file.
mvn install:install-file should create appropriate entries so that dependencies with version ranges will use installed file. Key: MINSTALL-33 URL: http://jira.codehaus.org/browse/MINSTALL-33 Project: Maven 2.x Install Plugin Issue Type: Bug Affects Versions: 2.1 Environment: all Reporter: Patrick Moore when using install:install-file it should cooperate with the code that handles versions that don't have an explicit version, but specify a version range. For example, if I install hibernate-3.2.0rc4, and my pom.xml has the hibernate dependency specified as: dependency groupIdhibernate/groupId artifactIdhibernate/artifactId version[3.2.0rc4,)/version /dependency maven will complain that it cannot find the hibernate version 3.2.0rc4. However if the dependency is specified as : dependency groupIdhibernate/groupId artifactIdhibernate/artifactId version3.2.0rc4/version /dependency then the project builds successfully. -- 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-441) Several projects have bad maven-metadata.xml files that are screwing up dependencies with version range feature
[ http://jira.codehaus.org/browse/MEV-441?page=comments#action_74088 ] Patrick Moore commented on MEV-441: --- a large % of the projects have incomplete maven-metadata.xml files in their repositories. Additional examples: hsqldb, commons-collections, rhino/js htmlunit Several projects have bad maven-metadata.xml files that are screwing up dependencies with version range feature --- Key: MEV-441 URL: http://jira.codehaus.org/browse/MEV-441 Project: Maven Evangelism Issue Type: Bug Reporter: Patrick Moore 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 in 2 ways. 1) maven-metadata.xml in the commons-httpclient directory does not list version 3.1-alpha1. This means that it will not find that version. 2) maven-metadata.xml lists a version20020423/version which is numerically the highest number version, so my build is picking up this very old version. Other projects with this problem include: commons-chain and jmock. -- 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: (MCLEAN-10) Option to mvn clean task not to follow soft links
[ http://jira.codehaus.org/browse/MCLEAN-10?page=comments#action_74089 ] Roar Lauritzsen commented on MCLEAN-10: --- This seems like the way to do it: project ... build plugins ... plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-clean-plugin/artifactId configuration fileset directorytarget/directory followSymlinksfalse/followSymlinks /fileset /configuration /plugin Option to mvn clean task not to follow soft links --- Key: MCLEAN-10 URL: http://jira.codehaus.org/browse/MCLEAN-10 Project: Maven 2.x Clean Plugin Issue Type: New Feature Environment: UNIX Reporter: Roar Lauritzsen Priority: Minor Our project builds an executable into our install subproject under install/target. To do a test-run of this executable, I usually symlink a directory containing about 1 million test-data files into the directory tree below target. I much prefer symlinking this test-data directory instead of copying it, because of the time it takes to copy. However, if I inadvertently do mvn clean without removing this link, maven will follow the symlink and recursively remove my whole input document directory. An option to mvn clean, like dontFollowSymlinks, could do the trick -- 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: (MCLOVER-52) Support for multiple source code folders
Support for multiple source code folders Key: MCLOVER-52 URL: http://jira.codehaus.org/browse/MCLOVER-52 Project: Maven 2.x Clover Plugin Issue Type: New Feature Reporter: Ingo Düppe Priority: Minor Add support for multiple source folders. It should be possible to configure that sources that are generated to an additional folder like /target/src also be covered by clover. -- 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-163) add support for javadoc bundles and maven1 plugins in LegacyDiscoverer
add support for javadoc bundles and maven1 plugins in LegacyDiscoverer -- Key: MRM-163 URL: http://jira.codehaus.org/browse/MRM-163 Project: Archiva Issue Type: Improvement Components: discovery Reporter: nicolas de loof Attachments: LegacyDiscoverer.patch path for maven/plugins/maven-test-plugin-1.8.jar or javax.sql/javadoc.jars/jdbc-2.0-javadoc.jar are not converted to Artifact by LegacyArtifactDiscoverer. The attached patch includes testcase for such path and some enhancements to LegacyArtifactDiscoverer to parse them 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] Updated: (CONTINUUM-845) Sort files list in working copy screen by name and add some informations about files (date, size)
[ http://jira.codehaus.org/browse/CONTINUUM-845?page=all ] Emmanuel Venisse updated CONTINUUM-845: --- Fix Version/s: 1.1 Summary: Sort files list in working copy screen by name and add some informations about files (date, size) (was: Sort file list in working copy screen by name and add some informations about files (date, size)) Sort files list in working copy screen by name and add some informations about files (date, size) - Key: CONTINUUM-845 URL: http://jira.codehaus.org/browse/CONTINUUM-845 Project: Continuum Issue Type: Improvement Components: Web interface Reporter: Emmanuel Venisse Priority: Trivial Fix For: 1.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: (CONTINUUM-845) Sort file list in working copy screen by name and add some informations about files (date, size)
Sort file list in working copy screen by name and add some informations about files (date, size) Key: CONTINUUM-845 URL: http://jira.codehaus.org/browse/CONTINUUM-845 Project: Continuum Issue Type: Improvement Components: Web interface Reporter: Emmanuel Venisse Priority: Trivial Fix For: 1.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] Commented: (MJAR-28) Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions
[ http://jira.codehaus.org/browse/MJAR-28?page=comments#action_74095 ] Max Bowsher commented on MJAR-28: - Baerrach: Do you mean MJAR-28-patch.txt ? If so, I don't see how it can do that, since it seems mostly to be a tree reorganization and deletion of dead comments and code. Is it possible that the wrong file is attached to JIRA ? Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions -- Key: MJAR-28 URL: http://jira.codehaus.org/browse/MJAR-28 Project: Maven 2.x Jar Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Mark J. Titorenko Attachments: MJAR-28-patch.txt When the POM contains dependencies to snapshot versions of jars, and snapshot versions of those jars are downloaded from a remote repository, the name of the jar contained in the classpath added to the manifest, of the form artifactID-X.X-SNAPSHOT.jar, does not match the actual name of the jar downloaded, which contains version information of the form artifactID-X.X-MMDD.HHmmss-V.jar. This does not affect snapshot versions which have been directly installed into a local repository and have no uploaded version within the remote repository, as these jars are named using the artifactID-X.X-SNAPSHOT.jar form. -- 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-1113) Please update/replace Sesame 1.2.6 and Rio 1.0.9 bundles in your maven2 repository
Please update/replace Sesame 1.2.6 and Rio 1.0.9 bundles in your maven2 repository -- Key: MAVENUPLOAD-1113 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1113 Project: maven-upload-requests Issue Type: Task Reporter: Arjohn Kampman http://www.openrdf.org/maven/sesame-1.2.6-bundle.jar http://www.openrdf.org/maven/rio-1.0.9-bundle.jar http://www.openrdf.org/maven/openrdf-util-1.2.6-bundle.jar http://www.openrdf.org/maven/openrdf-model-1.2.6-bundle.jar If possible, can you replace the Sesame 1.2.6 and Rio 1.0.9 bundles that have been added earlier with the bundles mentioned above? The new bundles now include the source files. -- 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: (MJAR-28) Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions
[ http://jira.codehaus.org/browse/MJAR-28?page=comments#action_74100 ] Baerrach bonDierne commented on MJAR-28: Sorry you are right. The changes I needed to make for this are in maven-archiver in the linked issue MNG-2456 as the archiver does all the actual work, jar just invokes archiver. Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions -- Key: MJAR-28 URL: http://jira.codehaus.org/browse/MJAR-28 Project: Maven 2.x Jar Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Mark J. Titorenko Attachments: MJAR-28-patch.txt When the POM contains dependencies to snapshot versions of jars, and snapshot versions of those jars are downloaded from a remote repository, the name of the jar contained in the classpath added to the manifest, of the form artifactID-X.X-SNAPSHOT.jar, does not match the actual name of the jar downloaded, which contains version information of the form artifactID-X.X-MMDD.HHmmss-V.jar. This does not affect snapshot versions which have been directly installed into a local repository and have no uploaded version within the remote repository, as these jars are named using the artifactID-X.X-SNAPSHOT.jar form. -- 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-1114) Upload Hibernate 3.2.0.cr4
Upload Hibernate 3.2.0.cr4 -- Key: MAVENUPLOAD-1114 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1114 Project: maven-upload-requests Issue Type: Task Reporter: Edson Yanaga Please upload the 3.2.0.cr4 version of Hibernate. -- 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-843) Add user form for self editing user details
[ http://jira.codehaus.org/browse/CONTINUUM-843?page=comments#action_74104 ] Napoleon Esmundo C. Ramirez commented on CONTINUUM-843: --- I'm thinking that, to reuse the same edit.jsp page in maven-user-webapp, we could use the authz taglib to disable the username text field and disable the stuff for editing the permissions. But wouldn't that tie acegi up with maven-user-webapp too much? Or am I just missing something? Add user form for self editing user details --- Key: CONTINUUM-843 URL: http://jira.codehaus.org/browse/CONTINUUM-843 Project: Continuum Issue Type: Sub-task Components: Web interface Reporter: Carlos Sanchez Assigned To: Carlos Sanchez Fix For: 1.1 Users should be able to edit its own details (like email) and change their password Of course thay can't edit their permissions or username Reuse as much as possible the edit user page already done for administrators Make sure the user id / username is not passed as argument anywhere, it must be retrieved by the UserManager object, to avoid dependency on acegi in maven-user-core i'm gonna create an interface there and add an implementation in maven-user-acegi -- 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-442) Several projects have maven-metadata.xml files that are missing released versions
Several projects have maven-metadata.xml files that are missing released versions - Key: MEV-442 URL: http://jira.codehaus.org/browse/MEV-442 Project: Maven Evangelism Issue Type: Bug Reporter: Patrick Moore 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 in 2 ways. 1) maven-metadata.xml in the commons-httpclient directory does not list version 3.1-alpha1. This means that it will not find that version. 2) maven-metadata.xml lists a version20020423/version which is numerically the highest number version, so my build is picking up this very old version. Other projects with this problem include: commons-chain and jmock. -- 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: (MEV-442) Several projects have maven-metadata.xml files that are missing released versions
[ http://jira.codehaus.org/browse/MEV-442?page=all ] Patrick Moore closed MEV-442. - Resolution: Duplicate cloning an issue didn't let me edit the issue. will make a new issue Several projects have maven-metadata.xml files that are missing released versions - Key: MEV-442 URL: http://jira.codehaus.org/browse/MEV-442 Project: Maven Evangelism Issue Type: Bug Reporter: Patrick Moore 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 in 2 ways. 1) maven-metadata.xml in the commons-httpclient directory does not list version 3.1-alpha1. This means that it will not find that version. 2) maven-metadata.xml lists a version20020423/version which is numerically the highest number version, so my build is picking up this very old version. Other projects with this problem include: commons-chain and jmock. -- 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-443) Several projects have maven-metadata.xml files that are missing released versions
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 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] Updated: (MSUREFIRE-143) provide option to list all of the test cases which failed when running a build
[ http://jira.codehaus.org/browse/MSUREFIRE-143?page=all ] Charlie Groves updated MSUREFIRE-143: - Attachment: MSUREFIRE-143-surefire-api.patch MSUREFIRE-143-maven-surefire-plugin.patch I've updated the patches to work as Brett suggested. That handles both with useFile and without and removes the @FL line. It changes the current behavior so that if printSummary is true the console printout uses the same format as the file output, but that seems better to me so I went with it. I think it'd be nice to delete the subclasses of ConsoleReporter and FileReporter in surefire-api(Brief*) and just require a format string to be passed in. The use of subclasses confused me initially since I thought that was the mechanism that was used to determine how to format output. I didn't go ahead and do that since I'm not sure if this is used external to the plugin. provide option to list all of the test cases which failed when running a build -- Key: MSUREFIRE-143 URL: http://jira.codehaus.org/browse/MSUREFIRE-143 Project: Maven 2.x Surefire Plugin Issue Type: Improvement Reporter: james strachan Fix For: 2.3 Attachments: MSUREFIRE-143-maven-surefire-plugin.patch, MSUREFIRE-143-maven-surefire-plugin.patch, MSUREFIRE-143-surefire-api.patch, MSUREFIRE-143-surefire-api.patch Lots of projects I work on have large numbers of test cases; the execution of the tests takes up many screens. We are often see the output... Results : Tests run: 1496, Failures: 0, Errors: 5, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] Then we have to page up manually grepping for FAILURE which can take a while. It would be good to just list the failed test cases in the output -- 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-441) Several projects have bad maven-metadata.xml files that are screwing up dependencies with version range feature
[ http://jira.codehaus.org/browse/MEV-441?page=comments#action_74114 ] Patrick Moore commented on MEV-441: --- I have added a new issue so that the two problems of missing versions and badly numbered versions can be tracked separately. http://jira.codehaus.org/browse/MEV-443 Several projects have bad maven-metadata.xml files that are screwing up dependencies with version range feature --- Key: MEV-441 URL: http://jira.codehaus.org/browse/MEV-441 Project: Maven Evangelism Issue Type: Bug Reporter: Patrick Moore 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 in 2 ways. 1) maven-metadata.xml in the commons-httpclient directory does not list version 3.1-alpha1. This means that it will not find that version. 2) maven-metadata.xml lists a version20020423/version which is numerically the highest number version, so my build is picking up this very old version. Other projects with this problem include: commons-chain and jmock. -- 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-155) Multiproject Release Fails on Windows
Multiproject Release Fails on Windows - Key: MRELEASE-155 URL: http://jira.codehaus.org/browse/MRELEASE-155 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-4 Environment: Windows 2000, Tortoise CVS 1.8.26. Maven 2.0.4, release 2.0-beta 4. Reporter: Todd Nine I am receiving errors when attempting to check in on a multiproject release. Below is my output. As you can see, it is not checking in the parent pom. If I manually execute the command in the output, the parent pom is correctly checked in. Is it possible the first file in the output (which happens to be the parent pom) is not getting added to the arguments when the commit command is executed? [INFO] Checking in modified POMs... [INFO] Executing: cvs -z3 -f -d :ext:[EMAIL PROTECTED]:/a01/proj/CVS -q commit -R -F C:\DOCUME~1\u84172\LOCALS~1\Temp\scm-commit-message27749.txt pom.xml messageDrivenSender/pom.xml messageDrivenPojo/pom.xml messageDrivenDelegate/pom.xml [INFO] Working directory: C:\development\ata\utilities [INFO] Tagging release with the label utilitiesParent-1_0_0... [INFO] Executing: cvs -z3 -f -d :ext:[EMAIL PROTECTED]:/a01/proj/CVS -q tag -F -c utilitiesParent-1_0_0 [INFO] Working directory: C:\development\ata\utilities [WARNING] Unknown status: '? '. [INFO] --- [ERROR] BUILD FAILURE [INFO] --- [INFO] Unable to tag SCM Provider message: The cvs tag command failed. Command output: cvs tag: pom.xml is locally modified cvs [tag aborted]: correct the above errors first! -- 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-443) Several projects have maven-metadata.xml files that are missing released versions
[ http://jira.codehaus.org/browse/MEV-443?page=all ] Patrick Moore updated MEV-443: -- Attachment: maven-metadata.xml This is a sample file showing what I think the maven-metadata.xml file should look like 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] Created: (MECLIPSE-155) Stop assuming J2EE 1.3
Stop assuming J2EE 1.3 -- Key: MECLIPSE-155 URL: http://jira.codehaus.org/browse/MECLIPSE-155 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Components: WTP support Affects Versions: 2.2 Reporter: Matthew Beermann Fix For: 2.3 Attachments: maven-eclipse-plugin.patch Currently, when writing out the WTP facet settings for an EAR, the eclipse goal is assuming J2EE version 1.3. This is a problem, as certain functionality could be disabled or broken in the IDE if we're actually working on a 1.4 project. The source code contains a comment saying as much. I'm attaching a patch that does the TODO, and lets the goal sense if we're running on J2EE 1.4. -- 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: (MRELEASE-94) Modified Parent POM is not commited
[ http://jira.codehaus.org/browse/MRELEASE-94?page=all ] Todd Nine reopened MRELEASE-94: --- I do not believe this is a cvs nt command problem. If I execute the command manually from the command line, it executes correctly. See the linked issue for a better explanation Modified Parent POM is not commited --- Key: MRELEASE-94 URL: http://jira.codehaus.org/browse/MRELEASE-94 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-3 Environment: Windows 2k, or Windows XP. JDK 1.4.2, scpexe=pscp sshexe=plink cvs=cvs.exe CVS_RSH=plink. Key authentication via pageant Reporter: Todd Nine Assigned To: Brett Porter Priority: Blocker I can successfully tag all sub projects of a parent pom (with the standard directory structure), but I'm unable complete the release:prepare operation since the parent POM is not checked in. As a result I am unable to perform a multi-project release. Each child pom has the scm repotisotries declared in the pom. Attached is verbose output of the command. mvn -Duser.name=c200506 -X clean release:prepare [DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0 for project: null:maven-plugin-parameter-documenter:jar:2.0 from the repository. [DEBUG] org.apache.maven:maven-plugin-parameter-documenter:jar:2.0:runtime (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed - nearer found: 1.1) [DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0 for project: null:maven-error-diagnostics:jar:2.0 from the repository. [DEBUG] org.apache.maven:maven-error-diagnostics:jar:2.0:runtime (selected for runtime)[DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0 for project: org.apac he.maven:maven-monitor:jar:2.0 from the repository. [DEBUG] org.apache.maven:maven-monitor:jar:2.0:runtime (selected for runtime ) [DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0 for project: null:mav en-settings:jar:2.0 from the repository. [DEBUG] org.apache.maven:maven-settings:jar:2.0:runtime (selected for runtim e) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed - near er found: 1.1) [DEBUG] org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-5:runtim e (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed - near er found: 1.1) [DEBUG] org.apache.maven.wagon:wagon-file:jar:1.0-alpha-5:runtime (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed - near er found: 1.1) [DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0 for project: org.apac he.maven:maven-plugin-descriptor:jar:2.0 from the repository. [DEBUG] org.apache.maven:maven-plugin-descriptor:jar:2.0:runtime (selected f or runtime) [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0:runtime (selected for ru ntime) [DEBUG] commons-cli:commons-cli:jar:1.0:runtime (selected for runtime) [DEBUG] org.apache.maven.wagon:wagon-ssh:jar:1.0-alpha-5:runtime (selected f or runtime) [DEBUG] com.jcraft:jsch:jar:0.1.23:runtime (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed - near er found: 1.1) [DEBUG] Retrieving parent-POM: org.apache.maven.reporting:maven-reporting::2.0 f or project: null:maven-reporting-api:jar:2.0 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0 for project: org.apac he.maven.reporting:maven-reporting:pom:2.0 from the repository. [DEBUG] org.apache.maven.reporting:maven-reporting-api:jar:2.0:runtime (sele cted for runtime) [DEBUG] doxia:doxia-sink-api:jar:1.0-alpha-4:runtime (selected for runtime ) [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0:runtime (selected for runt ime) [DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0 for project: org.apac he.maven:maven-plugin-registry:jar:2.0 from the repository. [DEBUG] org.apache.maven:maven-plugin-registry:jar:2.0:runtime (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed - near er found: 1.1) [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0:runtime (selected for runtim e) [DEBUG] org.apache.maven:maven-artifact:jar:2.0:runtime (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed - nearer found: 1.1) [DEBUG] Skipping disabled repository central [DEBUG] maven-scm-manager-plexus: resolved to version 1.0-beta-3-20060330.123807 -1 from repository apache.snapshots [DEBUG] Retrieving parent-POM: org.apache.maven.scm:maven-scm-managers::1.0-beta -3-SNAPSHOT for project: null:maven-scm-manager-plexus:jar:1.0-beta-3-20060330.1
[jira] Closed: (MNG-1797) Dependency excludes apply to every subsequent dependency, not just the one it is declared under.
[ http://jira.codehaus.org/browse/MNG-1797?page=all ] John Casey closed MNG-1797. --- Assignee: John Casey Resolution: Fixed Fix Version/s: (was: 2.1) 2.0.5 Applied the code patch, but I added a simpler unit test. Dependency excludes apply to every subsequent dependency, not just the one it is declared under. Key: MNG-1797 URL: http://jira.codehaus.org/browse/MNG-1797 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.1 Reporter: David Hawkins Assigned To: John Casey Fix For: 2.0.5 Attachments: it1019.tgz, it1020.tgz, MNG-1797-maven-project.patch, MNG-1797-unit-test.patch If you specify ANY dependency excludes, all dependencies after that one in the pom will also exclude what you specified. They appear to be cumulative on every dependency in that they bleed over into sibling dependencies. It's easy to test if you add an exclusion to a random dependency. This exclusion should exclude a required transitive dependency that is included by a dependency lower in the list. You will find that the dependency lower in the list no longer includes the required dependency because it is using the filter you declared in the other dependency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2420) exclusion on dependency seems to act global on POM
[ http://jira.codehaus.org/browse/MNG-2420?page=all ] John Casey closed MNG-2420. --- Assignee: John Casey Resolution: Duplicate Fix Version/s: (was: 2.1) 2.0.5 Fixed in MNG-1797 exclusion on dependency seems to act global on POM -- Key: MNG-2420 URL: http://jira.codehaus.org/browse/MNG-2420 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Environment: tested on solaris, linux and windows Reporter: Jörg Hohwiller Assigned To: John Casey Fix For: 2.0.5 In my POM I added xerces:xercesImpl:2.8.0 as compile dependency what depends on xml-apis:xml-apis:1.3.03. Since I also have commons-betwixt:commons-betwixt:0.7, commons-configuration:commons-configuration:1.2, and ant:ant:1.6.5 as dependencies that also depend on xml-apis but in different versions I came into trouble. Since one of theses xml-apis dependencies has a higher version number (but is the JAR of an earlier version) maven does not decide for 1.3.03 which is correct behaviour for maven. Anyways I got NoClassDefFoundError: org/w3c/dom/DOMError when I run my tests with XmlUnit. Now here comes the problem: I added the following XML snipplet to all dependencies that depend on xml-apis except for xercesImpl. exclusion artifactIdxml-apis/artifactId groupIdxml-apis/groupId /exclusion This caused maven NOT to include the dependency on xml-apis at all. This was hard to track because the org/w3c/dom/DOMError did not occure on evey machine involved in the project. I figured out that the ones having no trouble used jdk1.5 that has this code included inside (JAXP 1.3). With jdk1.4.2 this bug was reproducable on any operating system. Now it comes even harder: I added dependency groupIdxml-apis/groupId artifactIdxml-apis/artifactId version1.3.03/version /dependency as toplevel dependency to the POM and still maven did NOT include this dependency when running the test. The funny thing is that mvn eclipse:eclipse produced the right dependency in my IDE. Anyways in the dependency report on the site it was missing. I additionally had to remove all the exclusion tags to make it work again. To me it looks like the handling of the exclusion tag is broken, meaning that it does NOT work as I (!) expected. I hope that this behaviour is NOT intendet. Best Regards Jörg -- 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-843) Add user form for self editing user details
[ http://jira.codehaus.org/browse/CONTINUUM-843?page=comments#action_74122 ] Carlos Sanchez commented on CONTINUUM-843: -- Putting the acegi taglib in the jsp is fine Add user form for self editing user details --- Key: CONTINUUM-843 URL: http://jira.codehaus.org/browse/CONTINUUM-843 Project: Continuum Issue Type: Sub-task Components: Web interface Reporter: Carlos Sanchez Assigned To: Carlos Sanchez Fix For: 1.1 Users should be able to edit its own details (like email) and change their password Of course thay can't edit their permissions or username Reuse as much as possible the edit user page already done for administrators Make sure the user id / username is not passed as argument anywhere, it must be retrieved by the UserManager object, to avoid dependency on acegi in maven-user-core i'm gonna create an interface there and add an implementation in maven-user-acegi -- 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: (MWAR-9) WAR plugin should support minimal WARs for inclusion within an EAR
[ http://jira.codehaus.org/browse/MWAR-9?page=comments#action_74125 ] Joe Mays commented on MWAR-9: - I agree with Al; until we can support packaging a mixture of WAR dependencies using WEB-INF/lib and MANIFEST.MF, m2 does not support JEE packaging requirements. WAR plugin should support minimal WARs for inclusion within an EAR -- Key: MWAR-9 URL: http://jira.codehaus.org/browse/MWAR-9 Project: Maven 2.x War Plugin Issue Type: Improvement Reporter: Mike Perham I noticed that when I build a WAR, I get a gigantic WEB-INF/lib with all my deps. This is fine for a default but maven should also support skeleton WARs which will be packaged within an EAR. We have EARs which package 3-4 WARs each and to have the deps duplicated within each WAR means we cannot have shared data (since the classes are loaded within each WAR's classloader, rather than by the parent EAR's classloader). It also means 80MB EARs! :-) It seems like two things need to happen: 1) Add a skeleton flag which prevents copying any dependencies to WEB-INF/lib. 2) Instead generate a META-INF/MANIFEST.MF which has a Class-Path entry which lists the relative locations of the dependencies within the parent EAR. Fabrice has basically the same idea written down here. Starting with - for a War... : http://marc.theaimsgroup.com/?l=turbine-maven-userm=112737860024530w=2 -- 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-2547) maven-grafo-plugin generates only create 1 node for each artifact eventhough multiple versions exist in edges
[ http://jira.codehaus.org/browse/MNG-2547?page=all ] Pin Ngee Koh updated MNG-2547: -- Attachment: Grafo.java Attached java files has the fix for this issue. maven-grafo-plugin generates only create 1 node for each artifact eventhough multiple versions exist in edges - Key: MNG-2547 URL: http://jira.codehaus.org/browse/MNG-2547 Project: Maven 2 Issue Type: Bug Components: Sandbox Affects Versions: 2.0.4 Environment: J2SE 1.5 Reporter: Pin Ngee Koh Attachments: Grafo.java If the following compile dependencies exist A-1.0.jar -- B-2.0.jar -- C-3.0.jar -- D-4.0.jar B-2.0.jar -- D-5.0.jar Node generated for artifact D is for version 5.0, while the edges reflects both version - 4.0 and 5.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] Created: (MAVENUPLOAD-1115) Upload jxls-0.8.9 bundle
Upload jxls-0.8.9 bundle Key: MAVENUPLOAD-1115 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1115 Project: maven-upload-requests Issue Type: Task Reporter: Leonid Vysochyn jXLS is small and easy-to-use Java library for generating Excel files using XLS templates. This is a new release of the library. The previous one 0.8.8 was already uploaded. See http://jira.codehaus.org/browse/MAVENUPLOAD-1062 for details. -- 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: (MCLOVER-48) add support for block contexts.
[ http://jira.codehaus.org/browse/MCLOVER-48?page=comments#action_74130 ] Robert Newson commented on MCLOVER-48: -- Does anyone still maintain the clover plugin? add support for block contexts. --- Key: MCLOVER-48 URL: http://jira.codehaus.org/browse/MCLOVER-48 Project: Maven 2.x Clover Plugin Issue Type: New Feature Reporter: Robert Newson We use a lot of asserts in our code. We would like to exclude the assert lines from our code coverage figures. The Ant, Eclipse and Maven 1.x plugin support Clover's block context feature. Can the Maven 2.x plugin be enhanced to support this? http://www.cenqua.com/clover/doc/adv/contexts.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: (MNG-2369) Generic 3rd Party DotNet Libraries not appropriately handled
[ http://jira.codehaus.org/browse/MNG-2369?page=comments#action_74132 ] Dan Fabulich commented on MNG-2369: --- I would also direct your attention to this doc: http://docs.codehaus.org/display/MAVENUSER/BEA+Maven+Requirement+Documents Generic 3rd Party DotNet Libraries not appropriately handled Key: MNG-2369 URL: http://jira.codehaus.org/browse/MNG-2369 Project: Maven 2 Issue Type: Improvement Components: Sandbox, Multiple Language Support Environment: Windows XP Reporter: James Carpenter Fix For: 2.2 The csharp plugins work great when using .Net dependencies built with the csharp plugins, but don't work in the general case. Problem Statement: (Note: As a Java developer, I might mess this up a bit.) A .NET assembly contains a manifest which lists the assemblies it depends upon. In addition to checking digital signatures for public assemblies, the classloader (whatever MS calls it) expects the filenames of the dependencies to match that described in the manifest. The problem is the maven repository structure imposes a particular naming convention upon the artifacts placed within it. So you can't just take a third party dll change its name to fit into the maven repo artifact naming convention and create an associated POM. Artifacts built by maven using the csharp plugins match the maven repo artifact naming conventions and the assembly manifests contain dependencies whose names are consistent with the maven repo artifact naming conventions. Tatical Solution: The nasty tatical solution I am currently using, is to simple refer to any 3rd party dlls as system dependencies. (scopesystem/scope) Potential Strategic Solution: I believe the solution is to create another maven artifact type to support 3rd party dlls. The artifact actually stored in the maven repo should be an archieve of some sort (jar, zip, etc.). During the process-resources (some phase prior to compilation, might need custom lifecycle) phase these 3rd party dependencies would be downloaded by the ArtifactResolver and unarchieved in some directory structure which maintains the versioning through directory naming, but not by file name. The dll filename would be the same as the original name of the 3rd party dll (most likely implementation choice is simply to let the archieve maintain the original name). When maven builds the classpath, any artifact of this new type would be represented in the classpath as the path to the unarchieved dll. (The current csharp compiler plugin sees these as the path to the local repo.) I believe, it will actually be necessary to produce two new artifact types. One will be used for managed dependencies and another for native unmanaged dependencies. This distinction is important because the csc (C# compiler) only wants to know about managed dependencies. (See as /resource arguments to csc compiler. Refer to plexus csharp compiler code for details.) I'm not sure my proposed solution is 100% accurate, as I still don't know the maven internals that well, but I think its close. -- 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-1107) upload jguard v1.00-beta-1 jars
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1107?page=comments#action_74143 ] Carlos Sanchez commented on MAVENUPLOAD-1107: - you have to do it manually upload jguard v1.00-beta-1 jars --- Key: MAVENUPLOAD-1107 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1107 Project: maven-upload-requests Issue Type: Task Reporter: charles gay http://jguard.sourceforge.net/v1.00/1.00-beta-1/jguard-core-1.00-beta-1-bundle.jar http://jguard.sourceforge.net/v1.00/1.00-beta-1/jguard-ext-1.00-beta-1-bundle.jar http://jguard.sourceforge.net/v1.00/1.00-beta-1/jguard-jee-1.00-beta-1-bundle.jar http://jguard.sourceforge.net/v1.00/1.00-beta-1/jguard-struts-example-1.00-beta-1-bundle.jar http://jguard.sourceforge.net/v1.00/1.00-beta-1/jguard-swing-example-1.00-beta-1-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1114) Upload Hibernate 3.2.0.cr4
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1114?page=all ] Carlos Sanchez closed MAVENUPLOAD-1114. --- Assignee: Carlos Sanchez Resolution: Incomplete Read instructions http://maven.apache.org/guides/mini/guide-ibiblio-upload.html Upload Hibernate 3.2.0.cr4 -- Key: MAVENUPLOAD-1114 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1114 Project: maven-upload-requests Issue Type: Task Reporter: Edson Yanaga Assigned To: Carlos Sanchez Please upload the 3.2.0.cr4 version of Hibernate. -- 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-1115) Upload jxls-0.8.9 bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1115?page=all ] Carlos Sanchez closed MAVENUPLOAD-1115. --- Assignee: Carlos Sanchez Resolution: Fixed Upload jxls-0.8.9 bundle Key: MAVENUPLOAD-1115 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1115 Project: maven-upload-requests Issue Type: Task Reporter: Leonid Vysochyn Assigned To: Carlos Sanchez jXLS is small and easy-to-use Java library for generating Excel files using XLS templates. This is a new release of the library. The previous one 0.8.8 was already uploaded. See http://jira.codehaus.org/browse/MAVENUPLOAD-1062 for details. -- 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-1113) Please update/replace Sesame 1.2.6 and Rio 1.0.9 bundles in your maven2 repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1113?page=all ] Carlos Sanchez closed MAVENUPLOAD-1113. --- Assignee: Carlos Sanchez Resolution: Fixed Deployed sources only Please update/replace Sesame 1.2.6 and Rio 1.0.9 bundles in your maven2 repository -- Key: MAVENUPLOAD-1113 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1113 Project: maven-upload-requests Issue Type: Task Reporter: Arjohn Kampman Assigned To: Carlos Sanchez http://www.openrdf.org/maven/sesame-1.2.6-bundle.jar http://www.openrdf.org/maven/rio-1.0.9-bundle.jar http://www.openrdf.org/maven/openrdf-util-1.2.6-bundle.jar http://www.openrdf.org/maven/openrdf-model-1.2.6-bundle.jar If possible, can you replace the Sesame 1.2.6 and Rio 1.0.9 bundles that have been added earlier with the bundles mentioned above? The new bundles now include the source files. -- 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-1109) ehcache-1.2.3 bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1109?page=all ] Carlos Sanchez closed MAVENUPLOAD-1109. --- Assignee: Carlos Sanchez Resolution: Fixed ehcache-1.2.3 bundle Key: MAVENUPLOAD-1109 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1109 Project: maven-upload-requests Issue Type: Task Reporter: Greg Luck Assigned To: Carlos Sanchez Attachments: ehcache-1.2.3-bundle.jar, ehcache-1.2.3-bundle.jar ehcache-1.2.3 bundle. The tgz was released on sourceforge yesterday. -- 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-1112) upload vraptor 2.1.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1112?page=all ] Carlos Sanchez closed MAVENUPLOAD-1112. --- Assignee: Carlos Sanchez Resolution: Fixed upload vraptor 2.1.1 Key: MAVENUPLOAD-1112 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1112 Project: maven-upload-requests Issue Type: Task Reporter: Guilherme Silveira Assigned To: Carlos Sanchez Its another mvc controller favoring conventions over configuration. It tries to solve some most problems without going to usual solutions as ThreadLocal (i.e. webwork/jsf based solution) for example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1111) JasperReports 1.2.6
[ http://jira.codehaus.org/browse/MAVENUPLOAD-?page=all ] Carlos Sanchez closed MAVENUPLOAD-. --- Assignee: Carlos Sanchez Resolution: Fixed JasperReports 1.2.6 --- Key: MAVENUPLOAD- URL: http://jira.codehaus.org/browse/MAVENUPLOAD- Project: maven-upload-requests Issue Type: Task Reporter: lucian chirita Assigned To: Carlos Sanchez Java reporting library released under LGPL -- 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-1110) jython-2.2-alpha1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1110?page=all ] Carlos Sanchez closed MAVENUPLOAD-1110. --- Assignee: Carlos Sanchez Resolution: Fixed jython-2.2-alpha1 - Key: MAVENUPLOAD-1110 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1110 Project: maven-upload-requests Issue Type: Task Reporter: fabrizio giustina Assigned To: Carlos Sanchez -- 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_74147 ] Carlos Sanchez commented on MEV-443: we're aware of these problems, hopefully will be solved with Archiva (or Maven Repository Manager) 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] Reopened: (MAVENUPLOAD-1109) ehcache-1.2.3 bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1109?page=all ] Greg Luck reopened MAVENUPLOAD-1109: Carlos I cannot find this anywhere ibiblio. Can you show me the path? I looked under ehcache top level and also under net/sf/ehcache Greg ehcache-1.2.3 bundle Key: MAVENUPLOAD-1109 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1109 Project: maven-upload-requests Issue Type: Task Reporter: Greg Luck Assigned To: Carlos Sanchez Attachments: ehcache-1.2.3-bundle.jar, ehcache-1.2.3-bundle.jar ehcache-1.2.3 bundle. The tgz was released on sourceforge yesterday. -- 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-1109) ehcache-1.2.3 bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1109?page=all ] Carlos Sanchez closed MAVENUPLOAD-1109. --- Resolution: Fixed takes up to 4 hours to be available in ibiblio ehcache-1.2.3 bundle Key: MAVENUPLOAD-1109 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1109 Project: maven-upload-requests Issue Type: Task Reporter: Greg Luck Assigned To: Carlos Sanchez Attachments: ehcache-1.2.3-bundle.jar, ehcache-1.2.3-bundle.jar ehcache-1.2.3 bundle. The tgz was released on sourceforge yesterday. -- 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-842) Maven-user improvements
[ http://jira.codehaus.org/browse/CONTINUUM-842?page=comments#action_74151 ] Carlos Sanchez commented on CONTINUUM-842: -- when editing an user, user name is modifiable and shouldn't be the confirmPassword field is missing Maven-user improvements --- Key: CONTINUUM-842 URL: http://jira.codehaus.org/browse/CONTINUUM-842 Project: Continuum Issue Type: Sub-task Components: Web interface Reporter: Carlos Sanchez Assigned To: Henry S. Isidro Fix For: 1.1 - user list page shows user.username user.email - when adding a user, the roles list shouldn't show up, only on editing -- 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-842) Maven-user improvements
[ http://jira.codehaus.org/browse/CONTINUUM-842?page=comments#action_74152 ] Carlos Sanchez commented on CONTINUUM-842: -- links in menu should not pass the username as an argument, or the user can edit it by hand and impersonate another user Maven-user improvements --- Key: CONTINUUM-842 URL: http://jira.codehaus.org/browse/CONTINUUM-842 Project: Continuum Issue Type: Sub-task Components: Web interface Reporter: Carlos Sanchez Assigned To: Henry S. Isidro Fix For: 1.1 - user list page shows user.username user.email - when adding a user, the roles list shouldn't show up, only on editing -- 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-150) add field validations for forms
[ http://jira.codehaus.org/browse/MRM-150?page=comments#action_74154 ] Maria Odea Ching commented on MRM-150: -- Validations already implemented: 1. ConfigureRepositoryAction-validation: - required fields: id, name, directory - layout field is validated if the selected value is in the selection list 2. ConfigureProxiedRepositoryAction-validation: - required fields: id, name, url, layout, managedRepository - snapshotsInterval and releasesInterval are validated if they are numeric - layout, snapshotsPolicy and releasesPolicy are validated if the selected values are in their respective selection list - snapshotsInterval and releasesInterval should be set to 0 when the selected policy is not 'interval' 3. ConfigureSyncedRepositoryAction-addSelectedSyncedRepository-validation: - requiredd fields: id, name, layout, managedRepository - layout field is validated if the selected value is in the selection list - sync settings is validated, depending on what method 4. ConfigureSyncedrepositoryAction-validation: - method field is required - method field is validatedd if the selected value is in the selection list add field validations for forms --- Key: MRM-150 URL: http://jira.codehaus.org/browse/MRM-150 Project: Archiva Issue Type: Task Components: web application Reporter: Brett Porter Assigned To: Maria Odea Ching Fix For: 1.0-beta-1 Original Estimate: 20 hours Time Spent: 1 day, 4 hours Remaining Estimate: 0 minutes these are documented in the validation files by todos -- 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: (MCLOVER-48) add support for block contexts.
[ http://jira.codehaus.org/browse/MCLOVER-48?page=comments#action_74155 ] Vincent Massol commented on MCLOVER-48: --- Hi Robert, Yes it's maintained. Does your question imply that you have a patch ready for this feature and you'd like to submit it for inclusion? :-) I'll work on this in due time, just haven't had the time yet. Now if you have a patch I could apply it. Thanks -Vincent add support for block contexts. --- Key: MCLOVER-48 URL: http://jira.codehaus.org/browse/MCLOVER-48 Project: Maven 2.x Clover Plugin Issue Type: New Feature Reporter: Robert Newson We use a lot of asserts in our code. We would like to exclude the assert lines from our code coverage figures. The Ant, Eclipse and Maven 1.x plugin support Clover's block context feature. Can the Maven 2.x plugin be enhanced to support this? http://www.cenqua.com/clover/doc/adv/contexts.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: (MCLOVER-48) add support for block contexts.
[ http://jira.codehaus.org/browse/MCLOVER-48?page=comments#action_74156 ] Robert Newson commented on MCLOVER-48: -- Hi! I was asking as there hasn't been much activity on the outstanding bugs that I can see. I may get time to work on a patch for this in the next few weeks, actually. I'd love to help out but I am kinda swamped right now (I'm sure you are too). I didn't mean to be critical and I'm glad you're still working on this. :) B. add support for block contexts. --- Key: MCLOVER-48 URL: http://jira.codehaus.org/browse/MCLOVER-48 Project: Maven 2.x Clover Plugin Issue Type: New Feature Reporter: Robert Newson We use a lot of asserts in our code. We would like to exclude the assert lines from our code coverage figures. The Ant, Eclipse and Maven 1.x plugin support Clover's block context feature. Can the Maven 2.x plugin be enhanced to support this? http://www.cenqua.com/clover/doc/adv/contexts.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: (MNG-2503) mvn.bat file is not correct for 4NT 5.0 and does endlocal twice if error
[ http://jira.codehaus.org/browse/MNG-2503?page=comments#action_74157 ] Mark DeLaFranier commented on MNG-2503: --- Vincent, I am not in a position to test with version 7.01 as I don't have access to this software - at least not in the short term. :-) Thanks for the tip for the next time. Mark mvn.bat file is not correct for 4NT 5.0 and does endlocal twice if error -- Key: MNG-2503 URL: http://jira.codehaus.org/browse/MNG-2503 Project: Maven 2 Issue Type: Bug Components: Command Line Affects Versions: 2.0.4 Environment: Windows XP SP2 and 4NT 5.00U Reporter: Mark DeLaFranier Priority: Minor Attachments: mvn.bat 1. If not setup properly and error occurs, the script attempts to endlocal twice: [d:\] mvn --version Exception in thread main java.lang.NoClassDefFoundError: org/codehaus/classworlds/Launcher 4NT: D:\dev\maven2\bin\mvn.bat [145] Missing SETLOCAL 2. Syntax wrong for adding CLASSWORLDS_JAR when under 4NT. For #1, I updated the :error section of the mvn.bat file. For #2, I added a new section to add the CLASSWORLDS_JAR -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCLOVER-47) review plugin documentation
[ http://jira.codehaus.org/browse/MCLOVER-47?page=comments#action_74158 ] Franz Allan Valencia See commented on MCLOVER-47: - Good day to you, Vincent, Regarding the Examples Section: Based from my understanding of the docck plugin and from the previous revised plugin docus before mine, I believe that the Usage Section is used to contain the basic uses cases, usually, one each goal. While the details of these use cases such as the optional and not so common/basic configurations are placed in the Examples Section. In this way, the users may read the Usage section to get a good idea of how to use it in their project, and they can use the Examples section as a quick reference for some configurations that they may need. At least this is to my understading. WDYT? :-) Regarding the Authorship and the Titles of the Documentation: Sorry about that :-) I failed to edit my copy-pastes :-) Thanks, Franz review plugin documentation --- Key: MCLOVER-47 URL: http://jira.codehaus.org/browse/MCLOVER-47 Project: Maven 2.x Clover Plugin Issue Type: Task Affects Versions: 2.2 Reporter: John Tolentino Assigned To: Vincent Massol Fix For: 2.3 Attachments: MCLOVER-47-maven-clover-plugin.patch http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation -- 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: (MCLOVER-47) review plugin documentation
[ http://jira.codehaus.org/browse/MCLOVER-47?page=all ] Franz Allan Valencia See updated MCLOVER-47: Attachment: MCLOVER-47-maven-clover-plugin-2.patch Changes in MCLOVER-47-maven-clover-plugin-2.patch: * Revised MCLOVER-47-maven-clover-plugin.patch so that it will work with commit 440599. * Included Vicent Massol in the Authorship of the Documentataions. * Wrote the proper documentation tiles. * Changed How to Use to Usage ...hopefully, I got it right this time :-) review plugin documentation --- Key: MCLOVER-47 URL: http://jira.codehaus.org/browse/MCLOVER-47 Project: Maven 2.x Clover Plugin Issue Type: Task Affects Versions: 2.2 Reporter: John Tolentino Assigned To: Vincent Massol Fix For: 2.3 Attachments: MCLOVER-47-maven-clover-plugin-2.patch, MCLOVER-47-maven-clover-plugin.patch http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation -- 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
