[jira] Created: (SUREFIRE-364) 2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency

2007-10-27 Thread Matt Read (JIRA)
2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency
---

 Key: SUREFIRE-364
 URL: http://jira.codehaus.org/browse/SUREFIRE-364
 Project: Maven Surefire
  Issue Type: Bug
  Components: plugin
Affects Versions: 2.4
Reporter: Matt Read
Priority: Blocker


Previously stable build now reports this:

 27-Oct-2007 12:04:15   [INFO] Failed to resolve artifact.
27-Oct-2007 12:04:15
27-Oct-2007 12:04:15Couldn't find a version in [1.0-alpha-7, 1.0-alpha-8, 
1.0-alpha-9] to match range [1.0-alpha-10-SNAPSHOT,1.0-alpha-10-SNAPSHOT]
27-Oct-2007 12:04:15  org.codehaus.plexus:plexus-archiver:jar:null
27-Oct-2007 12:04:15
27-Oct-2007 12:04:15from the specified remote repositories:
27-Oct-2007 12:04:15  maven.catlin.com.repo.releases 
(http://maven.catlin.com/​maven2-repo/​releases),
27-Oct-2007 12:04:15  Apache Snapshots 
(http://people.apache.org/​repo/​m2-snapshot-repository),
27-Oct-2007 12:04:15  stat-scm-sourceforge 
(http://stat-scm.sourceforge.net/​maven2),
27-Oct-2007 12:04:15  maven.catlin.com.repo.snapshots 
(http://maven.catlin.com/​maven2-repo/​snapshots),
27-Oct-2007 12:04:15  central (http://repo1.maven.org/​maven2),
27-Oct-2007 12:04:15  codehaus.snapshots 
(http://snapshots.repository.codehaus.org),
27-Oct-2007 12:04:15  apache.snapshots 
(http://people.apache.org/​repo/​m2-snapshot-repository),
27-Oct-2007 12:04:15  Codehaus Snapshots 
(http://snapshots.repository.codehaus.org/​;)
27-Oct-2007 12:04:15


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (SUREFIRE-364) 2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency

2007-10-27 Thread Matt Read (JIRA)
2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency
---

 Key: SUREFIRE-364
 URL: http://jira.codehaus.org/browse/SUREFIRE-364
 Project: Maven Surefire
  Issue Type: Bug
  Components: plugin
Affects Versions: 2.4
Reporter: Matt Read
Priority: Blocker


Previously stable build now reports this:

27-Oct-2007 12:04:15 [INFO] Failed to resolve artifact.
27-Oct-2007 12:04:15
27-Oct-2007 12:04:15 Couldn't find a version in [1.0-alpha-7, 1.0-alpha-8, 
1.0-alpha-9] to match range [1.0-alpha-10-SNAPSHOT,1.0-alpha-10-SNAPSHOT]
27-Oct-2007 12:04:15 org.codehaus.plexus:plexus-archiver:jar:null
27-Oct-2007 12:04:15
27-Oct-2007 12:04:15 from the specified remote repositories:
27-Oct-2007 12:04:15 maven.catlin.com.repo.releases 
(http://maven.catlin.com/​maven2-repo/​releases),
27-Oct-2007 12:04:15 Apache Snapshots 
(http://people.apache.org/​repo/​m2-snapshot-repository),
27-Oct-2007 12:04:15 stat-scm-sourceforge 
(http://stat-scm.sourceforge.net/​maven2),
27-Oct-2007 12:04:15 maven.catlin.com.repo.snapshots 
(http://maven.catlin.com/​maven2-repo/​snapshots),
27-Oct-2007 12:04:15 central (http://repo1.maven.org/​maven2),
27-Oct-2007 12:04:15 codehaus.snapshots 
(http://snapshots.repository.codehaus.org),
27-Oct-2007 12:04:15 apache.snapshots 
(http://people.apache.org/​repo/​m2-snapshot-repository),
27-Oct-2007 12:04:15 Codehaus Snapshots 
(http://snapshots.repository.codehaus.org/​
27-Oct-2007 12:04:15 

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




[jira] Commented: (SUREFIRE-364) 2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency

2007-10-27 Thread Olivier Lamy (JIRA)

[ 
http://jira.codehaus.org/browse/SUREFIRE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111662
 ] 

Olivier Lamy commented on SUREFIRE-364:
---

The snapshot is on the place.
Look here : 
http://snapshots.repository.codehaus.org/org/codehaus/plexus/plexus-archiver/1.0-alpha-10-SNAPSHOT/.
If you don't want trouble don't use snapshot repositories especially apache 
plugins snapshot repository !


> 2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency
> ---
>
> Key: SUREFIRE-364
> URL: http://jira.codehaus.org/browse/SUREFIRE-364
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: plugin
>Affects Versions: 2.4
>Reporter: Matt Read
>Priority: Blocker
>
> Previously stable build now reports this:
> 27-Oct-2007 12:04:15 [INFO] Failed to resolve artifact.
> 27-Oct-2007 12:04:15
> 27-Oct-2007 12:04:15 Couldn't find a version in [1.0-alpha-7, 1.0-alpha-8, 
> 1.0-alpha-9] to match range [1.0-alpha-10-SNAPSHOT,1.0-alpha-10-SNAPSHOT]
> 27-Oct-2007 12:04:15 org.codehaus.plexus:plexus-archiver:jar:null
> 27-Oct-2007 12:04:15
> 27-Oct-2007 12:04:15 from the specified remote repositories:
> 27-Oct-2007 12:04:15 maven.catlin.com.repo.releases 
> (http://maven.catlin.com/​maven2-repo/​releases),
> 27-Oct-2007 12:04:15 Apache Snapshots 
> (http://people.apache.org/​repo/​m2-snapshot-repository),
> 27-Oct-2007 12:04:15 stat-scm-sourceforge 
> (http://stat-scm.sourceforge.net/​maven2),
> 27-Oct-2007 12:04:15 maven.catlin.com.repo.snapshots 
> (http://maven.catlin.com/​maven2-repo/​snapshots),
> 27-Oct-2007 12:04:15 central (http://repo1.maven.org/​maven2),
> 27-Oct-2007 12:04:15 codehaus.snapshots 
> (http://snapshots.repository.codehaus.org),
> 27-Oct-2007 12:04:15 apache.snapshots 
> (http://people.apache.org/​repo/​m2-snapshot-repository),
> 27-Oct-2007 12:04:15 Codehaus Snapshots 
> (http://snapshots.repository.codehaus.org/​
> 27-Oct-2007 12:04:15 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (SUREFIRE-364) 2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency

2007-10-27 Thread Olivier Lamy (JIRA)

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

Olivier Lamy closed SUREFIRE-364.
-

  Assignee: Olivier Lamy
Resolution: Cannot Reproduce

Re open it if you have trouble because I can't reproduce your issue. 

> 2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency
> ---
>
> Key: SUREFIRE-364
> URL: http://jira.codehaus.org/browse/SUREFIRE-364
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: plugin
>Affects Versions: 2.4
>Reporter: Matt Read
>Assignee: Olivier Lamy
>Priority: Blocker
>
> Previously stable build now reports this:
> 27-Oct-2007 12:04:15 [INFO] Failed to resolve artifact.
> 27-Oct-2007 12:04:15
> 27-Oct-2007 12:04:15 Couldn't find a version in [1.0-alpha-7, 1.0-alpha-8, 
> 1.0-alpha-9] to match range [1.0-alpha-10-SNAPSHOT,1.0-alpha-10-SNAPSHOT]
> 27-Oct-2007 12:04:15 org.codehaus.plexus:plexus-archiver:jar:null
> 27-Oct-2007 12:04:15
> 27-Oct-2007 12:04:15 from the specified remote repositories:
> 27-Oct-2007 12:04:15 maven.catlin.com.repo.releases 
> (http://maven.catlin.com/​maven2-repo/​releases),
> 27-Oct-2007 12:04:15 Apache Snapshots 
> (http://people.apache.org/​repo/​m2-snapshot-repository),
> 27-Oct-2007 12:04:15 stat-scm-sourceforge 
> (http://stat-scm.sourceforge.net/​maven2),
> 27-Oct-2007 12:04:15 maven.catlin.com.repo.snapshots 
> (http://maven.catlin.com/​maven2-repo/​snapshots),
> 27-Oct-2007 12:04:15 central (http://repo1.maven.org/​maven2),
> 27-Oct-2007 12:04:15 codehaus.snapshots 
> (http://snapshots.repository.codehaus.org),
> 27-Oct-2007 12:04:15 apache.snapshots 
> (http://people.apache.org/​repo/​m2-snapshot-repository),
> 27-Oct-2007 12:04:15 Codehaus Snapshots 
> (http://snapshots.repository.codehaus.org/​
> 27-Oct-2007 12:04:15 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-549) Strange Groovy entries in the repository

2007-10-27 Thread Paul King (JIRA)

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

Paul King commented on MEV-549:
---

Take 2: Let me know if this sounds OK.

Please remove the following file as it is unusable:
maven/groovy/jars/-0.2.jar

Please update the following pom files:
http://dist.codehaus.org/groovy/poms/groovy-all-1.1-beta-1.pom -> 
http://repo1.maven.org/maven/groovy/poms/groovy-all-1.1-beta-1.pom
http://dist.codehaus.org/groovy/poms/groovy-all-1.1-beta-2.pom -> 
http://repo1.maven.org/maven/groovy/poms/groovy-all-1.1-beta-2.pom
(this leaves all dependencies and other info unchanged; just changes the 
groupId from org.codehaus.groovy to groovy to match the directory they are in)

If this works fine, then we can look at what needs to be done for the 
groovy-all and groovy-all-minimal artifacts. Thanks.

> Strange Groovy entries in the repository
> 
>
> Key: MEV-549
> URL: http://jira.codehaus.org/browse/MEV-549
> Project: Maven Evangelism
>  Issue Type: Task
>  Components: Relocation
>Reporter: Paul King
>
> Hi, I am trying to track down why some spurious entries are showing up for 
> Groovy. Please let me know if this is not the appropriate forum.
> Groovy used to publish into the maven1 repo and there was some magic in place 
> that "republished" artifacts into the maven 2 repo.
> Groovy now publishes into the maven2 repo and some magic "republishes" the 
> jars back into repo1.
> Unfortunately, the old magic still seems to be in place and a spurious entry 
> appears (under the old groupId) in the maven 2 repo.
> Does anyone know how to turn off the old magic? I guess then we need to clean 
> up the spurious artifacts but I can submit separate issue(s) for that if 
> needed.
> Here is my understanding of the trail:
> (1) Project publishes to http://repository.codehaus.org/org/codehaus/groovy/
> (2) Sync happens to copy artifacts to 
> http://repo1.maven.org/maven2/org/codehaus/groovy/
> (3) Magic happens here to copy artifacts back to maven 1 land ending up at 
> http://repo1.maven.org/maven/groovy/jars/
> This is actually broken in that it should be being copied to 
> http://repo1.maven.org/maven/org.codehaus.groovy/jars/
> and also the copying of the poms to http://repo1.maven.org/maven/groovy/poms 
> (which of course should also
> be changed to http://repo1.maven.org/maven/org.codehaus.groovy/poms) has 
> stopped working at some point.
> (4) Additional magic which should be turned off now occurs at this point and 
> copies the artifacts back to the maven 2
> repo. An example of this from 1.1-rc-1 (12 Oct 2007) can be found here:
> http://repo1.maven.org/maven2/groovy/groovy-all/1.1-rc-1/
> This is in the wrong place given the groupId and doesn't contain a POM.
> I am trying to track this down so I can request that step (4) be turned off.
> Thanks, Paul.

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




[jira] Created: (MINSTALL-44) add XML encoding support for POM reading/writing

2007-10-27 Thread Herve Boutemy (JIRA)
add XML encoding support for POM reading/writing


 Key: MINSTALL-44
 URL: http://jira.codehaus.org/browse/MINSTALL-44
 Project: Maven 2.x Install Plugin
  Issue Type: Improvement
Affects Versions: 2.2
Reporter: Herve Boutemy
Assignee: Herve Boutemy
 Fix For: 2.3


With MNG-2254 being fixed in Maven 2.0.8, same XML encoding support is 
necessary in this plugin to avoid data corruption when reading and writing POM 
files

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




[jira] Created: (MDEPLOY-66) add XML encoding support for POM reading/writing

2007-10-27 Thread Herve Boutemy (JIRA)
add XML encoding support for POM reading/writing


 Key: MDEPLOY-66
 URL: http://jira.codehaus.org/browse/MDEPLOY-66
 Project: Maven 2.x Deploy Plugin
  Issue Type: Improvement
Affects Versions: 2.3
Reporter: Herve Boutemy


With MNG-2254 being fixed in Maven 2.0.8, same XML encoding support is 
necessary in this plugin to avoid data corruption when reading and writing POM 
files

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




[jira] Created: (MREPOSITORY-10) add XML encoding support for POM reading/writing

2007-10-27 Thread Herve Boutemy (JIRA)
add XML encoding support for POM reading/writing


 Key: MREPOSITORY-10
 URL: http://jira.codehaus.org/browse/MREPOSITORY-10
 Project: Maven 2.x Repository Plugin
  Issue Type: Improvement
Affects Versions: 2.0
Reporter: Herve Boutemy


With MNG-2254 being fixed in Maven 2.0.8, same XML encoding support is 
necessary in this plugin to avoid data corruption when reading and writing POM 
files

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




[jira] Updated: (MREPOSITORY-10) add XML encoding support for POM reading/writing

2007-10-27 Thread Herve Boutemy (JIRA)

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

Herve Boutemy updated MREPOSITORY-10:
-

 Assignee: Herve Boutemy
Fix Version/s: 2.1

> add XML encoding support for POM reading/writing
> 
>
> Key: MREPOSITORY-10
> URL: http://jira.codehaus.org/browse/MREPOSITORY-10
> Project: Maven 2.x Repository Plugin
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 2.1
>
>
> With MNG-2254 being fixed in Maven 2.0.8, same XML encoding support is 
> necessary in this plugin to avoid data corruption when reading and writing 
> POM files

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




[jira] Updated: (MDEPLOY-66) add XML encoding support for POM reading/writing

2007-10-27 Thread Herve Boutemy (JIRA)

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

Herve Boutemy updated MDEPLOY-66:
-

 Assignee: Herve Boutemy
Fix Version/s: 2.4

> add XML encoding support for POM reading/writing
> 
>
> Key: MDEPLOY-66
> URL: http://jira.codehaus.org/browse/MDEPLOY-66
> Project: Maven 2.x Deploy Plugin
>  Issue Type: Improvement
>Affects Versions: 2.3
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 2.4
>
>
> With MNG-2254 being fixed in Maven 2.0.8, same XML encoding support is 
> necessary in this plugin to avoid data corruption when reading and writing 
> POM files

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




[jira] Created: (MENFORCER-20) add XML encoding support for POM reading/writing

2007-10-27 Thread Herve Boutemy (JIRA)
add XML encoding support for POM reading/writing


 Key: MENFORCER-20
 URL: http://jira.codehaus.org/browse/MENFORCER-20
 Project: Maven 2.x Enforcer Plugin
  Issue Type: Improvement
Affects Versions: 1.0-alpha-3
Reporter: Herve Boutemy
Assignee: Brian Fox


With MNG-2254 being fixed in Maven 2.0.8, same XML encoding support is 
necessary in this plugin to avoid data corruption when reading and writing POM 
files

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




[jira] Updated: (MENFORCER-20) add XML encoding support for POM reading/writing

2007-10-27 Thread Herve Boutemy (JIRA)

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

Herve Boutemy updated MENFORCER-20:
---

Assignee: Herve Boutemy  (was: Brian Fox)

> add XML encoding support for POM reading/writing
> 
>
> Key: MENFORCER-20
> URL: http://jira.codehaus.org/browse/MENFORCER-20
> Project: Maven 2.x Enforcer Plugin
>  Issue Type: Improvement
>Affects Versions: 1.0-alpha-3
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>
> With MNG-2254 being fixed in Maven 2.0.8, same XML encoding support is 
> necessary in this plugin to avoid data corruption when reading and writing 
> POM files

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




[jira] Commented: (MSOURCES-17) Source plugin packages each module with *all* module's sources, in multi-module build

2007-10-27 Thread Dennis Lundberg (JIRA)

[ 
http://jira.codehaus.org/browse/MSOURCES-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111690
 ] 

Dennis Lundberg commented on MSOURCES-17:
-

Could this issue be closed now as "Cannot reproduce"?

> Source plugin packages each module with *all* module's sources, in 
> multi-module build
> -
>
> Key: MSOURCES-17
> URL: http://jira.codehaus.org/browse/MSOURCES-17
> Project: Maven 2.x Source Plugin
>  Issue Type: Bug
>Reporter: Howard M. Lewis Ship
>
> Just upgraded from 2.0.4 to 2.0.5.
> Performed a mvn clean install on my project.
> Everything built correctly, but the source plugin:
>   
>   
> org.apache.maven.plugins
>   
> maven-source-plugin
>   
>   
>   
>   jar
>   
>   
>   
>   
> Packaged each sub-module's -sources.jar with all the sources from all the 
> modules.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MSOURCES-19) source plugin with phase 'package' does not upload sources.jar into repository

2007-10-27 Thread Dennis Lundberg (JIRA)

[ 
http://jira.codehaus.org/browse/MSOURCES-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111691
 ] 

Dennis Lundberg commented on MSOURCES-19:
-

Why do you want to change the phase that maven-source-plugin is run in?

The default phase is package, which seems natural to me. You are packaging your 
artifacts.

> source plugin with phase 'package' does not upload sources.jar into repository
> --
>
> Key: MSOURCES-19
> URL: http://jira.codehaus.org/browse/MSOURCES-19
> Project: Maven 2.x Source Plugin
>  Issue Type: Bug
>Affects Versions: 2.0.3
> Environment: windows
>Reporter: werner mueller
>Assignee: Stephane Nicoll
>
> hallo
> when using the source plugin with phase install:
> 
> maven-source-plugin
> 
> true
> 
>   
>   
>   install
>   
>   jar
>   test-jar
>   
>   
>   
>   
> the generated sources are uploaded into the snapshot repository just fine 
> (when i execute 'mvn deploy')
> when the phase is changed to deploy:
>   
>   maven-source-plugin
> 
> true
> 
>   
>   
>   deploy
>   
>   jar
>   test-jar
>   
>   
>   
>   
> the sources jars are created but not copied into the local repository nor 
> uploaded into the snapshot repository.
> i would like to create source jar's in a later phase than install because in 
> eclipse/m2eclipse an install would take too long since it creates the sources 
> jar every time.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MSOURCES-20) Allow Source plugin to specify alternate DistributionManagement

2007-10-27 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg updated MSOURCES-20:


Affects Version/s: (was: 2.0.4)
   2.0.3
Fix Version/s: (was: 2.0.4)

> Allow Source plugin to specify alternate DistributionManagement
> ---
>
> Key: MSOURCES-20
> URL: http://jira.codehaus.org/browse/MSOURCES-20
> Project: Maven 2.x Source Plugin
>  Issue Type: Improvement
>Affects Versions: 2.0.3
>Reporter: James William Dumay
> Attachments: maven-source-plugin.patch
>
>
> The following patch allows the source 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: (MSOURCES-18) Honour targetPath

2007-10-27 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg closed MSOURCES-18.
---

   Resolution: Fixed
Fix Version/s: 2.0.4

Patch applied and new SNAPSHOT deployed.
Thanks!

> Honour targetPath
> -
>
> Key: MSOURCES-18
> URL: http://jira.codehaus.org/browse/MSOURCES-18
> Project: Maven 2.x Source Plugin
>  Issue Type: Improvement
>Affects Versions: 2.0.3
> Environment: All
>Reporter: Tim Pizey
>Assignee: Dennis Lundberg
> Fix For: 2.0.4
>
> Attachments: honourTargetPath.patch
>
>
> Attached patch checks if targetPath has been set for a resource and calls 
> archive with prifix if it has. 
> Existing tests all pass. 
> I have not added a test for new functionality, can do it needed.
> It might be that if targetPath is set then the plugin should add a duplicate 
> to the archive - I do not know how people use the 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




[jira] Commented: (MSOURCES-21) Allow classes to be bundled with the source code

2007-10-27 Thread Dennis Lundberg (JIRA)

[ 
http://jira.codehaus.org/browse/MSOURCES-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111693
 ] 

Dennis Lundberg commented on MSOURCES-21:
-

I agree with Benjamin here. This sounds like a case for the assembly-plugin.

> Allow classes to be bundled with the source code
> 
>
> Key: MSOURCES-21
> URL: http://jira.codehaus.org/browse/MSOURCES-21
> Project: Maven 2.x Source Plugin
>  Issue Type: New Feature
>Affects Versions: 2.0.3
>Reporter: Tom Schneider
>Priority: Minor
> Attachments: sourceplugin-includeClasses.patch
>
>
> We have the need to bundle the compiled class files with the source code and 
> other resources.  So I created a patch that adds a new configuration point 
> (includeClasses) that when set to true, will bundle not only the source code 
> and resources, but also the generated class files.

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




[jira] Commented: (MSOURCES-13) No-Forking mojos for use within a POM instead of CLI

2007-10-27 Thread Dennis Lundberg (JIRA)

[ 
http://jira.codehaus.org/browse/MSOURCES-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111698
 ] 

Dennis Lundberg commented on MSOURCES-13:
-

Are you saying that the "generate-sources" phase will be run twice?
Because SourceJarMojo has

@phase package (which also includes generate-sources)
and
@execute phase="generate-sources"

> No-Forking mojos for use within a POM instead of CLI
> 
>
> Key: MSOURCES-13
> URL: http://jira.codehaus.org/browse/MSOURCES-13
> Project: Maven 2.x Source Plugin
>  Issue Type: Improvement
> Environment: ALL
>Reporter: Ben Tatham
> Attachments: nofork.patch, nofork.patch
>
>
> The exiting jar at test-jar mojos will always cause a lifecycle fork and 
> generate-sources.  This can cause all kinds of undesired side effects when 
> using the source plugin with a pom, instead of CLI.  I propose a simple fix 
> (patch attached) to extend these two mojos in no-forking mode.  I can't think 
> of a better name for them.  
> This behaviour is similar to the difference between assembly:assembly and 
> assembly:attached.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MSOURCES-22) configuration option for source:jar to exclude resources

2007-10-27 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg closed MSOURCES-22.
---

   Resolution: Fixed
Fix Version/s: 2.0.4

Added a configuration parameter "excludeResources" for this that defaults to 
"false". Can also be set from the command line with
{code}
-Dsource.excludeResources=
{code}

Also deployed a new 2.0.4-SNAPSHOT so that you can try it out.

> configuration option for source:jar to exclude resources
> 
>
> Key: MSOURCES-22
> URL: http://jira.codehaus.org/browse/MSOURCES-22
> Project: Maven 2.x Source Plugin
>  Issue Type: Improvement
>Affects Versions: 2.0.3
>Reporter: Daniel Siegmann
>Assignee: Dennis Lundberg
>Priority: Minor
> Fix For: 2.0.4
>
>
> A typical use case for the source jar is attachment in an IDE, which allows 
> for access to javadocs, and debugging. For this case there is no need to 
> include resources in the source jar, as they will already be in the standard 
> jar.
> This does not create any errors, but it may be inconvenient if a project 
> includes large resources, such as images.
> It would be useful to provide a configuration option which allows the 
> resources to be excluded.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MSOURCES-24) jar misses resources from "generate-resources" phase

2007-10-27 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg updated MSOURCES-24:


Fix Version/s: 2.1

> jar misses resources from "generate-resources" phase
> 
>
> Key: MSOURCES-24
> URL: http://jira.codehaus.org/browse/MSOURCES-24
> Project: Maven 2.x Source Plugin
>  Issue Type: Improvement
>Affects Versions: 2.0.3
> Environment: Maven 2.0.7
>Reporter: Benjamin Bentmann
>Priority: Minor
> Fix For: 2.1
>
>
> When the goal source:jar is run directly from the command-line, the plugin 
> will miss resource files that get generated during the "generate-resources" 
> phase as the mojo currently only requires the "generate-sources" phase.
> Increasing the lifecycle requirements of the mojo to "generate-resources" 
> would also cause "process-sources" to get run. I cannot judge whether this 
> would cause any harm to existing plugin users. One might further consider to 
> increase the lifecycle requirement to "process-resources" so that both 
> sources and resources are in a consistent state before being packaged.
> Taking [MSOURCES-22|http://jira.codehaus.org/browse/MSOURCES-22] into 
> account, it might be advisable to separate the packaging of sources and 
> resources into two distinct mojos. The first mojo would only package the 
> (compile) source files and would therefore only require the 
> "generate-/process-sources" phase. The second mojo would package the source 
> files and the resources (similar to the current jar goal), requiring the 
> phase "generate-/process-resources". In contrast to adding a configuration 
> option to exclude resources, introducing a new mojo would allow to tune the 
> lifecycle requirements, hopefully supporting more use-cases for the 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




[jira] Updated: (MSOURCES-23) test-jar misses sources from "generate-test-sources" phase

2007-10-27 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg updated MSOURCES-23:


Fix Version/s: 2.1

> test-jar misses sources from "generate-test-sources" phase
> --
>
> Key: MSOURCES-23
> URL: http://jira.codehaus.org/browse/MSOURCES-23
> Project: Maven 2.x Source Plugin
>  Issue Type: Improvement
>Affects Versions: 2.0.3
> Environment: Maven 2.0.7
>Reporter: Benjamin Bentmann
>Priority: Minor
> Fix For: 2.1
>
>
> When the goal source:test-jar is run directly from the command-line, the 
> plugin will miss source files that get generated during the 
> "generate-test-sources" phase as the mojo currently only requires the 
> "generate-sources" phase.
> Though simply increasing the mojos lifecycle requirement would solve the 
> problem, it kind of looks ugly to have the lengthy and potentially failing 
> "compile" phase get run just to package test sources (first time I realize 
> practical limitations of Maven's simple waterfall lifecycle compared to 
> partially ordered goals...). An additional mojo like "generated-test-jar" 
> might therefore be the best solution to keep the majority of use-cases fast 
> but support the more sophisticated cases as well.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MSOURCES-20) Allow Source plugin to specify alternate DistributionManagement

2007-10-27 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg updated MSOURCES-20:


Fix Version/s: 2.1

> Allow Source plugin to specify alternate DistributionManagement
> ---
>
> Key: MSOURCES-20
> URL: http://jira.codehaus.org/browse/MSOURCES-20
> Project: Maven 2.x Source Plugin
>  Issue Type: Improvement
>Affects Versions: 2.0.3
>Reporter: James William Dumay
> Fix For: 2.1
>
> Attachments: maven-source-plugin.patch
>
>
> The following patch allows the source 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] Created: (MRAR-19) projects with packaging rar don't compile

2007-10-27 Thread Salvio Sergi (JIRA)
projects with packaging rar don't compile
-

 Key: MRAR-19
 URL: http://jira.codehaus.org/browse/MRAR-19
 Project: Maven 2.x Rar Plugin
  Issue Type: Bug
Affects Versions: 2.0
 Environment: windows xp professional
Reporter: Salvio Sergi
Priority: Trivial


In documentation (sub) projects it may be very useful to pack the generated 
site to an archive. I tried using rar and found this bug.

Steps to reproduce

* create a new (empty) project with the following pom.xml
{code} 


  4.0.0
  sample
  sample
  rar
  0.0.1

{code} 
* running {{noformat}} mvn package I get the following error
{noformat} 
[WARNING] Connector deployment descriptor: 
C:\projects\sample\target\sample-0.0.1\META-INF\ra.xml does not exist.
[INFO] Could not find manifest file: 
C:\projects\sample\src\main\rar\META-INF\MANIFEST.MF - Generating one
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Error assembling RAR

Embedded error: C:\projects\sample\target\sample-0.0.1 isn't a directory.
{noformat} 

I would expect this to work similarly to the jar packaging type...

*Workaround*: manually create a directory /target/sample-0.0.1 before running 
mvn 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] Commented: (MRAR-19) projects with packaging rar don't compile

2007-10-27 Thread Dennis Lundberg (JIRA)

[ 
http://jira.codehaus.org/browse/MRAR-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111703
 ] 

Dennis Lundberg commented on MRAR-19:
-

rar is not a packaging - it's a plugin.
Please see the documentation at
http://maven.apache.org/plugins/maven-rar-plugin/
and the FAQ at
http://maven.apache.org/plugins/maven-rar-plugin/faq.html


> projects with packaging rar don't compile
> -
>
> Key: MRAR-19
> URL: http://jira.codehaus.org/browse/MRAR-19
> Project: Maven 2.x Rar Plugin
>  Issue Type: Bug
>Affects Versions: 2.0
> Environment: windows xp professional
>Reporter: Salvio Sergi
>Priority: Trivial
>
> In documentation (sub) projects it may be very useful to pack the generated 
> site to an archive. I tried using rar and found this bug.
> Steps to reproduce
> * create a new (empty) project with the following pom.xml
> {code} 
> 
> 
>   4.0.0
>   sample
>   sample
>   rar
>   0.0.1
> 
> {code} 
> * running {{noformat}} mvn package I get the following error
> {noformat} 
> [WARNING] Connector deployment descriptor: 
> C:\projects\sample\target\sample-0.0.1\META-INF\ra.xml does not exist.
> [INFO] Could not find manifest file: 
> C:\projects\sample\src\main\rar\META-INF\MANIFEST.MF - Generating one
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Error assembling RAR
> Embedded error: C:\projects\sample\target\sample-0.0.1 isn't a directory.
> {noformat} 
> I would expect this to work similarly to the jar packaging type...
> *Workaround*: manually create a directory /target/sample-0.0.1 before running 
> mvn 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] Commented: (MSOURCES-21) Allow classes to be bundled with the source code

2007-10-27 Thread Tom Schneider (JIRA)

[ 
http://jira.codehaus.org/browse/MSOURCES-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111710
 ] 

Tom Schneider commented on MSOURCES-21:
---

For a single project, I think the assembly plugin is an ok solution.  However, 
for a multimodule project were you want to build a jar for each submodule in a 
standard way I don't think that's a good solution.  (At least with whats 
currently available from the assembly plugin)  I did go down that route before 
I created this patch.  I think it may make more sense to create a separate 
plugin that has the behavior that I was looking for.  (It would definitely ease 
the configuration IMO)

Fortunately, I no longer have a need for this functionality.  This was needed 
to mimic the way our old system build source jars, but we've decided to 
strongarm our other projects into fully adopting maven.  So I'm ok with this 
not being implemented.

> Allow classes to be bundled with the source code
> 
>
> Key: MSOURCES-21
> URL: http://jira.codehaus.org/browse/MSOURCES-21
> Project: Maven 2.x Source Plugin
>  Issue Type: New Feature
>Affects Versions: 2.0.3
>Reporter: Tom Schneider
>Priority: Minor
> Attachments: sourceplugin-includeClasses.patch
>
>
> We have the need to bundle the compiled class files with the source code and 
> other resources.  So I created a patch that adds a new configuration point 
> (includeClasses) that when set to true, will bundle not only the source code 
> and resources, but also the generated class files.

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




[jira] Issue Comment Edited: (MSOURCES-21) Allow classes to be bundled with the source code

2007-10-27 Thread Tom Schneider (JIRA)

[ 
http://jira.codehaus.org/browse/MSOURCES-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111710
 ] 

Tom Schneider edited comment on MSOURCES-21 at 10/27/07 8:39 PM:
-

For a single project, I think the assembly plugin is an ok solution.  However, 
for a multimodule project were you want to build a jar for each submodule in a 
standard way I don't think that's a good solution.  (At least with whats 
currently available from the assembly plugin)  I did go down that route before 
I created this patch.  I think it may make more sense to create a separate 
plugin that has the behavior that I was looking for.  (It would definitely ease 
the configuration IMO)

Fortunately, I no longer have a need for this functionality.  This was needed 
to mimic the way our old system built source jars, but we've decided to 
strongarm our other projects into fully adopting maven.  So I'm ok with this 
not being implemented.


 was:
For a single project, I think the assembly plugin is an ok solution.  However, 
for a multimodule project were you want to build a jar for each submodule in a 
standard way I don't think that's a good solution.  (At least with whats 
currently available from the assembly plugin)  I did go down that route before 
I created this patch.  I think it may make more sense to create a separate 
plugin that has the behavior that I was looking for.  (It would definitely ease 
the configuration IMO)

Fortunately, I no longer have a need for this functionality.  This was needed 
to mimic the way our old system build source jars, but we've decided to 
strongarm our other projects into fully adopting maven.  So I'm ok with this 
not being implemented.

> Allow classes to be bundled with the source code
> 
>
> Key: MSOURCES-21
> URL: http://jira.codehaus.org/browse/MSOURCES-21
> Project: Maven 2.x Source Plugin
>  Issue Type: New Feature
>Affects Versions: 2.0.3
>Reporter: Tom Schneider
>Priority: Minor
> Attachments: sourceplugin-includeClasses.patch
>
>
> We have the need to bundle the compiled class files with the source code and 
> other resources.  So I created a patch that adds a new configuration point 
> (includeClasses) that when set to true, will bundle not only the source code 
> and resources, but also the generated class files.

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




[jira] Closed: (MSOURCES-21) Allow classes to be bundled with the source code

2007-10-27 Thread Tom Schneider (JIRA)

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

Tom Schneider closed MSOURCES-21.
-

Resolution: Won't Fix

Not needed anymore and the included patch has phase dependency issues.

> Allow classes to be bundled with the source code
> 
>
> Key: MSOURCES-21
> URL: http://jira.codehaus.org/browse/MSOURCES-21
> Project: Maven 2.x Source Plugin
>  Issue Type: New Feature
>Affects Versions: 2.0.3
>Reporter: Tom Schneider
>Priority: Minor
> Attachments: sourceplugin-includeClasses.patch
>
>
> We have the need to bundle the compiled class files with the source code and 
> other resources.  So I created a patch that adds a new configuration point 
> (includeClasses) that when set to true, will bundle not only the source code 
> and resources, but also the generated class files.

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




[jira] Commented: (MEV-550) Missing castor version or incorrect groovy/openejb dependencies

2007-10-27 Thread Carlos Sanchez (JIRA)

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

Carlos Sanchez commented on MEV-550:


you can exclude the missing dep using 

> Missing castor version or incorrect groovy/openejb dependencies
> ---
>
> Key: MEV-550
> URL: http://jira.codehaus.org/browse/MEV-550
> Project: Maven Evangelism
>  Issue Type: Bug
>  Components: Dependencies
>Reporter: Nicolas Kyriazopoulos-Panagiotopoulos
>
> We have a problem of dependencies:
> [INFO]  Path to dependency: 
> [INFO]1) [OUR PROJECT]
> [INFO]2) groovy:groovy:jar:1.0
> [INFO]3) openejb:openejb-loader:jar:1.0
> [INFO]4) openejb:openejb-core:jar:1.0
> [INFO]5) castor:castor:jar:0.9.9.0-pre
> The problem is new (we are using groovy for almost a year) . It seems that 
> someone very recently erased this version of the castor jar and grovy cannot 
> work without it (unless the problem is caused by newly changed poms). Finding 
> this particular version of castor on the web seems very difficult.
> This is VERY URGENT: there is  no newer stable version of groovy so we have 
> no alternative, and the problem makes new application deployments impossible 
> (unless we do kung fu with the downloaded poms to refer to other versions, 
> which is impractical and dangerous).
> Thanks in advance!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-92) setting from $M2_HOME/conf/settings.xml not respected

2007-10-27 Thread Richard Ziegler (JIRA)
 setting from $M2_HOME/conf/settings.xml not respected
---

 Key: MANTTASKS-92
 URL: http://jira.codehaus.org/browse/MANTTASKS-92
 Project: Maven 2.x Ant Tasks
  Issue Type: Bug
  Components: dependencies task
Affects Versions: 2.0.7
Reporter: Richard Ziegler


|| $M2_HOME/conf/settings.xml || build.xml ||
| {code:xml}

 c:/.m2repo
...

{code} | {code:xml}


  

   ...
 {code}|

The default localRepository location is used despite having  
set in the site settings.xml
The same is true when set in $ANT_HOME/etc/settings.xml.  I know this because 
when I invoke my ant target, I see ~/.m2/repository get created, when it 
shouldn't.

However, when  is specified in ~/.m2/settings.xml or 
~/.ant/settings.xml, it works.  Unfortunatly this is not an option as I need to 
configure this at the site installation.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-93) variables not interpolated while reading settings.xml

2007-10-27 Thread Richard Ziegler (JIRA)
variables not interpolated while reading settings.xml 
--

 Key: MANTTASKS-93
 URL: http://jira.codehaus.org/browse/MANTTASKS-93
 Project: Maven 2.x Ant Tasks
  Issue Type: Bug
Affects Versions: 2.0.7
Reporter: Richard Ziegler


I suspect that variables are not interpolated while reading settings.xml.

For instance, I have set the environment variable REPO_DIR=c:/.m2repo.  
However, my  setting is not respected if i use a 
$\{env.variable\} for the localRepository.  I also tried adding 
-DREPO_DIR=c:/.m2repo to ANT_OPTS and using $\{variable\}, but still no luck.

I was only able to test this in ~/.m2/settings.xml , and ~/.ant/settings.xml, 
because of MANTTASKS-92

{code:xml|title=~/.m2/settings.xml}


c:/.m2repo





{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