date:20071213

On Thursday 13 December 2007, Brett Porter wrote:
> Sounds familiar now... should we continue to consider this a failure
> then until it is added?

I would say yes.  You could disable it for the time being since we know 
it doesn't build with 1.4.

Dan


>
> On 14/12/2007, at 2:00 PM, Daniel Kulp wrote:
> > On Thursday 13 December 2007, Brett Porter wrote:
> >> is PMD JDK 5 only now?
> >
> > Yes.  But they are working on getting a retrotranslated version
> > submitted
> > to central the the plugin can use.
> >
> > Dan
> >
> >> - Brett
> >>
> >> On 14/12/2007, at 1:35 PM, [EMAIL PROTECTED] wrote:
> >>> Online report :
> >>> http://maven.zones.apache.org/continuum/buildResult.action?buildId
> >>>=3 8882&projectId=27
> >>>
> >>> Build statistics:
> >>> State: Failed
> >>> Previous State: Failed
> >>> Started at: Fri 14 Dec 2007 02:35:26 +
> >>> Finished at: Fri 14 Dec 2007 02:35:35 +
> >>> Total time: 8s
> >>> Build Trigger: Schedule
> >>> Build Number: 100
> >>> Exit code: 1
> >>> Building machine hostname: maven.zones.apache.org
> >>> Operating system : SunOS(unknown)
> >>> Java Home version :  java version "1.4.2_09"
> >>>Java(TM) 2 Runtime Environment, Standard Edition (build
> >>> 1.4.2_09-b05)
> >>>Java HotSpot(TM) Client VM (build 1.4.2_09-b05, mixed mode)
> >>>   Builder version :
> >>>Maven version: 2.0.7
> >>>Java version: 1.4.2_09
> >>>OS name: "sunos" version: "5.10" arch: "x86"
> >>>
> >>> **
> >>>**  SCM Changes:
> >>> **
> >>>**  No files changed
> >>>
> >>> **
> >>>**  Dependencies Changes:
> >>> **
> >>>**  No dependencies changed
> >>>
> >>>
> >>> **
> >>>**  Build Defintion:
> >>> **
> >>>**  POM filename: pom.xml
> >>> Goals: clean install   Arguments: --batch-mode --non-recursive -P
> >>> integration-tests
> >>> Build Fresh: true
> >>> Always Build: true
> >>> Default Build Definition: false
> >>> Schedule: Integration Test Run
> >>> Profile Name: JDK 1.4.2
> >>> Description:
> >>>
> >>> **
> >>>**  Test Summary:
> >>> **
> >>>**  Tests: 0
> >>> Failures: 0
> >>> Total time: 0
> >>>
> >>> **
> >>>**  Output:
> >>> **
> >>>**  [INFO] Scanning for projects...
> >>> [INFO]
> >>> --
> >>>--  [INFO] Building Maven PMD Plugin
> >>> [INFO]task-segment: [clean, install]
> >>> [INFO]
> >>> --
> >>>--  [INFO] [clean:clean]
> >>> [INFO] [plugin:descriptor]
> >>> [INFO] Using 2 extractors.
> >>> [INFO] Applying extractor for language: java
> >>> [INFO] Extractor for language: java found 4 mojo descriptors.
> >>> [INFO] Applying extractor for language: bsh
> >>> [INFO] Extractor for language: bsh found 0 mojo descriptors.
> >>> [INFO] [resources:resources]
> >>> [INFO] Using default encoding to copy filtered resources.
> >>> [INFO] Copying 4 resources
> >>> [INFO] [compiler:compile]
> >>> [INFO] Compiling 9 source files to
> >>> /export/home/build/data/continuum/ checkouts/27/target/classes
> >>> [INFO]
> >>> --
> >>>--  [ERROR] BUILD FAILURE
> >>> [INFO]
> >>> --
> >>>--  [INFO] Compilation failure
> >>> /export/home/build/data/continuum/checkouts/27/src/main/java/org/
> >>> apache/maven/plugin/pmd/CpdReportGenerator.java:[27,-1] cannot
> >>> access net.sourceforge.pmd.PMD
> >>> bad class file: /export/home/build/.m2/repository/pmd/pmd/4.1/
> >>> pmd-4.1.jar(net/sourceforge/pmd/PMD.class)
> >>> class file has wrong version 49.0, should be 48.0
> >>>
> >>>
> >>>
> >>> /export/home/build/data/continuum/checkouts/27/src/main/java/org/
> >>> apache/maven/plugin/pmd/CpdReportGenerator.java:[27,-1] cannot
> >>> access net.sourceforge.pmd.PMD
> >>> bad class file: /export/home/build/.m2/repository/pmd/pmd/4.1/
> >>> pmd-4.1.jar(net/sourceforge/pmd/PMD.class)
> >>> class file has wrong version 49.0, should be 48.0
> >>>
> >>>
> >>> [INFO]
> >>> --
> >>>--  [INFO] For more information, run Maven with the -e switch
> >>> [INFO]
> >>> --

Re: [continuum] BUILD FAILURE: Maven PMD Plugin

2007-12-13 Thread Brett Porter

Sounds familiar now... should we continue to consider this a failure  
then until it is added?


On 14/12/2007, at 2:00 PM, Daniel Kulp wrote:


On Thursday 13 December 2007, Brett Porter wrote:

is PMD JDK 5 only now?


Yes.  But they are working on getting a retrotranslated version  
submitted

to central the the plugin can use.

Dan




- Brett

On 14/12/2007, at 1:35 PM, [EMAIL PROTECTED] wrote:

Online report :
http://maven.zones.apache.org/continuum/buildResult.action?buildId=3
8882&projectId=27

Build statistics:
State: Failed
Previous State: Failed
Started at: Fri 14 Dec 2007 02:35:26 +
Finished at: Fri 14 Dec 2007 02:35:35 +
Total time: 8s
Build Trigger: Schedule
Build Number: 100
Exit code: 1
Building machine hostname: maven.zones.apache.org
Operating system : SunOS(unknown)
Java Home version :  java version "1.4.2_09"
   Java(TM) 2 Runtime Environment, Standard Edition (build
1.4.2_09-b05)
   Java HotSpot(TM) Client VM (build 1.4.2_09-b05, mixed mode)
  Builder version :
   Maven version: 2.0.7
   Java version: 1.4.2_09
   OS name: "sunos" version: "5.10" arch: "x86"


 SCM Changes:

 No files changed


 Dependencies Changes:

 No dependencies changed



 Build Defintion:

 POM filename: pom.xml
Goals: clean install   Arguments: --batch-mode --non-recursive -P
integration-tests
Build Fresh: true
Always Build: true
Default Build Definition: false
Schedule: Integration Test Run
Profile Name: JDK 1.4.2
Description:


 Test Summary:

 Tests: 0
Failures: 0
Total time: 0


 Output:

 [INFO] Scanning for projects...
[INFO]

 [INFO] Building Maven PMD Plugin
[INFO]task-segment: [clean, install]
[INFO]

 [INFO] [clean:clean]
[INFO] [plugin:descriptor]
[INFO] Using 2 extractors.
[INFO] Applying extractor for language: java
[INFO] Extractor for language: java found 4 mojo descriptors.
[INFO] Applying extractor for language: bsh
[INFO] Extractor for language: bsh found 0 mojo descriptors.
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] Copying 4 resources
[INFO] [compiler:compile]
[INFO] Compiling 9 source files to
/export/home/build/data/continuum/ checkouts/27/target/classes
[INFO]

 [ERROR] BUILD FAILURE
[INFO]

 [INFO] Compilation failure
/export/home/build/data/continuum/checkouts/27/src/main/java/org/
apache/maven/plugin/pmd/CpdReportGenerator.java:[27,-1] cannot
access net.sourceforge.pmd.PMD
bad class file: /export/home/build/.m2/repository/pmd/pmd/4.1/
pmd-4.1.jar(net/sourceforge/pmd/PMD.class)
class file has wrong version 49.0, should be 48.0



/export/home/build/data/continuum/checkouts/27/src/main/java/org/
apache/maven/plugin/pmd/CpdReportGenerator.java:[27,-1] cannot
access net.sourceforge.pmd.PMD
bad class file: /export/home/build/.m2/repository/pmd/pmd/4.1/
pmd-4.1.jar(net/sourceforge/pmd/PMD.class)
class file has wrong version 49.0, should be 48.0


[INFO]

 [INFO] For more information, run Maven with the -e switch
[INFO]

 [INFO] Total time: 6 seconds
[INFO] Finished at: Fri Dec 14 02:35:34 GMT+00:00 2007
[INFO] Final Memory: 12M/22M
[INFO]







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [continuum] BUILD FAILURE: Maven PMD Plugin

On Thursday 13 December 2007, Brett Porter wrote:
> is PMD JDK 5 only now?

Yes.  But they are working on getting a retrotranslated version submitted 
to central the the plugin can use. 

Dan



> - Brett
>
> On 14/12/2007, at 1:35 PM, [EMAIL PROTECTED] wrote:
> > Online report :
> > http://maven.zones.apache.org/continuum/buildResult.action?buildId=3
> >8882&projectId=27
> >
> > Build statistics:
> > State: Failed
> > Previous State: Failed
> > Started at: Fri 14 Dec 2007 02:35:26 +
> > Finished at: Fri 14 Dec 2007 02:35:35 +
> > Total time: 8s
> > Build Trigger: Schedule
> > Build Number: 100
> > Exit code: 1
> > Building machine hostname: maven.zones.apache.org
> > Operating system : SunOS(unknown)
> > Java Home version :  java version "1.4.2_09"
> > Java(TM) 2 Runtime Environment, Standard Edition (build
> > 1.4.2_09-b05)
> > Java HotSpot(TM) Client VM (build 1.4.2_09-b05, mixed mode)
> >Builder version :
> > Maven version: 2.0.7
> > Java version: 1.4.2_09
> > OS name: "sunos" version: "5.10" arch: "x86"
> >
> > 
> > SCM Changes:
> > 
> > No files changed
> >
> > 
> > Dependencies Changes:
> > 
> > No dependencies changed
> >
> >
> > 
> > Build Defintion:
> > 
> > POM filename: pom.xml
> > Goals: clean install   Arguments: --batch-mode --non-recursive -P
> > integration-tests
> > Build Fresh: true
> > Always Build: true
> > Default Build Definition: false
> > Schedule: Integration Test Run
> > Profile Name: JDK 1.4.2
> > Description:
> >
> > 
> > Test Summary:
> > 
> > Tests: 0
> > Failures: 0
> > Total time: 0
> >
> > 
> > Output:
> > 
> > [INFO] Scanning for projects...
> > [INFO]
> > 
> > [INFO] Building Maven PMD Plugin
> > [INFO]task-segment: [clean, install]
> > [INFO]
> > 
> > [INFO] [clean:clean]
> > [INFO] [plugin:descriptor]
> > [INFO] Using 2 extractors.
> > [INFO] Applying extractor for language: java
> > [INFO] Extractor for language: java found 4 mojo descriptors.
> > [INFO] Applying extractor for language: bsh
> > [INFO] Extractor for language: bsh found 0 mojo descriptors.
> > [INFO] [resources:resources]
> > [INFO] Using default encoding to copy filtered resources.
> > [INFO] Copying 4 resources
> > [INFO] [compiler:compile]
> > [INFO] Compiling 9 source files to
> > /export/home/build/data/continuum/ checkouts/27/target/classes
> > [INFO]
> > 
> > [ERROR] BUILD FAILURE
> > [INFO]
> > 
> > [INFO] Compilation failure
> > /export/home/build/data/continuum/checkouts/27/src/main/java/org/
> > apache/maven/plugin/pmd/CpdReportGenerator.java:[27,-1] cannot
> > access net.sourceforge.pmd.PMD
> > bad class file: /export/home/build/.m2/repository/pmd/pmd/4.1/
> > pmd-4.1.jar(net/sourceforge/pmd/PMD.class)
> > class file has wrong version 49.0, should be 48.0
> >
> >
> >
> > /export/home/build/data/continuum/checkouts/27/src/main/java/org/
> > apache/maven/plugin/pmd/CpdReportGenerator.java:[27,-1] cannot
> > access net.sourceforge.pmd.PMD
> > bad class file: /export/home/build/.m2/repository/pmd/pmd/4.1/
> > pmd-4.1.jar(net/sourceforge/pmd/PMD.class)
> > class file has wrong version 49.0, should be 48.0
> >
> >
> > [INFO]
> > 
> > [INFO] For more information, run Maven with the -e switch
> > [INFO]
> > 
> > [INFO] Total time: 6 seconds
> > [INFO] Finished at: Fri Dec 14 02:35:34 GMT+00:00 2007
> > [INFO] Final Memory: 12M/22M
> > [INFO]
> > 
> >
> >
> > 
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194

Re: [continuum] BUILD FAILURE: Maven PMD Plugin

2007-12-13 Thread Brett Porter


is PMD JDK 5 only now?

- Brett

On 14/12/2007, at 1:35 PM, [EMAIL PROTECTED] wrote:


Online report : 
http://maven.zones.apache.org/continuum/buildResult.action?buildId=38882&projectId=27

Build statistics:
State: Failed
Previous State: Failed
Started at: Fri 14 Dec 2007 02:35:26 +
Finished at: Fri 14 Dec 2007 02:35:35 +
Total time: 8s
Build Trigger: Schedule
Build Number: 100
Exit code: 1
Building machine hostname: maven.zones.apache.org
Operating system : SunOS(unknown)
Java Home version :  java version "1.4.2_09"
Java(TM) 2 Runtime Environment, Standard Edition (build  
1.4.2_09-b05)

Java HotSpot(TM) Client VM (build 1.4.2_09-b05, mixed mode)
   Builder version :
Maven version: 2.0.7
Java version: 1.4.2_09
OS name: "sunos" version: "5.10" arch: "x86"
   


SCM Changes:

No files changed


Dependencies Changes:

No dependencies changed



Build Defintion:

POM filename: pom.xml
Goals: clean install   Arguments: --batch-mode --non-recursive -P  
integration-tests

Build Fresh: true
Always Build: true
Default Build Definition: false
Schedule: Integration Test Run
Profile Name: JDK 1.4.2
Description:


Test Summary:

Tests: 0
Failures: 0
Total time: 0


Output:

[INFO] Scanning for projects...
[INFO]  


[INFO] Building Maven PMD Plugin
[INFO]task-segment: [clean, install]
[INFO]  


[INFO] [clean:clean]
[INFO] [plugin:descriptor]
[INFO] Using 2 extractors.
[INFO] Applying extractor for language: java
[INFO] Extractor for language: java found 4 mojo descriptors.
[INFO] Applying extractor for language: bsh
[INFO] Extractor for language: bsh found 0 mojo descriptors.
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] Copying 4 resources
[INFO] [compiler:compile]
[INFO] Compiling 9 source files to /export/home/build/data/continuum/ 
checkouts/27/target/classes
[INFO]  


[ERROR] BUILD FAILURE
[INFO]  


[INFO] Compilation failure
/export/home/build/data/continuum/checkouts/27/src/main/java/org/ 
apache/maven/plugin/pmd/CpdReportGenerator.java:[27,-1] cannot  
access net.sourceforge.pmd.PMD
bad class file: /export/home/build/.m2/repository/pmd/pmd/4.1/ 
pmd-4.1.jar(net/sourceforge/pmd/PMD.class)

class file has wrong version 49.0, should be 48.0



/export/home/build/data/continuum/checkouts/27/src/main/java/org/ 
apache/maven/plugin/pmd/CpdReportGenerator.java:[27,-1] cannot  
access net.sourceforge.pmd.PMD
bad class file: /export/home/build/.m2/repository/pmd/pmd/4.1/ 
pmd-4.1.jar(net/sourceforge/pmd/PMD.class)

class file has wrong version 49.0, should be 48.0


[INFO]  


[INFO] For more information, run Maven with the -e switch
[INFO]  


[INFO] Total time: 6 seconds
[INFO] Finished at: Fri Dec 14 02:35:34 GMT+00:00 2007
[INFO] Final Memory: 12M/22M
[INFO]  









-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [continuum] BUILD FAILURE: Maven Shared File Management API

2007-12-13 Thread Brett Porter


Anyone know what caused this error? I see it on my macbook as well.

- Brett

On 14/12/2007, at 10:55 AM, [EMAIL PROTECTED] wrote:


Online report : 
http://maven.zones.apache.org/continuum/buildResult.action?buildId=38854&projectId=55

Build statistics:
State: Failed
Previous State: Failed
Started at: Thu 13 Dec 2007 23:55:37 +
Finished at: Thu 13 Dec 2007 23:55:49 +
Total time: 12s
Build Trigger: Forced
Build Number: 19
Exit code: 1
Building machine hostname: maven.zones.apache.org
Operating system : SunOS(unknown)
Java Home version :  java version "1.4.2_09"
Java(TM) 2 Runtime Environment, Standard Edition (build  
1.4.2_09-b05)

Java HotSpot(TM) Client VM (build 1.4.2_09-b05, mixed mode)
   Builder version :
Maven version: 2.0.7
Java version: 1.4.2_09
OS name: "sunos" version: "5.10" arch: "x86"
   


SCM Changes:

No files changed


Dependencies Changes:

No dependencies changed



Build Defintion:

POM filename: pom.xml
Goals: clean install   Arguments: --batch-mode --non-recursive
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: DEFAULT_SCHEDULE
Profile Name: JDK 1.4.2
Description:


Test Summary:

Tests: 4
Failures: 1
Total time: 165


Output:

[INFO] Scanning for projects...
[INFO]  


[INFO] Building Maven Shared File Management API
[INFO]task-segment: [clean, install]
[INFO]  


[INFO] [clean:clean]
[INFO] Deleting directory /export/home/build/data/continuum/ 
checkouts/55/target

[INFO] [modello:xpp3-reader {execution: fileset}]
[INFO] outputDirectory: /export/home/build/data/continuum/checkouts/ 
55/target/generated-sources/modello

[INFO] Generating current version: 1.1.0
[INFO] [modello:xpp3-writer {execution: fileset}]
[INFO] outputDirectory: /export/home/build/data/continuum/checkouts/ 
55/target/generated-sources/modello

[INFO] Generating current version: 1.1.0
[INFO] [modello:java {execution: fileset}]
[INFO] outputDirectory: /export/home/build/data/continuum/checkouts/ 
55/target/generated-sources/modello

[INFO] Generating current version: 1.1.0
[INFO] [modello:xsd {execution: fileset}]
[INFO] outputDirectory: /export/home/build/data/continuum/checkouts/ 
55/target/generated-site/xsd

[INFO] Generating current version: 1.1.0
[INFO] Setting property: classpath.resource.loader.class =>  
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.

[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] Copying 2 resources
[INFO] [compiler:compile]
[INFO] Compiling 15 source files to /export/home/build/data/ 
continuum/checkouts/55/target/classes

[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] Copying 9 resources
[INFO] Copying 2 resources
[INFO] [compiler:testCompile]
[INFO] Compiling 1 source file to /export/home/build/data/continuum/ 
checkouts/55/target/test-classes

[INFO] [surefire:test]
[INFO] Surefire report directory: /export/home/build/data/continuum/ 
checkouts/55/target/surefire-reports


---
T E S T S
---
Running org.apache.maven.shared.model.fileset.util.FileSetUtilsTest
Setting up directory for test: testGetIncludedFiles
Setting up directory for test: testIncludesDontFollowSymlinks
Setting up directory for test: testDeleteDontFollowSymlinks
Setting up directory for test: testDelete
Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:  
0.181 sec <<< FAILURE!


Results :

Tests in error:   
testDeleteDontFollowSymlinks 
(org.apache.maven.shared.model.fileset.util.FileSetUtilsTest)


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

[INFO]  


[ERROR

Re: [VOTE] Release Maven Surefire 2.3.1

2007-12-13 Thread Michael McCallum

On Thu, 13 Dec 2007 05:59:18 Benjamin Bentmann wrote:
> Mauro Talevi wrote:
> > firstly, nothing prevents us from releasing a 2.3.2 right after a 2.3.1.
>
> If an ordinary user may disturb:
> I really appreciate Mauro's attitude. For my taste, there could be more
> maintenance releases. Please consider that not all Maven users can/want to
> build plugins from source just to get a snapshot with a long awaited
> bugfix. Furthermore, a shorter release cycle will produce more release
> artifacts, giving users more possibilities to hack their POM if they find
> the latest release not usuable.
>
>
> Benjamin Bentmann

i second that

-- 
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Maven Ant Tasks 2.0.8 (take 2)

2007-12-13 Thread Hervé BOUTEMY

I still miss 2 PMC votes: anybody interested in MANTTASKS?
This time, I promise I won't cancel the vote :)

Hervé

Le lundi 10 décembre 2007, Hervé BOUTEMY a écrit :
> Hi,
>
> Following Maven release, I'd like to release (again) Maven Ant Tasks 2.0.8.
> Problem with dependencies order has been fixed.
>
> We solved 16 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11533&styleName=
>Html&version=13618
>
> The tasks can be downloaded from:
> http://people.apache.org/~hboutemy/staging-repo/org/apache/maven/maven-ant-
>tasks/2.0.8/maven-ant-tasks-2.0.8.jar
>
> Staging repo:
> http://people.apache.org/~hboutemy/staging-repo/
>
> Tag:
> http://svn.apache.org/viewvc/maven/ant-tasks/tags/maven-ant-tasks-2.0.8/
>
> Vote open for 72 hours.
>
> Here is my +1
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Regards,
>
> Hervé
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [MECLIPSE] refactor IT tests to use shitty maven plugin ?

I've never used invoker or verifier, so still have to make my opinion.

I just had many issues configuring testing-harness with required maven
components : I added new feature to my mojos but tests cannot be updated due
to some new dependencies introduced that have no stub in testing-harness (or
no easy way to get one).
Shitty was an easy way to solve this.

AFAIK, shitty is similar to invoker, but does more : it install the current
artifact in local repo with version "testing" and invoke a maven build.
Seems to be what the invoker it-test do. Shitty alos use groovy scripts to
test the result.

Nico.

2007/12/13, Dan Fabulich <[EMAIL PROTECTED]>:
>
> nicolas de loof wrote:
>
> > shitty is a very simple way to it-test plugins.
>
> So I've heard...  But I've also heard good things about
> maven-invoker-plugin.  And I've said a lot of good things about
> maven-verifier tests.  Why use SHITTY and not one of the others?
>
> Or, let me phrase my question a different way.  I think we shouldn't keep
> using more and more different IT test plugins; we should narrow it down to
> just one or two different ways of doing these tests.
>
> Do you agree with that?  If so, do you think we should use shitty instead
> of maven-invoker-plugin?  As well as maven-invoker-plugin?  Should
> everybody just use whatever works?  (That's a fair answer, too...)
>
> -Dan
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: [Vote][second try] Release Maven Invoker 2.0.7


olivier lamy wrote:

But this means we have to wait the end of the discussions before 
releasing something ?


No, don't wait.  I haven't voted (I've never used Maven Invoker Plugin) 
but these discussions shouldn't hold up the vote.


+0, if that helps.  [I haven't tried the new version, but I'm sure it's 
fine! ;-)]


-Dan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [MECLIPSE] refactor IT tests to use shitty maven plugin ?


nicolas de loof wrote:


shitty is a very simple way to it-test plugins.


So I've heard...  But I've also heard good things about 
maven-invoker-plugin.  And I've said a lot of good things about 
maven-verifier tests.  Why use SHITTY and not one of the others?


Or, let me phrase my question a different way.  I think we shouldn't keep 
using more and more different IT test plugins; we should narrow it down to 
just one or two different ways of doing these tests.


Do you agree with that?  If so, do you think we should use shitty instead 
of maven-invoker-plugin?  As well as maven-invoker-plugin?  Should 
everybody just use whatever works?  (That's a fair answer, too...)


-Dan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Maven Ant Tasks 2.0.8 (take 2)

2007-12-13 Thread dndiaye


I check your take 2 at work, and i didn't find mistake.

+1
-- 
View this message in context: 
http://www.nabble.com/-VOTE--Maven-Ant-Tasks-2.0.8-%28take-2%29-tp14260773s177p14322253.html
Sent from the Maven Developers mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Vote][take 2] maven-shade-plugin release 1.0-alpha-15 and move out of sandbox

2007-12-13 Thread Mauro Talevi


Daniel Kulp wrote:
Crap.  Second time I've done this in the last couple weeks.   :-(   Why 
the 1.5 javac doesn't flag these things with source/targe set to 1.4 is 
beyond me.   Eclipse doesn't even flag them when using 1.5 but project 
is set to 1.4.


That said, I just figured out how to get the eclipse project to use a 1.4 
JVM for the maven projects I have so hopefully I won't do this again.


I've just committed fixes for it.  Sorry about that.



Thanks for that Dan!

I've rebuilt staging artifacts and created tag with latest revision.

URLs same as in the original email.

I'll wait until tomorrow to copy from staging to release repo.

Cheers


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [MECLIPSE] refactor IT tests to use shitty maven plugin ?

One repo test use testing-harness.

Other ones require to have many maven stubs, and a Project with an
ArtifactHandler (for language == java check) that is not (yet) supported bu
maven-plugin-testing-harness.

shitty is a very simple way to it-test plugins.

2007/12/13, Dan Fabulich <[EMAIL PROTECTED]>:
>
> nicolas de loof wrote:
>
> > I tried to look at maven-eclipse-plugin tests and was really confused on
> > it's testing framework complexity.
>
> Am I right in thinking that right now it's using the
> "maven-plugin-testing-harness?"  (I've never understood that either,
> though I haven't tried very hard.)
>
> > What about moving thoses IT tests to src/it via the Shitty maven plugin
> > ( http://mojo.codehaus.org/shitty-maven-plugin/usage.html) I allready
> > used it and found it simple to use and very powerfull.
>
> We've already got at least two other mechanisms for running plugin IT
> tests: maven-invoker-plugin and tests written in the maven-verifier style
> like those in maven/core-integration-testing or
> maven-surefire-plugin/trunk/surefire-integration-tests.  (I think the
> surefire tests might be a better example for comparison with the Eclipse
> plugin.)
>
>
> http://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/TestSingleTest.java
> http://tinyurl.com/3aqauu
>
> Can you help me understand the difference between SHITTY and those other
> mechanisms?  I'd really like to firmly advocate against proliferating more
> IT frameworks, that we try to narrow down on just one or two.
>
> In particular, I don't see advantages over using SHITTY versus using
> maven-invoker-plugin... I mean, I know they all do the same thing, but
> m-i-p and SHITTY look *really* similar.  Why use one over the other?
>
> Moreover, as you may have noticed in a nearby thread, jdcasey and I have
> been discussing the merits and flaws of the maven-invoker-plugin vs. the
> maven-verifier style of testing.  I think everything we've said about the
> m-i-p (for and against) would apply equally to SHITTY; I'm curious whether
> you have thoughts about this.
>
> > The only difficulty AFAIK is to refactor the generated file verification
> > to be used from validate.groovy scripts.
>
> I don't think this would be a difficulty if the tests were using the
> maven-verifier style; I think they may also be a bit more comprehensible
> that way, though I'll admit that I'm biased.
>
> -Dan
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

[ANN] Maven Remote Resources Plugin 1.0-beta-1 released


The Maven team is proud of announcing the new release of the Maven Remote 
Resources Plugin 1.0-beta-2 for Maven 2. 


Release Notes - Maven 2.x Remote Resources Plugin - Version 1.0-beta-2


** Bug
* [MRRESOURCES-26] - NPE in remote-resources:process while 
   sorting orgs
* [MRRESOURCES-27] - RemoteResourcesClassLoader isn't isolated 
   from maven jar


** Wish
* [MRRESOURCES-28] - Attaching the generated resources to the 
   project should be optional (for webapps)

For complete details, see:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13291&styleName=Html&projectId=11391&Create=Create



-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Vote][second try] Release Maven Invoker 2.0.7

2007-12-13 Thread olivier lamy

Hi,
I know there is some discussions about invoker versus verifier etc...
But this means we have to wait the end of the discussions before releasing
something ?
Some of you have voted +1 on the first try.

Thanks,

--
Olivier

12 Dec 2007 18:13:38 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>
> Hi,
> In the preparation of the Maven Invoker Plugin release, I would like to
> release maven-invoker:2.0.7
> The last release was done around one year ago.
> Staging repo :
> http://people.apache.org/~olamy/staging-repo/
> Vote open for 72 hours.
>
> Here my +1 (non binding).
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> --
> Olivier
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Invoker vs. Verifier?


John Casey wrote:



On Dec 12, 2007, at 9:47 PM, Dan Fabulich wrote:

I tweak the test to add a MAVEN_OPTS environment variable, including the 
-Xrunjdwp string.  (It would be easy to add some sugar to Verifier and/or 
Invoker to make this easier; I didn't want to go fooling around with the 
Verifier, so I just copied and pasted out of my notes when I needed this.)


Do you have an actual example of this that I can look at?


In Eclipse/IDEA you can launch the test and modify the test configuration 
to include different environment variables; it's all GUI and hard to 
provide an "example."


However, you can also do it by modifying the code of the test like this:

Verifier verifier = new Verifier( testDir.getAbsolutePath() );
HashMap envVars = new HashMap();
envVars.put( "MAVEN_OPTS", "-Xdebug 
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8001 -Xnoagent -Djava.compiler=NONE" 
);
verifier.executeGoal( "test" , envVars );
verifier.verifyErrorFreeLog();
verifier.resetStreams();

-Dan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoker vs. Verifier?

2007-12-13 Thread John Casey



On Dec 12, 2007, at 9:47 PM, Dan Fabulich wrote:

I tweak the test to add a MAVEN_OPTS environment variable,  
including the -Xrunjdwp string.  (It would be easy to add some  
sugar to Verifier and/or Invoker to make this easier; I didn't want  
to go fooling around with the Verifier, so I just copied and pasted  
out of my notes when I needed this.)


Do you have an actual example of this that I can look at?

As for the rest, I'll be interested to see what you come up with. I  
definitely agree that this Tower of Babel approach to things that we  
have in place now isn't helpful. I'm still not completely convinced  
that it's effective to do all of this through the IDE (yet), but I'm  
definitely willing to see an example of how it can be improved, as  
long as this doesn't mean compromising readability or debug-ability  
of headless build logs, as in the case of a test failing on the CI  
server, but not on my localhost.




---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john

Re: [Vote][take 2] maven-shade-plugin release 1.0-alpha-15 and move out of sandbox

Crap.  Second time I've done this in the last couple weeks.   :-(   Why 
the 1.5 javac doesn't flag these things with source/targe set to 1.4 is 
beyond me.   Eclipse doesn't even flag them when using 1.5 but project 
is set to 1.4.

That said, I just figured out how to get the eclipse project to use a 1.4 
JVM for the maven projects I have so hopefully I won't do this again.

I've just committed fixes for it.  Sorry about that.

Dan

On Thursday 13 December 2007, Mauro Talevi wrote:
> Vincent Siveton wrote:
> > -1 due to compilation failure with jdk1.4 on tag.
> > http://rafb.net/p/jVfAXG92.html
>
> Right - I thought the maven plugins parent POM would have fixed the
> target/source JDK to 1.4.
>
> I'd continue with vote (would avoid issuing another one) and fix JDK
> compat before releasing.
>
> Any objections?
>
> Cheers
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [MECLIPSE] refactor IT tests to use shitty maven plugin ?

nicolas de loof wrote:

I tried to look at maven-eclipse-plugin tests and was really confused on
it's testing framework complexity.

Am I right in thinking that right now it's using the
"maven-plugin-testing-harness?" (I've never understood that either,
though I haven't tried very hard.)

What about moving thoses IT tests to src/it via the Shitty maven plugin
( http://mojo.codehaus.org/shitty-maven-plugin/usage.html) I allready
used it and found it simple to use and very powerfull.

We've already got at least two other mechanisms for running plugin IT
tests: maven-invoker-plugin and tests written in the maven-verifier style
like those in maven/core-integration-testing or
maven-surefire-plugin/trunk/surefire-integration-tests. (I think the
surefire tests might be a better example for comparison with the Eclipse
plugin.)

http://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/TestSingleTest.java
http://tinyurl.com/3aqauu

Can you help me understand the difference between SHITTY and those other
mechanisms? I'd really like to firmly advocate against proliferating more
IT frameworks, that we try to narrow down on just one or two.

In particular, I don't see advantages over using SHITTY versus using
maven-invoker-plugin... I mean, I know they all do the same thing, but
m-i-p and SHITTY look *really* similar. Why use one over the other?

Moreover, as you may have noticed in a nearby thread, jdcasey and I have
been discussing the merits and flaws of the maven-invoker-plugin vs. the
maven-verifier style of testing. I think everything we've said about the
m-i-p (for and against) would apply equally to SHITTY; I'm curious whether
you have thoughts about this.

The only difficulty AFAIK is to refactor the generated file verification
to be used from validate.groovy scripts.

I don't think this would be a difficulty if the tests were using the
maven-verifier style; I think they may also be a bit more comprehensible
that way, though I'll admit that I'm biased.

-Dan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [MECLIPSE] refactor IT tests to use shitty maven plugin ?

2007-12-13 Thread Arnaud HERITIER

I understand. I had the same problem at the beginning.
When it works you can also check that you didn't brake the continuous
integration.
http://maven.zones.apache.org/continuum/buildResults.action?projectId=17&projectGroupId=2
For the Shitty plugin I'm in favor to use it (I also uses it in other
plugins I'm working on) .
The problem is with existing patchs posted by the community.


On Dec 13, 2007 3:17 PM, nicolas de loof <[EMAIL PROTECTED]> wrote:

> To be honest, my initial goal was to fix some Jira issues, but as some
> tests
> fail on my environment its difficult to know if I introduced some new
> issues
> or not.
>
> I've attached a patch on MECLIPSE-101 as a proof of concept on moving
> project-01 IT test to SHITTY.
>
>
> 2007/12/13, Arnaud HERITIER <[EMAIL PROTECTED]>:
> >
> > Tests defined in the eclipse plugin have to be completely refactored.
> > With the shitty plugin why not.
> > I already opened several issues to separate unit and integration tests
> and
> > also to refactor the plugin itself.
> > Actually, I don't want to begin all those changes if we didn't finish to
> > apply/reject existing patchs in Jira.
> > I'm working on MECLIPSE-344. If you want to help me to cleanup Jira ;-)
> >
> > Arnaud
> >
> > On Dec 13, 2007 2:58 PM, nicolas de loof <[EMAIL PROTECTED]> wrote:
> >
> > > Hello
> > >
> > > I tried to look at maven-eclipse-plugin tests and was really confused
> on
> > > it's testing framework complexity.
> > >
> > > What about moving thoses IT tests to src/it via the Shitty maven
> plugin
> > (
> > > http://mojo.codehaus.org/shitty-maven-plugin/usage.html)
> > > I allready used it and found it simple to use and very powerfull.
> > > The only difficulty AFAIK is to refactor the generated file
> verification
> > > to
> > > be used from validate.groovy scripts.
> > >
> > >
> > > I also got some errors running the tests as my local repo contains
> some
> > > source jars, so the generated .classpath files does not match the
> > expected
> > > ones.
> > >
> > > Maybe those tests should rely on a test localrepository and a test
> > > remoterepository to avoid such false-failures
> > >
> > > Nico.
> > >
> >
> >
> >
> > --
> > ..
> > Arnaud HERITIER
> > ..
> > OCTO Technology - aheritier AT octo DOT com
> > www.octo.com | blog.octo.com
> > ..
> > ASF - aheritier AT apache DOT org
> > www.apache.org | maven.apache.org
> > ...
> >
>



-- 
..
Arnaud HERITIER
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...

Re: [MECLIPSE] refactor IT tests to use shitty maven plugin ?

To be honest, my initial goal was to fix some Jira issues, but as some tests
fail on my environment its difficult to know if I introduced some new issues
or not.

I've attached a patch on MECLIPSE-101 as a proof of concept on moving
project-01 IT test to SHITTY.


2007/12/13, Arnaud HERITIER <[EMAIL PROTECTED]>:
>
> Tests defined in the eclipse plugin have to be completely refactored.
> With the shitty plugin why not.
> I already opened several issues to separate unit and integration tests and
> also to refactor the plugin itself.
> Actually, I don't want to begin all those changes if we didn't finish to
> apply/reject existing patchs in Jira.
> I'm working on MECLIPSE-344. If you want to help me to cleanup Jira ;-)
>
> Arnaud
>
> On Dec 13, 2007 2:58 PM, nicolas de loof <[EMAIL PROTECTED]> wrote:
>
> > Hello
> >
> > I tried to look at maven-eclipse-plugin tests and was really confused on
> > it's testing framework complexity.
> >
> > What about moving thoses IT tests to src/it via the Shitty maven plugin
> (
> > http://mojo.codehaus.org/shitty-maven-plugin/usage.html)
> > I allready used it and found it simple to use and very powerfull.
> > The only difficulty AFAIK is to refactor the generated file verification
> > to
> > be used from validate.groovy scripts.
> >
> >
> > I also got some errors running the tests as my local repo contains some
> > source jars, so the generated .classpath files does not match the
> expected
> > ones.
> >
> > Maybe those tests should rely on a test localrepository and a test
> > remoterepository to avoid such false-failures
> >
> > Nico.
> >
>
>
>
> --
> ..
> Arnaud HERITIER
> ..
> OCTO Technology - aheritier AT octo DOT com
> www.octo.com | blog.octo.com
> ..
> ASF - aheritier AT apache DOT org
> www.apache.org | maven.apache.org
> ...
>

Re: [MECLIPSE] refactor IT tests to use shitty maven plugin ?

2007-12-13 Thread Arnaud HERITIER

Tests defined in the eclipse plugin have to be completely refactored.
With the shitty plugin why not.
I already opened several issues to separate unit and integration tests and
also to refactor the plugin itself.
Actually, I don't want to begin all those changes if we didn't finish to
apply/reject existing patchs in Jira.
I'm working on MECLIPSE-344. If you want to help me to cleanup Jira ;-)

Arnaud

On Dec 13, 2007 2:58 PM, nicolas de loof <[EMAIL PROTECTED]> wrote:

> Hello
>
> I tried to look at maven-eclipse-plugin tests and was really confused on
> it's testing framework complexity.
>
> What about moving thoses IT tests to src/it via the Shitty maven plugin (
> http://mojo.codehaus.org/shitty-maven-plugin/usage.html)
> I allready used it and found it simple to use and very powerfull.
> The only difficulty AFAIK is to refactor the generated file verification
> to
> be used from validate.groovy scripts.
>
>
> I also got some errors running the tests as my local repo contains some
> source jars, so the generated .classpath files does not match the expected
> ones.
>
> Maybe those tests should rely on a test localrepository and a test
> remoterepository to avoid such false-failures
>
> Nico.
>

-- 
..
Arnaud HERITIER
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...

Re: [Vote][take 2] maven-shade-plugin release 1.0-alpha-15 and move out of sandbox

2007-12-13 Thread Mauro Talevi


Vincent Siveton wrote:

-1 due to compilation failure with jdk1.4 on tag.
http://rafb.net/p/jVfAXG92.html



Right - I thought the maven plugins parent POM would have fixed the 
target/source JDK to 1.4.


I'd continue with vote (would avoid issuing another one) and fix JDK 
compat before releasing.


Any objections?

Cheers



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[MECLIPSE] refactor IT tests to use shitty maven plugin ?