date:20080310


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

Lukas Theussl closed DOXIA-74.
--

  Assignee: Lukas Theussl
Resolution: Won't Fix

Arnaud expressed privately that he doesn't want to include this in doxia 
anymore.

 Added muse format to doxia-core
 ---

 Key: DOXIA-74
 URL: http://jira.codehaus.org/browse/DOXIA-74
 Project: Maven Doxia
  Issue Type: New Feature
  Components: Core
Affects Versions: 1.0-alpha-8
Reporter: Arnaud Bailly
Assignee: Lukas Theussl
Priority: Minor
 Attachments: patch-doxia-1.0-alpha-8, patch-doxia-1.0-alpha-8-1.0-rc3


 As a workaround to DOXIA-68 bug, I have m\ade a patch to 
 doxia-core-1.0-alpha-8 that include necessary code for generating maven sites 
 from muse syntax and add a dependency to muse-parser from doxia-core pom.xml. 
 This patch may be useful for people who wish to write their documentation 
 using Emacs muse mode.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (DOXIA-203) Add support for level 6 sections and generalize Sink API for sections


[ 
http://jira.codehaus.org/browse/DOXIA-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126712
 ] 

Lukas Theussl commented on DOXIA-203:
-

There is an issue (don't know if it's an inconsistency) with the xhtml-based 
parsers and sinks: eg sectionTitle1() in XhtmlBaseSink emits a h2 tag, 
sectionTitle2() a h3 etc, sectionTitle5() emits a h6 but there is no method 
that emits a h1.

 Add support for level 6 sections and generalize Sink API for sections
 -

 Key: DOXIA-203
 URL: http://jira.codehaus.org/browse/DOXIA-203
 Project: Maven Doxia
  Issue Type: Improvement
  Components: Sink API
Affects Versions: 1.0-alpha-10
Reporter: Vincent Massol

 XWiki supports 6 levels (see 
 http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax) and thus I cannot 
 write a valid parser if the Sink API doesn't support a level 6.
 I'd even suggest to unify all sink method for sections into a single method 
 with a level parameter passed instead of having sectionTitle1(), etc.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (DOXIA-206) Add new standard parameters to link sink API


[ 
http://jira.codehaus.org/browse/DOXIA-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126715
 ] 

Lukas Theussl commented on DOXIA-206:
-

query string is html specific, so it shouldn't go into the sink api. Anchors 
are already supported as part of the link and the rest should be covered by 
DOXIA-204. Ok to close?

 Add new standard parameters to link sink API
 

 Key: DOXIA-206
 URL: http://jira.codehaus.org/browse/DOXIA-206
 Project: Maven Doxia
  Issue Type: Improvement
  Components: Sink API
Affects Versions: 1.0-alpha-10
Reporter: Vincent Massol

 For example XWik supports the following parameters:
 http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax#HLinks
 Here are some that could be added as standard parameters:
 * query string
 * anchor
 * interwiki link (maybe)
 Other parameters are specific to XWiki (space, subwiki, page name, etc), and 
 thus we should also have a generic way of adding parameters, see DOXIA-204

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (DOXIA-205) Add new standard parameters to figure sink API


[ 
http://jira.codehaus.org/browse/DOXIA-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126716
 ] 

Lukas Theussl commented on DOXIA-205:
-

The first 4 (and more) are now supported with DOXIA-204, the image as a link 
can be done by sandwiching the figure between link()/link_() events. Ok to 
close?

 Add new standard parameters to figure sink API 
 ---

 Key: DOXIA-205
 URL: http://jira.codehaus.org/browse/DOXIA-205
 Project: Maven Doxia
  Issue Type: Improvement
  Components: Sink API
Affects Versions: 1.0-alpha-10
Reporter: Vincent Massol

 For example XWik supports the following parameters:
 http://code.xwiki.org/xwiki/bin/view/Macros/ImageMacro
 Here are some that could be added as standard parameters:
 * width
 * height
 * vertical alignment
 * horizontal alignment
 * whether the figure should be a link
 Other parameters are specific to XWiki and thus we should also have a generic 
 way of adding parameters, see DOXIA-204

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-206) Add new standard parameters to link sink API


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

Lukas Theussl closed DOXIA-206.
---

 Assignee: Lukas Theussl
   Resolution: Fixed
Fix Version/s: 1.0-beta-1

 Add new standard parameters to link sink API
 

 Key: DOXIA-206
 URL: http://jira.codehaus.org/browse/DOXIA-206
 Project: Maven Doxia
  Issue Type: Improvement
  Components: Sink API
Affects Versions: 1.0-alpha-10
Reporter: Vincent Massol
Assignee: Lukas Theussl
 Fix For: 1.0-beta-1


 For example XWik supports the following parameters:
 http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax#HLinks
 Here are some that could be added as standard parameters:
 * query string
 * anchor
 * interwiki link (maybe)
 Other parameters are specific to XWiki (space, subwiki, page name, etc), and 
 thus we should also have a generic way of adding parameters, see DOXIA-204

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-205) Add new standard parameters to figure sink API


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

Lukas Theussl closed DOXIA-205.
---

 Assignee: Lukas Theussl
   Resolution: Fixed
Fix Version/s: 1.0-beta-1

 Add new standard parameters to figure sink API 
 ---

 Key: DOXIA-205
 URL: http://jira.codehaus.org/browse/DOXIA-205
 Project: Maven Doxia
  Issue Type: Improvement
  Components: Sink API
Affects Versions: 1.0-alpha-10
Reporter: Vincent Massol
Assignee: Lukas Theussl
 Fix For: 1.0-beta-1


 For example XWik supports the following parameters:
 http://code.xwiki.org/xwiki/bin/view/Macros/ImageMacro
 Here are some that could be added as standard parameters:
 * width
 * height
 * vertical alignment
 * horizontal alignment
 * whether the figure should be a link
 Other parameters are specific to XWiki and thus we should also have a generic 
 way of adding parameters, see DOXIA-204

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2433) Maven looks for snapshots in offline mode

2008-03-10 Thread Paul Benedict (JIRA)


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

Paul Benedict commented on MNG-2433:


Do you not have 2.2-SNAPSHOT already present on your system? I imagine that if 
it isn't there the first time, it cannot possibly build with a plugin that's 
absent. That is different than trying to update a plugin that already is 
installed.

 Maven looks for snapshots in offline mode
 -

 Key: MNG-2433
 URL: http://jira.codehaus.org/browse/MNG-2433
 Project: Maven 2
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 2.0.5
Reporter: Carsten Ziegeler
Assignee: Jason van Zyl
Priority: Critical
 Fix For: 2.0.6


 It seems that sometimes Maven2 is looking for snapshots in offline mode (this 
 happens for example in the Cocoon project). here is an output that might help:
 :\dev\workspace\cocoon-2.2\core\cocoon-webappmvn -o -Dmaven.test.skip=true 
 coc
 oon:deploy
 [INFO]
 NOTE: Maven is executing in offline mode. Any artifacts not already in your 
 loca
 l
 repository will be inaccessible.
 [INFO] Scanning for projects...
 [INFO] Searching repository for plugin with prefix: 'cocoon'.
 [INFO] org.apache.maven.plugins: checking for updates from snapshots
 [INFO] org.apache.maven.plugins: checking for updates from mortbay-repo
 [INFO] org.codehaus.mojo: checking for updates from snapshots
 [INFO] org.codehaus.mojo: checking for updates from mortbay-repo
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from snapshots
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from mortbay-repo
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from central
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from apache.snapshot
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from apache-cvs
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from apache.snapshots
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from snapshots
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from mortbay-repo
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from central
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from apache.snapshot
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from apache-cvs
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from apache.snapshots
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from snapshots
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from mortbay-repo
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from central
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from apache.snapshot
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from apache-cvs
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from apache.snapshots
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from s
 napshots
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from m
 ortbay-repo
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from c
 entral
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from a
 pache.snapshot
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from a
 pache-cvs
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from a
 pache.snapshots

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MEAR-82) From version 2.3 on, resources are not always copied to the EAR structure

2008-03-10 Thread Torsten Reinhard (JIRA)


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

Torsten Reinhard commented on MEAR-82:
--

I just wondered, why I was missing resources in my ear, too.
Have you tried to configure 
resourcesDir${project.build.outputDirectory}/resourcesDir ?

Don´t know, why this is not a default...

 From version 2.3 on, resources are not always copied to the EAR structure
 -

 Key: MEAR-82
 URL: http://jira.codehaus.org/browse/MEAR-82
 Project: Maven 2.x Ear Plugin
  Issue Type: Bug
Affects Versions: 2.3, 2.3.1
Reporter: Emmanuel
 Attachments: dummyProject.zip


 I had a EAR project that copied resources from a higher-level folder (see  
 ../  below). It worked perfectly with maven-ear-plugin version 2.2
 With versions 2.3 and 2.3.1, it seems to have stopped working that way. 
 However, I see nowhere an indication on whether it is a new feature / 
 impovement or a bug. Or is it that I'm not using it the right way? But if so, 
 how do you explain the change of behaviour between versions 2.2 and 2.3 ?
 Here above is a part of a Ear POM that shows the problem.
 And attached is a complete simple project to help reproduce the problem.
 packagingear/packaging
 [...]
 resources
   resource
   directory../myResources/directory
   targetPathtargResources/targetPath
   includes
   include*.properties/include
   /includes
   /resource
 /resources
 plugins
   plugin
   artifactIdmaven-ear-plugin/artifactId
   !-- From Version 2.3 on, resources are no longer 
 copied properly. Bug or evolution? --
   !--version2.3.1/version--
   version2.2/version
   /plugin
   /plugins
 [...]
 Hope this helps make a better (world?) 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: (MNG-2744) checksum comparison should be case-insensitive


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

Brian Fox commented on MNG-2744:


Ben, we need tests for these things so it's not just a one liner. A unit test 
at minimum, an IT test in addition would be better.

 checksum comparison should be case-insensitive
 --

 Key: MNG-2744
 URL: http://jira.codehaus.org/browse/MNG-2744
 Project: Maven 2
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 2.0.4
Reporter: Ian Springer
 Fix For: 2.0.9

 Attachments: case-insensitive-checksums-2.0.x.patch, 
 case-insensitive-checksums-2.1.x.patch


 Validation of MD5 and SHA1 checksums should be case-insensitive (since the 
 individual characters represent hexadecimal digits). For example:
 [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 
 '9657ed010cea89caa1e35ae326dfccf28ea007f5'; remote
 = '9657ED010CEA89CAA1E35AE326DFCCF28EA007F5' - RETRYING

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

[jira] Reopened: (MNG-3452) StackOverflowError building Apache ServiceMix 3


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

John Casey reopened MNG-3452:
-

  Assignee: John Casey  (was: Brett Porter)

I don't know that these are duplicates. The stack traces are very different.

 StackOverflowError building Apache ServiceMix 3
 ---

 Key: MNG-3452
 URL: http://jira.codehaus.org/browse/MNG-3452
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Eugene Kuleshov
Assignee: John Casey
 Attachments: clipboard.txt


 Maven 2.1-SNAPSHOT fail on building ServiceMix projects. Steps to reproduce:
 * Checkout https://svn.apache.org/repos/asf/servicemix/smx3/trunk 
 * Run mvn install
 This works with maven 2.0.8 but fails with the following exception with 
 recent 2.1-SNAPSHOT

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-3452) StackOverflowError building Apache ServiceMix 3


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

jdcasey edited comment on MNG-3452 at 3/10/08 12:23 PM:
---

I don't know that this is a duplicate of MNG-3391, actually. The stack traces 
are very different. At the very least, it's worth investigating to verify that 
they really are caused by the same problem.

  was (Author: jdcasey):
I don't know that these are duplicates. The stack traces are very different.
  
 StackOverflowError building Apache ServiceMix 3
 ---

 Key: MNG-3452
 URL: http://jira.codehaus.org/browse/MNG-3452
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Eugene Kuleshov
Assignee: John Casey
 Attachments: clipboard.txt


 Maven 2.1-SNAPSHOT fail on building ServiceMix projects. Steps to reproduce:
 * Checkout https://svn.apache.org/repos/asf/servicemix/smx3/trunk 
 * Run mvn install
 This works with maven 2.0.8 but fails with the following exception with 
 recent 2.1-SNAPSHOT

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-3415) Transfer errors cause junk metadata in the local repo

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

John Casey closed MNG-3415.
---

Resolution: Fixed

This issue is fixed. I applied Brett's patch (thanks for the heavy lifting
here, Brett), and added integration tests to check writing the metadata on
ResourceNotFoundException, but not on TransferFailedException.

NOTE: This integration test required a little extra functionality in the
abstract parent test class, to allow conditional use of different files for the
updateInterval calculation (we're making sure these files are not modified on
successive builds when ResourceNotFoundException happens).

The integration test should be fairly well-documented, so have a look.

Transfer errors cause junk metadata in the local repo
-

Key: MNG-3415
URL: http://jira.codehaus.org/browse/MNG-3415
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.0.8
Reporter: Brian Fox
Assignee: John Casey
Fix For: 2.0.9

Attachments: MNG-3415.diff

I see this all the time and I swear there was an issue for it, but now I
can't find it. Sometimes there is metadata in the repo, usually after an
offline build or a build where something went wrong downloading artifacts.
Maven will apparently decide based on the metadata that the file can never be
found and will simply fail on a missing artifact. You can tell this has
happened because no attempt has actually been made to download the artifact
from a repository. Subsequent clearing of (portions) the localrepo fixes the
issue. This is terribly confusing to new users...and annoying to everyone.

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


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

Work on MNG-2861 started by Brian Fox.

 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
Assignee: Brian Fox
 Fix For: 2.0.9

 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)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
   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)

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


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

Brian Fox commented on MNG-2861:


I was not able to reproduce using the file based repo, but when I added them to 
an http repo, i can reproduce in 2.0.9-SNAPSHOT

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

 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)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
   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)

[jira] Commented: (MNG-3431) Pom Extensions not supported for Toolchains

2008-03-10 Thread Shane Isbell (JIRA)


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

Shane Isbell commented on MNG-3431:
---

I tried the toolchain in 2.1 and it looks as though the extensions work in that 
version but then I get:

java.lang.ClassCastException: 
org.apache.maven.dotnet.extensions.toolchain.DotnetToolchain cannot be cast to 
org.apache.maven.dotnet.extensions.toolchain.Dotnet
Toolchainat 
org.apache.maven.dotnet.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:127)

I get the same exception in 2.0.9 if I put my jar containing the dotnet 
toolchain directly in the maven/lib directory.

 Pom Extensions not supported for Toolchains
 ---

 Key: MNG-3431
 URL: http://jira.codehaus.org/browse/MNG-3431
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.0.9
Reporter: Shane Isbell
Priority: Minor

 When I add a pom extension referening a jar containing an implementation of a 
 toolchain and toolchain factory, the toolchain plugin does not pick up my 
 extensions. I get an exception on mvn install:
 Caused by: java.lang.ClassNotFoundException: 
 org.apache.maven.dotnet.extensions.toolchain.DotnetToolchainFactory

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MANTRUN-55) Review Plugin Documentation


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

Dennis Lundberg closed MANTRUN-55.
--

   Resolution: Fixed
Fix Version/s: 1.2

 Review Plugin Documentation
 ---

 Key: MANTRUN-55
 URL: http://jira.codehaus.org/browse/MANTRUN-55
 Project: Maven 2.x Antrun Plugin
  Issue Type: Task
Reporter: Allan Ramirez
Assignee: Allan Ramirez
 Fix For: 1.2

 Attachments: MANTRUN-55-maven-antrun-plugin-2.patch, 
 MANTRUN-55-maven-antrun-plugin-3.patch, MANTRUN-55-maven-antrun-plugin.patch

   Original Estimate: 12 hours
  Time Spent: 2 hours
  Remaining Estimate: 10 hours



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-45) Ability to create an ear/war/zip from site


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

Dennis Lundberg closed MSITE-45.


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

 Ability to create an ear/war/zip from site
 --

 Key: MSITE-45
 URL: http://jira.codehaus.org/browse/MSITE-45
 Project: Maven 2.x Site Plugin
  Issue Type: New Feature
Affects Versions: 2.0-beta-5
Reporter: Brett Porter
Assignee: Dennis Lundberg
 Fix For: 2.0-beta-6

 Attachments: MSITE-45-maven-site-plugin.patch, patch.txt


 I think they should be standalone goals, like in m1
 site:ear - create ear
 site:war - create war
 site:zip - create zip
 I think this one might be a lower priority. I will postpone it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MANTRUN-51) Can't find plugin dependency in multiproject

2008-03-10 Thread gotama (JIRA)


[ 
http://jira.codehaus.org/browse/MANTRUN-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126760
 ] 

gotama commented on MANTRUN-51:
---

Steinar - THANK YOU for the workaround! OMG I was going nuts for 2 days trying 
to figure this out. I figured it was a bug. I was simply trying to use Ant to 
scp some files and discovered the same - that on the module itself, it works 
but when exec from a parent POM on a multi-module project, the 'scp' fails. I 
added:

dependencies
dependency
groupIdant/groupId
artifactIdant-optional/artifactId
version1.5.3-1/version
/dependency
dependency
groupIdant/groupId
artifactIdant-jsch/artifactId
version1.6.5/version
/dependency
/dependencies

to the ant plugin for the first executing module in the multi-module project 
and when the last module was exec'd w/ the 'scp' command, all worked ok.

OK, so this bug is 2 years old and still causing pain.  Whats the status on 
getting this fixed? Any interest? Thanks.




 Can't find plugin dependency in multiproject
 

 Key: MANTRUN-51
 URL: http://jira.codehaus.org/browse/MANTRUN-51
 Project: Maven 2.x Antrun Plugin
  Issue Type: Bug
Affects Versions: 1.0, 1.1
 Environment: maven 2.0.4, antrun 1.0  1.1, jdk 1.5.0_06, windows xp
Reporter: Fredrik Vraalsen

 I'm using antrun in my project to create an IzPack installation.  The plugin 
 configuration is below.  
 When maven is run from the top-level project, the ant taskdef fails because 
 it cannot find the IzPackTask class.  However, when I run maven from the 
 subproject itself, it works fine.  Not sure if this is related to 
 http://jira.codehaus.org/browse/MANTRUN-49.  The error message from maven is 
 at the bottom.
 {noformat}
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-antrun-plugin/artifactId
   executions
   execution
   phasepackage/phase
   configuration
   tasks
   taskdef name=izpack 
 classname=com.izforge.izpack.ant.IzPackTask/
   izpack 
 input=${project.build.directory}/classes/izPack.xml 
 output=${project.build.directory}/CorasTool-${coras.version}-installer.jar 
 basedir=${project.build.directory}/
   /tasks
   /configuration
   goals
   goalrun/goal
   /goals
   /execution
   /executions
   dependencies
   dependency
   groupIdizpack/groupId
   artifactIdstandalone-compiler/artifactId
   version3.8.0/version
   /dependency
   /dependencies
 /plugin
 [INFO] [antrun:run {execution: default}]
 [INFO] Executing tasks
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Error executing ant tasks
 Embedded error: taskdef class com.izforge.izpack.ant.IzPackTask cannot be 
 found
 [INFO] 
 
 [INFO] Trace
 org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant 
 tasks
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
 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)

[jira] Commented: (MNG-3430) Toolchain doesn't match Toolchain extensions

2008-03-10 Thread Milos Kleint (JIRA)


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

Milos Kleint commented on MNG-3430:
---

the factory should use this constructor
protected DefaultToolchain( ToolchainModel model, String type, Logger logger )
for some reason the incomplete
protected DefaultToolchain( ToolchainModel model, Logger logger )
constructor is also present. 

What about I keep both constructors supported and the getType() method does 
this:
return type != null ? type : model.getType();




 Toolchain doesn't match Toolchain extensions
 

 Key: MNG-3430
 URL: http://jira.codehaus.org/browse/MNG-3430
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.0.9
Reporter: Shane Isbell
Assignee: Milos Kleint
Priority: Minor

 Toolchain uses null key within storing toolchains in Maven Session, which 
 causes extensions not to match.
 Specifically, this problem occurs in the 
 DefaultToolchainManager.storeToolchainToBuildContext method.  When storing 
 into context
 context.put( getStorageKey( toolchain.getType() ), toolchain.getModel() );
 toolchain.getType() always returns null. Using toolchain.getModel().getType() 
 will return the correct type and fix the 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: (MNG-3430) Toolchain doesn't match Toolchain extensions

2008-03-10 Thread Milos Kleint (JIRA)


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

Milos Kleint closed MNG-3430.
-

   Resolution: Fixed
Fix Version/s: 2.1-alpha-1
   2.0.x

done:
http://svn.apache.org/viewvc?rev=635690view=rev

 Toolchain doesn't match Toolchain extensions
 

 Key: MNG-3430
 URL: http://jira.codehaus.org/browse/MNG-3430
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.0.9
Reporter: Shane Isbell
Assignee: Milos Kleint
Priority: Minor
 Fix For: 2.0.x, 2.1-alpha-1


 Toolchain uses null key within storing toolchains in Maven Session, which 
 causes extensions not to match.
 Specifically, this problem occurs in the 
 DefaultToolchainManager.storeToolchainToBuildContext method.  When storing 
 into context
 context.put( getStorageKey( toolchain.getType() ), toolchain.getModel() );
 toolchain.getType() always returns null. Using toolchain.getModel().getType() 
 will return the correct type and fix the 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] Commented: (MPIR-77) index mojo does not recognize src/site/apt/index.apt as an override for the generated index.html file.


[ 
http://jira.codehaus.org/browse/MPIR-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126763
 ] 

Dennis Lundberg commented on MPIR-77:
-

Ping!

 index mojo does not recognize src/site/apt/index.apt as an override for the 
 generated index.html file.
 --

 Key: MPIR-77
 URL: http://jira.codehaus.org/browse/MPIR-77
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Bug
Affects Versions: 2.0.1
Reporter: John Casey

 It seems that the only way to override the generated output of the index 
 report is to use the src/site/resources/index.html file...the 
 src/site/apt/index.apt file does not work. It should be possible to create 
 any file matching: src/site/(suffix)/index.(suffix) and have it replace the 
 output of this report, or at least displace it to an about.html file or 
 something similar.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-3430) Toolchain doesn't match Toolchain extensions

2008-03-10 Thread Paul Benedict (JIRA)


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

Paul Benedict commented on MNG-3430:


Affects version is 2.0.9 -- should Fix Version also be 2.0.9 not 2.0.x?

 Toolchain doesn't match Toolchain extensions
 

 Key: MNG-3430
 URL: http://jira.codehaus.org/browse/MNG-3430
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.0.9
Reporter: Shane Isbell
Assignee: Milos Kleint
Priority: Minor
 Fix For: 2.0.x, 2.1-alpha-1


 Toolchain uses null key within storing toolchains in Maven Session, which 
 causes extensions not to match.
 Specifically, this problem occurs in the 
 DefaultToolchainManager.storeToolchainToBuildContext method.  When storing 
 into context
 context.put( getStorageKey( toolchain.getType() ), toolchain.getModel() );
 toolchain.getType() always returns null. Using toolchain.getModel().getType() 
 will return the correct type and fix the 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: (MONE-23) one:convert kept linksa,b,c/links vs making linkslinka/linklinkb/linklinkc/link/links


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

Dennis Lundberg closed MONE-23.
---

   Resolution: Fixed
Fix Version/s: 1.3

Fixed and a new 1.3-SNAPSHOT has been deployed.

 one:convert kept linksa,b,c/links vs making 
 linkslinka/linklinkb/linklinkc/link/links 
 --

 Key: MONE-23
 URL: http://jira.codehaus.org/browse/MONE-23
 Project: Maven 2.x One Plugin
  Issue Type: Bug
Affects Versions: 1.2
 Environment: Windows
Reporter: Jeff Jensen
Assignee: Dennis Lundberg
Priority: Minor
 Fix For: 1.3


 Workaround is an easy manual adjustment.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-467) NoSuchMethodError UrlUtils.getURL when using JDK3 for testing

2008-03-10 Thread Herve Boutemy (JIRA)


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

Herve Boutemy closed SUREFIRE-467.
--

 Assignee: Herve Boutemy
   Resolution: Fixed
Fix Version/s: 2.5

fixed in r635738

 NoSuchMethodError UrlUtils.getURL when using JDK3 for testing
 -

 Key: SUREFIRE-467
 URL: http://jira.codehaus.org/browse/SUREFIRE-467
 Project: Maven Surefire
  Issue Type: Bug
Affects Versions: 2.4.2
 Environment: Maven 2.0.8
 JDK 1.5.0_11
 JDK 1.3.1_20
Reporter: Antoine Véret
Assignee: Herve Boutemy
 Fix For: 2.5

 Attachments: debug.log


 java.lang.NoSuchMethodError
 at org.apache.maven.surefire.util.UrlUtils.getURL(UrlUtils.java:39)
 at 
 org.apache.maven.surefire.booter.SurefireBooter.createClassLoader(SurefireBooter.java:730)
 Only appears when using JDK3, not JDK4 with the following configuration
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-surefire-plugin/artifactId
 configuration
   jvm${JDK3_HOME}/bin/java/jvm
 /configuration
   /plugin
 See the debug log

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MONE-24) one:convert puts javadoc-plugin in build/plugins vs reporting/plugins

one:convert puts javadoc-plugin in build/plugins vs reporting/plugins
-

 Key: MONE-24
 URL: http://jira.codehaus.org/browse/MONE-24
 Project: Maven 2.x One Plugin
  Issue Type: Bug
Affects Versions: 1.2
Reporter: Jeff Jensen




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MONE-24) one:convert puts javadoc-plugin in build/plugins vs reporting/plugins


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

Dennis Lundberg closed MONE-24.
---

 Assignee: Dennis Lundberg
   Resolution: Fixed
Fix Version/s: 1.3

 one:convert puts javadoc-plugin in build/plugins vs reporting/plugins
 -

 Key: MONE-24
 URL: http://jira.codehaus.org/browse/MONE-24
 Project: Maven 2.x One Plugin
  Issue Type: Bug
Affects Versions: 1.2
Reporter: Jeff Jensen
Assignee: Dennis Lundberg
 Fix For: 1.3




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-3361) Deploying from Leopard, with Svn 1.4.4 has error on automated Svn commit

2008-03-10 Thread Matt Ryall (JIRA)


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

Matt Ryall commented on MNG-3361:
-

This is actually a Leopard issue, but there is a bug in Subversion for tracking 
it here:

http://subversion.tigris.org/issues/show_bug.cgi?id=3059

 Deploying from Leopard, with Svn 1.4.4 has error on automated Svn commit
 

 Key: MNG-3361
 URL: http://jira.codehaus.org/browse/MNG-3361
 Project: Maven 2
  Issue Type: Bug
  Components: Deployment
Affects Versions: 2.0.8
Reporter: Paul Hammant

 [INFO] 
 
 [INFO] BUILD SUCCESSFUL
 [INFO] 
 
 [INFO] Total time: 3 minutes 25 seconds
 [INFO] Finished at: Fri Jan 11 08:49:42 PST 2008
 [INFO] Final Memory: 14M/29M
 [INFO] 
 
 [INFO] Checking in modified POMs...
 [INFO] Executing: svn --non-interactive commit --file 
 /tmp/maven-scm-1359802395.commit --targets /tmp/maven-scm-28211-targets
 [INFO] Working directory: /scm/oss/jremoting/root/trunk
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] Unable to commit files
 Provider message:
 The svn command failed.
 Command output:
 svn: Commit failed (details follow):
 svn: MKACTIVITY of 
 '/jremoting/!svn/act/c136e17a-8ec7-44c4-a326-b2611ec72ffc': authorization 
 failed (https://svn.codehaus.org)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-1323) Plugin extensions (dependencies) not resolved in reactor build


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

Brian Fox commented on MNG-1323:


Piotr, yes, I've scheduled it for 2.0.10 so we will be looking at it soon.

 Plugin extensions (dependencies) not resolved in reactor build
 --

 Key: MNG-1323
 URL: http://jira.codehaus.org/browse/MNG-1323
 Project: Maven 2
  Issue Type: Bug
  Components: Plugins and Lifecycle
Affects Versions: 2.0
Reporter: Kenney Westerhof
 Fix For: 2.0.10

 Attachments: MNG-1323-components-2.0.x.diff, 
 MNG-1323-core-integration-testing-2.diff, 
 MNG-1323-core-integration-testing.diff, 
 MNG-1323-core-integration-tests-3.diff, MNG-1323-core-integration-tests.diff, 
 MNG1323-maven-core-2.1.diff


 I've added a dependency on an Ant Task in 
 project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ 
 and run that anttask using the antrun plugin.
 When run from the project dir itself it runs fine.
 When running from the root of the project tree (reactor build, project one 
 level below root),
 antrun bails out because the taskdef can't be found (not on classpath).
 It looks like the dependency isn't resolved, or not added to the plugins' 
 classrealm.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2744) checksum comparison should be case-insensitive


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

Benjamin Bentmann updated MNG-2744:
---

Attachment: case-insensitive-checksums-2.1.x.patch

Brian, I don't want to question your endeavor to increase test coverage but I 
don't agree that this is a reason to prevent trivial fixes with tiny code 
changes from being applied as soon as possible. I would rather suggest to 
create sub tasks Add test for XYZ for those trivial patches where an 
accompanying is nice to have but not necessary.

Anyway, here's my next try to patch the trunk, was really more than one line 
;-) I's not elegant but shows the failure if unpatched.

 checksum comparison should be case-insensitive
 --

 Key: MNG-2744
 URL: http://jira.codehaus.org/browse/MNG-2744
 Project: Maven 2
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 2.0.4
Reporter: Ian Springer
 Fix For: 2.0.9

 Attachments: case-insensitive-checksums-2.0.x.patch, 
 case-insensitive-checksums-2.1.x.patch, case-insensitive-checksums-2.1.x.patch


 Validation of MD5 and SHA1 checksums should be case-insensitive (since the 
 individual characters represent hexadecimal digits). For example:
 [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 
 '9657ed010cea89caa1e35ae326dfccf28ea007f5'; remote
 = '9657ED010CEA89CAA1E35AE326DFCCF28EA007F5' - RETRYING

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2744) checksum comparison should be case-insensitive


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

bentmann edited comment on MNG-2744 at 3/10/08 7:54 PM:
-

Brian, I don't want to question your endeavor to increase test coverage but I 
don't agree that this is a reason to prevent trivial fixes with tiny code 
changes from being applied as soon as possible. I would rather suggest to 
create sub tasks Add test for XYZ for those trivial patches where an 
accompanying test is nice to have but not necessary.

Anyway, here's my next try to patch the trunk, was really more than one line 
;-) I's not elegant but shows the failure if unpatched.

  was (Author: bentmann):
Brian, I don't want to question your endeavor to increase test coverage but 
I don't agree that this is a reason to prevent trivial fixes with tiny code 
changes from being applied as soon as possible. I would rather suggest to 
create sub tasks Add test for XYZ for those trivial patches where an 
accompanying is nice to have but not necessary.

Anyway, here's my next try to patch the trunk, was really more than one line 
;-) I's not elegant but shows the failure if unpatched.
  
 checksum comparison should be case-insensitive
 --

 Key: MNG-2744
 URL: http://jira.codehaus.org/browse/MNG-2744
 Project: Maven 2
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 2.0.4
Reporter: Ian Springer
 Fix For: 2.0.9

 Attachments: case-insensitive-checksums-2.0.x.patch, 
 case-insensitive-checksums-2.1.x.patch, case-insensitive-checksums-2.1.x.patch


 Validation of MD5 and SHA1 checksums should be case-insensitive (since the 
 individual characters represent hexadecimal digits). For example:
 [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 
 '9657ed010cea89caa1e35ae326dfccf28ea007f5'; remote
 = '9657ED010CEA89CAA1E35AE326DFCCF28EA007F5' - RETRYING

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2744) checksum comparison should be case-insensitive


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

Benjamin Bentmann updated MNG-2744:
---

Attachment: (was: case-insensitive-checksums-2.1.x.patch)

 checksum comparison should be case-insensitive
 --

 Key: MNG-2744
 URL: http://jira.codehaus.org/browse/MNG-2744
 Project: Maven 2
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 2.0.4
Reporter: Ian Springer
 Fix For: 2.0.9

 Attachments: case-insensitive-checksums-2.0.x.patch, 
 case-insensitive-checksums-2.1.x.patch, case-insensitive-checksums-2.1.x.patch


 Validation of MD5 and SHA1 checksums should be case-insensitive (since the 
 individual characters represent hexadecimal digits). For example:
 [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 
 '9657ed010cea89caa1e35ae326dfccf28ea007f5'; remote
 = '9657ED010CEA89CAA1E35AE326DFCCF28EA007F5' - RETRYING

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2744) checksum comparison should be case-insensitive


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

Benjamin Bentmann updated MNG-2744:
---

Attachment: case-insensitive-checksums-2.1.x.patch

 checksum comparison should be case-insensitive
 --

 Key: MNG-2744
 URL: http://jira.codehaus.org/browse/MNG-2744
 Project: Maven 2
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 2.0.4
Reporter: Ian Springer
 Fix For: 2.0.9

 Attachments: case-insensitive-checksums-2.0.x.patch, 
 case-insensitive-checksums-2.1.x.patch, case-insensitive-checksums-2.1.x.patch


 Validation of MD5 and SHA1 checksums should be case-insensitive (since the 
 individual characters represent hexadecimal digits). For example:
 [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 
 '9657ed010cea89caa1e35ae326dfccf28ea007f5'; remote
 = '9657ED010CEA89CAA1E35AE326DFCCF28EA007F5' - RETRYING

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

[jira] Created: (MNG-3454) processing a relocation erases requested version range

processing a relocation erases requested version range
--

 Key: MNG-3454
 URL: http://jira.codehaus.org/browse/MNG-3454
 Project: Maven 2
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 2.0.8, 2.0.7, 2.0.6, 2.0.5
Reporter: Brian Fox
Priority: Minor


While fixing MNG-2861, I came across a weird scenario where the contents of the 
relocation can affect what happens. In 2861, the relocation did not specify a 
version, only a group id. However, if a version is specified, in 
MavenMetadataSource: 164 the versionRange is reset to the contents of the 
relocation.getVersion(). This effectively tosses out the requested range 
information. We only get here after selecting the version that has been 
relocated, but now we have a recommended version, which can cause a different 
version to be selected. See the two sample projects in MNG-2861 to see how the 
handling is different. (brett's version has the version in the relocation and 
thus expresses the behavior described here)

The fix is simple, change the line to:
if ( relocation.getVersion() != null )
{
//we don't want to blast the versionRange 
information
artifact.selectVersion( relocation.getVersion() );
}

however, I'm not certain what the ramifications of this are. The potential 
exists for having selected a version that no longer matches the requested 
version range. Say the version range was [1.0,2.0] and 2.0 was relocated to 
3.0. The fix to 2861 involves reloading the available versions from the 
relocated artifact. This means that there is no not an artifact to match 
1.0-2.0 and who knows what's going to happen.

I'm choosing to document this and not fix it for now due to the risk of 
instability. A search of open issues didn't result in anyone experiencing 
trouble with 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] Updated: (MNG-3454) processing a relocation erases requested version range

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

Brian Fox updated MNG-3454:
---

Attachment: MNG-2861_broken.zip

processing a relocation erases requested version range
--

Key: MNG-3454
URL: http://jira.codehaus.org/browse/MNG-3454
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.0.5, 2.0.6, 2.0.7, 2.0.8
Reporter: Brian Fox
Priority: Minor
Attachments: MNG-2861.tar.gz, MNG-2861_broken.zip

While fixing MNG-2861, I came across a weird scenario where the contents of
the relocation can affect what happens. In 2861, the relocation did not
specify a version, only a group id. However, if a version is specified, in
MavenMetadataSource: 164 the versionRange is reset to the contents of the
relocation.getVersion(). This effectively tosses out the requested range
information. We only get here after selecting the version that has been
relocated, but now we have a recommended version, which can cause a different
version to be selected. See the two sample projects in MNG-2861 to see how
the handling is different. (brett's version has the version in the relocation
and thus expresses the behavior described here)
The fix is simple, change the line to:
if ( relocation.getVersion() != null )
{
//we don't want to blast the versionRange
information
artifact.selectVersion( relocation.getVersion() );
}
however, I'm not certain what the ramifications of this are. The potential
exists for having selected a version that no longer matches the requested
version range. Say the version range was [1.0,2.0] and 2.0 was relocated to
3.0. The fix to 2861 involves reloading the available versions from the
relocated artifact. This means that there is no not an artifact to match
1.0-2.0 and who knows what's going to happen.
I'm choosing to document this and not fix it for now due to the risk of
instability. A search of open issues didn't result in anyone experiencing
trouble with this.

[jira] Updated: (MNG-3454) processing a relocation erases requested version range

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

Brian Fox updated MNG-3454:
---

Attachment: MNG-2861.tar.gz

processing a relocation erases requested version range
--

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


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

Brian Fox closed MNG-2861.
--

Resolution: Fixed

fixed + IT

 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
Assignee: Brian Fox
 Fix For: 2.0.9

 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)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
   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

[jira] Updated: (MNG-3284) Cached plugins are used, even when the specifically declared


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

Brian Fox updated MNG-3284:
---

Fix Version/s: 2.0.9

Identified as blocker to upgrading. Lets try to include this (even has an IT)

 Cached plugins are used, even when the specifically declared 
 -

 Key: MNG-3284
 URL: http://jira.codehaus.org/browse/MNG-3284
 Project: Maven 2
  Issue Type: Bug
  Components: Dependencies, Plugins and Lifecycle
Affects Versions: 2.0.7
Reporter: Nigel Magnay
Priority: Critical
 Fix For: 2.0.9

 Attachments: 
 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 
 maven-bug-2.tar, mng3284-usingCachedPlugins.tar, pluginbug.tar


 In the attached project, you can build module A, then build module B, but the 
 top level aggregator project will fail at B.
 The reason this happens is that maven seems to cache plugins. When B is built 
 in isolation, all things are fine - but when built in aggregation, one of the 
 plugins that it uses has already been instantiated, and so it uses that one. 
 This is incorrect, since the declared version is different in B, and is 
 relying on functionality not present in the version declared in A.
 I have seen similar behaviour when a plugin relies on other plugins to get 
 work done - all of a sudden a build mysteriously stops working, because of a 
 completely unrelated plugin.
 This is pretty painful because
 - it's possible to get into a 'no solution', where one project relies on one 
 behaviour so can't upgrade, and one project relies on new behaviour, so can't 
 downgrade.
 - you get builds that work OK in isolation, but not in their project. This is 
 bad. Also builds tied together in bigger aggregator projects can fail in 
 mysterious ways (mysterious because the user /has/ specified the plugin 
 version, and maven has ignored them, or it's a plugin dependency that got 
 there first)
 - subtle build ordering changes can cause new failures (the example has B 
 depend on A - but the bug might only manifest itself in certain build orders 
 that change even when B and A don't).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-3284) Cached plugins are used, even when the specifically declared


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

Brian Fox commented on MNG-3284:


any chance you can make that patch against svn?

 Cached plugins are used, even when the specifically declared 
 -

 Key: MNG-3284
 URL: http://jira.codehaus.org/browse/MNG-3284
 Project: Maven 2
  Issue Type: Bug
  Components: Dependencies, Plugins and Lifecycle
Affects Versions: 2.0.7
Reporter: Nigel Magnay
Priority: Critical
 Fix For: 2.0.9

 Attachments: 
 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 
 maven-bug-2.tar, mng3284-usingCachedPlugins.tar, pluginbug.tar


 In the attached project, you can build module A, then build module B, but the 
 top level aggregator project will fail at B.
 The reason this happens is that maven seems to cache plugins. When B is built 
 in isolation, all things are fine - but when built in aggregation, one of the 
 plugins that it uses has already been instantiated, and so it uses that one. 
 This is incorrect, since the declared version is different in B, and is 
 relying on functionality not present in the version declared in A.
 I have seen similar behaviour when a plugin relies on other plugins to get 
 work done - all of a sudden a build mysteriously stops working, because of a 
 completely unrelated plugin.
 This is pretty painful because
 - it's possible to get into a 'no solution', where one project relies on one 
 behaviour so can't upgrade, and one project relies on new behaviour, so can't 
 downgrade.
 - you get builds that work OK in isolation, but not in their project. This is 
 bad. Also builds tied together in bigger aggregator projects can fail in 
 mysterious ways (mysterious because the user /has/ specified the plugin 
 version, and maven has ignored them, or it's a plugin dependency that got 
 there first)
 - subtle build ordering changes can cause new failures (the example has B 
 depend on A - but the bug might only manifest itself in certain build orders 
 that change even when B and A don't).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-1959) Please sync org.mockftpserver repository with ibiblio

2008-03-10 Thread Chris Mair (JIRA)

Please sync org.mockftpserver repository with ibiblio
-

 Key: MAVENUPLOAD-1959
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1959
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Chris Mair


Please sync the org.mockftpserver repository with the central repository.

Comma-Delimited Form:
org.mockftpserver,[EMAIL 
PROTECTED]/home/groups/m/mo/mockftpserver/htdocs/m2repo,rsync_ssh,Chris 
Mair, [EMAIL PROTECTED] ,,

Proof of Ownership of the mockftpserver.org domain
http://reports.internic.net/cgi/whois?whois_nic=mockftpserver.orgtype=domain
Note name=Chris Mair and [EMAIL PROTECTED]

AND SourceForge project page showing Chris Mair as the project owner:
http://sourceforge.net/projects/mockftpserver

Follow the chrismair Project Admins link and note that the name and email are 
the same.

Thanks. - Chris Mair

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-3452) StackOverflowError building Apache ServiceMix 3


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

John Casey closed MNG-3452.
---

Resolution: Fixed

 StackOverflowError building Apache ServiceMix 3
 ---

 Key: MNG-3452
 URL: http://jira.codehaus.org/browse/MNG-3452
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Eugene Kuleshov
Assignee: John Casey
 Attachments: clipboard.txt


 Maven 2.1-SNAPSHOT fail on building ServiceMix projects. Steps to reproduce:
 * Checkout https://svn.apache.org/repos/asf/servicemix/smx3/trunk 
 * Run mvn install
 This works with maven 2.0.8 but fails with the following exception with 
 recent 2.1-SNAPSHOT

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-3391) StackOverflowError in DefaultMavenProjectBuilder