[jira] Commented: (MPTEST-75) Final test failure leads to strange formatted error

[Andy Jefferson (JIRA)]

[ 
http://jira.codehaus.org/browse/MPTEST-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_101543
 ] 

Andy Jefferson commented on MPTEST-75:
--

Ahh, ok. So what should I be using to get the same behaviour as Maven 1.0.2 ? 
(because my settings are the same as I used there). I want it to plough on 
regardless.

> Final test failure leads to strange formatted error
> ---
>
> Key: MPTEST-75
> URL: http://jira.codehaus.org/browse/MPTEST-75
> Project: Maven 1.x Test Plugin
>  Issue Type: Bug
>Affects Versions: 1.8.2
>Reporter: Andy Jefferson
>
> When running JUnit tests with Maven 1.1.0 on Linux if the final test fails I 
> get non-standard output. To attempt to explain better ...
> [junit] Running org.jpox.tests.NondurableIdTest
> [junit] Tests run: 3, Failures: 2, Errors: 0, Time elapsed: 5.947 sec
> [junit] [ERROR] Test org.jpox.tests.NondurableIdTest FAILED
> [junit] Running org.jpox.tests.ObjectFCOTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.471 sec
> [junit] Running org.jpox.tests.PersistenceManagerFactoryImplTest
> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 25.693 sec
> [junit] Running org.jpox.tests.PersistenceManagerImplTest
> [junit] Tests run: 49, Failures: 1, Errors: 0, Time elapsed: 8.589 sec
> [junit] [ERROR] Test org.jpox.tests.PersistenceManagerImplTest FAILED
> [junit] Running org.jpox.tests.SequenceTest
> [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.072 sec
> [junit] Running org.jpox.tests.SerializationTest
> [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 3.607 sec
> [junit] Running org.jpox.tests.TransactionTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.142 sec
> [junit] Running org.jpox.tests.TypeManagerTest
> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.016 sec
> [junit] Running org.jpox.tests.TypeStorageTest
> [junit] Tests run: 11, Failures: 0, Errors: 0, Time elapsed: 11.486 sec
> [junit] Running org.jpox.tests.TypesMappingTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.016 sec
> [junit] Running org.jpox.tests.ViewTest
> [junit] Tests run: 5, Failures: 0, Errors: 1, Time elapsed: 2.33 sec
> ---
> >> Unable to obtain goal [test:test]
> >> Test org.jpox.tests.ViewTest failed
> ---
> BUILD FAILED
> So normally when a test fails you get the line [ERROR] but when its the final 
> test you dont get that and get the ugly "Unable to obtain goal" etc. Why is 
> it not displaying the final test correctly?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MPTEST-75) Final test failure leads to strange formatted error

[Lukas Theussl (JIRA)]

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

Lukas Theussl closed MPTEST-75.
---

  Assignee: Lukas Theussl
Resolution: Won't Fix

maven.test.error.ignore=true ;) Check the plugin properties ( 
http://maven.apache.org/maven-1.x/plugins/test/properties.html ), there are a 
few settings to control the behavior, and yes, some things have changed wrt 
m1.0.2...

> Final test failure leads to strange formatted error
> ---
>
> Key: MPTEST-75
> URL: http://jira.codehaus.org/browse/MPTEST-75
> Project: Maven 1.x Test Plugin
>  Issue Type: Bug
>Affects Versions: 1.8.2
>Reporter: Andy Jefferson
>Assignee: Lukas Theussl
>
> When running JUnit tests with Maven 1.1.0 on Linux if the final test fails I 
> get non-standard output. To attempt to explain better ...
> [junit] Running org.jpox.tests.NondurableIdTest
> [junit] Tests run: 3, Failures: 2, Errors: 0, Time elapsed: 5.947 sec
> [junit] [ERROR] Test org.jpox.tests.NondurableIdTest FAILED
> [junit] Running org.jpox.tests.ObjectFCOTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.471 sec
> [junit] Running org.jpox.tests.PersistenceManagerFactoryImplTest
> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 25.693 sec
> [junit] Running org.jpox.tests.PersistenceManagerImplTest
> [junit] Tests run: 49, Failures: 1, Errors: 0, Time elapsed: 8.589 sec
> [junit] [ERROR] Test org.jpox.tests.PersistenceManagerImplTest FAILED
> [junit] Running org.jpox.tests.SequenceTest
> [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.072 sec
> [junit] Running org.jpox.tests.SerializationTest
> [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 3.607 sec
> [junit] Running org.jpox.tests.TransactionTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.142 sec
> [junit] Running org.jpox.tests.TypeManagerTest
> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.016 sec
> [junit] Running org.jpox.tests.TypeStorageTest
> [junit] Tests run: 11, Failures: 0, Errors: 0, Time elapsed: 11.486 sec
> [junit] Running org.jpox.tests.TypesMappingTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.016 sec
> [junit] Running org.jpox.tests.ViewTest
> [junit] Tests run: 5, Failures: 0, Errors: 1, Time elapsed: 2.33 sec
> ---
> >> Unable to obtain goal [test:test]
> >> Test org.jpox.tests.ViewTest failed
> ---
> BUILD FAILED
> So normally when a test fails you get the line [ERROR] but when its the final 
> test you dont get that and get the ugly "Unable to obtain goal" etc. Why is 
> it not displaying the final test correctly?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MJAVADOC-130) Inproper Handling of Tag Definitions

[Vincent Siveton (JIRA)]

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

Vincent Siveton closed MJAVADOC-130.


 Assignee: Vincent Siveton
   Resolution: Fixed
Fix Version/s: 2.3

Fixed in svn

> Inproper Handling of Tag Definitions
> 
>
> Key: MJAVADOC-130
> URL: http://jira.codehaus.org/browse/MJAVADOC-130
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.2
> Environment: JDK 1.5.0_12, Win32
>Reporter: Benjamin Bentmann
>Assignee: Vincent Siveton
>Priority: Minor
> Fix For: 2.3
>
>
> Consider the following POM snippet for the Javadoc plugin:
> 
>   
>   generatorClass
>   Generator Class:
>   t
>   
>   
>   version
>   
> 
> This leads to the following contents of the options file passed to javadoc:
>   -tag
>   "generatorClass:t:'Generator Class:'"
> instead of 
>   -tag
>   generatorClass:t:"Generator Class:"
>   -tag
>   version
> The single quotation marks produced by the plugin will make it into the 
> generated HTML output which is not intended. Likewise, specifying the version 
> tag should allow to reorder the standard tags but the plugin will simply drop 
> the setting because no further tag option is provided:
>   A tag option is empty. Ignore this option.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MJAVADOC-128) Plugin does not accept URL to an offlineLink's location

[Vincent Siveton (JIRA)]

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

Vincent Siveton closed MJAVADOC-128.


 Assignee: Vincent Siveton
   Resolution: Fixed
Fix Version/s: 2.3

Patch applied. Thanks!

> Plugin does not accept URL to an offlineLink's location
> ---
>
> Key: MJAVADOC-128
> URL: http://jira.codehaus.org/browse/MJAVADOC-128
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Greg Thompson
>Assignee: Vincent Siveton
> Fix For: 2.3
>
> Attachments: MJAVADOC-128.diff
>
>
> According to 
> http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/javadoc.html#linkoffline,
>  the location "is the path or URL to the directory containing the 
> package-list file for the external documentation."  The plugin's 
> OfflineLink.java uses a java.io.File for the argument, which munges it if 
> it's a URL.  Easiest fix might be to just use String instead of File.

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

[jira] Closed: (MJAVADOC-131) file configuration should use File type instead of String

[Vincent Siveton (JIRA)]

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

Vincent Siveton closed MJAVADOC-131.


 Assignee: Vincent Siveton
   Resolution: Fixed
Fix Version/s: 2.3

Done for javadocDirectory and overview fields

> file configuration should use File type instead of String
> -
>
> Key: MJAVADOC-131
> URL: http://jira.codehaus.org/browse/MJAVADOC-131
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Brett Porter
>Assignee: Vincent Siveton
>Priority: Minor
> Fix For: 2.3
>
>
> review all, but a specific example is the  parameter: this is a 
> String but refers to a File, so should be a File so that it is aligned 
> against basedir automatically by Maven.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MJAVADOC-129) javadocDirectory config parameter is ignored and default doesn't work either.

[Vincent Siveton (JIRA)]

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

Vincent Siveton closed MJAVADOC-129.


 Assignee: Vincent Siveton
   Resolution: Fixed
Fix Version/s: 2.3

Added automatically  the javadocDir in the sourcepath

> javadocDirectory config parameter is ignored and default doesn't work either. 
> --
>
> Key: MJAVADOC-129
> URL: http://jira.codehaus.org/browse/MJAVADOC-129
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.3
> Environment: linux 2.6, mvn 2.0.6
>Reporter: Adam Hardy
>Assignee: Vincent Siveton
> Fix For: 2.3
>
> Attachments: javadocBug.zip
>
>
> javadoc should pick up the javadoc package.html and overview.html and image 
> files from src/main/javadoc by default. 
> It will only pick up the src/main/javadoc directory if it is entered in the 
> sourcepath config param. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-3094) xml mistake in docs

[Dennis Lundberg (JIRA)]

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

Dennis Lundberg closed MNG-3094.


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

Thanks for spotting this.
Fixed in SVN r554184.

> xml mistake in docs
> ---
>
> Key: MNG-3094
> URL: http://jira.codehaus.org/browse/MNG-3094
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Documentation: Guides
>Reporter: [EMAIL PROTECTED]
>Assignee: Dennis Lundberg
> Fix For: Documentation
>
>
> This xml example 
>
>  
>   my-internal-site
>   http://myserver/repo
>  
>
> On this page,
> http://maven.apache.org/guides/introduction/introduction-to-repositories.html
> Is not valid   The second  should read 
> As a second note. the error that maven reports  seems to be a schema 
> validation error,
> org.apache.maven.reactor.MavenExecutionException: Parse error reading POM. 
> Reason: Unrecognised tag: 'repository' (position: START_TAG see
> n ...\n ... @32:18)
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> 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)
>  It would be more useful if you did encounter an error, to report well 
> formededness exceptions first.  If the error had said something like missing 
> end tag, I would know what the problem was right away.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MANTLR-20) Cannot execute the plugin: NullPointerException in AntlrPlugin.execute(AntlrPlugin.java:75)

[Vincent Siveton (JIRA)]

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

Vincent Siveton closed MANTLR-20.
-

 Assignee: Vincent Siveton
   Resolution: Fixed
Fix Version/s: 2.0-beta-2

Throw an Exception. BTW the grammar seems to be not valid.

> Cannot execute the plugin: NullPointerException in 
> AntlrPlugin.execute(AntlrPlugin.java:75)
> ---
>
> Key: MANTLR-20
> URL: http://jira.codehaus.org/browse/MANTLR-20
> Project: Maven 2.x Antlr Plugin
>  Issue Type: Bug
>Affects Versions: 2.0-beta-1
> Environment: java version "1.5.0_11"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_11-b03, mixed mode)
> Maven version: 2.0.6
>Reporter: Régis Décamps
>Assignee: Vincent Siveton
>Priority: Critical
> Fix For: 2.0-beta-2
>
> Attachments: mantlr-20.zip, mantrl-20.log
>
>
> Maven fails to execute the antlr:geenrate task.
> It fails with a NullPointerException
> {panel:title=Console}
> mvn antlr:generate
>   [kro64]
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'antlr'.
> [INFO] 
> 
> [INFO] Building Unnamed - fr.bdf.sptim.telma:telma-parser:jar:0.0.1
> [INFO]task-segment: [antlr:generate]
> [INFO] 
> 
> [INFO] [antlr:generate]
> [INFO] grammar: /home/regis/workspace/telma-parser/src/main/antlr/java.g
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] null
> [INFO] 
> 
> [INFO] Trace
> java.lang.NullPointerException
> at 
> org.apache.maven.plugin.antlr.AntlrPlugin.execute(AntlrPlugin.java:75)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> 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:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> 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)
> {panel}
> Here is my POM:
> {code:title=pom.xml|xml}
> 
> 
>   4.0.0
>   fr.bdf.sptim.telma
>   telma-parser
>   0.0.1
>   
>   
>   
>   
>   org.apache.maven.plugins
>   maven-antlr-plugin
>   
>   java.g
>   
>   
>   
>   
>   generate
>   
>   
>   
>   
>   
>   
> 
> {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/soft

[jira] Created: (MAVENUPLOAD-1628) Upload Request

[Roberto Lo Giacco (JIRA)]

Upload Request
--

 Key: MAVENUPLOAD-1628
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1628
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Roberto Lo Giacco


SmartWeb is a rapid web application development framework based on apache 
struts and hibernate. This package is a JUnit extension to allow easy unit test 
of framework based web applications.

Please upload!

P.S.
Whenever I need to upload a new release, should I reply to this issue or create 
a new one?

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

[jira] Closed: (MJAVADOC-127) Tests fail on MacOS X

[Vincent Siveton (JIRA)]

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

Vincent Siveton closed MJAVADOC-127.


 Assignee: Vincent Siveton
   Resolution: Fixed
Fix Version/s: 2.3

Fixed in svn
http://maven.zones.apache.org/continuum/buildResult.action?buildId=11342&projectId=23

> Tests fail on MacOS X
> -
>
> Key: MJAVADOC-127
> URL: http://jira.codehaus.org/browse/MJAVADOC-127
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.3
> Environment: MacOS X 10.4.9, Java 1.5.0_07, Maven 2.0.6
>Reporter: Thomas Krammer
>Assignee: Vincent Siveton
> Fix For: 2.3
>
> Attachments: ttt.txt
>
>
> The build of the plugin fails on MacOS X with the following errors:
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.182 sec <<< 
> FAILURE!
> Running org.apache.maven.plugin.javadoc.TagTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.311 sec
> Results :
> Tests in error: 
>   testToFindJavadoc(org.apache.maven.plugin.javadoc.JavadocReportTest)
>   testJavadocResources(org.apache.maven.plugin.javadoc.JavadocReportTest)
>   
> testAggregateJavadocResources(org.apache.maven.plugin.javadoc.JavadocReportTest)
>   testDefaultConfig(org.apache.maven.plugin.javadoc.JavadocJarTest)
>   testInvalidDestdir(org.apache.maven.plugin.javadoc.JavadocJarTest)
>   testTestJavadoc(org.apache.maven.plugin.javadoc.TestJavadocReportTest)
> The full output is attached.
> This is the actual exception thrown by testGetQuotedPath (for some reason the 
> exception isn't logged to stdout):
> org.apache.maven.plugin.MojoExecutionException: An error has occurred in 
> JavaDocs report generation:Exit code: 2 - /bin/bash: -c: line 1: unexpected 
> EOF while looking for matching `''
> /bin/bash: -c: line 2: syntax error: unexpected end of file
> Command line was:"cd 
> /Users/user/alienbrainWork/mvn/maven-javadoc-plugin/target/test/unit/quotedpath'test/target/site/apidocs
>  && 
> /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc" 
> @options @argfile
>   at 
> org.apache.maven.plugin.javadoc.JavadocReport.execute(JavadocReport.java:233)
>   at 
> org.apache.maven.plugin.javadoc.JavadocReportTest.testQuotedPath(JavadocReportTest.java:508)
>   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 junit.framework.TestCase.runTest(TestCase.java:154)
>   at junit.framework.TestCase.runBare(TestCase.java:127)
>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>   at junit.framework.TestResult.run(TestResult.java:109)
>   at junit.framework.TestCase.run(TestCase.java:118)
>   at junit.framework.TestSuite.runTest(TestSuite.java:208)
>   at junit.framework.TestSuite.run(TestSuite.java:203)
>   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.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
>   at 
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
>   at 
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
>   at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
>   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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
>   at 
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818)
> Caused by: org.apache.maven.reporting.MavenReportException: Exit code: 2 - 
> /bin/bash: -c: line 1: unexpected EOF while looking for matching `''
> /bin/bash: -c: line 2: syntax error: unexpected end of file
> Command line was:"cd 
> /Users/user/alienbrainWork/mvn/maven-javadoc-plugin/target/test/unit/quotedpath'test/target/site/apidocs
>  && 
> /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc" 
> @options @argfile
>   

[jira] Updated: (MECLIPSE-292) Behaviour for sources and Javadoc attachement for dependencies should be consistent

[Brian Fox (JIRA)]

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

Brian Fox updated MECLIPSE-292:
---

Attachment: MECLIPSE-292-updated.patch

Updated patch. We just need some tests and doc updates.

> Behaviour for sources and Javadoc attachement for dependencies should be 
> consistent
> ---
>
> Key: MECLIPSE-292
> URL: http://jira.codehaus.org/browse/MECLIPSE-292
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Improvement
>  Components: dependency resolution
>Affects Versions: 2.4
> Environment: Windows XP, Maven 2.0.6, maven-eclipse-plugin 
> 2.4-20070628.215652-24
>Reporter: Denis Cabasson
>Assignee: Brian Fox
>Priority: Minor
> Attachments: MECLIPSE-292-updated.patch, MECLIPSE-292.patch
>
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> Why couldn't we have a consistent behaviour for javadoc and sources jar 
> attachment?
> Why not adding a downloadJavadoc property, which, when set to true, would 
> download and attach the javadoc to the dependency.
> I don't really see why javadoc should be a fallback if sources are not 
> available.
> Some developpers might prefer to have javadoc linked, some sources linked and 
> some both. Shouldn't the eclipse plugin allow for all the possiblities 
> instead of stating that the preferred option is always to get the sources 
> instead of the Javadoc?

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

[jira] Commented: (MECLIPSE-292) Behaviour for sources and Javadoc attachement for dependencies should be consistent

[Brian Fox (JIRA)]

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

Brian Fox commented on MECLIPSE-292:


tested by hand and works. The classpath file has absolute references to the 
javadoc jar, it should use M2_REPO like the rest.

> Behaviour for sources and Javadoc attachement for dependencies should be 
> consistent
> ---
>
> Key: MECLIPSE-292
> URL: http://jira.codehaus.org/browse/MECLIPSE-292
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Improvement
>  Components: dependency resolution
>Affects Versions: 2.4
> Environment: Windows XP, Maven 2.0.6, maven-eclipse-plugin 
> 2.4-20070628.215652-24
>Reporter: Denis Cabasson
>Assignee: Brian Fox
>Priority: Minor
> Attachments: MECLIPSE-292-updated.patch, MECLIPSE-292.patch
>
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> Why couldn't we have a consistent behaviour for javadoc and sources jar 
> attachment?
> Why not adding a downloadJavadoc property, which, when set to true, would 
> download and attach the javadoc to the dependency.
> I don't really see why javadoc should be a fallback if sources are not 
> available.
> Some developpers might prefer to have javadoc linked, some sources linked and 
> some both. Shouldn't the eclipse plugin allow for all the possiblities 
> instead of stating that the preferred option is always to get the sources 
> instead of the Javadoc?

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

[jira] Created: (MRELEASE-263) Interactive plugins cannot work in forked executions

[Daniel Kulp (JIRA)]

Interactive plugins cannot work in forked executions


 Key: MRELEASE-263
 URL: http://jira.codehaus.org/browse/MRELEASE-263
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
Affects Versions: 2.0-beta-6
Reporter: Daniel Kulp
Priority: Critical


I was looking into the problems with the GPG plugin when run from the 
release plugin and the problems seem to entirely be problems of the 
release plugin and Plexus utils.   They are showing up in the gpg 
plugin, but any plugin that tries to do anything interactively would 
most likely run into the same problems.  

Issues:
1) System.in - the release manager doesn't feed anything from System.in 
into the forked process.  I tried adding System.in to the 
CommandLineUtils.executeCommandLine call, but that just causes a hang.   
CommandLineUtils will wait until the "in" stream is completely consumed 
(returns -1) before returning.   With System.in, that never will happen.

2) Buffered(line style) out - the StreamPumpers use 
BufferedInputStream.readLine() to pump from one stream to the other.   
This won't work.   Anything that does something (like the release plugin 
itself) that prompts and then waits for a response on the same line will 
appear to just "hang" as the prompt will never make it to the screen.

Basically, those two issues completely prevent us from being able to 
un-hard code GPG passphrases from build scripts and such.   (unless you 
set gpg.useagent to true and use an agent)

In anycase, MGPG-9 is really a release plugin bug although part of it is 
due to plexus-utils not providing the support it would need to work 
properly.Most likely, we'll need to add a method in CommandLineUtils 
that would just take the raw streams (in/out/err) and do straight byte 
copy reads without the line buffering.  (and once the process 
completely, stop pumping the in stream)   (of course, that would then 
require another plexus-utils release and then the release plugin would 
only work with Maven 2.0.6+ with the utils shaded, but that may be 
minor)   I'll poke around more and see if I can come up with something.  


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-1629) Upload new version of SmartWeb to Central Repository

[Roberto Lo Giacco (JIRA)]

Upload new version of SmartWeb to Central Repository


 Key: MAVENUPLOAD-1629
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1629
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Roberto Lo Giacco


http://smartweb.sourceforge.net/smartweb-bundle.jar

http://smartweb.sourceforge.net
http://smartweb.sourceforge.net/team-list.html

SmartWeb is a rapid web application development framework based on apache 
struts and hibernate.

A bugfixing release has been prepared: please upload!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-1630) Upload maven-openfire-plugin

[Stefan Reuter (JIRA)]

Upload maven-openfire-plugin


 Key: MAVENUPLOAD-1630
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1630
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Stefan Reuter


The Maven Openfire Plugin is responsible for collecting all artifact 
dependencies, classes and
resources of an Openfire plugin and packaging them into a jar suitable for 
deployment to an Openfire
XMPP server.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MPTEST-75) Final test failure leads to strange formatted error

[Andy Jefferson (JIRA)]

[ 
http://jira.codehaus.org/browse/MPTEST-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_101588
 ] 

Andy Jefferson commented on MPTEST-75:
--

Thx :-) - last time I tried to find such settings there were no docs (but that 
was maybe 2 yrs ago). Glad its moving forward, and sorry for the erroneous bug 
report

> Final test failure leads to strange formatted error
> ---
>
> Key: MPTEST-75
> URL: http://jira.codehaus.org/browse/MPTEST-75
> Project: Maven 1.x Test Plugin
>  Issue Type: Bug
>Affects Versions: 1.8.2
>Reporter: Andy Jefferson
>Assignee: Lukas Theussl
>
> When running JUnit tests with Maven 1.1.0 on Linux if the final test fails I 
> get non-standard output. To attempt to explain better ...
> [junit] Running org.jpox.tests.NondurableIdTest
> [junit] Tests run: 3, Failures: 2, Errors: 0, Time elapsed: 5.947 sec
> [junit] [ERROR] Test org.jpox.tests.NondurableIdTest FAILED
> [junit] Running org.jpox.tests.ObjectFCOTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.471 sec
> [junit] Running org.jpox.tests.PersistenceManagerFactoryImplTest
> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 25.693 sec
> [junit] Running org.jpox.tests.PersistenceManagerImplTest
> [junit] Tests run: 49, Failures: 1, Errors: 0, Time elapsed: 8.589 sec
> [junit] [ERROR] Test org.jpox.tests.PersistenceManagerImplTest FAILED
> [junit] Running org.jpox.tests.SequenceTest
> [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.072 sec
> [junit] Running org.jpox.tests.SerializationTest
> [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 3.607 sec
> [junit] Running org.jpox.tests.TransactionTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.142 sec
> [junit] Running org.jpox.tests.TypeManagerTest
> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.016 sec
> [junit] Running org.jpox.tests.TypeStorageTest
> [junit] Tests run: 11, Failures: 0, Errors: 0, Time elapsed: 11.486 sec
> [junit] Running org.jpox.tests.TypesMappingTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.016 sec
> [junit] Running org.jpox.tests.ViewTest
> [junit] Tests run: 5, Failures: 0, Errors: 1, Time elapsed: 2.33 sec
> ---
> >> Unable to obtain goal [test:test]
> >> Test org.jpox.tests.ViewTest failed
> ---
> BUILD FAILED
> So normally when a test fails you get the line [ERROR] but when its the final 
> test you dont get that and get the ugly "Unable to obtain goal" etc. Why is 
> it not displaying the final test correctly?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MCHANGES-72) Build Failure using IBM JDK 1.4.2 SR7

[Dennis Lundberg (JIRA)]

[ 
http://jira.codehaus.org/browse/MCHANGES-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_101589
 ] 

Dennis Lundberg commented on MCHANGES-72:
-

I've had a look at this and have a couple of follow-up questions for Patrick.

Are you getting this when you are trying to send an announcement? Calling 'mvn 
changes:announcement-mail' on the command line.

Have you set sslMode=true in the configuration?

Would it be possible for you to send the plugin-snippet from your pom.xml?

> Build Failure using IBM JDK 1.4.2 SR7
> -
>
> Key: MCHANGES-72
> URL: http://jira.codehaus.org/browse/MCHANGES-72
> Project: Maven 2.x Changes Plugin
>  Issue Type: Bug
>  Components: announcement
>Affects Versions: 2.0-beta-2
> Environment: Windows XP Pro
> Maven 2.0.5
> IBM JDK 1.4.2 SR7
>Reporter: Patrick Schneider
> Attachments: changes-ibmjdk.txt
>
>
> Attached is the -e output from running 'mvn site:site'.

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

[jira] Created: (MAVENUPLOAD-1631) OpenID4Java is an OpenID implementation for Java. Please upload!

[zhoushuqun (JIRA)]

OpenID4Java is an OpenID implementation for Java. Please upload!


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


http://openid4java.googlecode.com/files/openid4java-0.9.3-bundle.jar

http://openid4java.org/
http://code.google.com/p/openid4java/

OpenID4Java is an OpenID implementation for Java. Please upload!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-178) filtering doesn't read filter files

[Mark Diggory (JIRA)]

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

Mark Diggory edited comment on MASSEMBLY-178 at 7/7/07 4:37 PM:


It appears that moduleSets cannot be filtered either.

 
 
*:war
 
 
false
webapps/${artifactId}
true

true

 
  


fails on Maven 2.0.7 and Assembly-plugin 2.2-beta-2-SNAPSHOT. I have a web.xml 
with a ${property} that will not get filtered when I have evidence all other 
 are filtered appropriately.


 was:
It appears that moduleSets cannot be filtered either.

 
 
*:war
 
 
false
webapps/${artifactId}
true

true

 
  


fails on Maven 2.0.7 and Assembly-plugin 2.2-beta-2-SNAPSHOT. I have a web.xml 
with a ${property} that will not get filtered when I have evidence all other 
 are filtered appropriately.

> filtering doesn't read filter files
> ---
>
> Key: MASSEMBLY-178
> URL: http://jira.codehaus.org/browse/MASSEMBLY-178
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.0
> Environment: Linux icebox 2.6.17-1.2174_FC5 #1 Tue Aug 8 15:30:55 EDT 
> 2006 i686 athlon i386 GNU/Linux
>Reporter: Paul Jungwirth
>Priority: Minor
> Fix For: 2.2-beta-2
>
> Attachments: filt-dist.diff, filter-test.tar.gz, filter-test.zip
>
>
> The assembly plugin's filtering supports POM properties like 
> ${project.artifactId}, but not properties read from the filter file, contrary 
> to the documentation here:
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/filtering-some-distribution-files.html
> I've attached a sample app demonstrating the problem. You can run it by 
> saying "mvn clean package." It tries to filter a README file with both 
> ${project.artifactId} and ${homer}. ${homer} is defined in filter.properties 
> like this:
> homer=woohoo
> But when you run the plugin, only ${project.artifactId} is filtered.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-178) filtering doesn't read filter files

[Mark Diggory (JIRA)]

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

Mark Diggory edited comment on MASSEMBLY-178 at 7/7/07 4:38 PM:


It appears that moduleSets cannot be filtered either.

 
 
*:war
 
 
false
webapps/${artifactId}
true

true

 
  


fails on Maven 2.0.7 and Assembly-plugin 2.2-beta-2-SNAPSHOT. I have a web.xml 
with a ${property} that will not get filtered when I have evidence all other 
 are filtered appropriately.


 was:
It appears that moduleSets cannot be filtered either.

 
 
*:war
 
 
false
webapps/${artifactId}
true

true

 
  


fails on Maven 2.0.7 and Assembly-plugin 2.2-beta-2-SNAPSHOT. I have a web.xml 
with a ${property} that will not get filtered when I have evidence all other 
 are filtered appropriately.

> filtering doesn't read filter files
> ---
>
> Key: MASSEMBLY-178
> URL: http://jira.codehaus.org/browse/MASSEMBLY-178
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.0
> Environment: Linux icebox 2.6.17-1.2174_FC5 #1 Tue Aug 8 15:30:55 EDT 
> 2006 i686 athlon i386 GNU/Linux
>Reporter: Paul Jungwirth
>Priority: Minor
> Fix For: 2.2-beta-2
>
> Attachments: filt-dist.diff, filter-test.tar.gz, filter-test.zip
>
>
> The assembly plugin's filtering supports POM properties like 
> ${project.artifactId}, but not properties read from the filter file, contrary 
> to the documentation here:
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/filtering-some-distribution-files.html
> I've attached a sample app demonstrating the problem. You can run it by 
> saying "mvn clean package." It tries to filter a README file with both 
> ${project.artifactId} and ${homer}. ${homer} is defined in filter.properties 
> like this:
> homer=woohoo
> But when you run the plugin, only ${project.artifactId} is filtered.

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

[jira] Commented: (MASSEMBLY-178) filtering doesn't read filter files

[Mark Diggory (JIRA)]

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

Mark Diggory commented on MASSEMBLY-178:


It appears that moduleSets cannot be filtered either.

 
 
*:war
 
 
false
webapps/${artifactId}
true

true

 
  


fails on Maven 2.0.7 and Assembly-plugin 2.2-beta-2-SNAPSHOT. I have a web.xml 
with a ${property} that will not get filtered when I have evidence all other 
 are filtered appropriately.

> filtering doesn't read filter files
> ---
>
> Key: MASSEMBLY-178
> URL: http://jira.codehaus.org/browse/MASSEMBLY-178
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.0
> Environment: Linux icebox 2.6.17-1.2174_FC5 #1 Tue Aug 8 15:30:55 EDT 
> 2006 i686 athlon i386 GNU/Linux
>Reporter: Paul Jungwirth
>Priority: Minor
> Fix For: 2.2-beta-2
>
> Attachments: filt-dist.diff, filter-test.tar.gz, filter-test.zip
>
>
> The assembly plugin's filtering supports POM properties like 
> ${project.artifactId}, but not properties read from the filter file, contrary 
> to the documentation here:
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/filtering-some-distribution-files.html
> I've attached a sample app demonstrating the problem. You can run it by 
> saying "mvn clean package." It tries to filter a README file with both 
> ${project.artifactId} and ${homer}. ${homer} is defined in filter.properties 
> like this:
> homer=woohoo
> But when you run the plugin, only ${project.artifactId} is filtered.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MASSEMBLY-178) filtering doesn't read filter files

[Mark Diggory (JIRA)]

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

Mark Diggory edited comment on MASSEMBLY-178 at 7/7/07 4:40 PM:


It appears that moduleSets cannot be filtered either.
{code:xml}
 
 
*:war
 
 
false
webapps/${artifactId}
true

true

 
  
{code}

fails on Maven 2.0.7 and Assembly-plugin 2.2-beta-2-SNAPSHOT. I have a web.xml 
with a ${property} that will not get filtered when I have evidence all other 
 are filtered appropriately.


 was:
It appears that moduleSets cannot be filtered either.

 
 
*:war
 
 
false
webapps/${artifactId}
true

true

 
  


fails on Maven 2.0.7 and Assembly-plugin 2.2-beta-2-SNAPSHOT. I have a web.xml 
with a ${property} that will not get filtered when I have evidence all other 
 are filtered appropriately.

> filtering doesn't read filter files
> ---
>
> Key: MASSEMBLY-178
> URL: http://jira.codehaus.org/browse/MASSEMBLY-178
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.0
> Environment: Linux icebox 2.6.17-1.2174_FC5 #1 Tue Aug 8 15:30:55 EDT 
> 2006 i686 athlon i386 GNU/Linux
>Reporter: Paul Jungwirth
>Priority: Minor
> Fix For: 2.2-beta-2
>
> Attachments: filt-dist.diff, filter-test.tar.gz, filter-test.zip
>
>
> The assembly plugin's filtering supports POM properties like 
> ${project.artifactId}, but not properties read from the filter file, contrary 
> to the documentation here:
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/filtering-some-distribution-files.html
> I've attached a sample app demonstrating the problem. You can run it by 
> saying "mvn clean package." It tries to filter a README file with both 
> ${project.artifactId} and ${homer}. ${homer} is defined in filter.properties 
> like this:
> homer=woohoo
> But when you run the plugin, only ${project.artifactId} is filtered.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MCHANGES-77) Document the variables available to the announcement template.

[Dennis Lundberg (JIRA)]

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

Dennis Lundberg updated MCHANGES-77:


 Assignee: Dennis Lundberg
Affects Version/s: (was: 2.0-beta-3)
   2.0-beta-2
Fix Version/s: 2.0-beta-3

> Document the variables available to the announcement template.
> --
>
> Key: MCHANGES-77
> URL: http://jira.codehaus.org/browse/MCHANGES-77
> Project: Maven 2.x Changes Plugin
>  Issue Type: Improvement
>  Components: announcement
>Affects Versions: 2.0-beta-2
>Reporter: Paul Spencer
>Assignee: Dennis Lundberg
> Fix For: 2.0-beta-3
>
>
>  Document the variables available to the announcement template. 
> The list currently includes:
>releases
>groupId
>artifactId
>version
>packaging
>url
>introduction
>developmentTeam
>finalName
>urlDownload

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MCHANGES-77) Document the variables available to the announcement template.

[Dennis Lundberg (JIRA)]

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

Dennis Lundberg closed MCHANGES-77.
---

Resolution: Fixed

Fixed in r554273.

> Document the variables available to the announcement template.
> --
>
> Key: MCHANGES-77
> URL: http://jira.codehaus.org/browse/MCHANGES-77
> Project: Maven 2.x Changes Plugin
>  Issue Type: Improvement
>  Components: announcement
>Affects Versions: 2.0-beta-2
>Reporter: Paul Spencer
>Assignee: Dennis Lundberg
> Fix For: 2.0-beta-3
>
>
>  Document the variables available to the announcement template. 
> The list currently includes:
>releases
>groupId
>artifactId
>version
>packaging
>url
>introduction
>developmentTeam
>finalName
>urlDownload

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MCHANGES-79) Allow for overriding the announcement email from address

[Dennis Lundberg (JIRA)]

[ 
http://jira.codehaus.org/browse/MCHANGES-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_101604
 ] 

Dennis Lundberg commented on MCHANGES-79:
-

I would like to propose a different approach to this. How about adding a 
{{fromDeveloperId}} parameter. This should match the {{id}} of one of the 
{{developers}} in the pom. If a matching developer is found it will be used 
instead of the first developer in the list.

> Allow for overriding the announcement email from address
> 
>
> Key: MCHANGES-79
> URL: http://jira.codehaus.org/browse/MCHANGES-79
> Project: Maven 2.x Changes Plugin
>  Issue Type: New Feature
>  Components: announcement
>Reporter: Alexander Schwartz
>
> Currently the goal {{changes:announcement-mail}} uses the email address of 
> the first developer found in the pom as the from address of the announcement 
> email. Very often a project is released by a developer that is not the first 
> on in the list of developers in the pom -- which results is an announcement 
> email with awron, confusing from address. (Of course one can change the list 
> of developers for each release, or add a dummy developer "buildmaster" as the 
> first one in the developer list, but this is not my preferred option).
> The maven1 announcement plugin has a parameter {{from}} which allows to 
> specify a different from address.
> I suggest to add an optional parameter {{fromAdress}} to the goal 
> {{changes:announcement-mail}}  of the {{maven-changes-plugin}} such that one
> can specify the sender as follows:
> {noformat}
> 
>   ...
>   
> 
>   
> org.apache.maven.plugins
> maven-changes-plugin
> 
> 
>  [EMAIL PROTECTED]
>
> 
>   
> 
>   
>   ...
> 
> {noformat}
>  If the paremter {{fromAdress}}  is given its content is taken as the the 
> sender address of the announcement mail. If the option is not specified, the 
> fallback is the email address of the first developer in the POM. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MCHANGES-70) NPE if the version attribute is not set properly in the changes.xml file

[Dennis Lundberg (JIRA)]

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

Dennis Lundberg closed MCHANGES-70.
---

Resolution: Fixed

Fixed in r554276.

> NPE if the version attribute is not set properly in the changes.xml file
> 
>
> Key: MCHANGES-70
> URL: http://jira.codehaus.org/browse/MCHANGES-70
> Project: Maven 2.x Changes Plugin
>  Issue Type: Bug
>  Components: announcement
>Affects Versions: 2.0-beta-3
>Reporter: Stephane Nicoll
>Assignee: Dennis Lundberg
>Priority: Minor
> Fix For: 2.0-beta-3
>
>
> If the version is not set in the release xml element, a NPE is thrown:
> {noformat}
>  java.lang.NullPointerException
> at 
> org.apache.maven.plugin.announcement.AnnouncementMojo.getLatestRelease(AnnouncementMojo.java:372)
> at 
> org.apache.maven.plugin.announcement.AnnouncementMojo.doGenerate(AnnouncementMojo.java:277)
> at 
> org.apache.maven.plugin.announcement.AnnouncementMojo.execute(AnnouncementMojo.java:235)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:898)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:734)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:505)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {noformat}

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

[jira] Updated: (MCHANGES-70) NPE if the version attribute is not set properly in the changes.xml file

[Dennis Lundberg (JIRA)]

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

Dennis Lundberg updated MCHANGES-70:


   Assignee: Dennis Lundberg  (was: Stephane Nicoll)
Component/s: (was: changes-report)
 announcement

> NPE if the version attribute is not set properly in the changes.xml file
> 
>
> Key: MCHANGES-70
> URL: http://jira.codehaus.org/browse/MCHANGES-70
> Project: Maven 2.x Changes Plugin
>  Issue Type: Bug
>  Components: announcement
>Affects Versions: 2.0-beta-3
>Reporter: Stephane Nicoll
>Assignee: Dennis Lundberg
>Priority: Minor
> Fix For: 2.0-beta-3
>
>
> If the version is not set in the release xml element, a NPE is thrown:
> {noformat}
>  java.lang.NullPointerException
> at 
> org.apache.maven.plugin.announcement.AnnouncementMojo.getLatestRelease(AnnouncementMojo.java:372)
> at 
> org.apache.maven.plugin.announcement.AnnouncementMojo.doGenerate(AnnouncementMojo.java:277)
> at 
> org.apache.maven.plugin.announcement.AnnouncementMojo.execute(AnnouncementMojo.java:235)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:898)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:734)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:505)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {noformat}

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

[jira] Updated: (MCHANGES-67) The changes plugin should not hard code the "team-list.html" file

[Dennis Lundberg (JIRA)]

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

Dennis Lundberg updated MCHANGES-67:


Issue Type: Improvement  (was: Bug)

> The changes plugin should not hard code the "team-list.html" file 
> --
>
> Key: MCHANGES-67
> URL: http://jira.codehaus.org/browse/MCHANGES-67
> Project: Maven 2.x Changes Plugin
>  Issue Type: Improvement
>  Components: changes-report
>Affects Versions: 2.0-beta-2, 2.0-beta-3
>Reporter: Henning Schmiedehausen
> Attachments: changes5.patch
>
>
> Projects that do not have a team-list file or use a different file will have 
> a number of broken links on the changes-plugin report page.
> The attached patch makes the URL of the team-list file configurable with the 
> default being the "team-list.html" file. This can be changed by setting the 
> 
>   foo.html
> 
> parameter. When this parameter is set to empty (e.g.
> 
>   
> 
> then no link is generated and just the names are reported.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MCHANGES-57) How does the plugin know what issues were fixed in this version?

[Dennis Lundberg (JIRA)]

[ 
http://jira.codehaus.org/browse/MCHANGES-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_101606
 ] 

Dennis Lundberg commented on MCHANGES-57:
-

Thanks for your patch Jochen. Unfortunately it will not work. When you supply a 
value for "fixfor" to JIRA you are supposed to give it the id of the version - 
not the name of the version.

> How does the plugin know what issues were fixed in this version?
> 
>
> Key: MCHANGES-57
> URL: http://jira.codehaus.org/browse/MCHANGES-57
> Project: Maven 2.x Changes Plugin
>  Issue Type: Bug
>  Components: jira-report
>Reporter: Dennis Lundberg
> Attachments: MCHANGES-57.patch
>
>
> From the user-list:
> I was able to configure the maven-changes plugin for JIRA, but how to
> generate a report.
> My basic question is: how does maven/svn know what issues got fixes as part
> of checkin? Does the developer need to mention this data in some xml file.
> I have read somewhere that if you configure JIRA as the issue
> management tool, it should pull automatically... I don't get that. Any
> clues?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (CONTINUUM-1340) After adding a ant project to the default project group (default project group is not displayed)

[Olivier Lamy (JIRA)]

After adding a ant project to the default project group (default project group 
is not displayed)


 Key: CONTINUUM-1340
 URL: http://jira.codehaus.org/browse/CONTINUUM-1340
 Project: Continuum
  Issue Type: Bug
  Components: Core system
 Environment: non relevant 
Reporter: Olivier Lamy


After adding a ant project to the default project group (without having added 
maven1/2 project before), the default project group is not displayed on the 
home page.
Missing role assignation for this projects types.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MCHANGES-75) Setting maxEntries results in incorrect JIRA results

[Dennis Lundberg (JIRA)]

[ 
http://jira.codehaus.org/browse/MCHANGES-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_101607
 ] 

Dennis Lundberg commented on MCHANGES-75:
-

This seems to be a limit in the SAX parser. The error happens when there are a 
lot of entities like & and such in the file being parsed. I got around this 
one by specifying an explicit value for this limit on the command line
{code}
mvn site -DentityExpansionLimit=10
{code}

When doing that, I *only* got issues for MNG - not any other project. So that 
may have been a glitch in codehaus JIRA at that time.

However, I have not been successful in doing this programatically in the 
plugin. You can set properties on the parser, but I don't know the correct id 
for the property.

> Setting maxEntries results in incorrect JIRA results
> 
>
> Key: MCHANGES-75
> URL: http://jira.codehaus.org/browse/MCHANGES-75
> Project: Maven 2.x Changes Plugin
>  Issue Type: Bug
>  Components: jira-report
>Affects Versions: 2.0-beta-2
> Environment: maven 2.0.6
>Reporter: John Casey
>
> When I configure maxEntries == 500 and point the jira-report at 
> http://jira.codehaus.org/browse/MNG, it fails to parse the resulting XML, 
> saying it has exceeded 64,000 entity expansions (something to do with SAX). 
> The error is:
> org.xml.sax.SAXParseException: Parser has reached the entity expansion limit 
> "64,000" set by the Application.
> When I wget the URL that the changes plugin has generated: 
> http://jira.codehaus.org/secure/IssueNavigator.jspa?view=rss&pid=10500&sorter/field=created&sorter/order=DESC&sorter/field=priority&sorter/order=DESC&tempMax=500&reset=true&decorator=none
> it shows results from XWIRE and XULUX...clearly not limited to MNG.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MCHANGES-62) Empty JIRA report

[Dennis Lundberg (JIRA)]

[ 
http://jira.codehaus.org/browse/MCHANGES-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_101608
 ] 

Dennis Lundberg commented on MCHANGES-62:
-

I have not been able to reproduce this issue.

I have run 'mvn site' for this plugin using both 2.0-beta-2 and the latest 
2.0-beta-3-SNAPSHOT, and both of the succeed in creating a good JIRA-report.

> Empty JIRA report
> -
>
> Key: MCHANGES-62
> URL: http://jira.codehaus.org/browse/MCHANGES-62
> Project: Maven 2.x Changes Plugin
>  Issue Type: Bug
>  Components: jira-report
>Affects Versions: 2.0-beta-2
> Environment: JIRA 3.6.5 Enterprise
>Reporter: Ky Vinh Tran Luu
> Attachments: IssueNavigator.jspa.xml, jira-results.xml, pom.xml
>
>
> When generating a JIRA report, the resulting page is blank (only shows column 
> headers "Key", "Summary", ...).
> When executing the changes:jira-report goal, maven outputs:
> [INFO] [site:site]
> [INFO] Generate "Jira Report" report.
> [INFO] JIRA lives at: http://localhost:8080
> [INFO] Downloading 
> http://localhost:8080/secure/IssueNavigator.jspa?view=rss&pid=10020&sorter/field=created&sorter/order=DESC&sorter/field=priority&sorter/order=DESC&tempMax=100&reset=true&decorator=none
> [INFO] Downloading successful
> [INFO] Generate "Maven Surefire Report" report.
> Attached are the results of the download and the jira-results.xml file 
> created in the target directory.
> Thanks

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

[jira] Commented: (MECLIPSE-266) plugin applies java facet to ear project

[Thierry Levieux (JIRA)]

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

Thierry Levieux commented on MECLIPSE-266:
--

Sorry, I was probably tired this day, facets are generated by 
maven-eclipse-plugin, 
not maven-ear-plugin !!! 
Also, you're right, these parameters seem to be wrong (Crtl-v / Crtl-c ?!).

Which maven-eclipse-plugin & eclipse-wtp versions are you using ?
I know that one way the plugin applies the ear version is to find the j2ee
version in the dependencies (javaee-api", "j2ee" or "geronimo-spec-j2ee).

Do you have any of them in your pom ?

Thierry



> plugin applies java facet to ear project
> 
>
> Key: MECLIPSE-266
> URL: http://jira.codehaus.org/browse/MECLIPSE-266
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Bug
>  Components: WTP support
>Affects Versions: 2.3
> Environment: Windows XP
>Reporter: Srepfler Srgjan
>
> In .settings/org.eclipse.wst.common.project.facet.core.xml of the EAR module 
> I'm getting this:
> 
>   
>   
>   
>   
> 
> This is a wrong facet on a EAR module and I can't compile if I don't edit 
> this file manually (I can't do it from the project properties - facets dialog)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MCHANGES-73) No longer integrates with JIRA

[Dennis Lundberg (JIRA)]

[ 
http://jira.codehaus.org/browse/MCHANGES-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_101610
 ] 

Dennis Lundberg commented on MCHANGES-73:
-

This seems strange. The 2.0-beta-2 release uses 
commons-httpclient:commons-httpclient:3.0.1, which in turn has a dependency on 
commons-codec:1.2. So unless you are using some sort of repository proxy there 
should be no problem for you. If you *are* using a proxy, make sure that you 
have commons-codec:commons-codec:1.2 in there.

> No longer integrates with JIRA
> --
>
> Key: MCHANGES-73
> URL: http://jira.codehaus.org/browse/MCHANGES-73
> Project: Maven 2.x Changes Plugin
>  Issue Type: Bug
>  Components: jira-report
>Affects Versions: 2.0-beta-2
> Environment: Windows XP, Linux (RHEL3)
>Reporter: Immo Huneke
>
> As of this morning (2nd April 2007), the Maven Changes Plugin suddenly 
> stopped working with a fatal error. Nothing about our POMs or the JIRA system 
> used here had changed overnight - yet we were seeing decoding errors in some 
> builds. In an attempt to resolve the situation, we deleted the local Maven 
> repository - with the result that now ALL builds failed during site 
> generation! The configured issue-tracking section of the POM is as follows:
> 
> JIRA
> 
> http://jira-xtools.ldn.swissbank.com:7500/jira/secure/BrowseProject.jspa?pid=10193
> 
> We previously had IssueNavigator.jspa, but the result was identical.
> Part of the error message is shown below:
> artifact org.apache.maven.skins:maven-default-skin: checking for updates from 
> central
> Generating 
> /sbclocal/icc/teamcity/buildagent1/ICC_Tools_BuildSystemHooks/SubversionHooks/target/site/jira-report.html
> Generate "Jira Report" report.
> JIRA lives at: http://jira-xtools.ldn.swissbank.com:7500/jira
> 
> FATAL ERROR
> 
> org/apache/commons/codec/DecoderException
> 
> Trace
> java.lang.NoClassDefFoundError: org/apache/commons/codec/DecoderException
>   at 
> org.apache.commons.httpclient.HttpMethodBase.(HttpMethodBase.java:217)
>   at 
> org.apache.commons.httpclient.methods.GetMethod.(GetMethod.java:88)
>   at 
> org.apache.maven.plugin.jira.AbstractJiraDownloader.download(AbstractJiraDownloader.java:479)
>   at 
> org.apache.maven.plugin.jira.AbstractJiraDownloader.doExecute(AbstractJiraDownloader.java:241)
>   at 
> org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:181)
>   at 
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:101)
>   at 
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:67)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MCHANGES-60) The jira report should handle the nonProxyHosts specified in settings.xml

[Dennis Lundberg (JIRA)]

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

Dennis Lundberg updated MCHANGES-60:


Issue Type: Improvement  (was: Bug)

> The jira report should handle the nonProxyHosts specified in settings.xml
> -
>
> Key: MCHANGES-60
> URL: http://jira.codehaus.org/browse/MCHANGES-60
> Project: Maven 2.x Changes Plugin
>  Issue Type: Improvement
>  Components: jira-report
>Affects Versions: 2.0-beta-2
> Environment: A network with a proxy to access the outside, and a JIRA 
> inside the network.
>Reporter: Pierre-Antoine Grégoire
>
> These nonProxyHosts can be retrieved with the 
> settings.getActiveProxy().getNonProxyHosts();
> This returns a String containing a (usually?)comma-separated list of 
> nonProxyHosts.
> If the jira URL matches one of these hosts, it should not use any proxy of 
> course ;).
> I haven't found a nonProxyHosts concept in commons-httpclient, so it should 
> be checked in the determineProxy Method of AbstractJiraDownloader.
> This is quickly fixed and would be very useful ;)
> 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] Reopened: (MECLIPSE-271) Ability to skip

[Dan Tran (JIRA)]

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

Dan Tran reopened MECLIPSE-271:
---


reopen to add ability to skip in eclipse:clean goal.  Without this, the 
original intension is useless since
eclipse:clean cleans up custom files

> Ability to skip
> ---
>
> Key: MECLIPSE-271
> URL: http://jira.codehaus.org/browse/MECLIPSE-271
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: New Feature
>  Components: multiproject
>Affects Versions: 2.3
> Environment: xp, linux
>Reporter: Dan Tran
>Assignee: Carlos Sanchez
> Fix For: 2.4
>
> Attachments: MECLIPSE-271.diff
>
>
> I would like mvn eclipse:eclipse to skip its execution 
> use case:  currently eclipse:eclipse goal can not generate my webapp project 
> file correctly using WTP 2.0 so I ended up to handcraft eclipse project and 
> setting files and check them into SCM.  By supporting 'skip' configuration, I 
> can have eclipse to generate other project file and skip my web app ( until 
> WTP 2.0 feature is added in the example) 
> comments?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MECLIPSE-65) Add contextName parameter to eclipse mojo so a webtool context name doesn't have to match artifactId/project name.

[Dan Tran (JIRA)]

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

Dan Tran updated MECLIPSE-65:
-

Attachment: MECLIPSE-65-271.diff

Attached is the resurrection of Edwin Punzalan's patch + testcases.  In this 
patch, I have to rename
deployName to contextName since

   - override the default JEE context name is the intention of the patch
   - deploy name has a different meaning in JEE terminology where a JEE deploy 
module which has a name
 but does have an internal context name. We want to leave  deploy name 
untouch.

I also attach MECLIPSE-271 since it is very trivial.

Brian please review, I can apply
   



> Add contextName parameter to eclipse mojo so a webtool context name doesn't 
> have to match artifactId/project name.
> --
>
> Key: MECLIPSE-65
> URL: http://jira.codehaus.org/browse/MECLIPSE-65
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: New Feature
>  Components: WTP support
>Reporter: Yujin Kim
>Assignee: Brian Fox
>Priority: Minor
> Fix For: 2.4
>
> Attachments: MECLIPSE-65-271.diff, MECLIPSE-65-PATCH.txt, 
> MECLIPSE-65.patch
>
>


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

[jira] Updated: (MECLIPSE-65) Add contextName parameter to eclipse mojo so a webtool context name doesn't have to match artifactId/project name.

[Dan Tran (JIRA)]

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

Dan Tran updated MECLIPSE-65:
-

Fix Version/s: (was: 2.5)
   2.4

> Add contextName parameter to eclipse mojo so a webtool context name doesn't 
> have to match artifactId/project name.
> --
>
> Key: MECLIPSE-65
> URL: http://jira.codehaus.org/browse/MECLIPSE-65
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: New Feature
>  Components: WTP support
>Reporter: Yujin Kim
>Assignee: Brian Fox
>Priority: Minor
> Fix For: 2.4
>
> Attachments: MECLIPSE-65-271.diff, MECLIPSE-65-PATCH.txt, 
> MECLIPSE-65.patch
>
>


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

[jira] Created: (MPLUGIN-34) plugin goal report should indicate deprecated parameters

[Brian Fox (JIRA)]

plugin goal report should indicate deprecated parameters


 Key: MPLUGIN-34
 URL: http://jira.codehaus.org/browse/MPLUGIN-34
 Project: Maven 2.x Plugin Plugin
  Issue Type: Improvement
Affects Versions: 2.3
Reporter: Brian Fox
Priority: Minor


Currently there is no indication on the goals page when a parameter is 
deprecated.

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

[jira] Commented: (MECLIPSE-271) Ability to skip

[Dan Tran (JIRA)]

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

Dan Tran commented on MECLIPSE-271:
---

eclipse:clean patch is included with MECLIPSE-75

> Ability to skip
> ---
>
> Key: MECLIPSE-271
> URL: http://jira.codehaus.org/browse/MECLIPSE-271
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: New Feature
>  Components: multiproject
>Affects Versions: 2.3
> Environment: xp, linux
>Reporter: Dan Tran
>Assignee: Carlos Sanchez
> Fix For: 2.4
>
> Attachments: MECLIPSE-271.diff
>
>
> I would like mvn eclipse:eclipse to skip its execution 
> use case:  currently eclipse:eclipse goal can not generate my webapp project 
> file correctly using WTP 2.0 so I ended up to handcraft eclipse project and 
> setting files and check them into SCM.  By supporting 'skip' configuration, I 
> can have eclipse to generate other project file and skip my web app ( until 
> WTP 2.0 feature is added in the example) 
> comments?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MECLIPSE-65) Add contextName parameter to eclipse mojo so a webtool context name doesn't have to match artifactId/project name.

[Brian Fox (JIRA)]

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

Brian Fox closed MECLIPSE-65.
-

Resolution: Fixed

I love it when patches apply w/no conflicts. Thanks Dan.

> Add contextName parameter to eclipse mojo so a webtool context name doesn't 
> have to match artifactId/project name.
> --
>
> Key: MECLIPSE-65
> URL: http://jira.codehaus.org/browse/MECLIPSE-65
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: New Feature
>  Components: WTP support
>Reporter: Yujin Kim
>Assignee: Brian Fox
>Priority: Minor
> Fix For: 2.4
>
> Attachments: MECLIPSE-65-271.diff, MECLIPSE-65-PATCH.txt, 
> MECLIPSE-65.patch
>
>


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

[jira] Closed: (MECLIPSE-271) Ability to skip

[Brian Fox (JIRA)]

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

Brian Fox closed MECLIPSE-271.
--

  Assignee: Brian Fox  (was: Carlos Sanchez)
Resolution: Fixed

Patch applied, thanks.

> Ability to skip
> ---
>
> Key: MECLIPSE-271
> URL: http://jira.codehaus.org/browse/MECLIPSE-271
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: New Feature
>  Components: multiproject
>Affects Versions: 2.3
> Environment: xp, linux
>Reporter: Dan Tran
>Assignee: Brian Fox
> Fix For: 2.4
>
> Attachments: MECLIPSE-271.diff
>
>
> I would like mvn eclipse:eclipse to skip its execution 
> use case:  currently eclipse:eclipse goal can not generate my webapp project 
> file correctly using WTP 2.0 so I ended up to handcraft eclipse project and 
> setting files and check them into SCM.  By supporting 'skip' configuration, I 
> can have eclipse to generate other project file and skip my web app ( until 
> WTP 2.0 feature is added in the example) 
> comments?

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

[jira] Commented: (MECLIPSE-213) more jee support for wtp

[Brian Fox (JIRA)]

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

Brian Fox commented on MECLIPSE-213:


Patch needs to be updated and should include a test.

> more jee support for wtp
> 
>
> Key: MECLIPSE-213
> URL: http://jira.codehaus.org/browse/MECLIPSE-213
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Improvement
>  Components: WTP support
>Affects Versions: 2.3
> Environment: linux suse 10.0 eclipse 3.2.1 and wtp 1.5.1 java 1.5.0_8
>Reporter: Richard van Nieuwenhoven
> Attachments: maven-eclipse-plugin-2.3-CFC-2007-03-08.patch, 
> maven-eclipse-plugin-2.3-PATCH-2007-03-08.tgz, 
> maven-eclipse-plugin-R494407.patch
>
>
> I tried the new release 2.3 of the eclipse plugin and noteted that not alle 
> of my paches where included. 
> I re-pached the 2.3 version again this time i made my changes configurable so 
> they can be turned on and off.
> my changes:
> - prohibit dupicate entries in the classpath
> provided system paths in combination with log4j/commons-logging/xerces 
> can easely create such problems
> - system paths are only included in ears and war when they are inside the 
> project
>bether behavior would be to exclude all system paths because the war and 
> ear plugin also ignore these
> - an application.xml specialy for eclipse-wtp 
>this makes wtp ears function correctly it includes the eclipse project 
> modules instead of the maven generated jars
> - manifest generation for wtp
>wtp needs manifest files, but not the ones maven creates because they have 
> version names for all modules etc
>this generates a wtp manifest that will be in a ons eclipse source 
> directory that is ignored my maven itself
> use the parameters  -Declipse.wtpmanifest=true 
> -Declipse.wtpapplicationxml=true  to acivate the patch.
> The manifest generator could be combined with the RadManifestWriter in the 
> future, they are almost the same.
> regards,
> Ritchie

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MECLIPSE-231) Clean mojo assumes that POM projects never have .project files - this is incorrect

[Brian Fox (JIRA)]

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

Brian Fox closed MECLIPSE-231.
--

 Assignee: Brian Fox
   Resolution: Fixed
Fix Version/s: 2.4

Patch applied, thanks.

> Clean mojo assumes that POM projects never have .project files - this is 
> incorrect
> --
>
> Key: MECLIPSE-231
> URL: http://jira.codehaus.org/browse/MECLIPSE-231
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: John Allen
>Assignee: Brian Fox
> Fix For: 2.4
>
> Attachments: EclipseCleanMojo.diff
>
>
> Quite simply there are quite a few ways to make eclipse:eclipse generate POM 
> based projects and thus the assumption in eclipse:clean that there are never 
> any to clean up is invalid.
> We use a flat hierarchy like this:
>  Directory of D:\APT\projects\apt\examples\calculator
> 14/02/2007  12:40  .
> 14/02/2007  12:40  ..
> 14/02/2007  16:32  calculator-ear
> 14/02/2007  16:32  calculator-ejb
> 14/02/2007  16:32  calculator-engine
> 14/02/2007  16:25  calculator-root
> 14/02/2007  16:32  calculator-servlets
> 14/02/2007  16:32  calculator-webapp
> calculator-root is the PARENT project of type POM which which logically 
> contains all the others. 
> As we are flat we can import all of these into Eclipse without any complaints 
> from Eclipse. To get eclipse:eclipse to generate a .project file for 
> calculator-root we tell the eclipse plugin that the Eclipse workspace is == 
> to the project.builddir. So inside calculator-root/pom.xml we have:-
>
>  
>
>   
>   
>   org.apache.maven.plugins
>   maven-eclipse-plugin
>   
>   
> ${project.basedir}
>   
>   
> 
>   
> This works a treat, we get all the Eclipse project files generated. However 
> eclipse:clean dont do the do. May i suggest you just delete any files in 
> clean rather than trying to be clever? Works for us. Patch 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] Commented: (MECLIPSE-165) Ability to exclude filtered resources from eclipse's source directories

[Brian Fox (JIRA)]

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

Brian Fox commented on MECLIPSE-165:


Applied the patch and updated so it applied cleanly. The resulting classpath 
doesn't match the expected one. Although the resulting one actually has the 
excludes, the format seems curious to me. It's excluding **/*.java from the 
binary resources. The code is applied to a branch here: 
https://svn.apache.org/repos/asf/maven/plugins/branches/maven-eclipse-plugin-MECLIPSE-165

If you can look and provide a patch from this branch, then we can get it 
applied to trunk. Thanks.

> Ability to exclude filtered resources from eclipse's source directories
> ---
>
> Key: MECLIPSE-165
> URL: http://jira.codehaus.org/browse/MECLIPSE-165
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: New Feature
>  Components: PDE support
>Affects Versions: 2.3
>Reporter: Cédric Vidal
> Attachments: MECLIPSE-165.patch
>
>
> Resources should be in the classpath from Eclipse's point of view because 
> they end up being in the classpath from Maven 2's point of view, but whenever 
> resources are marked as being filtered by M2, Eclipse puts them unfiltered in 
> the classpath thus introducing an inconsistency between Maven 2 and Eclipse.
> Whether or not to include filtered resource directories in eclipse's sources 
> directories is therefore a real dilemna. While I'm sure a consistent solution 
> to this dilemna will eventually be found, it would be great to let the user 
> choose what to do in the meantime.
> The attached patch adresses this issue by adding a parameter, 
> 'excludeFilteredResourcesFromSourceDirs', which when set to true prevents 
> filtered resource directories from being added to eclipse's source 
> directories. The parameter defaults to false to avoid changing current 
> projects' behavior.
> Regards,
> Cédric Vidal
> http://www.B-Process.com
> PS: This parameter could be overriden on a per resource directory basis as 
> mentionned in MECLIPSE-162. This is not adressed by the attached patch though

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

[jira] Commented: (MECLIPSE-217) WTP component file is sometimes missing libraries if the POM lists multiple artifact types with the same artifact ID

[Brian Fox (JIRA)]

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

Brian Fox commented on MECLIPSE-217:


patch should be updated. Recent fixes have been made to be sensitive to 
classifier, it's possible this would solve the problem also.

> WTP component file is sometimes missing libraries if the POM lists multiple 
> artifact types with the same artifact ID
> 
>
> Key: MECLIPSE-217
> URL: http://jira.codehaus.org/browse/MECLIPSE-217
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Bug
>  Components: WTP support
>Affects Versions: 2.3
>Reporter: DJ Gregor
> Attachments: diffs, diffs
>
>
> A number of the projects in our application require not only the binary JAR 
> from another project, but also the test JAR.  When generating the Eclipse WTP 
> configuration files with the plugin, some of these libraries needed at 
> runtime are not put in the component file, and cause the webapp to not be 
> functional.  The behavior is not always consistent--sometimes all libraries 
> will be there, or one or more will be missing.
> Here's an example of from our POM (which can be seen in whole here: 
> ):
> 
>   org.opennms
>   opennms-dao
> 
> 
> 
>   org.opennms
>   opennms-dao
>   ${project.version}
>   test-jar
>   test
> 
> Notice that we have opennms-dao listed twice, once to get the binary JAR, and 
> once for the test JAR.  This works fine with Maven from the command line and 
> works fine within Eclipse until we go to deploy a webapp with WTP.
> AbstractIdeSupportMojo.doDependencyResolution() keeps a HashSet of projects 
> that have already been added to the dependency list in 
> emittedReactorProjectId, keyed on the group ID and artifact ID of the 
> project.  Since our project requires multiple artifacts of different types 
> from the same project, only one dependency makes it into the list that 
> AbstractIdeSupportMojo.doDependencyResolution() returns.  This wouldn't be a 
> problem, except sometimes instead of our runtime dependency making it in 
> first, the dependency that makes it in is the test dependency which later 
> gets thrown out by AbstractWtpResourceWriter.writeWarOrEarResources.
> The attached patch changes the key used for inserting values into the 
> emittedReactorProjectId HashSet to include the artifact type.  The 
> EclipseProjectWriter and EclipseClasspathWriter need to only print out unique 
> artifact IDs (which are Eclipse projects), so they each keep their own 
> HashSet keyed on artifact ID to ensure that an artifact ID is only emitted 
> once.
> This patch solves this problem that I've been having on OpenNMS.  I will work 
> on unit tests for these changes as I have 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] Closed: (MECLIPSE-292) Behaviour for sources and Javadoc attachement for dependencies should be consistent

[Brian Fox (JIRA)]

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

Brian Fox closed MECLIPSE-292.
--

   Resolution: Fixed
Fix Version/s: 2.4

Eclipse doesn't support variables in the javadoc classpath and having absolute 
references breaks the unit tests for now. 

> Behaviour for sources and Javadoc attachement for dependencies should be 
> consistent
> ---
>
> Key: MECLIPSE-292
> URL: http://jira.codehaus.org/browse/MECLIPSE-292
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Improvement
>  Components: dependency resolution
>Affects Versions: 2.4
> Environment: Windows XP, Maven 2.0.6, maven-eclipse-plugin 
> 2.4-20070628.215652-24
>Reporter: Denis Cabasson
>Assignee: Brian Fox
>Priority: Minor
> Fix For: 2.4
>
> Attachments: MECLIPSE-292-updated.patch, MECLIPSE-292.patch
>
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> Why couldn't we have a consistent behaviour for javadoc and sources jar 
> attachment?
> Why not adding a downloadJavadoc property, which, when set to true, would 
> download and attach the javadoc to the dependency.
> I don't really see why javadoc should be a fallback if sources are not 
> available.
> Some developpers might prefer to have javadoc linked, some sources linked and 
> some both. Shouldn't the eclipse plugin allow for all the possiblities 
> instead of stating that the preferred option is always to get the sources 
> instead of the Javadoc?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-3090) Nearest dependency, which is not included by a filter, wins, although a farthest dependency, which is included by the same filter, does not win.

[Christian Schulte (JIRA)]

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

Christian Schulte commented on MNG-3090:


Reading 
http://docs.codehaus.org/x/IGU#DependencyMediationandConflictResolution-Scoperesolution
 I think that since the dependency management can now be used to control scopes 
and versions of all dependencies, including transitive dependencies, scope 
updates can simply be discarded. I took a look at various issues regarding 
transitive dependencies and this scope update thing really seems to be a work 
around for the missing manageArtifact() from the dependency management in 
previous releases. Also looking at all the changes of DefaultArtifactCollector 
I think updating the scope only was needed since dependency management could 
not be used ? What people were requesting was exactly what the testcase does. 
Getting a farther transitive dependency when the nearer would be excluded for 
some reason when the farther would not.  Also, if I get it right, the current 
code seems to not do, what the comments in the code state. Look at these code 
snippets from DefaultArtifactCollector:

if ( checkScopeUpdate( farthest, nearest, listeners ) )
{

Its the following comment which is confusing. It talks about an updated scope 
of the nearest artifact but then disables this updated node in favour of the 
farther!

// if we need to update scope of nearest to use 
farthest scope, use the nearest version, but farthest scope
nearest.disable(); <-- gets disabled although the scope 
got updated in checkScopeUpdate()
farthest.getArtifact().setVersion( 
nearest.getArtifact().getVersion() ); <-- nearest version is used and farthest 
scope since the farthest node is used, so the nearest node's scope would not 
have to get updated anyways ?
fireEvent( ResolutionListener.OMIT_FOR_NEARER, 
listeners, nearest, farthest.getArtifact() );
}

and in checkScopeUpdate():

if ( updateScope )
{
fireEvent( ResolutionListener.UPDATE_SCOPE, listeners, nearest, 
farthestArtifact );
nearestArtifact.setScope( farthestArtifact.getScope() );
}

So when in checkScopeUpdate() the condition to update the scope is true, the 
scope of the nearest artifact gets updated to the scope of the farthest - but 
in the code calling checkScopeUpdate the updated nearest node will not get used 
and gets disabled when this same condition holds true. This makes me think that 
the updated scope of the nearest node never played any role since the node gets 
disabled in favour of the farther which has the same scope the nearer got 
updated with. If I get it right the whole checkScopeUpdate() method could be 
discarded then and the node.filterTrail() method could be used similarly as 
done in my patch. Can someone please explain why this scope update thing got 
introduced and for what exactly it was needed ? Currently nodes which got 
theire scope updated will actually not get used so there really is no scope 
updating happening! It seems that it can be discarded in favour of 
node.filterTrail() without braking existing builds then. Looking at the code of 
DefaultArtifactCollector it seems that a node which got disabled once, will 
never get enabled again. If this is true, the checkScopeUpdate() method could 
be removed since all it does was forcing an update of the version of a farther 
node to the version of a nearer. Nearest version wins, but farther node gets 
used with the updated version of the nearer node. That's what the patch does 
when checkScopeUpdate() returns false. All it would have to do additionally 
would be to also update the version of the farther node with the one from the 
nearer, which it currently does not. I will prepare another patch for review.


> Nearest dependency, which is not included by a filter, wins, although a 
> farthest dependency, which is included by the same filter, does not win.
> 
>
> Key: MNG-3090
> URL: http://jira.codehaus.org/browse/MNG-3090
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.7
>Reporter: Christian Schulte
> Attachments: maven-artifact-2.0.x.patch, testcase.tar.bz2
>
>
> There seems to be a problem with transitive dependencies and the nearest wins 
> strategy. The nearest dependency wins, although a filter is in use which will 
> not include that dependency when there is the same dependency at a deeper 
> level, where it is included by the same filter. The nearest dependency gets 
> discarded (e.g. is missi

[jira] Updated: (MNG-3090) Nearest dependency, which is not included by a filter, wins, although a farthest dependency, which is included by the same filter, does not win.

[Christian Schulte (JIRA)]

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

Christian Schulte updated MNG-3090:
---

Attachment: MNG-3090.patch

Patch to additionally update the version of the farther node with that from the 
nearer.
After removing the checkScopeUpdateMethod() and taking a look at the testcases 
which then fail, it is now clear what the scope updates are needed for.


> Nearest dependency, which is not included by a filter, wins, although a 
> farthest dependency, which is included by the same filter, does not win.
> 
>
> Key: MNG-3090
> URL: http://jira.codehaus.org/browse/MNG-3090
> Project: Maven 2
>  Issue Type: Improvement
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.7
>Reporter: Christian Schulte
> Attachments: maven-artifact-2.0.x.patch, MNG-3090.patch, 
> testcase.tar.bz2
>
>
> There seems to be a problem with transitive dependencies and the nearest wins 
> strategy. The nearest dependency wins, although a filter is in use which will 
> not include that dependency when there is the same dependency at a deeper 
> level, where it is included by the same filter. The nearest dependency gets 
> discarded (e.g. is missing on the compile classpath) although the farthest 
> dependency would have been included. Please see the comments in the attached 
> patch.

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