[jira] Commented: (CONTINUUM-1387) Can't initiate a build of a new project in continuum until all modules have been checked out

[Teodoro Cue Jr. (JIRA)]

[ 
http://jira.codehaus.org/browse/CONTINUUM-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105385
 ] 

Teodoro Cue Jr. commented on CONTINUUM-1387:


sounds like a good plan! :) thanks jesse! will try to implement your solution...

> Can't initiate a build of a new project in continuum until all modules have 
> been checked out
> 
>
> Key: CONTINUUM-1387
> URL: http://jira.codehaus.org/browse/CONTINUUM-1387
> Project: Continuum
>  Issue Type: Bug
>Affects Versions: 1.1-beta-1
>Reporter: Wendy Smoak
>Assignee: Teodoro Cue Jr.
>
> When a multi-module project is added to continuum, a working copy of each 
> module is extracted from subversion.
> Typically after adding a project I want to kick off a build.
> If I initiate the build before all the modules are extracted, the ones that 
> have not yet been fully extracted will not be queued for build. Only those 
> already fully extracted will be built.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MECLIPSE-318) test classes and resources need to be first in .classpath file

[Jim Sellers (JIRA)]

test classes and resources need to be first in .classpath file
--

 Key: MECLIPSE-318
 URL: http://jira.codehaus.org/browse/MECLIPSE-318
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Improvement
Reporter: Jim Sellers


They have changed the core dependancy resolution to be "tests first".  I'm 
assuming that the plug-in will need to be changed to reflect this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (ARCHETYPE-83) archetypeng:create crashes with java.lang.ClassNotFoundException: org.apache.maven.plugin.resource.loader.ProjectResourceLoader

[Brian Fox (JIRA)]

 [ 
http://jira.codehaus.org/browse/ARCHETYPE-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Fox closed ARCHETYPE-83.
--

  Assignee: Brian Fox
Resolution: Cannot Reproduce

i can't reproduce this anymore

> archetypeng:create crashes with java.lang.ClassNotFoundException: 
> org.apache.maven.plugin.resource.loader.ProjectResourceLoader
> ---
>
> Key: ARCHETYPE-83
> URL: http://jira.codehaus.org/browse/ARCHETYPE-83
> Project: Maven Archetype
>  Issue Type: Bug
>  Components: Plugin
>Affects Versions: NG-1.0-alpha-1
>Reporter: Brian Fox
>Assignee: Brian Fox
>
> {noformat}
> E:\svn\Maven\atest>mvn archetypeng:create
> Using maven.home=c:\Program Files\maven2\bin\\..
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'archetypeng'.
> [INFO] 
> 
> [INFO] Building Maven Default Project
> [INFO]task-segment: [archetypeng:create] (aggregator-style)
> [INFO] 
> 
> [INFO] Preparing archetypeng:create
> [INFO] [archetypeng:select-archetype]
> Choose group:
> 1: org.apache.maven.its
> Choose a number:  (1): 1
> [INFO] org.apache.maven.its: checking for updates from central
> Choose archetype:
> 1: Unnamed - 
> org.apache.maven.its:maven-integration-test-archetype:maven-archetype:1.0-SNAPSHOT
>  (org.apache.maven.its:maven-integrat
> ion-test-archetype)
> Choose a number:  (1): 1
> [INFO] org.apache.maven.its.maven-integration-test-archetype: checking for 
> updates from central
> Choose version:
> 1: 1.0-SNAPSHOT
> Choose a number:  (1): 1
> Confirm archetype selection:
> org.apache.maven.its/Unnamed - 
> org.apache.maven.its:maven-integration-test-archetype:maven-archetype:1.0-SNAPSHOT
>  (Y/N) Y: : Y
> [INFO] Setting property: file.resource.loader.class => 
> 'org.apache.maven.plugin.resource.loader.ProjectResourceLoader'.
> [INFO] Setting property: class.resource.loader.class => 
> 'org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader'.
> [INFO] Setting property: resource.loader => 'file,class'.
> [ERROR] Problem instantiating the template loader.
> Look at your properties file and make sure the
> name of the template loader is correct. Here is the
> error: java.lang.ClassNotFoundException: 
> org.apache.maven.plugin.resource.loader.ProjectResourceLoader
> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at 
> org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195)
> at 
> org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255)
> at 
> org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274)
> at 
> org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:164)
> at 
> org.apache.velocity.runtime.resource.loader.ResourceLoaderFactory.getLoader(ResourceLoaderFactory.java:41)
> at 
> org.apache.velocity.runtime.resource.ResourceManagerImpl.initialize(ResourceManagerImpl.java:142)
> at 
> org.apache.velocity.runtime.RuntimeInstance.initializeResourceManager(RuntimeInstance.java:522)
> at 
> org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:227)
> at org.apache.velocity.app.VelocityEngine.init(VelocityEngine.java:80)
> at 
> org.codehaus.plexus.velocity.DefaultVelocityComponent.initialize(DefaultVelocityComponent.java:79)
> at 
> org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializePhase.execute(InitializePhase.java:16)
> at 
> org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101)
> at 
> org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105)
> at 
> org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95)
> at 
> org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java
> :92)
> at 
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331)
> at 
> o

[jira] Closed: (MASSEMBLY-222) 2.2-beta-1 regression in assembly descriptor interpolation

[John Casey (JIRA)]

 [ 
http://jira.codehaus.org/browse/MASSEMBLY-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey closed MASSEMBLY-222.


Resolution: Fixed

I've changed it so pom.* refers to the current pom being built, while 
artifact.* and module.* refer to the current artifact in process, its project 
instance, and it's associated artifact handler...incidentally, 
artifact.handler.* and module.handler.* are also available.

The module.* syntax should only be used inside the moduleSets section.

> 2.2-beta-1 regression in assembly descriptor interpolation
> --
>
> Key: MASSEMBLY-222
> URL: http://jira.codehaus.org/browse/MASSEMBLY-222
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Max Bowsher
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.2-beta-2
>
>
> I have found a significant change in behaviour between 2.1 and 2.2-beta-1, 
> using the following assembly descriptor:
> {code:xml}
> 
>   dist
>   
> tar.gz
>   
>   no
>   
> 
>   /foobar-${version}
>   
> README.txt
> changelog.txt
> java.policy
>   
> 
> 
>   target
>   /foobar-${version}/jars
>   
> foobar-${version}.jar
>   
> 
> 
>   src/main/scripts
>   /foobar-${version}/bin
>   0755
> 
>   
>   
> 
>   /foobar-${version}/jars
>   false
> 
>   
> 
> {code}
> Using 2.1, ${version} interpolates with the version of the project being 
> assembled.
> Using 2.2-beta-1, the ${version} in the  interpolates with the 
> version of each individual dependency, leading to the  being 
> scattered across many directories.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (ARCHETYPE-91) create is prompting for a package

[Brian Fox (JIRA)]

create is prompting for a package
-

 Key: ARCHETYPE-91
 URL: http://jira.codehaus.org/browse/ARCHETYPE-91
 Project: Maven Archetype
  Issue Type: Bug
  Components: Generator
Affects Versions: NG-1.0-alpha-1
Reporter: Brian Fox


shouldn't the package type of the created project be the same as the one in the 
archetype? It doesn't make sense to take a war, make an archetype and then 
allow the user to generate it as a jar.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (ARCHETYPE-90) all the contents of an archetype shouldn't be processed by velocity during creation

[Brian Fox (JIRA)]

all the contents of an archetype shouldn't be processed by velocity during 
creation
---

 Key: ARCHETYPE-90
 URL: http://jira.codehaus.org/browse/ARCHETYPE-90
 Project: Maven Archetype
  Issue Type: Bug
  Components: Creator
Affects Versions: NG-1.0-alpha-1
Reporter: Brian Fox


Archetypes may contain contents that shouldn't be processed. The IT sample is 
one:

{noformat}
[WARNING] org.apache.velocity.runtime.exception.ReferenceException: reference : 
template = archetype-resources/src/test/resources/mng--descriptionOfProblem/
checkstyle-test/pom.xml [line 42,column 26] : ${project.build.directory} is not 
a valid reference.
{noformat}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (ARCHETYPE-89) archetypeng:create doesn't use configured repos to find artifacts

[Brian Fox (JIRA)]

archetypeng:create doesn't use configured repos to find artifacts
-

 Key: ARCHETYPE-89
 URL: http://jira.codehaus.org/browse/ARCHETYPE-89
 Project: Maven Archetype
  Issue Type: Bug
Affects Versions: NG-1.0-alpha-1
Reporter: Brian Fox


I deployed a snapshot of the archetype and create isn't finding it even though 
i have the maven-snapshot repo in my settings. A secondary problem is that if 
nothing is found, you get into an infinite loop where it asks you to pick a 
number that isn't there.

{noformat}
$ mvn.bat archetypeng:create
Using maven.home=c:\Program Files\maven2\bin\\..
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'archetypeng'.
[INFO] 

[INFO] Building Maven Default Project
[INFO]task-segment: [archetypeng:create] (aggregator-style)
[INFO] 

[INFO] Preparing archetypeng:create
[INFO] [archetypeng:select-archetype]
Choose group:
1: org.apache.maven.archetypes
2: org.codehaus.mojo.archetypes
3: org.apache.maven.its
Choose a number:  (1/2/3): 3
[INFO] org.apache.maven.its: checking for updates from central
Choose archetype:
Choose a number: :
{noformat}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (ARCHETYPE-88) sometimes add-groups fails when there is a pom present

[Brian Fox (JIRA)]

sometimes add-groups fails when there is a pom present
--

 Key: ARCHETYPE-88
 URL: http://jira.codehaus.org/browse/ARCHETYPE-88
 Project: Maven Archetype
  Issue Type: Bug
Affects Versions: NG-1.0-alpha-1
Reporter: Brian Fox


{noformat}
[EMAIL PROTECTED] 
/cygdrive/e/svn/Maven/maven-it-tests/maven-integration-test-archetype
$ mvn.bat archetypeng:add-groups -Dgroups=org.apache.maven.something
Using maven.home=c:\Program Files\maven2\bin\\..
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'archetypeng'.
[INFO] 

[INFO] Building Unnamed - 
org.apache.maven.its:maven-integration-test-sample-archetype:maven-archetype:1.0-SNAPSHOT
[INFO]task-segment: [archetypeng:add-groups] (aggregator-style)
[INFO] 

[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Internal error in the plugin manager executing goal 
'org.apache.maven.plugins:maven-archetypeng-plugin:1.0-SNAPSHOT:add-groups': 
Unable to find the mojo
'org.apache.maven.plugins:maven-archetypeng-plugin:1.0-SNAPSHOT:add-groups' in 
the plugin 'org.apache.maven.plugins:maven-archetypeng-plugin'
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 4 seconds
[INFO] Finished at: Tue Aug 21 21:05:49 EDT 2007
[INFO] Final Memory: 6M/13M
[INFO] 
{noformat}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (ARCHETYPE-82) add-groups doesn't create archetype.xml

[Brian Fox (JIRA)]

[ 
http://jira.codehaus.org/browse/ARCHETYPE-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105378
 ] 

Brian Fox commented on ARCHETYPE-82:


verified this is ok.

> add-groups doesn't create archetype.xml
> ---
>
> Key: ARCHETYPE-82
> URL: http://jira.codehaus.org/browse/ARCHETYPE-82
> Project: Maven Archetype
>  Issue Type: Bug
>Affects Versions: NG-1.0-alpha-1
>Reporter: Brian Fox
>
> {noformat}
> E:\svn\Maven\atest>mvn archetypeng:add-groups -Dgroups=org.apache.maven.its
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'archetypeng'.
> [INFO] 
> 
> [INFO] Building Maven Default Project
> [INFO]task-segment: [archetypeng:add-groups] (aggregator-style)
> [INFO] 
> 
> [INFO] [archetypeng:add-groups]
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] C:\Documents and Settings\brianf\.m2\archetype.xml (The system cannot 
> find the file specified)
> [INFO] 
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO] 
> 
> [INFO] Total time: 4 seconds
> [INFO] Finished at: Wed Aug 08 21:48:18 EDT 2007
> [INFO] Final Memory: 5M/10M
> [INFO] 
> 
> {noformat}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (ARCHETYPE-87) create-from-project replaces too many things in the pom with variables

[Brian Fox (JIRA)]

create-from-project replaces too many things in the pom with variables
--

 Key: ARCHETYPE-87
 URL: http://jira.codehaus.org/browse/ARCHETYPE-87
 Project: Maven Archetype
  Issue Type: Bug
Affects Versions: NG-1.0-alpha-1
Reporter: Brian Fox
Priority: Blocker


Using the maven-integration-test-sample project, and create-from-project, I 
find that the processed pom has every fragment of the group,artifactid and 
version replaced. It's not a safe assumption that everything with the same 
version (and other values) should be generic. For example, if my sample project 
has 1.0 as a version, every version 1.0 will be replaced, even if it's 
something completely unrelated to my project. 

Example output:
{noformat}

  4.0.0 
  ${groupId}
  ${artifactId}
  ${version}
  Maven Integration Tests
  

  org.apache.maven.shared
  maven-verifier
  1.0


  org.apache.maven.its
  maven-integration-test-helper
  ${version}

{noformat}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (CONTINUUM-1387) Can't initiate a build of a new project in continuum until all modules have been checked out

[Jesse McConnell (JIRA)]

[ 
http://jira.codehaus.org/browse/CONTINUUM-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105376
 ] 

Jesse McConnell commented on CONTINUUM-1387:


if there is an easy way to block the build queuing process until continuum has 
had a change to fully initialize upon adding the project, I would prefer that 
solution personally..

new queuing structures smell like new features to me and we are in beta for 1.1 
:)

but thats just my opinion.  

the build process will checkout on an empty project directory, that is how the 
'Build Fresh' feature works, it smokes the stuff in that directory and then the 
build process just checks it back out.

odds are you would be ok just removing that checkout queue check like you were 
thinking of...could you maybe on the build check if it is in the checkout queue 
and if it is wack it out of there and then add into the build queue since we 
know the build process will check it out anyway?



> Can't initiate a build of a new project in continuum until all modules have 
> been checked out
> 
>
> Key: CONTINUUM-1387
> URL: http://jira.codehaus.org/browse/CONTINUUM-1387
> Project: Continuum
>  Issue Type: Bug
>Affects Versions: 1.1-beta-1
>Reporter: Wendy Smoak
>Assignee: Teodoro Cue Jr.
>
> When a multi-module project is added to continuum, a working copy of each 
> module is extracted from subversion.
> Typically after adding a project I want to kick off a build.
> If I initiate the build before all the modules are extracted, the ones that 
> have not yet been fully extracted will not be queued for build. Only those 
> already fully extracted will be built.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2254) the encoding parameter in xml declaration of POM is ignored

[Herve Boutemy (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105371
 ] 

Herve Boutemy commented on MNG-2254:


the 2 latest only are to be applied:
- MNG-2254_artifact.diff for maven/artifact/trunk and 
maven/components/branches/maven-2.0.x/maven-artifact
- MNG-2254_components.diff for maven/components/trunk and 
maven/components/branches/maven-2.0.x

> the encoding parameter in xml declaration of POM is ignored 
> 
>
> Key: MNG-2254
> URL: http://jira.codehaus.org/browse/MNG-2254
> Project: Maven 2
>  Issue Type: Bug
>  Components: POM::Encoding
>Reporter: Naoki Nose
>Assignee: Jason van Zyl
> Fix For: 2.0.8
>
> Attachments: DefaultMavenProjectBuilder.diff, MNG-2254-2.diff, 
> MNG-2254.diff, MNG-2254_artifact.diff, MNG-2254_components.diff, 
> modello-plugin-xpp3.diff
>
>
> DefaultMavenProjectBuilder reads POM in system default character encoding, 
> and the encoding parameter in xml declartion is ignored.
> to fix this problem, We should
> -  fix  modello-plugin-xpp3 to use the xml parser which is able to handle the 
> encoding parameter properly
> - regenerate maven-model using fixed modello-plugin-xpp3
> - fix DefaultMavenProjectBuilder to use regenerated maven-model properly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Issue Comment Edited: (MNG-2254) the encoding parameter in xml declaration of POM is ignored

[Herve Boutemy (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105371
 ] 

Herve Boutemy edited comment on MNG-2254 at 8/21/07 5:02 PM:
-

the 2 latest only are to be applied:
- {{MNG-2254_artifact.diff}} for maven/artifact/trunk and 
maven/components/branches/maven-2.0.x/maven-artifact
- {{MNG-2254_components.diff}} for maven/components/trunk and 
maven/components/branches/maven-2.0.x


 was:
the 2 latest only are to be applied:
- MNG-2254_artifact.diff for maven/artifact/trunk and 
maven/components/branches/maven-2.0.x/maven-artifact
- MNG-2254_components.diff for maven/components/trunk and 
maven/components/branches/maven-2.0.x

> the encoding parameter in xml declaration of POM is ignored 
> 
>
> Key: MNG-2254
> URL: http://jira.codehaus.org/browse/MNG-2254
> Project: Maven 2
>  Issue Type: Bug
>  Components: POM::Encoding
>Reporter: Naoki Nose
>Assignee: Jason van Zyl
> Fix For: 2.0.8
>
> Attachments: DefaultMavenProjectBuilder.diff, MNG-2254-2.diff, 
> MNG-2254.diff, MNG-2254_artifact.diff, MNG-2254_components.diff, 
> modello-plugin-xpp3.diff
>
>
> DefaultMavenProjectBuilder reads POM in system default character encoding, 
> and the encoding parameter in xml declartion is ignored.
> to fix this problem, We should
> -  fix  modello-plugin-xpp3 to use the xml parser which is able to handle the 
> encoding parameter properly
> - regenerate maven-model using fixed modello-plugin-xpp3
> - fix DefaultMavenProjectBuilder to use regenerated maven-model properly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-2254) the encoding parameter in xml declaration of POM is ignored

[Andrew Williams (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105369
 ] 

Andrew Williams commented on MNG-2254:
--

Can you please clarify which patches apply and which do not

> the encoding parameter in xml declaration of POM is ignored 
> 
>
> Key: MNG-2254
> URL: http://jira.codehaus.org/browse/MNG-2254
> Project: Maven 2
>  Issue Type: Bug
>  Components: POM::Encoding
>Reporter: Naoki Nose
>Assignee: Jason van Zyl
> Fix For: 2.0.8
>
> Attachments: DefaultMavenProjectBuilder.diff, MNG-2254-2.diff, 
> MNG-2254.diff, MNG-2254_artifact.diff, MNG-2254_components.diff, 
> modello-plugin-xpp3.diff
>
>
> DefaultMavenProjectBuilder reads POM in system default character encoding, 
> and the encoding parameter in xml declartion is ignored.
> to fix this problem, We should
> -  fix  modello-plugin-xpp3 to use the xml parser which is able to handle the 
> encoding parameter properly
> - regenerate maven-model using fixed modello-plugin-xpp3
> - fix DefaultMavenProjectBuilder to use regenerated maven-model properly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MSITE-239) encoding declaration in site.xml is ignored

[Andrew Williams (JIRA)]

 [ 
http://jira.codehaus.org/browse/MSITE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Williams closed MSITE-239.
-

Resolution: Fixed

Fixed but no new snapshot deployed, awaiting response from the site maintainers 
as before

> encoding declaration in site.xml is ignored
> ---
>
> Key: MSITE-239
> URL: http://jira.codehaus.org/browse/MSITE-239
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>Affects Versions: 2.0-beta-4, 2.0-beta-5
>Reporter: Herve Boutemy
> Fix For: 2.0-beta-6
>
> Attachments: MSITE-239.diff, MSITE-239.tgz
>
>
> when PLXUTILS-11 will be fixed, and XmlReader will be available, there won't 
> be any problem to fix this one

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MAVENUPLOAD-1678) please upload new jdeb version 0.2

[Torsten Curdt (JIRA)]

please upload new jdeb version 0.2
--

 Key: MAVENUPLOAD-1678
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1678
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Torsten Curdt




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-66) Ability to index into a nominated dependency JAR to identify files to include in the assembly (Im thinking .so/.dll etc)

[Andy Brook (JIRA)]

[ 
http://jira.codehaus.org/browse/MASSEMBLY-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105361
 ] 

Andy Brook commented on MASSEMBLY-66:
-

I haven't looked recently, I'll make a note to check those options 

> Ability to index into a nominated dependency JAR to identify files to include 
> in the assembly (Im thinking .so/.dll etc)
> 
>
> Key: MASSEMBLY-66
> URL: http://jira.codehaus.org/browse/MASSEMBLY-66
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Improvement
> Environment: Linux, x86_64, x86, win32
>Reporter: Andy Brook
> Fix For: 2.2
>
>
> Im trying to bundle a SWT application, I'm almost there, the only thing 
> missing is the ability to include .so files in the assembly that are 
> currently stored inside a dependancy.  As far as I can tell there is no neat 
> way to pull a few files out of a given dependency...
> My example is the SWT libraries, the GTK linux specific JAR in the eclipse 
> bundle also contain the native libraries.  Ive renamed this to fit into a 
> maven2 repository, but really dont want to have to copy the files manually.
> Ideally, I would like to be able to specify the dependency in mind and extend 
> the fileSet element to allow the context of the include to work only within 
> that dependency.
> If there is something Im missing and this can be done with existing plugins 
> Id like to hear about it!
> eg:
> ::POM::
>
> 
>   org.eclipse.swt
>   gtk-linux-x86
>   3.1.1
>   runtime
> 
> ::assembly-descriptor.xml::
> 
>   
>   org.eclipse.swt:gtk-linux-x86:3.1.1
>   /lib
>   
>   *.so
>   
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-34) Check site for dead links

[Dennis Lundberg (JIRA)]

[ 
http://jira.codehaus.org/browse/MSITE-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105360
 ] 

Dennis Lundberg commented on MSITE-34:
--

Count me in as well. This is something that we need.

> Check site for dead links
> -
>
> Key: MSITE-34
> URL: http://jira.codehaus.org/browse/MSITE-34
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>Reporter: Jason van Zyl
>
> We could use the m1 link checking plugin or we can steal a bit of code from 
> xstream which has some link checking code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MAVENUPLOAD-1677) Please sync with maven-har repo

[Tom Cort (JIRA)]

Please sync with maven-har repo
---

 Key: MAVENUPLOAD-1677
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1677
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Tom Cort


Please sync with maven-har's repo. The shell can be found at
http://maven-har.sourceforge.net/net.sf.maven-har.sh

The repo contains jars for binary, source and javadoc, release 0.9.

I can't subscribe to the Maven repository mailing list for the same reason 
mentioned in http://jira.codehaus.org/browse/MNGSITE-17

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MAVENUPLOAD-1651) junit 4.4

[Carlos Sanchez (JIRA)]

 [ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carlos Sanchez closed MAVENUPLOAD-1651.
---

  Assignee: Carlos Sanchez  (was: Mauro Talevi)
Resolution: Fixed

I have uploaded the 4.4 available for download in their web site. If they 
release another binary without the bundled 3rd party classes we' ll put it too 

> junit 4.4
> -
>
> Key: MAVENUPLOAD-1651
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1651
> Project: maven-upload-requests
>  Issue Type: Bug
>Reporter: Tomislav Stojcevich
>Assignee: Carlos Sanchez
> Attachments: junit-4.4-bundle.jar, junit-4.4-bundle.jar, 
> junit-4.4-bundle.jar
>
>
> Upload new version.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MAVENUPLOAD-1651) junit 4.4

[Carlos Sanchez (JIRA)]

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105356
 ] 

Carlos Sanchez commented on MAVENUPLOAD-1651:
-

Jose, what I mean is that only official releases built by the junit team will 
be uploaded to the junit group in the repo. You can't take their sources and 
recompile, put or remove things from the library, and get it uploaded to the 
junit group.

> junit 4.4
> -
>
> Key: MAVENUPLOAD-1651
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1651
> Project: maven-upload-requests
>  Issue Type: Bug
>Reporter: Tomislav Stojcevich
>Assignee: Mauro Talevi
> Attachments: junit-4.4-bundle.jar, junit-4.4-bundle.jar, 
> junit-4.4-bundle.jar
>
>
> Upload new version.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MAVENUPLOAD-1659) rhino-js-1.6R6

[Carlos Sanchez (JIRA)]

 [ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carlos Sanchez closed MAVENUPLOAD-1659.
---

  Assignee: Carlos Sanchez  (was: Mauro Talevi)
Resolution: Fixed

you can get it in this repo http://repo1.maven.org/maven [ 
http://repo1.maven.org/maven/rhino/jars/js-1.6R6.jar ]
Note that it's a redirection, you won' t see the jar in 
http://repo1.maven.org/maven/rhino/jars but can be downloaded anyway

> rhino-js-1.6R6
> --
>
> Key: MAVENUPLOAD-1659
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1659
> Project: maven-upload-requests
>  Issue Type: Task
>Reporter: Marc Guillemot
>Assignee: Carlos Sanchez
>
> Downloaded from http://developer.mozilla.org/en/docs/Rhino_downloads
> New features in 1.6R6 can be found at 
> http://developer.mozilla.org/en/docs/New_in_Rhino_1.6R6

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MAVENUPLOAD-1672) Request to upload MyDas Distributed Annotation Server core jar.

[Carlos Sanchez (JIRA)]

 [ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carlos Sanchez closed MAVENUPLOAD-1672.
---

  Assignee: Carlos Sanchez
Resolution: Fixed

> Request to upload MyDas Distributed Annotation Server core jar.
> ---
>
> Key: MAVENUPLOAD-1672
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1672
> Project: maven-upload-requests
>  Issue Type: Wish
>Reporter: Philip Jones
>Assignee: Carlos Sanchez
>
> http://code.google.com/p/mydas/
> Developers:
> http://www.ebi.ac.uk/Information/Staff/person_maint.php?s_person_id=471
> http://www.ebi.ac.uk/Information/Staff/person_maint.php?s_person_id=479
> MyDas is a new DAS (Distributed Annotation System) Server API, written in 
> Java.  It is built using Maven 2 and the template project also uses Maven 2, 
> so having this jar uploaded to the public Maven repository would be very 
> useful!
> It is now stable - a publicly available example implementation of this server 
> can be viewed at http://www.ebi.ac.uk/das-srv/uniprot/das
> Best regards,
> Phil.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MSITE-239) encoding declaration in site.xml is ignored

[Herve Boutemy (JIRA)]

 [ 
http://jira.codehaus.org/browse/MSITE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy updated MSITE-239:


Attachment: (was: MSITE-239.diff)

> encoding declaration in site.xml is ignored
> ---
>
> Key: MSITE-239
> URL: http://jira.codehaus.org/browse/MSITE-239
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>Affects Versions: 2.0-beta-4, 2.0-beta-5
>Reporter: Herve Boutemy
> Fix For: 2.0-beta-6
>
> Attachments: MSITE-239.diff, MSITE-239.tgz
>
>
> when PLXUTILS-11 will be fixed, and XmlReader will be available, there won't 
> be any problem to fix this one

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MSITE-239) encoding declaration in site.xml is ignored

[Herve Boutemy (JIRA)]

 [ 
http://jira.codehaus.org/browse/MSITE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy updated MSITE-239:


Attachment: MSITE-239.diff

re-did the patch with latest trunk revision

> encoding declaration in site.xml is ignored
> ---
>
> Key: MSITE-239
> URL: http://jira.codehaus.org/browse/MSITE-239
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>Affects Versions: 2.0-beta-4, 2.0-beta-5
>Reporter: Herve Boutemy
> Fix For: 2.0-beta-6
>
> Attachments: MSITE-239.diff, MSITE-239.tgz
>
>
> when PLXUTILS-11 will be fixed, and XmlReader will be available, there won't 
> be any problem to fix this one

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MAVENUPLOAD-1666) upload vraptor 2.4

[Carlos Sanchez (JIRA)]

 [ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carlos Sanchez closed MAVENUPLOAD-1666.
---

  Assignee: Carlos Sanchez
Resolution: Fixed

> upload vraptor 2.4
> --
>
> Key: MAVENUPLOAD-1666
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1666
> Project: maven-upload-requests
>  Issue Type: Task
>Reporter: Fabio Kung
>Assignee: Carlos Sanchez
> Attachments: org.vraptor.sh
>
>
> upload vraptor 2.2
> file: http://www.vraptor.org/vraptor-2.2-bundle.jar
> project: http://www.vraptor.org
> team: http://www.vraptor.org/team-list.html
> VRaptor 2.2 framework update with many improvements and new docs.
>  
>  VRaptor 2 is a mvc controller based on the idea (stolen) from Rails
>  that configuration should be minimal and conventions should be
>  maximized.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MEV-543) XML Security 1.3.0 missing POM

[Carlos Sanchez (JIRA)]

[ 
http://jira.codehaus.org/browse/MEV-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105350
 ] 

Carlos Sanchez commented on MEV-543:


you have to provide a pom with at least the minimal info listed in 
http://maven.apache.org/guides/mini/guide-central-repository-upload.html

> XML Security 1.3.0 missing POM
> --
>
> Key: MEV-543
> URL: http://jira.codehaus.org/browse/MEV-543
> Project: Maven Evangelism
>  Issue Type: Improvement
>  Components: Missing POM
>Reporter: Stefano Mazzocchi
>
> Based on version 1.2.1 that has a POM, I think that 
> 
> 4.0.0
> xml-security
> xmlsec
> 1.3.0
> 
> should be enough as a POM for this 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] Updated: (MNG-2861) NullPointerException in DefaultArtifactCollector for relocated resolvedArtifacts with different version ranges and available versions.

[Micah Whitacre (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Micah Whitacre updated MNG-2861:


Attachment: MNG-2861_broken.zip

Your testcase worked for me as well.  I found that there was a difference 
between how your relocation POMs look compared the ones that were deployed in 
our repo.  The difference was that in your relocation POM you have the 
following information:

  

  newgroupId
  project
  1.2

  

vs. in our relocation POMs we just have this:



newgroupId



What we have follows the minimal required POM as documented on the Maven 
site.[1]

The attachment includes a modified version of your repository (I didn't 
regenerate the checksums) so that it follows what we have.  In that case I get 
the NPE for which this issue is logged.

[1] - http://maven.apache.org/guides/mini/guide-relocation.html

> NullPointerException in DefaultArtifactCollector for relocated 
> resolvedArtifacts with different version ranges and available versions.
> --
>
> Key: MNG-2861
> URL: http://jira.codehaus.org/browse/MNG-2861
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.5
>Reporter: Micah Whitacre
> Fix For: 2.0.x
>
> Attachments: MNG-2861-maven-project.patch, MNG-2861.tar.gz, 
> MNG-2861_broken.zip
>
>
> In a remoteRepository that I am populating I have a project.  Previously I 
> was deploying artifacts with an old groupId and then decided to switch to 
> having a new more descriptive groupId.  For the old groupId I have deployed 
> versions 1.0 and 1.1.  For the new groupId I have deployed 1.2 and 2.0.  I 
> deployed a relocation POM to the old groupId for the 1.2 version.  I also 
> updated the metadata.xml files to include 1.2 as an available version.  This 
> way projects using version ranges [1,2) will be able to pick up the newest 
> version.  So in the repository I now have:
> oldgroupId:project:1.0
> oldgroupId:project:1.1
> oldgroupId:project:1.2 - redirecting to newgroupId:project:1.2
> newgroupId:project:1.2
> newgroupId:project:2.0
> The oldgroupId's metadata lists the available versions as [1.0,1.1,1.2].  The 
> newgroupId's metadata lists the available versions has [1,2].
> I have 3 additional projects A, B, C.  A depends on B and C.  B depends on 
> oldgroupId:project:[1,2).  Project B has also finished development and been 
> released so we are avoiding rereleasing it for the groupId change.   C 
> depends on newgroupId:project:[2,3).  When I try to build project A, Maven 
> dies and gives me the following stack trace.
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] null
> [INFO] 
> 
> [DEBUG] Trace
> java.lang.NullPointerException
>   at 
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:168)
>   at 
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:305)
>   at 
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:305)
>   at 
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:70)
>   at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284)
>   at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272)
>   at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:243)
>   at 
> org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1142)
>   at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:374)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
>

[jira] Created: (MDEP-105) Make it possible to copy all dependencies (and their transitive ones) excluding a few (and their transitive ones)

[Stefano Mazzocchi (JIRA)]

Make it possible to copy all dependencies (and their transitive ones) excluding 
a few (and their transitive ones)
-

 Key: MDEP-105
 URL: http://jira.codehaus.org/browse/MDEP-105
 Project: Maven 2.x Dependency Plugin
  Issue Type: Wish
  Components: copy
Reporter: Stefano Mazzocchi
Assignee: Brian Fox


While it is currently possible to exclude particular artifacts from being 
copied, this happens after the transitive dependencies have been evaluated. 
This makes it impossible to exclude one artifacts along with all their 
transitive dependencies. A suggestion (don't know how feasible this is) would 
be to have two exclusion lists, one that gets applied before the transitive 
dependency is called and one after.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MEV-543) XML Security 1.3.0 missing POM

[Stefano Mazzocchi (JIRA)]

XML Security 1.3.0 missing POM
--

 Key: MEV-543
 URL: http://jira.codehaus.org/browse/MEV-543
 Project: Maven Evangelism
  Issue Type: Improvement
  Components: Missing POM
Reporter: Stefano Mazzocchi


Based on version 1.2.1 that has a POM, I think that 


4.0.0
xml-security
xmlsec
1.3.0


should be enough as a POM for this 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] Commented: (MASSEMBLY-231) Allow Assembly plugin to specify alternate DistributionManagement

[Andrew Williams (JIRA)]

[ 
http://jira.codehaus.org/browse/MASSEMBLY-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105344
 ] 

Andrew Williams commented on MASSEMBLY-231:
---

Indenting is broken in 
src/it/repositories/basic-repository-deploys-artifact-with-distribution-management/pom.xml
 at least

> Allow Assembly plugin to specify alternate DistributionManagement
> -
>
> Key: MASSEMBLY-231
> URL: http://jira.codehaus.org/browse/MASSEMBLY-231
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Improvement
>Affects Versions: 2.2-beta-2
>Reporter: James William Dumay
> Attachments: maven-assembly-plugin.patch, maven-assembly-plugin.patch
>
>
> The following patch allows the assembly plugin to specify alternate 
> repository locations for deployment of its attached 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: (MNG-3152) Change to plugin testing harness to allow the setting of ArtifactRepository on the ArtifactStub

[Andrew Williams (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-3152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Williams closed MNG-3152.


 Assignee: Andrew Williams
   Resolution: Fixed
Fix Version/s: 2.0.8

> Change to plugin testing harness to allow the setting of ArtifactRepository 
> on the ArtifactStub
> ---
>
> Key: MNG-3152
> URL: http://jira.codehaus.org/browse/MNG-3152
> Project: Maven 2
>  Issue Type: Improvement
>Affects Versions: 2.0.8
>Reporter: James William Dumay
>Assignee: Andrew Williams
> Fix For: 2.0.8
>
> Attachments: maven-plugin-testing-harness.patch
>
>
> Change to plugin testing harness to allow the setting of ArtifactRepository 
> on the ArtifactStub

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2399) file size check on pom.xml (or thing specified by --file opt) should only apply to regular files (patch attached)

[Jason van Zyl (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105342
 ] 

Jason van Zyl commented on MNG-2399:


Is it really that hard to generate the POM first? And I'm not sure this great 
usage pattern.

> file size check on pom.xml (or thing specified by --file opt) should only 
> apply to regular files (patch attached)
> -
>
> Key: MNG-2399
> URL: http://jira.codehaus.org/browse/MNG-2399
> Project: Maven 2
>  Issue Type: Bug
>  Components: Command Line, General
>Affects Versions: 2.0.4
>Reporter: Alan D. Salewski
>Priority: Minor
> Fix For: 2.0.x
>
> Attachments: MNG-2399-maven-core-2.0.4.patch, 
> MNG-2399-maven-core-trunk.patch, mvn-get-plugin
>
>
> The file size check in {{maven-core/.../org/apache/maven/DefaultMaven.java}} 
> is applied too aggressively. In particular, it should only be applied to 
> regular files; when reading from a unix named pipe (probably other 
> platform-specific devices, too) we may not be able to determine the file size 
> prior to reading the data.
> The real-world motiviation from this is the attached '{{mvn-get-plugin}}' 
> {{bash}} script, which wants to pipe a dummy {{pom.xml}} file to {{mvn}} on 
> {{stdin}} (by specifying {{/dev/stdin}} as the argument to the {{mvn}} 
> {{\-\-file}} command line option).
> Once I submit this issue and have the issue number, I'll attach two patches, 
> one against the maven svn trunk, and one against the {{maven-2.0.4}} tag.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-3151) Allow plugins that attach artifacts to specify deployment locations

[Jason van Zyl (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105339
 ] 

Jason van Zyl commented on MNG-3151:


I'm not sure this is really something we want to encourage. Why would you want 
to separate the javadoc, and sources from the original artifact?

> Allow plugins that attach artifacts to specify deployment locations
> ---
>
> Key: MNG-3151
> URL: http://jira.codehaus.org/browse/MNG-3151
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Artifacts and Repositories, General
>Affects Versions: 2.0.8
>Reporter: James William Dumay
>Assignee: Brett Porter
> Fix For: 2.0.8
>
> Attachments: MNG-3151-maven-2.0.x.patch
>
>
> The following patch allows plugins to specify Distribution Management 
> relating to their attached artifacts.
> This is useful in large Java shops where, depending on the type of artifact 
> (Javadoc, source, assembly, etc)m you may want to deploy these artifacts to 
> different repositories (eg public and private).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MDEPLOY-46) "mvn -DaltDeploymentRepository=... deploy" of a SNAPSHOT doesn't replace date.buildnumber

[Mikko Koponen (JIRA)]

 [ 
http://jira.codehaus.org/browse/MDEPLOY-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikko Koponen updated MDEPLOY-46:
-

Attachment: MDEPLOY-46.patch

Attaching a one-liner patch to fix this issue.

I ain't no maven expert, so I really don't know if there is a valid reason to 
not use unique versions for alt deployment repos for some reason. If so, I 
suppose the altDeploymentRepository syntax could be extended to allow this 
flag. 

> "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] Issue Comment Edited: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails

[Sebastian Annies (JIRA)]

[ 
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105305
 ] 

Sebastian Annies edited comment on CONTINUUM-1402 at 8/21/07 10:16 AM:
---

MORE READABLE HERE:

When a client is created it is named:

E.g. 
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}

that is ok, but now comes the sync command and uses following commandline

{{/bin/bash c "p4 -d 
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
 
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
 sync"}}

The Bash now removes the backslashes in the client name! The result is that the 
client is not existent and perforce returns with an error.

I think continuum does everything allright but we need the ticket here to be 
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.

The Problem starts in 'PerforceCheckOutCommand':


{quote}public static Commandline createCommandLine( 
PerforceScmProviderRepository repo, File workingDirectory,
   ScmVersion version, 
String specname )
{
 Commandline command = PerforceScmProvider.createP4Command( repo, 
workingDirectory );
 {color:red}command.createArgument().setValue( "-c" + specname );{color}
 command.createArgument().setValue( "sync" );
 
 // Use a simple heuristic to determine if we should use the Force flag
 // on sync. Forcing sync is a HUGE performance hit but is required in
 // rare instances where source is somehow deleted. If the target
 // directory is completely empty, assume a force is required. If
 // not empty, we assume a previous checkout was already done and a normal
 // sync will suffice.
 // SCM-110
 String[] files = workingDirectory.list();
 if ( files == null || files.length == 0 )
 \{ 
  // We need to force so checkout to an empty directory will work.   
  command.createArgument().setValue( "-f" ); 
 \}
  // Not sure what to do here. I'm unclear whether we should be
  // sync'ing each file individually to the label or just sync the
  // entire contents of the workingDir. I'm going to assume the
  // latter until the exact semantics are clearer.
  if ( version != null && StringUtils.isNotEmpty( version.getName() ) )  \{ 
 command.createArgument().setValue( "@" + version.getName() ); 
 \}
 }

{quote}

The {{specname}} contains the backslashes and is these are neither escaped nor 
quoted! Hmm ... Is that a job that the CommandLine should handle? I think so!

The next thing I will do is to file an issue at plexus-utils and link the 
issues.



 was:
MORE READABLE HERE:

When a client is created it is named:

E.g. 
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}

that is ok, but now comes the sync command and uses following commandline

{{/bin/bash c "p4 -d 
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
 
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
 sync"}}

The Bash now removes the backslashes in the client name! The result is that the 
client is not existent and perforce returns with an error.

I think continuum does everything allright but we need the ticket here to be 
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.

The Problem starts in 'PerforceCheckOutCommand':


{quote}public static Commandline createCommandLine( 
PerforceScmProviderRepository repo, File workingDirectory,
   ScmVersion version, 
String specname )
{
 Commandline command = PerforceScmProvider.createP4Command( repo, 
workingDirectory );
 {color:red}command.createArgument().setValue( "-c" + specname );{color}
 command.createArgument().setValue( "sync" );
 
 // Use a simple heuristic to determine if we should use the Force flag
 // on sync. Forcing sync is a HUGE performance hit but is required in
 // rare instances where source is somehow deleted. If the target
 // directory is completely empty, assume a force is required. If
 // not empty, we assume a previous checkout was already done and a normal
 // sync will suffice.
 // SCM-110
 String[] files = workingDirectory.list();
 if ( files == null || files.length == 0 )
 { 
  // We need to force so checkout to an empty directory will work. 
command.createArgument().setValue( "-f" ); }
  // Not sure what to do here. I'm unclear whether we should be
  // sync'ing each file individually to the label or just sync the
  // entire contents of the workingDir. I'm going to assume the
  // latter until the exact semantics are clearer.
  if ( version != null && StringUtils.isNotEmpty( version.getName() ) )
   \{ command.createArgument().setValue( "@" +

[jira] Issue Comment Edited: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails

[Sebastian Annies (JIRA)]

[ 
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105305
 ] 

Sebastian Annies edited comment on CONTINUUM-1402 at 8/21/07 10:15 AM:
---

MORE READABLE HERE:

When a client is created it is named:

E.g. 
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}

that is ok, but now comes the sync command and uses following commandline

{{/bin/bash c "p4 -d 
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
 
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
 sync"}}

The Bash now removes the backslashes in the client name! The result is that the 
client is not existent and perforce returns with an error.

I think continuum does everything allright but we need the ticket here to be 
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.

The Problem starts in 'PerforceCheckOutCommand':


{quote}public static Commandline createCommandLine( 
PerforceScmProviderRepository repo, File workingDirectory,
   ScmVersion version, 
String specname )
{
 Commandline command = PerforceScmProvider.createP4Command( repo, 
workingDirectory );
 {color:red}command.createArgument().setValue( "-c" + specname );{color}
 command.createArgument().setValue( "sync" );
 
 // Use a simple heuristic to determine if we should use the Force flag
 // on sync. Forcing sync is a HUGE performance hit but is required in
 // rare instances where source is somehow deleted. If the target
 // directory is completely empty, assume a force is required. If
 // not empty, we assume a previous checkout was already done and a normal
 // sync will suffice.
 // SCM-110
 String[] files = workingDirectory.list();
 if ( files == null || files.length == 0 )
 { 
  // We need to force so checkout to an empty directory will work. 
command.createArgument().setValue( "-f" ); }
  // Not sure what to do here. I'm unclear whether we should be
  // sync'ing each file individually to the label or just sync the
  // entire contents of the workingDir. I'm going to assume the
  // latter until the exact semantics are clearer.
  if ( version != null && StringUtils.isNotEmpty( version.getName() ) )
   \{ command.createArgument().setValue( "@" + version.getName() ); \}
 }

{quote}

The {{specname}} contains the backslashes and is these are neither escaped nor 
quoted! Hmm ... Is that a job that the CommandLine should handle? I think so!

The next thing I will do is to file an issue at plexus-utils and link the 
issues.



 was:
MORE READABLE HERE:

When a client is created it is named:

E.g. 
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}

that is ok, but now comes the sync command and uses following commandline

{{/bin/bash c "p4 -d 
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
 
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
 sync"}}

The Bash now removes the backslashes in the client name! The result is that the 
client is not existent and perforce returns with an error.

I think continuum does everything allright but we need the ticket here to be 
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.

The Problem starts in 'PerforceCheckOutCommand':


{quote}public static Commandline createCommandLine( 
PerforceScmProviderRepository repo, File workingDirectory,
   ScmVersion version, 
String specname )
{
 Commandline command = PerforceScmProvider.createP4Command( repo, 
workingDirectory );
 {color:red}command.createArgument().setValue( "-c" + specname );{color}
 command.createArgument().setValue( "sync" );
 
 // Use a simple heuristic to determine if we should use the Force flag
 // on sync. Forcing sync is a HUGE performance hit but is required in
 // rare instances where source is somehow deleted. If the target
 // directory is completely empty, assume a force is required. If
 // not empty, we assume a previous checkout was already done and a normal
 // sync will suffice.
 // SCM-110
 String[] files = workingDirectory.list();
 if ( files == null || files.length == 0 )
 { 
  // We need to force so checkout to an empty directory will work. 
command.createArgument().setValue( "-f" ); }
  // Not sure what to do here. I'm unclear whether we should be
  // sync'ing each file individually to the label or just sync the
  // entire contents of the workingDir. I'm going to assume the
  // latter until the exact semantics are clearer.
  if ( version != null && StringUtils.isNotEmpty( version.getName() ) )
   { command.createArgument().setValue( "@" + version.getNam

[jira] Commented: (MNG-2861) NullPointerException in DefaultArtifactCollector for relocated resolvedArtifacts with different version ranges and available versions.

[Matthew Beermann (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105329
 ] 

Matthew Beermann commented on MNG-2861:
---

I'm having trouble creating a _minimized_ testcase too... but I do know that 
someone in our organization seems to encounter this problem almost daily. If it 
comes to it, I can always email you our entire repository and a project that 
exhibits the issue. :(

Other details: The stack trace has morphed slightly in recent versions of 
Maven, since this bug was first filed. In 2.0.7, it looks like:

[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] null
[INFO] 
[DEBUG] Trace
java.lang.NullPointerException
at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:197)
at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:367)
at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:367)
at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74)
at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284)
at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272)
at 
org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238)

Also, with the patch applied, the build still fails, but with a more 
informative error message:

[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Failed to resolve artifact.

Couldn't find a version in [1.6.0, 1.7, 1.7.1, 2.0] to match range 
[2.0-SNAPSHOT,2)


> NullPointerException in DefaultArtifactCollector for relocated 
> resolvedArtifacts with different version ranges and available versions.
> --
>
> Key: MNG-2861
> URL: http://jira.codehaus.org/browse/MNG-2861
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.5
>Reporter: Micah Whitacre
> Fix For: 2.0.x
>
> Attachments: MNG-2861-maven-project.patch, MNG-2861.tar.gz
>
>
> In a remoteRepository that I am populating I have a project.  Previously I 
> was deploying artifacts with an old groupId and then decided to switch to 
> having a new more descriptive groupId.  For the old groupId I have deployed 
> versions 1.0 and 1.1.  For the new groupId I have deployed 1.2 and 2.0.  I 
> deployed a relocation POM to the old groupId for the 1.2 version.  I also 
> updated the metadata.xml files to include 1.2 as an available version.  This 
> way projects using version ranges [1,2) will be able to pick up the newest 
> version.  So in the repository I now have:
> oldgroupId:project:1.0
> oldgroupId:project:1.1
> oldgroupId:project:1.2 - redirecting to newgroupId:project:1.2
> newgroupId:project:1.2
> newgroupId:project:2.0
> The oldgroupId's metadata lists the available versions as [1.0,1.1,1.2].  The 
> newgroupId's metadata lists the available versions has [1,2].
> I have 3 additional projects A, B, C.  A depends on B and C.  B depends on 
> oldgroupId:project:[1,2).  Project B has also finished development and been 
> released so we are avoiding rereleasing it for the groupId change.   C 
> depends on newgroupId:project:[2,3).  When I try to build project A, Maven 
> dies and gives me the following stack trace.
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] null
> [INFO] 
> 
> [DEBUG] Trace
> java.lang.NullPointerException
>   at 
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:168)
>   at 
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:305)
>   at 
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:305)
>   at 
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:70)
>   at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResol

[jira] Commented: (MANTTASKS-86) Resolution of java.net dependencies

[Werner Guttmann (JIRA)]

[ 
http://jira.codehaus.org/browse/MANTTASKS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105325
 ] 

Werner Guttmann commented on MANTTASKS-86:
--

Actually, just verified that this issue is still an issue with 2.0.7.

> Resolution of java.net dependencies
> ---
>
> Key: MANTTASKS-86
> URL: http://jira.codehaus.org/browse/MANTTASKS-86
> Project: Maven 2.x Ant Tasks
>  Issue Type: Bug
>Affects Versions: 2.0.6
>Reporter: Werner Guttmann
> Attachments: build.bat, build.xml, pom.xml
>
>
> I am trying to use the Ant task for Maven with the root Maven POM for
> the Castor project for download the dependencies and place them into a
> lib directory.
> What I have observed is that there's a few dependencies missing when I
> run the corresponding Ant target. But if I use Maven for the build
> process, the missing JARs are downloaded as well and placed into my
> local repository.
> I have tried to define remoteRepository entries for the java.net and the
> Maven 2 java.net repositories (where e.g. java.transaction:jta:1.1.1B
> resides), but this does not make a difference.
> Any idea what I could try in addition ? Having said that, all other
> dependencies are resolved and copied without any problems. It looks like
> it's just the dependencies that are not synced globally that create a
> problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MANTTASKS-86) Resolution of java.net dependencies

[Werner Guttmann (JIRA)]

 [ 
http://jira.codehaus.org/browse/MANTTASKS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Werner Guttmann updated MANTTASKS-86:
-

Attachment: build.bat

Convenience batch file ... if needed.

> Resolution of java.net dependencies
> ---
>
> Key: MANTTASKS-86
> URL: http://jira.codehaus.org/browse/MANTTASKS-86
> Project: Maven 2.x Ant Tasks
>  Issue Type: Bug
>Affects Versions: 2.0.6
>Reporter: Werner Guttmann
> Attachments: build.bat, build.xml, pom.xml
>
>
> I am trying to use the Ant task for Maven with the root Maven POM for
> the Castor project for download the dependencies and place them into a
> lib directory.
> What I have observed is that there's a few dependencies missing when I
> run the corresponding Ant target. But if I use Maven for the build
> process, the missing JARs are downloaded as well and placed into my
> local repository.
> I have tried to define remoteRepository entries for the java.net and the
> Maven 2 java.net repositories (where e.g. java.transaction:jta:1.1.1B
> resides), but this does not make a difference.
> Any idea what I could try in addition ? Having said that, all other
> dependencies are resolved and copied without any problems. It looks like
> it's just the dependencies that are not synced globally that create a
> problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MANTTASKS-86) Resolution of java.net dependencies

[Werner Guttmann (JIRA)]

 [ 
http://jira.codehaus.org/browse/MANTTASKS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Werner Guttmann updated MANTTASKS-86:
-

Attachment: build.xml

Sample Ant build file to showcase the problem.

> Resolution of java.net dependencies
> ---
>
> Key: MANTTASKS-86
> URL: http://jira.codehaus.org/browse/MANTTASKS-86
> Project: Maven 2.x Ant Tasks
>  Issue Type: Bug
>Affects Versions: 2.0.6
>Reporter: Werner Guttmann
> Attachments: build.xml, pom.xml
>
>
> I am trying to use the Ant task for Maven with the root Maven POM for
> the Castor project for download the dependencies and place them into a
> lib directory.
> What I have observed is that there's a few dependencies missing when I
> run the corresponding Ant target. But if I use Maven for the build
> process, the missing JARs are downloaded as well and placed into my
> local repository.
> I have tried to define remoteRepository entries for the java.net and the
> Maven 2 java.net repositories (where e.g. java.transaction:jta:1.1.1B
> resides), but this does not make a difference.
> Any idea what I could try in addition ? Having said that, all other
> dependencies are resolved and copied without any problems. It looks like
> it's just the dependencies that are not synced globally that create a
> problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MANTTASKS-86) Resolution of java.net dependencies

[Werner Guttmann (JIRA)]

Resolution of java.net dependencies
---

 Key: MANTTASKS-86
 URL: http://jira.codehaus.org/browse/MANTTASKS-86
 Project: Maven 2.x Ant Tasks
  Issue Type: Bug
Affects Versions: 2.0.6
Reporter: Werner Guttmann
 Attachments: build.xml, pom.xml

I am trying to use the Ant task for Maven with the root Maven POM for
the Castor project for download the dependencies and place them into a
lib directory.

What I have observed is that there's a few dependencies missing when I
run the corresponding Ant target. But if I use Maven for the build
process, the missing JARs are downloaded as well and placed into my
local repository.

I have tried to define remoteRepository entries for the java.net and the
Maven 2 java.net repositories (where e.g. java.transaction:jta:1.1.1B
resides), but this does not make a difference.

Any idea what I could try in addition ? Having said that, all other
dependencies are resolved and copied without any problems. It looks like
it's just the dependencies that are not synced globally that create a
problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MANTTASKS-86) Resolution of java.net dependencies

[Werner Guttmann (JIRA)]

 [ 
http://jira.codehaus.org/browse/MANTTASKS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Werner Guttmann updated MANTTASKS-86:
-

Attachment: pom.xml

Castor's Maven 2 POM.

> Resolution of java.net dependencies
> ---
>
> Key: MANTTASKS-86
> URL: http://jira.codehaus.org/browse/MANTTASKS-86
> Project: Maven 2.x Ant Tasks
>  Issue Type: Bug
>Affects Versions: 2.0.6
>Reporter: Werner Guttmann
> Attachments: build.xml, pom.xml
>
>
> I am trying to use the Ant task for Maven with the root Maven POM for
> the Castor project for download the dependencies and place them into a
> lib directory.
> What I have observed is that there's a few dependencies missing when I
> run the corresponding Ant target. But if I use Maven for the build
> process, the missing JARs are downloaded as well and placed into my
> local repository.
> I have tried to define remoteRepository entries for the java.net and the
> Maven 2 java.net repositories (where e.g. java.transaction:jta:1.1.1B
> resides), but this does not make a difference.
> Any idea what I could try in addition ? Having said that, all other
> dependencies are resolved and copied without any problems. It looks like
> it's just the dependencies that are not synced globally that create a
> problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (DOXIA-136) Create an FML DTD or XSD

[Vincent Siveton (JIRA)]

 [ 
http://jira.codehaus.org/browse/DOXIA-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vincent Siveton closed DOXIA-136.
-

 Assignee: Vincent Siveton
   Resolution: Fixed
Fix Version/s: (was: 1.0-beta-1)
   1.0-alpha-9

Added modello stuff in r568106

> Create an FML DTD or XSD
> 
>
> Key: DOXIA-136
> URL: http://jira.codehaus.org/browse/DOXIA-136
> Project: Maven Doxia
>  Issue Type: Task
>  Components: Module - Fml
>Reporter: Vincent Siveton
>Assignee: Vincent Siveton
> Fix For: 1.0-alpha-9
>
>
> Review the M1 FAQ schema is certainly a good start.
> http://maven.apache.org/maven-1.x/plugins/faq/faq.xsd

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails

[Sebastian Annies (JIRA)]

[ 
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105305
 ] 

Sebastian Annies edited comment on CONTINUUM-1402 at 8/21/07 7:40 AM:
--

MORE READABLE HERE:

When a client is created it is named:

E.g. 
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}

that is ok, but now comes the sync command and uses following commandline

{{/bin/bash c "p4 -d 
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
 
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
 sync"}}

The Bash now removes the backslashes in the client name! The result is that the 
client is not existent and perforce returns with an error.

I think continuum does everything allright but we need the ticket here to be 
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.

The Problem starts in 'PerforceCheckOutCommand':


{{public static Commandline createCommandLine( PerforceScmProviderRepository 
repo, File workingDirectory,
   ScmVersion version, 
String specname )
{
 Commandline command = PerforceScmProvider.createP4Command( repo, 
workingDirectory );
 {color:red}command.createArgument().setValue( "-c" + specname );{color}
 command.createArgument().setValue( "sync" );
 
 // Use a simple heuristic to determine if we should use the Force flag
 // on sync. Forcing sync is a HUGE performance hit but is required in
 // rare instances where source is somehow deleted. If the target
 // directory is completely empty, assume a force is required. If
 // not empty, we assume a previous checkout was already done and a normal
 // sync will suffice.
 // SCM-110
 String[] files = workingDirectory.list();
 if ( files == null || files.length == 0 )
 { 
  // We need to force so checkout to an empty directory will work. 
command.createArgument().setValue( "-f" ); }
  // Not sure what to do here. I'm unclear whether we should be
  // sync'ing each file individually to the label or just sync the
  // entire contents of the workingDir. I'm going to assume the
  // latter until the exact semantics are clearer.
  if ( version != null && StringUtils.isNotEmpty( version.getName() ) )
   { command.createArgument().setValue( "@" + version.getName() ); }
 }

}}

The {{specname}} contains the backslashes and is these are neither escaped nor 
quoted! Hmm ... Is that a job that the CommandLine should handle? I think so!

The next thing I will do is to file an issue at plexus-utils and link the 
issues.



 was:
MORE READABLE HERE:

When a client is created it is named:

E.g. 
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}

that is ok, but now comes the sync command and uses following commandline

{{/bin/bash c "p4 -d 
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
 
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
 sync"}}

The Bash now removes the backslashes in the client name! The result is that the 
client is not existent and perforce returns with an error.

I think continuum does everything allright but we need the ticket here to be 
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.

The Problem starts in 'PerforceCheckOutCommand':


{{public static Commandline createCommandLine( PerforceScmProviderRepository 
repo, File workingDirectory,
   ScmVersion version, 
String specname )
{
 Commandline command = PerforceScmProvider.createP4Command( repo, 
workingDirectory );
 {color.red}
 command.createArgument().setValue( "-c" + specname );{color}
 command.createArgument().setValue( "sync" );
 
 // Use a simple heuristic to determine if we should use the Force flag
 // on sync. Forcing sync is a HUGE performance hit but is required in
 // rare instances where source is somehow deleted. If the target
 // directory is completely empty, assume a force is required. If
 // not empty, we assume a previous checkout was already done and a normal
 // sync will suffice.
 // SCM-110
 String[] files = workingDirectory.list();
 if ( files == null || files.length == 0 )
 { 
  // We need to force so checkout to an empty directory will work. 
command.createArgument().setValue( "-f" ); }
  // Not sure what to do here. I'm unclear whether we should be
  // sync'ing each file individually to the label or just sync the
  // entire contents of the workingDir. I'm going to assume the
  // latter until the exact semantics are clearer.
  if ( version != null && StringUtils.isNotEmpty( version.getName() ) )
   { command.createArgument().setValue( "@" + version.getName() ); }
 }

}}

[jira] Issue Comment Edited: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails

[Sebastian Annies (JIRA)]

[ 
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105305
 ] 

Sebastian Annies edited comment on CONTINUUM-1402 at 8/21/07 7:41 AM:
--

MORE READABLE HERE:

When a client is created it is named:

E.g. 
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}

that is ok, but now comes the sync command and uses following commandline

{{/bin/bash c "p4 -d 
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
 
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
 sync"}}

The Bash now removes the backslashes in the client name! The result is that the 
client is not existent and perforce returns with an error.

I think continuum does everything allright but we need the ticket here to be 
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.

The Problem starts in 'PerforceCheckOutCommand':


{quote}public static Commandline createCommandLine( 
PerforceScmProviderRepository repo, File workingDirectory,
   ScmVersion version, 
String specname )
{
 Commandline command = PerforceScmProvider.createP4Command( repo, 
workingDirectory );
 {color:red}command.createArgument().setValue( "-c" + specname );{color}
 command.createArgument().setValue( "sync" );
 
 // Use a simple heuristic to determine if we should use the Force flag
 // on sync. Forcing sync is a HUGE performance hit but is required in
 // rare instances where source is somehow deleted. If the target
 // directory is completely empty, assume a force is required. If
 // not empty, we assume a previous checkout was already done and a normal
 // sync will suffice.
 // SCM-110
 String[] files = workingDirectory.list();
 if ( files == null || files.length == 0 )
 { 
  // We need to force so checkout to an empty directory will work. 
command.createArgument().setValue( "-f" ); }
  // Not sure what to do here. I'm unclear whether we should be
  // sync'ing each file individually to the label or just sync the
  // entire contents of the workingDir. I'm going to assume the
  // latter until the exact semantics are clearer.
  if ( version != null && StringUtils.isNotEmpty( version.getName() ) )
   { command.createArgument().setValue( "@" + version.getName() ); }
 }

{quote}

The {{specname}} contains the backslashes and is these are neither escaped nor 
quoted! Hmm ... Is that a job that the CommandLine should handle? I think so!

The next thing I will do is to file an issue at plexus-utils and link the 
issues.



 was:
MORE READABLE HERE:

When a client is created it is named:

E.g. 
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}

that is ok, but now comes the sync command and uses following commandline

{{/bin/bash c "p4 -d 
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
 
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
 sync"}}

The Bash now removes the backslashes in the client name! The result is that the 
client is not existent and perforce returns with an error.

I think continuum does everything allright but we need the ticket here to be 
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.

The Problem starts in 'PerforceCheckOutCommand':


{{public static Commandline createCommandLine( PerforceScmProviderRepository 
repo, File workingDirectory,
   ScmVersion version, 
String specname )
{
 Commandline command = PerforceScmProvider.createP4Command( repo, 
workingDirectory );
 {color:red}command.createArgument().setValue( "-c" + specname );{color}
 command.createArgument().setValue( "sync" );
 
 // Use a simple heuristic to determine if we should use the Force flag
 // on sync. Forcing sync is a HUGE performance hit but is required in
 // rare instances where source is somehow deleted. If the target
 // directory is completely empty, assume a force is required. If
 // not empty, we assume a previous checkout was already done and a normal
 // sync will suffice.
 // SCM-110
 String[] files = workingDirectory.list();
 if ( files == null || files.length == 0 )
 { 
  // We need to force so checkout to an empty directory will work. 
command.createArgument().setValue( "-f" ); }
  // Not sure what to do here. I'm unclear whether we should be
  // sync'ing each file individually to the label or just sync the
  // entire contents of the workingDir. I'm going to assume the
  // latter until the exact semantics are clearer.
  if ( version != null && StringUtils.isNotEmpty( version.getName() ) )
   { command.createArgument().setValue( "@" + version.getName() ); }

[jira] Commented: (MSITE-251) tr locale support

[Vincent Siveton (JIRA)]

[ 
http://jira.codehaus.org/browse/MSITE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105306
 ] 

Vincent Siveton commented on MSITE-251:
---

Provide patch in UTF-8 charset. Thanks!

http://maven.apache.org/plugins/maven-site-plugin/i18n.html
 

> tr locale support
> -
>
> Key: MSITE-251
> URL: http://jira.codehaus.org/browse/MSITE-251
> Project: Maven 2.x Site Plugin
>  Issue Type: New Feature
> Environment: Windows XP
>Reporter: gulcan yalcinkaya
>Priority: Trivial
> Attachments: project-info-report_tr.properties, 
> site-plugin_tr.properties
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails

[Sebastian Annies (JIRA)]

[ 
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105305
 ] 

Sebastian Annies edited comment on CONTINUUM-1402 at 8/21/07 7:39 AM:
--

MORE READABLE HERE:

When a client is created it is named:

E.g. 
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}

that is ok, but now comes the sync command and uses following commandline

{{/bin/bash c "p4 -d 
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
 
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
 sync"}}

The Bash now removes the backslashes in the client name! The result is that the 
client is not existent and perforce returns with an error.

I think continuum does everything allright but we need the ticket here to be 
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.

The Problem starts in 'PerforceCheckOutCommand':


{{public static Commandline createCommandLine( PerforceScmProviderRepository 
repo, File workingDirectory,
   ScmVersion version, 
String specname )
{
 Commandline command = PerforceScmProvider.createP4Command( repo, 
workingDirectory );
 {color.red}
 command.createArgument().setValue( "-c" + specname );{color}
 command.createArgument().setValue( "sync" );
 
 // Use a simple heuristic to determine if we should use the Force flag
 // on sync. Forcing sync is a HUGE performance hit but is required in
 // rare instances where source is somehow deleted. If the target
 // directory is completely empty, assume a force is required. If
 // not empty, we assume a previous checkout was already done and a normal
 // sync will suffice.
 // SCM-110
 String[] files = workingDirectory.list();
 if ( files == null || files.length == 0 )
 { 
  // We need to force so checkout to an empty directory will work. 
command.createArgument().setValue( "-f" ); }
  // Not sure what to do here. I'm unclear whether we should be
  // sync'ing each file individually to the label or just sync the
  // entire contents of the workingDir. I'm going to assume the
  // latter until the exact semantics are clearer.
  if ( version != null && StringUtils.isNotEmpty( version.getName() ) )
   { command.createArgument().setValue( "@" + version.getName() ); }
 }

}}

The {{specname}} contains the backslashes and is these are neither escaped nor 
quoted! Hmm ... Is that a job that the CommandLine should handle? I think so!

The next thing I will do is to file an issue at plexus-utils and link the 
issues.



 was:
MORE READABLE HERE:

When a client is created it is named:

E.g. 
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}

that is ok, but now comes the sync command and uses following commandline

{{/bin/bash c "p4 -d 
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
 
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
 sync"}}

The Bash now removes the backslashes in the client name! The result is that the 
client is not existent and perforce returns with an error.

I think continuum does everything allright but we need the ticket here to be 
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.

The Problem starts in 'PerforceCheckOutCommand':


{{
public static Commandline createCommandLine( PerforceScmProviderRepository 
repo, File workingDirectory,
   ScmVersion version, 
String specname )
{
 Commandline command = PerforceScmProvider.createP4Command( repo, 
workingDirectory );
 {color.red}
 command.createArgument().setValue( "-c" + specname );{color}
 command.createArgument().setValue( "sync" );
 
 // Use a simple heuristic to determine if we should use the Force flag
 // on sync. Forcing sync is a HUGE performance hit but is required in
 // rare instances where source is somehow deleted. If the target
 // directory is completely empty, assume a force is required. If
 // not empty, we assume a previous checkout was already done and a normal
 // sync will suffice.
 // SCM-110
 String[] files = workingDirectory.list();
 if ( files == null || files.length == 0 )
 { 
  // We need to force so checkout to an empty directory will work. 
command.createArgument().setValue( "-f" ); }
  // Not sure what to do here. I'm unclear whether we should be
  // sync'ing each file individually to the label or just sync the
  // entire contents of the workingDir. I'm going to assume the
  // latter until the exact semantics are clearer.
  if ( version != null && StringUtils.isNotEmpty( version.getName() ) )
   { command.createArgument().setValue( "@" + version.getName() ); }
 }

}

[jira] Commented: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails

[Sebastian Annies (JIRA)]

[ 
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105305
 ] 

Sebastian Annies commented on CONTINUUM-1402:
-

MORE READABLE HERE:

When a client is created it is named:

E.g. 
{{sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6}}

that is ok, but now comes the sync command and uses following commandline

{{/bin/bash c "p4 -d 
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
 
-cbackground-sojus-MavenSCM\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
 sync"}}

The Bash now removes the backslashes in the client name! The result is that the 
client is not existent and perforce returns with an error.

I think continuum does everything allright but we need the ticket here to be 
reminded to switch to a new plexus-utils or maven-scm if it is fixed there.

The Problem starts in 'PerforceCheckOutCommand':


{{
public static Commandline createCommandLine( PerforceScmProviderRepository 
repo, File workingDirectory,
   ScmVersion version, 
String specname )
{
 Commandline command = PerforceScmProvider.createP4Command( repo, 
workingDirectory );
 {color.red}
 command.createArgument().setValue( "-c" + specname );{color}
 command.createArgument().setValue( "sync" );
 
 // Use a simple heuristic to determine if we should use the Force flag
 // on sync. Forcing sync is a HUGE performance hit but is required in
 // rare instances where source is somehow deleted. If the target
 // directory is completely empty, assume a force is required. If
 // not empty, we assume a previous checkout was already done and a normal
 // sync will suffice.
 // SCM-110
 String[] files = workingDirectory.list();
 if ( files == null || files.length == 0 )
 { 
  // We need to force so checkout to an empty directory will work. 
command.createArgument().setValue( "-f" ); }
  // Not sure what to do here. I'm unclear whether we should be
  // sync'ing each file individually to the label or just sync the
  // entire contents of the workingDir. I'm going to assume the
  // latter until the exact semantics are clearer.
  if ( version != null && StringUtils.isNotEmpty( version.getName() ) )
   { command.createArgument().setValue( "@" + version.getName() ); }
 }

}}

The {{specname }} contains the backslashes and is these are neither escaped nor 
quoted! Hmm ... Is that a job that the CommandLine should handle? I think so!

The next thing I will do is to file an issue at plexus-utils and link the 
issues.


> Syncing with Perforce on Linux/Unix/Bash fails
> --
>
> Key: CONTINUUM-1402
> URL: http://jira.codehaus.org/browse/CONTINUUM-1402
> Project: Continuum
>  Issue Type: Bug
>  Components: Integration - Maven 2, SCM
>Affects Versions: 1.1-beta-2
> Environment: Bash
>Reporter: Sebastian Annies
>Priority: Critical
>
> When a client is created it is named:
> E.g.{{monospaced}} 
> sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6{{monospaced}}
> that is ok, but now comes the sync command and uses following commandline
> {{monospaced}}
> /bin/bash -c "p4 -d 
> /opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
>  
> -cbackground-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
>  sync"
> {{monospaced}}
> The Bash now removes the backslashes in the client name! The result is that 
> the client is not existent and perforce returns with an error. 
> I think continuum does everything allright but we need the ticket here to be 
> reminded to switch to a new plexus-utils or maven-scm if it is fixed there. 
> The Problem starts in 'PerforceCheckOutCommand':
> {{monospaced}}
> public static Commandline createCommandLine( 
> PerforceScmProviderRepository repo, File workingDirectory,
>  ScmVersion version, String 
> specname )
> {
> Commandline command = PerforceScmProvider.createP4Command( repo, 
> workingDirectory );
> {color:red} 
> command.createArgument().setValue( "-c" + specname  );
> {color}
> command.createArgument().setValue( "sync" );
> // Use a simple heuristic to determine if we should use the Force flag
> // on sync.  Forcing sync is a HUGE performance hit but is required in
> // rare instances where source is somehow deleted.  If the target
> // directory is completely empty, assume a force is required.  If
> // not empty, we assume a previous checkout was already done and a 
> normal
> // sync will suffice.
> // SCM-110
> Stri

[jira] Created: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails

[Sebastian Annies (JIRA)]

Syncing with Perforce on Linux/Unix/Bash fails
--

 Key: CONTINUUM-1402
 URL: http://jira.codehaus.org/browse/CONTINUUM-1402
 Project: Continuum
  Issue Type: Bug
  Components: Integration - Maven 2, SCM
Affects Versions: 1.1-beta-2
 Environment: Bash
Reporter: Sebastian Annies
Priority: Critical


When a client is created it is named:

E.g.{{monospaced}} 
sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6{{monospaced}}

that is ok, but now comes the sync command and uses following commandline

{{monospaced}}
/bin/bash -c "p4 -d 
/opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
 
-cbackground-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
 sync"
{{monospaced}}

The Bash now removes the backslashes in the client name! The result is that the 
client is not existent and perforce returns with an error. 

I think continuum does everything allright but we need the ticket here to be 
reminded to switch to a new plexus-utils or maven-scm if it is fixed there. 

The Problem starts in 'PerforceCheckOutCommand':
{{monospaced}}

public static Commandline createCommandLine( PerforceScmProviderRepository 
repo, File workingDirectory,
 ScmVersion version, String 
specname )
{
Commandline command = PerforceScmProvider.createP4Command( repo, 
workingDirectory );
{color:red} 
command.createArgument().setValue( "-c" + specname  );
{color}
command.createArgument().setValue( "sync" );

// Use a simple heuristic to determine if we should use the Force flag
// on sync.  Forcing sync is a HUGE performance hit but is required in
// rare instances where source is somehow deleted.  If the target
// directory is completely empty, assume a force is required.  If
// not empty, we assume a previous checkout was already done and a 
normal
// sync will suffice.
// SCM-110
String[] files = workingDirectory.list();
if ( files == null || files.length == 0 )
{
// We need to force so checkout to an empty directory will work.
command.createArgument().setValue( "-f" );
}

// Not sure what to do here. I'm unclear whether we should be
// sync'ing each file individually to the label or just sync the
// entire contents of the workingDir. I'm going to assume the
// latter until the exact semantics are clearer.
if ( version != null && StringUtils.isNotEmpty( version.getName() ) )
{
command.createArgument().setValue( "@" + version.getName() );
}
return command;
{{monospaced}}

The {{monospaced}}specname  {{monospaced}} contains the backslashes and is 
these are neither escaped nor quoted! Hmm ... Is that a job that the 
CommandLine should handle? I think so!

The next thing I will do is to file an issue at plexus-utils and link the 
issues.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (ARCHETYPE-86) maven-archetype-portlet: Wrong in portlet.xml

[Nils-Helge Garli (JIRA)]

maven-archetype-portlet: Wrong  in portlet.xml
-

 Key: ARCHETYPE-86
 URL: http://jira.codehaus.org/browse/ARCHETYPE-86
 Project: Maven Archetype
  Issue Type: Bug
  Components: Archetypes
Reporter: Nils-Helge Garli


The  element in portlet.xml generates the wrong portlet class 
unless you specify MyPortlet as artifactId. The errors lies in the portlet.xml 
template:

${groupId}.${artifactId}

The Class of the portlet is constant, namely MyPortlet, so it should instead 
say:

${groupId}.MyPortlet

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-87) Poms are written with wrong encodings

[Herve Boutemy (JIRA)]

 [ 
http://jira.codehaus.org/browse/MRELEASE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy updated MRELEASE-87:
--

Attachment: MRELEASE-87-bis.diff

ok, reworked the patch: the unreleased dependency was a typo (how could I let 
it into the patch?...)
but one problem persists when running testcases that I cannot find how to fix: 
{{org.codehaus.plexus.component.repository.exception.ComponentLookupException: 
Component descriptor cannot be found in the component repository: 
org.apache.maven.artifact.metadata.ArtifactMetadataSource [default] (lookup 
realm: ClassRealm[plexus.core, parent: null]).}}
:(

it contains a little fix for a problem committed this morning in r567988 for 
MRELEASE-124: String.contains API is only available in Java 5+, it is not in 
Java 1.4

> Poms are written with wrong encodings
> -
>
> Key: MRELEASE-87
> URL: http://jira.codehaus.org/browse/MRELEASE-87
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>Affects Versions: 2.0-beta-4, 2.0-beta-5, 2.0-beta-6
>Reporter: Carlos Sanchez
>Priority: Critical
> Fix For: 2.0-beta-7
>
> Attachments: MRELEASE-87-bis.diff, MRELEASE-87.diff
>
>
> I have committed a test that works in my Sun and IBM JDKs under windows but 
> breaks in the Continuum at codehaus.
> Tomorrow i'll try with IBM JDK under linux.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-3151) Allow plugins that attach artifacts to specify deployment locations

[Maria Odea Ching (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105291
 ] 

Maria Odea Ching commented on MNG-3151:
---

I got test failures from DefaultMavenProjectHelperTest due to NPEs in 
AttachedArtifact.getVersion() so the patch wasn't applied. Also, the patch 
needs to be updated to trunk. Thanks!

> Allow plugins that attach artifacts to specify deployment locations
> ---
>
> Key: MNG-3151
> URL: http://jira.codehaus.org/browse/MNG-3151
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Artifacts and Repositories, General
>Affects Versions: 2.0.8
>Reporter: James William Dumay
>Assignee: Brett Porter
> Fix For: 2.0.8
>
> Attachments: MNG-3151-maven-2.0.x.patch
>
>
> The following patch allows plugins to specify Distribution Management 
> relating to their attached artifacts.
> This is useful in large Java shops where, depending on the type of artifact 
> (Javadoc, source, assembly, etc)m you may want to deploy these artifacts to 
> different repositories (eg public and private).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (CONTINUUM-1353) after a few weeks, continuum runs into outofmemory error

[tony nys (JIRA)]

[ 
http://jira.codehaus.org/browse/CONTINUUM-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105290
 ] 

tony nys commented on CONTINUUM-1353:
-

When will this issue be fixed ? 
It is really annoying: every 2 weeks, I need to clean up the database manually 
and bring continuum offline

> after a few weeks, continuum runs into outofmemory error
> 
>
> Key: CONTINUUM-1353
> URL: http://jira.codehaus.org/browse/CONTINUUM-1353
> Project: Continuum
>  Issue Type: Bug
>  Components: Core system
>Affects Versions: 1.1-alpha-2
>Reporter: tony nys
>Priority: Blocker
>
> when clicking on the build history, memory of the jvm increases from 100MB 
> until 470MB
> after that it crashes with outofmemory error (JDO exception)
> Increasing the plexus jvm memory does have no affect: 
> %PLEXUS_JAVA_EXE% %PLEXUS_OPTS% -Xmx900M -XX:MaxPermSize=128m -classpath 
> "%PLEXUS_HOME%\core\boot\plexus-classworlds-1.2-alpha-7.jar" 
> -Dclassworlds.conf="%PLEXUS_HOME%\conf\classworlds.conf" 
> -Dplexus.core=%PLEXUS_CORE% -Dplexus.system.path="%PATH%" 
> -Djava.io.tmpdir=%PLEXUS_TMPDIR% -Dplexus.home="%PLEXUS_HOME%" 
> -Dappserver.base="%PLEXUS_BASE%" -Dtools.jar="%TOOLS_JAR%" 
> org.codehaus.plexus.classworlds.launcher.Launcher %PLEXUS_CMD_LINE_ARGS%
> So probably bug in fetch from db where all objects are retrieved ?
> For us this is a showstopper. Would MySQL DB be a workaround ? I guess the 
> query is the same, so will the memory usage be ?
> Where can I find the complete DDL script for mysql ? On the wiki there is 
> only 1 table ... ?
> javax.jdo.JDODataStoreException: Iteration request failed : 
> SELECT 
> THIS.CHANGEFILE_ID,THIS.MODEL_ENCODING,THIS."NAME",THIS.REVISION,THIS.STATUS,THIS.FILES_INTEGER_IDX
>  AS JPOXORDER0 FROM 
> CHANGEFILE THIS WHERE ? = THIS.FILES_CHANGESET_ID_OID AND 
> THIS.FILES_INTEGER_IDX >= ? ORDER BY JPOXORDER0 NestedThrowables: SQL 
> Exception: Java exception: 
> 'Java heap space: java.lang.OutOfMemoryError'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MECLIPSE-317) Unable to build inside eclipse when module name and artifact-id are not the same

[Dan Tran (JIRA)]

[ 
http://jira.codehaus.org/browse/MECLIPSE-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105288
 ] 

Dan Tran commented on MECLIPSE-317:
---

here are errors found on eclipse console

Severity and DescriptionPathResourceLocation
Creation Time   Id
Project 'core15' is missing required Java project: 'myfaces-orchestra-core' 
core15  Build path  1187686011616   451
Project 'examples' is missing required Java project: 'myfaces-orchestra-core'   
examplesBuild path  1187686011631   452
Project 'examples' is missing required Java project: 'myfaces-orchestra-core15' 
examplesBuild path  1187686011647   453
The project cannot be built until build path errors are resolved
core15  Unknown 1187686015335   504
The project cannot be built until build path errors are resolved
examplesUnknown 1187686015335   505


> Unable to build inside eclipse when module name and artifact-id are not the 
> same
> 
>
> Key: MECLIPSE-317
> URL: http://jira.codehaus.org/browse/MECLIPSE-317
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: xp, eclipse 3.3
>Reporter: Dan Tran
>
> and example of this is issue is 
>   http://svn.apache.org/repos/asf/myfaces/orchestra/trunk
> where the core is buildable but core15 and examples are not

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MECLIPSE-317) Unable to build inside eclipse when module name and artifact-id are not the same

[Dan Tran (JIRA)]

Unable to build inside eclipse when module name and artifact-id are not the same


 Key: MECLIPSE-317
 URL: http://jira.codehaus.org/browse/MECLIPSE-317
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
Affects Versions: 2.4
 Environment: xp, eclipse 3.3
Reporter: Dan Tran


and example of this is issue is 

  http://svn.apache.org/repos/asf/myfaces/orchestra/trunk

where the core is buildable but core15 and examples are not




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MRELEASE-277) Unique versioned snapshots allowance not covering always parent

[Tuomas Kiviaho (JIRA)]

Unique versioned snapshots allowance not covering always parent
---

 Key: MRELEASE-277
 URL: http://jira.codehaus.org/browse/MRELEASE-277
 Project: Maven 2.x Release Plugin
  Issue Type: Sub-task
Reporter: Tuomas Kiviaho
 Attachments: 
CheckDependencySnapshotsPhaseTest.testAllowTimestampedParent.patch

Parent version could also be referenced by unique version number  (assuming 
allowance to be set).

Problems arise when such parent is resolved to a file containing -SNAPSHOT 
marker instead of unique version number. See 


Reason is that whilst original model parent has the unique version artifact 
version is used instead.

There are uniquely versioned artifacts as well which (I assume) avoid the 
problem
See 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MAVENUPLOAD-1651) junit 4.4

[Mauro Talevi (JIRA)]

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105284
 ] 

Mauro Talevi commented on MAVENUPLOAD-1651:
---

Artifacts will be released by the JUnit projects.

David has accepted the argument put forward in the thread 
(http://thread.gmane.org/gmane.comp.java.junit.devel/1137/focus=15173) and will 
be releasing both bundled and unbundled junit artifacts.  I'll ping him to see 
where we stand.

The whole point of having and unbundled artifact (ie with hamcrest as a 
transitive dependency) is to prevent the problem you outline.   Until we have 
that we can't do anything about the hamcrest classes in the junit jar.








> junit 4.4
> -
>
> Key: MAVENUPLOAD-1651
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1651
> Project: maven-upload-requests
>  Issue Type: Bug
>Reporter: Tomislav Stojcevich
>Assignee: Mauro Talevi
> Attachments: junit-4.4-bundle.jar, junit-4.4-bundle.jar, 
> junit-4.4-bundle.jar
>
>
> Upload new version.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MRM-449) improvement to the reports form group search

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MRM-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter closed MRM-449.


Resolution: Fixed

applied, thanks!

> improvement to the reports form group search
> 
>
> Key: MRM-449
> URL: http://jira.codehaus.org/browse/MRM-449
> Project: Archiva
>  Issue Type: Improvement
>  Components: web application
>Affects Versions: 1.0-beta-1
>Reporter: Brett Porter
>Assignee: Teodoro Cue Jr.
> Fix For: 1.0-beta-2
>
>
> if you search for org.apache, it should find org.apache.*

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-450) change default label for repository ID report search to "All repositories" instead of ""

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MRM-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter closed MRM-450.


Resolution: Fixed

applied, thanks!

> change default label for repository ID report search to "All repositories" 
> instead of ""
> 
>
> Key: MRM-450
> URL: http://jira.codehaus.org/browse/MRM-450
> Project: Archiva
>  Issue Type: Improvement
>Affects Versions: 1.0-beta-1
>Reporter: Brett Porter
>Assignee: Teodoro Cue Jr.
> Fix For: 1.0-beta-2
>
> Attachments: MRM-450.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: (MSITE-34) Check site for dead links

[Lukas Theussl (JIRA)]

[ 
http://jira.codehaus.org/browse/MSITE-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105281
 ] 

Lukas Theussl commented on MSITE-34:


With all the anchor/link problems we had recently, this feature would be of 
enormous use for the doxia team. :)

Arnaud, do you plan to work on this? I can help if necessary, AFAIS, the code 
is perfectly re-usable and the core could even be factored into a separate 
project (a la JXR) to be used by both m1 and m2 plugins. WDYT?

> Check site for dead links
> -
>
> Key: MSITE-34
> URL: http://jira.codehaus.org/browse/MSITE-34
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>Reporter: Jason van Zyl
>
> We could use the m1 link checking plugin or we can steal a bit of code from 
> xstream which has some link checking code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-714) When artifact not found on mirror the real site isn't checked

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated MNG-714:
-

Patch Submitted: [Yes]

> When artifact not found on mirror the real site isn't checked
> -
>
> Key: MNG-714
> URL: http://jira.codehaus.org/browse/MNG-714
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0-beta-1
>Reporter: Kenney Westerhof
>Assignee: Jason van Zyl
> Fix For: 2.1.x
>
> Attachments: MNG-714-maven-artifact-manager.patch
>
>   Original Estimate: 3 hours
>  Remaining Estimate: 3 hours
>
> I'm using the settings.xml mirror feature as a local cache. Periodically I 
> upload my local repo
> to the webserver specified as mirror.
> When an artifact cannot be found on the mirror, the original site isn't 
> checked (and possibly the rest of the sites).
> I'm not sure what the exact function of the mirror is (except caching?), but 
> repo1 is checked often regardless
> of mirror presence, so I figure it's not meant to totally disable checking 
> the central repo's.
> Simple reproduction: define a few mirrors in your settings.xml for central, 
> central-plugins and snapshots, pointing to
> say file://tmp/empty/dir/.
> Stacktrace:
> [DEBUG] Error resolving artifact version from metadata.
> org.apache.maven.wagon.ResourceDoesNotExistException: Unable to locate 
> resource in repository
> at 
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:81)
> at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:70)
> at 
> org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:343)
> at 
> org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(DefaultWagonManager.java:263)
> at 
> org.apache.maven.artifact.metadata.AbstractVersionArtifactMetadata.retrieveFromRemoteRepository(AbstractVersionArtifactMetadata.java:93)
> at 
> org.apache.maven.artifact.transform.AbstractVersionTransformation.retrieveFromRemoteRepository(AbstractVersionTransformation.java:171)
> at 
> org.apache.maven.artifact.transform.AbstractVersionTransformation.resolveVersion(AbstractVersionTransformation.java:96)
> at 
> org.apache.maven.artifact.transform.SnapshotTransformation.transformForResolve(SnapshotTransformation.java:43)
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:95)
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:290)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:274)
> at 
> org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:81)
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:186)
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:70)
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:197)
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:185)
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:156)
> at 
> org.apache.maven.plugin.DefaultPluginManager.ensurePluginContainerIsComplete(DefaultPluginManager.java:544)
> at 
> org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:479)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:334)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:378)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:351)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:337)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:229)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:123)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:209)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:267)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.Nat

[jira] Updated: (MNG-2356) Add timing information to integration tests

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated MNG-2356:
--

Patch Submitted: [Yes]

> Add timing information to integration tests
> ---
>
> Key: MNG-2356
> URL: http://jira.codehaus.org/browse/MNG-2356
> Project: Maven 2
>  Issue Type: Improvement
>  Components: integration tests
>Affects Versions: 2.0.4
>Reporter: Jerome Lacoste
>Priority: Trivial
> Fix For: 2.2.x
>
> Attachments: MNG-2356.diff
>
>
> Also document why using your installed maven to recompile this plugin is a 
> bad idea :)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-671) implement a license clickthrough

[Brett Porter (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105280
 ] 

Brett Porter commented on MNG-671:
--

maven-license-patches is the latest - it was reopened per Stefano's comments. 
It has never been applied. I haven't reviewed the latest one - but my comments 
on the first version are included earlier.

> implement a license clickthrough
> 
>
> Key: MNG-671
> URL: http://jira.codehaus.org/browse/MNG-671
> Project: Maven 2
>  Issue Type: New Feature
>  Components: Dependencies
>Reporter: Brett Porter
>Assignee: Brett Porter
> Fix For: 2.1.x
>
> Attachments: maven-artifact-manager-patch-2.txt, 
> maven-artifact-manager-patch.txt, maven-artifact-patch-2.txt, 
> maven-license-patches-3.zip, maven-settings-patch-2.txt, 
> maven-settings-patch.txt
>
>
> we need some basic license acceptance policy for downloadable artifacts. For 
> now, this can just be a Y/N that is saved forever.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2484) Document the naming convention for archetypes

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated MNG-2484:
--

Patch Submitted: [Yes]

> Document the naming convention for archetypes
> -
>
> Key: MNG-2484
> URL: http://jira.codehaus.org/browse/MNG-2484
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Documentation: Guides
>Reporter: Wendy Smoak
> Fix For: Documentation
>
> Attachments: archetype-naming-convention.diff
>
>
> As discussed, document the archetype naming convention as 
> -archetype-.
> http://mail-archives.apache.org/mod_mbox/maven-dev/200607.mbox/[EMAIL 
> PROTECTED]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2123) NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated MNG-2123:
--

Patch Submitted: [Yes]

> NullPointerException when a dependency uses version range and another uses an 
> actual version incompatible with that range
> -
>
> Key: MNG-2123
> URL: http://jira.codehaus.org/browse/MNG-2123
> Project: Maven 2
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 2.0.2, 2.0.3, 2.0.4
>Reporter: Carlos Sanchez
>Assignee: Jason van Zyl
> Fix For: 2.0.x
>
> Attachments: MNG-2123-maven-artifact.patch, pom.xml
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Struts 1.2.7 depends on commons-digester 1.6 and jasperreports 1.1.1 in [1.7,)
> Build fails with a null pointer exception that is not very explanatory
> [INFO] Scanning for projects...
> [INFO] 
> 
> [INFO] Building Unnamed - test:test:jar:1.0-SNAPSHOT
> [INFO]task-segment: [test]
> [INFO] 
> 
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] version was null for commons-digester:commons-digester
> [INFO] 
> 
> [INFO] Trace
> java.lang.NullPointerException: version was null for 
> commons-digester:commons-digester
> at 
> org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:361)
> at 
> org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:222)
> at 
> org.apache.maven.artifact.resolver.ResolutionNode.getDependencyTrail(ResolutionNode.java:115)
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:88)
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:223)
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211)
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182)
> at 
> org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1117)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:366)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> [INFO] 
> 
> [INFO] Total time: 1 second
> [INFO] Finished at: Sun Mar 05 23:26:16 PST 2006
> [INFO] Final Memory: 3M/5M
> [INFO] 
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure

[jira] Updated: (MNG-2655) Revise Introduction to the Build Lifecycle

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated MNG-2655:
--

Patch Submitted: [Yes]

> Revise Introduction to the Build Lifecycle
> --
>
> Key: MNG-2655
> URL: http://jira.codehaus.org/browse/MNG-2655
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Documentation: Introductions
>Reporter: Franz Allan Valencia See
>Priority: Minor
> Fix For: Documentation
>
> Attachments: MNG-2655-maven-site.patch
>
>
> * Provide a Table of Contents (the page is too long).
> * Enumerate the available lifecycles (default, clean, site).
> * Provide references to the list of phases for those lifecycles lifecycles .
> * Explain goals and how they relate to the build phases.
> * Provide references to the default goal bindings on the build phases.
> * Explain what plugins are and how they relate to goals
> * Transfer the "...For developers" section to Guide to Java Plugin 
> Development. Users don't need to know tihs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2698) Good Primer on Maven for site

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated MNG-2698:
--

Patch Submitted: [Yes]

> Good Primer on Maven for site
> -
>
> Key: MNG-2698
> URL: http://jira.codehaus.org/browse/MNG-2698
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Documentation: Introductions
>Reporter: Brian Topping
> Fix For: Documentation
>
> Attachments: MavenPrimer.html
>
>
> I've attached a document I wrote for use at a company I am doing some work 
> for.  They couldn't use it, but this document is succinct and may be worth 
> putting it on the site.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-1682) Plugins do not honor the correct extension when run as a part of a multiproject build

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated MNG-1682:
--

Patch Submitted: [Yes]

> Plugins do not honor the correct extension when run as a part of a 
> multiproject build
> -
>
> Key: MNG-1682
> URL: http://jira.codehaus.org/browse/MNG-1682
> Project: Maven 2
>  Issue Type: Bug
>  Components: Plugins and Lifecycle
>Affects Versions: 2.0
> Environment: Windows NT; JDK 1.5
>Reporter: Nigel Magnay
> Fix For: 2.1.x
>
> Attachments: MNG-1682-ittest.patch, ReactorProblem.tar.gz
>
>
> I have a plugin with a component.xml described here.
> I think the component.xml is correct - it certainly looks the
> same as the plexus examples.
> My project that uses this plugin works entirely correctly, *unless* it
> is a part of a multiproject build, in which case it uses the wrong
> extension. I don't know why this would be the case unless I've missed
> something?
> In same directory:
> W:\kms\dev\apps\kms>mvn install
> [INFO] Scanning for projects...
> [INFO] 
> 
> [INFO] Building KMS Application Code
> [INFO]task-segment: [install]
> [INFO] 
> 
> [INFO] [cargo2:uberwar]
> [INFO] [install:install]
> [INFO] Installing W:\1244 - Knowledge Management System
> (KMS)\dev\apps\kms\target\kms-2.0-SNAPSHOT.war to C:\Documents and
> Settings\nig
> el.magnay\.m2\repository\com\cswgroup\kms\kms\2.0-SNAPSHOT\kms-2.0-SNAPSHOT.war
> [INFO] 
> 
> [INFO] BUILD SUCCESSFUL
> [INFO] 
> 
> [INFO] Total time: 1 minute 9 seconds
> [INFO] Finished at: Thu Nov 24 11:46:53 GMT 2005
> [INFO] Final Memory: 3M/6M
> [INFO] 
> 
> As a part of a multiproject:
> 
> [INFO] 
> 
> [INFO] Building KMS Application Code
> [INFO]task-segment: [install]
> [INFO] 
> 
> [INFO] [cargo2:uberwar]
> [INFO] [install:install]
> [INFO] Installing W:\1244 - Knowledge Management System
> (KMS)\dev\apps\kms\target\kms-2.0-SNAPSHOT.war to C:\Documents and
> Settings\nig
> el.magnay\.m2\repository\com\cswgroup\kms\kms\2.0-SNAPSHOT\kms-2.0-SNAPSHOT.uberwar
> 
> Config of plugin:
> 
>  
>
>  org.apache.maven.lifecycle.mapping.LifecycleMapping
>  uberwar
>  
> org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping
>  
>
>  
>org.codehaus.cargo.maven2:cargo-maven2-plugin:uberwar
>  
>  
> org.apache.maven.plugins:maven-install-plugin:install
>  
> org.apache.maven.plugins:maven-deploy-plugin:deploy
>
>  
>
>
>  org.apache.maven.artifact.handler.ArtifactHandler
>  uberwar
>  
> org.apache.maven.artifact.handler.DefaultArtifactHandler
>  
>uberwar
> war
>uberwar
>  
>
>  
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2799) Plugin descriptor extractor crashes on certain types of Java source files

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated MNG-2799:
--

Patch Submitted: [Yes]

> Plugin descriptor extractor crashes on certain types of Java source files
> -
>
> Key: MNG-2799
> URL: http://jira.codehaus.org/browse/MNG-2799
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Plugin Creation Tools
> Environment: Tested with Maven version 2.0.4, and 2.0.x SNAPSHOT.
>Reporter: Paul Gier
> Fix For: Reviewed Pending Version Assignment
>
> Attachments: JavaMojoDescriptorExtractor.java, 
> JavaMojoDescriptorExtractor.java
>
>
> Part of my plugin includes a .java file that contains an annotation type 
> declaration.  It looks like this:
> {quote}
> package org.jboss.lang.annotation;
> import java.lang.annotation.ElementType;
> import java.lang.annotation.Retention;
> import java.lang.annotation.RetentionPolicy;
> import java.lang.annotation.Target;
> @Retention(RetentionPolicy.RUNTIME)
> @Target(ElementType.ANNOTATION_TYPE)
> public @interface Inherited {
> }
> {quote}
> When the JavaMojoDescriptorExtractor encounters this file it crashes because 
> of an ArrayIndexOutOfBoundsException.  Because the code is trying to access 
> the 1st element of a zero length array.  The attached file has a simple fix 
> where the descriptor extractor just ignores any java source file that does 
> not contain a valid class.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Moved: (MSITE-251) tr locale support

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MSITE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter moved MNG-2882 to MSITE-251:
-

Affects Version/s: (was: 2.0.5)
Fix Version/s: (was: Reviewed Pending Version Assignment)
  Component/s: (was: Multiple Language Support)
   Complexity:   (was: Intermediate)
  Key: MSITE-251  (was: MNG-2882)
  Project: Maven 2.x Site Plugin  (was: Maven 2)

> tr locale support
> -
>
> Key: MSITE-251
> URL: http://jira.codehaus.org/browse/MSITE-251
> Project: Maven 2.x Site Plugin
>  Issue Type: New Feature
> Environment: Windows XP
>Reporter: gulcan yalcinkaya
>Priority: Trivial
> Attachments: project-info-report_tr.properties, 
> site-plugin_tr.properties
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2882) tr locale support

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated MNG-2882:
--

Patch Submitted: [Yes]

> tr locale support
> -
>
> Key: MNG-2882
> URL: http://jira.codehaus.org/browse/MNG-2882
> Project: Maven 2
>  Issue Type: New Feature
> Environment: Windows XP
>Reporter: gulcan yalcinkaya
>Priority: Trivial
> Attachments: project-info-report_tr.properties, 
> site-plugin_tr.properties
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2940) Add a method to the embedder to list available versions of an artifact

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated MNG-2940:
--

Patch Submitted: [Yes]

> Add a method to the embedder to list available versions of an artifact
> --
>
> Key: MNG-2940
> URL: http://jira.codehaus.org/browse/MNG-2940
> Project: Maven 2
>  Issue Type: New Feature
>  Components: Embedding
>Affects Versions: 2.1.x
>Reporter: Carlos Sanchez
>Assignee: Jason van Zyl
> Fix For: Reviewed Pending Version Assignment
>
> Attachments: patch.txt, patch.txt
>
>
> I've added a method following the style of the resolve method already present
> public void resolve( Artifact artifact, List remoteRepositories, 
> ArtifactRepository localRepository ) throws ArtifactResolutionException, 
> ArtifactNotFoundException

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-3004) Allow build lifecycle to execute tasks in parallel

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated MNG-3004:
--

Patch Submitted: [Yes]

> Allow build lifecycle to execute tasks in parallel
> --
>
> Key: MNG-3004
> URL: http://jira.codehaus.org/browse/MNG-3004
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Bootstrap & Build, General, Performance
>Affects Versions: 2.0.6
>Reporter: Nigel Magnay
> Fix For: Reviewed Pending Version Assignment
>
> Attachments: parallel-builds.patch
>
>
> One of the great advantages with maven over scripted build environments is 
> that it can calculate the dependencies of the build, and it could execute 
> items that are independent of each other in parallel.
> Unfortunately it currently doesn't do this, which would be a big win over 
> tools such as 'ant'. It also means that multicore machines have lots of idle 
> capacity when running a serial build that could be utilised.
> I had a quick shot at seeing what might be required. Bear in mind this is the 
> first time I have looked at maven internally, and I was just trying to feel 
> my way around and build a POC. I got some of the way there, but my build 
> threads don't seem to have the correct classpath - I think this is something 
> to do with plexus / classworlds - but I don't know enough.
> It'd be great to get this feature in a future version, or a way of running my 
> hack (figuring out why in a thread has not the plexus stuff) in the interim.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2010) Add new lifecycle phases for IT

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated MNG-2010:
--

Patch Submitted: [Yes]

> Add new lifecycle phases for IT
> ---
>
> Key: MNG-2010
> URL: http://jira.codehaus.org/browse/MNG-2010
> Project: Maven 2
>  Issue Type: Task
>  Components: integration tests, Plugins and Lifecycle
>Reporter: Vincent Massol
> Fix For: 2.0.x
>
> Attachments: MNG-2010-maven-lifecycle.patch, MNG-2010-site.patch
>
>
> Namely:
> * generate-integration-test-sources
> * process-integration-test-sources
> * generate-integration-test-resources
> * process-integration-test-resources
> * integration-test-compile
> and possibly a:
> * integration-test-package

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2871) Subartifact (ejb-client for example) are not reselved as active project artifacts

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated MNG-2871:
--

Patch Submitted: [Yes]

> Subartifact (ejb-client for example) are not reselved as active project 
> artifacts
> -
>
> Key: MNG-2871
> URL: http://jira.codehaus.org/browse/MNG-2871
> Project: Maven 2
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 2.0.4, 2.0.5
> Environment: Not platform dependent
>Reporter: Piotr Tabor
>Assignee: John Casey
> Fix For: 2.1-alpha-1
>
> Attachments: MavenProject.java, MNG-2871-core-integration-tests.diff, 
> root.tar
>
>
> I have prepared simple project to show the bug.
> It contains three artifacts: 
> |-root
> \--- ejb3
> \--- client
> Client depends on ejb3 with ejb-client.
> The local and remote repository must not contain those artifacts. 
> When I do "mvn -X compile" (or even integration-tests) on root project I will
> get those errors: 
> ...
> [DEBUG] Configuring mojo 
> 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' -->
> [DEBUG] (f) filters = []
> [DEBUG] (f) outputDirectory = /home/ptab/m2/bug/root/client/target/classes
> [DEBUG] (f) project = [EMAIL PROTECTED]
> [DEBUG] (f) resources = [EMAIL PROTECTED]
> [DEBUG] -- end configuration --
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [DEBUG] pl.waw.tabor:client:jar:1.0-SNAPSHOT (selected for null)
> [DEBUG] junit:junit:jar:3.8.1:test (selected for test)
> [DEBUG] pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT:compile (selected 
> for compile)
> [DEBUG] Skipping disabled repository Newitech-repository
> [DEBUG] Skipping disabled repository central
> [DEBUG] ejb3: using locally installed snapshot
> [DEBUG] Trying repository Newitech-snapshots-repository
> Downloading: 
> scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar
> [WARNING] Unable to get resource 
> 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository 
> Newitech-snapshots-repository 
> (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots)
> [DEBUG] Skipping disabled repository Newitech-repository
> [DEBUG] Trying repository Newitech-publiczne
> Downloading: 
> scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne//pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar
> [WARNING] Unable to get resource 
> 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository 
> Newitech-publiczne 
> (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/)
> [DEBUG] Trying repository Maven Snapshots
> Downloading: 
> http://people.apache.org/maven-snapshot-repository/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar
> [WARNING] Unable to get resource 
> 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Maven 
> Snapshots (http://people.apache.org/maven-snapshot-repository)
> [DEBUG] Trying repository codehausSnapshots
> Downloading: 
> http://snapshots.maven.codehaus.org/maven2/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar
> [WARNING] Unable to get resource 
> 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository 
> codehausSnapshots (http://snapshots.maven.codehaus.org/maven2)
> [DEBUG] Skipping disabled repository central
> [DEBUG] Unable to download the artifact from any repository
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \
> -Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file
> Path to dependency:
> 1) pl.waw.tabor:client:jar:1.0-SNAPSHOT
> 2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT
> pl.waw.tabor:ejb3:ejb-client:1.0-SNAPSHOT
> from the specified remote repositories:
> Maven Snapshots (http://people.apache.org/maven-snapshot-repository),
> central (http://repo1.maven.org/maven2),
> codehausSnapshots (http://snapshots.maven.codehaus.org/maven2),
> Newitech-snapshots-repository 
> (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots),
> Newitech-publiczne 
> (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/),
> Newitech-repository 
> (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech)
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn in

[jira] Created: (MNG-3161) im trying to run mvn deploy:deploy and it supplies error

[eyal david (JIRA)]

im trying to run mvn deploy:deploy and it supplies error 
-

 Key: MNG-3161
 URL: http://jira.codehaus.org/browse/MNG-3161
 Project: Maven 2
  Issue Type: Bug
  Components: Deployment
Affects Versions: 2.0.7
Reporter: eyal david


hello i need help in deploymeny issue 
im trying to deploy my jar to our company remote repository 
im getting an error :The packaging for this project did not assign a file to 
the build artifact

what  I need to wirte more in the pom file ? 

 im guessing that something is missing 

thank you for your help 




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-1493) Support in multiproject environment modules with different named POMs

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated MNG-1493:
--

Patch Submitted: [Yes]

> Support in multiproject environment modules with different named POMs
> -
>
> Key: MNG-1493
> URL: http://jira.codehaus.org/browse/MNG-1493
> Project: Maven 2
>  Issue Type: Improvement
>  Components: POM
>Affects Versions: 2.0
>Reporter: Joerg Schaible
>Priority: Minor
> Fix For: 2.1.x
>
> Attachments: DefaultMaven.diff
>
>
> Command line version of Maven 2 supports POMs with a different name using the 
> -f option. Unfortunately such POMs cannot be used as modules, since the value 
> of the module tag is defined as a directory to another pom.xml instead of a 
> pathname to another POM. Only if the value is not already an existing file 
> the value should be treated as directory with a present pom.xml file. Similar 
> situation applies to the relativePath element of the parent tag.
> This makes the generation of different artifacts from the same sources (with 
> some modifications) much more easy. Currently you will have to put the POMs 
> in separate directories and modify the sourec location into another module.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-3089) DefaultArtifactCollector does not filter ResolutionListener events

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated MNG-3089:
--

Patch Submitted: [Yes]

> DefaultArtifactCollector does not filter ResolutionListener events
> --
>
> Key: MNG-3089
> URL: http://jira.codehaus.org/browse/MNG-3089
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.7
>Reporter: Mark Hobson
> Attachments: MNG-3089.patch
>
>
> The ArtifactFilter passed to the ArtifactCollector.collect methods is only 
> used to filter the ArtifactResolutionResult.artifacts and not the 
> ResolutionListener events.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2254) the encoding parameter in xml declaration of POM is ignored

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated MNG-2254:
--

Patch Submitted: [Yes]

> the encoding parameter in xml declaration of POM is ignored 
> 
>
> Key: MNG-2254
> URL: http://jira.codehaus.org/browse/MNG-2254
> Project: Maven 2
>  Issue Type: Bug
>  Components: POM::Encoding
>Reporter: Naoki Nose
>Assignee: Jason van Zyl
> Fix For: 2.0.8
>
> Attachments: DefaultMavenProjectBuilder.diff, MNG-2254-2.diff, 
> MNG-2254.diff, MNG-2254_artifact.diff, MNG-2254_components.diff, 
> modello-plugin-xpp3.diff
>
>
> DefaultMavenProjectBuilder reads POM in system default character encoding, 
> and the encoding parameter in xml declartion is ignored.
> to fix this problem, We should
> -  fix  modello-plugin-xpp3 to use the xml parser which is able to handle the 
> encoding parameter properly
> - regenerate maven-model using fixed modello-plugin-xpp3
> - fix DefaultMavenProjectBuilder to use regenerated maven-model properly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MNG-3119) Duplicate attached artifacts should not be allowed.

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated MNG-3119:
--

Patch Submitted: [Yes]

> Duplicate attached artifacts should not be allowed.
> ---
>
> Key: MNG-3119
> URL: http://jira.codehaus.org/browse/MNG-3119
> Project: Maven 2
>  Issue Type: Improvement
>  Components: General
>Affects Versions: 2.0.7
>Reporter: Paul Gier
> Attachments: MNG-3119-maven-project-r558713.patch
>
>
> Currently, a project allows duplicate artifacts to be attached.  This causes 
> the second and other additional artifacts to overwrite the first attached 
> artifact.  This occurs during the package, install, and deploy phases.
> This can be reproduced by adding three instances of the source plugin (with 
> different ids) to a project build configuration.  The 2nd plugin will 
> overwrite the first, and the third will overwrite the second.
> The desired behaviour is that the user should receive a warning or error when 
> this happens.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MNG-2994) Snapshot repositories are not checked when using ranges

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MNG-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated MNG-2994:
--

Patch Submitted: [Yes]

> Snapshot repositories are not checked when using ranges
> ---
>
> Key: MNG-2994
> URL: http://jira.codehaus.org/browse/MNG-2994
> Project: Maven 2
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.6
> Environment: Windows XP, Cygwin
>Reporter: Mark Hobson
>Assignee: Jason van Zyl
> Fix For: Reviewed Pending Version Assignment
>
> Attachments: MNG-2994-2.patch, MNG-2994-3.patch, 
> MNG-2994-core-it.patch, patch.txt
>
>
> The attached patch demonstrates the problem by adding it0121.  If the test 
> repository has releases enabled, the test passes, when they are disabled, the 
> test fails.  This appears to be due to DefaultArtifact.isSnapshot returning 
> false for unresolved ranges, thus causing snapshot repositories to be 
> disabled when resolving 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: (MRELEASE-124) Impossible to depend on a deployed snapshot

[Brett Porter (JIRA)]

 [ 
http://jira.codehaus.org/browse/MRELEASE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter closed MRELEASE-124.
-

   Resolution: Fixed
Fix Version/s: 2.0-beta-7

applied, thanks for that!

> Impossible to depend on a deployed snapshot
> ---
>
> Key: MRELEASE-124
> URL: http://jira.codehaus.org/browse/MRELEASE-124
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>Affects Versions: 2.0-beta-4
>Reporter: Mike Perham
>Assignee: Brett Porter
>Priority: Critical
> Fix For: 2.0-beta-7
>
> Attachments: 
> maven-release-manager-1.0-alpha-4-SNAPSHOT.rev552741.patch, 
> maven-release-plugin-2.0-beta-7-SNAPSHOT.rev552741.patch, 
> releasePluginIgnoreSnapshot.patch, ReleaseUtils.rev552741.patch
>
>
> I have a SNAPSHOT of the war plugin that I built and deployed to fix a 
> blocker for us (MWAR-39) that has not been released.  In my POM, I refer to 
> it like this:
> 
>   
> 
>   maven-war-plugin
>   2.0.1-20060525.222101-1
> I did this specifically so the release plugin would not think it was a 
> SNAPSHOT so I could release the module.  But when I do try to release, I get 
> this error:
> [INFO] Can't release project due to non released dependencies :
> 
> org.apache.maven.plugins:maven-war-plugin:maven-plugin:2.0.1-SNAPSHOT:runtime
> in project 'UDDI WAR' (com.webify.fabric:fabric-uddi-web:war:1.1.0-SNAPSHOT)
> This is because in ArtifactUtils.isSnapshot, it specifically disallows the 
> version pattern created by the deploy plugin.
> So consider my usecase: I'm Joe Corporate, a user who needs a war bug fix in 
> their build process ASAP.  I build and deploy the latest war plugin to my 
> internal repo and reference that explicit timestamp version in my build 
> process.  Now I can understand why you disallow this because if I try to 
> build outside of our corporate walls, it will not work.  But I can't use the 
> release plugin to release either because it requires me to check the modified 
> POMs into my SCM and the war plugin is in Apache's SCM and I can't check into 
> it.
> There's only two hack workarounds I can think of: 1) explicitly reversion the 
> jar to not include SNAPSHOT or the specific timestamp pattern. 2) Check the 
> war plugin into our own SCM and release from there, effectively forking the 
> code.
> Your thoughts?  How can we fix bugs in the build process locally and still 
> use the release plugin?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira