[jira] Commented: (SCM-558) Add support for 'mkdir' command
[ http://jira.codehaus.org/browse/SCM-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=244246#action_244246 ] Maria Odea Ching commented on SCM-558: -- Nothing more to do here Olivier. Thanks! Add support for 'mkdir' command --- Key: SCM-558 URL: http://jira.codehaus.org/browse/SCM-558 Project: Maven SCM Issue Type: New Feature Components: maven-scm-api Reporter: Maria Odea Ching Assignee: Maria Odea Ching -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-558) Add support for 'mkdir' command
[ http://jira.codehaus.org/browse/SCM-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated SCM-558: - Fix Version/s: 1.5 Add support for 'mkdir' command --- Key: SCM-558 URL: http://jira.codehaus.org/browse/SCM-558 Project: Maven SCM Issue Type: New Feature Components: maven-scm-api Reporter: Maria Odea Ching Assignee: Maria Odea Ching Fix For: 1.5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-558) Add support for 'mkdir' command
[ http://jira.codehaus.org/browse/SCM-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed SCM-558. Resolution: Fixed Resolving as fixed for version 1.5. Add support for 'mkdir' command --- Key: SCM-558 URL: http://jira.codehaus.org/browse/SCM-558 Project: Maven SCM Issue Type: New Feature Components: maven-scm-api Reporter: Maria Odea Ching Assignee: Maria Odea Ching Fix For: 1.5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-46) mvn -DaltDeploymentRepository=... deploy of a SNAPSHOT doesn't replace date.buildnumber
[ http://jira.codehaus.org/browse/MDEPLOY-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=233858#action_233858 ] Maria Odea Ching commented on MDEPLOY-46: - This seems to be fixed in 2.5. Please verify so we can close this issue. mvn -DaltDeploymentRepository=... deploy of a SNAPSHOT doesn't replace date.buildnumber -- Key: MDEPLOY-46 URL: http://jira.codehaus.org/browse/MDEPLOY-46 Project: Maven 2.x Deploy Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Geoffrey De Smet Attachments: MDEPLOY-46.patch I 've checkouted a m2 project (spring-richclient) and deployed it to my local repo using the altDeploymentRepository parameter (from MDEPLOY-41). But the checkout is a SNAPSHOT version and the deployer should replace it with something like spring-richclient-core-0.3.0-20070101.160450-2.jar like the mvn deploy without altDeploymentRepository does, but it doesn't: [INFO] [deploy:deploy] altDeploymentRepository = ggg-dev::default::scp://mvn.ggg.be/maven/maven2/dev [INFO] Using alternate deployment repository ggg-dev::default::scp://mvn.ggg.be/maven/maven2/dev [INFO] Retrieving previous build number from ggg-dev Uploading: scp://mvn.ggg.be/maven/maven2/dev/org/springframework/richclient/spring-richclient-core/0.3.0-SNAPSHOT/spring-richclient-core-0.3.0-SNAPSHOT.jar 50K uploaded -- 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: (WAGON-297) Wagon SCM does not automatically create missing directories during deployment
[ http://jira.codehaus.org/browse/WAGON-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated WAGON-297: --- Attachment: WAGON-297.patch Attached the updated patch. Instead of checking out the entire root tree, it utilizes the SCM mkdir command instead (implemented in SCM-558). Please take note that I upgraded the maven-scm APIs to 1.4-SNAPSHOT so we can use the SCM mkdir command. Wagon SCM does not automatically create missing directories during deployment - Key: WAGON-297 URL: http://jira.codehaus.org/browse/WAGON-297 Project: Maven Wagon Issue Type: Bug Components: wagon-scm Affects Versions: 1.0-beta-6 Reporter: Maria Odea Ching Attachments: WAGON-297.patch, WAGON-297.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-558) Add support for 'mkdir' command
[ http://jira.codehaus.org/browse/SCM-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=226136#action_226136 ] Maria Odea Ching commented on SCM-558: -- Added mkdir implementation for SCM local provider in maven-scm trunk [-r957146|http://svn.apache.org/viewvc?revision=957146view=revision]. I also added a test case when the directory to be created already exists in the repo for SVN SCM provider. Add support for 'mkdir' command --- Key: SCM-558 URL: http://jira.codehaus.org/browse/SCM-558 Project: Maven SCM Issue Type: New Feature Components: maven-scm-api Reporter: Maria Odea Ching Assignee: Maria Odea Ching -- 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-558) Add support for 'mkdir' command
[ http://jira.codehaus.org/browse/SCM-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=226041#action_226041 ] Maria Odea Ching commented on SCM-558: -- Hi Grant, for the other providers, the mkdir command is simply just add. But for SVN provider, you can run mkdir in two ways: * svn mkdir [DIRNAME] * svn mkdir [REPO URL] The related wagon-scm issue is for deploying documentation to a SCM repository. The case there is when the specified path does not exist, the deploying fails. So what we wanted to do was create the missing directory paths first. In cases when the provider is SVN, we want to utilize the 'svn mkdir [REPO URL]' command so that there's no need to checkout the entire source tree just to create the directories. For the other SCM providers, I don't think there's an equivalent for 'svn mkdir [REPO URL]' (only for 'svn mkdir [DIRNAME]' to create/add dir in working copy has an equivalent) so what I did with the CVS implementation for the mkdir command is to just invoke the the CVS Add command from within. I'm still fixing some tests and I'll commit it later if you can take a look. Add support for 'mkdir' command --- Key: SCM-558 URL: http://jira.codehaus.org/browse/SCM-558 Project: Maven SCM Issue Type: New Feature Components: maven-scm-api Reporter: Maria Odea Ching Assignee: Maria Odea Ching -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SCM-558) Add support for 'mkdir' command
[ http://jira.codehaus.org/browse/SCM-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=226041#action_226041 ] Maria Odea Ching edited comment on SCM-558 at 6/22/10 1:21 AM: --- Hi Grant, for the other providers, the mkdir command is simply just add. But for SVN provider, you can run mkdir in two ways: * svn mkdir [DIRNAME] * svn mkdir [REPO URL] The related wagon-scm issue is for deploying documentation to a SCM repository. The case there is when the specified path does not exist, the deployment fails. So what we wanted to do was create the missing directory paths first. In cases when the provider is SVN, we want to utilize the 'svn mkdir [REPO URL]' command so that there's no need to checkout the entire source tree just to create the directories. For the other SCM providers, I don't think there's an equivalent for 'svn mkdir [REPO URL]' (only for 'svn mkdir [DIRNAME]' to create/add dir in working copy has an equivalent) so what I did with the CVS implementation for the mkdir command is to just invoke the the CVS Add command from within. I'm still fixing some tests and I'll commit it later if you can take a look. was (Author: oching): Hi Grant, for the other providers, the mkdir command is simply just add. But for SVN provider, you can run mkdir in two ways: * svn mkdir [DIRNAME] * svn mkdir [REPO URL] The related wagon-scm issue is for deploying documentation to a SCM repository. The case there is when the specified path does not exist, the deploying fails. So what we wanted to do was create the missing directory paths first. In cases when the provider is SVN, we want to utilize the 'svn mkdir [REPO URL]' command so that there's no need to checkout the entire source tree just to create the directories. For the other SCM providers, I don't think there's an equivalent for 'svn mkdir [REPO URL]' (only for 'svn mkdir [DIRNAME]' to create/add dir in working copy has an equivalent) so what I did with the CVS implementation for the mkdir command is to just invoke the the CVS Add command from within. I'm still fixing some tests and I'll commit it later if you can take a look. Add support for 'mkdir' command --- Key: SCM-558 URL: http://jira.codehaus.org/browse/SCM-558 Project: Maven SCM Issue Type: New Feature Components: maven-scm-api Reporter: Maria Odea Ching Assignee: Maria Odea Ching -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SCM-558) Add support for 'mkdir' command
[ http://jira.codehaus.org/browse/SCM-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=226041#action_226041 ] Maria Odea Ching edited comment on SCM-558 at 6/22/10 1:21 AM: --- Hi Grant, for the other providers, the mkdir command is simply just add. But for SVN provider, you can run mkdir in two ways: * svn mkdir [DIRNAME] * svn mkdir [REPO URL] The related wagon-scm issue is for deploying documentation to a SCM repository. The case there is when the specified path does not exist, the deployment fails. So what we wanted to do was create the missing directory paths first. In cases when the provider is SVN, we want to utilize the 'svn mkdir [REPO URL]' command so that there's no need to checkout the entire source tree just to create the directories. For the other SCM providers, I don't think there's an equivalent for 'svn mkdir [REPO URL]' (only for 'svn mkdir [DIRNAME]' to create/add dir in working copy has an equivalent) so what I did with the CVS implementation for the mkdir command is to just invoke the the CVS Add command from within. I'm still fixing some tests and I'll commit it later if you want to take a look. was (Author: oching): Hi Grant, for the other providers, the mkdir command is simply just add. But for SVN provider, you can run mkdir in two ways: * svn mkdir [DIRNAME] * svn mkdir [REPO URL] The related wagon-scm issue is for deploying documentation to a SCM repository. The case there is when the specified path does not exist, the deployment fails. So what we wanted to do was create the missing directory paths first. In cases when the provider is SVN, we want to utilize the 'svn mkdir [REPO URL]' command so that there's no need to checkout the entire source tree just to create the directories. For the other SCM providers, I don't think there's an equivalent for 'svn mkdir [REPO URL]' (only for 'svn mkdir [DIRNAME]' to create/add dir in working copy has an equivalent) so what I did with the CVS implementation for the mkdir command is to just invoke the the CVS Add command from within. I'm still fixing some tests and I'll commit it later if you can take a look. Add support for 'mkdir' command --- Key: SCM-558 URL: http://jira.codehaus.org/browse/SCM-558 Project: Maven SCM Issue Type: New Feature Components: maven-scm-api Reporter: Maria Odea Ching Assignee: Maria Odea Ching -- 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-558) Add support for 'mkdir' command
[ http://jira.codehaus.org/browse/SCM-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=226058#action_226058 ] Maria Odea Ching commented on SCM-558: -- Implementation for CVS Exe committed to trunk [-r956796|http://svn.apache.org/viewvc?revision=956796view=revision]. I also moved the tck test for creating a dir directly in the scm repo url to SVN mkdir tck test since it is only applicable there. Add support for 'mkdir' command --- Key: SCM-558 URL: http://jira.codehaus.org/browse/SCM-558 Project: Maven SCM Issue Type: New Feature Components: maven-scm-api Reporter: Maria Odea Ching Assignee: Maria Odea Ching -- 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-558) Add support for 'mkdir' command
[ http://jira.codehaus.org/browse/SCM-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=226062#action_226062 ] Maria Odea Ching commented on SCM-558: -- Implementation of mkdir command for cvsjava committed to trunk [-r956830|http://svn.apache.org/viewvc?revision=956830view=revision]. Add support for 'mkdir' command --- Key: SCM-558 URL: http://jira.codehaus.org/browse/SCM-558 Project: Maven SCM Issue Type: New Feature Components: maven-scm-api Reporter: Maria Odea Ching Assignee: Maria Odea Ching -- 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-558) Add support for 'mkdir' command
[ http://jira.codehaus.org/browse/SCM-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=225942#action_225942 ] Maria Odea Ching commented on SCM-558: -- Additional changes to SVN implementation of mkdir command committed to trunk [-r956487|http://svn.apache.org/viewvc?revision=956487view=revision]: * add parameter to specify whether 'mkdir' should be executed in local path or in repo URL * added tests for creating a directory in working dir * execute mkdir tck test from svnexe module Add support for 'mkdir' command --- Key: SCM-558 URL: http://jira.codehaus.org/browse/SCM-558 Project: Maven SCM Issue Type: New Feature Components: maven-scm-api Reporter: Maria Odea Ching Assignee: Maria Odea Ching -- 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-558) Add support for 'mkdir' command
[ http://jira.codehaus.org/browse/SCM-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=225923#action_225923 ] Maria Odea Ching commented on SCM-558: -- Thanks Olivier! I don't seem to be subscribed to maven scm commit notifications so I didn't see the commits. Subscribing now.. :) Add support for 'mkdir' command --- Key: SCM-558 URL: http://jira.codehaus.org/browse/SCM-558 Project: Maven SCM Issue Type: New Feature Components: maven-scm-api Reporter: Maria Odea Ching Assignee: Maria Odea Ching -- 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-558) Add support for 'mkdir' command
[ http://jira.codehaus.org/browse/SCM-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=225898#action_225898 ] Maria Odea Ching commented on SCM-558: -- Yes, I have yet to implement the command for the other SCM providers. Thanks for pointing out the revision, I'll change it to a SCMRevision instead. Add support for 'mkdir' command --- Key: SCM-558 URL: http://jira.codehaus.org/browse/SCM-558 Project: Maven SCM Issue Type: New Feature Components: maven-scm-api Reporter: Maria Odea Ching Assignee: Maria Odea Ching -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-558) Add support for 'mkdir' command
[ http://jira.codehaus.org/browse/SCM-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated SCM-558: - Assignee: Maria Odea Ching Add support for 'mkdir' command --- Key: SCM-558 URL: http://jira.codehaus.org/browse/SCM-558 Project: Maven SCM Issue Type: New Feature Components: maven-scm-api Reporter: Maria Odea Ching Assignee: Maria Odea Ching -- 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-558) Add support for 'mkdir' command
[ http://jira.codehaus.org/browse/SCM-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=225571#action_225571 ] Maria Odea Ching commented on SCM-558: -- Committed in trunk [-r955486|http://svn.apache.org/viewvc?revision=955486view=revision] with the following changes: * added mkdir command to scm api * implement mkdir in SVN scm provider * added unit tests and tck tests for svn mkdir command Add support for 'mkdir' command --- Key: SCM-558 URL: http://jira.codehaus.org/browse/SCM-558 Project: Maven SCM Issue Type: New Feature Components: maven-scm-api Reporter: Maria Odea Ching Assignee: Maria Odea Ching -- 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: (WAGON-297) Wagon SCM does not automatically create missing directories during deployment
[ http://jira.codehaus.org/browse/WAGON-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=225314#action_225314 ] Maria Odea Ching commented on WAGON-297: Hi Brett, I checked the SCM API code and currently there's no implementation for the mkdir command. I'll file a separate issue for that in Maven SCM jira and add an implementation of that command so we can use it for wagon SCM. Wagon SCM does not automatically create missing directories during deployment - Key: WAGON-297 URL: http://jira.codehaus.org/browse/WAGON-297 Project: Maven Wagon Issue Type: Bug Components: wagon-scm Affects Versions: 1.0-beta-6 Reporter: Maria Odea Ching Attachments: WAGON-297.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-558) Add support for
Add support for Key: SCM-558 URL: http://jira.codehaus.org/browse/SCM-558 Project: Maven SCM Issue Type: New Feature Reporter: Maria Odea Ching -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-558) Add support for 'mkdir' command
[ http://jira.codehaus.org/browse/SCM-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated SCM-558: - Component/s: maven-scm-api Summary: Add support for 'mkdir' command (was: Add support for ) Add support for 'mkdir' command --- Key: SCM-558 URL: http://jira.codehaus.org/browse/SCM-558 Project: Maven SCM Issue Type: New Feature Components: maven-scm-api Reporter: Maria Odea Ching -- 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: (WAGON-297) Wagon SCM does not automatically create missing directories during deployment
[ http://jira.codehaus.org/browse/WAGON-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=208796#action_208796 ] Maria Odea Ching commented on WAGON-297: {quote} * the multiple levels of try/catch is a bit scary {quote} I'll see what else I can do about this. {quote} * the checkOut call that fails with a TransferFailedException seems to be called identically after calculating the missing directories. Am I misreading it? {quote} Yes, it's being called again but this time using the base scm url (where the missing directories will be added). The TransferFailedException is the one thrown when the checkout fails because of the missing directory. {quote} * it might be nice to have a block comment that explains what happens (are the directories added in the local checkout, created, remotely, etc? Is it checking out a new base directory higher up to create the directories?) {quote} Ok, I'll add a block comment for what it does. {quote} * also, you want to make sure you don't start creating directories within the original supplied URL - wagon doesn't do that, only create those that it tries to put within that. {quote} That's what the patch does.. it only creates the missing directories where it tried to deploy. For example: the deployment site url is http://svn.example.com/repos/myproject/www/docs/${project.version} whereas docs/${project.version} does not exist yet, with this patch, what will be created will be starting from the docs directory. Is this what you meant? {quote} Separately - is the test case one that is valid across all the providers? Maybe it can be pushed up to the abstract class? {quote} I'll see if I can move this up to the abstract class as I just based it on the existing test case for ScmSvnExeWagonTest. Wagon SCM does not automatically create missing directories during deployment - Key: WAGON-297 URL: http://jira.codehaus.org/browse/WAGON-297 Project: Maven Wagon Issue Type: Bug Components: wagon-scm Affects Versions: 1.0-beta-6 Reporter: Maria Odea Ching Attachments: WAGON-297.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WAGON-297) Wagon SCM does not automatically create missing directories during deployment
Wagon SCM does not automatically create missing directories during deployment - Key: WAGON-297 URL: http://jira.codehaus.org/browse/WAGON-297 Project: Maven Wagon Issue Type: Bug Components: wagon-scm Affects Versions: 1.0-beta-6 Reporter: Maria Odea Ching -- 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: (WAGON-297) Wagon SCM does not automatically create missing directories during deployment
[ http://jira.codehaus.org/browse/WAGON-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated WAGON-297: --- Attachment: WAGON-297.patch The attached patch automatically creates the missing directory when put(...) or putDirectory(...) is executed for wagon-scm. A unit test is also provided. Can someone kindly review this first before I commit them to SVN? Thanks.. Wagon SCM does not automatically create missing directories during deployment - Key: WAGON-297 URL: http://jira.codehaus.org/browse/WAGON-297 Project: Maven Wagon Issue Type: Bug Components: wagon-scm Affects Versions: 1.0-beta-6 Reporter: Maria Odea Ching Attachments: WAGON-297.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-511) Build error when publishing a new version of the site through the command line. Error: Embedded error: Unable to commit file. The svn command failed. svn: URL '----------'
[ http://jira.codehaus.org/browse/SCM-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=206173#action_206173 ] Maria Odea Ching commented on SCM-511: -- Attached patch in WAGON-297 to fix this problem (if not using Subversion 1.5+ which is related to SCM-487). Build error when publishing a new version of the site through the command line. Error: Embedded error: Unable to commit file. The svn command failed. svn: URL '--' doesn't exist -- Key: SCM-511 URL: http://jira.codehaus.org/browse/SCM-511 Project: Maven SCM Issue Type: Bug Components: maven-scm-site Environment: Command line, Java Reporter: Rolan Sanchez Priority: Minor In declaring interdependencies by referencing project properties e.g., reports/${project.groupId}/${project.artifactId}/${project.version} if a newer version of the site is created and then if try to publish it to SVN, Maven cannot create the parent directory. Since the parent directory does not exist in SVN, Maven does not automatically create and publish site to SVN and an error is thrown: Embedded error: Unable to commit file. The svn command failed. svn: URL 'https:///svn/../trunk/www//com.ears//1.0.2-SNAPSHOT/.' doesn't exist. Maven expects at least parent directory to be created manually in order to publish the site before the build. Instead the Directory creation for the newer version should be automatic. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (WAGON-297) Wagon SCM does not automatically create missing directories during deployment
[ http://jira.codehaus.org/browse/WAGON-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=206171#action_206171 ] Maria Odea Ching edited comment on WAGON-297 at 1/11/10 2:45 AM: - The attached patch automatically creates the missing directory/directories when put(...) or putDirectory(...) is executed for wagon-scm. A unit test is also provided. Can someone kindly review this first before I commit them to SVN? Thanks.. was (Author: oching): The attached patch automatically creates the missing directory when put(...) or putDirectory(...) is executed for wagon-scm. A unit test is also provided. Can someone kindly review this first before I commit them to SVN? Thanks.. Wagon SCM does not automatically create missing directories during deployment - Key: WAGON-297 URL: http://jira.codehaus.org/browse/WAGON-297 Project: Maven Wagon Issue Type: Bug Components: wagon-scm Affects Versions: 1.0-beta-6 Reporter: Maria Odea Ching Attachments: WAGON-297.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-511) Build error when publishing a new version of the site through the command line. Error: Embedded error: Unable to commit file. The svn command failed. svn: URL '----------'
[ http://jira.codehaus.org/browse/SCM-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=205346#action_205346 ] Maria Odea Ching commented on SCM-511: -- This error occurs in versions 1.1 and lower of maven-scm-manager-plexus and maven-scm-provider-svnexe. A different error related to plexus-utils occurs instead for version 1.2 and 1.3-SNAPSHOT. Build error when publishing a new version of the site through the command line. Error: Embedded error: Unable to commit file. The svn command failed. svn: URL '--' doesn't exist -- Key: SCM-511 URL: http://jira.codehaus.org/browse/SCM-511 Project: Maven SCM Issue Type: Bug Components: maven-scm-site Environment: Command line, Java Reporter: Rolan Sanchez Priority: Minor In declaring interdependencies by referencing project properties e.g., reports/${project.groupId}/${project.artifactId}/${project.version} if a newer version of the site is created and then if try to publish it to SVN, Maven cannot create the parent directory. Since the parent directory does not exist in SVN, Maven does not automatically create and publish site to SVN and an error is thrown: Embedded error: Unable to commit file. The svn command failed. svn: URL 'https:///svn/../trunk/www//com.ears//1.0.2-SNAPSHOT/.' doesn't exist. Maven expects at least parent directory to be created manually in order to publish the site before the build. Instead the Directory creation for the newer version should be automatic. -- 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-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching reopened MRELEASE-261: --- Re-opened issue due to last comment. release:prepare shouls support flat directory multimodule projects -- Key: MRELEASE-261 URL: http://jira.codehaus.org/browse/MRELEASE-261 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Environment: linux / maven2 / svn Reporter: paul.whe...@gmail.com Assignee: Maria Odea Ching Fix For: 2.0-beta-10 Attachments: flatProject.main.patch, flatProject.test.patch, maven-release-issue.tar.gz, MRELEASE-261-with-its-v3.patch, MRELEASE-261-with-its.patch, MRELEASE-261.patch, PrepareReleaseMojo.patch What I mean by flat file structure firstly. parent/pom.xml module1/pom.xml module2/pom.xml . . . module15/pom.xml the parent references the modules like so modules module../module1/module module../module2/module . . . module../module15/module /modules When i release:prepare only the parent project is tagged the modules projects versions are incremented etc but the modules are not tagged in svn. I use this structure as i use eclipse as my IDE. I would love to see a fix for the issue marked as closed here http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand each submodule of the projects but it would be so nice to have the release plugin do this for me. forgive my english. -- 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: (MSHADE-58) Add sample configuration for AppendingTransformer in docs
Add sample configuration for AppendingTransformer in docs - Key: MSHADE-58 URL: http://jira.codehaus.org/browse/MSHADE-58 Project: Maven 2.x Shade Plugin Issue Type: Improvement Reporter: Maria Odea Ching -- 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: (MSHADE-58) Add sample configuration for AppendingTransformer in docs
[ http://jira.codehaus.org/browse/MSHADE-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MSHADE-58: --- Assignee: Maria Odea Ching Fix Version/s: 1.2.2 Add sample configuration for AppendingTransformer in docs - Key: MSHADE-58 URL: http://jira.codehaus.org/browse/MSHADE-58 Project: Maven 2.x Shade Plugin Issue Type: Improvement Reporter: Maria Odea Ching Assignee: Maria Odea Ching Fix For: 1.2.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] Closed: (MSHADE-58) Add sample configuration for AppendingTransformer in docs
[ http://jira.codehaus.org/browse/MSHADE-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MSHADE-58. -- Resolution: Fixed Fixed in trunk -r798819. Add sample configuration for AppendingTransformer in docs - Key: MSHADE-58 URL: http://jira.codehaus.org/browse/MSHADE-58 Project: Maven 2.x Shade Plugin Issue Type: Improvement Reporter: Maria Odea Ching Assignee: Maria Odea Ching Fix For: 1.2.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] Closed: (MNG-4189) Maven not picking up specific timestamped version dependency when a later timestamped version was downloaded and already present in the local repository
[ http://jira.codehaus.org/browse/MNG-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MNG-4189. - Resolution: Fixed Fix Version/s: (was: 2.2.x) 2.1.1 Fix committed in 2.1.x branch -r788583 and merged to 2.2.x branch -r788596. Integration tests committed in core-integration-testing trunk -r788584. Maven not picking up specific timestamped version dependency when a later timestamped version was downloaded and already present in the local repository Key: MNG-4189 URL: http://jira.codehaus.org/browse/MNG-4189 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories, General Affects Versions: 2.0.9, 2.1.0 Reporter: Maria Odea Ching Assignee: Maria Odea Ching Fix For: 2.1.1 Attachments: MNG-4189-core-integration-testing.patch, MNG-4189-maven-2.1.x.patch, MNG-4189.patch, mng-4189.zip To reproduce this issue: # Create a project (let's call this projectA) with a class named ClassA having a method named methodA(). Set the version as 1.0-SNAPSHOT and set uniqueVersion=true. # Deploy this in a remote repository # Create another project (let's call this projectB) which has a dependency on projectA. Set the dependency's version to the specific timestamped version when projectA was deployed in step 2. Create a class named ClassB and add a method which invokes ClassA's methodA(). # Add your remote repository either in the settings or in the pom. # Build projectB. You will get a successful build. # Now go back to projectA and remove methodA() from classA. # Deploy projectA to the remote repository again. # Update the dependency version of projectA in projectB's pom.xml. Set it to the latest timestamp version. # Build projectB. Your build will fail because methodA() was removed. # Revert the dependency version of projectA in projectB's pom.xml. Set it to the same value you've set in step 3. # Build projectB. Your build will still fail even though you've set the correct version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4189) Maven not picking up specific timestamped version dependency when a later timestamped version was downloaded and already present in the local repository
[ http://jira.codehaus.org/browse/MNG-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=180023#action_180023 ] Maria Odea Ching commented on MNG-4189: --- Ok, thanks for reviewing them Benjamin. I'll update the patches. Should I merge this to 2.2.x branch as well after I commit it to 2.1.x branch? Maven not picking up specific timestamped version dependency when a later timestamped version was downloaded and already present in the local repository Key: MNG-4189 URL: http://jira.codehaus.org/browse/MNG-4189 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories, General Affects Versions: 2.0.9, 2.1.0 Reporter: Maria Odea Ching Assignee: Maria Odea Ching Attachments: MNG-4189-core-integration-testing.patch, MNG-4189-maven-2.1.x.patch, MNG-4189.patch, mng-4189.zip To reproduce this issue: # Create a project (let's call this projectA) with a class named ClassA having a method named methodA(). Set the version as 1.0-SNAPSHOT and set uniqueVersion=true. # Deploy this in a remote repository # Create another project (let's call this projectB) which has a dependency on projectA. Set the dependency's version to the specific timestamped version when projectA was deployed in step 2. Create a class named ClassB and add a method which invokes ClassA's methodA(). # Add your remote repository either in the settings or in the pom. # Build projectB. You will get a successful build. # Now go back to projectA and remove methodA() from classA. # Deploy projectA to the remote repository again. # Update the dependency version of projectA in projectB's pom.xml. Set it to the latest timestamp version. # Build projectB. Your build will fail because methodA() was removed. # Revert the dependency version of projectA in projectB's pom.xml. Set it to the same value you've set in step 3. # Build projectB. Your build will still fail even though you've set the correct version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4189) Maven not picking up specific timestamped version dependency when a later timestamped version was downloaded and already present in the local repository
[ http://jira.codehaus.org/browse/MNG-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MNG-4189: -- Attachment: MNG-4189-core-integration-testing.patch Attaching patch for core-integration-testing integrating the IT test for this issue.. Maven not picking up specific timestamped version dependency when a later timestamped version was downloaded and already present in the local repository Key: MNG-4189 URL: http://jira.codehaus.org/browse/MNG-4189 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories, General Affects Versions: 2.0.9, 2.1.0 Reporter: Maria Odea Ching Assignee: Maria Odea Ching Attachments: MNG-4189-core-integration-testing.patch, mng-4189.zip To reproduce this issue: # Create a project (let's call this projectA) with a class named ClassA having a method named methodA(). Set the version as 1.0-SNAPSHOT and set uniqueVersion=true. # Deploy this in a remote repository # Create another project (let's call this projectB) which has a dependency on projectA. Set the dependency's version to the specific timestamped version when projectA was deployed in step 2. Create a class named ClassB and add a method which invokes ClassA's methodA(). # Add your remote repository either in the settings or in the pom. # Build projectB. You will get a successful build. # Now go back to projectA and remove methodA() from classA. # Deploy projectA to the remote repository again. # Update the dependency version of projectA in projectB's pom.xml. Set it to the latest timestamp version. # Build projectB. Your build will fail because methodA() was removed. # Revert the dependency version of projectA in projectB's pom.xml. Set it to the same value you've set in step 3. # Build projectB. Your build will still fail even though you've set the correct version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4189) Maven not picking up specific timestamped version dependency when a later timestamped version was downloaded and already present in the local repository
[ http://jira.codehaus.org/browse/MNG-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MNG-4189: -- Attachment: MNG-4189-maven-2.1.x.patch Attaching MNG-4189-maven-2.1.x.patch to fix this issue. Unit tests included in the patch. Could someone please review this before I commit it to trunk? Maven not picking up specific timestamped version dependency when a later timestamped version was downloaded and already present in the local repository Key: MNG-4189 URL: http://jira.codehaus.org/browse/MNG-4189 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories, General Affects Versions: 2.0.9, 2.1.0 Reporter: Maria Odea Ching Assignee: Maria Odea Ching Attachments: MNG-4189-core-integration-testing.patch, MNG-4189-maven-2.1.x.patch, mng-4189.zip To reproduce this issue: # Create a project (let's call this projectA) with a class named ClassA having a method named methodA(). Set the version as 1.0-SNAPSHOT and set uniqueVersion=true. # Deploy this in a remote repository # Create another project (let's call this projectB) which has a dependency on projectA. Set the dependency's version to the specific timestamped version when projectA was deployed in step 2. Create a class named ClassB and add a method which invokes ClassA's methodA(). # Add your remote repository either in the settings or in the pom. # Build projectB. You will get a successful build. # Now go back to projectA and remove methodA() from classA. # Deploy projectA to the remote repository again. # Update the dependency version of projectA in projectB's pom.xml. Set it to the latest timestamp version. # Build projectB. Your build will fail because methodA() was removed. # Revert the dependency version of projectA in projectB's pom.xml. Set it to the same value you've set in step 3. # Build projectB. Your build will still fail even though you've set the correct 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] Issue Comment Edited: (MNG-4189) Maven not picking up specific timestamped version dependency when a later timestamped version was downloaded and already present in the local repository
[ http://jira.codehaus.org/browse/MNG-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=179761#action_179761 ] Maria Odea Ching edited comment on MNG-4189 at 6/9/09 5:57 AM: --- Attaching MNG-4189-maven-2.1.x.patch to fix this issue. Unit tests included in the patch. Could someone please review this before I commit it to 2.1.x branch? Thanks in advance! was (Author: oching): Attaching MNG-4189-maven-2.1.x.patch to fix this issue. Unit tests included in the patch. Could someone please review this before I commit it to trunk? Maven not picking up specific timestamped version dependency when a later timestamped version was downloaded and already present in the local repository Key: MNG-4189 URL: http://jira.codehaus.org/browse/MNG-4189 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories, General Affects Versions: 2.0.9, 2.1.0 Reporter: Maria Odea Ching Assignee: Maria Odea Ching Attachments: MNG-4189-core-integration-testing.patch, MNG-4189-maven-2.1.x.patch, mng-4189.zip To reproduce this issue: # Create a project (let's call this projectA) with a class named ClassA having a method named methodA(). Set the version as 1.0-SNAPSHOT and set uniqueVersion=true. # Deploy this in a remote repository # Create another project (let's call this projectB) which has a dependency on projectA. Set the dependency's version to the specific timestamped version when projectA was deployed in step 2. Create a class named ClassB and add a method which invokes ClassA's methodA(). # Add your remote repository either in the settings or in the pom. # Build projectB. You will get a successful build. # Now go back to projectA and remove methodA() from classA. # Deploy projectA to the remote repository again. # Update the dependency version of projectA in projectB's pom.xml. Set it to the latest timestamp version. # Build projectB. Your build will fail because methodA() was removed. # Revert the dependency version of projectA in projectB's pom.xml. Set it to the same value you've set in step 3. # Build projectB. Your build will still fail even though you've set the correct version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4189) Maven not picking up specific timestamped version dependency when a later timestamped version was downloaded and already present in the local repository
[ http://jira.codehaus.org/browse/MNG-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MNG-4189: -- Affects Version/s: 2.0.9 Maven not picking up specific timestamped version dependency when a later timestamped version was downloaded and already present in the local repository Key: MNG-4189 URL: http://jira.codehaus.org/browse/MNG-4189 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories, General Affects Versions: 2.0.9, 2.1.0 Reporter: Maria Odea Ching To reproduce this issue: # Create a project (let's call this projectA) with a class named ClassA having a method named methodA(). Set the version as 1.0-SNAPSHOT and set uniqueVersion=true. # Deploy this in a remote repository # Create another project (let's call this projectB) which has a dependency on projectA. Set the dependency's version to the specific timestamped version when projectA was deployed in step 2. Create a class named ClassB and add a method which invokes ClassA's methodA(). # Add your remote repository either in the settings or in the pom. # Build projectB. You will get a successful build. # Now go back to projectA and remove methodA() from classA. # Deploy projectA to the remote repository again. # Update the dependency version of projectA in projectB's pom.xml. Set it to the latest timestamp version. # Build projectB. Your build will fail because methodA() was removed. # Revert the dependency version of projectA in projectB's pom.xml. Set it to the same value you've set in step 3. # Build projectB. Your build will still fail even though you've set the correct 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] Created: (MNG-4189) Maven not picking up specific timestamped version dependency when a later timestamped version was downloaded and already present in the local repository
Maven not picking up specific timestamped version dependency when a later timestamped version was downloaded and already present in the local repository Key: MNG-4189 URL: http://jira.codehaus.org/browse/MNG-4189 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories, General Affects Versions: 2.1.0 Reporter: Maria Odea Ching To reproduce this issue: # Create a project (let's call this projectA) with a class named ClassA having a method named methodA(). Set the version as 1.0-SNAPSHOT and set uniqueVersion=true. # Deploy this in a remote repository # Create another project (let's call this projectB) which has a dependency on projectA. Set the dependency's version to the specific timestamped version when projectA was deployed in step 2. Create a class named ClassB and add a method which invokes ClassA's methodA(). # Add your remote repository either in the settings or in the pom. # Build projectB. You will get a successful build. # Now go back to projectA and remove methodA() from classA. # Deploy projectA to the remote repository again. # Update the dependency version of projectA in projectB's pom.xml. Set it to the latest timestamp version. # Build projectB. Your build will fail because methodA() was removed. # Revert the dependency version of projectA in projectB's pom.xml. Set it to the same value you've set in step 3. # Build projectB. Your build will still fail even though you've set the correct version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4189) Maven not picking up specific timestamped version dependency when a later timestamped version was downloaded and already present in the local repository
[ http://jira.codehaus.org/browse/MNG-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=179575#action_179575 ] Maria Odea Ching commented on MNG-4189: --- I'm still creating an IT for this, will attach it to this jira issue once completed.. Maven not picking up specific timestamped version dependency when a later timestamped version was downloaded and already present in the local repository Key: MNG-4189 URL: http://jira.codehaus.org/browse/MNG-4189 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories, General Affects Versions: 2.0.9, 2.1.0 Reporter: Maria Odea Ching To reproduce this issue: # Create a project (let's call this projectA) with a class named ClassA having a method named methodA(). Set the version as 1.0-SNAPSHOT and set uniqueVersion=true. # Deploy this in a remote repository # Create another project (let's call this projectB) which has a dependency on projectA. Set the dependency's version to the specific timestamped version when projectA was deployed in step 2. Create a class named ClassB and add a method which invokes ClassA's methodA(). # Add your remote repository either in the settings or in the pom. # Build projectB. You will get a successful build. # Now go back to projectA and remove methodA() from classA. # Deploy projectA to the remote repository again. # Update the dependency version of projectA in projectB's pom.xml. Set it to the latest timestamp version. # Build projectB. Your build will fail because methodA() was removed. # Revert the dependency version of projectA in projectB's pom.xml. Set it to the same value you've set in step 3. # Build projectB. Your build will still fail even though you've set the correct version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4189) Maven not picking up specific timestamped version dependency when a later timestamped version was downloaded and already present in the local repository
[ http://jira.codehaus.org/browse/MNG-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MNG-4189: -- Attachment: mng-4189.zip Attaching IT for this bug.. Maven not picking up specific timestamped version dependency when a later timestamped version was downloaded and already present in the local repository Key: MNG-4189 URL: http://jira.codehaus.org/browse/MNG-4189 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories, General Affects Versions: 2.0.9, 2.1.0 Reporter: Maria Odea Ching Attachments: mng-4189.zip To reproduce this issue: # Create a project (let's call this projectA) with a class named ClassA having a method named methodA(). Set the version as 1.0-SNAPSHOT and set uniqueVersion=true. # Deploy this in a remote repository # Create another project (let's call this projectB) which has a dependency on projectA. Set the dependency's version to the specific timestamped version when projectA was deployed in step 2. Create a class named ClassB and add a method which invokes ClassA's methodA(). # Add your remote repository either in the settings or in the pom. # Build projectB. You will get a successful build. # Now go back to projectA and remove methodA() from classA. # Deploy projectA to the remote repository again. # Update the dependency version of projectA in projectB's pom.xml. Set it to the latest timestamp version. # Build projectB. Your build will fail because methodA() was removed. # Revert the dependency version of projectA in projectB's pom.xml. Set it to the same value you've set in step 3. # Build projectB. Your build will still fail even though you've set the correct version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=177892#action_177892 ] Maria Odea Ching commented on MRELEASE-261: --- Additional fix for determining the common path which was failing in windows was committed to trunk -r778269. release:prepare shouls support flat directory multimodule projects -- Key: MRELEASE-261 URL: http://jira.codehaus.org/browse/MRELEASE-261 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Environment: linux / maven2 / svn Reporter: paul.whe...@gmail.com Assignee: Maria Odea Ching Fix For: 2.0-beta-10 Attachments: flatProject.main.patch, flatProject.test.patch, MRELEASE-261-with-its-v3.patch, MRELEASE-261-with-its.patch, MRELEASE-261.patch, PrepareReleaseMojo.patch What I mean by flat file structure firstly. parent/pom.xml module1/pom.xml module2/pom.xml . . . module15/pom.xml the parent references the modules like so modules module../module1/module module../module2/module . . . module../module15/module /modules When i release:prepare only the parent project is tagged the modules projects versions are incremented etc but the modules are not tagged in svn. I use this structure as i use eclipse as my IDE. I would love to see a fix for the issue marked as closed here http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand each submodule of the projects but it would be so nice to have the release plugin do this for me. forgive my english. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-322) Unable to set the working directory for projects where the master pom isn't at the root of the project
[ http://jira.codehaus.org/browse/MRELEASE-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRELEASE-322. - Resolution: Fixed Fixed in trunk 778088. See MRELEASE-261 Unable to set the working directory for projects where the master pom isn't at the root of the project -- Key: MRELEASE-322 URL: http://jira.codehaus.org/browse/MRELEASE-322 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Affects Versions: 2.0-beta-7 Reporter: Christian Nelson Assignee: Maria Odea Ching Priority: Blocker Attachments: maven-release-manager-flat.patch, maven-release-plugin-flat.patch Branches and Tags are created from the current working directory, which isn't always correct and there isn't a way to override the working directory. For example, we have the following directory structure: ${root}/master/pom.xml - The modules section include relative paths to modules a, b, and c. ${root}/module-a/pom.xml ${root}/module-b/pom.xml ${root}/module-c/pom.xml All subversion copies (via branch or prepare) originate from ${root}/master. As a result, they are incomplete; we really want to create copies from ${root} not ${root}/master. Here's the subversion command that I think is the problem: {noformat} [INFO] Working directory: C:\devsys\repos\trunk\master [INFO] Branching release with the label release-1.0... [INFO] Executing: svn --non-interactive copy --file C:\Users\cnelson\AppData\Local\Temp\maven-scm-1179760787.commit . http://hostname/svn/dev/branches/release-1.0 {noformat} The period after the filename is what's indicating to subversion to create the copy from master instead of ${root}. Note: the working directory is derived from the basedir and I couldn't find a way to override the basedir. While not having the master pom at the root of the project may be a little uncommon, it doesn't seem unreasonable. Can we add a configuration option to handle these cases? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-322) Unable to set the working directory for projects where the master pom isn't at the root of the project
[ http://jira.codehaus.org/browse/MRELEASE-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRELEASE-322: -- Fix Version/s: 2.0-beta-10 Unable to set the working directory for projects where the master pom isn't at the root of the project -- Key: MRELEASE-322 URL: http://jira.codehaus.org/browse/MRELEASE-322 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Affects Versions: 2.0-beta-7 Reporter: Christian Nelson Assignee: Maria Odea Ching Priority: Blocker Fix For: 2.0-beta-10 Attachments: maven-release-manager-flat.patch, maven-release-plugin-flat.patch Branches and Tags are created from the current working directory, which isn't always correct and there isn't a way to override the working directory. For example, we have the following directory structure: ${root}/master/pom.xml - The modules section include relative paths to modules a, b, and c. ${root}/module-a/pom.xml ${root}/module-b/pom.xml ${root}/module-c/pom.xml All subversion copies (via branch or prepare) originate from ${root}/master. As a result, they are incomplete; we really want to create copies from ${root} not ${root}/master. Here's the subversion command that I think is the problem: {noformat} [INFO] Working directory: C:\devsys\repos\trunk\master [INFO] Branching release with the label release-1.0... [INFO] Executing: svn --non-interactive copy --file C:\Users\cnelson\AppData\Local\Temp\maven-scm-1179760787.commit . http://hostname/svn/dev/branches/release-1.0 {noformat} The period after the filename is what's indicating to subversion to create the copy from master instead of ${root}. Note: the working directory is derived from the basedir and I couldn't find a way to override the basedir. While not having the master pom at the root of the project may be a little uncommon, it doesn't seem unreasonable. Can we add a configuration option to handle these cases? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRELEASE-261: -- Fix Version/s: 2.0-beta-10 release:prepare shouls support flat directory multimodule projects -- Key: MRELEASE-261 URL: http://jira.codehaus.org/browse/MRELEASE-261 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Environment: linux / maven2 / svn Reporter: paul.whe...@gmail.com Assignee: Maria Odea Ching Fix For: 2.0-beta-10 Attachments: flatProject.main.patch, flatProject.test.patch, MRELEASE-261-with-its-v3.patch, MRELEASE-261-with-its.patch, MRELEASE-261.patch, PrepareReleaseMojo.patch What I mean by flat file structure firstly. parent/pom.xml module1/pom.xml module2/pom.xml . . . module15/pom.xml the parent references the modules like so modules module../module1/module module../module2/module . . . module../module15/module /modules When i release:prepare only the parent project is tagged the modules projects versions are incremented etc but the modules are not tagged in svn. I use this structure as i use eclipse as my IDE. I would love to see a fix for the issue marked as closed here http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand each submodule of the projects but it would be so nice to have the release plugin do this for me. forgive my english. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRELEASE-261. - Resolution: Fixed Fixed in trunk 778088 (applied MRELEASE-261-with-its-v3.patch). release:prepare shouls support flat directory multimodule projects -- Key: MRELEASE-261 URL: http://jira.codehaus.org/browse/MRELEASE-261 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Environment: linux / maven2 / svn Reporter: paul.whe...@gmail.com Assignee: Maria Odea Ching Attachments: flatProject.main.patch, flatProject.test.patch, MRELEASE-261-with-its-v3.patch, MRELEASE-261-with-its.patch, MRELEASE-261.patch, PrepareReleaseMojo.patch What I mean by flat file structure firstly. parent/pom.xml module1/pom.xml module2/pom.xml . . . module15/pom.xml the parent references the modules like so modules module../module1/module module../module2/module . . . module../module15/module /modules When i release:prepare only the parent project is tagged the modules projects versions are incremented etc but the modules are not tagged in svn. I use this structure as i use eclipse as my IDE. I would love to see a fix for the issue marked as closed here http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand each submodule of the projects but it would be so nice to have the release plugin do this for me. forgive my english. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-225) release should support multi-module project with sibling subprojects
[ http://jira.codehaus.org/browse/MRELEASE-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRELEASE-225. - Resolution: Fixed Fix Version/s: 2.0-beta-10 Fixed in trunk 778088. See MRELEASE-261 release should support multi-module project with sibling subprojects Key: MRELEASE-225 URL: http://jira.codehaus.org/browse/MRELEASE-225 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: scm Affects Versions: 2.0-beta-5 Reporter: Alain Coetmeur Assignee: Maria Odea Ching Fix For: 2.0-beta-10 When I try to prepare a release for my project it refuses (after project rebuild) with such a message : An error is occurred in the checkin process: C:\Developpement\MavenWork\SIBLING-SUBMODULE-XX\pom.xml was not contained in C:\Developpement\MavenWork\MAIN-MODULE indeed, my project is quite complex with some modules which are sibling to the main module... this architecture is related to the legacy, and also to the fact that Eclipse does not appreciate project inside projects. anyway I have carefully configured the scmdeveloperConnection in each POM... a way to do that could be to gather the SCM URLS that are used by each POM, then remove those that are included inside others, and then apply the commit/update... for every remainding. Since many people have the same constraint (Eclipse, legacy...) this improvement would be very valuable note that there is a similar demand for SCM update http://jira.codehaus.org/browse/SCM-116 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 minute 23 seconds [INFO] Finished at: Thu Apr 26 19:16:06 CEST 2007 [INFO] Final Memory: 19M/61M [INFO] [INFO] Checking in modified POMs... [INFO] [ERROR] BUILD ERROR [INFO] [INFO] An error is occurred in the checkin process: C:\Developpement\MavenWork\FWK DEI Module Trace Manager\pom.xml was not contai ned in C:\Developpement\MavenWork\FWK DEI Maven All -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-336) unable to release:prepare flat hierarchy project
[ http://jira.codehaus.org/browse/MRELEASE-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRELEASE-336. - Resolution: Fixed Fix Version/s: 2.0-beta-10 Fixed in trunk 778088. See MRELEASE-261 unable to release:prepare flat hierarchy project - Key: MRELEASE-336 URL: http://jira.codehaus.org/browse/MRELEASE-336 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Affects Versions: 2.0-beta-8 Environment: m2eclipse 0.9.0/ mvn 2.0.8, subclipse 1.2.4, jdk1.6.0_03, ubuntu Reporter: Duan Mamrilla Assignee: Maria Odea Ching Priority: Blocker Fix For: 2.0-beta-10 I have projects in flat hierarchy like this {noformat} - hsm/pom.xml -- parent pom - hsm-api/pom.xml - hsm-core/pom.xml - hsm-/pom.xml {noformat} I use also inheritance from parent in modules . When I try to run prepare goal, everything runs OK until: {noformat} [INFO] Executing: svn --non-interactive commit --file /tmp/maven-scm-760111578.commit --targets /tmp/maven-scm-64915-targets [INFO] Working directory: /home/bond/workspace/hsm [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to commit files Provider message: The svn command failed. Command output: svn: '/home/bond/workspace' is not a working copy svn: Can't open file '/home/bond/workspace/.svn/entries': No such file or directory {noformat} It seems that release plugin is trying to find some SVN information directly in my workspace directory. Each pom has separately defined scm options. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=177324#action_177324 ] Maria Odea Ching commented on MRELEASE-261: --- If no one objects to the fix I did, I'll commit it to trunk already.. release:prepare shouls support flat directory multimodule projects -- Key: MRELEASE-261 URL: http://jira.codehaus.org/browse/MRELEASE-261 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Environment: linux / maven2 / svn Reporter: paul.whe...@gmail.com Attachments: flatProject.main.patch, flatProject.test.patch, MRELEASE-261-with-its-v3.patch, MRELEASE-261-with-its.patch, MRELEASE-261.patch, PrepareReleaseMojo.patch What I mean by flat file structure firstly. parent/pom.xml module1/pom.xml module2/pom.xml . . . module15/pom.xml the parent references the modules like so modules module../module1/module module../module2/module . . . module../module15/module /modules When i release:prepare only the parent project is tagged the modules projects versions are incremented etc but the modules are not tagged in svn. I use this structure as i use eclipse as my IDE. I would love to see a fix for the issue marked as closed here http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand each submodule of the projects but it would be so nice to have the release plugin do this for me. forgive my english. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRELEASE-261: -- Attachment: MRELEASE-261-with-its-v3.patch Attached patch with a couple of fixes for the tag url written in the pom and additional tests. release:prepare shouls support flat directory multimodule projects -- Key: MRELEASE-261 URL: http://jira.codehaus.org/browse/MRELEASE-261 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Environment: linux / maven2 / svn Reporter: paul.whe...@gmail.com Attachments: flatProject.main.patch, flatProject.test.patch, MRELEASE-261-with-its-v3.patch, MRELEASE-261-with-its.patch, MRELEASE-261.patch, PrepareReleaseMojo.patch What I mean by flat file structure firstly. parent/pom.xml module1/pom.xml module2/pom.xml . . . module15/pom.xml the parent references the modules like so modules module../module1/module module../module2/module . . . module../module15/module /modules When i release:prepare only the parent project is tagged the modules projects versions are incremented etc but the modules are not tagged in svn. I use this structure as i use eclipse as my IDE. I would love to see a fix for the issue marked as closed here http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand each submodule of the projects but it would be so nice to have the release plugin do this for me. forgive my english. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRELEASE-261: -- Attachment: MRELEASE-261-with-its.patch Attaching revised patch with integration tests for a flat multi-module project and a regular multi-module project. release:prepare shouls support flat directory multimodule projects -- Key: MRELEASE-261 URL: http://jira.codehaus.org/browse/MRELEASE-261 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Environment: linux / maven2 / svn Reporter: paul.whe...@gmail.com Attachments: flatProject.main.patch, flatProject.test.patch, MRELEASE-261-with-its.patch, MRELEASE-261.patch, PrepareReleaseMojo.patch What I mean by flat file structure firstly. parent/pom.xml module1/pom.xml module2/pom.xml . . . module15/pom.xml the parent references the modules like so modules module../module1/module module../module2/module . . . module../module15/module /modules When i release:prepare only the parent project is tagged the modules projects versions are incremented etc but the modules are not tagged in svn. I use this structure as i use eclipse as my IDE. I would love to see a fix for the issue marked as closed here http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand each submodule of the projects but it would be so nice to have the release plugin do this for me. forgive my english. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRELEASE-261: -- Attachment: MRELEASE-261.patch Attaching MRELEASE-261.patch.. The base working directory and the base scm url is determined based on the root project's working dir and scm url, and the relative path of it's modules. Tested the fix with Continuum and the maven-release-plugin. I'm not very familiar with the source code of the Maven Release component so I would really appreciate it if someone could review the fix before I commit it to trunk. Thanks in advance.. release:prepare shouls support flat directory multimodule projects -- Key: MRELEASE-261 URL: http://jira.codehaus.org/browse/MRELEASE-261 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Environment: linux / maven2 / svn Reporter: paul.whe...@gmail.com Attachments: flatProject.main.patch, flatProject.test.patch, MRELEASE-261.patch, PrepareReleaseMojo.patch What I mean by flat file structure firstly. parent/pom.xml module1/pom.xml module2/pom.xml . . . module15/pom.xml the parent references the modules like so modules module../module1/module module../module2/module . . . module../module15/module /modules When i release:prepare only the parent project is tagged the modules projects versions are incremented etc but the modules are not tagged in svn. I use this structure as i use eclipse as my IDE. I would love to see a fix for the issue marked as closed here http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand each submodule of the projects but it would be so nice to have the release plugin do this for me. forgive my english. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=176245#action_176245 ] Maria Odea Ching commented on MRELEASE-261: --- Just unit tests for getting the base working dir and base scm url. I just saw the it tests in maven-release-plugin now, I'll see if I can write one for a flat multi-module. release:prepare shouls support flat directory multimodule projects -- Key: MRELEASE-261 URL: http://jira.codehaus.org/browse/MRELEASE-261 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Environment: linux / maven2 / svn Reporter: paul.whe...@gmail.com Attachments: flatProject.main.patch, flatProject.test.patch, MRELEASE-261.patch, PrepareReleaseMojo.patch What I mean by flat file structure firstly. parent/pom.xml module1/pom.xml module2/pom.xml . . . module15/pom.xml the parent references the modules like so modules module../module1/module module../module2/module . . . module../module15/module /modules When i release:prepare only the parent project is tagged the modules projects versions are incremented etc but the modules are not tagged in svn. I use this structure as i use eclipse as my IDE. I would love to see a fix for the issue marked as closed here http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand each submodule of the projects but it would be so nice to have the release plugin do this for me. forgive my english. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=176245#action_176245 ] Maria Odea Ching edited comment on MRELEASE-261 at 5/13/09 6:01 AM: I only have unit tests for getting the base working dir and base scm url. I just saw the it tests in maven-release-plugin now, I'll see if I can write one for a flat multi-module. was (Author: oching): Just unit tests for getting the base working dir and base scm url. I just saw the it tests in maven-release-plugin now, I'll see if I can write one for a flat multi-module. release:prepare shouls support flat directory multimodule projects -- Key: MRELEASE-261 URL: http://jira.codehaus.org/browse/MRELEASE-261 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Environment: linux / maven2 / svn Reporter: paul.whe...@gmail.com Attachments: flatProject.main.patch, flatProject.test.patch, MRELEASE-261.patch, PrepareReleaseMojo.patch What I mean by flat file structure firstly. parent/pom.xml module1/pom.xml module2/pom.xml . . . module15/pom.xml the parent references the modules like so modules module../module1/module module../module2/module . . . module../module15/module /modules When i release:prepare only the parent project is tagged the modules projects versions are incremented etc but the modules are not tagged in svn. I use this structure as i use eclipse as my IDE. I would love to see a fix for the issue marked as closed here http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand each submodule of the projects but it would be so nice to have the release plugin do this for me. forgive my english. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=174581#action_174581 ] Maria Odea Ching commented on MRELEASE-261: --- I'm currently working on fixing flat multi-module issues with Continuum and I'd probably be touching this issue since Continuum and the maven-release-plugin use the same release manager component. I'll take a look at the attached patches when I get to fixing the releasing part of flat multi-modules. See comments in CONTINUUM-1569 for details on how we're approaching this in Continuum.. release:prepare shouls support flat directory multimodule projects -- Key: MRELEASE-261 URL: http://jira.codehaus.org/browse/MRELEASE-261 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Environment: linux / maven2 / svn Reporter: paul.whe...@gmail.com Attachments: flatProject.main.patch, flatProject.test.patch, PrepareReleaseMojo.patch What I mean by flat file structure firstly. parent/pom.xml module1/pom.xml module2/pom.xml . . . module15/pom.xml the parent references the modules like so modules module../module1/module module../module2/module . . . module../module15/module /modules When i release:prepare only the parent project is tagged the modules projects versions are incremented etc but the modules are not tagged in svn. I use this structure as i use eclipse as my IDE. I would love to see a fix for the issue marked as closed here http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand each submodule of the projects but it would be so nice to have the release plugin do this for me. forgive my english. -- 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: (MSITE-163) The modules menu is not inherited if the parent project has no modules of its own
[ http://jira.codehaus.org/browse/MSITE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching reopened MSITE-163: Problem still occurs in 2.0. menu ref=modules inherit=top / is still not being inherited in the child modules. The modules menu is not inherited if the parent project has no modules of its own - Key: MSITE-163 URL: http://jira.codehaus.org/browse/MSITE-163 Project: Maven 2.x Site Plugin Issue Type: Bug Components: inheritance Affects Versions: 2.0-beta-4 Environment: ubuntu linux / debian linux Reporter: Andrew Williams Assignee: Dennis Lundberg Fix For: 2.0 if I have a site.xml in a parent project that contains the line menu ref=modules inherit=top / it is not inherited by child projects. menu ref=reports inherit=top / works, as does parent. This happens when the parent project has no modules of its own. -- 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-553) Secure Storage of Server Passwords
[ http://jira.codehaus.org/browse/MNG-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=145130#action_145130 ] Maria Odea Ching commented on MNG-553: -- I made some updates in the design docs: http://docs.codehaus.org/display/MAVEN/Secured+Passwords I already included password encryption in the document. Please review.. Thanks! Secure Storage of Server Passwords -- Key: MNG-553 URL: http://jira.codehaus.org/browse/MNG-553 Project: Maven 2 Issue Type: Improvement Components: Settings Affects Versions: 2.0-alpha-3 Environment: Although it may not be relevant since this is a general improvement issue, Windows XP, JDK 1.4.1. Reporter: J. Michael McGarr Assignee: Brett Porter Priority: Critical Fix For: 3.0 This was a question pose to the Maven User's Group and it was suggested I add it here. It would be benefitial to provide a more secure means of storing password's to the servers listed in the .m2/settings.xml. They are currently being stored as plain text and could definately be considered a security breach. Numerous organizations would undoubtedly considered this an unacceptable security risk, and this could prevent widespread adoption of Maven2. I would suggest leaving an option to encrypt the password into the settings file (more secure, but not foolproof) or even requiring the password to be manually provided per build (would prevent automation of builds). I am sure that there is a secure solution to this problem and it should be part of the 2.0 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-553) Secure Storage of Server Passwords
[ http://jira.codehaus.org/browse/MNG-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=144751#action_144751 ] Maria Odea Ching commented on MNG-553: -- Ok, thanks for pointing that out Heinrich. I'll create a separate design doc for the encryption. I'll look more into the code Brett posted above.. Thanks! Secure Storage of Server Passwords -- Key: MNG-553 URL: http://jira.codehaus.org/browse/MNG-553 Project: Maven 2 Issue Type: Improvement Components: Settings Affects Versions: 2.0-alpha-3 Environment: Although it may not be relevant since this is a general improvement issue, Windows XP, JDK 1.4.1. Reporter: J. Michael McGarr Assignee: Brett Porter Priority: Critical Fix For: 2.1 This was a question pose to the Maven User's Group and it was suggested I add it here. It would be benefitial to provide a more secure means of storing password's to the servers listed in the .m2/settings.xml. They are currently being stored as plain text and could definately be considered a security breach. Numerous organizations would undoubtedly considered this an unacceptable security risk, and this could prevent widespread adoption of Maven2. I would suggest leaving an option to encrypt the password into the settings file (more secure, but not foolproof) or even requiring the password to be manually provided per build (would prevent automation of builds). I am sure that there is a secure solution to this problem and it should be part of the 2.0 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-553) Secure Storage of Server Passwords
[ http://jira.codehaus.org/browse/MNG-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=144475#action_144475 ] Maria Odea Ching commented on MNG-553: -- I made an initial draft on how to implement this issue, please see http://docs.codehaus.org/display/MAVEN/Secured+Passwords. Comments and suggestions are very welcome :) Secure Storage of Server Passwords -- Key: MNG-553 URL: http://jira.codehaus.org/browse/MNG-553 Project: Maven 2 Issue Type: Improvement Components: Settings Affects Versions: 2.0-alpha-3 Environment: Although it may not be relevant since this is a general improvement issue, Windows XP, JDK 1.4.1. Reporter: J. Michael McGarr Assignee: Brett Porter Priority: Critical Fix For: 2.1 This was a question pose to the Maven User's Group and it was suggested I add it here. It would be benefitial to provide a more secure means of storing password's to the servers listed in the .m2/settings.xml. They are currently being stored as plain text and could definately be considered a security breach. Numerous organizations would undoubtedly considered this an unacceptable security risk, and this could prevent widespread adoption of Maven2. I would suggest leaving an option to encrypt the password into the settings file (more secure, but not foolproof) or even requiring the password to be manually provided per build (would prevent automation of builds). I am sure that there is a secure solution to this problem and it should be part of the 2.0 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-553) Secure Storage of Server Passwords
[ http://jira.codehaus.org/browse/MNG-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=144373#action_144373 ] Maria Odea Ching commented on MNG-553: -- Is there a design document for this available somewhere? :) Secure Storage of Server Passwords -- Key: MNG-553 URL: http://jira.codehaus.org/browse/MNG-553 Project: Maven 2 Issue Type: Improvement Components: Settings Affects Versions: 2.0-alpha-3 Environment: Although it may not be relevant since this is a general improvement issue, Windows XP, JDK 1.4.1. Reporter: J. Michael McGarr Assignee: Brett Porter Priority: Critical Fix For: 2.1 This was a question pose to the Maven User's Group and it was suggested I add it here. It would be benefitial to provide a more secure means of storing password's to the servers listed in the .m2/settings.xml. They are currently being stored as plain text and could definately be considered a security breach. Numerous organizations would undoubtedly considered this an unacceptable security risk, and this could prevent widespread adoption of Maven2. I would suggest leaving an option to encrypt the password into the settings file (more secure, but not foolproof) or even requiring the password to be manually provided per build (would prevent automation of builds). I am sure that there is a secure solution to this problem and it should be part of the 2.0 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-553) Secure Storage of Server Passwords
[ http://jira.codehaus.org/browse/MNG-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=17#action_17 ] Maria Odea Ching commented on MNG-553: -- Ok, thanks Brett. I'll see what I can come up for this.. Secure Storage of Server Passwords -- Key: MNG-553 URL: http://jira.codehaus.org/browse/MNG-553 Project: Maven 2 Issue Type: Improvement Components: Settings Affects Versions: 2.0-alpha-3 Environment: Although it may not be relevant since this is a general improvement issue, Windows XP, JDK 1.4.1. Reporter: J. Michael McGarr Assignee: Brett Porter Priority: Critical Fix For: 2.1 This was a question pose to the Maven User's Group and it was suggested I add it here. It would be benefitial to provide a more secure means of storing password's to the servers listed in the .m2/settings.xml. They are currently being stored as plain text and could definately be considered a security breach. Numerous organizations would undoubtedly considered this an unacceptable security risk, and this could prevent widespread adoption of Maven2. I would suggest leaving an option to encrypt the password into the settings file (more secure, but not foolproof) or even requiring the password to be manually provided per build (would prevent automation of builds). I am sure that there is a secure solution to this problem and it should be part of the 2.0 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-329) infinite build loop during site generation
[ http://jira.codehaus.org/browse/MSITE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=135868#action_135868 ] Maria Odea Ching commented on MSITE-329: This was also experienced in Archiva, see http://www.nabble.com/Trunk-has-a-build-loop---td16075681.html infinite build loop during site generation -- Key: MSITE-329 URL: http://jira.codehaus.org/browse/MSITE-329 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Environment: Maven 2.0.9; Sun JDK 1.6.0_06; Linux Ubuntu 8.04 Reporter: Alessio Pace My multi module project can be correctly built from the top most parent module with a simple mvn -DskipTests clean install, but trying instead to perform a mvn -DskipTests clean site causes an infinite loop in the build process, where the overall build and site generation is performed all and all over again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-331) SCM urls are broken for all modules, except the parent
[ http://jira.codehaus.org/browse/MRELEASE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133443#action_133443 ] Maria Odea Ching commented on MRELEASE-331: --- Is this the same as MRELEASE-305? SCM urls are broken for all modules, except the parent --- Key: MRELEASE-331 URL: http://jira.codehaus.org/browse/MRELEASE-331 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-7 Reporter: Vincent Siveton Priority: Blocker This comes from the parent pom, which is missing a / at the end of the scm urls. See: http://www.nabble.com/Re%3A-svn-commit%3A-r635240---in--maven-plugin-tools-trunk%3A-.--maven-plugin-plugin--maven-plugin-tools-ant--maven-plugin-tools-api--maven-plugin-tools-beanshell--maven-plugin-tools-java--maven-plugin-tools-javadoc--maven-plugin-tools-model--tt15929761s177.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-773) Improve RSS feed generation
[ http://jira.codehaus.org/browse/MRM-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=131213#action_131213 ] Maria Odea Ching commented on MRM-773: -- Security: - if a user who is subscribed to a feed has been stripped of the necessary permissions or has been deleted, the user should no longer be able to receive updates from the feed Improve RSS feed generation --- Key: MRM-773 URL: http://jira.codehaus.org/browse/MRM-773 Project: Archiva Issue Type: Improvement Components: web application Affects Versions: 1.1 Reporter: Maria Odea Ching Assignee: Maria Odea Ching Fix For: 1.1 - add check to control file size of generated RSS feeds - make sure that the when the client requests the RSS, it gets the right headers to not try and update it if it hasn't changed for performance - get the urls of the feeds from the rss feed request More info in: http://www.nabble.com/Re%3A-svn-commit%3A-r645833---in--archiva-trunk%3A-archiva-jetty-src-main-conf-jetty.xml-archiva-modules-archiva-web-archiva-rss-src-main-java-org-apache-archiva-rss-processor-NewArtifactsRssFeedProcessor.java-td16562163.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-773) Improve RSS feed generation
[ http://jira.codehaus.org/browse/MRM-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=130833#action_130833 ] Maria Odea Ching commented on MRM-773: -- Also, clicking the rss feed icon in the repositories page results to a 404 error if the rss feed file does not exist yet. Improve RSS feed generation --- Key: MRM-773 URL: http://jira.codehaus.org/browse/MRM-773 Project: Archiva Issue Type: Improvement Components: web application Affects Versions: 1.1 Reporter: Maria Odea Ching Assignee: Maria Odea Ching Fix For: 1.1 - add check to control file size of generated RSS feeds - make sure that the when the client requests the RSS, it gets the right headers to not try and update it if it hasn't changed for performance - get the urls of the feeds from the rss feed request More info in: http://www.nabble.com/Re%3A-svn-commit%3A-r645833---in--archiva-trunk%3A-archiva-jetty-src-main-conf-jetty.xml-archiva-modules-archiva-web-archiva-rss-src-main-java-org-apache-archiva-rss-processor-NewArtifactsRssFeedProcessor.java-td16562163.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-677) Upgrade archiva to the latest redback (1.0.1)
[ http://jira.codehaus.org/browse/MRM-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-677: - Summary: Upgrade archiva to the latest redback (1.0.1) (was: Upgrade archiva to the latest redback (1.1)) Upgrade archiva to the latest redback (1.0.1) - Key: MRM-677 URL: http://jira.codehaus.org/browse/MRM-677 Project: Archiva Issue Type: Task Components: build Affects Versions: 1.0, 1.0.1 Reporter: Maria Odea Ching Assignee: Maria Odea Ching 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] Updated: (MRM-777) assignments.jsp: missing tr/tr group under Resource Roles:
[ http://jira.codehaus.org/browse/MRM-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-777: - Fix Version/s: 1.1 assignments.jsp: missing tr/tr group under Resource Roles: -- Key: MRM-777 URL: http://jira.codehaus.org/browse/MRM-777 Project: Archiva Issue Type: Bug Components: web application Affects Versions: 1.1 Reporter: Carlos Costa e Silva Priority: Minor Fix For: 1.1 /archiva-webapp/src/main/webapp/WEB-INF/jsp/redback/admin/assignments.jsp missing tr/tr group under Resource Roles: h5Resource Roles:/h5 ... c:forEach var=row items=${table} -- tr c:forEach var=column items=${row} ... /c:forEach -- /tr /c:forEach -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRM-711) Security using ldap throws NullPointerException
[ http://jira.codehaus.org/browse/MRM-711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-711. Resolution: Fixed Fixed in redback 1.0.1. I already upgraded archiva's redback to this version (-r647651). Security using ldap throws NullPointerException --- Key: MRM-711 URL: http://jira.codehaus.org/browse/MRM-711 Project: Archiva Issue Type: Bug Components: Users/Security Affects Versions: 1.0.1 Environment: Ubuntu Linux, Open-ldap Reporter: Lucas Vilela de Souza Gonçalves Assignee: Maria Odea Ching Priority: Critical Fix For: 1.1 I configured ~/.m2/security.properties with ldap information. In DefaultArchivaConfiguration the Registry load all informations of security.properties. When i was loggin throws this Exception: java.lang.NullPointerException org.codehaus.plexus.redback.common.ldap.connection.LdapConnection.init(LdapConnection.java:58) org.codehaus.plexus.redback.common.ldap.connection.ConfigurableLdapConnectionFactory.getConnection(ConfigurableLdapConnectionFactory.java:123) org.codehaus.plexus.redback.authentication.ldap.LdapBindAuthenticator.authenticate(LdapBindAuthenticator.java:92) I got redback source code, and i see that any information of ldap was there in LdapConnection! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRM-728) After successful admin login archiva reacts as if user is guest
[ http://jira.codehaus.org/browse/MRM-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=130354#action_130354 ] oching edited comment on MRM-728 at 4/10/08 3:34 AM: --- Hmm, it worked for me in IE6. I was still able to login as admin with the correct permissions. The IE6 version I was using was 6.0.2900.2180.xpsp_sp2_qfe.070227-2300. In both tests, I was using the standalone Archiva 1.0.1. The java version installed in the linux machine where Archiva is installed is java 1.5.0_11. Btw, you could set the log level to DEBUG in apps/archiva/webapp/WEB-INF/classes/log4j.xml. was (Author: oching): Hmm, it worked for me in IE6. The IE6 version I was using was 6.0.2900.2180.xpsp_sp2_qfe.070227-2300. In both tests, I was using the standalone Archiva 1.0.1. The java version installed in the linux machine where Archiva is installed is java 1.5.0_11. Btw, you could set the log level to DEBUG in apps/archiva/webapp/WEB-INF/classes/log4j.xml. After successful admin login archiva reacts as if user is guest --- Key: MRM-728 URL: http://jira.codehaus.org/browse/MRM-728 Project: Archiva Issue Type: Bug Affects Versions: 1.0.1 Environment: linux Reporter: Robin Roos Priority: Critical Fix For: 1.0.x Attachments: archiva.log I ran Archiva on my windows box and, after configuring the admin user, I was able to login. The header of the web page identified me as Administrator (admin) and I could see all the expected functions on the left hand frame. So far so good. I had Archiva installed on a linux box and started. I surfed to the box from Windows and configured the admin user. But when I logged in as admin I got a page with only Search/FindArtifact/Browse functions. The header page reads Login - Register. It is as if I am not logged in and am seeing the guest functions. Note that if I log in with a deliberately incorrect password then I get an error message as expected. But logging in with the right credentials appears to fail silently. As a result I cannot deploy any artifacts into Archiva, I cannot roll out the maven/subversion/archiva based edition of our in-house project, and I fear my time is limited! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-775) Support generation of pom for legacy artifacts in web upload form
[ http://jira.codehaus.org/browse/MRM-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-775: - Fix Version/s: 1.x Support generation of pom for legacy artifacts in web upload form - Key: MRM-775 URL: http://jira.codehaus.org/browse/MRM-775 Project: Archiva Issue Type: New Feature Components: web application Affects Versions: 1.1 Reporter: Maria Odea Ching Fix For: 1.x -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-774) Support inclusion of pom file when deploying an artifact via the web upload form
[ http://jira.codehaus.org/browse/MRM-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-774: - Fix Version/s: 1.x Support inclusion of pom file when deploying an artifact via the web upload form Key: MRM-774 URL: http://jira.codehaus.org/browse/MRM-774 Project: Archiva Issue Type: New Feature Components: web application Affects Versions: 1.1 Reporter: Maria Odea Ching Fix For: 1.x Currently the web upload form only supports pom generation when uploading M2 artifacts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRM-123) add RSS view to repository manager
[ http://jira.codehaus.org/browse/MRM-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-123. Resolution: Fixed add RSS view to repository manager -- Key: MRM-123 URL: http://jira.codehaus.org/browse/MRM-123 Project: Archiva Issue Type: New Feature Components: web application Reporter: Brett Porter Assignee: Maria Odea Ching Fix For: 1.1 possibly needs a new component in JIRA. Items that could have RSS: - a particular search - preset for latest added artifacts - preset for new versions of artifacts - preset for new artifacts from a given sync partner -- 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-123) add RSS view to repository manager
[ http://jira.codehaus.org/browse/MRM-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=130106#action_130106 ] Maria Odea Ching commented on MRM-123: -- -r645833: - configure host port of the links in the rss feeds add RSS view to repository manager -- Key: MRM-123 URL: http://jira.codehaus.org/browse/MRM-123 Project: Archiva Issue Type: New Feature Components: web application Reporter: Brett Porter Assignee: Maria Odea Ching Fix For: 1.1 possibly needs a new component in JIRA. Items that could have RSS: - a particular search - preset for latest added artifacts - preset for new versions of artifacts - preset for new artifacts from a given sync partner -- 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-123) add RSS view to repository manager
[ http://jira.codehaus.org/browse/MRM-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=130021#action_130021 ] Maria Odea Ching commented on MRM-123: -- Changes in -r645576: - generate/update rss feeds after repository scan - add rss feed icon in repositories (for new artifacts in repo feed) and in browse artifact (for new versions of artifact feed) add RSS view to repository manager -- Key: MRM-123 URL: http://jira.codehaus.org/browse/MRM-123 Project: Archiva Issue Type: New Feature Components: web application Reporter: Brett Porter Assignee: Maria Odea Ching Fix For: 1.1 possibly needs a new component in JIRA. Items that could have RSS: - a particular search - preset for latest added artifacts - preset for new versions of artifacts - preset for new artifacts from a given sync partner -- 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-123) add RSS view to repository manager
[ http://jira.codehaus.org/browse/MRM-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=129960#action_129960 ] Maria Odea Ching commented on MRM-123: -- Additional commit in -r645347: - generate feeds for new artifacts in the repository and new versions of artifacts - created tests add RSS view to repository manager -- Key: MRM-123 URL: http://jira.codehaus.org/browse/MRM-123 Project: Archiva Issue Type: New Feature Components: web application Reporter: Brett Porter Assignee: Maria Odea Ching Fix For: 1.1 possibly needs a new component in JIRA. Items that could have RSS: - a particular search - preset for latest added artifacts - preset for new versions of artifacts - preset for new artifacts from a given sync partner -- 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-123) add RSS view to repository manager
[ http://jira.codehaus.org/browse/MRM-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=129501#action_129501 ] Maria Odea Ching commented on MRM-123: -- Initial commit in -r643826. add RSS view to repository manager -- Key: MRM-123 URL: http://jira.codehaus.org/browse/MRM-123 Project: Archiva Issue Type: New Feature Components: web application Reporter: Brett Porter Assignee: Maria Odea Ching Fix For: 1.1 possibly needs a new component in JIRA. Items that could have RSS: - a particular search - preset for latest added artifacts - preset for new versions of artifacts - preset for new artifacts from a given sync partner -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRM-727) Archiva does not download plugin artifacts in Geronimo
[ http://jira.codehaus.org/browse/MRM-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-727. Resolution: Fixed Archiva does not download plugin artifacts in Geronimo -- Key: MRM-727 URL: http://jira.codehaus.org/browse/MRM-727 Project: Archiva Issue Type: Bug Affects Versions: 1.0.1 Environment: Ubuntu 7.10 x64, jdk1.6.0_04 x64, geronimo 2.0.2, maven 2.0.8 on client Reporter: Christian Domsch Assignee: Maria Odea Ching Fix For: 1.0.x Attachments: maven-resources-plugin-maven-metadata-central.xml, MRM-727-build-stack-trace.txt, MRM-727-geronimo-tomcat-log-0.0.0.0_access_log.2008-03-10.txt, MRM727.diff, settings-wrong.xml When i have an initially blank local maven repo and for example start maven with mvn clean, no artifacts get downloaded. Maven is configured via the attached settings.xml. When i monitor the tcp traffic, i see that the GET (in this case for the maven-metadata.xml for maven-clean-plugin) request issued to archiva is the correct one. Archiva responses with a 404. When I browse the repository file system on the server where archiva stores its files, i see that a maven-metadata-central.xml was stored. the contents of this file are not correct, though. From trial and error I found out, that any request to a plugin related maven-metadata.xml file will fail. If I try the same for a normal artifact maven-metadata.xml (like the one for commons-lang) then archiva downloads the correct file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-622) database not being updated with project model information
[ http://jira.codehaus.org/browse/MRM-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-622: - Fix Version/s: (was: 1.1) 1.0.2 database not being updated with project model information - Key: MRM-622 URL: http://jira.codehaus.org/browse/MRM-622 Project: Archiva Issue Type: Bug Affects Versions: 1.0 Environment: OS: Windows XP Software: Java 5 Update 12 and Maven 2.0.4 Reporter: Dário Oliveros Assignee: Maria Odea Ching Fix For: 1.0.2 Attachments: archiva-database-consumers.patch, archiva-database.patch, archiva-scheduled.patch I noticed Archiva database was not being updated with project model information in the following scenario: 1) Project B (1.0-SNAPSHOT) depends on Project A (1.0) 2) Project B is deployed to Archiva repository 3) Project B changes Project A dependency version from 1.0 to 1.1-SNAPSHOT 4) Project B is deployed to Archiva repository again. 5) The user executes 'Scan Repository Now' and 'Update Database Now' using Archiva. At this point, if you browse project B, you'll notice it still keeps the reference to the former version of Project A, 1.0, and not 1.1-SNAPSHOT. However, if you download the POM file, you will see it has the lastet dependency version as expected. NOTE: In project B POM file the snapshotRepository is configured with uniqueVersion equals to false. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-688) Replace plexus-runtime with standalone jetty bundle
[ http://jira.codehaus.org/browse/MRM-688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-688: - Assignee: Brett Porter (was: Maria Odea Ching) Replace plexus-runtime with standalone jetty bundle --- Key: MRM-688 URL: http://jira.codehaus.org/browse/MRM-688 Project: Archiva Issue Type: Task Components: build Affects Versions: 1.0, 1.0.1 Reporter: Maria Odea Ching Assignee: Brett Porter Fix For: 1.1 http://www.nabble.com/Re%3A-Archiva-1.1-Roadmap-p15331690.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] Created: (MRM-754) Update the screenshots in the docs
Update the screenshots in the docs -- Key: MRM-754 URL: http://jira.codehaus.org/browse/MRM-754 Project: Archiva Issue Type: Task Components: documentation Reporter: Maria Odea Ching Priority: Minor Fix For: 1.1 Update the following to reflect the changes in the UI (new sections like Legacy Support and Upload Artifact): - Feature Tour - Reports - Search - Identifying An Artifact -- 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] Assigned: (MRM-584) Newly created user cannot login
[ http://jira.codehaus.org/browse/MRM-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching reassigned MRM-584: Assignee: Maria Odea Ching Newly created user cannot login --- Key: MRM-584 URL: http://jira.codehaus.org/browse/MRM-584 Project: Archiva Issue Type: Bug Components: Users/Security Affects Versions: 1.0-beta-4 Reporter: Maria Odea Ching Assignee: Maria Odea Ching Priority: Critical Fix For: 1.1 A new user which has just been created cannot login to Archiva because the user is not validated yet. No email for the new user to validate his/her account is being sent to the user after the account is created. The work around is to click 'Resend Validation' in the User Account page so a validation email is sent to the user and the user can login to Archiva after validating his/her account. Should this be in redback? -- 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-677) Upgrade archiva to redback 1.0
[ http://jira.codehaus.org/browse/MRM-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127984 ] Maria Odea Ching commented on MRM-677: -- I'll update the issue summary as the released redback 1.0 is not usable when I upgraded Archiva to it. The errors I posted above are what I encountered in redback 1.0. The fixes for it are already in place in the deployed redback 1.1-SNAPSHOT. Upgrade archiva to redback 1.0 -- Key: MRM-677 URL: http://jira.codehaus.org/browse/MRM-677 Project: Archiva Issue Type: Task Components: build Affects Versions: 1.0, 1.0.1 Reporter: Maria Odea Ching Assignee: Maria Odea Ching 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] Updated: (MRM-677) Upgrade archiva to the latest redback (1.1)
[ http://jira.codehaus.org/browse/MRM-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-677: - Summary: Upgrade archiva to the latest redback (1.1) (was: Upgrade archiva to redback 1.0) Upgrade archiva to the latest redback (1.1) --- Key: MRM-677 URL: http://jira.codehaus.org/browse/MRM-677 Project: Archiva Issue Type: Task Components: build Affects Versions: 1.0, 1.0.1 Reporter: Maria Odea Ching Assignee: Maria Odea Ching 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] Closed: (MRM-677) Upgrade archiva to redback 1.0
[ http://jira.codehaus.org/browse/MRM-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-677. Resolution: Fixed Fixed in archiva-trunk -r638845. Changes made: - upgraded redback to 1.1-SNAPSHOT - updated the archiva redback models to the new redback model Upgrade archiva to redback 1.0 -- Key: MRM-677 URL: http://jira.codehaus.org/browse/MRM-677 Project: Archiva Issue Type: Task Components: build Affects Versions: 1.0, 1.0.1 Reporter: Maria Odea Ching Assignee: Maria Odea Ching 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] Assigned: (MRM-711) Security using ldap throws NullPointerException
[ http://jira.codehaus.org/browse/MRM-711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching reassigned MRM-711: Assignee: Maria Odea Ching Security using ldap throws NullPointerException --- Key: MRM-711 URL: http://jira.codehaus.org/browse/MRM-711 Project: Archiva Issue Type: Bug Components: Users/Security Affects Versions: 1.0.1 Environment: Ubuntu Linux, Open-ldap Reporter: Lucas Vilela de Souza Gonçalves Assignee: Maria Odea Ching Priority: Critical Fix For: 1.1 I configured ~/.m2/security.properties with ldap information. In DefaultArchivaConfiguration the Registry load all informations of security.properties. When i was loggin throws this Exception: java.lang.NullPointerException org.codehaus.plexus.redback.common.ldap.connection.LdapConnection.init(LdapConnection.java:58) org.codehaus.plexus.redback.common.ldap.connection.ConfigurableLdapConnectionFactory.getConnection(ConfigurableLdapConnectionFactory.java:123) org.codehaus.plexus.redback.authentication.ldap.LdapBindAuthenticator.authenticate(LdapBindAuthenticator.java:92) I got redback source code, and i see that any information of ldap was there in LdapConnection! -- 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] Assigned: (MRM-591) Reports should show from which repository the defective artifact was found.
[ http://jira.codehaus.org/browse/MRM-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching reassigned MRM-591: Assignee: Maria Odea Ching Reports should show from which repository the defective artifact was found. --- Key: MRM-591 URL: http://jira.codehaus.org/browse/MRM-591 Project: Archiva Issue Type: Improvement Components: reporting Affects Versions: 1.0-beta-4 Reporter: Maria Odea Ching Assignee: Maria Odea Ching Fix For: 1.1 In the report showing the defective/problematic artifacts from All Repositories, it would be nice to see from which repository each defective artifact was found. The artifacts could be grouped by 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] Closed: (MRM-622) database not being updated with project model information
[ http://jira.codehaus.org/browse/MRM-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-622. Resolution: Fixed Applied the following sections from the archiva-database-consumers.patch in ProjectModelToDatabaseConsumer and DatabaseCleanupRemoveProjectConsumer: // Force removal of project model from effective cache String projectKey = toProjectKey( projectModel ); synchronized ( effectiveProjectCache ) { if ( effectiveProjectCache.hasKey( projectKey ) ) { effectiveProjectCache.remove( projectKey ); } } ... private String toProjectKey( ArchivaProjectModel project ) { StringBuilder key = new StringBuilder(); key.append( project.getGroupId() ).append( : ); key.append( project.getArtifactId() ).append( : ); key.append( project.getVersion() ); return key.toString(); } Other changes made: - delete the project model if it already exists in the database (ProjectModelToDatabaseConsumer) - added the effective-project-cache component in the DatabaseCleanupRemoveProjectModelTest The above fixes are in -r637928. Thanks! database not being updated with project model information - Key: MRM-622 URL: http://jira.codehaus.org/browse/MRM-622 Project: Archiva Issue Type: Bug Affects Versions: 1.0 Environment: OS: Windows XP Software: Java 5 Update 12 and Maven 2.0.4 Reporter: Dário Oliveros Assignee: Maria Odea Ching Fix For: 1.1 Attachments: archiva-database-consumers.patch, archiva-database.patch, archiva-scheduled.patch I noticed Archiva database was not being updated with project model information in the following scenario: 1) Project B (1.0-SNAPSHOT) depends on Project A (1.0) 2) Project B is deployed to Archiva repository 3) Project B changes Project A dependency version from 1.0 to 1.1-SNAPSHOT 4) Project B is deployed to Archiva repository again. 5) The user executes 'Scan Repository Now' and 'Update Database Now' using Archiva. At this point, if you browse project B, you'll notice it still keeps the reference to the former version of Project A, 1.0, and not 1.1-SNAPSHOT. However, if you download the POM file, you will see it has the lastet dependency version as expected. NOTE: In project B POM file the snapshotRepository is configured with uniqueVersion equals to false. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRM-608) Unable to find project model for [...] if the initial import of the POM failed
[ http://jira.codehaus.org/browse/MRM-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-608. Resolution: Fixed Fixed in -r637023. -set whenProcessed to null of every artifact discovered (ArtufactUpdateDatabaseConsumer) Unable to find project model for [...] if the initial import of the POM failed --- Key: MRM-608 URL: http://jira.codehaus.org/browse/MRM-608 Project: Archiva Issue Type: Bug Components: repository scanning Affects Versions: 1.0 Environment: Windows32 Reporter: Arne Degenring Assignee: Maria Odea Ching Priority: Critical Fix For: 1.1 Attachments: archiva.log, data.zip It seems that Archiva is not properly updating the database if the initial import of the POM failed due to a parse error, even after the original problem has been corrected, the repository has been rescanned, and the database updated again. Steps to reproduce: 1. Start with a fresh Archiva 1.0 installation 2. Drop a group containing an artifact with a broken POM (illegal XML) to Archiva's internal repo directory 3. Run Scan Repository Now and Update Database Now. The log shows a ProjectModelException because the broken POM could not be parsed. 4. Fix the broken POM. Run Scan Repository Now and Update Database Now again. 5. Use the Browse page to browse to the artifact - you get the error message: Unable to find project model for [junit:junit:3.7]. I've attached the zipped contents of the data directory after performing the steps above, and the log file. Notice that there might be general repository scanning problem in 1.0 that could be related, see http://www.nabble.com/Repository-scanning-problem-in-1.0--tf4897121.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] Assigned: (MRM-622) database not being updated with project model information
[ http://jira.codehaus.org/browse/MRM-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching reassigned MRM-622: Assignee: Maria Odea Ching database not being updated with project model information - Key: MRM-622 URL: http://jira.codehaus.org/browse/MRM-622 Project: Archiva Issue Type: Bug Affects Versions: 1.0 Environment: OS: Windows XP Software: Java 5 Update 12 and Maven 2.0.4 Reporter: Dário Oliveros Assignee: Maria Odea Ching Fix For: 1.1 Attachments: archiva-database-consumers.patch, archiva-database.patch, archiva-scheduled.patch I noticed Archiva database was not being updated with project model information in the following scenario: 1) Project B (1.0-SNAPSHOT) depends on Project A (1.0) 2) Project B is deployed to Archiva repository 3) Project B changes Project A dependency version from 1.0 to 1.1-SNAPSHOT 4) Project B is deployed to Archiva repository again. 5) The user executes 'Scan Repository Now' and 'Update Database Now' using Archiva. At this point, if you browse project B, you'll notice it still keeps the reference to the former version of Project A, 1.0, and not 1.1-SNAPSHOT. However, if you download the POM file, you will see it has the lastet dependency version as expected. NOTE: In project B POM file the snapshotRepository is configured with uniqueVersion equals to false. -- 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-216) Upload (deploy) artifacts to a repository - via a web form (not using wagon)
[ http://jira.codehaus.org/browse/MRM-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127064 ] Maria Odea Ching commented on MRM-216: -- The following has already been finished in -r636284 and -r636703: - 'Upload Artifact' already in navigation menu - dropdown box for the repository ids - check for write permissions before allowing deployment in repo - allow user to specify whether to generate a pom for the artifact - update metadata file Upload (deploy) artifacts to a repository - via a web form (not using wagon) Key: MRM-216 URL: http://jira.codehaus.org/browse/MRM-216 Project: Archiva Issue Type: New Feature Components: web application Reporter: Oliver Fink Assignee: John Tolentino Fix For: 1.1 Attachments: MRM-216-20070818-1935.patch The web interface should allow to upload artifacts to the repository. For M1 one could just ftp the artifacts as neededm but with M2 having to go through the file:deploy plugin is a pain. Archiva could help a lot here -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRM-216) Upload (deploy) artifacts to a repository - via a web form (not using wagon)
[ http://jira.codehaus.org/browse/MRM-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127064 ] oching edited comment on MRM-216 at 3/13/08 8:24 PM: --- The following has already been finished in -r636284 and -r636703: - 'Upload Artifact' already in navigation menu - dropdown box for the repository ids - check for write permissions before allowing deployment in repo - allow user to specify whether to generate a pom for the artifact (for Maven 2 artifacts) - update metadata file was (Author: oching): The following has already been finished in -r636284 and -r636703: - 'Upload Artifact' already in navigation menu - dropdown box for the repository ids - check for write permissions before allowing deployment in repo - allow user to specify whether to generate a pom for the artifact - update metadata file Upload (deploy) artifacts to a repository - via a web form (not using wagon) Key: MRM-216 URL: http://jira.codehaus.org/browse/MRM-216 Project: Archiva Issue Type: New Feature Components: web application Reporter: Oliver Fink Assignee: John Tolentino Fix For: 1.1 Attachments: MRM-216-20070818-1935.patch The web interface should allow to upload artifacts to the repository. For M1 one could just ftp the artifacts as neededm but with M2 having to go through the file:deploy plugin is a pain. Archiva could help a lot here -- 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-216) Upload (deploy) artifacts to a repository - via a web form (not using wagon)
[ http://jira.codehaus.org/browse/MRM-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127168 ] Maria Odea Ching commented on MRM-216: -- Additional fix: - Added form validation and other validations in action class (-r636953) Upload (deploy) artifacts to a repository - via a web form (not using wagon) Key: MRM-216 URL: http://jira.codehaus.org/browse/MRM-216 Project: Archiva Issue Type: New Feature Components: web application Reporter: Oliver Fink Assignee: John Tolentino Fix For: 1.1 Attachments: MRM-216-20070818-1935.patch The web interface should allow to upload artifacts to the repository. For M1 one could just ftp the artifacts as neededm but with M2 having to go through the file:deploy plugin is a pain. Archiva could help a lot here -- 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-216) Upload (deploy) artifacts to a repository - via a web form (not using wagon)
[ http://jira.codehaus.org/browse/MRM-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127170 ] Maria Odea Ching commented on MRM-216: -- Additional fix: - generate or update checksums of metadata file (-r636957) Upload (deploy) artifacts to a repository - via a web form (not using wagon) Key: MRM-216 URL: http://jira.codehaus.org/browse/MRM-216 Project: Archiva Issue Type: New Feature Components: web application Reporter: Oliver Fink Assignee: John Tolentino Fix For: 1.1 Attachments: MRM-216-20070818-1935.patch The web interface should allow to upload artifacts to the repository. For M1 one could just ftp the artifacts as neededm but with M2 having to go through the file:deploy plugin is a pain. Archiva could help a lot here -- 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-216) Upload (deploy) artifacts to a repository - via a web form (not using wagon)
[ http://jira.codehaus.org/browse/MRM-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127171 ] Maria Odea Ching commented on MRM-216: -- Added instructions on how to deploy an artifact via the web UI form in archiva-docs (-r636970) Upload (deploy) artifacts to a repository - via a web form (not using wagon) Key: MRM-216 URL: http://jira.codehaus.org/browse/MRM-216 Project: Archiva Issue Type: New Feature Components: web application Reporter: Oliver Fink Assignee: John Tolentino Fix For: 1.1 Attachments: MRM-216-20070818-1935.patch The web interface should allow to upload artifacts to the repository. For M1 one could just ftp the artifacts as neededm but with M2 having to go through the file:deploy plugin is a pain. Archiva could help a lot here -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRM-216) Upload (deploy) artifacts to a repository - via a web form (not using wagon)
[ http://jira.codehaus.org/browse/MRM-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-216. Resolution: Fixed Upload (deploy) artifacts to a repository - via a web form (not using wagon) Key: MRM-216 URL: http://jira.codehaus.org/browse/MRM-216 Project: Archiva Issue Type: New Feature Components: web application Reporter: Oliver Fink Assignee: Maria Odea Ching Fix For: 1.1 Attachments: MRM-216-20070818-1935.patch The web interface should allow to upload artifacts to the repository. For M1 one could just ftp the artifacts as neededm but with M2 having to go through the file:deploy plugin is a pain. Archiva could help a lot here -- 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] Assigned: (MRM-608) Unable to find project model for [...] if the initial import of the POM failed
[ http://jira.codehaus.org/browse/MRM-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching reassigned MRM-608: Assignee: Maria Odea Ching Unable to find project model for [...] if the initial import of the POM failed --- Key: MRM-608 URL: http://jira.codehaus.org/browse/MRM-608 Project: Archiva Issue Type: Bug Components: repository scanning Affects Versions: 1.0 Environment: Windows32 Reporter: Arne Degenring Assignee: Maria Odea Ching Priority: Critical Fix For: 1.1 Attachments: archiva.log, data.zip It seems that Archiva is not properly updating the database if the initial import of the POM failed due to a parse error, even after the original problem has been corrected, the repository has been rescanned, and the database updated again. Steps to reproduce: 1. Start with a fresh Archiva 1.0 installation 2. Drop a group containing an artifact with a broken POM (illegal XML) to Archiva's internal repo directory 3. Run Scan Repository Now and Update Database Now. The log shows a ProjectModelException because the broken POM could not be parsed. 4. Fix the broken POM. Run Scan Repository Now and Update Database Now again. 5. Use the Browse page to browse to the artifact - you get the error message: Unable to find project model for [junit:junit:3.7]. I've attached the zipped contents of the data directory after performing the steps above, and the log file. Notice that there might be general repository scanning problem in 1.0 that could be related, see http://www.nabble.com/Repository-scanning-problem-in-1.0--tf4897121.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-711) Security using ldap throws NullPointerException
[ http://jira.codehaus.org/browse/MRM-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126789 ] Maria Odea Ching commented on MRM-711: -- This is already fixed in redback-trunk. We're migrating archiva 1.0.2 to the latest redback, so this would be fixed by then. I'll move this issue to 1.0.2.. Security using ldap throws NullPointerException --- Key: MRM-711 URL: http://jira.codehaus.org/browse/MRM-711 Project: Archiva Issue Type: Bug Components: Users/Security Affects Versions: 1.0.1 Environment: Ubuntu Linux, Open-ldap Reporter: Lucas Vilela de Souza Gonçalves Priority: Critical I configured ~/.m2/security.properties with ldap information. In DefaultArchivaConfiguration the Registry load all informations of security.properties. When i was loggin throws this Exception: java.lang.NullPointerException org.codehaus.plexus.redback.common.ldap.connection.LdapConnection.init(LdapConnection.java:58) org.codehaus.plexus.redback.common.ldap.connection.ConfigurableLdapConnectionFactory.getConnection(ConfigurableLdapConnectionFactory.java:123) org.codehaus.plexus.redback.authentication.ldap.LdapBindAuthenticator.authenticate(LdapBindAuthenticator.java:92) I got redback source code, and i see that any information of ldap was there in LdapConnection! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-711) Security using ldap throws NullPointerException
[ http://jira.codehaus.org/browse/MRM-711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-711: - Fix Version/s: 1.0.2 Security using ldap throws NullPointerException --- Key: MRM-711 URL: http://jira.codehaus.org/browse/MRM-711 Project: Archiva Issue Type: Bug Components: Users/Security Affects Versions: 1.0.1 Environment: Ubuntu Linux, Open-ldap Reporter: Lucas Vilela de Souza Gonçalves Priority: Critical Fix For: 1.0.2 I configured ~/.m2/security.properties with ldap information. In DefaultArchivaConfiguration the Registry load all informations of security.properties. When i was loggin throws this Exception: java.lang.NullPointerException org.codehaus.plexus.redback.common.ldap.connection.LdapConnection.init(LdapConnection.java:58) org.codehaus.plexus.redback.common.ldap.connection.ConfigurableLdapConnectionFactory.getConnection(ConfigurableLdapConnectionFactory.java:123) org.codehaus.plexus.redback.authentication.ldap.LdapBindAuthenticator.authenticate(LdapBindAuthenticator.java:92) I got redback source code, and i see that any information of ldap was there in LdapConnection! -- 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-216) Upload (deploy) artifacts to a repository - via a web form (not using wagon)
[ http://jira.codehaus.org/browse/MRM-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126798 ] Maria Odea Ching commented on MRM-216: -- Applied the patch in archiva-trunk -r635836. I commented out some parts in the UploadAction class which need to be modified due to the changes in the Archiva components used. I made an initial list of what I think still needs to be done and can be improved: - modify the commented parts to adapt to the changes in the components (like the repository layout) - add 'Upload/Deploy Artifact' in the navigation menu - form validation - maybe we could have a drop-down box for the repository ids - include this feature in the documentation Upload (deploy) artifacts to a repository - via a web form (not using wagon) Key: MRM-216 URL: http://jira.codehaus.org/browse/MRM-216 Project: Archiva Issue Type: New Feature Components: web application Reporter: Oliver Fink Assignee: John Tolentino Fix For: 1.1 Attachments: MRM-216-20070818-1935.patch The web interface should allow to upload artifacts to the repository. For M1 one could just ftp the artifacts as neededm but with M2 having to go through the file:deploy plugin is a pain. Archiva could help a lot here -- 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-727) Archiva does not download plugin artifacts
[ http://jira.codehaus.org/browse/MRM-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126680 ] Maria Odea Ching commented on MRM-727: -- I also found this in the geronimo logs.. 14:32:33,558 ERROR [[RepositoryServlet]] Servlet.service() for servlet RepositoryServlet threw exception org.dom4j.InvalidXPathException: Invalid XPath expression: '//metadata/groupId'. Caused by: org/dom4j/Element at org.dom4j.xpath.DefaultXPath.parse(DefaultXPath.java:362) at org.dom4j.xpath.DefaultXPath.init(DefaultXPath.java:59) at org.dom4j.DocumentFactory.createXPath(DocumentFactory.java:230) at org.dom4j.tree.AbstractNode.createXPath(AbstractNode.java:207) at org.apache.maven.archiva.xml.XMLReader.createXPath(XMLReader.java:175) at org.apache.maven.archiva.xml.XMLReader.getElementText(XMLReader.java:258) at org.apache.maven.archiva.repository.metadata.RepositoryMetadataReader.read(RepositoryMetadataReader.java:56) at org.apache.maven.archiva.repository.metadata.MetadataTools.readProxyMetadata(MetadataTools.java:360) at org.apache.maven.archiva.repository.metadata.MetadataTools.updateMetadata(MetadataTools.java:435) at org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors.fetchFromProxies(DefaultRepositoryProxyConnectors.java:367) at org.apache.maven.archiva.web.repository.ProxiedDavServer.fetchMetadataFromProxies(ProxiedDavServer.java:405) at org.apache.maven.archiva.web.repository.ProxiedDavServer.fetchContentFromProxies(ProxiedDavServer.java:343) at org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:189) at org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:119) at org.apache.maven.archiva.web.repository.RepositoryServlet.service(RepositoryServlet.java:155) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:353) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:595) Is this the one you've mentioned above Christian? Archiva does not download plugin artifacts -- Key: MRM-727 URL: http://jira.codehaus.org/browse/MRM-727 Project: Archiva Issue Type: Bug Affects Versions: 1.0.1 Environment: Ubuntu 7.10 x64, jdk1.6.0_04 x64, geronimo 2.0.2, maven 2.0.8 on client Reporter: Christian Domsch Assignee: Maria Odea
[jira] Commented: (MRM-727) Archiva does not download plugin artifacts
[ http://jira.codehaus.org/browse/MRM-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126687 ] Maria Odea Ching commented on MRM-727: -- Could you try it Christian and see if it works for you? Thanks.. Archiva does not download plugin artifacts -- Key: MRM-727 URL: http://jira.codehaus.org/browse/MRM-727 Project: Archiva Issue Type: Bug Affects Versions: 1.0.1 Environment: Ubuntu 7.10 x64, jdk1.6.0_04 x64, geronimo 2.0.2, maven 2.0.8 on client Reporter: Christian Domsch Assignee: Maria Odea Ching Fix For: 1.0.2 Attachments: maven-resources-plugin-maven-metadata-central.xml, MRM-727-build-stack-trace.txt, MRM-727-geronimo-tomcat-log-0.0.0.0_access_log.2008-03-10.txt, MRM727.diff, settings-wrong.xml When i have an initially blank local maven repo and for example start maven with mvn clean, no artifacts get downloaded. Maven is configured via the attached settings.xml. When i monitor the tcp traffic, i see that the GET (in this case for the maven-metadata.xml for maven-clean-plugin) request issued to archiva is the correct one. Archiva responses with a 404. When I browse the repository file system on the server where archiva stores its files, i see that a maven-metadata-central.xml was stored. the contents of this file are not correct, though. From trial and error I found out, that any request to a plugin related maven-metadata.xml file will fail. If I try the same for a normal artifact maven-metadata.xml (like the one for commons-lang) then archiva downloads the correct file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-727) Archiva does not download plugin artifacts
[ http://jira.codehaus.org/browse/MRM-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126673 ] Maria Odea Ching commented on MRM-727: -- Hi James, I was able to reproduce the plugin download problem in Geronimo. The metadata xml files are all incorrect for the plugins. I've attached the logs and the metadata files. Archiva does not download plugin artifacts -- Key: MRM-727 URL: http://jira.codehaus.org/browse/MRM-727 Project: Archiva Issue Type: Bug Affects Versions: 1.0.1 Environment: Ubuntu 7.10 x64, jdk1.6.0_04 x64, geronimo 2.0.2, maven 2.0.8 on client Reporter: Christian Domsch Assignee: Maria Odea Ching Fix For: 1.0.2 Attachments: MRM727.diff, settings-wrong.xml When i have an initially blank local maven repo and for example start maven with mvn clean, no artifacts get downloaded. Maven is configured via the attached settings.xml. When i monitor the tcp traffic, i see that the GET (in this case for the maven-metadata.xml for maven-clean-plugin) request issued to archiva is the correct one. Archiva responses with a 404. When I browse the repository file system on the server where archiva stores its files, i see that a maven-metadata-central.xml was stored. the contents of this file are not correct, though. From trial and error I found out, that any request to a plugin related maven-metadata.xml file will fail. If I try the same for a normal artifact maven-metadata.xml (like the one for commons-lang) then archiva downloads the correct file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-727) Archiva does not download plugin artifacts
[ http://jira.codehaus.org/browse/MRM-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-727: - Attachment: MRM-727-build-stack-trace.txt Archiva does not download plugin artifacts -- Key: MRM-727 URL: http://jira.codehaus.org/browse/MRM-727 Project: Archiva Issue Type: Bug Affects Versions: 1.0.1 Environment: Ubuntu 7.10 x64, jdk1.6.0_04 x64, geronimo 2.0.2, maven 2.0.8 on client Reporter: Christian Domsch Assignee: Maria Odea Ching Fix For: 1.0.2 Attachments: MRM-727-build-stack-trace.txt, MRM727.diff, settings-wrong.xml When i have an initially blank local maven repo and for example start maven with mvn clean, no artifacts get downloaded. Maven is configured via the attached settings.xml. When i monitor the tcp traffic, i see that the GET (in this case for the maven-metadata.xml for maven-clean-plugin) request issued to archiva is the correct one. Archiva responses with a 404. When I browse the repository file system on the server where archiva stores its files, i see that a maven-metadata-central.xml was stored. the contents of this file are not correct, though. From trial and error I found out, that any request to a plugin related maven-metadata.xml file will fail. If I try the same for a normal artifact maven-metadata.xml (like the one for commons-lang) then archiva downloads the correct file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira