[jira] Commented: (MNG-4639) Be able to profile a maven build

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-4639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=253165#action_253165
 ] 

Jerome Lacoste commented on MNG-4639:
-

For those who are interested in this feature:

* hudson already does this for you (at least in the maven3 support). the time 
for the mojos is stored in the build.xml (Search for ExecutedMojo). There's 
also a per module page summary on hudson that will display time used per mojo
* you can implement the same in maven by looking at 
  
http://maven.apache.org/ref/3.0.2/maven-core/apidocs/org/apache/maven/execution/AbstractExecutionListener.html.
 This is used in  and 
./maven-embedder/src/main/java/org/apache/maven/cli/ExecutionEventLogger.java 
and instantiated by 
maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
  You might for example want to add a new 'profiling' option. Not to confuse 
with maven profiles..
* if you are interested by the downloads time, you might want to look at 
./maven-embedder/src/main/java/org/apache/maven/cli/AbstractMavenTransferListener.java
  but as downloads might happen in parallel, I am not sure you will get the 
information you want (i.e. user time spent waiting for download to complete)

Hope that helps.

 Be able to profile a maven build
 

 Key: MNG-4639
 URL: http://jira.codehaus.org/browse/MNG-4639
 Project: Maven 2  3
  Issue Type: New Feature
Reporter: Baptiste MATHUS
 Fix For: Issues to be reviewed for 3.x


 A common problem with builds is that they can become quite long to run. As it 
 is a know anti-pattern for CI for example, one has the need to try and 
 optimize their builds.
 The thing is: the current granularity isn't sufficiently precise. In fact, 
 you only only the time spent to build each module. This is a good start, 
 though.
 Maven currently displays something like the following (let's speak only about 
 maven 3):
 {quote}
 [INFO] Reactor Summary:
 [INFO] 
 
 [INFO] p1  SUCCESS [1:12.938s]
 [INFO] p2  SUCCESS [5.750s]
 [INFO] p3  SUCCESS [3:58.488s]
 [INFO] p4  SUCCESS [24.437s]
 [INFO] p5  SUCCESS [1.563s]
 [INFO] 
 
 [INFO] 
 
 [INFO] BUILD SUCCESSFUL
 [INFO] 
 
 [INFO] Total time: 5 minutes 46 seconds
 {quote}
 What would be great would be adding an option that would higher the details. 
 Something like -A/--analyze (--profile would be too close to -P/profile 
 option) would add detailed analysis, would print something like. 
 {quote}
 [INFO] Reactor Summary:
 [INFO] 
 
 [INFO] p1  SUCCESS [1:12.938s]
 clean:clean (somepkg.CleanMojo) : 10.3s
 compiler:compile (...) : 50s
 ...
 and so on
 {quote}
 I'm not very well aware the level of details maven 3 API could provide. So 
 the printing above could become irrelevant. In this case, printing a 
 dedicated html or so report might be a better choice.
 Cheers
 PS : Though I'm really not introduced into maven code, if you think it's not 
 too complicated, I could try and contribute on this field if I'm given some 
 hints or good starting points. 

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

[jira] Created: (MSHARED-178) Verifier#setDebug seems ineffective

[Jerome Lacoste (JIRA)]

Verifier#setDebug seems ineffective
---

 Key: MSHARED-178
 URL: http://jira.codehaus.org/browse/MSHARED-178
 Project: Maven Shared Components
  Issue Type: Bug
  Components: maven-verifier
Affects Versions: maven-verifier 1.2
Reporter: Jerome Lacoste


Looking at the Verifier code: 
http://maven.apache.org/shared/maven-verifier/xref/index.html

it seems that this.debug is only used in the constructor 
(http://maven.apache.org/shared/maven-verifier/xref/org/apache/maven/it/Verifier.html#130).
 The setDebug() method 
(http://maven.apache.org/shared/maven-verifier/xref/org/apache/maven/it/Verifier.html#2056)
 will then be ineffective.

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

[jira] Commented: (MPIR-171) support TimeZones as a timezone

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MPIR-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=199189#action_199189
 ] 

Jerome Lacoste commented on MPIR-171:
-

Looks like the new page doesn't work on my Firefox 3.5, but works in opera 
10.01 and chromium 4.0.252.0.
No error in the javascript console it seems...


 support TimeZones as a timezone
 -

 Key: MPIR-171
 URL: http://jira.codehaus.org/browse/MPIR-171
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
Affects Versions: 2.1.2
Reporter: James Nord
Priority: Trivial

 The POM XSD defiens the TimeZone as an xs:string (although the descriptions 
 says an integer between -11 and 12)
 If the desctription is enforced you can not be in a timezone that is not a 
 multiple of 1 hour away from UTC (e.g. certain parts of india)
 So the description is wrong and it's just a String.  
 So why not support a full formatted timezone such as Europe/London, then the 
 mpir can use funky javascript to show your actual time including any daylight 
 saving offset. (as opposed to a fixed offset from GMT ignoring DST changes)
 e.g. support
 developers
 developer
 idbob/id
 nameBob Hacker/name
 emailb...@example.com/email
 timezoneEurope/London/timezone
 roles
 roledeveloper/role
 /roles
 /developer
 /developers
 Currently the site shows NaN for the Current time.

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

[jira] Issue Comment Edited: (MPIR-171) support TimeZones as a timezone

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MPIR-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=199162#action_199162
 ] 

Jerome Lacoste edited comment on MPIR-171 at 11/24/09 3:48 AM:
---

I've implemented a HTML version of the team-list that uses 
http://js.fleegix.org/plugins/date/date
to support String timezones.

See http://coffeebreaks.org/tmp/mvn-mpir-171/team-list2.html for demo

the diff to the generated files is

{code}
--- team-list.html  2009-11-23 23:38:37.0 +0100
+++ team-list2.html 2009-11-24 09:55:37.0 +0100
@@ -521,18 +521,28 @@
 /table
 /div
 /div
+script type=text/javascript src=scripts/fleegix.js/
+script type=text/javascript src=scripts/date.js/
 script type=text/javascript
 function offsetDate(id, offset) {
-var now = new Date();
-var nowTime = now.getTime();
-var localOffset = now.getTimezoneOffset();
-var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset * 
60 * 1000 );
-var developerDate = new Date(developerTime);
-
+var developerDate;
+if (offset.indexOf('/') != -1) {
+  var dt = new fleegix.date.Date();
+  dt.setTimezone(offset);
+  developerDate = new Date(dt);
+} else {
+  var now = new Date();
+  var nowTime = now.getTime();
+  var localOffset = now.getTimezoneOffset();
+  var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset 
* 60 * 1000 );
+  developerDate = new Date(developerTime);
+}
 document.getElementById(id).innerHTML = developerDate;
 }
 
 function init(){
+fleegix.date.timezone.zoneFileBasePath = './tz/';
+fleegix.date.timezone.init();
 offsetDate('developer-0', '-5');
 offsetDate('developer-1', '+1');
 offsetDate('developer-3', '+1');
{code}

general drawbacks of such a solution
* the pages generate more traffic (javascripts, zoneInfo files)
* zoneInfo values may not be valid in the future (pages may not work in some 
years if the tz isn't updated)


the drawbacks of the current demo:
* the zoneInfo files are not trimmed for space
* we use a simple check to identify String timezones. Is it robust enough ?
* there should probably be some try/catch to detect issues.

Ideally the method offsetDate() should be renamed.

Let me know if that seems interesting, and I can look into changing the code to 
support this.






  was (Author: lacostej):
I've implemented a HTML version of the team-list that uses 
http://js.fleegix.org/plugins/date/date
to support String timezones.

See http://coffeebreaks.org/tmp/mvn-mpir-171/team-list2.html for demo

the diff to the generated files is

{code}
--- team-list2.html 2009-11-24 01:07:46.0 +0100
+++ team-list.html  2009-11-23 23:38:37.0 +0100
@@ -521,29 +521,18 @@
 /table
 /div
 /div
-script type=text/javascript src=scripts/fleegix.js/
-script type=text/javascript src=scripts/date.js/
 script type=text/javascript
 function offsetDate(id, offset) {
-var developerDate;
-if (offset.indexOf('/') != -1) {
-  var dt = new fleegix.date.Date();
-  dt.setTimezone(offset);
-  offset = - dt.getTimezoneOffset() / 60;
-  developerDate = new Date(dt);
-} else {
-  var now = new Date();
-  var nowTime = now.getTime();
-  var localOffset = now.getTimezoneOffset();
-  var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset 
* 60 * 1000 );
-  developerDate = new Date(developerTime);
-}
+var now = new Date();
+var nowTime = now.getTime();
+var localOffset = now.getTimezoneOffset();
+var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset * 
60 * 1000 );
+var developerDate = new Date(developerTime);
+
 document.getElementById(id).innerHTML = developerDate;
 }
 
 function init(){
-fleegix.date.timezone.zoneFileBasePath = './tz/';
-fleegix.date.timezone.init();
 offsetDate('developer-0', '-5');
 offsetDate('developer-1', '+1');
 offsetDate('developer-3', '+1');
{code}

general drawbacks of such a solution
* the pages generate more traffic (javascripts, zoneInfo files)
* zoneInfo values may not be valid in the future (pages may not work in some 
years if the tz isn't updated)


the drawbacks of the current demo:
* the zoneInfo files are not trimmed for space
* we use a simple check to identify String timezones. Is it robust enough ?
* there should probably be some try/catch to detect issues.

Ideally the method offsetDate() should be renamed.

Let me know if that seems interesting, and I can look into changing the code to 
support this.





  
 support TimeZones as a timezone
 -

 Key: MPIR-171
 URL: http://jira.codehaus.org/browse/MPIR-171
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
Affects Versions: 2.1.2
Reporter: 

[jira] Issue Comment Edited: (MPIR-171) support TimeZones as a timezone

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MPIR-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=199162#action_199162
 ] 

Jerome Lacoste edited comment on MPIR-171 at 11/24/09 4:23 AM:
---

I've implemented a HTML version of the team-list that uses 
http://js.fleegix.org/plugins/date/date
to support String timezones.

See http://coffeebreaks.org/tmp/mvn-mpir-171/team-list2.html for demo

the diff to the generated files is

{code}
--- team-list.html  2009-11-23 23:38:37.0 +0100
+++ team-list2.html 2009-11-24 11:22:10.0 +0100
@@ -521,18 +521,28 @@
 /table
 /div
 /div
+script type=text/javascript src=scripts/fleegix.js/script
+script type=text/javascript src=scripts/date.js/script
 script type=text/javascript
 function offsetDate(id, offset) {
-var now = new Date();
-var nowTime = now.getTime();
-var localOffset = now.getTimezoneOffset();
-var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset * 
60 * 1000 );
-var developerDate = new Date(developerTime);
-
+var developerDate;
+if (offset.indexOf('/') != -1) {
+  var dt = new fleegix.date.Date();
+  dt.setTimezone(offset);
+  developerDate = new Date(dt);
+} else {
+  var now = new Date();
+  var nowTime = now.getTime();
+  var localOffset = now.getTimezoneOffset();
+  var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset 
* 60 * 1000 );
+  developerDate = new Date(developerTime);
+}
 document.getElementById(id).innerHTML = developerDate;
 }
 
 function init(){
+fleegix.date.timezone.zoneFileBasePath = './tz/';
+fleegix.date.timezone.init();
 offsetDate('developer-0', '-5');
 offsetDate('developer-1', '+1');
 offsetDate('developer-3', '+1');
{code}

general drawbacks of such a solution
* the pages generate more traffic (javascripts, zoneInfo files)
* zoneInfo values may not be valid in the future (pages may not work in some 
years if the tz isn't updated)


the drawbacks of the current demo:
* the zoneInfo files are not trimmed for space
* we use a simple check to identify String timezones. Is it robust enough ?
* there should probably be some try/catch to detect issues.

Ideally the method offsetDate() should be renamed.

Let me know if that seems interesting, and I can look into changing the code to 
support this.






  was (Author: lacostej):
I've implemented a HTML version of the team-list that uses 
http://js.fleegix.org/plugins/date/date
to support String timezones.

See http://coffeebreaks.org/tmp/mvn-mpir-171/team-list2.html for demo

the diff to the generated files is

{code}
--- team-list.html  2009-11-23 23:38:37.0 +0100
+++ team-list2.html 2009-11-24 09:55:37.0 +0100
@@ -521,18 +521,28 @@
 /table
 /div
 /div
+script type=text/javascript src=scripts/fleegix.js/
+script type=text/javascript src=scripts/date.js/
 script type=text/javascript
 function offsetDate(id, offset) {
-var now = new Date();
-var nowTime = now.getTime();
-var localOffset = now.getTimezoneOffset();
-var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset * 
60 * 1000 );
-var developerDate = new Date(developerTime);
-
+var developerDate;
+if (offset.indexOf('/') != -1) {
+  var dt = new fleegix.date.Date();
+  dt.setTimezone(offset);
+  developerDate = new Date(dt);
+} else {
+  var now = new Date();
+  var nowTime = now.getTime();
+  var localOffset = now.getTimezoneOffset();
+  var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset 
* 60 * 1000 );
+  developerDate = new Date(developerTime);
+}
 document.getElementById(id).innerHTML = developerDate;
 }
 
 function init(){
+fleegix.date.timezone.zoneFileBasePath = './tz/';
+fleegix.date.timezone.init();
 offsetDate('developer-0', '-5');
 offsetDate('developer-1', '+1');
 offsetDate('developer-3', '+1');
{code}

general drawbacks of such a solution
* the pages generate more traffic (javascripts, zoneInfo files)
* zoneInfo values may not be valid in the future (pages may not work in some 
years if the tz isn't updated)


the drawbacks of the current demo:
* the zoneInfo files are not trimmed for space
* we use a simple check to identify String timezones. Is it robust enough ?
* there should probably be some try/catch to detect issues.

Ideally the method offsetDate() should be renamed.

Let me know if that seems interesting, and I can look into changing the code to 
support this.





  
 support TimeZones as a timezone
 -

 Key: MPIR-171
 URL: http://jira.codehaus.org/browse/MPIR-171
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
Affects Versions: 2.1.2
Reporter: James Nord
Priority: 

[jira] Issue Comment Edited: (MPIR-171) support TimeZones as a timezone

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MPIR-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=199189#action_199189
 ] 

Jerome Lacoste edited comment on MPIR-171 at 11/24/09 4:25 AM:
---

strikeLooks like the new page doesn't work on my Firefox 3.5, but works in 
opera 10.01 and chromium 4.0.252.0.
No error in the javascript console it seems.../strike

page tested and works in opera, ff and chromium. Problem was use of script/ 
while page was identified as HTML (due to extension it seems) even if the 
doctype is XHTML. Thus the loading of the external scripts failed.
Using script/script solves it.


  was (Author: lacostej):
Looks like the new page doesn't work on my Firefox 3.5, but works in opera 
10.01 and chromium 4.0.252.0.
No error in the javascript console it seems...

  
 support TimeZones as a timezone
 -

 Key: MPIR-171
 URL: http://jira.codehaus.org/browse/MPIR-171
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
Affects Versions: 2.1.2
Reporter: James Nord
Priority: Trivial

 The POM XSD defiens the TimeZone as an xs:string (although the descriptions 
 says an integer between -11 and 12)
 If the desctription is enforced you can not be in a timezone that is not a 
 multiple of 1 hour away from UTC (e.g. certain parts of india)
 So the description is wrong and it's just a String.  
 So why not support a full formatted timezone such as Europe/London, then the 
 mpir can use funky javascript to show your actual time including any daylight 
 saving offset. (as opposed to a fixed offset from GMT ignoring DST changes)
 e.g. support
 developers
 developer
 idbob/id
 nameBob Hacker/name
 emailb...@example.com/email
 timezoneEurope/London/timezone
 roles
 roledeveloper/role
 /roles
 /developer
 /developers
 Currently the site shows NaN for the Current time.

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

[jira] Issue Comment Edited: (MPIR-171) support TimeZones as a timezone

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MPIR-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=199189#action_199189
 ] 

Jerome Lacoste edited comment on MPIR-171 at 11/24/09 4:26 AM:
---

--Looks like the new page doesn't work on my Firefox 3.5, but works in opera 
10.01 and chromium 4.0.252.0.
No error in the javascript console it seems...--

page tested and works in opera, ff and chromium. Problem was use of script/ 
while page was identified as HTML (due to extension it seems) even if the 
doctype is XHTML. Thus the loading of the external scripts failed.
Using script/script solves it.


  was (Author: lacostej):
strikeLooks like the new page doesn't work on my Firefox 3.5, but works 
in opera 10.01 and chromium 4.0.252.0.
No error in the javascript console it seems.../strike

page tested and works in opera, ff and chromium. Problem was use of script/ 
while page was identified as HTML (due to extension it seems) even if the 
doctype is XHTML. Thus the loading of the external scripts failed.
Using script/script solves it.

  
 support TimeZones as a timezone
 -

 Key: MPIR-171
 URL: http://jira.codehaus.org/browse/MPIR-171
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
Affects Versions: 2.1.2
Reporter: James Nord
Priority: Trivial

 The POM XSD defiens the TimeZone as an xs:string (although the descriptions 
 says an integer between -11 and 12)
 If the desctription is enforced you can not be in a timezone that is not a 
 multiple of 1 hour away from UTC (e.g. certain parts of india)
 So the description is wrong and it's just a String.  
 So why not support a full formatted timezone such as Europe/London, then the 
 mpir can use funky javascript to show your actual time including any daylight 
 saving offset. (as opposed to a fixed offset from GMT ignoring DST changes)
 e.g. support
 developers
 developer
 idbob/id
 nameBob Hacker/name
 emailb...@example.com/email
 timezoneEurope/London/timezone
 roles
 roledeveloper/role
 /roles
 /developer
 /developers
 Currently the site shows NaN for the Current time.

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

[jira] Issue Comment Edited: (MPIR-171) support TimeZones as a timezone

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MPIR-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=199189#action_199189
 ] 

Jerome Lacoste edited comment on MPIR-171 at 11/24/09 4:27 AM:
---

-Looks like the new page doesn't work on my Firefox 3.5, but works in opera 
10.01 and chromium 4.0.252.0. No error in the javascript console it seems...-

page tested and works in opera, ff and chromium. Problem was use of script/ 
while page was identified as HTML (due to extension it seems) even if the 
doctype is XHTML. Thus the loading of the external scripts failed.
Using script/script solves it.


  was (Author: lacostej):
--Looks like the new page doesn't work on my Firefox 3.5, but works in 
opera 10.01 and chromium 4.0.252.0.
No error in the javascript console it seems...--

page tested and works in opera, ff and chromium. Problem was use of script/ 
while page was identified as HTML (due to extension it seems) even if the 
doctype is XHTML. Thus the loading of the external scripts failed.
Using script/script solves it.

  
 support TimeZones as a timezone
 -

 Key: MPIR-171
 URL: http://jira.codehaus.org/browse/MPIR-171
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
Affects Versions: 2.1.2
Reporter: James Nord
Priority: Trivial

 The POM XSD defiens the TimeZone as an xs:string (although the descriptions 
 says an integer between -11 and 12)
 If the desctription is enforced you can not be in a timezone that is not a 
 multiple of 1 hour away from UTC (e.g. certain parts of india)
 So the description is wrong and it's just a String.  
 So why not support a full formatted timezone such as Europe/London, then the 
 mpir can use funky javascript to show your actual time including any daylight 
 saving offset. (as opposed to a fixed offset from GMT ignoring DST changes)
 e.g. support
 developers
 developer
 idbob/id
 nameBob Hacker/name
 emailb...@example.com/email
 timezoneEurope/London/timezone
 roles
 roledeveloper/role
 /roles
 /developer
 /developers
 Currently the site shows NaN for the Current time.

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

[jira] Commented: (MPIR-178) some reports have inconsistent line ending style

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MPIR-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=199072#action_199072
 ] 

Jerome Lacoste commented on MPIR-178:
-

First problem is in  
./src/main/java/org/apache/maven/report/projectinfo/TeamListReport.java

public void renderBody()
{

(hardcoded \n)

See also 
src/main/java/org/apache/maven/report/projectinfo/dependencies/renderer/DependenciesRenderer.java

with the hardcoded JAVASCRIPT instance

As for the dependency description:

See
private void printDescriptionsAndURLs( DependencyNode node, String uid )

but there I am not sure if the sink should be responsible for converting the \n 
or if the input should be sanitized before being sent as a parameter.

 some reports have inconsistent line ending style
 

 Key: MPIR-178
 URL: http://jira.codehaus.org/browse/MPIR-178
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Bug
  Components: dependencies, project-team
Affects Versions: 2.1.2
 Environment: Windows
Reporter: Oleg Estekhin
Priority: Minor

 Some of the reports generated by the plugin have inconsistent line ending 
 style. I have marked dependency and team-list components as affected by 
 probably other components can produce inconsistent line endings too.
 I am working on Windows so it is (somewhat) expected that files generated by 
 the plugin will have the CRLF line ending, but some files will have a mixed 
 line ending style due to different reasons.
 The plugin should enforce consistent line ending style in the output files. 
 It is possible that this issue is not caused by the plugin itself but 
 inherited from some of its dependencies that handle generic maven reporting 
 functionality, in this case please move the issue to the appropriate maven 
 component.
 Examples:
 *team-list.html*
 The following code fragment near the end of the file seems to always have the 
 LF line endings:
 {code}
 script type=text/javascript
 function offsetDate(id, offset) {
 var now = new Date();
 var nowTime = now.getTime();
 var localOffset = now.getTimezoneOffset();
 var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset 
 * 60 * 1000 );
 var developerDate = new Date(developerTime);
 document.getElementById(id).innerHTML = developerDate;
 }
 function init(){
 }
 window.onLoad = init();
 /script
 {code}
 This code is probably copied to the resulting report page from some string 
 literal with hard-coded line ending.
 *dependencies.html*
 The dependency report contains a dependency tree that has an I icon that 
 unhides a description of a particular dependency. The description text is 
 obtained from somewhere (the dependency pom?) and copied to the 
 dependencies.html as is, including its line ending style.
 For example, org.antlr:stringtemplate:jar:3.2 and antlr:antlr:jar:2.7.7 
 dependencies have a description that uses LF line endings. When these 
 artifacts are required either directly or indirectly then the project's 
 dependencies.html will contain both CRLF for generated code and LF for 
 copy-pasted descriptions.
 Check the http://maven-svn-wagon.googlecode.com/svn/site/dependencies.html, 
 lines 450-464 for the specific example.

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

[jira] Issue Comment Edited: (MPIR-171) support TimeZones as a timezone

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MPIR-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=199162#action_199162
 ] 

Jerome Lacoste edited comment on MPIR-171 at 11/23/09 6:16 PM:
---

I've implemented a HTML version of the team-list that uses 
http://js.fleegix.org/plugins/date/date
to support String timezones.

See http://coffeebreaks.org/tmp/mvn-mpir-171/team-list2.html for demo

the diff to the generated files is

{code}
--- team-list2.html 2009-11-24 01:07:46.0 +0100
+++ team-list.html  2009-11-23 23:38:37.0 +0100
@@ -521,29 +521,18 @@
 /table
 /div
 /div
-script type=text/javascript src=scripts/fleegix.js/
-script type=text/javascript src=scripts/date.js/
 script type=text/javascript
 function offsetDate(id, offset) {
-var developerDate;
-if (offset.indexOf('/') != -1) {
-  var dt = new fleegix.date.Date();
-  dt.setTimezone(offset);
-  offset = - dt.getTimezoneOffset() / 60;
-  developerDate = new Date(dt);
-} else {
-  var now = new Date();
-  var nowTime = now.getTime();
-  var localOffset = now.getTimezoneOffset();
-  var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset 
* 60 * 1000 );
-  developerDate = new Date(developerTime);
-}
+var now = new Date();
+var nowTime = now.getTime();
+var localOffset = now.getTimezoneOffset();
+var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset * 
60 * 1000 );
+var developerDate = new Date(developerTime);
+
 document.getElementById(id).innerHTML = developerDate;
 }
 
 function init(){
-fleegix.date.timezone.zoneFileBasePath = './tz/';
-fleegix.date.timezone.init();
 offsetDate('developer-0', '-5');
 offsetDate('developer-1', '+1');
 offsetDate('developer-3', '+1');
{code}

general drawbacks of such a solution
* the pages generate more traffic (javascripts, zoneInfo files)
* zoneInfo values may not be valid in the future (pages may not work in some 
years if the tz isn't updated)


the drawbacks of the current demo:
* the zoneInfo files are not trimmed for space
* we use a simple check to identify String timezones. Is it robust enough ?
* there should probably be some try/catch to detect issues.

Ideally the method offsetDate() should be renamed.

Let me know if that seems interesting, and I can look into changing the code to 
support this.






  was (Author: lacostej):
I've implemented a HTML version of the team-list that uses 
http://js.fleegix.org/plugins/date/date
to support String timezones.

See http://coffeebreaks.org/tmp/mvn-mpir-171/team-list2.html for demo

the diff to the generated files is

--- team-list2.html 2009-11-24 01:07:46.0 +0100
+++ team-list.html  2009-11-23 23:38:37.0 +0100
@@ -521,29 +521,18 @@
 /table
 /div
 /div
-script type=text/javascript src=scripts/fleegix.js/
-script type=text/javascript src=scripts/date.js/
 script type=text/javascript
 function offsetDate(id, offset) {
-var developerDate;
-if (offset.indexOf('/') != -1) {
-  var dt = new fleegix.date.Date();
-  dt.setTimezone(offset);
-  offset = - dt.getTimezoneOffset() / 60;
-  developerDate = new Date(dt);
-} else {
-  var now = new Date();
-  var nowTime = now.getTime();
-  var localOffset = now.getTimezoneOffset();
-  var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset 
* 60 * 1000 );
-  developerDate = new Date(developerTime);
-}
+var now = new Date();
+var nowTime = now.getTime();
+var localOffset = now.getTimezoneOffset();
+var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset * 
60 * 1000 );
+var developerDate = new Date(developerTime);
+
 document.getElementById(id).innerHTML = developerDate;
 }
 
 function init(){
-fleegix.date.timezone.zoneFileBasePath = './tz/';
-fleegix.date.timezone.init();
 offsetDate('developer-0', '-5');
 offsetDate('developer-1', '+1');
 offsetDate('developer-3', '+1');

general drawbacks of such a solution
* the pages generate more traffic (javascripts, zoneInfo files)
* zoneInfo values may not be valid in the future (pages may not work in some 
years if the tz isn't updated)


the drawbacks of the current demo:
* the zoneInfo files are not trimmed for space
* we use a simple check to identify String timezones. Is it robust enough ?
* there should probably be some try/catch to detect issues.

Ideally the method offsetDate() should be renamed.

Let me know if that seems interesting, and I can look into changing the code to 
support this.





  
 support TimeZones as a timezone
 -

 Key: MPIR-171
 URL: http://jira.codehaus.org/browse/MPIR-171
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
Affects 

[jira] Commented: (MPIR-171) support TimeZones as a timezone

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MPIR-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=199162#action_199162
 ] 

Jerome Lacoste commented on MPIR-171:
-

I've implemented a HTML version of the team-list that uses 
http://js.fleegix.org/plugins/date/date
to support String timezones.

See http://coffeebreaks.org/tmp/mvn-mpir-171/team-list2.html for demo

the diff to the generated files is

--- team-list2.html 2009-11-24 01:07:46.0 +0100
+++ team-list.html  2009-11-23 23:38:37.0 +0100
@@ -521,29 +521,18 @@
 /table
 /div
 /div
-script type=text/javascript src=scripts/fleegix.js/
-script type=text/javascript src=scripts/date.js/
 script type=text/javascript
 function offsetDate(id, offset) {
-var developerDate;
-if (offset.indexOf('/') != -1) {
-  var dt = new fleegix.date.Date();
-  dt.setTimezone(offset);
-  offset = - dt.getTimezoneOffset() / 60;
-  developerDate = new Date(dt);
-} else {
-  var now = new Date();
-  var nowTime = now.getTime();
-  var localOffset = now.getTimezoneOffset();
-  var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset 
* 60 * 1000 );
-  developerDate = new Date(developerTime);
-}
+var now = new Date();
+var nowTime = now.getTime();
+var localOffset = now.getTimezoneOffset();
+var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset * 
60 * 1000 );
+var developerDate = new Date(developerTime);
+
 document.getElementById(id).innerHTML = developerDate;
 }
 
 function init(){
-fleegix.date.timezone.zoneFileBasePath = './tz/';
-fleegix.date.timezone.init();
 offsetDate('developer-0', '-5');
 offsetDate('developer-1', '+1');
 offsetDate('developer-3', '+1');

general drawbacks of such a solution
* the pages generate more traffic (javascripts, zoneInfo files)
* zoneInfo values may not be valid in the future (pages may not work in some 
years if the tz isn't updated)


the drawbacks of the current demo:
* the zoneInfo files are not trimmed for space
* we use a simple check to identify String timezones. Is it robust enough ?
* there should probably be some try/catch to detect issues.

Ideally the method offsetDate() should be renamed.

Let me know if that seems interesting, and I can look into changing the code to 
support this.






 support TimeZones as a timezone
 -

 Key: MPIR-171
 URL: http://jira.codehaus.org/browse/MPIR-171
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
Affects Versions: 2.1.2
Reporter: James Nord
Priority: Trivial

 The POM XSD defiens the TimeZone as an xs:string (although the descriptions 
 says an integer between -11 and 12)
 If the desctription is enforced you can not be in a timezone that is not a 
 multiple of 1 hour away from UTC (e.g. certain parts of india)
 So the description is wrong and it's just a String.  
 So why not support a full formatted timezone such as Europe/London, then the 
 mpir can use funky javascript to show your actual time including any daylight 
 saving offset. (as opposed to a fixed offset from GMT ignoring DST changes)
 e.g. support
 developers
 developer
 idbob/id
 nameBob Hacker/name
 emailb...@example.com/email
 timezoneEurope/London/timezone
 roles
 roledeveloper/role
 /roles
 /developer
 /developers
 Currently the site shows NaN for the Current time.

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

[jira] Commented: (MECLIPSE-156) Plugin should support setting file encoding

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MECLIPSE-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=197036#action_197036
 ] 

Jerome Lacoste commented on MECLIPSE-156:
-

I was reading the code to try to fix another issue and there seems to be an 
issue with the latest commit

http://svn.apache.org/viewvc/maven/plugins/trunk/maven-eclipse-plugin/src/main/java/org/apache/maven/plugin/ide/IdeUtils.java?r1=825432r2=826602

in particular

http://svn.apache.org/viewvc/maven/plugins/trunk/maven-eclipse-plugin/src/main/java/org/apache/maven/plugin/ide/IdeUtils.java?view=annotate#l166

1. the check of this value shouldn't be made in the method, but probably in  
getCompilerSourceEncoding()

2. the return of getProperty() should be used.

I attach a patch that is completely untested !

 Plugin should support setting file encoding
 ---

 Key: MECLIPSE-156
 URL: http://jira.codehaus.org/browse/MECLIPSE-156
 Project: Maven 2.x Eclipse Plugin
  Issue Type: New Feature
Reporter: Ralph Poellath
Assignee: nicolas de loof
 Fix For: 2.8

 Attachments: maven-eclipse-plugin-2.5.1.tar.gz, 
 MECLIPSE-156-maven-eclipse-plugin.patch, 
 MECLIPSE-156_proper_use_of_project_build_sourceEncoding.patch


 The plugin should support setting Eclipse's text file encoding on a 
 per-project basis.

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

[jira] Updated: (MCHANGELOG-79) Add support for tag type report of Subversion

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste updated MCHANGELOG-79:
-

Attachment: 
MCHANGELOG-79_0001-Add-support-for-svn-tag-diffs.-Redo-the-original-MCH.patch

New version of the patch.

The original patch wasn't working for me when testing changelogs for various 
tags. The problem was caused by the way the SvnInfoCommand was used, and the 
way plexus-utils has evolved I guess: the executed command ended up being:

cd $workingDir$svnTag  

causing the command line to fail.

I've forked the SvnInfoCommand into an SvnInfoCommandExpanded and packaged it 
into the changelog plugin to make it quick to test the changes. The proper fix 
would be to propagate the changes of SvnInfoCommandExpanded into the 
maven-svm-provider-svn project.

I haven't tested all use cases specified by this patch and chose to let the 
original code as much as possible. I haven't added unit tests...

Let me know if you need further info/code.

 Add support for tag type report of Subversion
 ---

 Key: MCHANGELOG-79
 URL: http://jira.codehaus.org/browse/MCHANGELOG-79
 Project: Maven 2.x Changelog Plugin
  Issue Type: Improvement
Reporter: Kinugasa Noriko
 Attachments: 
 MCHANGELOG-79_0001-Add-support-for-svn-tag-diffs.-Redo-the-original-MCH.patch,
  svntag-report-sample.JPG, SvnTag_changelog.patch


  Currently, Changelog plugin don't support Subversion's tag.
  This patch make  The tag type report available even if you are using 
 Subversion.
  This gets each revision of tags in Subversion system, and generates the 
 log-report between those revisions.
 For example, assume you have following repositoy structure:
 {noformat}
 http://example.com/svn/project
  +trunk/
  |+src/
  |  ...
  +tags/
  |+1.0/
  |+1.1/
  |+1.2/
  |+2.0/
  |+2.1/
  +branches/
   +1.x/
 {noformat}
 To generate svn log's between 1.1 and 1.2 tag in 1.x branch:
   [pom.xml]
 {code:xml}
   ...
   !-- Subversion repositoy --
   scm
 !-- svn connection --
 connectionscm:svn:http://example.com/svn/project/connection
   /scm
   ...
   reporting
 plugins
   !-- changelog-plugin --
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-changelog-plugin/artifactId
 version2.2.1/version
 configuration
   !-- type is tag --
   typetag/type
   tags
 !-- between 1.1 and 1.2 tag --
 tag implementation=java.lang.String1.2/tag
 tag implementation=java.lang.String1.1/tag
   /tags
   !-- in 1.x branch --
   branchBasebranches/1.x/branchBase
   !-- encoding --
   outputEncodingWindows-31J/outputEncoding
 /configuration
   /plugin
 /plugins
   /reporting
   ...
 {code} 
  To generate svn log-report between 2.1 and 2.0 tag in trunk:
  [pom.xml]
 {code:xml}
  ...
  !-- Subversion repositoy --
   scm
 !-- svn connection --
 connectionscm:svn:http://example.com/svn/project/connection
   /scm
   ...
   reporting
 plugins
   !-- changelog-plugin --
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-changelog-plugin/artifactId
 version2.2.1/version
 configuration
   !-- type is tag --
   typetag/type
   tags
 !-- between 2.1 and 2.0 tag --
 tag implementation=java.lang.String2.0/tag
 tag implementation=java.lang.String2.1/tag
   /tags
   !-- in trunk (Default brancheBase is trunk. So, branchBase
element is optional when to use trunk. ) --
   [branchBasetrunk/branchBase]
   !-- encoding --
   outputEncodingWindows-31J/outputEncoding
 /configuration
   /plugin
 /plugins
   /reporting
   ...
 {code}

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

[jira] Commented: (MJAR-115) Provide Access to Undocumented Jarsigner -J Option for Increasing Heap

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MJAR-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=186471#action_186471
 ] 

Jerome Lacoste commented on MJAR-115:
-

What about supporting all extra options instead ?

i.e. something like extraParameters-J-Mmx .../extraParameters





 Provide Access to Undocumented Jarsigner -J Option for Increasing Heap
 --

 Key: MJAR-115
 URL: http://jira.codehaus.org/browse/MJAR-115
 Project: Maven 2.x Jar Plugin
  Issue Type: Improvement
  Components: sign
Affects Versions: 2.2
 Environment: Mac 10.5.6, Windows XP SP3, Maven 2.0.9, Jar Plugin 2.2
Reporter: Matthew McCullough
Priority: Minor
 Attachments: 0001-Adding-maximum-memory-option-to-jar-signing.patch, 
 REVISED-0001-Adding-maximum-memory-option-to-jar-signing.patch


 I am signing very large JARs. I don't have the option (legally) of splitting 
 the JAR into smaller pieces.  One of them specifically is wl_fullclient.jar, 
 the 64MB WebLogic JEE client JAR.
 I have found an undocumented option -J-Xmx to jarsigner that has 
 accomplished what I need on Windows and Mac.  It is used in the Ant 
 equivalent jar signing task.
 The Ant Source can be viewed here on line 286
 http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/AbstractJarSignerTask.java?view=markup

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

[jira] Commented: (MSHARED-87) ZipException throw by SDK's JarFile constructor may lack file name

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MSHARED-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=174001#action_174001
 ] 

Jerome Lacoste commented on MSHARED-87:
---

I've been pinged by other users that faced this issue. This trivial patch helps 
and could be applied.

Thanks, J

 ZipException throw by SDK's JarFile constructor may lack file name
 --

 Key: MSHARED-87
 URL: http://jira.codehaus.org/browse/MSHARED-87
 Project: Maven Shared Components
  Issue Type: Improvement
  Components: maven-shared-jar
Reporter: Jerome Lacoste
Priority: Trivial
 Attachments: 
 MNG-3977-maven-shared-jar_add_contextual_info_to_ZipException.txt


 We get the following (non fatal) error. The attached patch helps us.
 [INFO] Generating Dependencies report.
 [ERROR] IOException: error in opening zip file
 java.util.zip.ZipException: error in opening zip file
 at java.util.zip.ZipFile.open(Native Method)
 at java.util.zip.ZipFile.init(ZipFile.java:203)
 at java.util.jar.JarFile.init(JarFile.java:132)
 at java.util.jar.JarFile.init(JarFile.java:97)
 at org.apache.maven.shared.jar.JarAnalyzer.init(JarAnalyzer.java:102)
 at 
 org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:282)
 at 
 org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1278)
 at 
 org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:423)
 at 
 org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:268)
 at 
 org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65)
 at 
 org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:239)
 at 
 org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
 at 
 org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139)
 at 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269)
 at 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101)
 at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129)
 at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 [INFO] Generating changelog report.
 [INFO] Generating dev-activity report.
 [INFO] Generating file-activity report.

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

[jira] Created: (MPIR-147) Dependencies report hangs while accessing SSL site. Connection never closes

[Jerome Lacoste (JIRA)]

Dependencies report hangs while accessing SSL site. Connection never closes
---

 Key: MPIR-147
 URL: http://jira.codehaus.org/browse/MPIR-147
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Bug
  Components: dependencies
Affects Versions: 2.1
Reporter: Jerome Lacoste


mvn site hangs while generating the reports (dump below). This is 100% 
reproducible.

This happens while contacting maven-repository.dev.java.net. The connection is 
opened and never closed. The connection to this external repository was done 
successfully several time in the same build.

Notes:
* a timeout would be useful:
at 
org.apache.maven.wagon.providers.http.LightweightHttpWagon.resourceExists(LightweightHttpWagon.java:312)
at 
org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.dependencyExistsInRepo(RepositoryUtils.java:219)

* for some reason, the site report bypass our corporate repository (nexus). Cf 
MPIR-137
* workaround is to enable
  dependencyLocationsEnabledfalse/dependencyLocationsEnabled
  dependencyDetailsEnabledfalse/dependencyDetailsEnabled
as done in MPIR-137







Full thread dump Java HotSpot(TM) Client VM (1.5.0_16-133 mixed mode):

AWT-AppKit daemon prio=5 tid=0x01038530 nid=0xa0110fa0 runnable 
[0x..0xbfffe818]

Low Memory Detector daemon prio=5 tid=0x01009030 nid=0x805800 runnable 
[0x..0x]

CompilerThread0 daemon prio=9 tid=0x01008580 nid=0x812c00 waiting on 
condition [0x..0xb0b077d8]

Signal Dispatcher daemon prio=9 tid=0x01008130 nid=0x811e00 waiting on 
condition [0x..0x]

Finalizer daemon prio=8 tid=0x01007860 nid=0x819200 in Object.wait() 
[0xb0a05000..0xb0a05d90]
at java.lang.Object.wait(Native Method)
- waiting on 0x0a440228 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:120)
- locked 0x0a440228 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:136)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

Reference Handler daemon prio=10 tid=0x01007480 nid=0x817800 in Object.wait() 
[0xb0984000..0xb0984d90]
at java.lang.Object.wait(Native Method)
- waiting on 0x0a4402b0 (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:474)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked 0x0a4402b0 (a java.lang.ref.Reference$Lock)

main prio=5 tid=0x01001570 nid=0xb0801000 runnable [0xb07fe000..0xb0800148]
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at 
com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:723)
- locked 0x05a4ba78 (a java.lang.Object)
at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:680)
at 
com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
- locked 0x05a4bb28 (a com.sun.net.ssl.internal.ssl.AppInputStream)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
- locked 0x06b58100 (a java.io.BufferedInputStream)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:681)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626)
at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:957)
- locked 0x06b56708 (a 
sun.net.www.protocol.https.DelegateHttpsURLConnection)
at 
java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:367)
at 
sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
at 
org.apache.maven.wagon.providers.http.LightweightHttpWagon.resourceExists(LightweightHttpWagon.java:312)
at 
org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.dependencyExistsInRepo(RepositoryUtils.java:219)
at 
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printArtifactsLocations(DependenciesRenderer.java:1122)
at 
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyRepositoryLocations(DependenciesRenderer.java:641)
at 
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:274)
at 

[jira] Closed: (MPIR-148) ZipException throw by SDK's JarFile constructor may lack file name

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste closed MPIR-148.
---

Resolution: Not A Bug

This was supposed to be for MNG, not MPIR..

 ZipException throw by SDK's JarFile constructor may lack file name
 --

 Key: MPIR-148
 URL: http://jira.codehaus.org/browse/MPIR-148
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
  Components: dependencies
Affects Versions: 2.1
Reporter: Jerome Lacoste
Priority: Trivial
 Attachments: 
 MNG-3977-maven-shared-jar_add_contextual_info_to_ZipException.txt


 We get the following (non fatal) error. The attached patch helps us.
 [INFO] Generating Dependencies report.
 [ERROR] IOException: error in opening zip file
 java.util.zip.ZipException: error in opening zip file
 at java.util.zip.ZipFile.open(Native Method)
 at java.util.zip.ZipFile.init(ZipFile.java:203)
 at java.util.jar.JarFile.init(JarFile.java:132)
 at java.util.jar.JarFile.init(JarFile.java:97)
 at 
 org.apache.maven.shared.jar.JarAnalyzer.init(JarAnalyzer.java:102)
 at 
 org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:282)
 at 
 org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1278)
 at 
 org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:423)
 at 
 org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:268)
 at 
 org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65)
 at 
 org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:239)
 at 
 org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
 at 
 org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139)
 at 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269)
 at 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101)
 at 
 org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129)
 at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at 
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 [INFO] Generating changelog report.
 [INFO] Generating dev-activity report.
 [INFO] Generating file-activity report.

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

[jira] Created: (MPIR-148) ZipException throw by SDK's JarFile constructor may lack file name

[Jerome Lacoste (JIRA)]

ZipException throw by SDK's JarFile constructor may lack file name
--

 Key: MPIR-148
 URL: http://jira.codehaus.org/browse/MPIR-148
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
  Components: dependencies
Affects Versions: 2.1
Reporter: Jerome Lacoste
Priority: Trivial
 Attachments: 
MNG-3977-maven-shared-jar_add_contextual_info_to_ZipException.txt

We get the following (non fatal) error. The attached patch helps us.

[INFO] Generating Dependencies report.
[ERROR] IOException: error in opening zip file
java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.init(ZipFile.java:203)
at java.util.jar.JarFile.init(JarFile.java:132)
at java.util.jar.JarFile.init(JarFile.java:97)
at org.apache.maven.shared.jar.JarAnalyzer.init(JarAnalyzer.java:102)
at 
org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:282)
at 
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1278)
at 
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:423)
at 
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:268)
at 
org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65)
at 
org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:239)
at 
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
at 
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139)
at 
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269)
at 
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101)
at 
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] Generating changelog report.
[INFO] Generating dev-activity report.
[INFO] Generating file-activity report.

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

[jira] Created: (MNG-3977) ZipException throw by SDK's JarFile constructor may lack file name

[Jerome Lacoste (JIRA)]

ZipException throw by SDK's JarFile constructor may lack file name
--

 Key: MNG-3977
 URL: http://jira.codehaus.org/browse/MNG-3977
 Project: Maven 2
  Issue Type: Improvement
Affects Versions: 2.0.9
Reporter: Jerome Lacoste
Priority: Trivial
 Attachments: 
MNG-3977-maven-shared-jar_add_contextual_info_to_ZipException.txt

We get the following (non fatal) error. The attached patch helps us.

[INFO] Generating Dependencies report.
[ERROR] IOException: error in opening zip file
java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.init(ZipFile.java:203)
at java.util.jar.JarFile.init(JarFile.java:132)
at java.util.jar.JarFile.init(JarFile.java:97)
at org.apache.maven.shared.jar.JarAnalyzer.init(JarAnalyzer.java:102)
at 
org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:282)
at 
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1278)
at 
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:423)
at 
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:268)
at 
org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65)
at 
org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:239)
at 
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
at 
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139)
at 
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269)
at 
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101)
at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] Generating changelog report.
[INFO] Generating dev-activity report.
[INFO] Generating file-activity report.

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

[jira] Created: (MANTRUN-99) plugin classpath is invalid in multi-project

[Jerome Lacoste (JIRA)]

plugin classpath is invalid in multi-project 
-

 Key: MANTRUN-99
 URL: http://jira.codehaus.org/browse/MANTRUN-99
 Project: Maven 2.x Antrun Plugin
  Issue Type: Bug
Affects Versions: 1.3
 Environment: maven 2.0.6
Reporter: Jerome Lacoste


[This is perhaps a maven 2.0.6 issue.]

pom.xml
module/pom.xml

module/pom.xml contains (in a profile enabled by default) an antrun plugin 
configuration with specific dependencies. The antrun plugin tasks tries to load 
a custom task (abator) found under the maven.plugin.classpath. This fails if I 
build from the root when I specify the antrun plugin version in the root POM: 
the plugin classpath lacks the dependencies. It doesn't fail if I build from 
the module itself. 

Something similar to:

  profiles
profile
  idgen-from-db/id
  activation
property
  name!gen.skip/name
/property
  /activation
  build
plugins 
  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
  execution
phasegenerate-sources/phase
configuration
  tasks
property name=plugin_classpath 
refid=maven.plugin.classpath/

echo message=plugin classpath:  ${plugin_classpath}/
   [...]
taskdef name=abator
 classname=org.apache.ibatis.abator.ant.AbatorAntTask
 classpath=${plugin_classpath}/

abator ... /

  /tasks
/configuration
goals
  goalrun/goal
/goals
  /execution
/executions
dependencies
  dependency
groupIdorg.apache.ibatis.abator/groupId
artifactIdabator/artifactId
version1.0.0/version
  /dependency
  dependency
groupIdcom.oracle/groupId
artifactIdojdbc14/artifactId
version10.2.0.3.0/version
  /dependency
/dependencies
  /plugin

If I build from the module or if I remove the versioning definition in the root 
POM, I get:

 [echo] plugin classpath:  
/home/jerome/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar:/home/jerome/.m2/repository/org/apache/ibatis/abator/abator/1.0.0_edb_1/abator-1.0.0_edb_1.jar:/home/jerome/.m2/repository/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar:/home/jerome/.m2/repository/com/oracle/ojdbc14/10.2.0.3.0/ojdbc14-10.2.0.3.0.jar:/home/jerome/.m2/repository/org/apache/ant/ant/1.7.1/ant-1.7.1.jar:/usr/local/lib/maven-2.0.6/lib/maven-core-2.0.6-uber.jar

which works.

If in the root pom.xml, I define the version of the antrun plugin under 
buildplugins, the plugin classpath is:

[echo] plugin classpath:  
/home/jerome/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar:/home/jerome/.m2/repository/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar:/home/jerome/.m2/repository/org/apache/ant/ant/1.7.1/ant-1.7.1.jar:/usr/local/lib/maven-2.0.6/lib/maven-core-2.0.6-uber.jar

which fails.

Workaround so far:
* do not define the antrun plugin version in parent POM
* move the plugin dependencies to the project's dependencies, e.g. using test 
scope, and use the maven.test.classpath instead of the maven.plugin one.

The problem is probably not related to antrun itself but to maven. I'll see if 
I get to create a test case. If it's in maven, then I am out of luck, as I am 
unable to move to a newer version of maven for a while.

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

[jira] Commented: (MEAR-76) This resolution resolves the Clover defect MCLOVER-77

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MEAR-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=136547#action_136547
 ] 

Jerome Lacoste commented on MEAR-76:


For information I've fixed MCLOVER-70 (in fact 
http://developer.atlassian.com/jira/browse/CLMVN-6) by fixing MNG-3595.

I wonder if by fixing MNG-3595, this issue would disappear as well.

 This resolution resolves the Clover defect MCLOVER-77
 -

 Key: MEAR-76
 URL: http://jira.codehaus.org/browse/MEAR-76
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.3.1
 Environment: windows/jdk1.5/cloer plugin 2.3.1 and above
Reporter: Martin Franklin
Assignee: Stephane Nicoll
 Attachments: cloverclassifier.diff


 The clover plugin 'swizzles' the dependencies of an artifact when the 
 clover:instrument goal is executed. This adds the classifier 'clover' to 
 those dependencies of the ear which can be resolved as clovered artifacts. 
 However due to some assumptions made in constructing the ear the problem 
 detailed in http://jira.codehaus.org/browse/MCLOVER-77 can be created.
 The cause turns out to be multiple problems - first after clover 'swizzles' 
 the dependencies the list gets new versions added during ear processing. I 
 suspect this is due to the classifier being different so the dependencies of 
 the dependencies are not found and so they get added again. Thus the same 
 dependency is listed in the project.getArtifacts() Set. Once with the clover 
 classifier and once with null. The second problem is the application.xml 
 generation which adds a second set of dependencies. This can be resolved by 
 specifying the classifier for the specific module listed in the Modules 
 section. However this is awkward to use if you wish to use the same pom for 
 both clovered and unclovered ear generation. This patch supports this.
 This patch will always select an artifact with a classifier rather than one 
 with null set. The matching is only done at the groupid/artifactid level, but 
 I believe that should be sufficient.
 Duplicate EarModules are also removed so that only the most specific 
 gorupid/artifactid/classifier is used for both inclusion in the ear and 
 inclusion in the application.xml
 One last point about the patch - I could not get test 42 to run before I 
 started work on the patch, so this test is commented out in the patch. All 
 the other tests worked fine.
 As creating a test would require creating a linkage with the clover plugin, 
 and the fact that the clover plugin itself needs a patch MCLOVER-82, in order 
 to fully display these effects easily, I haven't created a test case for it. 
 I have tested this with my own projects which show that MCLOVER-77 is now 
 resolved with this patch.

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

[jira] Commented: (MNG-3595) Changes made to project resolved artifacts are overriden when a plugin uses @requiresDependencyResolution

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-3595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=136560#action_136560
 ] 

Jerome Lacoste commented on MNG-3595:
-

#maven
lacostej  yo ! Is there anything I can do in exchange for some 
comments regarding MNG-3595 ? :) at least to know if this problem is something 
that is worth addressing. Thanks
Brian lacostej, i don't think we should make that change in 2.0.x, 
but perhaps 2.1
Brian it's a little scary to make changes in this area anymore 
because it will inevitably break someone's build
lacostej  Brian: OK. I am willing to provide a cleaner patch for 
2.1, I just need some comments on what approach to follow.
lacostej  the current patch cannot build any existing build as it 
provides a new hook for adding the functionality. But I don't like changing 
MavenProject
Brian jdcasey, wdyt?
jdcasey   looking
jdcasey   lacostej: I'm not sure I get it, the clover plugin 
would register a post-processor for dependencies? or, would it attach a 
post-processor to the project for use ahead of successive plugin executions?
jdcasey   lacostej, Brian: why not simply remember when/what 
scope we've resolved to for a given project, and avoid re-resolving? then 
swizzled artifacts would remain intact for the forked project instance
Brian jdcasey, that would be the preferred technique performance wise 
also, but i'm afraid of consequences in 2.0.x
lacostej  jdcasey: the way I solved the problem was just the 
quickest solution I found. The problem is that successive plugin executions 
affect the list of transitive dependencies, because of the 
requireDependencyResolution tag. The idea was then to post process this 
dependency resolution operation, if it is to happen again. Another solution 
would be to prevent from the re-resolution to happen again,...
lacostej  ...but I wasn't sure if it is possible to achieve this 
without locking maven into one corner. I wasn't sure why we were not already 
re-resolving for each plugin that required it
jdcasey   Brian: I understand, but this _should_ be relatively 
tame
jdcasey   lacostej: I think as long as we never prune the list of 
transitive artifacts (i.e. going from test scope to compile scope only) in the 
project instance, we should be able to avoid re-resolving pretty safely
Brian there's a lot of sketchy stuff in there, like you may still get 
artifacts even if you didn't request resolution, depending on what plugin(s) 
ran before
jdcasey   IIRC, there is another long-standing issue with 
re-resolving the artifacts...jesse filed it, but I'd have to dig around to find 
it again
lacostej  jdcasey: what happens if we start adding a new scope ?
jdcasey   Brian: true, we'd almost need a masked project instance 
for things that didn't request dependency resolution
Brian yeah which is why this scares me in 2.o
jdcasey   yeah
jdcasey   Brian: you don't think we could hem it in with a bunch 
of tests and get the possible pathways covered?
jdcasey   I mean, it'd be a lot of work, and this is sort of an 
edge case (if you don't mind my saying so), but still...
jdcasey   2.1 is definitely safest
Brian i'm risk averse after the mess we went through with .9
Brian we're trying to reduce regressions not make more ;-)
jdcasey   it's probably worth mentioning in connection that we 
ought to do a full audit of the mutability of the MavenProject instance, to 
make sure things are intuitive across the board...fwiw
jdcasey   heh
lacostej  jdcasey: that's a good think. In fact what I was 
missing when developing is a contract between the plugins and maven core
jdcasey   Brian: that pretty much means just shoring up the 
behavior and adopting a sunset clause for 2.0.x asap, then?
jdcasey   :)
lacostej  think-thing
jdcasey   lacostej: yeah, the formal contract thing keeps coming 
up
lacostej  e.g. what should a plugin expect after using 
setArtifacts()
jdcasey   I started looking at that awhile back, something 
outside the core that was fluent in both the 2.0.x core and the 2.1 core, but 
ran out of time
jdcasey   sure
Brian jdcasey, that's essentially what i had in mind, continue to fix 
bugs and regressions only
jdcasey   that's cool
jdcasey   Brian: maybe it's worth talking about a less scary 2.1, 
then? something that will do a new feature-set in between the current plan and 
the 2.0.x features?
jdcasey   I mean, we have enough code now to talk about killing 
bugs and doing a release
* jdcasey   shrugs
Brian yes but 2.1 hardly 

[jira] Commented: (MNG-519) Timestamps on messages

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=136068#action_136068
 ] 

Jerome Lacoste commented on MNG-519:


As a work-around it is possible to pipe the output to a script that will add 
the timestamp for you. On Linux, you can use the ts perl script.

 Timestamps on messages
 --

 Key: MNG-519
 URL: http://jira.codehaus.org/browse/MNG-519
 Project: Maven 2
  Issue Type: Wish
  Components: Plugins and Lifecycle
Reporter: Jeff Jensen
Priority: Minor
 Fix For: 2.x


 With current and/or moving forward with M2, I would like an option for 
 timestamped messages.
 We have a somewhat long nightly process.  I regularly wish for timestamps on 
 the log messages from the Maven build.  The two primary reasons for this are 
 duration calculation - how long did something take, and an occasional 
 correlation with an outside event.

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

[jira] Created: (MNG-3595) Changes made to project resolved artifacts are overriden when a plugin uses @requiresDependencyResolution

[Jerome Lacoste (JIRA)]

Changes made to project resolved artifacts are overriden when a plugin uses 
@requiresDependencyResolution
-

 Key: MNG-3595
 URL: http://jira.codehaus.org/browse/MNG-3595
 Project: Maven 2
  Issue Type: Bug
  Components: Plugins and Lifecycle
Reporter: Jerome Lacoste


clover:instrument mojo creates instrumented artifacts and attaches them with a 
'clover' classifier.

It forks a lifecycle [1][2] and which triggers clover:intrumentInternal which 
tries to change the project direct and transitive dependencies after 
'swizzling' them [3] (replacing normal artifacts with their clovered ones). 
This in theory would allow to build clovered WAR and EAR, i.e. WAR/EAR 
containing all available clovered dependencies.

Unfortunately maven handles direct and transitive dependencies differently [4]. 
While direct dependencies are somewhat preserved (the code comments references 
clover), transitive dependencies are re-resolved, and thus the results of the 
swizzling operation are lost as soon as a plugin requiresDependencyResolution 
in a further part of the lifecycle.

I've managed to hack maven and clover:instrument to work together by allowing a 
plugin to attach some sort of dependency resolution post processing operation 
[5].
In the case of clover:instrument, the swizzling is then registered in the maven 
project and re-performed each time the artifacts are re-resolved.

I am not very fond of this solution, but it seems to work for us on the 
attached example. I will further test the patch this week on a large scale 
project.

I would like to discuss ways to solve this interaction, whether the clover 
plugin should be implemented differently or if maven should have some sort of 
support for this use case.

[1] 
http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentMojo.java
[2] 
http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/resources/META-INF/maven/lifecycle.xml
[3] 
http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentInternalMojo.java
[4] 
http://maven.apache.org/ref/2.0.9/maven-core/xref/org/apache/maven/plugin/DefaultPluginManager.html#1406
[5] http://www.mail-archive.com/[EMAIL PROTECTED]/msg74636.html


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

[jira] Updated: (MNG-3595) Changes made to project resolved artifacts are overriden when a plugin uses @requiresDependencyResolution

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste updated MNG-3595:


Attachment: MNG-3595-test-project.tar.bz2

a simple test project that contains a log produced after patching maven and 
cloved plugin with the hack .

Notice how the expected-mvn.log contains:

[INFO] Building war: 
/tmp/clover-war-hello-world-trunk/webapp/target/clover/sayHello-1.0-clover.war
[DEBUG] adding directory META-INF/
[...]
[DEBUG] adding entry WEB-INF/lib/a-1.0-clover.jar
[DEBUG] adding entry WEB-INF/lib/clover-2.1.0.jar
[DEBUG] adding entry WEB-INF/lib/b-1.0-clover.jar

while maven will today include b-1.0-clover.jar and a-1.0.jar

 Changes made to project resolved artifacts are overriden when a plugin uses 
 @requiresDependencyResolution
 -

 Key: MNG-3595
 URL: http://jira.codehaus.org/browse/MNG-3595
 Project: Maven 2
  Issue Type: Bug
  Components: Plugins and Lifecycle
Reporter: Jerome Lacoste
 Attachments: MNG-3595-test-project.tar.bz2


 clover:instrument mojo creates instrumented artifacts and attaches them with 
 a 'clover' classifier.
 It forks a lifecycle [1][2] and which triggers clover:intrumentInternal which 
 tries to change the project direct and transitive dependencies after 
 'swizzling' them [3] (replacing normal artifacts with their clovered ones). 
 This in theory would allow to build clovered WAR and EAR, i.e. WAR/EAR 
 containing all available clovered dependencies.
 Unfortunately maven handles direct and transitive dependencies differently 
 [4]. While direct dependencies are somewhat preserved (the code comments 
 references clover), transitive dependencies are re-resolved, and thus the 
 results of the swizzling operation are lost as soon as a plugin 
 requiresDependencyResolution in a further part of the lifecycle.
 I've managed to hack maven and clover:instrument to work together by allowing 
 a plugin to attach some sort of dependency resolution post processing 
 operation [5].
 In the case of clover:instrument, the swizzling is then registered in the 
 maven project and re-performed each time the artifacts are re-resolved.
 I am not very fond of this solution, but it seems to work for us on the 
 attached example. I will further test the patch this week on a large scale 
 project.
 I would like to discuss ways to solve this interaction, whether the clover 
 plugin should be implemented differently or if maven should have some sort of 
 support for this use case.
 [1] 
 http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentMojo.java
 [2] 
 http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/resources/META-INF/maven/lifecycle.xml
 [3] 
 http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentInternalMojo.java
 [4] 
 http://maven.apache.org/ref/2.0.9/maven-core/xref/org/apache/maven/plugin/DefaultPluginManager.html#1406
 [5] http://www.mail-archive.com/[EMAIL PROTECTED]/msg74636.html

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

[jira] Updated: (MNG-3595) Changes made to project resolved artifacts are overriden when a plugin uses @requiresDependencyResolution

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste updated MNG-3595:


Attachment: MNG-3595.diff

The patch I've applied to maven before modifying the clover plugin

 Changes made to project resolved artifacts are overriden when a plugin uses 
 @requiresDependencyResolution
 -

 Key: MNG-3595
 URL: http://jira.codehaus.org/browse/MNG-3595
 Project: Maven 2
  Issue Type: Bug
  Components: Plugins and Lifecycle
Reporter: Jerome Lacoste
 Attachments: MNG-3595-test-project.tar.bz2, MNG-3595.diff


 clover:instrument mojo creates instrumented artifacts and attaches them with 
 a 'clover' classifier.
 It forks a lifecycle [1][2] and which triggers clover:intrumentInternal which 
 tries to change the project direct and transitive dependencies after 
 'swizzling' them [3] (replacing normal artifacts with their clovered ones). 
 This in theory would allow to build clovered WAR and EAR, i.e. WAR/EAR 
 containing all available clovered dependencies.
 Unfortunately maven handles direct and transitive dependencies differently 
 [4]. While direct dependencies are somewhat preserved (the code comments 
 references clover), transitive dependencies are re-resolved, and thus the 
 results of the swizzling operation are lost as soon as a plugin 
 requiresDependencyResolution in a further part of the lifecycle.
 I've managed to hack maven and clover:instrument to work together by allowing 
 a plugin to attach some sort of dependency resolution post processing 
 operation [5].
 In the case of clover:instrument, the swizzling is then registered in the 
 maven project and re-performed each time the artifacts are re-resolved.
 I am not very fond of this solution, but it seems to work for us on the 
 attached example. I will further test the patch this week on a large scale 
 project.
 I would like to discuss ways to solve this interaction, whether the clover 
 plugin should be implemented differently or if maven should have some sort of 
 support for this use case.
 [1] 
 http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentMojo.java
 [2] 
 http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/resources/META-INF/maven/lifecycle.xml
 [3] 
 http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentInternalMojo.java
 [4] 
 http://maven.apache.org/ref/2.0.9/maven-core/xref/org/apache/maven/plugin/DefaultPluginManager.html#1406
 [5] http://www.mail-archive.com/[EMAIL PROTECTED]/msg74636.html

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

[jira] Updated: (MNG-3595) Changes made to project resolved artifacts are overriden when a plugin uses @requiresDependencyResolution

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste updated MNG-3595:


Attachment: MNG-3595.diff

 Changes made to project resolved artifacts are overriden when a plugin uses 
 @requiresDependencyResolution
 -

 Key: MNG-3595
 URL: http://jira.codehaus.org/browse/MNG-3595
 Project: Maven 2
  Issue Type: Bug
  Components: Plugins and Lifecycle
Reporter: Jerome Lacoste
 Attachments: MNG-3595-test-project.tar.bz2, MNG-3595.diff, 
 MNG-3595.diff


 clover:instrument mojo creates instrumented artifacts and attaches them with 
 a 'clover' classifier.
 It forks a lifecycle [1][2] and which triggers clover:intrumentInternal which 
 tries to change the project direct and transitive dependencies after 
 'swizzling' them [3] (replacing normal artifacts with their clovered ones). 
 This in theory would allow to build clovered WAR and EAR, i.e. WAR/EAR 
 containing all available clovered dependencies.
 Unfortunately maven handles direct and transitive dependencies differently 
 [4]. While direct dependencies are somewhat preserved (the code comments 
 references clover), transitive dependencies are re-resolved, and thus the 
 results of the swizzling operation are lost as soon as a plugin 
 requiresDependencyResolution in a further part of the lifecycle.
 I've managed to hack maven and clover:instrument to work together by allowing 
 a plugin to attach some sort of dependency resolution post processing 
 operation [5].
 In the case of clover:instrument, the swizzling is then registered in the 
 maven project and re-performed each time the artifacts are re-resolved.
 I am not very fond of this solution, but it seems to work for us on the 
 attached example. I will further test the patch this week on a large scale 
 project.
 I would like to discuss ways to solve this interaction, whether the clover 
 plugin should be implemented differently or if maven should have some sort of 
 support for this use case.
 [1] 
 http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentMojo.java
 [2] 
 http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/resources/META-INF/maven/lifecycle.xml
 [3] 
 http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentInternalMojo.java
 [4] 
 http://maven.apache.org/ref/2.0.9/maven-core/xref/org/apache/maven/plugin/DefaultPluginManager.html#1406
 [5] http://www.mail-archive.com/[EMAIL PROTECTED]/msg74636.html

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

[jira] Created: (MNG-3594) Maven 2.0.6 tag doesn't build properly anymore

[Jerome Lacoste (JIRA)]

Maven 2.0.6 tag doesn't build properly anymore
--

 Key: MNG-3594
 URL: http://jira.codehaus.org/browse/MNG-3594
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.0.6
Reporter: Jerome Lacoste
 Attachments: maven-2.0.6-maven-core.diff

The uberjar wasn't generated when building. Tried bootstrapping and normal 
build (using a maven 2.0.6 install).

I've had to patch the maven-core pom and specify the shade version to get it to 
work again. I've used version 0.4 (which was also used in maven 2.0.7)

$ svn info
Path: .
URL: https://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.6
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 659652
Node Kind: directory
Schedule: normal
Last Changed Author: jvanzyl
Last Changed Rev: 522714
Last Changed Date: 2007-03-27 04:40:40 +0200 (Tue, 27 Mar 2007)


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

[jira] Commented: (MENFORCER-17) add a new rule to enforce that no repositories are defined in the poms.

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MENFORCER-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=135070#action_135070
 ] 

Jerome Lacoste commented on MENFORCER-17:
-

Brian, can you enlighten as to why this is a bad practise ?

What should developers do ? settings.xml + proxy server ?

 add a new rule to enforce that no repositories are defined in the poms.
 ---

 Key: MENFORCER-17
 URL: http://jira.codehaus.org/browse/MENFORCER-17
 Project: Maven 2.x Enforcer Plugin
  Issue Type: New Feature
  Components: Standard Rules
Affects Versions: 1.0-alpha-3
Reporter: Brian Fox
Assignee: Brian Fox

 repositories in the poms are against best practices

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

[jira] Commented: (MECLIPSE-416) Build failures (EclipsePluginTest failures and errors)

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MECLIPSE-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=129668#action_129668
 ] 

Jerome Lacoste commented on MECLIPSE-416:
-

Good point. Disregard my patch then.

 Build failures (EclipsePluginTest failures and errors)
 --

 Key: MECLIPSE-416
 URL: http://jira.codehaus.org/browse/MECLIPSE-416
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
 Environment: $ uname -a
 Linux expresso2 2.6.24-12-generic #1 SMP Wed Mar 12 23:01:54 UTC 2008 i686 
 GNU/Linux
 $ java -version
 java version 1.5.0_11
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
 Java HotSpot(TM) Server VM (build 1.5.0_11-b03, mixed mode)
Reporter: Jerome Lacoste
Assignee: Arnaud Heritier
 Fix For: 2.5.2

 Attachments: MECLIPSE-416.diff, 
 org.apache.maven.plugin.eclipse.EclipsePluginTest.txt


 Trunk build fails (r642941).
 Results :
 Failed tests: 
   testProject33(org.apache.maven.plugin.eclipse.EclipsePluginTest)
 Tests in error: 
   testProject16(org.apache.maven.plugin.eclipse.EclipsePluginTest)
   testProject17(org.apache.maven.plugin.eclipse.EclipsePluginTest)
   testMECLIPSE_56_encoding(org.apache.maven.plugin.eclipse.EclipsePluginTest)
 Tests run: 91, Failures: 1, Errors: 3, Skipped: 0
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] There are test failures.
 $ svn info
 Path: .
 URL: http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-eclipse-plugin
 Repository Root: http://svn.apache.org/repos/asf
 Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
 Revision: 642941
 Node Kind: directory
 Schedule: normal
 Last Changed Author: aheritier
 Last Changed Rev: 642029
 Last Changed Date: 2008-03-28 00:43:44 +0100 (Fri, 28 Mar 2008)
 This probably encompass various failures.

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

[jira] Created: (MECLIPSE-416) Build failures (EclipsePluginTest failures and errors)

[Jerome Lacoste (JIRA)]

Build failures (EclipsePluginTest failures and errors)
--

 Key: MECLIPSE-416
 URL: http://jira.codehaus.org/browse/MECLIPSE-416
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
 Environment: $ uname -a
Linux expresso2 2.6.24-12-generic #1 SMP Wed Mar 12 23:01:54 UTC 2008 i686 
GNU/Linux
$ java -version
java version 1.5.0_11
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
Java HotSpot(TM) Server VM (build 1.5.0_11-b03, mixed mode)

Reporter: Jerome Lacoste
 Attachments: org.apache.maven.plugin.eclipse.EclipsePluginTest.txt

Trunk build fails (r642941).

Results :

Failed tests: 
  testProject33(org.apache.maven.plugin.eclipse.EclipsePluginTest)

Tests in error: 
  testProject16(org.apache.maven.plugin.eclipse.EclipsePluginTest)
  testProject17(org.apache.maven.plugin.eclipse.EclipsePluginTest)
  testMECLIPSE_56_encoding(org.apache.maven.plugin.eclipse.EclipsePluginTest)

Tests run: 91, Failures: 1, Errors: 3, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.







$ svn info
Path: .
URL: http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-eclipse-plugin
Repository Root: http://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 642941
Node Kind: directory
Schedule: normal
Last Changed Author: aheritier
Last Changed Rev: 642029
Last Changed Date: 2008-03-28 00:43:44 +0100 (Fri, 28 Mar 2008)

This probably encompass various failures.

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

[jira] Commented: (MECLIPSE-416) Build failures (EclipsePluginTest failures and errors)

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MECLIPSE-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=129209#action_129209
 ] 

Jerome Lacoste commented on MECLIPSE-416:
-

Forgot to mention but I used maven 2.+.6 to build. I am running the build again 
with 2.0.8.
That should fix at least some of the problems (some tests required 2.0.8).

Full build takes time though !

 Build failures (EclipsePluginTest failures and errors)
 --

 Key: MECLIPSE-416
 URL: http://jira.codehaus.org/browse/MECLIPSE-416
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
 Environment: $ uname -a
 Linux expresso2 2.6.24-12-generic #1 SMP Wed Mar 12 23:01:54 UTC 2008 i686 
 GNU/Linux
 $ java -version
 java version 1.5.0_11
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
 Java HotSpot(TM) Server VM (build 1.5.0_11-b03, mixed mode)
Reporter: Jerome Lacoste
 Attachments: org.apache.maven.plugin.eclipse.EclipsePluginTest.txt


 Trunk build fails (r642941).
 Results :
 Failed tests: 
   testProject33(org.apache.maven.plugin.eclipse.EclipsePluginTest)
 Tests in error: 
   testProject16(org.apache.maven.plugin.eclipse.EclipsePluginTest)
   testProject17(org.apache.maven.plugin.eclipse.EclipsePluginTest)
   testMECLIPSE_56_encoding(org.apache.maven.plugin.eclipse.EclipsePluginTest)
 Tests run: 91, Failures: 1, Errors: 3, Skipped: 0
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] There are test failures.
 $ svn info
 Path: .
 URL: http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-eclipse-plugin
 Repository Root: http://svn.apache.org/repos/asf
 Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
 Revision: 642941
 Node Kind: directory
 Schedule: normal
 Last Changed Author: aheritier
 Last Changed Rev: 642029
 Last Changed Date: 2008-03-28 00:43:44 +0100 (Fri, 28 Mar 2008)
 This probably encompass various failures.

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

[jira] Updated: (MECLIPSE-416) Build failures (EclipsePluginTest failures and errors)

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste updated MECLIPSE-416:


Attachment: MECLIPSE-416.diff

No build failures using maven 2.0.8.

 Build failures (EclipsePluginTest failures and errors)
 --

 Key: MECLIPSE-416
 URL: http://jira.codehaus.org/browse/MECLIPSE-416
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
 Environment: $ uname -a
 Linux expresso2 2.6.24-12-generic #1 SMP Wed Mar 12 23:01:54 UTC 2008 i686 
 GNU/Linux
 $ java -version
 java version 1.5.0_11
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
 Java HotSpot(TM) Server VM (build 1.5.0_11-b03, mixed mode)
Reporter: Jerome Lacoste
 Attachments: MECLIPSE-416.diff, 
 org.apache.maven.plugin.eclipse.EclipsePluginTest.txt


 Trunk build fails (r642941).
 Results :
 Failed tests: 
   testProject33(org.apache.maven.plugin.eclipse.EclipsePluginTest)
 Tests in error: 
   testProject16(org.apache.maven.plugin.eclipse.EclipsePluginTest)
   testProject17(org.apache.maven.plugin.eclipse.EclipsePluginTest)
   testMECLIPSE_56_encoding(org.apache.maven.plugin.eclipse.EclipsePluginTest)
 Tests run: 91, Failures: 1, Errors: 3, Skipped: 0
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] There are test failures.
 $ svn info
 Path: .
 URL: http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-eclipse-plugin
 Repository Root: http://svn.apache.org/repos/asf
 Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
 Revision: 642941
 Node Kind: directory
 Schedule: normal
 Last Changed Author: aheritier
 Last Changed Rev: 642029
 Last Changed Date: 2008-03-28 00:43:44 +0100 (Fri, 28 Mar 2008)
 This probably encompass various failures.

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

[jira] Created: (MSITE-291) FAQ section without question ends up in NPE

[Jerome Lacoste (JIRA)]

FAQ section without question ends up in NPE
---

 Key: MSITE-291
 URL: http://jira.codehaus.org/browse/MSITE-291
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
Reporter: Jerome Lacoste
Priority: Critical


This happened during a release:perform

[INFO] [site:site]
[WARNING] Unable to load parent project from repository: Could not find 
the model file 
'/home/jerome/Code/OSS/m2/mojo/keytool-maven-plugin/target/checkout/../pom.xml'.
[INFO] Skipped Maven Surefire Report report, file 
surefire-report.html already exists for the English version.
[INFO] Skipped About report, file index.html already exists for the 
English version.
[INFO] 

[ERROR] FATAL ERROR
[INFO] 

[INFO] null
[INFO] 

[INFO] Trace
java.lang.NullPointerException
at 
org.apache.maven.doxia.module.fml.FmlParser.createSink(FmlParser.java:270)
at 
org.apache.maven.doxia.module.fml.FmlParser.parse(FmlParser.java:61)
at 
org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:52)
at 
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:264)
at 
org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:43)
at 
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:239)
at 
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:115)
at 
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:124)
at 
org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at 
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] 

[INFO] Total time: 6 minutes 48 seconds
[INFO] Finished at: Wed Jan 30 22:46:46 GMT+01:00 2008
[INFO] Final Memory: 35M/108M
[INFO] 

[INFO] 

This faq should help reproducing the pb:

?xml version=1.0?
faqs id=FAQ title=Frequently Asked Questions

  part id=General

!--faq id=dummy_question
  questionWhy this question ?/question
  answer
p
  To avoid an NPE in the FAQ site renderer...
/p
  /answer
/faq--
  /part

/faqs


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

[jira] Commented: (SUREFIRE-350) if test parameter is provided, and no match is found, an error should occur, not a successful build with 0 tests

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste commented on SUREFIRE-350:
-

BTW, this create a very small 'regression' in our hacky use of the plugin.

In order to speed up build in some cases, we skipped the tests, but didn't skip 
the compile.tests phase.

We used to achieve this with the following little convenient trick:

   mvn install -Dtest=x

Now this doesn't work anymore and we have to do:

   mvn install -Dtest=x -DfailIfNoTests=false

which is too much verbose to my taste.

 if test parameter is provided, and no match is found, an error should occur, 
 not a successful build with 0 tests
 

 Key: SUREFIRE-350
 URL: http://jira.codehaus.org/browse/SUREFIRE-350
 Project: Maven Surefire
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Brett Porter
 Fix For: 2.4




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

[jira] Created: (SUREFIRE-419) Cannot build current surefire from tunk (r606821), fail in integration tests

[Jerome Lacoste (JIRA)]

Cannot build current surefire from tunk (r606821), fail in integration tests


 Key: SUREFIRE-419
 URL: http://jira.codehaus.org/browse/SUREFIRE-419
 Project: Maven Surefire
  Issue Type: Bug
Affects Versions: 2.4
 Environment: Windows XP Pro SP2

java version 1.6.0_01
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode)
Reporter: Jerome Lacoste
 Attachments: org.apache.maven.surefire.its.WorkingDirectoryTest.txt

Results :

Tests in error:
  
testWorkingDirectoryChildOnly(org.apache.maven.surefire.its.WorkingDirectoryTest)

(report attached)

svn info
Path: .
URL: https://svn.apache.org/repos/asf/maven/surefire/trunk
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 606821
Node Kind: directory
Schedule: normal
Last Changed Author: dfabulich
Last Changed Rev: 606813
Last Changed Date: 2007-12-25 22:26:20 +0100 (ti, 25 des 2007)

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

[jira] Commented: (SUREFIRE-328) java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/NestedRuntimeException

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste commented on SUREFIRE-328:
-

Dan,

I don't manage to reproduce this failure anymore.  The only thing I took note 
of is that in my mvn.log file, surefire was resolved to  2.4-20071211.083739-20 
while the other surefire modules were resolved to 2.4-20071220... Not sure if 
that could be a reason. I doubt.

As a sidenote, I had managed to reproduce the compilation failure with 
JarUnsignMojo, but only sporadically. Now I can't anymore. A very strange week 
on the reproducibility side of maven... I don't like that at all. MWEBSTART-82 
if you're curious.


 java.lang.NoClassDefFoundError: 
 org/apache/maven/surefire/util/NestedRuntimeException
 -

 Key: SUREFIRE-328
 URL: http://jira.codehaus.org/browse/SUREFIRE-328
 Project: Maven Surefire
  Issue Type: Bug
  Components: TestNG support
Affects Versions: 2.4
 Environment: Windows XP
 Maven 2.0.6
Reporter: Wim Deblauwe
 Attachments: mvn.log


 I just updated my surefire 2.4-SNAPSHOT plugin, but now I cannot build 
 anymore. I get a NoClassDefFoundError: 
 org/apache/maven/surefire/util/NestedRuntimeException. This is the console 
 output with the -e option:
 mvn -e clean test
 [INFO] [surefire:test]
 [INFO] Surefire report directory: C:\personal\vigilog\target\surefire-reports
 java.lang.NoClassDefFoundError: 
 org/apache/maven/surefire/util/NestedRuntimeException
 Exception in thread main
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] There are test failures.
 [INFO] 
 
 [INFO] Trace
 org.apache.maven.BuildFailureException: There are test failures.
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals 
 (DefaultLifecycleExecutor.java:560)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal 
 (DefaultLifecycleExecutor.java:459)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments 
 (DefaultLifecycleExecutor.java:278)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke (Method.java:597)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at org.codehaus.classworlds.Launcher.mainWithExitCode 
 (Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.apache.maven.plugin.MojoFailureException: There are test 
 failures.
 at org.apache.maven.plugin.surefire.SurefirePlugin.execute 
 (SurefirePlugin.java:413)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java
  :539)
 ... 16 more
 [INFO] 
 
 [INFO] Total time: 6 seconds
 [INFO] Finished at: Mon May 14 10:45:43 CEST 2007
 [INFO] Final Memory: 8M/25M
 [INFO] 
 
 I'm using the snapshot release because I use TestNG 5.5. Any solution to make 
 my build work again would be highly appriciated.
 regards,
 Wim

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

[jira] Updated: (SUREFIRE-328) java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/NestedRuntimeException

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste updated SUREFIRE-328:


Attachment: mvn.log

Same issue today building mwebstart on windows XP.

$ svn info
Path: .
URL: https://svn.codehaus.org/mojo/trunk/mojo/webstart-maven-plugin/plugin
Repository Root: https://svn.codehaus.org/mojo
Repository UUID: 52ab4f32-60fc-0310-b215-8acea882cd1b
Revision: 5808
Node Kind: directory
Schedule: normal
Last Changed Author: lacostej
Last Changed Rev: 5808
Last Changed Date: 2007-12-20 23:44:00 +0100 (to, 20 des 2007)

maven 2.0.6

I am not using TestNG so this is not TestNG specific.

Dan, can you look at that one? Thanks.

 java.lang.NoClassDefFoundError: 
 org/apache/maven/surefire/util/NestedRuntimeException
 -

 Key: SUREFIRE-328
 URL: http://jira.codehaus.org/browse/SUREFIRE-328
 Project: Maven Surefire
  Issue Type: Bug
  Components: TestNG support
Affects Versions: 2.4
 Environment: Windows XP
 Maven 2.0.6
Reporter: Wim Deblauwe
 Fix For: 2.4

 Attachments: mvn.log


 I just updated my surefire 2.4-SNAPSHOT plugin, but now I cannot build 
 anymore. I get a NoClassDefFoundError: 
 org/apache/maven/surefire/util/NestedRuntimeException. This is the console 
 output with the -e option:
 mvn -e clean test
 [INFO] [surefire:test]
 [INFO] Surefire report directory: C:\personal\vigilog\target\surefire-reports
 java.lang.NoClassDefFoundError: 
 org/apache/maven/surefire/util/NestedRuntimeException
 Exception in thread main
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] There are test failures.
 [INFO] 
 
 [INFO] Trace
 org.apache.maven.BuildFailureException: There are test failures.
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals 
 (DefaultLifecycleExecutor.java:560)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal 
 (DefaultLifecycleExecutor.java:459)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments 
 (DefaultLifecycleExecutor.java:278)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke (Method.java:597)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at org.codehaus.classworlds.Launcher.mainWithExitCode 
 (Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.apache.maven.plugin.MojoFailureException: There are test 
 failures.
 at org.apache.maven.plugin.surefire.SurefirePlugin.execute 
 (SurefirePlugin.java:413)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java
  :539)
 ... 16 more
 [INFO] 
 
 [INFO] Total time: 6 seconds
 [INFO] Finished at: Mon May 14 10:45:43 CEST 2007
 [INFO] Final Memory: 8M/25M
 [INFO] 
 
 I'm using the snapshot release because I use TestNG 5.5. Any solution to make 
 my build work again would be highly appriciated.
 regards,
 Wim

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

[jira] Commented: (SUREFIRE-328) java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/NestedRuntimeException

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste commented on SUREFIRE-328:
-

Not sure if they are related.

But a simple thing that might help me to troubleshoot further would be to still 
have access to the temporary jars created by the surefire-booter.

http://svn.apache.org/viewvc/maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkConfiguration.java?revision=602583view=markup

File file = File.createTempFile( surefirebooter, .jar );
file.deleteOnExit();

if this deleteOnExit() could be disabled from the command line, then I would be 
able to check the temporary jars and/or try to reproduce the executed command 
manually.

 java.lang.NoClassDefFoundError: 
 org/apache/maven/surefire/util/NestedRuntimeException
 -

 Key: SUREFIRE-328
 URL: http://jira.codehaus.org/browse/SUREFIRE-328
 Project: Maven Surefire
  Issue Type: Bug
  Components: TestNG support
Affects Versions: 2.4
 Environment: Windows XP
 Maven 2.0.6
Reporter: Wim Deblauwe
 Fix For: 2.4

 Attachments: mvn.log


 I just updated my surefire 2.4-SNAPSHOT plugin, but now I cannot build 
 anymore. I get a NoClassDefFoundError: 
 org/apache/maven/surefire/util/NestedRuntimeException. This is the console 
 output with the -e option:
 mvn -e clean test
 [INFO] [surefire:test]
 [INFO] Surefire report directory: C:\personal\vigilog\target\surefire-reports
 java.lang.NoClassDefFoundError: 
 org/apache/maven/surefire/util/NestedRuntimeException
 Exception in thread main
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] There are test failures.
 [INFO] 
 
 [INFO] Trace
 org.apache.maven.BuildFailureException: There are test failures.
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals 
 (DefaultLifecycleExecutor.java:560)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal 
 (DefaultLifecycleExecutor.java:459)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments 
 (DefaultLifecycleExecutor.java:278)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke (Method.java:597)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at org.codehaus.classworlds.Launcher.mainWithExitCode 
 (Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.apache.maven.plugin.MojoFailureException: There are test 
 failures.
 at org.apache.maven.plugin.surefire.SurefirePlugin.execute 
 (SurefirePlugin.java:413)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java
  :539)
 ... 16 more
 [INFO] 
 
 [INFO] Total time: 6 seconds
 [INFO] Finished at: Mon May 14 10:45:43 CEST 2007
 [INFO] Final Memory: 8M/25M
 [INFO] 
 
 I'm using the snapshot release because I use TestNG 5.5. Any solution to make 
 my build work again would be highly appriciated.
 regards,
 Wim

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

[jira] Commented: (SUREFIRE-328) java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/NestedRuntimeException

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste commented on SUREFIRE-328:
-

Dan, 

* I don't get any compilation failure with JarUnsignMojo
* I still cannot run my tests on XP. I will try various things like using a 
fresh local repos, etc...

When I am done with my other more pressing issues, I will look into that one.

 java.lang.NoClassDefFoundError: 
 org/apache/maven/surefire/util/NestedRuntimeException
 -

 Key: SUREFIRE-328
 URL: http://jira.codehaus.org/browse/SUREFIRE-328
 Project: Maven Surefire
  Issue Type: Bug
  Components: TestNG support
Affects Versions: 2.4
 Environment: Windows XP
 Maven 2.0.6
Reporter: Wim Deblauwe
 Attachments: mvn.log


 I just updated my surefire 2.4-SNAPSHOT plugin, but now I cannot build 
 anymore. I get a NoClassDefFoundError: 
 org/apache/maven/surefire/util/NestedRuntimeException. This is the console 
 output with the -e option:
 mvn -e clean test
 [INFO] [surefire:test]
 [INFO] Surefire report directory: C:\personal\vigilog\target\surefire-reports
 java.lang.NoClassDefFoundError: 
 org/apache/maven/surefire/util/NestedRuntimeException
 Exception in thread main
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] There are test failures.
 [INFO] 
 
 [INFO] Trace
 org.apache.maven.BuildFailureException: There are test failures.
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals 
 (DefaultLifecycleExecutor.java:560)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal 
 (DefaultLifecycleExecutor.java:459)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments 
 (DefaultLifecycleExecutor.java:278)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke (Method.java:597)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at org.codehaus.classworlds.Launcher.mainWithExitCode 
 (Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.apache.maven.plugin.MojoFailureException: There are test 
 failures.
 at org.apache.maven.plugin.surefire.SurefirePlugin.execute 
 (SurefirePlugin.java:413)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java
  :539)
 ... 16 more
 [INFO] 
 
 [INFO] Total time: 6 seconds
 [INFO] Finished at: Mon May 14 10:45:43 CEST 2007
 [INFO] Final Memory: 8M/25M
 [INFO] 
 
 I'm using the snapshot release because I use TestNG 5.5. Any solution to make 
 my build work again would be highly appriciated.
 regards,
 Wim

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

[jira] Commented: (SUREFIRE-409) test fails (due to bad plexus isolation?) after upgrading from 2.3 to latest 2.4 SNAPSHOT

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste commented on SUREFIRE-409:
-

so upgrading surefire just reveals a bug that existed before.

In my case the issue was that plexus-utils had been relocated (from plexus to 
org.codehaus.plexus) and the dependency resolver doesn't appear to be able to 
take this into account. Thus the duplication.

I've added 4-5 excludes and now the plexus deps are not duplicated in the 
classpath. I will have now to check that this indeed solves the build problem 
on Windows.

Thanks a lot for the troubleshooting.I owe you one.

 test fails (due to bad plexus isolation?) after upgrading from 2.3 to latest 
 2.4 SNAPSHOT
 -

 Key: SUREFIRE-409
 URL: http://jira.codehaus.org/browse/SUREFIRE-409
 Project: Maven Surefire
  Issue Type: Bug
  Components: classloading
Affects Versions: 2.4
Reporter: Jerome Lacoste
 Attachments: mvn_2.3_with_systemClassLoader.log, 
 mvn_2.3_without_systemClassLoader.log, mvn_2.4_with_systemClassLoader.log, 
 mvn_2.4_without_systemClassLoader.log, pom.diff, 
 pom_2.4_with_systemClassLoader.xml, svn_info.txt, test-failure-2.4.txt


 If I upgrade surefire in the Mowebstart plugin project, I get test failures:
 Caused by: java.lang.NoSuchMethodError: 
 org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars()Ljava/util/Properties;
 at 
 org.apache.maven.project.interpolation.RegexBasedModelInterpolator.init(RegexBasedModelInterpolator.java:63
 )
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
 Method)
 at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
 at java.lang.Class.newInstance0(Class.java:350)
 at java.lang.Class.newInstance(Class.java:303)
 at 
 org.codehaus.plexus.component.factory.java.JavaComponentFactory.newInstance(JavaComponentFactory.java:44)
 ... 43 more
 It sounds like SUREFIRE-347.
 Note that my build was broke on Windows. I usually build on Linux so I didn't 
 notice the problem. Maybe it has been there for a while. I also attach here 
 the error I was getting when building with 2.3 on Windows. So I removed the 
 useSystemClassLoader config (that was introduced to work-around SUREFIRE-347 
 w/ surefire 2.3...) in my POM and the build passed again on Windows (didn't 
 try on Linux).
 Then I upgraded to surefire plugin 2.4 and started to see failures in test. I 
 added the useSystemClassLoader=true section in the surefire plugin config 
 still the same issue.
 I will try on linux when I get the time...

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

[jira] Commented: (SUREFIRE-409) Upgrading to surefire 2.4-SNAPSHOT breaks my build

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste commented on SUREFIRE-409:
-

sorry for the bad title. I can't change it. Better one: test fails (due to bad 
plexus isolation?) after upgrading from 2.3 to latest 2.4 SNAPSHOT

 Upgrading to surefire 2.4-SNAPSHOT breaks my build
 --

 Key: SUREFIRE-409
 URL: http://jira.codehaus.org/browse/SUREFIRE-409
 Project: Maven Surefire
  Issue Type: Bug
  Components: classloading
Affects Versions: 2.4
Reporter: Jerome Lacoste
 Attachments: mvn_2.3_with_systemClassLoader.log, 
 mvn_2.3_without_systemClassLoader.log, mvn_2.4_with_systemClassLoader.log, 
 mvn_2.4_without_systemClassLoader.log, pom.diff, 
 pom_2.4_with_systemClassLoader.xml, svn_info.txt, test-failure-2.4.txt


 If I upgrade surefire in the Mowebstart plugin project, I get test failures:
 Caused by: java.lang.NoSuchMethodError: 
 org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars()Ljava/util/Properties;
 at 
 org.apache.maven.project.interpolation.RegexBasedModelInterpolator.init(RegexBasedModelInterpolator.java:63
 )
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
 Method)
 at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
 at java.lang.Class.newInstance0(Class.java:350)
 at java.lang.Class.newInstance(Class.java:303)
 at 
 org.codehaus.plexus.component.factory.java.JavaComponentFactory.newInstance(JavaComponentFactory.java:44)
 ... 43 more
 It sounds like SUREFIRE-347.
 Note that my build was broke on Windows. I usually build on Linux so I didn't 
 notice the problem. Maybe it has been there for a while. I also attach here 
 the error I was getting when building with 2.3 on Windows. So I removed the 
 useSystemClassLoader config (that was introduced to work-around SUREFIRE-347 
 w/ surefire 2.3...) in my POM and the build passed again on Windows (didn't 
 try on Linux).
 Then I upgraded to surefire plugin 2.4 and started to see failures in test. I 
 added the useSystemClassLoader=true section in the surefire plugin config 
 still the same issue.
 I will try on linux when I get the time...

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

[jira] Created: (SUREFIRE-409) Upgrading to surefire 2.4-SNAPSHOT breaks my build

[Jerome Lacoste (JIRA)]

Upgrading to surefire 2.4-SNAPSHOT breaks my build
--

 Key: SUREFIRE-409
 URL: http://jira.codehaus.org/browse/SUREFIRE-409
 Project: Maven Surefire
  Issue Type: Bug
  Components: classloading
Affects Versions: 2.4
Reporter: Jerome Lacoste
 Attachments: mvn_2.3_with_systemClassLoader.log, 
mvn_2.3_without_systemClassLoader.log, mvn_2.4_with_systemClassLoader.log, 
mvn_2.4_without_systemClassLoader.log, pom.diff, 
pom_2.4_with_systemClassLoader.xml, svn_info.txt, test-failure-2.4.txt

If I upgrade surefire in the Mowebstart plugin project, I get test failures:

Caused by: java.lang.NoSuchMethodError: 
org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars()Ljava/util/Properties;
at 
org.apache.maven.project.interpolation.RegexBasedModelInterpolator.init(RegexBasedModelInterpolator.java:63
)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at java.lang.Class.newInstance0(Class.java:350)
at java.lang.Class.newInstance(Class.java:303)
at 
org.codehaus.plexus.component.factory.java.JavaComponentFactory.newInstance(JavaComponentFactory.java:44)
... 43 more

It sounds like SUREFIRE-347.

Note that my build was broke on Windows. I usually build on Linux so I didn't 
notice the problem. Maybe it has been there for a while. I also attach here the 
error I was getting when building with 2.3 on Windows. So I removed the 
useSystemClassLoader config (that was introduced to work-around SUREFIRE-347 w/ 
surefire 2.3...) in my POM and the build passed again on Windows (didn't try on 
Linux).

Then I upgraded to surefire plugin 2.4 and started to see failures in test. I 
added the useSystemClassLoader=true section in the surefire plugin config still 
the same issue.

I will try on linux when I get the time...

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

[jira] Updated: (SUREFIRE-409) Upgrading to surefire 2.4-SNAPSHOT breaks my build

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste updated SUREFIRE-409:


Attachment: pom_2.4_with_systemClassLoader.xml
pom.diff
mvn_2.4_without_systemClassLoader.log

 Upgrading to surefire 2.4-SNAPSHOT breaks my build
 --

 Key: SUREFIRE-409
 URL: http://jira.codehaus.org/browse/SUREFIRE-409
 Project: Maven Surefire
  Issue Type: Bug
  Components: classloading
Affects Versions: 2.4
Reporter: Jerome Lacoste
 Attachments: mvn_2.3_with_systemClassLoader.log, 
 mvn_2.3_without_systemClassLoader.log, mvn_2.4_with_systemClassLoader.log, 
 mvn_2.4_without_systemClassLoader.log, pom.diff, 
 pom_2.4_with_systemClassLoader.xml, svn_info.txt, test-failure-2.4.txt


 If I upgrade surefire in the Mowebstart plugin project, I get test failures:
 Caused by: java.lang.NoSuchMethodError: 
 org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars()Ljava/util/Properties;
 at 
 org.apache.maven.project.interpolation.RegexBasedModelInterpolator.init(RegexBasedModelInterpolator.java:63
 )
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
 Method)
 at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
 at java.lang.Class.newInstance0(Class.java:350)
 at java.lang.Class.newInstance(Class.java:303)
 at 
 org.codehaus.plexus.component.factory.java.JavaComponentFactory.newInstance(JavaComponentFactory.java:44)
 ... 43 more
 It sounds like SUREFIRE-347.
 Note that my build was broke on Windows. I usually build on Linux so I didn't 
 notice the problem. Maybe it has been there for a while. I also attach here 
 the error I was getting when building with 2.3 on Windows. So I removed the 
 useSystemClassLoader config (that was introduced to work-around SUREFIRE-347 
 w/ surefire 2.3...) in my POM and the build passed again on Windows (didn't 
 try on Linux).
 Then I upgraded to surefire plugin 2.4 and started to see failures in test. I 
 added the useSystemClassLoader=true section in the surefire plugin config 
 still the same issue.
 I will try on linux when I get the time...

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

[jira] Updated: (MJAR-71) use manifest in classesdir/META-INF if exists

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste updated MJAR-71:
---

Attachment: MJAR-71-disabled_by_default.diff

Here's a tentative fix for the issue. I've made 2 versions, one where the 
feature is enabled by default, one disabled by default.

 use manifest in classesdir/META-INF if exists
 -

 Key: MJAR-71
 URL: http://jira.codehaus.org/browse/MJAR-71
 Project: Maven 2.x Jar Plugin
  Issue Type: Improvement
Affects Versions: 2.1
Reporter: Carlos Sanchez
 Fix For: 2.2

 Attachments: MJAR-71-disabled_by_default.diff, 
 MJAR-71-enabled_by_default.diff


 With 2.1 I need to add this to the pom to use the manifest that it's already 
 in the classes folder, make this the default
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-jar-plugin/artifactId
 version2.1/version
 configuration
   archive
 
 manifestFile${project.build.outputDirectory}/META-INF/MANIFEST.MF/manifestFile
   /archive
 /configuration
   /plugin

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

[jira] Commented: (MJAR-82) Class-Path manifest entry should support maven repository layout

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste commented on MJAR-82:


This one requires changes in the archiver, so fixing it would require releasing 
other modules. I would suggest to delay it if we want 2.2 out soon.

 Class-Path manifest entry should support maven repository layout
 

 Key: MJAR-82
 URL: http://jira.codehaus.org/browse/MJAR-82
 Project: Maven 2.x Jar Plugin
  Issue Type: Improvement
Affects Versions: 2.1
Reporter: Geoffrey De Smet
 Fix For: 2.2


 The assembly plugin supports outputting all dependencies in a repository 
 layout.
 The jar plugin should support adding the classpath manifest entry based on 
 the repository layout.
 The combination of the two makes it easy to write a script to run the app: 
 java -jar org/domain/project/projectApp.jar at the base of the repository 
 layout.
 Example of a Class-Path entry:
 ClassPath: 
 org/springframework/spring-core/2.0/spring-core-2.0.jar;org/drools/drools-core/4.0/drools-core-4.0.jar;org/domain/project/projectApp.jar
 Also see maven user mailing list maven-jar-plugin: how to avoid conflicts in 
 addClasspath

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

[jira] Commented: (MJAR-49) Jarsigner fails on windows due to spaces in pathnames

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MJAR-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116144
 ] 

Jerome Lacoste commented on MJAR-49:


Olivier, according to my users, upgrading to 1.4.8 fixed their problems.

 Jarsigner fails on windows due to spaces in pathnames
 -

 Key: MJAR-49
 URL: http://jira.codehaus.org/browse/MJAR-49
 Project: Maven 2.x Jar Plugin
  Issue Type: Bug
  Components: sign
Affects Versions: 2.1
 Environment: Windows XP
Reporter: Jon Tayler
Assignee: Olivier Lamy
 Fix For: 2.2

 Attachments: pathproblem.txt


 This is a problem uncovered while running the latest (1.0-20060307.100605-1) 
 version of the webstart plugin, which uses the jar plugin to sign jars.  
 During the signing stage maven fails with 
 [debug] jarsigner executable=[C:\Program 
 Files\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe]
 [debug] Signing JAR in-place (overwritting original JAR).
 [warn] 'C:\Program' is not recognized as an internal or external command,
 [warn] operable program or batch file.
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Result of C:\Program Files\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe 
 -verbose -keystore C:\Documents and Settings\jdt\.keystore -storepass 
 ** -keypass ** 
 E:\jdt\data\workspace\tabview\tabview-webstart\target\jnlp\commons-logging-1.0.3.jar
  roe execution is: '1'.
 [INFO] 
 
 (full trace is attached).
 It looks as though the plexus utils classes are tokenizing the path to the 
 jarsigner executable wrongly due to it containing spaces.

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

[jira] Commented: (MJAR-49) Jarsigner fails on windows due to spaces in pathnames

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MJAR-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116101
 ] 

Jerome Lacoste commented on MJAR-49:


I seem to have similar problems with other plugins. But I've upgraded them to 
p-u 1.4.2 so it's perhaps not sufficient. 
I don't run Windows so I don't see those issues. In a tentative to work around 
the problems encountered in the other plugins, I've bumped p-u to 1.4.8. See 
MWEBSTART-60 as an example.

 Jarsigner fails on windows due to spaces in pathnames
 -

 Key: MJAR-49
 URL: http://jira.codehaus.org/browse/MJAR-49
 Project: Maven 2.x Jar Plugin
  Issue Type: Bug
  Components: sign
Affects Versions: 2.1
 Environment: Windows XP
Reporter: Jon Tayler
Assignee: Olivier Lamy
 Fix For: 2.2

 Attachments: pathproblem.txt


 This is a problem uncovered while running the latest (1.0-20060307.100605-1) 
 version of the webstart plugin, which uses the jar plugin to sign jars.  
 During the signing stage maven fails with 
 [debug] jarsigner executable=[C:\Program 
 Files\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe]
 [debug] Signing JAR in-place (overwritting original JAR).
 [warn] 'C:\Program' is not recognized as an internal or external command,
 [warn] operable program or batch file.
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Result of C:\Program Files\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe 
 -verbose -keystore C:\Documents and Settings\jdt\.keystore -storepass 
 ** -keypass ** 
 E:\jdt\data\workspace\tabview\tabview-webstart\target\jnlp\commons-logging-1.0.3.jar
  roe execution is: '1'.
 [INFO] 
 
 (full trace is attached).
 It looks as though the plexus utils classes are tokenizing the path to the 
 jarsigner executable wrongly due to it containing spaces.

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

[jira] Updated: (MJAR-84) Need ability to not attach a jar when not signing in place

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste updated MJAR-84:
---

Attachment: MWEBSTART-84.diff

Attach new version of the patch (updated from the one present in MWEBSTART-34). 
The new field is not exposed as a parameter until it is really needed from the 
users of this mojo. That should be a good compromise.

 Need ability to not attach a jar when not signing in place
 --

 Key: MJAR-84
 URL: http://jira.codehaus.org/browse/MJAR-84
 Project: Maven 2.x Jar Plugin
  Issue Type: New Feature
  Components: sign
Affects Versions: 2.1
Reporter: Jerome Lacoste
Priority: Blocker
 Fix For: 2.2

 Attachments: MWEBSTART-84.diff


 I need the ability to skip attaching a jar when the sign mojo doesn't sign in 
 place. The reason is that I reuse the jarsign mojo in the webstart plugin and 
 get a NPE as no project field has been initialized by plexus. 
 I created a patch that solves my problem. It is currently attached to 
 MWEBSTART-34 
 (http://jira.codehaus.org/secure/attachment/29710/MJAR_MWEBSTART-34_support_plus_MJAR-67.diff)
  but I am not completely satisfied: ideally the sign functionality should be 
 independant of the mojo itself and this field should not be necessary.
 WDYT ?

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

[jira] Created: (MNG-3238) property not resolved in dependencyoptional for war projects

[Jerome Lacoste (JIRA)]

property not resolved in dependencyoptional for war projects


 Key: MNG-3238
 URL: http://jira.codehaus.org/browse/MNG-3238
 Project: Maven 2
  Issue Type: Bug
  Components: POM
Reporter: Jerome Lacoste
 Attachments: optional-properties-taken-from-pom.tar

I am trying to make some sort of custom skinny war files without having to use 
profiles which tend to be very verbose.

So I am using optionaltrue/optional to make those dependencies not being 
packaged.

In order to make this conditional, I tried to use a property to define the 
default value, which I can override in the command line.

This doesn't work. See attached test case.

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

[jira] Commented: (MJAR-78) jar:sign skip option does not work

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MJAR-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108907
 ] 

Jerome Lacoste commented on MJAR-78:


Can someone check in this trivial patch ?

 jar:sign skip option does not work
 --

 Key: MJAR-78
 URL: http://jira.codehaus.org/browse/MJAR-78
 Project: Maven 2.x Jar Plugin
  Issue Type: Bug
  Components: sign
Affects Versions: 2.1, 2.2
Reporter: Ryan Perkins
Priority: Minor
 Fix For: 2.2

 Attachments: MJAR-78-maven-jar-plugin.patch


 The skip option added to jar:sign in MJAR-23 prints a message saying that 
 signing will be skipped, but signing still happens.

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

[jira] Created: (MJAR-84) Need ability to not attach a jar when not signing in place

[Jerome Lacoste (JIRA)]

Need ability to not attach a jar when not signing in place
--

 Key: MJAR-84
 URL: http://jira.codehaus.org/browse/MJAR-84
 Project: Maven 2.x Jar Plugin
  Issue Type: New Feature
  Components: sign
Affects Versions: 2.1
Reporter: Jerome Lacoste
Priority: Blocker
 Fix For: 2.2


I need the ability to skip attaching a jar when the sign mojo doesn't sign in 
place. The reason is that I reuse the jarsign mojo in the webstart plugin and 
get a NPE as no project field has been initialized by plexus. 

I created a patch that solves my problem. It is currently attached to 
MWEBSTART-34 
(http://jira.codehaus.org/secure/attachment/29710/MJAR_MWEBSTART-34_support_plus_MJAR-67.diff)
 but I am not completely satisfied: ideally the sign functionality should be 
independant of the mojo itself and this field should not be necessary.

WDYT ?

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

[jira] Commented: (MJAR-49) Jarsigner fails on windows due to spaces in pathnames

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MJAR-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105694
 ] 

Jerome Lacoste commented on MJAR-49:


I believe that Brett's last comment is no longer valid starting from maven 
2.0.6.

We could bump the plexus utils version  to at least 1.4.2 to make sure this is 
fixed. (there was a regression between I think 1.2 and 1.4.1).

 Jarsigner fails on windows due to spaces in pathnames
 -

 Key: MJAR-49
 URL: http://jira.codehaus.org/browse/MJAR-49
 Project: Maven 2.x Jar Plugin
  Issue Type: Bug
Affects Versions: 2.1
 Environment: Windows XP
Reporter: Jon Tayler
 Attachments: pathproblem.txt


 This is a problem uncovered while running the latest (1.0-20060307.100605-1) 
 version of the webstart plugin, which uses the jar plugin to sign jars.  
 During the signing stage maven fails with 
 [debug] jarsigner executable=[C:\Program 
 Files\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe]
 [debug] Signing JAR in-place (overwritting original JAR).
 [warn] 'C:\Program' is not recognized as an internal or external command,
 [warn] operable program or batch file.
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Result of C:\Program Files\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe 
 -verbose -keystore C:\Documents and Settings\jdt\.keystore -storepass 
 ** -keypass ** 
 E:\jdt\data\workspace\tabview\tabview-webstart\target\jnlp\commons-logging-1.0.3.jar
  roe execution is: '1'.
 [INFO] 
 
 (full trace is attached).
 It looks as though the plexus utils classes are tokenizing the path to the 
 jarsigner executable wrongly due to it containing spaces.

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

[jira] Commented: (MJAR-67) jar:sign - Jars containing invalid remains of older signatures won't get signed

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MJAR-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105697
 ] 

Jerome Lacoste commented on MJAR-67:


 The problem seems to be that jarsigner is called with -verify - although I'm 
 explicitely turning it of in plugin configuration.

I have a feeling that the attached patch is not enough right way to fix the 
issue,

The exception should be thrown by default and a user flag should be there to 
allow bypassing the failed check.
Also the log message should be warn instead of info. Patch coming.

Finally you could also try to remove signatures (try the webstart:unsign mojo)

Another solution was for JarSignVerifyMojo to not throw an exception when 
errorWhenNotSigned is true, which I didn't like much,


 jar:sign - Jars containing invalid remains of older signatures won't get 
 signed
 ---

 Key: MJAR-67
 URL: http://jira.codehaus.org/browse/MJAR-67
 Project: Maven 2.x Jar Plugin
  Issue Type: Bug
  Components: sign
Affects Versions: 2.1
 Environment: Maven 2.0.4 on Windows XP
 JDK 1.5.0_08
Reporter: Gottfried Ganßauge
 Attachments: error.log, jar-plugin.patch, pom.xml


 I'm trying to ease the burden of applet deployment by integrating every 
 dependency of that applet into the applet's .jar archive.
 For this purpose I'm using the unpack goal of the dependency plugin (see 
 attached POM).
 For a particular case I had to integrate an already signed applet.
 There is no way I can get the integrated jar signed using jar:sign - I always 
 get an error from jarsigner (see attached error.log).
 The problem seems to be that jarsigner is called with -verify - although I'm 
 explicitely turning it of in plugin configuration.
 When calling jarsigned from the command line without -verify it runs to 
 completion.
 When running it with -verify from the command line the same error occurs as 
 in the maven build.

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

[jira] Updated: (MJAR-67) jar:sign - Jars containing invalid remains of older signatures won't get signed

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste updated MJAR-67:
---

Attachment: MJAR-67.diff

Force the user to add a flag to bypass this issue. Failures cause by signing an 
already signed jar should not go unnoticed.

So the exception is thrown by default and a user flag is added to allow 
bypassing the failed check.
Finally the log message is a warning instead of info.

 jar:sign - Jars containing invalid remains of older signatures won't get 
 signed
 ---

 Key: MJAR-67
 URL: http://jira.codehaus.org/browse/MJAR-67
 Project: Maven 2.x Jar Plugin
  Issue Type: Bug
  Components: sign
Affects Versions: 2.1
 Environment: Maven 2.0.4 on Windows XP
 JDK 1.5.0_08
Reporter: Gottfried Ganßauge
 Attachments: error.log, jar-plugin.patch, MJAR-67.diff, pom.xml


 I'm trying to ease the burden of applet deployment by integrating every 
 dependency of that applet into the applet's .jar archive.
 For this purpose I'm using the unpack goal of the dependency plugin (see 
 attached POM).
 For a particular case I had to integrate an already signed applet.
 There is no way I can get the integrated jar signed using jar:sign - I always 
 get an error from jarsigner (see attached error.log).
 The problem seems to be that jarsigner is called with -verify - although I'm 
 explicitely turning it of in plugin configuration.
 When calling jarsigned from the command line without -verify it runs to 
 completion.
 When running it with -verify from the command line the same error occurs as 
 in the maven build.

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

[jira] Commented: (MNG-2962) (False) transitive dependencies don't appear on the compiler classpath in some windows environments since m2.0.6.

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste commented on MNG-2962:
-

in your fail build log:

   be.schaubroeck.atlas:atlas-spring:test-jar:tests:0.4.0-SNAPSHOT:test 
(selected for test)
 commons-logging:commons-logging:jar:1.1:test (applying scope: compile)
 be.schaubroeck.atlas:atlas-core:jar:0.4.0-SNAPSHOT:test (applying scope: 
compile)
 commons-lang:commons-lang:jar:2.2:test (applying scope: compile)
 org.springframework:spring-beans:jar:2.0.2:test (applying scope: compile)
 org.springframework:spring-beans:jar:2.0.2:compile (selected for compile)
 org.springframework:spring-context:jar:2.0.2:test (applying scope: compile)

notice how spring-beans jar is both as test and compile scope. This doesn't 
happen in the working one.

Are you 100% sure that your poms are completely identical on both machines, 
including local caches ?

Why is working machine has this in the logs:

+[DEBUG] Skipping disabled repository schaubroeck-dev
+[DEBUG] maven-compiler-plugin: resolved to version 2.0.2 from repository 
central

?

 (False) transitive dependencies don't appear on the compiler classpath in 
 some windows environments since m2.0.6.
 -

 Key: MNG-2962
 URL: http://jira.codehaus.org/browse/MNG-2962
 Project: Maven 2
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 2.0.6
 Environment: windows
Reporter: Geoffrey De Smet
 Attachments: m2.0.6-failing-compile-machineC.log, 
 m2.0.6-working-compile-machineB.log


 Since m2.0.6 builds that work perfectly on linux machine A and sometimes even 
 on a windows machine B, breaks on another windows machine C.
 We have some false transitive dependencies: transitive dependencies that 
 should be direct dependencies.
 (We currently do this to avoid having to duplicate the version number as the 
 different projects don't have a common superpom.)
 Making those dependencies direct dependencies fixes the problem with windows 
 machine C, but the real problem is that the guy on linux machine A should get 
 the problems too, before committing.
 The compiler plugin version is locked down to 2.0.2, but are using maven 
 2.0.6. This did not occur in maven 2.0.5.
 Attached you'll find the mvn -X install logs of the 2 windows machines.
 The log of machine C is specifically interesting, as it shows 
 spring-beans:2.0.2 as a transitive dependency, yet it forgets it on the 
 classpath in the compiler plugin:
 [DEBUG] Adding managed depedendencies for unknown:atlas-spring
 ...
 [DEBUG]   org.springframework:spring-beans:jar:2.0.2:compile
 ...
 [DEBUG] Classpath: [d:\sources\atlas-all\atlas-checkpoint\target\classes
 .. (no org.springframework:spring-beans:jar:2.0.2)
 Machine B instead has instead this at the classpath log part:
 [DEBUG] Classpath: [d:\projects\sb\atlas_all\atlas-checkpoint\target\classes
 ...
  C:\Documents and 
 Settings\gds\.m2\repository\org\springframework\spring-beans\2.0.2\spring-beans-2.0.2.jar

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

[jira] Created: (SUREFIRE-324) Deploy the 2.3 documentation

[Jerome Lacoste (JIRA)]

Deploy the 2.3 documentation


 Key: SUREFIRE-324
 URL: http://jira.codehaus.org/browse/SUREFIRE-324
 Project: Maven Surefire
  Issue Type: Task
  Components: documentation
Affects Versions: 2.3
Reporter: Jerome Lacoste
Priority: Critical


2.3 doc not online. Support for JUnit 4 is in and documentation is misleading.

See 
http://www.nabble.com/surefire-and-junit-4-website-out-of-date-t3584296s177.html

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

[jira] Commented: (MECLIPSE-38) Allow custom code formatters to be written to .settings

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste commented on MECLIPSE-38:


Some thoughts
* the set of rules and the formatter don't completely match.
* given a checkstyle XML file it is hard to know to which version of checkstyle 
the config applies. The DTD hasn't changed for a while.
* an idea could be to have the tool that converts from checkstyle to eclipse 
outside of this plugin. The tool could part of checkstyle or eclipse, or 
completely separate.

 Allow custom code formatters to be written to .settings
 ---

 Key: MECLIPSE-38
 URL: http://jira.codehaus.org/browse/MECLIPSE-38
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Improvement
Affects Versions: 2.0
Reporter: Mark Hobson

 It'd be handy if there was a way of embedding custom code formatters to 
 .settings.  Eclipse can currently export code formatter profiles as a list of 
 properties in an XML format, so this file could be configured against the 
 eclipse plugin for it to generate the corresponding properties-format 
 .settings/org.eclipse.jdt.core.prefs file.

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

[jira] Created: (MSITE-216) Don't break lines in apt generated table cells

[Jerome Lacoste (JIRA)]

Don't break lines in apt generated table cells
--

 Key: MSITE-216
 URL: http://jira.codehaus.org/browse/MSITE-216
 Project: Maven 2.x Site Plugin
  Issue Type: Improvement
 Environment: mvn 2.0.5
Reporter: Jerome Lacoste
Priority: Trivial
 Attachments: APT-tables.png

See attached screenshot. Is there a way to make this table look nicer ? I.e. 
get rid off the br ?

lacostej_ how does one create multiline table cells in APT format 
? the parser introduces br elements and that makes the rendering ugly
lacostej_ I have a screenshot of the problem available
lacostej_ kenney: http://www.flickr.com/photos/[EMAIL 
PROTECTED]/421928169/
kenneycan you paste the apt for the table?

*--+--+
|command line  |   Java Mojo
  |
*--+--+
| the VM exits as soon as the only |  By default daemon threads are joined  
  |
| remaining threads are daemon threads | and interrupted once all known non 
  |
|  | daemon threads have quitted. The join  
  |
|  | timeout is customisable
  |
|  | The user might wish to further cleanup 
  |
|  | cleanup by stopping the unresponsive   
  |
|  | threads.   
  |
|  | The user can disable the full extra
  |
|  | thread management 
(interrupt/join/[stop])|
*--+--+

kenneylacostej_: i'd say that the APT engine produced a 
one-on-one image of the source, quite nice ;)
lacostej_ :)
kenneyi guess you have to put everything on 1 line to make it 
render properly
kenneytoo bad you can't specify 'align=justify'
kenneywhat about \ ?
kenneyow crap: Line breaks must not be used inside titles and 
tables (which are line oriented blocks with implicit line breaks).
kenneyand \ is a line break, instead of a continuation as is 
used everywhere else

EODiscussion



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

[jira] Commented: (MSITE-216) Don't break lines in apt generated table cells

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste commented on MSITE-216:
--

Jira screewed up my ATP table.. See http://pastebin.ca/395850 for a paste.

 Don't break lines in apt generated table cells
 --

 Key: MSITE-216
 URL: http://jira.codehaus.org/browse/MSITE-216
 Project: Maven 2.x Site Plugin
  Issue Type: Improvement
 Environment: mvn 2.0.5
Reporter: Jerome Lacoste
Priority: Trivial
 Attachments: APT-tables.png


 See attached screenshot. Is there a way to make this table look nicer ? I.e. 
 get rid off the br ?
   lacostej_ how does one create multiline table cells in APT format 
 ? the parser introduces br elements and that makes the rendering ugly
   lacostej_ I have a screenshot of the problem available
   lacostej_ kenney: http://www.flickr.com/photos/[EMAIL 
 PROTECTED]/421928169/
   kenneycan you paste the apt for the table?
 *--+--+
 |command line  |   Java Mojo  
 |
 *--+--+
 | the VM exits as soon as the only |  By default daemon threads are 
 joined|
 | remaining threads are daemon threads | and interrupted once all known non   
 |
 |  | daemon threads have quitted. The 
 join|
 |  | timeout is customisable  
 |
 |  | The user might wish to further 
 cleanup   |
 |  | cleanup by stopping the unresponsive 
 |
 |  | threads. 
 |
 |  | The user can disable the full extra  
 |
 |  | thread management 
 (interrupt/join/[stop])|
 *--+--+
   kenneylacostej_: i'd say that the APT engine produced a 
 one-on-one image of the source, quite nice ;)
   lacostej_ :)
   kenneyi guess you have to put everything on 1 line to make it 
 render properly
   kenneytoo bad you can't specify 'align=justify'
   kenneywhat about \ ?
   kenneyow crap: Line breaks must not be used inside titles and 
 tables (which are line oriented blocks with implicit line breaks).
   kenneyand \ is a line break, instead of a continuation as is 
 used everywhere else
 EODiscussion

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

[jira] Commented: (MNG-2293) maven-plugin-descriptor: Not possible to define a default implementation for a field defined by its interface

[Jerome Lacoste (JIRA)]

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

Jerome Lacoste commented on MNG-2293:
-

I believe this has not been properly fixed. I am now working on MWEBSTART-18 
using maven 2.0.5 and maven doesn't add the default implementation to the 
generated  plugin.xml file. Maybe my integration test was incorrect which led 
Kenney to think that MNG-2352 was not a blocker ?

In the end, I think we need to make sure that the fix for  PLX-219 is used by 
maven. Will try to trouble shoot the issue.

 maven-plugin-descriptor: Not possible to define a default implementation for 
 a field defined by its interface
 -

 Key: MNG-2293
 URL: http://jira.codehaus.org/browse/MNG-2293
 Project: Maven 2
  Issue Type: New Feature
  Components: Plugin Creation Tools
Affects Versions: 2.0.4
Reporter: Jerome Lacoste
 Assigned To: Kenney Westerhof
Priority: Critical
 Fix For: 2.0.5, 2.1

 Attachments: dependency-mistery.log, it0106.tar.bz2, 
 MNG-2293-plugins.diff, MNG-2293.diff, MNG-2293.diff, 
 patch-MNG-2293-source2.tar.bz2, patch-MNG-2293.diff


 MOJO-393 is about letting the user define an alternate configuration element, 
 thus changing the way the webstart plugin works.
 For that the idea was to make the mojo field an interface, provide a default 
 implementation in the plugin and let the user use plexus to instanciate a new 
 implemenation.
 so for most users we would have:
 configuration
   bla
   /bla
 /configuration
 and for some:
 configuration
   bla implementation=combla
   /bla
 /configuration
 Unfortunately, today I am forced to specify the implementation in both cases. 
 There's no way to inform the plugin to use the default implementation.
 The plugin.xml contains:
 parameter
   namebla/name
   type...BlaInterface/type !-- that will fail --
...
 /parameter
 I tried to use 
  /[EMAIL PROTECTED] implementation=...BlaImplementation*/
  BlaInterface bla;
 but that fails as well.
 Marking critical because it doesn't allow me add new features to the plugin 
 without breaking the config.xml.

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

[jira] Commented: (MNG-2762) warning during tar unpackaging

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2762?page=comments#action_84918 ] 

Jerome Lacoste commented on MNG-2762:
-

The issue might be simiilar to http://pear.php.net/bugs/bug.php?id=5452

Does that mean that the fix is to change

http://svn.codehaus.org/plexus/plexus-components/trunk/plexus-archiver/src/main/java/org/codehaus/plexus/archiver/tar/TarOutputStream.java

public void finish()
throws IOException
{
this.writeEOFRecord();
}

into

public void finish()
throws IOException
{
this.writeEOFRecord();
this.writeEOFRecord();
}

??

Then as in the PHP Pear issue above, care must be taken if there are other 
parts of the archiver that expects a single empty block.

 warning during tar unpackaging
 --

 Key: MNG-2762
 URL: http://jira.codehaus.org/browse/MNG-2762
 Project: Maven 2
  Issue Type: Bug
  Components: Bootstrap  Build
Reporter: Tomasz Pik
Priority: Minor

 Using tar distribution, during upackaging I'm getting:
 tar: A lone zero block at 4174
 warning message in output.
 Archive is being untarred correctly but this message may worry users that 
 archive is corrupted

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

[jira] Closed: (MPWAR-39) Documentation: filter web.xml should recommend to add a pregoal to war:war-resources

[Jerome Lacoste (JIRA)]

 [ http://jira.codehaus.org/browse/MPWAR-39?page=all ]

Jerome Lacoste closed MPWAR-39.
---


 Documentation: filter web.xml should recommend to add a pregoal to 
 war:war-resources
 

 Key: MPWAR-39
 URL: http://jira.codehaus.org/browse/MPWAR-39
 Project: maven-war-plugin
  Issue Type: Improvement
Reporter: Jerome Lacoste
 Assigned To: Stephane Nicoll
 Fix For: 1.6.2


 Documentation says:
 If you need to copy the web.xml file in order to replace some filter tokens 
 or simply perform some custom modification to it, simply write a pre-goal to 
 the war:war goal in which you perform the manipulation. Then set the 
 maven.war.webxml property to point to your modified web.xml.
 instead it could say
 [...] simply write a pre-goal to the war:war-resources [...] 
 Otherwise it won't work with exploded war files.

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

[jira] Commented: (MAVENUPLOAD-1322) Intellij 6.0.3 redistribution jars

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1322?page=comments#action_84847 ] 

Jerome Lacoste commented on MAVENUPLOAD-1322:
-

Forgot to say: I need this to update the ideauidesigner Mojo plugin. Thanks !

 Intellij 6.0.3 redistribution jars
 --

 Key: MAVENUPLOAD-1322
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1322
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Jerome Lacoste
 Attachments: annotations-6.0.3-bundle.jar, forms_rt-6.0.3-bundle.jar, 
 javac2-6.0.3-bundle.jar


 Intellij 5.0 and 5.1 jars are already distributed on ibiblio:
 http://www.ibiblio.org/maven2/com/intellij/
 The poms are manually made and have been verified by compiling the sources 
 distributed with IDEA. Should I remove the build section from the POM ?
  md5sum /usr/local/lib/idea-6.0.3/redist/*.jar 
  /usr/local/lib/idea-6.0.3/redist/src/*
 b5132ca1ac90701c0ae2622fe191c4b9  
 /usr/local/lib/idea-6.0.3/redist/annotations.jar
 dfed9d14de41952e73a4a87e47699271  
 /usr/local/lib/idea-6.0.3/redist/forms_rt.jar
 aeea1eb6fab86f4cdb5aa6aba4a5ae5c  /usr/local/lib/idea-6.0.3/redist/javac2.jar
 6549d92828826d00e8fd1f1676d002d9  
 /usr/local/lib/idea-6.0.3/redist/src/src_annotations.zip
 de80928aeaebec995b8bd64ac84385eb  
 /usr/local/lib/idea-6.0.3/redist/src/src_forms_rt.zip
 3eba12d85a5ecb71f80e952be5e6017e  
 /usr/local/lib/idea-6.0.3/redist/src/src_javac2.zip
 One can get IDEA from http://www.jetbrains.com/idea/download

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

[jira] Created: (MAVENUPLOAD-1322) Intellij 6.0.3 redistribution jars

[Jerome Lacoste (JIRA)]

Intellij 6.0.3 redistribution jars
--

 Key: MAVENUPLOAD-1322
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1322
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Jerome Lacoste
 Attachments: annotations-6.0.3-bundle.jar, forms_rt-6.0.3-bundle.jar, 
javac2-6.0.3-bundle.jar

Intellij 5.0 and 5.1 jars are already distributed on ibiblio:

http://www.ibiblio.org/maven2/com/intellij/

The poms are manually made and have been verified by compiling the sources 
distributed with IDEA. Should I remove the build section from the POM ?

 md5sum /usr/local/lib/idea-6.0.3/redist/*.jar 
 /usr/local/lib/idea-6.0.3/redist/src/*
b5132ca1ac90701c0ae2622fe191c4b9  
/usr/local/lib/idea-6.0.3/redist/annotations.jar
dfed9d14de41952e73a4a87e47699271  /usr/local/lib/idea-6.0.3/redist/forms_rt.jar
aeea1eb6fab86f4cdb5aa6aba4a5ae5c  /usr/local/lib/idea-6.0.3/redist/javac2.jar
6549d92828826d00e8fd1f1676d002d9  
/usr/local/lib/idea-6.0.3/redist/src/src_annotations.zip
de80928aeaebec995b8bd64ac84385eb  
/usr/local/lib/idea-6.0.3/redist/src/src_forms_rt.zip
3eba12d85a5ecb71f80e952be5e6017e  
/usr/local/lib/idea-6.0.3/redist/src/src_javac2.zip

One can get IDEA from http://www.jetbrains.com/idea/download

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

[jira] Created: (MPLUGIN-26) Parsing issue due to qdox regression

[Jerome Lacoste (JIRA)]

Parsing issue due to qdox regression


 Key: MPLUGIN-26
 URL: http://jira.codehaus.org/browse/MPLUGIN-26
 Project: Maven 2.x Plugin Plugin
  Issue Type: Bug
Affects Versions: 2.2
Reporter: Jerome Lacoste
Priority: Blocker


The webstart plugin build broke as the latest qdox (1.6.1) doesn't parse valid 
code.

See QDOX-107

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

[jira] Commented: (MJAR-26) Need the ability to unsign a jar

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MJAR-26?page=comments#action_83520 ] 

Jerome Lacoste commented on MJAR-26:


FYI, after an almost year stall, I finally commited the code in the webstart 
plugin. If you need to unsign jars, look at the unsign mojo inside that plugin.

 Need the ability to unsign a jar
 

 Key: MJAR-26
 URL: http://jira.codehaus.org/browse/MJAR-26
 Project: Maven 2.x Jar Plugin
  Issue Type: New Feature
Reporter: Jerome Lacoste
Priority: Critical

 There are some issues with doubly signed jars. We need a way to unsign those 
 jars.
 I have some code in the webstart plugin (not yet committed to svn) that deals 
 with that (patch came from Andrius Šabanas).
 But this is also something that once may want to do once and for all.
 I will wait for the code to stabilize and will submit it here when we have 
 tested it sufficiently.

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

[jira] Commented: (MNG-2621) IncludesArtifactFilter in maven-artifact should accept wildcards

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2621?page=comments#action_80383 ] 

Jerome Lacoste commented on MNG-2621:
-

It would be nice if you could add a unit test. Then +1 from me

 IncludesArtifactFilter in maven-artifact should accept wildcards
 

 Key: MNG-2621
 URL: http://jira.codehaus.org/browse/MNG-2621
 Project: Maven 2
  Issue Type: Improvement
  Components: Artifacts
Reporter: Brian Topping
 Attachments: IncludesArtifactFilter.patch


 There is a todo in 
 http://svn.apache.org/viewvc/maven/components/trunk/maven-artifact/src/main/java/org/apache/maven/artifact/resolver/filter/IncludesArtifactFilter.java?view=markup
  to add regex.  I checked all the sources and could only find usages of this 
 code by maven-assembly-plugin, webstart-maven-plugin and exec-maven-plugin.  
 The latter two are in mojo.  
 If you look at 
 http://svn.palle.net/projects/hauskeeper/hauskeeper-server/src/assemblies/debian.xml,
  Trygvis is assuming that wildcards work, when in fact they do not.  
 Arguably, this is a documentation bug that it does not work.
 The attached patch fixes this problem.

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

[jira] Created: (MCHECKSTYLE-48) regression: report generation doesn't work while dealing with the header file

[Jerome Lacoste (JIRA)]

regression: report generation doesn't work while dealing with the header file
-

 Key: MCHECKSTYLE-48
 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-48
 Project: Maven 2.x Checkstyle Plugin
Type: Bug

 Environment: Checkstyle 2.2-SNAPSHOT rev 419829.
Reporter: Jerome Lacoste
Priority: Blocker
 Attachments: mvn.log

Configured as is:

  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
configuration
  configLocationconfig/maven_checks.xml/configLocation
/configuration
  /plugin

Checkstyle stopped working. I made a fresh svn update and mvn 
checkstyle:checkstyle fails with:

[...]
Caused by: com.puppycrawl.tools.checkstyle.api.CheckstyleException: cannot 
initialize module TreeWalker - Cannot set property 'headerFile' in module 
RegexpHeader to 
'/home/jerome/Dev/OSS/perso/jar-info/target/checkstyle-header.txt': line 24 in 
header specification is not a regular expression
at com.puppycrawl.tools.checkstyle.Checker.setupChild(Checker.java:165)
at 
com.puppycrawl.tools.checkstyle.api.AutomaticBean.configure(AutomaticBean.java:209)
at 
org.apache.maven.plugin.checkstyle.CheckstyleReport.executeCheckstyle(CheckstyleReport.java:729)
at 
org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:490)
[...]
Caused by: org.apache.commons.beanutils.ConversionException: line 24 in header 
specification is not a regular expression
at 
com.puppycrawl.tools.checkstyle.checks.header.RegexpHeaderCheck.initHeaderRegexps(RegexpHeaderCheck.java:116)
at 
com.puppycrawl.tools.checkstyle.checks.header.RegexpHeaderCheck.setHeaderFile(RegexpHeaderCheck.java:85)
... 34 more

Full log attached.

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

[jira] Created: (MNG-2421) [plugins/docck] fail to run org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Jdk14Logger does not implement Log

[Jerome Lacoste (JIRA)]

[plugins/docck] fail to run 
org.apache.commons.logging.LogConfigurationException: Class 
org.apache.commons.logging.impl.Jdk14Logger does not implement Log


 Key: MNG-2421
 URL: http://jira.codehaus.org/browse/MNG-2421
 Project: Maven 2
Type: Bug

  Components: Sandbox  
 Environment: maven 2.0.4
Reporter: Jerome Lacoste
 Attachments: mvn.log

This happens when I try running it on the under the 
mojo/webstart-maven-plugin/plugin directory

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

[jira] Created: (MASSEMBLY-124) DpendencySet doesn't work anymore when taken from executedProject

[Jerome Lacoste (JIRA)]

DpendencySet doesn't work anymore when taken from executedProject
-

 Key: MASSEMBLY-124
 URL: http://jira.codehaus.org/browse/MASSEMBLY-124
 Project: Maven 2.x Assembly Plugin
Type: Bug

Versions: 2.2
 Environment: maven 2.0.4
Reporter: Jerome Lacoste
Priority: Blocker
 Attachments: patch.diff

One of my project build just broke after an upgrade to the latest plugins.

assembly contains:

  dependencySets
dependencySet
  outputDirectorylib/outputDirectory
  unpackfalse/unpack
  scoperuntime/scope
/dependencySet

If I add a logging to the DirectoryMojo class I can see that no dependencies 
are seen for the project.

+getLog().debug( DependencySet[ + output + ] +  
allDependencies:  + allDependencyArtifacts.size()
++  filtered:  + dependencyArtifacts.size() );
+

[INFO] [assembly:directory]
[...]
[DEBUG] DependencySet[ubd-1.0.1-SNAPSHOT/lib/] dir perms: 40755 file perms: 
100644
[DEBUG] DependencySet[ubd-1.0.1-SNAPSHOT/lib/] allDependencies: 0 filtered: 0
[...]

If I force the plugin to use the original project (not the executedProject), 
assembly works again (see patch).

As such, this issue very similar to the MCLIRR-2 one encountered by Vincent.

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

[jira] Commented: (MJAR-49) Jarsigner fails on windows due to spaces in pathnames

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MJAR-49?page=comments#action_69081 ] 

Jerome Lacoste commented on MJAR-49:


Looking at the plexus code, I believe the problem may be fixed by forcing the 
upgrade to plexus = 1.2 (where the shell element was introduced).

Could you try building a local maven-jar-plugin that reuses the latest plexus 
and see if that fixes your issue ?


 Jarsigner fails on windows due to spaces in pathnames
 -

  Key: MJAR-49
  URL: http://jira.codehaus.org/browse/MJAR-49
  Project: Maven 2.x Jar Plugin
 Type: Bug

 Versions: 2.1
  Environment: Windows XP
 Reporter: Jon Tayler
  Attachments: pathproblem.txt


 This is a problem uncovered while running the latest (1.0-20060307.100605-1) 
 version of the webstart plugin, which uses the jar plugin to sign jars.  
 During the signing stage maven fails with 
 [debug] jarsigner executable=[C:\Program 
 Files\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe]
 [debug] Signing JAR in-place (overwritting original JAR).
 [warn] 'C:\Program' is not recognized as an internal or external command,
 [warn] operable program or batch file.
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Result of C:\Program Files\Java\jdk1.5.0_06\jre\..\bin\jarsigner.exe 
 -verbose -keystore C:\Documents and Settings\jdt\.keystore -storepass 
 ** -keypass ** 
 E:\jdt\data\workspace\tabview\tabview-webstart\target\jnlp\commons-logging-1.0.3.jar
  roe execution is: '1'.
 [INFO] 
 
 (full trace is attached).
 It looks as though the plexus utils classes are tokenizing the path to the 
 jarsigner executable wrongly due to it containing spaces.

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

[jira] Commented: (MNG-2352) Upgrade to plexus-container-default-alpha-10

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2352?page=comments#action_68676 ] 

Jerome Lacoste commented on MNG-2352:
-

Brett, 

Nothing else interesting in the stack trace? What does trigger this lookup ?

I created the patch on the trunk.  So the problem could either be an 
incompatibility, or something that changed in the past 2 weeks. Will try to 
look at it again. 

 Upgrade to plexus-container-default-alpha-10
 

  Key: MNG-2352
  URL: http://jira.codehaus.org/browse/MNG-2352
  Project: Maven 2
 Type: Improvement

 Reporter: Jerome Lacoste
 Priority: Blocker
  Fix For: 2.0.5
  Attachments: MNG-2352.diff


 This is required for MNG-2201 in particular.

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

[jira] Commented: (MRELEASE-35) release plugin doesn't tag correctly with svn+ssh when remote and local username don't match

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MRELEASE-35?page=comments#action_68093 ] 

Jerome Lacoste commented on MRELEASE-35:


I've just been beaten by that :(

Basically, --username is ignored for every command with a URLs based on svn+ssh 
form. Dixit darix on #svn. Will try to find a fix.

 release plugin doesn't tag correctly with svn+ssh when remote and local 
 username don't match
 

  Key: MRELEASE-35
  URL: http://jira.codehaus.org/browse/MRELEASE-35
  Project: Maven 2.x Release Plugin
 Type: Bug

 Reporter: Brett Porter
  Fix For: 2.0


 Original Estimate: 30 minutes
 Remaining: 30 minutes

 svn is very stubborn about this. Basically you have to have the value in 
 developerConnection match the url used to check it out.
 Things that will fail:
 - if you pass in a different username to --username, it is not passed on to 
 ssh
 - if you specify a username in the ssh command it works, as long as the URL 
 is the same in both. svn+ssh://[EMAIL PROTECTED]/... is considered a 
 different repository to svn+ssh://foo/... even if I am bporter
 I think we can take a couple of steps:
 - for svn+ssh, put the username in the URL instead of passing --username
 - possibly check the current checkout (svn info) and derive the tag location 
 from that, ignoring the local checkout OR if they don't match, relocate the 
 local checkout to that of developerConnection
 - use javasvn instead

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

[jira] Commented: (MRELEASE-35) release plugin doesn't tag correctly with svn+ssh when remote and local username don't match

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MRELEASE-35?page=comments#action_68094 ] 

Jerome Lacoste commented on MRELEASE-35:


After some more tests, of all the commands currently implemented in the scm 
provider, 

 log, co, diff, list, remove all work with --username and no username in the 
svn+ssh://server.com...

so copy seems to be the only command that requires to be fixed. Taking issue...

 release plugin doesn't tag correctly with svn+ssh when remote and local 
 username don't match
 

  Key: MRELEASE-35
  URL: http://jira.codehaus.org/browse/MRELEASE-35
  Project: Maven 2.x Release Plugin
 Type: Bug

 Reporter: Brett Porter
  Fix For: 2.0


 Original Estimate: 30 minutes
 Remaining: 30 minutes

 svn is very stubborn about this. Basically you have to have the value in 
 developerConnection match the url used to check it out.
 Things that will fail:
 - if you pass in a different username to --username, it is not passed on to 
 ssh
 - if you specify a username in the ssh command it works, as long as the URL 
 is the same in both. svn+ssh://[EMAIL PROTECTED]/... is considered a 
 different repository to svn+ssh://foo/... even if I am bporter
 I think we can take a couple of steps:
 - for svn+ssh, put the username in the URL instead of passing --username
 - possibly check the current checkout (svn info) and derive the tag location 
 from that, ignoring the local checkout OR if they don't match, relocate the 
 local checkout to that of developerConnection
 - use javasvn instead

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

[jira] Created: (SCM-217) workaround svn issue with svn+ssh scheme requiring to specify [EMAIL PROTECTED] and ignoring --username

[Jerome Lacoste (JIRA)]

workaround svn issue with svn+ssh scheme requiring to specify [EMAIL PROTECTED] 
and ignoring --username
---

 Key: SCM-217
 URL: http://jira.codehaus.org/browse/SCM-217
 Project: Maven SCM
Type: Bug

  Components: maven-scm-provider-svn  
Versions: 1.0-beta-3
Reporter: Jerome Lacoste
Priority: Blocker
 Attachments: SCM-217.diff

See MRELEASE-35 for details.

Here's the patch: I fixed the tag and checkout commands. Other commands may 
need to be fixed for other purposes, but I didn't try to.

The patch comes with basic unit tests (for tag command not checkout command, as 
the fix is identical) and I tested the patch locally doing a release of a 
project onto a ssh based server. Both release:prepare and release:perform now 
work.

I don't give rights to Apache with regard to reusing the code.

Kidding... :)

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

[jira] Commented: (MRELEASE-35) release plugin doesn't tag correctly with svn+ssh when remote and local username don't match

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MRELEASE-35?page=comments#action_68109 ] 

Jerome Lacoste commented on MRELEASE-35:


Just as a side note, the patched release plugin failed during site generation 
because of cobertura failing to find the CommandLineBuilder class. probably 
another issue, but wanted to add it here just in case.

 release plugin doesn't tag correctly with svn+ssh when remote and local 
 username don't match
 

  Key: MRELEASE-35
  URL: http://jira.codehaus.org/browse/MRELEASE-35
  Project: Maven 2.x Release Plugin
 Type: Bug

 Reporter: Brett Porter
  Fix For: 2.0


 Original Estimate: 30 minutes
 Remaining: 30 minutes

 svn is very stubborn about this. Basically you have to have the value in 
 developerConnection match the url used to check it out.
 Things that will fail:
 - if you pass in a different username to --username, it is not passed on to 
 ssh
 - if you specify a username in the ssh command it works, as long as the URL 
 is the same in both. svn+ssh://[EMAIL PROTECTED]/... is considered a 
 different repository to svn+ssh://foo/... even if I am bporter
 I think we can take a couple of steps:
 - for svn+ssh, put the username in the URL instead of passing --username
 - possibly check the current checkout (svn info) and derive the tag location 
 from that, ignoring the local checkout OR if they don't match, relocate the 
 local checkout to that of developerConnection
 - use javasvn instead

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

[jira] Commented: (MCHANGELOG-38) NPE when developer section does not include an id

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MCHANGELOG-38?page=comments#action_67913 
] 

Jerome Lacoste commented on MCHANGELOG-38:
--

The id is required for the changelog plugin to work, otherwise it cannot match 
your SCM id to your name. So I don't think this is critical.

The code could be more resistant and throw a user friendly exception instead of 
a NPE though.

 NPE when developer section does not include an id
 -

  Key: MCHANGELOG-38
  URL: http://jira.codehaus.org/browse/MCHANGELOG-38
  Project: Maven 2.x Changelog Plugin
 Type: Bug

 Reporter: Baerrach bonDierne
 Priority: Critical



 [DEBUG] Trace
 java.lang.NullPointerException
 at java.util.Hashtable.put(Hashtable.java:398)
 at 
 org.apache.maven.changelog.ChangeLog.getUserList(ChangeLog.java:530)
 at 
 org.apache.maven.changelog.ChangeLog.replaceAuthorIdWithName(ChangeLog.java:541)
 at org.apache.maven.changelog.ChangeLog.doExecute(ChangeLog.java:370)
 at 
 org.apache.maven.changelog.ChangeLogReport.getChangeLog(ChangeLogReport.java:263)
 at 
 org.apache.maven.changelog.ChangeLogReport.generateChangeSetsFromSCM(ChangeLogReport.java:218)
 at 
 org.apache.maven.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:198)
 at 
 org.apache.maven.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:173)
 at 
 org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117)
 at 
 org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:67)
 at 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:239)
 This is easy to replicate, find a working mvn site and then remove an id 
 from a developer.
 This is for plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-changelog-plugin/artifactId
 I'd like to provide version details but this plugin isn't in my repository! 
 So I am not sure how it is actually working.
 The website does't point to a repository, and I accidentally found it at 
 http://svn.apache.org/repos/asf/maven/sandbox/plugins/maven-changelog-plugins
 but this code doesn't match up with the error message.
 I couldn't find the code base from the the old codehaus repository either.

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

[jira] Commented: (MJAR-31) [webstart] NPE when signing dependencies

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MJAR-31?page=comments#action_68038 ] 

Jerome Lacoste commented on MJAR-31:


Can we close that one? I am 95% sure the issue was fixed. It just didn't make 
it into a stable release yet.

 [webstart] NPE when signing dependencies
 

  Key: MJAR-31
  URL: http://jira.codehaus.org/browse/MJAR-31
  Project: Maven 2.x Jar Plugin
 Type: Bug

  Environment: WinXP
 Maven 2.0.2
 Latest maven-jar-plugin from SVN
 Latest webstart checkout
 Reporter: Michael Böckling
 Priority: Critical
  Attachments: MOJO-295.diff


 In JarSignMojo, the call to this.signedjar.getPath() produces a NPE, because 
 in JnlpMojo:863, signJar.setSignedJar() has been commented out.
 Stacktrace:
 [debug] jarsigner 
 executable=[C:\Programme\Java\jdk1.5.0_06\jre\..\bin\jarsigner
 .exe]
 [INFO] 
 -
 ---
 [ERROR] BUILD ERROR
 [INFO] 
 -
 ---
 [INFO] Failure to run the plugin:
 [INFO] 
 -
 ---
 [DEBUG] Trace
 org.apache.maven.lifecycle.LifecycleExecutionException: Failure to run the 
 plugi
 n:
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
 ultLifecycleExecutor.java:556)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
 fecycle(DefaultLifecycleExecutor.java:472)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
 ltLifecycleExecutor.java:451)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
 dleFailures(DefaultLifecycleExecutor.java:303)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
 ts(DefaultLifecycleExecutor.java:270)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
 fecycleExecutor.java:139)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
 java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
 sorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at 
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.apache.maven.plugin.MojoExecutionException: Failure to run the 
 pl
 ugin:
 at org.codehaus.mojo.webstart.JnlpMojo.execute(JnlpMojo.java:479)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
 nManager.java:415)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
 ultLifecycleExecutor.java:531)
 ... 16 more
 Caused by: java.lang.NullPointerException
 at 
 org.apache.maven.plugin.jar.JarSignMojo.signJar(JarSignMojo.java:227)
 at 
 org.apache.maven.plugin.jar.JarSignMojo.execute(JarSignMojo.java:185)
 at org.codehaus.mojo.webstart.JnlpMojo.signJars(JnlpMojo.java:865)
 at org.codehaus.mojo.webstart.JnlpMojo.execute(JnlpMojo.java:441)
 ... 18 more

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

[jira] Commented: (MJAR-37) HttpJarSignClient - New goal httpsign which will sign jar files by submitting them to a signing service via HTTP Post

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MJAR-37?page=comments#action_68039 ] 

Jerome Lacoste commented on MJAR-37:


This issue is related to MOJO-393. It should be moved to webstart plugin. 
Please do so if you want (we need to create a webstart project in Jira first).

 HttpJarSignClient - New goal httpsign which will sign jar files by 
 submitting them to a signing service via HTTP Post
 ---

  Key: MJAR-37
  URL: http://jira.codehaus.org/browse/MJAR-37
  Project: Maven 2.x Jar Plugin
 Type: Improvement

 Reporter: David Boden
  Attachments: jar-plugin-newfiles.zip, jarplugin.diff


 The patch and new files attached to this issue are newer and make the 
 contributions in MJAR-35 obsolete.
 There is a test pom.xml that you can do a mvn install on to see the new 
 goal working.

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

[jira] Commented: (MJAR-35) Abstraction for JarSignMojo so that webstart plugin can allow the user to choose how their jars are signed

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MJAR-35?page=comments#action_68040 ] 

Jerome Lacoste commented on MJAR-35:


Please close that one. Issue was moved to Webstart mojo. 

 Abstraction for JarSignMojo so that webstart plugin can allow the user to 
 choose how their jars are signed
 --

  Key: MJAR-35
  URL: http://jira.codehaus.org/browse/MJAR-35
  Project: Maven 2.x Jar Plugin
 Type: New Feature

 Reporter: David Boden
  Attachments: JarSignerMojo.java, MJAR-35.diff, lehmanjarsigner-1.0-src.zip


 The webstart Maven 2 plugin signs jar files as part of its operation. At the 
 moment, it relies upon JarSignMojo to do this.
 While this is going to be correct 90% of the time, sometimes users (like 
 myself!) need to ask the webstart plugin to sign jars in a different way.
 Specifically, my company keeps its private key separate and provides an HTTP 
 Post interface to allow me to submit jars for signing. I've got a Mojo to do 
 this.
 What I need is for the webstart plugin to use an abstraction defined in an 
 interface called JarSignerMojo (attached to this issue) rather than 
 JarSignMojo. That way, I can plug my own Mojo in to be used instead of 
 JarSignMojo. Jerome Lacoste is doing the webstart plugin development and is 
 happy to accommodate this change if we can get the interface added to the jar 
 plugin project.
 The only change to the existing code is that JarSignMojo's class declaration 
 needs to be changed to:
 public class JarSignMojo extends AbstractMojo implements JarSignerMojo

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

[jira] Commented: (MJAR-4) Multiline description provides invalid header in the generated jar files

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MJAR-4?page=comments#action_68042 ] 

Jerome Lacoste commented on MJAR-4:
---

http://jira.codehaus.org/browse/MJAR-39#action_67458 seems to confirm my point. 
Should probably be closed...

  Multiline description provides invalid header in the generated jar files
 -

  Key: MJAR-4
  URL: http://jira.codehaus.org/browse/MJAR-4
  Project: Maven 2.x Jar Plugin
 Type: Bug

 Reporter: Gilles Scokart



 When a description text is written on more than 1 line, the produced Manifest 
 files are invalid.
 Indeed one of the header of this manifiest contains the description text as 
 is.  When the jar is loaded, we receive an error saying invalid headers.

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

[jira] Commented: (MRELEASE-111) Add a filtering configuration element

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MRELEASE-111?page=comments#action_67358 ] 

Jerome Lacoste commented on MRELEASE-111:
-

I like that. The user should perhaps need to specify a particular version of 
the snapshot artifact, -SNAPSHOT not being accepted. Comments?

 Add a filtering configuration element
 -

  Key: MRELEASE-111
  URL: http://jira.codehaus.org/browse/MRELEASE-111
  Project: Maven 2.x Release Plugin
 Type: New Feature

 Versions: 2.0-beta-4
 Reporter: Alexandre Poitras



 Sometimes you don't have a choice but to depends upon a snapshot artifact 
 (critical bug). Right now the release plugin doesn't allow it and I think 
 it's alright but a filtering configuration element would be a nice addition 
 to tell the release plugin when you are ok to go in production with a 
 snapshot dependency that you have throughoutly tested.

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

[jira] Commented: (MJAR-4) Multiline description provides invalid header in the generated jar files

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MJAR-4?page=comments#action_67365 ] 

Jerome Lacoste commented on MJAR-4:
---

But does maven 2.0.4 use the plexus library that contains the fix? I don't 
think so. On my machine mvn package uses 

[DEBUG] org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-3:runtime 
(selected for runtime)

while the fix (PLX-185) made it in alpha-6

http://svn.plexus.codehaus.org/browse/plexus/trunk/plexus-components/plexus-archiver/src/main/java/org/codehaus/plexus/archiver/jar/Manifest.java

Can you try forcing the dependency to this version of the plexus-archiver and 
repeat your tests?

  Multiline description provides invalid header in the generated jar files
 -

  Key: MJAR-4
  URL: http://jira.codehaus.org/browse/MJAR-4
  Project: Maven 2.x Jar Plugin
 Type: Bug

 Reporter: Gilles Scokart



 When a description text is written on more than 1 line, the produced Manifest 
 files are invalid.
 Indeed one of the header of this manifiest contains the description text as 
 is.  When the jar is loaded, we receive an error saying invalid headers.

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

[jira] Commented: (MJAR-39) Maven Sets Manifest Attribute Values to Multi-Line Strings

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MJAR-39?page=comments#action_67367 ] 

Jerome Lacoste commented on MJAR-39:


 Kenney is wrong. In other words, Mike's patch (for MJAR-38 and MJAR-39) 
 should still be applied.

I am not so sure. Aren't multiline attributes ('continuations') allowed in 
Manifest files? See http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html

Have you guys tried to force using the plexus-archiver 1.0-alpha-6? That's 
where the fix for PLX-185 went in.

 Maven Sets Manifest Attribute Values to Multi-Line Strings
 --

  Key: MJAR-39
  URL: http://jira.codehaus.org/browse/MJAR-39
  Project: Maven 2.x Jar Plugin
 Type: Bug

 Versions: 2.0
  Environment: Maven version: 2.0.4
 Microsoft Windows XP [Version 5.1.2600]
 Reporter: Steven Coco
  Attachments: Jar Specification-Title Tester.zip, MJAR-39.patch


  Maven will set a Manifest attribute's value to a multi-line string, 
 which results in an invalid Manifest.
  By default, on its own, Maven adds a Specification-Title attribute to 
 the Manifest, and sets its value to the POM's description element.  If this 
 is a multi-line value in the POM, Maven will insert it unchanged: and yield 
 an invalid Manifest.  Maven then can't even load the jar that it just created 
 itself!
  I have filed another bug relating to the fact that it should not insert 
 such an attribute by default: MJAR-38

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

[jira] Commented: (MNG-2293) maven-plugin-descriptor: Not possible to define a default implementation for a field defined by its interface

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2293?page=comments#action_67239 ] 

Jerome Lacoste commented on MNG-2293:
-

I removed link to MNG-2352 as Kenney found out it wasn't dependent on it. Don't 
get it as PLX-219 made it in alpha-10. So maybe PLX-219 wasn't a blocker 
neither?

 maven-plugin-descriptor: Not possible to define a default implementation for 
 a field defined by its interface
 -

  Key: MNG-2293
  URL: http://jira.codehaus.org/browse/MNG-2293
  Project: Maven 2
 Type: New Feature

   Components: Plugin Creation Tools
 Versions: 2.0.4
 Reporter: Jerome Lacoste
 Assignee: Kenney Westerhof
 Priority: Critical
  Fix For: 2.1
  Attachments: MNG-2293-plugins.diff, MNG-2293.diff, MNG-2293.diff, 
 dependency-mistery.log, it0106.tar.bz2, patch-MNG-2293-source2.tar.bz2, 
 patch-MNG-2293.diff


 MOJO-393 is about letting the user define an alternate configuration element, 
 thus changing the way the webstart plugin works.
 For that the idea was to make the mojo field an interface, provide a default 
 implementation in the plugin and let the user use plexus to instanciate a new 
 implemenation.
 so for most users we would have:
 configuration
   bla
   /bla
 /configuration
 and for some:
 configuration
   bla implementation=combla
   /bla
 /configuration
 Unfortunately, today I am forced to specify the implementation in both cases. 
 There's no way to inform the plugin to use the default implementation.
 The plugin.xml contains:
 parameter
   namebla/name
   type...BlaInterface/type !-- that will fail --
...
 /parameter
 I tried to use 
  /[EMAIL PROTECTED] implementation=...BlaImplementation*/
  BlaInterface bla;
 but that fails as well.
 Marking critical because it doesn't allow me add new features to the plugin 
 without breaking the config.xml.

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

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

[Jerome Lacoste (JIRA)]

Add timing information to integration tests
---

 Key: MNG-2356
 URL: http://jira.codehaus.org/browse/MNG-2356
 Project: Maven 2
Type: Improvement

  Components: integration tests  
Versions: 2.0.4
Reporter: Jerome Lacoste
Priority: Trivial
 Attachments: MNG-2356.diff

Also document why using your installed maven to recompile this plugin is a bad 
idea :)

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

[jira] Created: (MNG-2357) misc cleanup

[Jerome Lacoste (JIRA)]

misc cleanup


 Key: MNG-2357
 URL: http://jira.codehaus.org/browse/MNG-2357
 Project: Maven 2
Type: Improvement

Versions: 2.1
Reporter: Jerome Lacoste
Priority: Trivial
 Attachments: MNG-2357.diff

small things including
- a little bit of doc for integration tests
- document 2 undocumented integration tests
- svn:ignore



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

[jira] Updated: (MNG-2352) Upgrade to plexus-container-default-alpha-10

[Jerome Lacoste (JIRA)]

 [ http://jira.codehaus.org/browse/MNG-2352?page=all ]

Jerome Lacoste updated MNG-2352:


Attachment: MNG-2352.diff

 Upgrade to plexus-container-default-alpha-10
 

  Key: MNG-2352
  URL: http://jira.codehaus.org/browse/MNG-2352
  Project: Maven 2
 Type: Improvement

 Reporter: Jerome Lacoste
 Priority: Blocker
  Attachments: MNG-2352.diff


 This is required for MNG-2201 in particular.

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

[jira] Updated: (MNG-2293) maven-plugin-descriptor: Not possible to define a default implementation for a field defined by its interface

[Jerome Lacoste (JIRA)]

 [ http://jira.codehaus.org/browse/MNG-2293?page=all ]

Jerome Lacoste updated MNG-2293:


Attachment: MNG-2293.diff

 maven-plugin-descriptor: Not possible to define a default implementation for 
 a field defined by its interface
 -

  Key: MNG-2293
  URL: http://jira.codehaus.org/browse/MNG-2293
  Project: Maven 2
 Type: New Feature

   Components: Plugin Creation Tools
 Versions: 2.0.4
 Reporter: Jerome Lacoste
 Priority: Critical
  Attachments: MNG-2293-plugins.diff, MNG-2293.diff, MNG-2293.diff, 
 dependency-mistery.log, it0106.tar.bz2, patch-MNG-2293-source2.tar.bz2, 
 patch-MNG-2293.diff


 MOJO-393 is about letting the user define an alternate configuration element, 
 thus changing the way the webstart plugin works.
 For that the idea was to make the mojo field an interface, provide a default 
 implementation in the plugin and let the user use plexus to instanciate a new 
 implemenation.
 so for most users we would have:
 configuration
   bla
   /bla
 /configuration
 and for some:
 configuration
   bla implementation=combla
   /bla
 /configuration
 Unfortunately, today I am forced to specify the implementation in both cases. 
 There's no way to inform the plugin to use the default implementation.
 The plugin.xml contains:
 parameter
   namebla/name
   type...BlaInterface/type !-- that will fail --
...
 /parameter
 I tried to use 
  /[EMAIL PROTECTED] implementation=...BlaImplementation*/
  BlaInterface bla;
 but that fails as well.
 Marking critical because it doesn't allow me add new features to the plugin 
 without breaking the config.xml.

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

[jira] Commented: (MNG-2293) maven-plugin-descriptor: Not possible to define a default implementation for a field defined by its interface

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2293?page=comments#action_67057 ] 

Jerome Lacoste commented on MNG-2293:
-

I don't get why it doesn't depend on the other issue as PLX-219 went
into plexus alpha-10-SNAPSHOT. Could there be some local repository caching 
issue of
some sort?

 maven-plugin-descriptor: Not possible to define a default implementation for 
 a field defined by its interface
 -

  Key: MNG-2293
  URL: http://jira.codehaus.org/browse/MNG-2293
  Project: Maven 2
 Type: New Feature

   Components: Plugin Creation Tools
 Versions: 2.0.4
 Reporter: Jerome Lacoste
 Assignee: Kenney Westerhof
 Priority: Critical
  Fix For: 2.1
  Attachments: MNG-2293-plugins.diff, MNG-2293.diff, MNG-2293.diff, 
 dependency-mistery.log, it0106.tar.bz2, patch-MNG-2293-source2.tar.bz2, 
 patch-MNG-2293.diff


 MOJO-393 is about letting the user define an alternate configuration element, 
 thus changing the way the webstart plugin works.
 For that the idea was to make the mojo field an interface, provide a default 
 implementation in the plugin and let the user use plexus to instanciate a new 
 implemenation.
 so for most users we would have:
 configuration
   bla
   /bla
 /configuration
 and for some:
 configuration
   bla implementation=combla
   /bla
 /configuration
 Unfortunately, today I am forced to specify the implementation in both cases. 
 There's no way to inform the plugin to use the default implementation.
 The plugin.xml contains:
 parameter
   namebla/name
   type...BlaInterface/type !-- that will fail --
...
 /parameter
 I tried to use 
  /[EMAIL PROTECTED] implementation=...BlaImplementation*/
  BlaInterface bla;
 but that fails as well.
 Marking critical because it doesn't allow me add new features to the plugin 
 without breaking the config.xml.

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

[jira] Commented: (MNG-2293) maven-plugin-descriptor: Not possible to define a default implementation for a field defined by its interface

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2293?page=comments#action_66915 ] 

Jerome Lacoste commented on MNG-2293:
-

The issue related to plexus-containers-default was that M2_HOME/core ships 
alpha-9.
I am rebuilding with forcing this to be alpha-10. Hope that will solve it.

 maven-plugin-descriptor: Not possible to define a default implementation for 
 a field defined by its interface
 -

  Key: MNG-2293
  URL: http://jira.codehaus.org/browse/MNG-2293
  Project: Maven 2
 Type: New Feature

   Components: Plugin Creation Tools
 Versions: 2.0.4
 Reporter: Jerome Lacoste
 Priority: Critical
  Attachments: MNG-2293-plugins.diff, MNG-2293.diff, dependency-mistery.log, 
 it0106.tar.bz2, patch-MNG-2293-source2.tar.bz2, patch-MNG-2293.diff


 MOJO-393 is about letting the user define an alternate configuration element, 
 thus changing the way the webstart plugin works.
 For that the idea was to make the mojo field an interface, provide a default 
 implementation in the plugin and let the user use plexus to instanciate a new 
 implemenation.
 so for most users we would have:
 configuration
   bla
   /bla
 /configuration
 and for some:
 configuration
   bla implementation=combla
   /bla
 /configuration
 Unfortunately, today I am forced to specify the implementation in both cases. 
 There's no way to inform the plugin to use the default implementation.
 The plugin.xml contains:
 parameter
   namebla/name
   type...BlaInterface/type !-- that will fail --
...
 /parameter
 I tried to use 
  /[EMAIL PROTECTED] implementation=...BlaImplementation*/
  BlaInterface bla;
 but that fails as well.
 Marking critical because it doesn't allow me add new features to the plugin 
 without breaking the config.xml.

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

[jira] Created: (MNG-2352) Upgrade to plexus-container-default-alpha-10

[Jerome Lacoste (JIRA)]

Upgrade to plexus-container-default-alpha-10


 Key: MNG-2352
 URL: http://jira.codehaus.org/browse/MNG-2352
 Project: Maven 2
Type: Improvement

Reporter: Jerome Lacoste
Priority: Blocker


This is required for MNG-2201 in particular.

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

[jira] Commented: (MAVENUPLOAD-908) Intellij 5.1 redistribution jars

[Jerome Lacoste (JIRA)]

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-908?page=comments#action_66815 ] 

Jerome Lacoste commented on MAVENUPLOAD-908:


Out of curiosity, is there something blocking this issue? Should I ask 
jetbrains to 'bless' this issue?

 Intellij 5.1 redistribution jars
 

  Key: MAVENUPLOAD-908
  URL: http://jira.codehaus.org/browse/MAVENUPLOAD-908
  Project: maven-upload-requests
 Type: Task

 Reporter: Jerome Lacoste
  Attachments: annotations-5.1-bundle.jar, annotations-5.1-bundle.jar, 
 annotations-5.1-bundle.jar, forms_rt-5.1-bundle.jar, forms_rt-5.1-bundle.jar, 
 forms_rt-5.1-bundle.jar, javac2-5.1-bundle.jar, javac2-5.1-bundle.jar, 
 javac2-5.1-bundle.jar


 Intellij 5.0 jars are already distributed on ibiblio:
 http://www.ibiblio.org/maven2/com/intellij/
 These jars do not include the javac2 ant tasks which is required for the idea 
 ui designer plugin (mojo sandbox)
 Notes: I asked jetbrains and they don't have a public URL where to fetch the 
 jars from. So I took them from my local IDEA install.
 I've made the poms so that I could compile the distributed sources. So 
 compared to the poms for 5.0, they also contain the dependencies.
 [EMAIL PROTECTED] md5sum ~/local/lib/idea/idea/redist/*
 dcf471d13e032fdc7fb6872c12a01b06  
 /home/jerome/local/lib/idea/idea/redist/annotations.jar
 e457e70bc383322c0e297880e6be5ebc  
 /home/jerome/local/lib/idea/idea/redist/forms_rt.jar
 ab8f1d2c49347f65a6ca26c54cb9b83e  
 /home/jerome/local/lib/idea/idea/redist/javac2.jar
 [EMAIL PROTECTED] md5sum ~/local/lib/idea/idea/redist/src/*
 251d1939107e2ce2bb98055b40addd8d  
 /home/jerome/local/lib/idea/idea/redist/src/src_annotations.zip
 325987e7cd85c455095ff2b5568ca4f7  
 /home/jerome/local/lib/idea/idea/redist/src/src_forms_rt.zip
 08403362ff77b9e79af7178d7dd9cf01  
 /home/jerome/local/lib/idea/idea/redist/src/src_javac2.zip
 Note that javac2 and forms_rt are very similar in content. But that's how 
 Jetbrains distribute them.
 One can get IDEA from http://www.jetbrains.com/idea/download

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

[jira] Created: (MNG-2351) mvn -X doesn't enable debugging

[Jerome Lacoste (JIRA)]

mvn -X doesn't enable debugging
---

 Key: MNG-2351
 URL: http://jira.codehaus.org/browse/MNG-2351
 Project: Maven 2
Type: Bug

  Components: Embedding  
Versions: 2.1
Reporter: Jerome Lacoste


mvn -X doesn't enable debugging

If I add the following code to DefaultMaven.execute(...)

public void execute( MavenExecutionRequest request )
throws MavenExecutionException

[...]

loggerManager.setThreshold( request.getLoggingLevel() );
// ADDED
loggerManager.getLoggerForComponent( Maven.ROLE ).info( XXX logging 
level  + request.getLoggingLevel());
loggerManager.getLoggerForComponent( Maven.ROLE ).debug( XXX logging 
level  + request.getLoggingLevel());
System.err.println(XXX logging level  + request.getLoggingLevel());
System.err.println(XXX show errors  + request.isShowErrors());
System.err.println(XXX logger threshold  + 
loggerManager.getLoggerForComponent( Maven.ROLE ).getThreshold());
// end of ADDED

I get:

[INFO] XXX logging level 0
XXX logging level 0
XXX show errors true
XXX logger threshold 1

Looks like something is wrong with regard to thresholds in the Maven.ROLE 
component.

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

[jira] Commented: (MNG-2351) mvn -X doesn't enable debugging

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2351?page=comments#action_66849 ] 

Jerome Lacoste commented on MNG-2351:
-

Given that LoggerManager API says that 

/**
 * Sets the threshold for all new loggers. It will NOT affect the existing 
loggers.
 * This is usually only set once while the logger manager is configured.
 * @param threshold The new threshold.
 */
void setThreshold( int threshold );

I thought that the Maven.ROLE logger must have already existed. I tried to 
force its theshold to DEBUG using LoggerManager.setThreshold(Maven.ROLE, 0) but 
that didn't work.

 mvn -X doesn't enable debugging
 ---

  Key: MNG-2351
  URL: http://jira.codehaus.org/browse/MNG-2351
  Project: Maven 2
 Type: Bug

   Components: Embedding
 Versions: 2.1
 Reporter: Jerome Lacoste



 mvn -X doesn't enable debugging
 If I add the following code to DefaultMaven.execute(...)
 public void execute( MavenExecutionRequest request )
 throws MavenExecutionException
 [...]
 
 loggerManager.setThreshold( request.getLoggingLevel() );
 // ADDED
 loggerManager.getLoggerForComponent( Maven.ROLE ).info( XXX logging 
 level  + request.getLoggingLevel());
 loggerManager.getLoggerForComponent( Maven.ROLE ).debug( XXX logging 
 level  + request.getLoggingLevel());
 System.err.println(XXX logging level  + request.getLoggingLevel());
 System.err.println(XXX show errors  + request.isShowErrors());
 System.err.println(XXX logger threshold  + 
 loggerManager.getLoggerForComponent( Maven.ROLE ).getThreshold());
 // end of ADDED
 I get:
 [INFO] XXX logging level 0
 XXX logging level 0
 XXX show errors true
 XXX logger threshold 1
 Looks like something is wrong with regard to thresholds in the Maven.ROLE 
 component.

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

[jira] Commented: (MNG-2351) mvn -X doesn't enable debugging

[Jerome Lacoste (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2351?page=comments#action_66852 ] 

Jerome Lacoste commented on MNG-2351:
-

* I also tried using setThreshold(Maven.ROLE, default, 0) instead, but that 
doesn't work better. The first version (without default) manages to get my 
test line

   loggerManager.getLoggerForComponent( Maven.ROLE ).debug( XXX logging level 
 + request.getLoggingLevel());

printed, but nothing else. I guess another logger is used...



* I also wondered why the DefaultMaven class referes to the Mojo.ROLE,

Logger logger = loggerManager.getLoggerForComponent( Mojo.ROLE );

But trying to change that didn't affect anything.



* the only way I was able to achieve some kinds of results was by changing the 
MavenCli class:

mavenEmbedder.setClassWorld( classWorld );
   // added
mavenEmbedder.setLogger( new MavenEmbedderConsoleLogger() );
// end of added

mavenEmbedder.start();

there by specifying the threshold of the MavenEmbedderConsoleLogger, I manage 
to get DEBUG messages, but they are prefixed by:


[ maven embedder INFO] 

[ maven embedder INFO] Total time: 3 seconds
[ maven embedder INFO] Finished at: Wed Jun 07 22:10:10 CEST 2006
[ maven embedder INFO] Final Memory: 2M/5M
[ maven embedder INFO] 


:(



* I suspect that the logger threshold must be set before starting the plexus 
embedder, but I don't see any way of programatically achieving this result.

Note: in MavenEmbedder.start(), the following debug prints out *null* for the 
logger field:

embedder = new Embedder();
System.err.println(XXX logger  + logger);

if ( logger != null )
{
embedder.setLoggerManager( new MavenEmbedderLoggerManager( new 
PlexusLoggerAdapter( logger ) ) );
}

Not sure if that helps...



* relevant IRC exchange

(22:09:01) lacoste1: jdcasey: if I do setThreshold(Maven.ROLE, DEBUG) then I 
see that the logger works with debug() later on, but as no other DEBUG message 
is printed, I guess that a different logger is used from within the 
application. I think that the logger threshold has to be initialized before the 
embedder is started, and that means changing the MavenCli. Will try that...
(22:09:21) jdcasey: yup, I think you're right
(22:09:36) jdcasey: actually, before the Plexus embedder is started...
(22:09:50) jdcasey: if the MavenEmbedder exists outside of the plexus embedder, 
it should be in the maven embedder
(22:09:53) jdcasey: not the CLI
(22:09:59) jdcasey: that way, it's reusable for embedded apps

 mvn -X doesn't enable debugging
 ---

  Key: MNG-2351
  URL: http://jira.codehaus.org/browse/MNG-2351
  Project: Maven 2
 Type: Bug

   Components: Embedding
 Versions: 2.1
 Reporter: Jerome Lacoste



 mvn -X doesn't enable debugging
 If I add the following code to DefaultMaven.execute(...)
 public void execute( MavenExecutionRequest request )
 throws MavenExecutionException
 [...]
 
 loggerManager.setThreshold( request.getLoggingLevel() );
 // ADDED
 loggerManager.getLoggerForComponent( Maven.ROLE ).info( XXX logging 
 level  + request.getLoggingLevel());
 loggerManager.getLoggerForComponent( Maven.ROLE ).debug( XXX logging 
 level  + request.getLoggingLevel());
 System.err.println(XXX logging level  + request.getLoggingLevel());
 System.err.println(XXX show errors  + request.isShowErrors());
 System.err.println(XXX logger threshold  + 
 loggerManager.getLoggerForComponent( Maven.ROLE ).getThreshold());
 // end of ADDED
 I get:
 [INFO] XXX logging level 0
 XXX logging level 0
 XXX show errors true
 XXX logger threshold 1
 Looks like something is wrong with regard to thresholds in the Maven.ROLE 
 component.

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

[jira] Updated: (MNG-2293) maven-plugin-descriptor: Not possible to define a default implementation for a field defined by its interface

[Jerome Lacoste (JIRA)]

 [ http://jira.codehaus.org/browse/MNG-2293?page=all ]

Jerome Lacoste updated MNG-2293:


Attachment: MNG-2293-plugins.diff
dependency-mistery.log
MNG-2293.diff

 maven-plugin-descriptor: Not possible to define a default implementation for 
 a field defined by its interface
 -

  Key: MNG-2293
  URL: http://jira.codehaus.org/browse/MNG-2293
  Project: Maven 2
 Type: New Feature

   Components: Plugin Creation Tools
 Versions: 2.0.4
 Reporter: Jerome Lacoste
 Priority: Critical
  Attachments: MNG-2293-plugins.diff, MNG-2293.diff, dependency-mistery.log, 
 it0106.tar.bz2, patch-MNG-2293-source2.tar.bz2, patch-MNG-2293.diff


 MOJO-393 is about letting the user define an alternate configuration element, 
 thus changing the way the webstart plugin works.
 For that the idea was to make the mojo field an interface, provide a default 
 implementation in the plugin and let the user use plexus to instanciate a new 
 implemenation.
 so for most users we would have:
 configuration
   bla
   /bla
 /configuration
 and for some:
 configuration
   bla implementation=combla
   /bla
 /configuration
 Unfortunately, today I am forced to specify the implementation in both cases. 
 There's no way to inform the plugin to use the default implementation.
 The plugin.xml contains:
 parameter
   namebla/name
   type...BlaInterface/type !-- that will fail --
...
 /parameter
 I tried to use 
  /[EMAIL PROTECTED] implementation=...BlaImplementation*/
  BlaInterface bla;
 but that fails as well.
 Marking critical because it doesn't allow me add new features to the plugin 
 without breaking the config.xml.

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

[jira] Updated: (MAVENUPLOAD-908) Intellij 5.1 redistribution jars

[Jerome Lacoste (JIRA)]

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-908?page=all ]

Jerome Lacoste updated MAVENUPLOAD-908:
---

Attachment: javac2-5.1-bundle.jar
forms_rt-5.1-bundle.jar
annotations-5.1-bundle.jar

 Intellij 5.1 redistribution jars
 

  Key: MAVENUPLOAD-908
  URL: http://jira.codehaus.org/browse/MAVENUPLOAD-908
  Project: maven-upload-requests
 Type: Task

 Reporter: Jerome Lacoste
  Attachments: annotations-5.1-bundle.jar, annotations-5.1-bundle.jar, 
 forms_rt-5.1-bundle.jar, forms_rt-5.1-bundle.jar, javac2-5.1-bundle.jar, 
 javac2-5.1-bundle.jar


 Intellij 5.0 jars are already distributed on ibiblio:
 http://www.ibiblio.org/maven2/com/intellij/
 These jars do not include the javac2 ant tasks which is required for the idea 
 ui designer plugin (mojo sandbox)
 Notes: I asked jetbrains and they don't have a public URL where to fetch the 
 jars from. So I took them from my local IDEA install.
 I've made the poms so that I could compile the distributed sources. So 
 compared to the poms for 5.0, they also contain the dependencies.
 [EMAIL PROTECTED] md5sum ~/local/lib/idea/idea/redist/*
 dcf471d13e032fdc7fb6872c12a01b06  
 /home/jerome/local/lib/idea/idea/redist/annotations.jar
 e457e70bc383322c0e297880e6be5ebc  
 /home/jerome/local/lib/idea/idea/redist/forms_rt.jar
 ab8f1d2c49347f65a6ca26c54cb9b83e  
 /home/jerome/local/lib/idea/idea/redist/javac2.jar
 [EMAIL PROTECTED] md5sum ~/local/lib/idea/idea/redist/src/*
 251d1939107e2ce2bb98055b40addd8d  
 /home/jerome/local/lib/idea/idea/redist/src/src_annotations.zip
 325987e7cd85c455095ff2b5568ca4f7  
 /home/jerome/local/lib/idea/idea/redist/src/src_forms_rt.zip
 08403362ff77b9e79af7178d7dd9cf01  
 /home/jerome/local/lib/idea/idea/redist/src/src_javac2.zip
 Note that javac2 and forms_rt are very similar in content. But that's how 
 Jetbrains distribute them.
 One can get IDEA from http://www.jetbrains.com/idea/download

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

[jira] Updated: (MAVENUPLOAD-908) Intellij 5.1 redistribution jars

[Jerome Lacoste (JIRA)]

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-908?page=all ]

Jerome Lacoste updated MAVENUPLOAD-908:
---

Attachment: javac2-5.1-bundle.jar
forms_rt-5.1-bundle.jar
annotations-5.1-bundle.jar

 Intellij 5.1 redistribution jars
 

  Key: MAVENUPLOAD-908
  URL: http://jira.codehaus.org/browse/MAVENUPLOAD-908
  Project: maven-upload-requests
 Type: Task

 Reporter: Jerome Lacoste
  Attachments: annotations-5.1-bundle.jar, annotations-5.1-bundle.jar, 
 annotations-5.1-bundle.jar, forms_rt-5.1-bundle.jar, forms_rt-5.1-bundle.jar, 
 forms_rt-5.1-bundle.jar, javac2-5.1-bundle.jar, javac2-5.1-bundle.jar, 
 javac2-5.1-bundle.jar


 Intellij 5.0 jars are already distributed on ibiblio:
 http://www.ibiblio.org/maven2/com/intellij/
 These jars do not include the javac2 ant tasks which is required for the idea 
 ui designer plugin (mojo sandbox)
 Notes: I asked jetbrains and they don't have a public URL where to fetch the 
 jars from. So I took them from my local IDEA install.
 I've made the poms so that I could compile the distributed sources. So 
 compared to the poms for 5.0, they also contain the dependencies.
 [EMAIL PROTECTED] md5sum ~/local/lib/idea/idea/redist/*
 dcf471d13e032fdc7fb6872c12a01b06  
 /home/jerome/local/lib/idea/idea/redist/annotations.jar
 e457e70bc383322c0e297880e6be5ebc  
 /home/jerome/local/lib/idea/idea/redist/forms_rt.jar
 ab8f1d2c49347f65a6ca26c54cb9b83e  
 /home/jerome/local/lib/idea/idea/redist/javac2.jar
 [EMAIL PROTECTED] md5sum ~/local/lib/idea/idea/redist/src/*
 251d1939107e2ce2bb98055b40addd8d  
 /home/jerome/local/lib/idea/idea/redist/src/src_annotations.zip
 325987e7cd85c455095ff2b5568ca4f7  
 /home/jerome/local/lib/idea/idea/redist/src/src_forms_rt.zip
 08403362ff77b9e79af7178d7dd9cf01  
 /home/jerome/local/lib/idea/idea/redist/src/src_javac2.zip
 Note that javac2 and forms_rt are very similar in content. But that's how 
 Jetbrains distribute them.
 One can get IDEA from http://www.jetbrains.com/idea/download

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