[jira] Commented: (SCM-558) Add support for 'mkdir' command

2010-11-24 Thread Maria Odea Ching (JIRA)

[ 
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

2010-11-24 Thread Maria Odea Ching (JIRA)

 [ 
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

2010-11-24 Thread Maria Odea Ching (JIRA)

 [ 
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

2010-09-01 Thread Maria Odea Ching (JIRA)

[ 
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

2010-06-29 Thread Maria Odea Ching (JIRA)

 [ 
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

2010-06-23 Thread Maria Odea Ching (JIRA)

[ 
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

2010-06-22 Thread Maria Odea Ching (JIRA)

[ 
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

2010-06-22 Thread Maria Odea Ching (JIRA)

[ 
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

2010-06-22 Thread Maria Odea Ching (JIRA)

[ 
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

2010-06-22 Thread Maria Odea Ching (JIRA)

[ 
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

2010-06-22 Thread Maria Odea Ching (JIRA)

[ 
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

2010-06-21 Thread Maria Odea Ching (JIRA)

[ 
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

2010-06-20 Thread Maria Odea Ching (JIRA)

[ 
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

2010-06-19 Thread Maria Odea Ching (JIRA)

[ 
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

2010-06-16 Thread Maria Odea Ching (JIRA)

 [ 
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

2010-06-16 Thread Maria Odea Ching (JIRA)

[ 
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

2010-06-15 Thread Maria Odea Ching (JIRA)

[ 
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

2010-06-15 Thread Maria Odea Ching (JIRA)
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

2010-06-15 Thread Maria Odea Ching (JIRA)

 [ 
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

2010-02-01 Thread Maria Odea Ching (JIRA)

[ 
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

2010-01-11 Thread Maria Odea Ching (JIRA)
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

2010-01-11 Thread Maria Odea Ching (JIRA)

 [ 
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 '----------'

2010-01-11 Thread Maria Odea Ching (JIRA)

[ 
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

2010-01-11 Thread Maria Odea Ching (JIRA)

[ 
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 '----------'

2010-01-06 Thread Maria Odea Ching (JIRA)

[ 
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

2009-12-17 Thread Maria Odea Ching (JIRA)

 [ 
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

2009-07-29 Thread Maria Odea Ching (JIRA)
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

2009-07-29 Thread Maria Odea Ching (JIRA)

 [ 
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

2009-07-29 Thread Maria Odea Ching (JIRA)

 [ 
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

2009-06-26 Thread Maria Odea Ching (JIRA)

 [ 
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

2009-06-11 Thread Maria Odea Ching (JIRA)

[ 
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

2009-06-09 Thread Maria Odea Ching (JIRA)

 [ 
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

2009-06-09 Thread Maria Odea Ching (JIRA)

 [ 
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

2009-06-09 Thread Maria Odea Ching (JIRA)

[ 
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

2009-06-08 Thread Maria Odea Ching (JIRA)

 [ 
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

2009-06-08 Thread Maria Odea Ching (JIRA)
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

2009-06-08 Thread Maria Odea Ching (JIRA)

[ 
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

2009-06-08 Thread Maria Odea Ching (JIRA)

 [ 
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

2009-05-24 Thread Maria Odea Ching (JIRA)

[ 
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

2009-05-23 Thread Maria Odea Ching (JIRA)

 [ 
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

2009-05-23 Thread Maria Odea Ching (JIRA)

 [ 
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

2009-05-23 Thread Maria Odea Ching (JIRA)

 [ 
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

2009-05-23 Thread Maria Odea Ching (JIRA)

 [ 
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

2009-05-23 Thread Maria Odea Ching (JIRA)

 [ 
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

2009-05-23 Thread Maria Odea Ching (JIRA)

 [ 
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: Dušan 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

2009-05-20 Thread Maria Odea Ching (JIRA)

[ 
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

2009-05-19 Thread Maria Odea Ching (JIRA)

 [ 
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

2009-05-14 Thread Maria Odea Ching (JIRA)

 [ 
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

2009-05-13 Thread Maria Odea Ching (JIRA)

 [ 
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

2009-05-13 Thread Maria Odea Ching (JIRA)

[ 
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

2009-05-13 Thread Maria Odea Ching (JIRA)

[ 
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

2009-04-29 Thread Maria Odea Ching (JIRA)

[ 
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

2009-04-16 Thread Maria Odea Ching (JIRA)

 [ 
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

2008-08-15 Thread Maria Odea Ching (JIRA)

[ 
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

2008-08-11 Thread Maria Odea Ching (JIRA)

[ 
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

2008-08-08 Thread Maria Odea Ching (JIRA)

[ 
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

2008-08-07 Thread Maria Odea Ching (JIRA)

[ 
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

2008-08-07 Thread Maria Odea Ching (JIRA)

[ 
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

2008-05-23 Thread Maria Odea Ching (JIRA)

[ 
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

2008-05-04 Thread Maria Odea Ching (JIRA)

[ 
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

2008-04-18 Thread Maria Odea Ching (JIRA)

[ 
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

2008-04-14 Thread Maria Odea Ching (JIRA)

[ 
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)

2008-04-13 Thread Maria Odea Ching (JIRA)

 [ 
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:

2008-04-13 Thread Maria Odea Ching (JIRA)

 [ 
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

2008-04-13 Thread Maria Odea Ching (JIRA)

 [ 
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

2008-04-10 Thread Maria Odea Ching (JIRA)

[ 
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

2008-04-09 Thread Maria Odea Ching (JIRA)

 [ 
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

2008-04-09 Thread Maria Odea Ching (JIRA)

 [ 
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

2008-04-08 Thread Maria Odea Ching (JIRA)

 [ 
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

2008-04-08 Thread Maria Odea Ching (JIRA)

[ 
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

2008-04-07 Thread Maria Odea Ching (JIRA)

[ 
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

2008-04-06 Thread Maria Odea Ching (JIRA)

[ 
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

2008-04-02 Thread Maria Odea Ching (JIRA)

[ 
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

2008-04-01 Thread Maria Odea Ching (JIRA)

 [ 
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

2008-03-31 Thread Maria Odea Ching (JIRA)

 [ 
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

2008-03-28 Thread Maria Odea Ching (JIRA)

 [ 
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

2008-03-28 Thread Maria Odea Ching (JIRA)
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

2008-03-28 Thread Maria Odea Ching (JIRA)

 [ 
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

2008-03-20 Thread Maria Odea Ching (JIRA)

[ 
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)

2008-03-20 Thread Maria Odea Ching (JIRA)

 [ 
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

2008-03-19 Thread Maria Odea Ching (JIRA)

 [ 
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

2008-03-19 Thread Maria Odea Ching (JIRA)

 [ 
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.

2008-03-17 Thread Maria Odea Ching (JIRA)

 [ 
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

2008-03-17 Thread Maria Odea Ching (JIRA)

 [ 
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

2008-03-14 Thread Maria Odea Ching (JIRA)

 [ 
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

2008-03-14 Thread Maria Odea Ching (JIRA)

 [ 
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)

2008-03-13 Thread Maria Odea Ching (JIRA)

[ 
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)

2008-03-13 Thread Maria Odea Ching (JIRA)

[ 
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)

2008-03-13 Thread Maria Odea Ching (JIRA)

[ 
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)

2008-03-13 Thread Maria Odea Ching (JIRA)

[ 
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)

2008-03-13 Thread Maria Odea Ching (JIRA)

[ 
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)

2008-03-13 Thread Maria Odea Ching (JIRA)

 [ 
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

2008-03-13 Thread Maria Odea Ching (JIRA)

 [ 
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

2008-03-11 Thread Maria Odea Ching (JIRA)

[ 
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

2008-03-11 Thread Maria Odea Ching (JIRA)

 [ 
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)

2008-03-11 Thread Maria Odea Ching (JIRA)

[ 
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

2008-03-10 Thread Maria Odea Ching (JIRA)

[ 
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

2008-03-10 Thread Maria Odea Ching (JIRA)

[ 
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

2008-03-09 Thread Maria Odea Ching (JIRA)

[ 
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

2008-03-09 Thread Maria Odea Ching (JIRA)

 [ 
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




  1   2   3   4   5   6   7   8   >