[jira] (SUREFIRE-1118) Update surefire to not run any tests, if nothing has changed.

2014-11-15 Thread Christian Schulte (JIRA)
Christian Schulte created SUREFIRE-1118:
---

 Summary: Update surefire to not run any tests, if nothing has 
changed.
 Key: SUREFIRE-1118
 URL: https://jira.codehaus.org/browse/SUREFIRE-1118
 Project: Maven Surefire
  Issue Type: Wish
  Components: Maven Surefire Plugin
Reporter: Christian Schulte


Just like the 'maven-compiler-plugin' does not re-compile unchanged source code 
files

{code}
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) ---
[INFO] Nothing to compile - all classes are up to date
{code}

{code}
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) ---
[INFO] Nothing to compile - all classes are up to date
{code}

The 'maven-surefire-plugin' should not re-run any tests, if nothing has changed.




--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MJAVADOC-414) Artifacts missing from test classpath.

2014-11-13 Thread Christian Schulte (JIRA)

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

Christian Schulte reopened MJAVADOC-414:



Reopening since the plugin still does not produce correct test javadocs. Please 
see the updated example project demonstrating the issue. Executing 'mvn 
javadoc:test-javadoc' the plugin produces

{code}
1 warning
[WARNING] Javadoc Warnings
[WARNING] /tmp/MJAVADOC-414/src/test/java/localhost/test/AppTest.java:6: error: 
cannot find symbol
[WARNING] import localhost.App;
[WARNING] ^
[WARNING] symbol:   class App
[WARNING] location: package localhost
{code}

Downgrading the plugin to version 2.9.1, no such warnings are produced.


 Artifacts missing from test classpath.
 --

 Key: MJAVADOC-414
 URL: https://jira.codehaus.org/browse/MJAVADOC-414
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.10
 Environment: Apache Maven 3.2.3 
 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00)
 Java version: 1.7.0_65, vendor: Oracle Corporation
 Default locale: de_DE, platform encoding: UTF-8
Reporter: Christian Schulte
 Attachments: mjavadoc-414.zip


 Upgrading the javadoc plugin to version 2.10, test documentation fails to 
 find classpath elements from 'test' scope.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MJAVADOC-414) Artifacts missing from test classpath.

2014-11-13 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MJAVADOC-414:
---

Attachment: mjavadoc-414.zip

Updated the example project demonstrating the issue. Executing 'mvn 
javadoc:test-javadoc' plugin version 2.10.1 produces the following warning:

{code}
1 warning
[WARNING] Javadoc Warnings
[WARNING] /tmp/MJAVADOC-414/src/test/java/localhost/test/AppTest.java:6: error: 
cannot find symbol
[WARNING] import localhost.App;
[WARNING] ^
[WARNING] symbol:   class App
[WARNING] location: package localhost
{code}

Downgrading to version 2.9.1 no such warnings are produced.


 Artifacts missing from test classpath.
 --

 Key: MJAVADOC-414
 URL: https://jira.codehaus.org/browse/MJAVADOC-414
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.10
 Environment: Apache Maven 3.2.3 
 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00)
 Java version: 1.7.0_65, vendor: Oracle Corporation
 Default locale: de_DE, platform encoding: UTF-8
Reporter: Christian Schulte
 Attachments: mjavadoc-414.zip, mjavadoc-414.zip


 Upgrading the javadoc plugin to version 2.10, test documentation fails to 
 find classpath elements from 'test' scope.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MJAVADOC-414) Artifacts missing from test classpath.

2014-11-13 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MJAVADOC-414:
---

Affects Version/s: (was: 2.10)

 Artifacts missing from test classpath.
 --

 Key: MJAVADOC-414
 URL: https://jira.codehaus.org/browse/MJAVADOC-414
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.10.1
 Environment: Apache Maven 3.2.3 
 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00)
 Java version: 1.7.0_65, vendor: Oracle Corporation
 Default locale: de_DE, platform encoding: UTF-8
Reporter: Christian Schulte
 Attachments: mjavadoc-414.zip, mjavadoc-414.zip


 Upgrading the javadoc plugin to version 2.10, test documentation fails to 
 find classpath elements from 'test' scope.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MJAVADOC-414) Artifacts missing from test classpath.

2014-11-13 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MJAVADOC-414:
---

Affects Version/s: 2.10.1

 Artifacts missing from test classpath.
 --

 Key: MJAVADOC-414
 URL: https://jira.codehaus.org/browse/MJAVADOC-414
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.10.1
 Environment: Apache Maven 3.2.3 
 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00)
 Java version: 1.7.0_65, vendor: Oracle Corporation
 Default locale: de_DE, platform encoding: UTF-8
Reporter: Christian Schulte
 Attachments: mjavadoc-414.zip, mjavadoc-414.zip


 Upgrading the javadoc plugin to version 2.10, test documentation fails to 
 find classpath elements from 'test' scope.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MJAVADOC-414) Artifacts missing from test classpath.

2014-11-13 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MJAVADOC-414:
---

Description: Upgrading the javadoc plugin to version 2.10 or 2.10.1, test 
documentation fails to find classpath elements from 'test' scope.  (was: 
Upgrading the javadoc plugin to version 2.10, test documentation fails to find 
classpath elements from 'test' scope.)

 Artifacts missing from test classpath.
 --

 Key: MJAVADOC-414
 URL: https://jira.codehaus.org/browse/MJAVADOC-414
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.10.1
 Environment: Apache Maven 3.2.3 
 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00)
 Java version: 1.7.0_65, vendor: Oracle Corporation
 Default locale: de_DE, platform encoding: UTF-8
Reporter: Christian Schulte
 Attachments: mjavadoc-414.zip, mjavadoc-414.zip


 Upgrading the javadoc plugin to version 2.10 or 2.10.1, test documentation 
 fails to find classpath elements from 'test' scope.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MASSEMBLY-733) Plugin no longer prepends final name when packaging files specified using 'files/file' elements.

2014-11-13 Thread Christian Schulte (JIRA)
Christian Schulte created MASSEMBLY-733:
---

 Summary: Plugin no longer prepends final name when packaging files 
specified using 'files/file' elements.
 Key: MASSEMBLY-733
 URL: https://jira.codehaus.org/browse/MASSEMBLY-733
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.1
 Environment: $ mvn -version
Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 
2014-08-11T22:58:10+02:00)
Java version: 1.7.0_65, vendor: Oracle Corporation
Default locale: de_DE, platform encoding: UTF-8

Reporter: Christian Schulte






--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MASSEMBLY-733) Plugin no longer prepends final name when packaging files specified using 'files/file' elements.

2014-11-13 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MASSEMBLY-733:


Attachment: MASSEMBLY-733.zip

Example project demonstrating the issue. Executing 'mvn package', plugin 
version 2.5.1 creates the following directory structure in the archives:

{code}
$ unzip target/my-final-name-bin.zip 
Archive:  target/my-final-name-bin.zip
   creating: root/
  inflating: root/bin.xml
{code}

{code}
$ tar xfvz target/my-final-name-bin.tar.gz   
root/bin.xml
{code}

{code}
$ tar xfvj target/my-final-name-bin.tar.bz2
root/bin.xml
{code}

Downgrading the plugin to version 2.4.1, the correct directory structure is 
created:

{code}
$ unzip target/my-final-name-bin.zip
Archive:  target/my-final-name-bin.zip
   creating: my-final-name/
   creating: my-final-name/root/
  inflating: my-final-name/root/bin.xml 
{code}

{code}
$ tar xfvz target/my-final-name-bin.tar.gz   
my-final-name/root/bin.xml
{code}

{code}
$ tar xfvj target/my-final-name-bin.tar.bz2
my-final-name/root/bin.xml
{code}

Directory 'my-final-name' is missing using version 2.5.1.

 Plugin no longer prepends final name when packaging files specified using 
 'files/file' elements.
 

 Key: MASSEMBLY-733
 URL: https://jira.codehaus.org/browse/MASSEMBLY-733
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.1
 Environment: $ mvn -version
 Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 
 2014-08-11T22:58:10+02:00)
 Java version: 1.7.0_65, vendor: Oracle Corporation
 Default locale: de_DE, platform encoding: UTF-8
Reporter: Christian Schulte
 Attachments: MASSEMBLY-733.zip






--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MJAVADOC-414) Artifacts missing from test classpath.

2014-09-26 Thread Christian Schulte (JIRA)
Christian Schulte created MJAVADOC-414:
--

 Summary: Artifacts missing from test classpath.
 Key: MJAVADOC-414
 URL: https://jira.codehaus.org/browse/MJAVADOC-414
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.10
 Environment: Apache Maven 3.2.3 
(33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00)
Java version: 1.7.0_65, vendor: Oracle Corporation
Default locale: de_DE, platform encoding: UTF-8

Reporter: Christian Schulte


Upgrading the javadoc plugin to version 2.10, test documentation fails to find 
classpath elements from 'test' scope.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MJAVADOC-414) Artifacts missing from test classpath.

2014-09-26 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MJAVADOC-414:
---

Attachment: mjavadoc-414.zip

Example project demonstrating the issue. Executing 'mvn javadoc:test-javadoc' 
produces the following warnings.

{code}
5 warnings
[WARNING] Javadoc Warnings
[WARNING] /tmp/mjavadoc-414/src/test/java/localhost/AppTest.java:3: error: 
package junit.framework does not exist
[WARNING] import junit.framework.Test;
[WARNING] ^
[WARNING] /tmp/mjavadoc-414/src/test/java/localhost/AppTest.java:4: error: 
package junit.framework does not exist
[WARNING] import junit.framework.TestCase;
[WARNING] ^
[WARNING] /tmp/mjavadoc-414/src/test/java/localhost/AppTest.java:5: error: 
package junit.framework does not exist
[WARNING] import junit.framework.TestSuite;
[WARNING] ^
[WARNING] /tmp/mjavadoc-414/src/test/java/localhost/AppTest.java:11: error: 
cannot find symbol
[WARNING] extends TestCase
[WARNING] ^
[WARNING] symbol: class TestCase
[WARNING] /tmp/mjavadoc-414/src/test/java/localhost/AppTest.java:26: error: 
cannot find symbol
[WARNING] public static Test suite()
[WARNING] ^
[WARNING] symbol:   class Test
[WARNING] location: class AppTest
{code}

Downgrading the plugin to version '2.9.1' solves the issue.

 Artifacts missing from test classpath.
 --

 Key: MJAVADOC-414
 URL: https://jira.codehaus.org/browse/MJAVADOC-414
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.10
 Environment: Apache Maven 3.2.3 
 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00)
 Java version: 1.7.0_65, vendor: Oracle Corporation
 Default locale: de_DE, platform encoding: UTF-8
Reporter: Christian Schulte
 Attachments: mjavadoc-414.zip


 Upgrading the javadoc plugin to version 2.10, test documentation fails to 
 find classpath elements from 'test' scope.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MSITE-724) An API incompatibility was encountered while executing org.apache.maven.plugins:maven-site-plugin:3.4:jar

2014-07-12 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MSITE-724:


Attachment: pom.xml

Example project demonstrating the issue. Executing 'mvn package', the exception 
is thrown. Manually upgrading the dependency on 'maven-archiver' to '2.5' 
building succeeds.


 An API incompatibility was encountered while executing 
 org.apache.maven.plugins:maven-site-plugin:3.4:jar
 -

 Key: MSITE-724
 URL: https://jira.codehaus.org/browse/MSITE-724
 Project: Maven Site Plugin
  Issue Type: Bug
Affects Versions: 3.4
Reporter: Christian Schulte
Priority: Blocker
 Attachments: pom.xml


 {code}
 Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
 default-jar of goal org.apache.maven.plugins:maven-site-plugin:3.4:jar 
 failed: An API incompatibility was encountered while executing 
 org.apache.maven.plugins:maven-site-plugin:3.4:jar: 
 java.lang.NoSuchMethodError: 
 org.codehaus.plexus.archiver.jar.Manifest.getMainSection()Lorg/codehaus/plexus/archiver/jar/Manifest$Section;
 {code}
 {code}
 Caused by: java.lang.NoSuchMethodError: 
 org.codehaus.plexus.archiver.jar.Manifest.getMainSection()Lorg/codehaus/plexus/archiver/jar/Manifest$Section;
 at 
 org.apache.maven.archiver.MavenArchiver.getManifest(MavenArchiver.java:102)
 at 
 org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:513)
 at 
 org.apache.maven.plugins.site.render.SiteJarMojo.createArchive(SiteJarMojo.java:201)
 at 
 org.apache.maven.plugins.site.render.SiteJarMojo.execute(SiteJarMojo.java:130)
 at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
 ... 20 more
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MSITE-724) An API incompatibility was encountered while executing org.apache.maven.plugins:maven-site-plugin:3.4:jar

2014-07-12 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MSITE-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=349572#comment-349572
 ] 

Christian Schulte commented on MSITE-724:
-

{code}
Apache Maven 3.2.2 (45f7c06d68e745d05611f7fd14efb6594181933e; 
2014-06-17T15:51:42+02:00)
Java version: 1.7.0_55, vendor: Oracle Corporation
Default locale: de_DE, platform encoding: UTF-8
{code}


 An API incompatibility was encountered while executing 
 org.apache.maven.plugins:maven-site-plugin:3.4:jar
 -

 Key: MSITE-724
 URL: https://jira.codehaus.org/browse/MSITE-724
 Project: Maven Site Plugin
  Issue Type: Bug
Affects Versions: 3.4
Reporter: Christian Schulte
Priority: Blocker
 Attachments: pom.xml


 {code}
 Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
 default-jar of goal org.apache.maven.plugins:maven-site-plugin:3.4:jar 
 failed: An API incompatibility was encountered while executing 
 org.apache.maven.plugins:maven-site-plugin:3.4:jar: 
 java.lang.NoSuchMethodError: 
 org.codehaus.plexus.archiver.jar.Manifest.getMainSection()Lorg/codehaus/plexus/archiver/jar/Manifest$Section;
 {code}
 {code}
 Caused by: java.lang.NoSuchMethodError: 
 org.codehaus.plexus.archiver.jar.Manifest.getMainSection()Lorg/codehaus/plexus/archiver/jar/Manifest$Section;
 at 
 org.apache.maven.archiver.MavenArchiver.getManifest(MavenArchiver.java:102)
 at 
 org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:513)
 at 
 org.apache.maven.plugins.site.render.SiteJarMojo.createArchive(SiteJarMojo.java:201)
 at 
 org.apache.maven.plugins.site.render.SiteJarMojo.execute(SiteJarMojo.java:130)
 at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
 ... 20 more
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MSITE-724) An API incompatibility was encountered while executing org.apache.maven.plugins:maven-site-plugin:3.4:jar

2014-07-12 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MSITE-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=349574#comment-349574
 ] 

Christian Schulte commented on MSITE-724:
-

Thank you.

 An API incompatibility was encountered while executing 
 org.apache.maven.plugins:maven-site-plugin:3.4:jar
 -

 Key: MSITE-724
 URL: https://jira.codehaus.org/browse/MSITE-724
 Project: Maven Site Plugin
  Issue Type: Bug
Affects Versions: 3.4
Reporter: Christian Schulte
Priority: Blocker
 Attachments: pom.xml


 {code}
 Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
 default-jar of goal org.apache.maven.plugins:maven-site-plugin:3.4:jar 
 failed: An API incompatibility was encountered while executing 
 org.apache.maven.plugins:maven-site-plugin:3.4:jar: 
 java.lang.NoSuchMethodError: 
 org.codehaus.plexus.archiver.jar.Manifest.getMainSection()Lorg/codehaus/plexus/archiver/jar/Manifest$Section;
 {code}
 {code}
 Caused by: java.lang.NoSuchMethodError: 
 org.codehaus.plexus.archiver.jar.Manifest.getMainSection()Lorg/codehaus/plexus/archiver/jar/Manifest$Section;
 at 
 org.apache.maven.archiver.MavenArchiver.getManifest(MavenArchiver.java:102)
 at 
 org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:513)
 at 
 org.apache.maven.plugins.site.render.SiteJarMojo.createArchive(SiteJarMojo.java:201)
 at 
 org.apache.maven.plugins.site.render.SiteJarMojo.execute(SiteJarMojo.java:130)
 at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
 ... 20 more
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MSITE-724) An API incompatibility was encountered while executing org.apache.maven.plugins:maven-site-plugin:3.4:jar

2014-07-11 Thread Christian Schulte (JIRA)
Christian Schulte created MSITE-724:
---

 Summary: An API incompatibility was encountered while executing 
org.apache.maven.plugins:maven-site-plugin:3.4:jar
 Key: MSITE-724
 URL: https://jira.codehaus.org/browse/MSITE-724
 Project: Maven Site Plugin
  Issue Type: Bug
Affects Versions: 3.4
Reporter: Christian Schulte
Priority: Blocker


{code}
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
default-jar of goal org.apache.maven.plugins:maven-site-plugin:3.4:jar failed: 
An API incompatibility was encountered while executing 
org.apache.maven.plugins:maven-site-plugin:3.4:jar: 
java.lang.NoSuchMethodError: 
org.codehaus.plexus.archiver.jar.Manifest.getMainSection()Lorg/codehaus/plexus/archiver/jar/Manifest$Section;
{code}

{code}
Caused by: java.lang.NoSuchMethodError: 
org.codehaus.plexus.archiver.jar.Manifest.getMainSection()Lorg/codehaus/plexus/archiver/jar/Manifest$Section;
at 
org.apache.maven.archiver.MavenArchiver.getManifest(MavenArchiver.java:102)
at 
org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:513)
at 
org.apache.maven.plugins.site.render.SiteJarMojo.createArchive(SiteJarMojo.java:201)
at 
org.apache.maven.plugins.site.render.SiteJarMojo.execute(SiteJarMojo.java:130)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
... 20 more
{code}





--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MCHECKSTYLE-208) The plugin generates reports incompatible with the 'maven-jxr-plugin' version 2.4.

2014-01-30 Thread Christian Schulte (JIRA)
Christian Schulte created MCHECKSTYLE-208:
-

 Summary: The plugin generates reports incompatible with the 
'maven-jxr-plugin' version 2.4.
 Key: MCHECKSTYLE-208
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-208
 Project: Maven Checkstyle Plugin
  Issue Type: Bug
Reporter: Christian Schulte






--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MPMD-179) The plugin generates reports incompatible with the 'maven-jxr-plugin' version 2.4.

2014-01-30 Thread Christian Schulte (JIRA)
Christian Schulte created MPMD-179:
--

 Summary: The plugin generates reports incompatible with the 
'maven-jxr-plugin' version 2.4.
 Key: MPMD-179
 URL: https://jira.codehaus.org/browse/MPMD-179
 Project: Maven PMD Plugin
  Issue Type: Bug
Reporter: Christian Schulte






--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MJARSIGNER-34) The 'verify' goal of the plugin is passing '-keystore' but not '-storetype'.

2014-01-09 Thread Christian Schulte (JIRA)
Christian Schulte created MJARSIGNER-34:
---

 Summary: The 'verify' goal of the plugin is passing '-keystore' 
but not '-storetype'.
 Key: MJARSIGNER-34
 URL: https://jira.codehaus.org/browse/MJARSIGNER-34
 Project: Maven Jar Signer Plugin
  Issue Type: Bug
Affects Versions: 1.3.1
Reporter: Christian Schulte
Priority: Blocker


Upgrading the 'maven-jarsigner-plugin' from version 1.2 to version 1.3.1, the 
plugin stops working. In version 1.2, the 'verify' goal did not pass 
'-keystore' to 'jarsigner'. As of version 1.3, the 'verify' goal passes 
'-keystore' to 'jarsigner' but does not pass '-storetype' which makes the 
'verify' goal fail with:

jarsigner error: keystore load: Invalid keystore format

due to

{xml}
jarsigner.storetypepkcs12/jarsigner.storetype
{xml}


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] (JXR-107) Line number anchor names have changed in an incompatible way.

2014-01-09 Thread Christian Schulte (JIRA)
Christian Schulte created JXR-107:
-

 Summary: Line number anchor names have changed in an incompatible 
way.
 Key: JXR-107
 URL: https://jira.codehaus.org/browse/JXR-107
 Project: Maven JXR
  Issue Type: Bug
  Components: maven2 jxr plugin
Affects Versions: 2.4
Reporter: Christian Schulte


Upgrading the 'maven-jxr-plugin' to version 2.4 breaks reports generated by 
other reporting plugins due to the line number anchor names changing from e.g. 
'#1' to '#L1'. The old anchor names should be generated again instead.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] (MSITE-665) Site plugin version 3.2 seems to modify a project's classpath.

2013-09-17 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MSITE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=332939#comment-332939
 ] 

Christian Schulte commented on MSITE-665:
-

Could someone please perform a release of the site plugin with the attached 
patch applied ? It is a regression and is blocking the upgrade to Maven 3.1.x.


 Site plugin version 3.2 seems to modify a project's classpath.
 --

 Key: MSITE-665
 URL: https://jira.codehaus.org/browse/MSITE-665
 Project: Maven Site Plugin
  Issue Type: Bug
Affects Versions: 3.2
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
 Java version: 1.7.0_03, vendor: Oracle Corporation
Reporter: Christian Schulte
 Attachments: MSITE-665.patch, MSITE-665.zip, msp-3.1.log, msp-3.2.log




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] (MNG-2199) Version ranges not supported for parent artifacts

2013-06-05 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MNG-2199:
---

Attachment: MNG-2199-3.1.0-alpha-1.patch

Patch for Maven 3.1.0-alpha-1. Final version.


 Version ranges not supported for parent artifacts
 -

 Key: MNG-2199
 URL: https://jira.codehaus.org/browse/MNG-2199
 Project: Maven 2  3
  Issue Type: Wish
  Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 2.0.3
Reporter: Christian Schulte
 Fix For: 3.1.1

 Attachments: MNG-2199-3.0.4.patch, MNG-2199-3.0.4.patch, 
 MNG-2199-3.1.0-alpha-1.patch, MNG-2199.patch, MNG-2199.patch, MNG-2199.patch, 
 MNG-2199.patch, MNG-2199.patch, MNG-2199.patch


 It would be great if Maven supports version ranges when specifying parent 
 artifacts in a multi-module build. Currently this does not work.
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, 2.0.1]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 2.0.1]/artifactId-[2.0, 2.0.1].pom
 Additionally it would be great if this
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, ${pom.version}]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 ${pom.version}]/artifactId-[2.0, ${pom.version}].pom
 would also work, if the version is specified in the same pom.xml which 
 defines this parent definition.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] (MSITE-665) Site plugin version 3.2 seems to modify a project's classpath.

2013-05-28 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MSITE-665:


Attachment: MSITE-665.patch

Patch adding missing

{code:xml}
requiresDependencyResolutiontest/requiresDependencyResolution
{code}

to the 'jar' goal.



 Site plugin version 3.2 seems to modify a project's classpath.
 --

 Key: MSITE-665
 URL: https://jira.codehaus.org/browse/MSITE-665
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
Affects Versions: 3.2
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
 Java version: 1.7.0_03, vendor: Oracle Corporation
Reporter: Christian Schulte
 Attachments: MSITE-665.patch, MSITE-665.zip, msp-3.1.log, msp-3.2.log




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] (MPIR-229) The 'modules' report does not support 'url' elements using properties.

2013-05-10 Thread Christian Schulte (JIRA)

 [ 
https://jira.codehaus.org/browse/MPIR-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MPIR-229:
---

Attachment: MPIR-229.patch

Patch updating the IT to demonstrate the issue. Applying this patch and 
executing 'mvn verify -Prun-its', the generated 
'target/it/mpir-229/target/site/modules.html' file contains the following 
broken link.

{code}
a href=$%7Bproject.artifactId%7D-$%7Bproject.version%7D/index.htmlnull/a
{code}


 The 'modules' report does not support 'url' elements using properties.
 --

 Key: MPIR-229
 URL: https://jira.codehaus.org/browse/MPIR-229
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Bug
  Components: modules
Affects Versions: 2.4
Reporter: Christian Schulte
 Attachments: MPIR-229.patch


 The 'modules' report does not support 'url' elements using properties.
 {code:xml}
 url${some.property}/${project.artifactId}-${project.version}/url
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] (MNG-2199) Version ranges not supported for parent artifacts

2012-11-19 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MNG-2199:
---

Attachment: MNG-2199-3.0.4.patch
MNG-2199.patch

Updated patches to handle unavailable versions for a given range.


 Version ranges not supported for parent artifacts
 -

 Key: MNG-2199
 URL: https://jira.codehaus.org/browse/MNG-2199
 Project: Maven 2  3
  Issue Type: Wish
  Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 2.0.3
Reporter: Christian Schulte
 Fix For: 3.1.1

 Attachments: MNG-2199-3.0.4.patch, MNG-2199-3.0.4.patch, 
 MNG-2199.patch, MNG-2199.patch, MNG-2199.patch, MNG-2199.patch, 
 MNG-2199.patch, MNG-2199.patch


 It would be great if Maven supports version ranges when specifying parent 
 artifacts in a multi-module build. Currently this does not work.
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, 2.0.1]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 2.0.1]/artifactId-[2.0, 2.0.1].pom
 Additionally it would be great if this
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, ${pom.version}]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 ${pom.version}]/artifactId-[2.0, ${pom.version}].pom
 would also work, if the version is specified in the same pom.xml which 
 defines this parent definition.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MNG-5379) Site plugin version 3.2 seems to modify a project's classpath.

2012-11-16 Thread Christian Schulte (JIRA)
Christian Schulte created MNG-5379:
--

 Summary: Site plugin version 3.2 seems to modify a project's 
classpath.
 Key: MNG-5379
 URL: https://jira.codehaus.org/browse/MNG-5379
 Project: Maven 2  3
  Issue Type: Bug
  Components: General
Affects Versions: 3.2
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Java version: 1.7.0_03, vendor: Oracle Corporation

Reporter: Christian Schulte
Priority: Blocker




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MNG-5379) Site plugin version 3.2 seems to modify a project's classpath.

2012-11-16 Thread Christian Schulte (JIRA)

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

Christian Schulte closed MNG-5379.
--

Resolution: Won't Fix

Accidentally reported against Maven itself. Issue belongs to Maven Site plugin.


 Site plugin version 3.2 seems to modify a project's classpath.
 --

 Key: MNG-5379
 URL: https://jira.codehaus.org/browse/MNG-5379
 Project: Maven 2  3
  Issue Type: Bug
  Components: General
Affects Versions: 3.2
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
 Java version: 1.7.0_03, vendor: Oracle Corporation
Reporter: Christian Schulte
Priority: Blocker



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSITE-665) Site plugin version 3.2 seems to modify a project's classpath.

2012-11-16 Thread Christian Schulte (JIRA)
Christian Schulte created MSITE-665:
---

 Summary: Site plugin version 3.2 seems to modify a project's 
classpath.
 Key: MSITE-665
 URL: https://jira.codehaus.org/browse/MSITE-665
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
Affects Versions: 3.2
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Java version: 1.7.0_03, vendor: Oracle Corporation

Reporter: Christian Schulte
Priority: Blocker




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSITE-665) Site plugin version 3.2 seems to modify a project's classpath.

2012-11-16 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MSITE-665:


Attachment: MSITE-665.zip

Example project demonstrating the issue. Executing 'mvn package' produces the 
following warnings during 'Generating Test JavaDocs report'.

{code}
10 warnings
[WARNING] Javadoc Warnings
[WARNING] /tmp/MSITE-665/src/test/java/msite665/AppTest.java:3: error: package 
org.junit does not exist
[WARNING] import org.junit.Test;
[WARNING] ^
[WARNING] /tmp/MSITE-665/src/test/java/msite665/AppTest.java:4: error: package 
org.junit does not exist
[WARNING] import static org.junit.Assert.assertTrue;
[WARNING] ^
[WARNING] /tmp/MSITE-665/src/test/java/msite665/AppTest.java:4: error: static 
import only from classes and interfaces
[WARNING] import static org.junit.Assert.assertTrue;
[WARNING] ^
[WARNING] /tmp/MSITE-665/src/test/java/msite665/AppTest.java:15: error: cannot 
find symbol
[WARNING] @Test
[WARNING] ^
[WARNING] symbol:   class Test
[WARNING] location: class AppTest
[WARNING] javadoc: warning - Class Test not found.
[WARNING] javadoc: warning - Class Test not found.
[WARNING] javadoc: warning - Class Test not found.
[WARNING] javadoc: warning - Class Test not found.
[WARNING] javadoc: warning - Class Test not found.
[WARNING] javadoc: warning - Class Test not found.
{code}

Downgrading the site plugin from 3.2 to 3.1 no such warnings are shown. 


 Site plugin version 3.2 seems to modify a project's classpath.
 --

 Key: MSITE-665
 URL: https://jira.codehaus.org/browse/MSITE-665
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
Affects Versions: 3.2
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
 Java version: 1.7.0_03, vendor: Oracle Corporation
Reporter: Christian Schulte
Priority: Blocker
 Attachments: MSITE-665.zip




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSITE-665) Site plugin version 3.2 seems to modify a project's classpath.

2012-11-16 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MSITE-665:


Attachment: msp-3.1.log

Output executing 'mvn package' with 'maven-site-plugin-3.1'.


 Site plugin version 3.2 seems to modify a project's classpath.
 --

 Key: MSITE-665
 URL: https://jira.codehaus.org/browse/MSITE-665
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
Affects Versions: 3.2
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
 Java version: 1.7.0_03, vendor: Oracle Corporation
Reporter: Christian Schulte
Priority: Blocker
 Attachments: MSITE-665.zip, msp-3.1.log




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSITE-665) Site plugin version 3.2 seems to modify a project's classpath.

2012-11-16 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MSITE-665:


Attachment: msp-3.2.log

Output executing 'mvn package' with 'maven-site-plugin-3.2'.


 Site plugin version 3.2 seems to modify a project's classpath.
 --

 Key: MSITE-665
 URL: https://jira.codehaus.org/browse/MSITE-665
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
Affects Versions: 3.2
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
 Java version: 1.7.0_03, vendor: Oracle Corporation
Reporter: Christian Schulte
Priority: Blocker
 Attachments: MSITE-665.zip, msp-3.1.log, msp-3.2.log




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MNG-2199) Version ranges not supported for parent artifacts

2012-10-23 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MNG-2199:
---

Attachment: MNG-2199.patch

Updated patch (class 'org.apache.maven.project.MavenProject' needed updating to 
also allow parent version ranges.)

 Version ranges not supported for parent artifacts
 -

 Key: MNG-2199
 URL: https://jira.codehaus.org/browse/MNG-2199
 Project: Maven 2  3
  Issue Type: Wish
  Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 2.0.3
Reporter: Christian Schulte
 Fix For: Issues to be reviewed for 3.x

 Attachments: MNG-2199.patch, MNG-2199.patch, MNG-2199.patch, 
 MNG-2199.patch, MNG-2199.patch


 It would be great if Maven supports version ranges when specifying parent 
 artifacts in a multi-module build. Currently this does not work.
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, 2.0.1]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 2.0.1]/artifactId-[2.0, 2.0.1].pom
 Additionally it would be great if this
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, ${pom.version}]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 ${pom.version}]/artifactId-[2.0, ${pom.version}].pom
 would also work, if the version is specified in the same pom.xml which 
 defines this parent definition.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MNG-2199) Version ranges not supported for parent artifacts

2012-10-23 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MNG-2199:
---

Attachment: MNG-2199-3.0.4.patch

Patch for Maven 3.0.4.

 Version ranges not supported for parent artifacts
 -

 Key: MNG-2199
 URL: https://jira.codehaus.org/browse/MNG-2199
 Project: Maven 2  3
  Issue Type: Wish
  Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 2.0.3
Reporter: Christian Schulte
 Fix For: Issues to be reviewed for 3.x

 Attachments: MNG-2199-3.0.4.patch, MNG-2199.patch, MNG-2199.patch, 
 MNG-2199.patch, MNG-2199.patch, MNG-2199.patch


 It would be great if Maven supports version ranges when specifying parent 
 artifacts in a multi-module build. Currently this does not work.
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, 2.0.1]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 2.0.1]/artifactId-[2.0, 2.0.1].pom
 Additionally it would be great if this
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, ${pom.version}]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 ${pom.version}]/artifactId-[2.0, ${pom.version}].pom
 would also work, if the version is specified in the same pom.xml which 
 defines this parent definition.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSITE-659) 'relativizeDecorationLinks' relativizes too much.

2012-10-14 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MSITE-659:


Attachment: MSITE-659-absolute.zip

Another example project demonstrating the issue. Unzip and execute 'mvn site'. 
Open 'target/site/index.html' from the parent project in a browser. The 'Inside 
Parent Jar' link got relativized correctly - that link is working ok at the 
deployed location and also inside the parent jar file. Now open the 
'child/target/site/index.html' from the child project in a browser. The 
inherited 'Inside Parent Jar' link got relativized correctly but that link only 
works when actually deployed to a web server. It is not working inside the jar 
where it should be an absolute link. Absolute link in the jar - relative link 
in the deployed web site. Now repeat the above with the 
'relativizeDecorationLinks' parameter set to 'false' (mvn clean site 
-DrelativizeDecorationLinks=false). The 'Inside Parent Jar' link in the 
'target/site/index.html' from the parent site now is kept absolute. This is 
kind of useless in the parent site jar and in the deployed web site. That same 
link in the 'child/target/site/index.html' from the child site is absolute in 
the child. That link now is working in the child site jar file (when unzipped 
and used locally) but is again kind of useless in the deployed web site.

To sum this up. There is nothing wrong with the 'relativizeDecorationLinks' 
feature when building a web-site you are actually going to deploy somewhere. 
The problem is when building a jar for use locally. Relative links pointing 
outside the jar file will not work there and need to be kept absolute and 
absolute links which are pointing to content inside the jar file should be 
relative otherwise the jar is quite useless.



 'relativizeDecorationLinks' relativizes too much.
 -

 Key: MSITE-659
 URL: https://jira.codehaus.org/browse/MSITE-659
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: relative links
Affects Versions: 3.1
Reporter: Christian Schulte
 Attachments: MSITE-659-absolute.zip, MSITE-659.zip, MSITE-659.zip


 When relativizing links, the plugin produces relative links to content not 
 generated by the plugin which should be kept absolute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSITE-659) 'relativizeDecorationLinks' relativizes too much.

2012-10-14 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MSITE-659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311442#comment-311442
 ] 

Christian Schulte commented on MSITE-659:
-

Put another way. Specifying relative links in the decoration model, inheriting 
them as absolute is not possible. Specifying absolute links in the decoration 
model, using 'relativizeDecorationLinks' is not possible since that will 
relativize at the 'child' level in a way links will not work when browsing that 
site locally (unzipped jar). Building a site for deployment and building a site 
for browsing locally (unzipped jar) would need to be handled differently to get 
this working. Let the jar goal update links in a way compatible with local 
browsing ('absolutizeDecorationLinks') and let the site goal update links in a 
way compatible with online browsing (already implemented).


 'relativizeDecorationLinks' relativizes too much.
 -

 Key: MSITE-659
 URL: https://jira.codehaus.org/browse/MSITE-659
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: relative links
Affects Versions: 3.1
Reporter: Christian Schulte
 Attachments: MSITE-659-absolute.zip, MSITE-659.zip, MSITE-659.zip


 When relativizing links, the plugin produces relative links to content not 
 generated by the plugin which should be kept absolute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSITE-659) 'relativizeDecorationLinks' relativizes too much.

2012-10-14 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MSITE-659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311445#comment-311445
 ] 

Christian Schulte commented on MSITE-659:
-

This is a request to add a new 'site:offline-jar' goal supporting the use case 
mentioned above then :-).

 'relativizeDecorationLinks' relativizes too much.
 -

 Key: MSITE-659
 URL: https://jira.codehaus.org/browse/MSITE-659
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: relative links
Affects Versions: 3.1
Reporter: Christian Schulte
 Attachments: MSITE-659-absolute.zip, MSITE-659.zip, MSITE-659.zip


 When relativizing links, the plugin produces relative links to content not 
 generated by the plugin which should be kept absolute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSITE-659) 'relativizeDecorationLinks' relativizes too much.

2012-10-13 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MSITE-659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311420#comment-311420
 ] 

Christian Schulte commented on MSITE-659:
-

This issue seems to only affect the 'site:jar' goal in combination with 
decoration model inheritance. Building a parent site jar, absolute links from 
the parent 'site.xml' should be made relative. Inherited to a child, they 
should be kept absolute there. Maybe the 'site:jar' goal needs a new parameter 
'absolutizeDecorationLinks' so that it is possible to use relative links in all 
'site.xml' files and make the 'site:jar' goal update all references to files 
outside the jar currently being built to absolute paths ?


 'relativizeDecorationLinks' relativizes too much.
 -

 Key: MSITE-659
 URL: https://jira.codehaus.org/browse/MSITE-659
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: relative links
Affects Versions: 3.1
Reporter: Christian Schulte
 Attachments: MSITE-659.zip, MSITE-659.zip


 When relativizing links, the plugin produces relative links to content not 
 generated by the plugin which should be kept absolute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSITE-658) 'relativizeDecorationLinks' not working using multiple 'locales'.

2012-10-10 Thread Christian Schulte (JIRA)
Christian Schulte created MSITE-658:
---

 Summary: 'relativizeDecorationLinks' not working using multiple 
'locales'.
 Key: MSITE-658
 URL: https://jira.codehaus.org/browse/MSITE-658
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: relative links
Affects Versions: 3.1
Reporter: Christian Schulte
Priority: Critical


The plugin does not take into account that output will be generated to 
sub-directories of the location specified by the project URL for all 
non-default languages setup using the 'locales' parameter and produces 
incorrect relative links in all non-default language pages.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSITE-658) 'relativizeDecorationLinks' not working using multiple 'locales'.

2012-10-10 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MSITE-658:


Attachment: MSITE-658.zip

Example project demonstrating the issue.

Execute 'mvn site' and open the 'target/site/de/dependencies.html' page in a 
browser. Clicking the 'Home' link in the navigation yields a file not found 
error due to an incorrect relative link.


 'relativizeDecorationLinks' not working using multiple 'locales'.
 -

 Key: MSITE-658
 URL: https://jira.codehaus.org/browse/MSITE-658
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: relative links
Affects Versions: 3.1
Reporter: Christian Schulte
Priority: Critical
 Attachments: MSITE-658.zip


 The plugin does not take into account that output will be generated to 
 sub-directories of the location specified by the project URL for all 
 non-default languages setup using the 'locales' parameter and produces 
 incorrect relative links in all non-default language pages.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSITE-658) 'relativizeDecorationLinks' not working using multiple 'locales'.

2012-10-10 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MSITE-658:


Attachment: MSITE-658.patch

Patch correcting the issue.

 'relativizeDecorationLinks' not working using multiple 'locales'.
 -

 Key: MSITE-658
 URL: https://jira.codehaus.org/browse/MSITE-658
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: relative links
Affects Versions: 3.1
Reporter: Christian Schulte
Priority: Critical
 Attachments: MSITE-658.patch, MSITE-658.zip


 The plugin does not take into account that output will be generated to 
 sub-directories of the location specified by the project URL for all 
 non-default languages setup using the 'locales' parameter and produces 
 incorrect relative links in all non-default language pages.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSITE-659) 'relativizeDecorationLinks' relativizes too much.

2012-10-10 Thread Christian Schulte (JIRA)
Christian Schulte created MSITE-659:
---

 Summary: 'relativizeDecorationLinks' relativizes too much.
 Key: MSITE-659
 URL: https://jira.codehaus.org/browse/MSITE-659
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: relative links
Affects Versions: 3.1
Reporter: Christian Schulte


When relativizing links, the plugin produces relative links to content not 
generated by the plugin which should be kept absolute.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSITE-659) 'relativizeDecorationLinks' relativizes too much.

2012-10-10 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MSITE-659:


Attachment: MSITE-659.zip

Example project demonstrating the issue.

Execute 'mvn site' and open the 'target/site/index.html' page in a browser. The 
'Outside Jar' link in the navigation should be an absolute link.



 'relativizeDecorationLinks' relativizes too much.
 -

 Key: MSITE-659
 URL: https://jira.codehaus.org/browse/MSITE-659
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: relative links
Affects Versions: 3.1
Reporter: Christian Schulte
 Attachments: MSITE-659.zip


 When relativizing links, the plugin produces relative links to content not 
 generated by the plugin which should be kept absolute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSITE-659) 'relativizeDecorationLinks' relativizes too much.

2012-10-10 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MSITE-659:


Attachment: MSITE-659.zip

Updated the example project.

This issue mainly affects the 'site:jar' goal. See the generated navigation. 
The 'Inside Jar' link correctly points to content inside the jar file, the 
'Outside Jar' link incorrectly points to content outside the jar file.


 'relativizeDecorationLinks' relativizes too much.
 -

 Key: MSITE-659
 URL: https://jira.codehaus.org/browse/MSITE-659
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: relative links
Affects Versions: 3.1
Reporter: Christian Schulte
 Attachments: MSITE-659.zip, MSITE-659.zip


 When relativizing links, the plugin produces relative links to content not 
 generated by the plugin which should be kept absolute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MJAVADOC-355) Encoding problem if platform encoding used to run Maven is different from default platform encoding.

2012-10-02 Thread Christian Schulte (JIRA)
Christian Schulte created MJAVADOC-355:
--

 Summary: Encoding problem if platform encoding used to run Maven 
is different from default platform encoding. 
 Key: MJAVADOC-355
 URL: https://jira.codehaus.org/browse/MJAVADOC-355
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Wish
Affects Versions: 2.9
Reporter: Christian Schulte
Priority: Trivial


When setting up a platform encoding in MAVEN_OPTS (e.g. 
'-Dfile.encoding=UTF-8'), the plugin writes command line argument files using 
that encoding. This encoding is not preserved when executing Javadoc which then 
reads these command line files using the real platform encoding. The platform 
encoding Maven is running with needs to be preserved in Javadoc.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MJAVADOC-355) Encoding problem if platform encoding used to run Maven is different from default platform encoding.

2012-10-02 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MJAVADOC-355:
---

Attachment: MJAVADOC-355.patch

Patch passing the platform encoding to Javadoc.

 Encoding problem if platform encoding used to run Maven is different from 
 default platform encoding. 
 -

 Key: MJAVADOC-355
 URL: https://jira.codehaus.org/browse/MJAVADOC-355
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Wish
Affects Versions: 2.9
Reporter: Christian Schulte
Priority: Trivial
 Attachments: MJAVADOC-355.patch


 When setting up a platform encoding in MAVEN_OPTS (e.g. 
 '-Dfile.encoding=UTF-8'), the plugin writes command line argument files using 
 that encoding. This encoding is not preserved when executing Javadoc which 
 then reads these command line files using the real platform encoding. The 
 platform encoding Maven is running with needs to be preserved in Javadoc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (DOXIASITETOOLS-76) Missing inheritance of 'googleAdSenseClient', 'googleAdSenseSlot' and 'googleAnalyticsAccountId' elements.

2012-10-02 Thread Christian Schulte (JIRA)
Christian Schulte created DOXIASITETOOLS-76:
---

 Summary: Missing inheritance of 'googleAdSenseClient', 
'googleAdSenseSlot' and 'googleAnalyticsAccountId' elements.
 Key: DOXIASITETOOLS-76
 URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-76
 Project: Maven Doxia Sitetools
  Issue Type: Bug
  Components: Decoration model
Affects Versions: 1.3
Reporter: Christian Schulte




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (DOXIASITETOOLS-76) Missing inheritance of 'googleAdSenseClient', 'googleAdSenseSlot' and 'googleAnalyticsAccountId' elements.

2012-10-02 Thread Christian Schulte (JIRA)

 [ 
https://jira.codehaus.org/browse/DOXIASITETOOLS-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated DOXIASITETOOLS-76:


Attachment: DOXIASITETOOLS-76.patch

Patch adding inheritance of the elements.

 Missing inheritance of 'googleAdSenseClient', 'googleAdSenseSlot' and 
 'googleAnalyticsAccountId' elements.
 --

 Key: DOXIASITETOOLS-76
 URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-76
 Project: Maven Doxia Sitetools
  Issue Type: Bug
  Components: Decoration model
Affects Versions: 1.3
Reporter: Christian Schulte
 Attachments: DOXIASITETOOLS-76.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MCHANGES-289) Please add support for HTTP digest authentication to the 'trac-report' plugin.

2012-09-21 Thread Christian Schulte (JIRA)
Christian Schulte created MCHANGES-289:
--

 Summary: Please add support for HTTP digest authentication to the 
'trac-report' plugin.
 Key: MCHANGES-289
 URL: https://jira.codehaus.org/browse/MCHANGES-289
 Project: Maven 2.x Changes Plugin
  Issue Type: Improvement
  Components: trac
Affects Versions: 2.8
Reporter: Christian Schulte
Priority: Trivial


Currently the 'trac-report' supports only basic HTTP authentication 
transmitting clear-text credentials. The 'trac-report' should also support the 
digest HTTP authentication scheme.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MCHANGES-289) Please add support for HTTP digest authentication to the 'trac-report' plugin.

2012-09-21 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MCHANGES-289:
---

Attachment: MCHANGES-289.patch

This patch exchanges the default JDK based 'XmlRpcTransportFactory' 
implementation with the 'commons-httpclient' based implementation supporting 
HTTP digest authentication.


 Please add support for HTTP digest authentication to the 'trac-report' plugin.
 --

 Key: MCHANGES-289
 URL: https://jira.codehaus.org/browse/MCHANGES-289
 Project: Maven 2.x Changes Plugin
  Issue Type: Improvement
  Components: trac
Affects Versions: 2.8
Reporter: Christian Schulte
Priority: Trivial
 Attachments: MCHANGES-289.patch


 Currently the 'trac-report' supports only basic HTTP authentication 
 transmitting clear-text credentials. The 'trac-report' should also support 
 the digest HTTP authentication scheme.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MNG-2199) Version ranges not supported for parent artifacts

2012-09-19 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MNG-2199:
---

Attachment: MNG-2199.patch

Updated the patch to additionally validate a 'version' to not use expressions.

{code}
Script started on Wed Sep 19 08:32:30 2012
$ cat pom.xml

project
  parent
groupIdorg.apache/groupId
artifactIdapache/artifactId
version[,11]/version
  /parent
  modelVersion4.0.0/modelVersion
  artifactIdmng2199/artifactId
  packagingjar/packaging
/project
$ mvn clean

[INFO] Scanning for projects...
[ERROR] The build could not read 1 project - [Help 1]
[ERROR]   
[ERROR]   The project org.apache:mng2199:11 (/tmp/mng2199/pom.xml) has 1 error
[ERROR] 'version' must be a constant. @ 
org.apache:mng2199:[unknown-version], /tmp/mng2199/pom.xml, line 2, column 11
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
$ ^D


Script done on Wed Sep 19 08:32:42 2012
{code}

{code}
Script started on Wed Sep 19 08:33:36 2012
$ cat pom.xml

project
  parent
groupIdorg.apache/groupId
artifactIdapache/artifactId
version[,11]/version
  /parent
  modelVersion4.0.0/modelVersion
  artifactIdmng2199/artifactId
  packagingjar/packaging
  version1.0-${expression}-SNAPSHOT/version
/project
$ mvn clean

[INFO] Scanning for projects...
[ERROR] The build could not read 1 project - [Help 1]
[ERROR]   
[ERROR]   The project org.apache:mng2199:1.0-${expression}-SNAPSHOT 
(/tmp/mng2199/pom.xml) has 1 error
[ERROR] 'version' contains an expression but must be a constant. @ line 2, 
column 11
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
$ ^D


Script done on Wed Sep 19 08:33:47 2012
{code}


 Version ranges not supported for parent artifacts
 -

 Key: MNG-2199
 URL: https://jira.codehaus.org/browse/MNG-2199
 Project: Maven 2  3
  Issue Type: Wish
  Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 2.0.3
Reporter: Christian Schulte
 Fix For: Issues to be reviewed for 3.x

 Attachments: MNG-2199.patch, MNG-2199.patch, MNG-2199.patch, 
 MNG-2199.patch


 It would be great if Maven supports version ranges when specifying parent 
 artifacts in a multi-module build. Currently this does not work.
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, 2.0.1]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 2.0.1]/artifactId-[2.0, 2.0.1].pom
 Additionally it would be great if this
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, ${pom.version}]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 ${pom.version}]/artifactId-[2.0, ${pom.version}].pom
 would also work, if the version is specified in the same pom.xml which 
 defines this parent definition.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MNG-2199) Version ranges not supported for parent artifacts

2012-09-18 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MNG-2199:
---

Attachment: MNG-2199.patch

Initial patch adding support for the requested feature.

 Version ranges not supported for parent artifacts
 -

 Key: MNG-2199
 URL: https://jira.codehaus.org/browse/MNG-2199
 Project: Maven 2  3
  Issue Type: Bug
  Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 2.0.3
Reporter: Christian Schulte
 Fix For: Issues to be reviewed for 3.x

 Attachments: MNG-2199.patch


 It would be great if Maven supports version ranges when specifying parent 
 artifacts in a multi-module build. Currently this does not work.
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, 2.0.1]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 2.0.1]/artifactId-[2.0, 2.0.1].pom
 Additionally it would be great if this
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, ${pom.version}]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 ${pom.version}]/artifactId-[2.0, ${pom.version}].pom
 would also work, if the version is specified in the same pom.xml which 
 defines this parent definition.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MNG-2199) Version ranges not supported for parent artifacts

2012-09-18 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MNG-2199:
---

Attachment: MNG-2199.patch

Updated patch.


 Version ranges not supported for parent artifacts
 -

 Key: MNG-2199
 URL: https://jira.codehaus.org/browse/MNG-2199
 Project: Maven 2  3
  Issue Type: Bug
  Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 2.0.3
Reporter: Christian Schulte
 Fix For: Issues to be reviewed for 3.x

 Attachments: MNG-2199.patch, MNG-2199.patch


 It would be great if Maven supports version ranges when specifying parent 
 artifacts in a multi-module build. Currently this does not work.
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, 2.0.1]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 2.0.1]/artifactId-[2.0, 2.0.1].pom
 Additionally it would be great if this
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, ${pom.version}]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 ${pom.version}]/artifactId-[2.0, ${pom.version}].pom
 would also work, if the version is specified in the same pom.xml which 
 defines this parent definition.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MNG-2199) Version ranges not supported for parent artifacts

2012-09-18 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308872#comment-308872
 ] 

Christian Schulte commented on MNG-2199:


[Super-POM 
History|http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml?view=log]

- [use proper 
CNAME|http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml?r1=1155270r2=1160922diff_format=h]
- [going back to assembly beta-1 as there is an important regression in 
assembly:attached|http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml?r1=639019r2=639744diff_format=h]
- [try using repo1 again to see if it avoids the 503 
errors|http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml?r1=320991r2=326009diff_format=h]
- [change main repo until we stabilise 
maven.org|http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml?r1=292103r2=320693diff_format=h]


 Version ranges not supported for parent artifacts
 -

 Key: MNG-2199
 URL: https://jira.codehaus.org/browse/MNG-2199
 Project: Maven 2  3
  Issue Type: Wish
  Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 2.0.3
Reporter: Christian Schulte
 Fix For: Issues to be reviewed for 3.x

 Attachments: MNG-2199.patch, MNG-2199.patch


 It would be great if Maven supports version ranges when specifying parent 
 artifacts in a multi-module build. Currently this does not work.
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, 2.0.1]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 2.0.1]/artifactId-[2.0, 2.0.1].pom
 Additionally it would be great if this
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, ${pom.version}]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 ${pom.version}]/artifactId-[2.0, ${pom.version}].pom
 would also work, if the version is specified in the same pom.xml which 
 defines this parent definition.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MNG-2199) Version ranges not supported for parent artifacts

2012-09-18 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MNG-2199:
---

Attachment: MNG-2199.patch

Updated the patch one more time. This patch adds support for

{code}
parent
  groupIdgid/groupId
  artifactIdaid/artifactId
  versionMaven version range syntax, e.g. [1.0, 2.0)/version
/parent
{code}

It will fail the build whenever a child references a parent that way without 
defining a version. Error message would be: 'Child POM 
gid:aid:[unknown-version] cannot inherit version [1.0,2.0) from parent. Must 
define a version explicitly.'

One thing I would want this patch to do additionally, is validation of the 
version ranges in use. I did not find methods at interface 
'org.sonatype.aether.version.VersionRange' to allow querying for 'isBounded' / 
'isUpperBounded' / 'isLowerBounded' which would be needed for this.


 Version ranges not supported for parent artifacts
 -

 Key: MNG-2199
 URL: https://jira.codehaus.org/browse/MNG-2199
 Project: Maven 2  3
  Issue Type: Wish
  Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 2.0.3
Reporter: Christian Schulte
 Fix For: Issues to be reviewed for 3.x

 Attachments: MNG-2199.patch, MNG-2199.patch, MNG-2199.patch


 It would be great if Maven supports version ranges when specifying parent 
 artifacts in a multi-module build. Currently this does not work.
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, 2.0.1]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 2.0.1]/artifactId-[2.0, 2.0.1].pom
 Additionally it would be great if this
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, ${pom.version}]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 ${pom.version}]/artifactId-[2.0, ${pom.version}].pom
 would also work, if the version is specified in the same pom.xml which 
 defines this parent definition.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MNG-2199) Version ranges not supported for parent artifacts

2012-09-17 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308736#comment-308736
 ] 

Christian Schulte commented on MNG-2199:


6 years after creating this issue, I still think it would be helpful to have 
this supported. For example:

The server name of a repository changes.
  = All POMs of all artifacts in the repository are broken and point to a 
non-existing repository.
  = need to re-release all artifacts
  = new artifact versions
  = everyone must update everything
  = at least one full release-cycle wasted

One might say that this kind of problem can be avoided by not adding 
repositories to the POM. If you think about that, this just ends in every 
environmental property being moved out into settings.xml or somewhere else. 
That just leads to non-determinism as well.

Executing 'mvn release:prepare' on a years old tag should work without touching 
anything else. It would be non-determinism if this would stop working a few 
years later, no ?


 Version ranges not supported for parent artifacts
 -

 Key: MNG-2199
 URL: https://jira.codehaus.org/browse/MNG-2199
 Project: Maven 2  3
  Issue Type: Bug
  Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 2.0.3
Reporter: Christian Schulte
 Fix For: Issues to be reviewed for 3.x


 It would be great if Maven supports version ranges when specifying parent 
 artifacts in a multi-module build. Currently this does not work.
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, 2.0.1]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 2.0.1]/artifactId-[2.0, 2.0.1].pom
 Additionally it would be great if this
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, ${pom.version}]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 ${pom.version}]/artifactId-[2.0, ${pom.version}].pom
 would also work, if the version is specified in the same pom.xml which 
 defines this parent definition.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MNG-2199) Version ranges not supported for parent artifacts

2012-09-17 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308736#comment-308736
 ] 

Christian Schulte edited comment on MNG-2199 at 9/17/12 11:55 AM:
--

6 years after creating this issue, I still think it would be helpful to have 
this supported. For example:

The server name of a repository changes.
  = All POMs of all artifacts in the repository are broken and point to a 
non-existing repository.
  = need to re-release all artifacts
  = new artifact versions
  = everyone must update everything
  = at least one full release-cycle wasted

One might say that this kind of problem can be avoided by not adding 
repositories to the POM. If you think about that, this just ends in every 
environmental property being moved out into settings.xml or somewhere else. 
That just leads to non-determinism as well.

Executing 'mvn release:prepare' on a years old tag should work without touching 
anything else. It would be non-determinism if this would stop working a few 
years later, no ?

The version range is very important here due to the ability to declare an upper 
bound. I am not requesting to 'just use the latest parent' but to use the 
latest parent from a range (of compatible parent POMs).


  was (Author: schulte2005):
6 years after creating this issue, I still think it would be helpful to 
have this supported. For example:

The server name of a repository changes.
  = All POMs of all artifacts in the repository are broken and point to a 
non-existing repository.
  = need to re-release all artifacts
  = new artifact versions
  = everyone must update everything
  = at least one full release-cycle wasted

One might say that this kind of problem can be avoided by not adding 
repositories to the POM. If you think about that, this just ends in every 
environmental property being moved out into settings.xml or somewhere else. 
That just leads to non-determinism as well.

Executing 'mvn release:prepare' on a years old tag should work without touching 
anything else. It would be non-determinism if this would stop working a few 
years later, no ?

  
 Version ranges not supported for parent artifacts
 -

 Key: MNG-2199
 URL: https://jira.codehaus.org/browse/MNG-2199
 Project: Maven 2  3
  Issue Type: Bug
  Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 2.0.3
Reporter: Christian Schulte
 Fix For: Issues to be reviewed for 3.x


 It would be great if Maven supports version ranges when specifying parent 
 artifacts in a multi-module build. Currently this does not work.
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, 2.0.1]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 2.0.1]/artifactId-[2.0, 2.0.1].pom
 Additionally it would be great if this
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, ${pom.version}]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 ${pom.version}]/artifactId-[2.0, ${pom.version}].pom
 would also work, if the version is specified in the same pom.xml which 
 defines this parent definition.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MNG-2199) Version ranges not supported for parent artifacts

2012-09-17 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308736#comment-308736
 ] 

Christian Schulte edited comment on MNG-2199 at 9/17/12 12:38 PM:
--

6 years after creating this issue, I still think it would be helpful to have 
this supported. For example:

The server name of a repository changes.
  = All POMs of all artifacts in the repository are broken and point to a 
non-existing repository.
  = need to re-release all artifacts
  = new artifact versions
  = everyone must update everything
  = at least one full release-cycle wasted

One might say that this kind of problem can be avoided by not adding 
repositories to the POM. If you think about that, this just ends in every 
environmental property being moved out into settings.xml or somewhere else. 
That just leads to non-determinism as well.

Executing 'mvn release:prepare' on a years old tag should work without touching 
anything else. It would be non-determinism if this would stop working a few 
years later, no ?

The version range is very important here due to the ability to declare an upper 
bound. I am not requesting to 'just use the latest parent' but to use the 
latest parent from a range (of compatible parent POMs).

During model building, if a POM contains a 'parent' element using a version 
range:
=validate that range has an upper bound and fail the build if unbounded
=load the latest parent from that range
=validate the latest parent does not define any 'modules' - fail the build if 
it does (maybe use some other information to validate the POM here - a new 
packaging used to flag a POM to be used that way e.g.)
=use that parent


  was (Author: schulte2005):
6 years after creating this issue, I still think it would be helpful to 
have this supported. For example:

The server name of a repository changes.
  = All POMs of all artifacts in the repository are broken and point to a 
non-existing repository.
  = need to re-release all artifacts
  = new artifact versions
  = everyone must update everything
  = at least one full release-cycle wasted

One might say that this kind of problem can be avoided by not adding 
repositories to the POM. If you think about that, this just ends in every 
environmental property being moved out into settings.xml or somewhere else. 
That just leads to non-determinism as well.

Executing 'mvn release:prepare' on a years old tag should work without touching 
anything else. It would be non-determinism if this would stop working a few 
years later, no ?

The version range is very important here due to the ability to declare an upper 
bound. I am not requesting to 'just use the latest parent' but to use the 
latest parent from a range (of compatible parent POMs).

  
 Version ranges not supported for parent artifacts
 -

 Key: MNG-2199
 URL: https://jira.codehaus.org/browse/MNG-2199
 Project: Maven 2  3
  Issue Type: Bug
  Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 2.0.3
Reporter: Christian Schulte
 Fix For: Issues to be reviewed for 3.x


 It would be great if Maven supports version ranges when specifying parent 
 artifacts in a multi-module build. Currently this does not work.
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, 2.0.1]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 2.0.1]/artifactId-[2.0, 2.0.1].pom
 Additionally it would be great if this
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, ${pom.version}]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 ${pom.version}]/artifactId-[2.0, ${pom.version}].pom
 would also work, if the version is specified in the same pom.xml which 
 defines this parent definition.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MNG-2199) Version ranges not supported for parent artifacts

2012-09-17 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308770#comment-308770
 ] 

Christian Schulte commented on MNG-2199:


Another example. Consider I have been using a parent POM containing the 
following information.

{code}
license
  nameGNU GENERAL PUBLIC LICENSE/name
  urlhttp://www.gnu.org/copyleft/gpl.txt/url
  distributionrepo/distribution
/license
{code}

As you may know, the content that URL points at changed from GPL 2.1 to GPL 3 a 
few years ago. If I want already deployed artifacts to stay at GPL 2.1, I 
cannot do anything about it. Releasing a new parent for all those artifacts 
would let me deal with this. Note that for this example I would want this 
feature to keep the artifacts from silently changing the referenced license 
text.

Not putting that URL into the POM would have avoided the situation, of course. 
You cannot predict the future, however.


 Version ranges not supported for parent artifacts
 -

 Key: MNG-2199
 URL: https://jira.codehaus.org/browse/MNG-2199
 Project: Maven 2  3
  Issue Type: Bug
  Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 2.0.3
Reporter: Christian Schulte
 Fix For: Issues to be reviewed for 3.x


 It would be great if Maven supports version ranges when specifying parent 
 artifacts in a multi-module build. Currently this does not work.
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, 2.0.1]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 2.0.1]/artifactId-[2.0, 2.0.1].pom
 Additionally it would be great if this
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, ${pom.version}]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 ${pom.version}]/artifactId-[2.0, ${pom.version}].pom
 would also work, if the version is specified in the same pom.xml which 
 defines this parent definition.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MDEP-367) 'Unused declared dependencies found' incorrect with Maven 3.

2012-08-20 Thread Christian Schulte (JIRA)
Christian Schulte created MDEP-367:
--

 Summary: 'Unused declared dependencies found' incorrect with Maven 
3.
 Key: MDEP-367
 URL: https://jira.codehaus.org/browse/MDEP-367
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: analyze
Affects Versions: 2.5, 2.4, 2.3, 2.2, 2.1, 2.0
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Reporter: Christian Schulte


The 'analyze' goal reports dependencies as 'unused declared' although the 
dependency is used. Works with Maven 2.2.1.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MDEP-367) 'Unused declared dependencies found' incorrect with Maven 3.

2012-08-20 Thread Christian Schulte (JIRA)

 [ 
https://jira.codehaus.org/browse/MDEP-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MDEP-367:
---

Attachment: MDEP-367.zip

Example project.

 'Unused declared dependencies found' incorrect with Maven 3.
 

 Key: MDEP-367
 URL: https://jira.codehaus.org/browse/MDEP-367
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: analyze
Affects Versions: 2.0, 2.1, 2.2, 2.3, 2.4, 2.5
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Reporter: Christian Schulte
 Attachments: MDEP-367.zip


 The 'analyze' goal reports dependencies as 'unused declared' although the 
 dependency is used. Works with Maven 2.2.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MDEP-367) 'Unused declared dependencies found' incorrect with Maven 3.

2012-08-20 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MDEP-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306551#comment-306551
 ] 

Christian Schulte commented on MDEP-367:


Output running 'analyze' using Maven 3.0.4.

{code}
Script started on Mon Aug 20 11:18:55 2012
$ mvn org.apache.maven.plugins:maven-dependency-plugin:2.5:analyze 

[INFO] Scanning for projects...
[INFO] 
[INFO] Reactor Build Order:
[INFO] 
[INFO] parent
[INFO] module1
[INFO] module2
[INFO] 
[INFO] 
[INFO] Building parent 1.0
[INFO] 
[INFO] 
[INFO]  maven-dependency-plugin:2.5:analyze (default-cli) @ parent 
[INFO] 
[INFO]  maven-dependency-plugin:2.5:analyze (default-cli) @ parent 
[INFO] 
[INFO] --- maven-dependency-plugin:2.5:analyze (default-cli) @ parent ---
[INFO] Skipping pom project
[INFO] 
[INFO] 
[INFO] Building module1 1.0
[INFO] 
[INFO] 
[INFO]  maven-dependency-plugin:2.5:analyze (default-cli) @ module1 
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ module1 
---
[debug] execute contextualize
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, 
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory 
/tmp/MDEP-367/module1/src/main/resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ module1 ---
[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. 
build is platform dependent!
[INFO] Compiling 1 source file to /tmp/MDEP-367/module1/target/classes
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
module1 ---
[debug] execute contextualize
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, 
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory 
/tmp/MDEP-367/module1/src/test/resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ 
module1 ---
[INFO] No sources to compile
[INFO] 
[INFO]  maven-dependency-plugin:2.5:analyze (default-cli) @ module1 
[INFO] 
[INFO] --- maven-dependency-plugin:2.5:analyze (default-cli) @ module1 ---
[INFO] No dependency problems found
[INFO] 
[INFO] 
[INFO] Building module2 1.0
[INFO] 
[INFO] 
[INFO]  maven-dependency-plugin:2.5:analyze (default-cli) @ module2 
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ module2 
---
[debug] execute contextualize
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, 
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory 
/tmp/MDEP-367/module2/src/main/resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ module2 ---
[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. 
build is platform dependent!
[INFO] Compiling 1 source file to /tmp/MDEP-367/module2/target/classes
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
module2 ---
[debug] execute contextualize
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, 
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory 
/tmp/MDEP-367/module2/src/test/resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ 
module2 ---
[INFO] No sources to compile
[INFO] 
[INFO]  maven-dependency-plugin:2.5:analyze (default-cli) @ module2 
[INFO] 
[INFO] --- maven-dependency-plugin:2.5:analyze (default-cli) @ module2 ---
[WARNING] Unused declared dependencies found:
[WARNING]mdep367:module1:jar:1.0:compile
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] parent  SUCCESS [1.029s]
[INFO] module1 ... SUCCESS [0.855s]
[INFO] module2 ... SUCCESS [0.404s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 2.696s
[INFO] Finished at: Mon Aug 20 11:19:01 CEST 2012
[INFO] Final Memory: 12M/30M
[INFO] 

[jira] (MDEP-367) 'Unused declared dependencies found' incorrect with Maven 3.

2012-08-20 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MDEP-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306552#comment-306552
 ] 

Christian Schulte commented on MDEP-367:


Output running 'analyze' using Maven 2.2.1.

{code}
Script started on Mon Aug 20 11:21:08 2012
$ mvn org.apache.maven.plugins:maven-dependency-plugin:2.5:analyze 

[INFO] Scanning for projects...
[INFO] Reactor build order: 
[INFO]   parent
[INFO]   module1
[INFO]   module2
[INFO] 
[INFO] Building parent
[INFO]task-segment: 
[org.apache.maven.plugins:maven-dependency-plugin:2.5:analyze]
[INFO] 
[INFO] Preparing dependency:analyze
[INFO] No goals needed for project - skipping
[INFO] [dependency:analyze {execution: default-cli}]
[INFO] Skipping pom project
[INFO] 
[INFO] Building module1
[INFO]task-segment: 
[org.apache.maven.plugins:maven-dependency-plugin:2.5:analyze]
[INFO] 
[INFO] Preparing dependency:analyze
[INFO] [resources:resources {execution: default-resources}]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, 
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory 
/tmp/MDEP-367/module1/src/main/resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources {execution: default-testResources}]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, 
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory 
/tmp/MDEP-367/module1/src/test/resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] No sources to compile
[INFO] [dependency:analyze {execution: default-cli}]
[INFO] No dependency problems found
[INFO] 
[INFO] Building module2
[INFO]task-segment: 
[org.apache.maven.plugins:maven-dependency-plugin:2.5:analyze]
[INFO] 
[INFO] Preparing dependency:analyze
[INFO] [resources:resources {execution: default-resources}]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, 
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory 
/tmp/MDEP-367/module2/src/main/resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources {execution: default-testResources}]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, 
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory 
/tmp/MDEP-367/module2/src/test/resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] No sources to compile
[INFO] [dependency:analyze {execution: default-cli}]
[INFO] No dependency problems found
[INFO] 
[INFO] 
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] parent  SUCCESS [3.543s]
[INFO] module1 ... SUCCESS [0.480s]
[INFO] module2 ... SUCCESS [0.029s]
[INFO] 
[INFO] 
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 4 seconds
[INFO] Finished at: Mon Aug 20 11:21:24 CEST 2012
[INFO] Final Memory: 20M/49M
[INFO] 
$ ^D


Script done on Mon Aug 20 11:21:31 2012
{code}


[INFO] No dependency problems found


 'Unused declared dependencies found' incorrect with Maven 3.
 

 Key: MDEP-367
 URL: https://jira.codehaus.org/browse/MDEP-367
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: analyze
Affects Versions: 2.0, 2.1, 2.2, 2.3, 2.4, 2.5
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Reporter: Christian Schulte
 Attachments: MDEP-367.zip


 The 'analyze' goal reports dependencies as 'unused declared' although the 
 dependency is used. Works with Maven 2.2.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 

[jira] (MSOURCES-62) An API incompatibility was encountered.

2012-08-17 Thread Christian Schulte (JIRA)
Christian Schulte created MSOURCES-62:
-

 Summary: An API incompatibility was encountered.
 Key: MSOURCES-62
 URL: https://jira.codehaus.org/browse/MSOURCES-62
 Project: Maven 2.x Source Plugin
  Issue Type: Bug
Affects Versions: 2.2
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Reporter: Christian Schulte
Priority: Blocker


The plugin fails when using custom 'manifestEntries' throwing the following 
exception:

{code}
[...]
Caused by: java.lang.NoSuchMethodError: 
org.codehaus.plexus.archiver.jar.Manifest.getMainSection()Lorg/codehaus/plexus/archiver/jar/Manifest$Section;
at 
org.apache.maven.archiver.MavenArchiver.getManifest(MavenArchiver.java:102)
at 
org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:513)
at 
org.apache.maven.plugin.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:288)
at 
org.apache.maven.plugin.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:240)
at 
org.apache.maven.plugin.source.AbstractSourceJarMojo.execute(AbstractSourceJarMojo.java:209)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
{code}


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSOURCES-62) An API incompatibility was encountered.

2012-08-17 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MSOURCES-62:
--

Attachment: MSOURCES-62.zip

Example project demonstrating the issue.

 An API incompatibility was encountered.
 ---

 Key: MSOURCES-62
 URL: https://jira.codehaus.org/browse/MSOURCES-62
 Project: Maven 2.x Source Plugin
  Issue Type: Bug
Affects Versions: 2.2
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Reporter: Christian Schulte
Priority: Blocker
 Attachments: MSOURCES-62.zip


 The plugin fails when using custom 'manifestEntries' throwing the following 
 exception:
 {code}
 [...]
 Caused by: java.lang.NoSuchMethodError: 
 org.codehaus.plexus.archiver.jar.Manifest.getMainSection()Lorg/codehaus/plexus/archiver/jar/Manifest$Section;
 at 
 org.apache.maven.archiver.MavenArchiver.getManifest(MavenArchiver.java:102)
 at 
 org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:513)
 at 
 org.apache.maven.plugin.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:288)
 at 
 org.apache.maven.plugin.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:240)
 at 
 org.apache.maven.plugin.source.AbstractSourceJarMojo.execute(AbstractSourceJarMojo.java:209)
 at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
 ... 20 more
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSOURCES-62) An API incompatibility was encountered.

2012-08-17 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MSOURCES-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306467#comment-306467
 ] 

Christian Schulte commented on MSOURCES-62:
---

{code}
Script started on Sat Aug 18 00:21:29 2012
$ mvn -e package

[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] 
[INFO] 
[INFO] Building 62 1.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 62 ---
[debug] execute contextualize
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, 
i.e. build is platform dependent!
[INFO] Copying 1 resource
[INFO] 
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ 62 ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
62 ---
[debug] execute contextualize
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, 
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /tmp/MSOURCES-62/src/test/resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ 62 
---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.10:test (default-test) @ 62 ---
[INFO] No tests to run.
[INFO] Surefire report directory: /tmp/MSOURCES-62/target/surefire-reports

---
 T E S T S
---

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO] 
[INFO] --- maven-jar-plugin:2.3.2:jar (default-jar) @ 62 ---
[INFO] Building jar: /tmp/MSOURCES-62/target/62-1.0-SNAPSHOT.jar
[INFO] 
[INFO] --- maven-source-plugin:2.2:jar-no-fork (default) @ 62 ---
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 2.051s
[INFO] Finished at: Sat Aug 18 00:21:43 CEST 2012
[INFO] Final Memory: 6M/15M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-source-plugin:2.2:jar-no-fork (default) on 
project 62: Execution default of goal 
org.apache.maven.plugins:maven-source-plugin:2.2:jar-no-fork failed: An API 
incompatibility was encountered while executing 
org.apache.maven.plugins:maven-source-plugin:2.2:jar-no-fork: 
java.lang.NoSuchMethodError: 
org.codehaus.plexus.archiver.jar.Manifest.getMainSection()Lorg/codehaus/plexus/archiver/jar/Manifest$Section;
[ERROR] -
[ERROR] realm =pluginorg.apache.maven.plugins:maven-source-plugin:2.2
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] = 
file:/home/schulte/.m2/central/org/apache/maven/plugins/maven-source-plugin/2.2/maven-source-plugin-2.2.jar
[ERROR] urls[1] = 
file:/home/schulte/.m2/central/junit/junit/3.8.1/junit-3.8.1.jar
[ERROR] urls[2] = 
file:/home/schulte/.m2/central/org/apache/maven/maven-archiver/2.4.1/maven-archiver-2.4.1.jar
[ERROR] urls[3] = 
file:/home/schulte/.m2/central/org/codehaus/plexus/plexus-interpolation/1.13/plexus-interpolation-1.13.jar
[ERROR] urls[4] = 
file:/home/schulte/.m2/central/org/codehaus/plexus/plexus-archiver/2.1.2/plexus-archiver-2.1.2.jar
[ERROR] urls[5] = 
file:/home/schulte/.m2/central/org/codehaus/plexus/plexus-io/2.0.4/plexus-io-2.0.4.jar
[ERROR] urls[6] = 
file:/home/schulte/.m2/central/org/codehaus/plexus/plexus-utils/3.0.1/plexus-utils-3.0.1.jar
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import  from realm ClassRealm[maven.api, parent: null]]
[ERROR] 
[ERROR] -
[ERROR] - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-source-plugin:2.2:jar-no-fork (default) on 
project 62: Execution default of goal 
org.apache.maven.plugins:maven-source-plugin:2.2:jar-no-fork failed: An API 
incompatibility was encountered while executing 
org.apache.maven.plugins:maven-source-plugin:2.2:jar-no-fork: 
java.lang.NoSuchMethodError: 
org.codehaus.plexus.archiver.jar.Manifest.getMainSection()Lorg/codehaus/plexus/archiver/jar/Manifest$Section;
-
realm =pluginorg.apache.maven.plugins:maven-source-plugin:2.2
strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
urls[0] = 
file:/home/schulte/.m2/central/org/apache/maven/plugins/maven-source-plugin/2.2/maven-source-plugin-2.2.jar
urls[1] = file:/home/schulte/.m2/central/junit/junit/3.8.1/junit-3.8.1.jar
urls[2] 

[jira] (MDEP-363) The plugin should not write debug messages to 'System.out'.

2012-07-31 Thread Christian Schulte (JIRA)
Christian Schulte created MDEP-363:
--

 Summary: The plugin should not write debug messages to 
'System.out'.
 Key: MDEP-363
 URL: https://jira.codehaus.org/browse/MDEP-363
 Project: Maven 2.x Dependency Plugin
  Issue Type: Task
Affects Versions: 2.4
Reporter: Christian Schulte
Priority: Trivial




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MDEP-363) The plugin should not write debug messages to 'System.out'.

2012-07-31 Thread Christian Schulte (JIRA)

 [ 
https://jira.codehaus.org/browse/MDEP-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MDEP-363:
---

Attachment: pom.xml

Executing 'mvn generate-resources' on this POM, no 'System.out' messages are 
printed. Repeating 'mvn generate-resources' without 'clean'ing the project, 
debug messages are printed to 'System.out'.


 The plugin should not write debug messages to 'System.out'.
 ---

 Key: MDEP-363
 URL: https://jira.codehaus.org/browse/MDEP-363
 Project: Maven 2.x Dependency Plugin
  Issue Type: Task
Affects Versions: 2.4
Reporter: Christian Schulte
Priority: Trivial
 Attachments: pom.xml




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MDEP-363) The plugin should not write debug messages to 'System.out'.

2012-07-31 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MDEP-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305100#comment-305100
 ] 

Christian Schulte commented on MDEP-363:


{code}
Script started on Tue Jul 31 22:30:31 2012
$ mvn clean

[INFO] Scanning for projects...
[INFO] 
[INFO] 
[INFO] Building mdep363 1.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ mdep363 ---
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 1.537s
[INFO] Finished at: Tue Jul 31 22:30:37 CEST 2012
[INFO] Final Memory: 3M/15M
[INFO] 
$ mvn generate-resources

[INFO] Scanning for projects...
[INFO] 
[INFO] 
[INFO] Building mdep363 1.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-dependency-plugin:2.4:unpack (default) @ mdep363 ---
[INFO] Configured Artifact: org.apache:apache-jar-resource-bundle:1.4:jar
[INFO] Unpacking 
/home/schulte/.m2/central/org/apache/apache-jar-resource-bundle/1.4/apache-jar-resource-bundle-1.4.jar
 to /tmp/mdep363/target/dependency with includes  and excludes 
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 9.668s
[INFO] Finished at: Tue Jul 31 22:30:57 CEST 2012
[INFO] Final Memory: 6M/15M
[INFO] 
$ 
$ mvn generate-resources 

[INFO] Scanning for projects...
[INFO] 
[INFO] 
[INFO] Building mdep363 1.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-dependency-plugin:2.4:unpack (default) @ mdep363 ---
[INFO] Configured Artifact: org.apache:apache-jar-resource-bundle:1.4:jar
 isMarkerOlder:
  artifact1 = 
/home/schulte/.m2/central/org/apache/apache-jar-resource-bundle/1.4/apache-jar-resource-bundle-1.4.jar
  marker= 
/tmp/mdep363/target/dependency-maven-plugin-markers/org.apache-apache-jar-resource-bundle-jar-1.4.marker
artifact1 lastModified: 1335224583000
marker lastModified: 1335224583000
 false = marker older than artifact?
[INFO] apache-jar-resource-bundle-1.4.jar already unpacked.
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 1.487s
[INFO] Finished at: Tue Jul 31 22:31:02 CEST 2012
[INFO] Final Memory: 6M/15M
[INFO] 
$ ^D


Script done on Tue Jul 31 22:31:06 2012
{code}


 The plugin should not write debug messages to 'System.out'.
 ---

 Key: MDEP-363
 URL: https://jira.codehaus.org/browse/MDEP-363
 Project: Maven 2.x Dependency Plugin
  Issue Type: Task
Affects Versions: 2.4
Reporter: Christian Schulte
Priority: Trivial
 Attachments: pom.xml




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MDEP-363) The plugin should not write debug messages to 'System.out'.

2012-07-31 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MDEP-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305102#comment-305102
 ] 

Christian Schulte commented on MDEP-363:


See [r1085956|http://svn.apache.org/viewvc?view=revisionrevision=1085956].


 The plugin should not write debug messages to 'System.out'.
 ---

 Key: MDEP-363
 URL: https://jira.codehaus.org/browse/MDEP-363
 Project: Maven 2.x Dependency Plugin
  Issue Type: Task
Affects Versions: 2.4
Reporter: Christian Schulte
Priority: Trivial
 Attachments: pom.xml




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSHADE-121) Default value of parameter 'dependencyReducedPomLocation' broken.

2012-06-02 Thread Christian Schulte (JIRA)
Christian Schulte created MSHADE-121:


 Summary: Default value of parameter 'dependencyReducedPomLocation' 
broken.
 Key: MSHADE-121
 URL: https://jira.codehaus.org/browse/MSHADE-121
 Project: Maven 2.x Shade Plugin
  Issue Type: Bug
Affects Versions: 1.7
Reporter: Christian Schulte
Priority: Critical


Upgrading the shade plugin from '1.6' to '1.7' breaks relative paths similar to 
MSHADE-23. This is due to an incorrect/missing default value for parameter 
'dependencyReducedPomLocation'.

{code}
/**
 * @parameter expression=${dependencyReducedPomLocation} 
defaultValue=${basedir}/dependency-reduced-pom.xml
 */
private File dependencyReducedPomLocation;
{code}

Should read 'default-value' instead of 'defaultValue'. Manually specifying

{xml}
dependencyReducedPomLocation${basedir}/dependency-reduced-pom.xml/dependencyReducedPomLocation
{xml}

solves this.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MCHANGES-272) Please add an option to the 'changes-check' goal to allow skipping release date checks of snapshot versions.

2012-04-23 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MCHANGES-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=297064#comment-297064
 ] 

Christian Schulte commented on MCHANGES-272:


I would like to be able to enable the release profile when building snapshots 
(e.g. for testing the release build or for deploying snapshots publicly). Just 
like 'mvn deploy' automatically chooses a repository to upload to based on the 
kind of artifact acted upon, I would like to avoid having to invoke maven 
differently based on the kind of artifact acted upon when enabling the release 
profile. The current behavior of the 'changes-check' goal makes this 
impossible, since it will fail the build when building a snapshot for which no 
matching release version is found in the 'changes.xml' file or for which no 
release date is found which makes no sense for snapshots, IMHO. Therefore, the 
goal should automatically skip itself, when building a snapshot.


 Please add an option to the 'changes-check' goal to allow skipping release 
 date checks of snapshot versions.
 

 Key: MCHANGES-272
 URL: https://jira.codehaus.org/browse/MCHANGES-272
 Project: Maven 2.x Changes Plugin
  Issue Type: New Feature
Affects Versions: 2.6
Reporter: Christian Schulte
Assignee: Benson Margulies
Priority: Trivial
 Attachments: MCHANGES-272.patch


 The 'changes-check' goal treats snapshot versions the same way as release 
 versions by removing the '-SNAPSHOT' suffix prior to checking the release 
 date. Please add an option to the 'changes-check' goal to allow skipping 
 snapshot versions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MCHANGES-272) Please add an option to the 'changes-check' goal to allow skipping release date checks of snapshot versions.

2012-04-23 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MCHANGES-272:
---

Attachment: MCHANGES-272.patch

Updated patch to use 'ArtifactUtils.isSnapshot'. I am not sure if method 
'ReleaseUtils.getLatestRelease' also needs updating to support timestamp 
snapshot version.



 Please add an option to the 'changes-check' goal to allow skipping release 
 date checks of snapshot versions.
 

 Key: MCHANGES-272
 URL: https://jira.codehaus.org/browse/MCHANGES-272
 Project: Maven 2.x Changes Plugin
  Issue Type: New Feature
Affects Versions: 2.6
Reporter: Christian Schulte
Assignee: Benson Margulies
Priority: Trivial
 Attachments: MCHANGES-272.patch, MCHANGES-272.patch


 The 'changes-check' goal treats snapshot versions the same way as release 
 versions by removing the '-SNAPSHOT' suffix prior to checking the release 
 date. Please add an option to the 'changes-check' goal to allow skipping 
 snapshot versions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MRELEASE-412) release:prepare does not update properties during rewrite-poms-for-development phase.

2012-01-16 Thread Christian Schulte (JIRA)

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

Christian Schulte closed MRELEASE-412.
--

   Resolution: Fixed
Fix Version/s: (was: 2.3)
   2.2.2

Version 2.2.2 fixed this as well.

 release:prepare does not update properties during 
 rewrite-poms-for-development phase.
 -

 Key: MRELEASE-412
 URL: https://jira.codehaus.org/browse/MRELEASE-412
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
  Components: prepare
Affects Versions: 2.0-beta-8
 Environment: Maven version: 2.0.10-RC8
 Java version: 1.5.0_14
 OS name: linux version: 2.6.28.4 arch: i386 Family: unix
Reporter: Christian Schulte
Priority: Blocker
  Labels: maven-patch-available, properties
 Fix For: 2.2.2

 Attachments: MRELEASE-412.patch


 When a dependency version is specified using a property like 
 ${someExpression} that property is correctly updated during the 
 rewrite-poms-for-release phase but not during the 
 rewrite-poms-for-development phase. The attached patch solves this for me.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MRELEASE-297) release doesn't bump versions in properties to the next dev iteration

2012-01-16 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MRELEASE-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=288385#comment-288385
 ] 

Christian Schulte commented on MRELEASE-297:


This seems to haven been fixed as of version '2.2.2' of the 
'maven-release-plugin'. Can someone confirm ?


 release doesn't bump versions in properties to the next dev iteration
 -

 Key: MRELEASE-297
 URL: https://jira.codehaus.org/browse/MRELEASE-297
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
  Components: prepare
Affects Versions: 2.0-beta-6, 2.0-beta-7
Reporter: Brian Fox
Assignee: Maria Odea Ching

 Properties used as versions are correctly updated to the release version and 
 committed, but they are not bumped to the next snapshot after.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MRELEASE-297) release doesn't bump versions in properties to the next dev iteration

2012-01-16 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MRELEASE-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=288385#comment-288385
 ] 

Christian Schulte edited comment on MRELEASE-297 at 1/16/12 5:19 AM:
-

This seems to have been fixed as of version '2.2.2'. Can someone confirm ?

  was (Author: schulte2005):
This seems to haven been fixed as of version '2.2.2' of the 
'maven-release-plugin'. Can someone confirm ?

  
 release doesn't bump versions in properties to the next dev iteration
 -

 Key: MRELEASE-297
 URL: https://jira.codehaus.org/browse/MRELEASE-297
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
  Components: prepare
Affects Versions: 2.0-beta-6, 2.0-beta-7
Reporter: Brian Fox
Assignee: Maria Odea Ching

 Properties used as versions are correctly updated to the release version and 
 committed, but they are not bumped to the next snapshot after.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MNG-3959) Per-execution inherited flag ignored

2012-01-16 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=288441#comment-288441
 ] 

Christian Schulte commented on MNG-3959:


Maven 3 correctly supports per-execution inherited flags.

 Per-execution inherited flag ignored
 

 Key: MNG-3959
 URL: https://jira.codehaus.org/browse/MNG-3959
 Project: Maven 2  3
  Issue Type: Bug
  Components: Inheritance and Interpolation
Reporter: Dave Syer
 Fix For: Issues to be reviewed for 3.x


 Per-execution inherited flag ignored.  E.g. 
 {code}
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-antrun-plugin/artifactId
   executions
   execution
   idtest/id
   phaseinitialize/phase
   inheritedfalse/inherited
 ...
 {code}
 If you move the inherited element up to the plugin level it works, but then 
 that applies to all executions, which isn't what is needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MNG-2984) Allow more control around the configuration and use of optional dependencies

2012-01-16 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=288444#comment-288444
 ] 

Christian Schulte commented on MNG-2984:


Wouldn't it be sufficient, if the 'optional' flag could be managed using the 
'dependencyManagement' ?

{code}
dependencyManagement
  dependencies
dependencies
  groupIdcommons-digester/groupId
  artifactIdcommons-digester/artifactId
  versionwhatever/version
  optionalfalse/optional !-- Ignored by Maven 2  3 in dependency 
management. --
/dependency
  /dependencies
/dependencyManagement
{code}


 Allow more control around the configuration and use of optional dependencies
 

 Key: MNG-2984
 URL: https://jira.codehaus.org/browse/MNG-2984
 Project: Maven 2  3
  Issue Type: Improvement
  Components: Dependencies
Affects Versions: 2.0.6
Reporter: Paul Spencer
 Fix For: Issues to be reviewed for 3.x


 This request is based on the following posting to the users mailing list.
 How can I include a dependency's optional dependency without
 adding the optional dependency to the pom?
 As an example, shale-test has an optional dependency on commons-digester.  
 Since
 my application does not use commons-digester, I do not have it defined as
 a dependency in the pom.  When the test that used shale-test failed I had to
 determine the failure was due to a missing dependency that was defined in 
 shale-test's
 pom. Thus the following questions.
 1) Is their a way I can include all of a dependencies optional dependencies
without knowing what they are?
   dependency
 groupIdorg.apache.shale/groupId
 artifactIdshale-test/artifactId
 version1.1.0-SNAPSHOT/version
 scopetest/scope
 includeOptionalDependencies all=true/  !-- Just a guess to 
 illustrate the intent --
   dependency
 2) Is their a way I can include selected optional dependencies for a 
 dependency?
   dependency
 groupIdorg.apache.shale/groupId
 artifactIdshale-test/artifactId
 version1.1.0-SNAPSHOT/version
 scopetest/scope
 includeOptionalDependencies  !-- Just a guess to illustrate 
 the intent --
   dependency
 groupIdcommons-digester/groupId
 artifactIdcommons-digester/artifactId
   /dependency
 /includeOptionalDependencies
   dependency
 3) Can optional dependencies be grouped to allow for the inclusion of a
named group of optional dependencies, thus freeing the user from
having to know and maintain a list of optional dependencies to
include?
   dependency
 groupIdorg.apache.shale/groupId
 artifactIdshale-test/artifactId
 version1.1.0-SNAPSHOT/version
 scopetest/scope
 includeOptionalDependencies group=FunctionalGroup1/  !-- 
 Just a guess to illustrate the intent --
   dependency

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MNG-5227) The 'optional' flag of a dependency should be manageable.

2012-01-16 Thread Christian Schulte (JIRA)
Christian Schulte created MNG-5227:
--

 Summary: The 'optional' flag of a dependency should be manageable.
 Key: MNG-5227
 URL: https://jira.codehaus.org/browse/MNG-5227
 Project: Maven 2  3
  Issue Type: Wish
  Components: Artifacts and Repositories
Affects Versions: 3.0.3
Reporter: Christian Schulte
Priority: Minor


{code}
dependencyManagement
  dependencies
dependency
  groupIdgroupId/groupId
  artifactIdartifactId/artifactId
  versionversion/version
  optionalfalse/optional !-- Ignored by Maven 2  3 in dependency 
management. --
/dependency
  /dependencies
/dependencyManagement
{code}


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MCHANGES-272) Please add an option to the 'changes-check' goal to allow skipping release date checks of snapshot versions.

2012-01-11 Thread Christian Schulte (JIRA)
Christian Schulte created MCHANGES-272:
--

 Summary: Please add an option to the 'changes-check' goal to allow 
skipping release date checks of snapshot versions.
 Key: MCHANGES-272
 URL: https://jira.codehaus.org/browse/MCHANGES-272
 Project: Maven 2.x Changes Plugin
  Issue Type: New Feature
Affects Versions: 2.6
Reporter: Christian Schulte
Priority: Trivial


The 'changes-check' goal treats snapshot versions the same way as release 
versions by removing the '-SNAPSHOT' suffix prior to checking the release date. 
Please add an option to the 'changes-check' goal to allow skipping snapshot 
versions.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MCHANGES-272) Please add an option to the 'changes-check' goal to allow skipping release date checks of snapshot versions.

2012-01-11 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MCHANGES-272:
---

Attachment: MCHANGES-272.patch

Patch adding a  'skipSnapshots' parameter to the 'changes-check' goal.

 Please add an option to the 'changes-check' goal to allow skipping release 
 date checks of snapshot versions.
 

 Key: MCHANGES-272
 URL: https://jira.codehaus.org/browse/MCHANGES-272
 Project: Maven 2.x Changes Plugin
  Issue Type: New Feature
Affects Versions: 2.6
Reporter: Christian Schulte
Priority: Trivial
 Attachments: MCHANGES-272.patch


 The 'changes-check' goal treats snapshot versions the same way as release 
 versions by removing the '-SNAPSHOT' suffix prior to checking the release 
 date. Please add an option to the 'changes-check' goal to allow skipping 
 snapshot versions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MPIR-238) Dependency File Details section of the dependencies report shows 'target/classes' for reactor artifacts.

2011-12-28 Thread Christian Schulte (JIRA)
Christian Schulte created MPIR-238:
--

 Summary: Dependency File Details section of the dependencies 
report shows 'target/classes' for reactor artifacts.
 Key: MPIR-238
 URL: https://jira.codehaus.org/browse/MPIR-238
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Bug
  Components: dependency-info
Affects Versions: 2.4
Reporter: Christian Schulte
Priority: Minor


Generating the dependencies report in a multi-module project leads to incorrect 
entries in the 'Dependency File Details' section of the dependencies report. 
For example, the [Maven Release Plugin Dependency File 
Details|http://maven.apache.org/plugins/maven-release-plugin/dependencies.html#Dependency_File_Details]
 report contains the following entry: 

||Filename||Size||Entries||Classes||Packages||JDK Rev||Debug||
|maven-release-manager/target/classes|-|0|0|0|-|release|

Building the site of a single module ('mvn site' in that modules directory), 
the correct entries are shown.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MNG-5222) Maven 3 no longer logs warnings about deprecated plugin parameters.

2011-12-28 Thread Christian Schulte (JIRA)
Christian Schulte created MNG-5222:
--

 Summary: Maven 3 no longer logs warnings about deprecated plugin 
parameters.
 Key: MNG-5222
 URL: https://jira.codehaus.org/browse/MNG-5222
 Project: Maven 2  3
  Issue Type: Wish
  Components: Plugins and Lifecycle
Affects Versions: 3.0.3
Reporter: Christian Schulte
Priority: Minor


Providing a value for a deprecated plugin parameter, Maven 2.2.1 used to log a 
warning. Currently Maven 3 does not.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MPIR-238) Dependency File Details section of the dependencies report shows 'target/classes' for reactor artifacts.

2011-12-28 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MPIR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=287015#comment-287015
 ] 

Christian Schulte edited comment on MPIR-238 at 12/28/11 2:50 PM:
--

The cause is class 'org.apache.maven.ReactorReader' falling back to returning 
directories when the 'compile' phase has completed which is the case for 
various report plugins marked '@execute phase=generate-test-sources'. 
MPIR-238.patch contains a patch for the dependencies report adding '@execute 
phase=package' to make the reactor reader stop returning directories. 
MPIR-238-ReactorReader.patch contains a patch for that class to not resolve to 
directories when not executing the default lifecycle.


  was (Author: schulte2005):
The cause is class 'org.apache.maven.ReactorReader' falling back to 
returning directories when the 'compile' phase has completed which is the case 
for various report plugins marked '@execute phase=generate-sources'. 
MPIR-238.patch contains a patch for the dependencies report adding '@execute 
phase=package' to make the reactor reader stop returning directories. 
MPIR-238-ReactorReader.patch contains a patch for that class to not resolve to 
directories when not executing the default lifecycle.

  
 Dependency File Details section of the dependencies report shows 
 'target/classes' for reactor artifacts.
 

 Key: MPIR-238
 URL: https://jira.codehaus.org/browse/MPIR-238
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Bug
  Components: dependency-info
Affects Versions: 2.4
Reporter: Christian Schulte
Priority: Minor
 Attachments: MPIR-238.patch, MPIR-238-ReactorReader.patch


 Generating the dependencies report in a multi-module project leads to 
 incorrect entries in the 'Dependency File Details' section of the 
 dependencies report. For example, the [Maven Release Plugin Dependency File 
 Details|http://maven.apache.org/plugins/maven-release-plugin/dependencies.html#Dependency_File_Details]
  report contains the following entry: 
 ||Filename||Size||Entries||Classes||Packages||JDK Rev||Debug||
 |maven-release-manager/target/classes|-|0|0|0|-|release|
 Building the site of a single module ('mvn site' in that modules directory), 
 the correct entries are shown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MPIR-238) Dependency File Details section of the dependencies report shows 'target/classes' for reactor artifacts.

2011-12-28 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MPIR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=287016#comment-287016
 ] 

Christian Schulte commented on MPIR-238:


This also affects the 'Dependency Repository Locations' report, which does not 
link to snapshot repositories in such situations.


 Dependency File Details section of the dependencies report shows 
 'target/classes' for reactor artifacts.
 

 Key: MPIR-238
 URL: https://jira.codehaus.org/browse/MPIR-238
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Bug
  Components: dependency-info
Affects Versions: 2.4
Reporter: Christian Schulte
Priority: Minor
 Attachments: MPIR-238.patch, MPIR-238-ReactorReader.patch


 Generating the dependencies report in a multi-module project leads to 
 incorrect entries in the 'Dependency File Details' section of the 
 dependencies report. For example, the [Maven Release Plugin Dependency File 
 Details|http://maven.apache.org/plugins/maven-release-plugin/dependencies.html#Dependency_File_Details]
  report contains the following entry: 
 ||Filename||Size||Entries||Classes||Packages||JDK Rev||Debug||
 |maven-release-manager/target/classes|-|0|0|0|-|release|
 Building the site of a single module ('mvn site' in that modules directory), 
 the correct entries are shown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MPIR-238) Dependency File Details section of the dependencies report shows 'target/classes' for reactor artifacts.

2011-12-28 Thread Christian Schulte (JIRA)

 [ 
https://jira.codehaus.org/browse/MPIR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MPIR-238:
---

Attachment: MPIR-238-ReactorReader.patch

Updated patch to test for the 'pre-clean' phase instead of 'clean'.


 Dependency File Details section of the dependencies report shows 
 'target/classes' for reactor artifacts.
 

 Key: MPIR-238
 URL: https://jira.codehaus.org/browse/MPIR-238
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Bug
  Components: dependency-info
Affects Versions: 2.4
Reporter: Christian Schulte
Priority: Minor
 Attachments: MPIR-238.patch, MPIR-238-ReactorReader.patch, 
 MPIR-238-ReactorReader.patch


 Generating the dependencies report in a multi-module project leads to 
 incorrect entries in the 'Dependency File Details' section of the 
 dependencies report. For example, the [Maven Release Plugin Dependency File 
 Details|http://maven.apache.org/plugins/maven-release-plugin/dependencies.html#Dependency_File_Details]
  report contains the following entry: 
 ||Filename||Size||Entries||Classes||Packages||JDK Rev||Debug||
 |maven-release-manager/target/classes|-|0|0|0|-|release|
 Building the site of a single module ('mvn site' in that modules directory), 
 the correct entries are shown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MJAVADOC-336) Reports contain temporary files due to usage of 'File.deleteOnExit'.

2011-12-26 Thread Christian Schulte (JIRA)
Christian Schulte created MJAVADOC-336:
--

 Summary: Reports contain temporary files due to usage of 
'File.deleteOnExit'.
 Key: MJAVADOC-336
 URL: https://jira.codehaus.org/browse/MJAVADOC-336
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.8
Reporter: Christian Schulte
Priority: Minor


The plugin creates temporary command line argument files (@file) in the output 
directory without removing them prior to e.g. site deployment. Please replace 
'File.deleteOnExit' with 'File.delete'.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MJAVADOC-336) Reports contain temporary files due to usage of 'File.deleteOnExit'.

2011-12-26 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MJAVADOC-336:
---

Attachment: MJAVADOC-336.patch

Patch replacing 'File.deleteOnExit' with 'File.delete'. Applying this patch, 
'mvn clean install -Prun-its' still succeeds for me.



 Reports contain temporary files due to usage of 'File.deleteOnExit'.
 

 Key: MJAVADOC-336
 URL: https://jira.codehaus.org/browse/MJAVADOC-336
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.8
Reporter: Christian Schulte
Priority: Minor
 Attachments: MJAVADOC-336.patch


 The plugin creates temporary command line argument files (@file) in the 
 output directory without removing them prior to e.g. site deployment. Please 
 replace 'File.deleteOnExit' with 'File.delete'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSITE-625) Please add an 'archive' parameter to the 'jar' goal of the 'maven-site-plugin'.

2011-12-21 Thread Christian Schulte (JIRA)
Christian Schulte created MSITE-625:
---

 Summary: Please add an 'archive' parameter to the 'jar' goal of 
the 'maven-site-plugin'. 
 Key: MSITE-625
 URL: https://jira.codehaus.org/browse/MSITE-625
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Wish
Affects Versions: 3.0
Reporter: Christian Schulte
Priority: Minor


{code}
/**
 * The archive configuration to use.
 * See a href=http://maven.apache.org/shared/maven-archiver/index.html;Maven 
Archiver Reference/a.
 *
 * @parameter
 */
private MavenArchiveConfiguration archive = new MavenArchiveConfiguration();
{code}


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSITE-625) Please add an 'archive' parameter to the 'jar' goal of the 'maven-site-plugin'.

2011-12-21 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MSITE-625:


Attachment: MSITE-625.patch

Patch adding parameters 'archive', 'archiveIncludes' and 'archiveExcludes'.


 Please add an 'archive' parameter to the 'jar' goal of the 
 'maven-site-plugin'. 
 

 Key: MSITE-625
 URL: https://jira.codehaus.org/browse/MSITE-625
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Wish
Affects Versions: 3.0
Reporter: Christian Schulte
Priority: Minor
 Attachments: MSITE-625.patch


 {code}
 /**
  * The archive configuration to use.
  * See a 
 href=http://maven.apache.org/shared/maven-archiver/index.html;Maven 
 Archiver Reference/a.
  *
  * @parameter
  */
 private MavenArchiveConfiguration archive = new MavenArchiveConfiguration();
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (MSHARED-213) Please add a method to class JarSignerUtil to test an archive to contain signature files.

2011-11-16 Thread Christian Schulte (JIRA)
Please add a method to class JarSignerUtil to test an archive to contain 
signature files.
-

 Key: MSHARED-213
 URL: https://jira.codehaus.org/browse/MSHARED-213
 Project: Maven Shared Components
  Issue Type: New Feature
  Components: maven-jarsigner
Affects Versions: maven-jarsigner-1.0
Reporter: Christian Schulte
Priority: Blocker




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (MSHARED-213) Please add a method to class JarSignerUtil to test an archive to contain signature files.

2011-11-16 Thread Christian Schulte (JIRA)

 [ 
https://jira.codehaus.org/browse/MSHARED-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MSHARED-213:
--

Attachment: MSHARED-213.patch

Patch adding a corresponding method.

 Please add a method to class JarSignerUtil to test an archive to contain 
 signature files.
 -

 Key: MSHARED-213
 URL: https://jira.codehaus.org/browse/MSHARED-213
 Project: Maven Shared Components
  Issue Type: New Feature
  Components: maven-jarsigner
Affects Versions: maven-jarsigner-1.0
Reporter: Christian Schulte
Priority: Blocker
 Attachments: MSHARED-213.patch




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (MSHARED-214) Method 'JarSignerUtil.isSignatureFile( String entryName )' needs to also account for files ending in '.EC'.

2011-11-16 Thread Christian Schulte (JIRA)
Method 'JarSignerUtil.isSignatureFile( String entryName )' needs to also 
account for files ending in '.EC'.
---

 Key: MSHARED-214
 URL: https://jira.codehaus.org/browse/MSHARED-214
 Project: Maven Shared Components
  Issue Type: Bug
  Components: maven-jarsigner
Affects Versions: maven-jarsigner-1.0
Reporter: Christian Schulte




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (MSHARED-214) Method 'JarSignerUtil.isSignatureFile( String entryName )' needs to also account for files ending in '.EC'.

2011-11-16 Thread Christian Schulte (JIRA)

 [ 
https://jira.codehaus.org/browse/MSHARED-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MSHARED-214:
--

Attachment: MSHARED-214.patch

Patch adding a corresponding check.

 Method 'JarSignerUtil.isSignatureFile( String entryName )' needs to also 
 account for files ending in '.EC'.
 ---

 Key: MSHARED-214
 URL: https://jira.codehaus.org/browse/MSHARED-214
 Project: Maven Shared Components
  Issue Type: Bug
  Components: maven-jarsigner
Affects Versions: maven-jarsigner-1.0
Reporter: Christian Schulte
 Attachments: MSHARED-214.patch




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (MJARSIGNER-19) Make mojo code reusable from another mojo + customize the working directory.

2011-10-17 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MJARSIGNER-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=281418#comment-281418
 ] 

Christian Schulte commented on MJARSIGNER-19:
-

Just a quick note regarding MJARSIGNER-9. Will it be possible to extend the 
shared component to support toolchains ? Haven't looked at it that closely.


 Make mojo code reusable from another mojo + customize the working directory.
 

 Key: MJARSIGNER-19
 URL: https://jira.codehaus.org/browse/MJARSIGNER-19
 Project: Maven 2.x Jar Signer Plugin
  Issue Type: Improvement
Affects Versions: 1.2
Reporter: Tony Chemit
Priority: Trivial
 Attachments: create-jarsigner-sharedcomponent.diff, 
 MJARSIGNER-19.patch


 In the webstart-maven-plugin We used the old jarsigner mojo (from the jar 
 plugin).
 We'd like to use now this plugin as the mojo from the jar plugin is 
 deprecated for this one (see MWEBSTART-149)
 Moreover, we want to use yet another working directory and at the moment in 
 the mojo this is hardcoed to project.getBasedir().
 Here is a patch which fix our needs.
 Hope this patch will be apply soon, I would really like to use your mojo :)
 Thanks for your work.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (MJARSIGNER-21) jars signed using Java 7 have invalid SHA1 signature

2011-10-17 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MJARSIGNER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=281422#comment-281422
 ] 

Christian Schulte commented on MJARSIGNER-21:
-

Signing with JDK 7 and verifying with JDK 5 and 6 works for me. Can you try 
unsigning the archives prior to signing (removeExistingSignatures parameter) ? 
What exactly is invalid about the signatures ?


 jars signed using Java 7 have invalid SHA1 signature
 --

 Key: MJARSIGNER-21
 URL: https://jira.codehaus.org/browse/MJARSIGNER-21
 Project: Maven 2.x Jar Signer Plugin
  Issue Type: Bug
Affects Versions: 1.2
 Environment: Java 7, Maven 2.2.1
Reporter: Mike Calmus
Priority: Critical

 Using the plugin with Java 6 works fine. When I use it with Java 7, my applet 
 won't load because the SHA1 signatures are invalid.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Issue Comment Edited: (MJARSIGNER-21) jars signed using Java 7 have invalid SHA1 signature

2011-10-17 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MJARSIGNER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=281455#comment-281455
 ] 

Christian Schulte edited comment on MJARSIGNER-21 at 10/17/11 3:06 PM:
---

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6561126
http://hg.openjdk.java.net/jdk7/tl/jdk/rev/29b076bfeafd

I think you need to use '-digestalg SHA-1' with JDK 7 or '-digestalg SHA-256' 
with JDK 6 to make this work.

{code:xml}
configuration
  arguments
argument-digestalg/argument
argument${jarsigner.digestalg}/argument
  /argument
/configuration
{code}


  was (Author: schulte2005):
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6561126
http://hg.openjdk.java.net/jdk7/tl/jdk/rev/29b076bfeafd

I think you need to use '-digestalg SHA-1' with JDK 7 or '-digestalg SHA-256' 
with JDK 6 to make this work.

{code:xml}
configuration
  arguments
argument-digestalg/argument
argument${jarsigner.digestalg}/argument
  /argument
/configuration
{code:xml}

  
 jars signed using Java 7 have invalid SHA1 signature
 --

 Key: MJARSIGNER-21
 URL: https://jira.codehaus.org/browse/MJARSIGNER-21
 Project: Maven 2.x Jar Signer Plugin
  Issue Type: Bug
Affects Versions: 1.2
 Environment: Java 7, Maven 2.2.1
Reporter: Mike Calmus
Priority: Critical

 Using the plugin with Java 6 works fine. When I use it with Java 7, my applet 
 won't load because the SHA1 signatures are invalid.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (MJARSIGNER-21) jars signed using Java 7 have invalid SHA1 signature

2011-10-17 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MJARSIGNER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=281455#comment-281455
 ] 

Christian Schulte commented on MJARSIGNER-21:
-

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6561126
http://hg.openjdk.java.net/jdk7/tl/jdk/rev/29b076bfeafd

I think you need to use '-digestalg SHA-1' with JDK 7 or '-digestalg SHA-256' 
with JDK 6 to make this work.

{code:xml}
configuration
  arguments
argument-digestalg/argument
argument${jarsigner.digestalg}/argument
  /argument
/configuration
{code:xml}


 jars signed using Java 7 have invalid SHA1 signature
 --

 Key: MJARSIGNER-21
 URL: https://jira.codehaus.org/browse/MJARSIGNER-21
 Project: Maven 2.x Jar Signer Plugin
  Issue Type: Bug
Affects Versions: 1.2
 Environment: Java 7, Maven 2.2.1
Reporter: Mike Calmus
Priority: Critical

 Using the plugin with Java 6 works fine. When I use it with Java 7, my applet 
 won't load because the SHA1 signatures are invalid.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (MJARSIGNER-19) Make mojo code reusable from another mojo + customize the working directory.

2011-10-17 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MJARSIGNER-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=281459#comment-281459
 ] 

Christian Schulte commented on MJARSIGNER-19:
-

Due to MJARSIGNER-18, class JarSignerUtil may need to provide an 'isSigned( 
java.io.File jar )' method which scans an archive for any signature files to 
exist.


 Make mojo code reusable from another mojo + customize the working directory.
 

 Key: MJARSIGNER-19
 URL: https://jira.codehaus.org/browse/MJARSIGNER-19
 Project: Maven 2.x Jar Signer Plugin
  Issue Type: Improvement
Affects Versions: 1.2
Reporter: Tony Chemit
Priority: Trivial
 Attachments: create-jarsigner-sharedcomponent.diff, 
 MJARSIGNER-19.patch


 In the webstart-maven-plugin We used the old jarsigner mojo (from the jar 
 plugin).
 We'd like to use now this plugin as the mojo from the jar plugin is 
 deprecated for this one (see MWEBSTART-149)
 Moreover, we want to use yet another working directory and at the moment in 
 the mojo this is hardcoed to project.getBasedir().
 Here is a patch which fix our needs.
 Hope this patch will be apply soon, I would really like to use your mojo :)
 Thanks for your work.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (MJARSIGNER-19) Make mojo code reusable from another mojo + customize the working directory.

2011-10-17 Thread Christian Schulte (JIRA)

[ 
https://jira.codehaus.org/browse/MJARSIGNER-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=281460#comment-281460
 ] 

Christian Schulte commented on MJARSIGNER-19:
-

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6870812
http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0d7c64c023c6

Method 'JarSignerUtil.isSignatureFile( String entryName )' may need to also 
account for files ending in '.EC'.


 Make mojo code reusable from another mojo + customize the working directory.
 

 Key: MJARSIGNER-19
 URL: https://jira.codehaus.org/browse/MJARSIGNER-19
 Project: Maven 2.x Jar Signer Plugin
  Issue Type: Improvement
Affects Versions: 1.2
Reporter: Tony Chemit
Priority: Trivial
 Attachments: create-jarsigner-sharedcomponent.diff, 
 MJARSIGNER-19.patch


 In the webstart-maven-plugin We used the old jarsigner mojo (from the jar 
 plugin).
 We'd like to use now this plugin as the mojo from the jar plugin is 
 deprecated for this one (see MWEBSTART-149)
 Moreover, we want to use yet another working directory and at the moment in 
 the mojo this is hardcoed to project.getBasedir().
 Here is a patch which fix our needs.
 Hope this patch will be apply soon, I would really like to use your mojo :)
 Thanks for your work.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (MPMD-128) Xref link generation regression with Maven 3

2011-08-24 Thread Christian Schulte (JIRA)

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

Christian Schulte updated MPMD-128:
---

Attachment: MPMD-128-IT.patch

Patch adding a corresponding integration test.


 Xref link generation regression with Maven 3
 

 Key: MPMD-128
 URL: https://jira.codehaus.org/browse/MPMD-128
 Project: Maven 2.x PMD Plugin
  Issue Type: Bug
  Components: CPD, PMD
Affects Versions: 2.5
 Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 11:58:32+0100)
 Java version: 1.6.0_20
 Java home: /usr/lib/jvm/java-6-openjdk/jre
 Default locale: en_GB, platform encoding: UTF-8
 OS name: linux version: 2.6.32-27-generic arch: i386 Family: unix
Reporter: Marc Rohlfs
Priority: Minor
 Attachments: MPMD-128-IT.patch, MPMD-128_sample.zip


 When the site reports are created with Maven 3, the PMD plugin doesn't 
 generate the links to the Source Xref pages, when the JXR Plugin hasn't been 
 executed before.
 The plugin looks for the {{xrefLocation}} directory and if it doesn't exist, 
 it checks if the JXR plugin is configured for the project (see 
 http://maven.apache.org/plugins/maven-checkstyle-plugin/xref/org/apache/maven/plugin/checkstyle/CheckstyleReport.html#670).
  To properly generate the Xref links when the report is created with Maven 3, 
 the plugin should also check the {{reportPlugins}} paramerter of the Site 
 plugin configuration.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (MCHECKSTYLE-150) Xref link generation regression with Maven 3

2011-08-24 Thread Christian Schulte (JIRA)

 [ 
https://jira.codehaus.org/browse/MCHECKSTYLE-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MCHECKSTYLE-150:
--

Attachment: MCHECKSTYLE-150-IT.patch

Patch adding a corresponding integration test.

 Xref link generation regression with Maven 3
 

 Key: MCHECKSTYLE-150
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-150
 Project: Maven 2.x Checkstyle Plugin
  Issue Type: Bug
Affects Versions: 2.6
 Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 11:58:32+0100)
 Java version: 1.6.0_20
 Java home: /usr/lib/jvm/java-6-openjdk/jre
 Default locale: en_GB, platform encoding: UTF-8
 OS name: linux version: 2.6.32-27-generic arch: i386 Family: unix
Reporter: Marc Rohlfs
Priority: Minor
 Attachments: MCHECKSTYLE-150-IT.patch, MCHECKSTYLE-150_sample.zip


 When the site reports are created with Maven 3, the Checkstyle plugin doesn't 
 generate the links to the Source Xref pages, when the JXR Plugin hasn't been 
 executed before.
 The plugin looks for the {{xrefLocation}} directory and if it doesn't exist, 
 it checks if the JXR plugin is configured for the project (see 
 http://maven.apache.org/plugins/maven-checkstyle-plugin/xref/org/apache/maven/plugin/checkstyle/CheckstyleReport.html#670).
  To properly generate the Xref links when the report is created with Maven 3, 
 the plugin should also check the {{reportPlugins}} paramerter of the Site 
 plugin configuration.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Closed: (JXR-91) Javadoc link generation not working when using the 'reportPlugins' parameter of the site plugin instead of the 'reporting' section of the pom.

2011-08-23 Thread Christian Schulte (JIRA)

 [ 
https://jira.codehaus.org/browse/JXR-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed JXR-91.


Resolution: Not A Bug

Caused by having

MAVEN_OPTS=... -DlinkJavadoc=false ...

in the ~/.mavenrc file.

Sorry for the noise.


 Javadoc link generation not working when using the 'reportPlugins' parameter 
 of the site plugin instead of the 'reporting' section of the pom.
 --

 Key: JXR-91
 URL: https://jira.codehaus.org/browse/JXR-91
 Project: Maven JXR
  Issue Type: Wish
  Components: maven2 jxr plugin
Affects Versions: 2.3
Reporter: Christian Schulte
Assignee: Benson Margulies
Priority: Minor

 The JXR plugin doesn't generate the links to the Javadoc pages when using the 
 'reportPlugins' parameter of the site plugin instead of the 'reporting' 
 section of the pom.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




<    5   6   7   8   9   10   11   >