$TEMP usage: surefire-booter and IT plugin test jar - shouldn't target/ be used instead?
I've a question as to why $TEMP is used to create temporary jar files
likesurefire-booter and the IT plugin test jars.
Why aren't these files created under ${basedir}\target\
The reason I ask is that my $TEMP directory on windows rarely gets
cleaned up and when I had a look in there I had 30+ IT plugin jars
and a smattering of surefire-booter jars too.
At least under target a mvn clean will delete these files.
The other benefit of target for the IT plugin test jar is that
previously created and unchanged class files may be re-used to speed
up the IT jar creation process.
Whereas in the $TEMP directory a new sub-dir is created each time the
process is run.
Thoughts?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: releasing verifier / core-integration-testing-support
On 15-Sep-08, at 11:55 AM, Brett Porter wrote: On 15/09/2008, at 6:47 PM, Jason van Zyl wrote: I honestly don't think this is necessary. The real problem is lack of consistency in deploying the IT ball. And honestly the IT ball is fine for casual people trying to test things but is ineffective for real-time work as we saw last week. It's dead simple to run the ITs from source using Hudson. I think the IT is great for contributors not really any good for us. Sure, but an entirely different problem to what I'm addressing here. You want to take maven-verifier out of shared? Yes, see above. -1 This is being used by other integration tests and is separate. I don't want it globbed in with our integration tests. It would still be separate. What I'm really suggesting is putting the helper (abstract test base class, used by both Maven's test suite and NMaven's test suite), in with the verifier and releasing them together. Shared is fine too, but I was thinking giving them their own trunk as a multi-module. I can go ahead and release the verifier on it's own, but the structure of the core-integration-testing is not conducive to releasing maven-integration-test-helper which is also needed. I think it makes more sense alongside the verifier. I don't really see much value in shuffling this around more right now. What would really help is to take the core-it-runner thing and put that in the same package and remove the duplication in the trunk and branches as that's really a separate module and doesn't belong with the rest of the code. And what would add even more value is knocking off some of these issues first: http://docs.codehaus.org/display/MAVEN/IT+Problems I'm not really having any difficultly with the current structure, neither are Shane and John now that they just run the job in Hudson which takes care of any necessary updating. I certainly don't want to move the verifier and second we change or add ITs which is happening fairly often now it just forces releasing, waiting for 3 days, people being out of sync. I just don't see it being worth it. It's easy in Hudson to run this stuff for our development purposes and CI. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding phase prepare-package in 2.1.0
Yes, please include support for prepare-package. We still will have to wait for jar/war plugins to support it, but it will then makes possible to implement web application post-processing (I think about javascript and css compression) and similmar stuff. Nicolas 2008/9/14 Brett Porter [EMAIL PROTECTED] Yeah, I think there are a few small changes like this that can be merged back. On 14/09/2008, at 3:41 AM, Olivier Lamy wrote: Hi, As we call now this version 2.1.x. Is it possible to add the new phase called prepare-package. This new phase is documented here [1] to be (Maven 2.1 and above). The related jira issue is MNG-2097 (it's a very old issue). We can certainly update the documentation and say (Maven 3.0 and above). But I prefer to add the new phase :-). Thanks, -- Olivier [1] http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: releasing verifier / core-integration-testing-support
On 15/09/2008, at 10:40 PM, Jason van Zyl wrote: It would still be separate. What I'm really suggesting is putting the helper (abstract test base class, used by both Maven's test suite and NMaven's test suite), in with the verifier and releasing them together. Shared is fine too, but I was thinking giving them their own trunk as a multi-module. I can go ahead and release the verifier on it's own, but the structure of the core-integration-testing is not conducive to releasing maven-integration-test-helper which is also needed. I think it makes more sense alongside the verifier. I don't really see much value in shuffling this around more right now. What would really help is to take the core-it-runner thing and put that in the same package and remove the duplication in the trunk and branches as that's really a separate module and doesn't belong with the rest of the code. And what would add even more value is knocking off some of these issues first: http://docs.codehaus.org/display/MAVEN/IT+Problems Tangent. Focus! :) I certainly don't want to move the verifier and second we change or add ITs which is happening fairly often now it just forces releasing, waiting for 3 days, people being out of sync. I just don't see it being worth it. It's easy in Hudson to run this stuff for our development purposes and CI. That's not what I'm aiming for. That can go back to a snapshot and stay there as soon as it changes, but I'd like to do a release so that NMaven doesn't require a snapshot. All I'm planning to do is: * release verifier * release maven-integration-test-helper (and the assoc archetypes/ sample for good measure) The latter would be ugly (with tags 3 levels up and needing to release a parent without its modules, etc), so I made a proposal to put them altogether as they are bits reusable outside Maven Core integration testing, as with the verifier, as you said. Do you have a different suggestion? I figured in essence you agree with me since you started to pull the support away from the suite, it's an extension of that. I sent this to make sure I'm not inadvertently mucking with others running the ITs so if anyone else has some concerns that there's something I've missed, let me know. Any takers? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Donation of Aardvark to Maven
On Tue, May 22, 2007 at 7:05 PM, Brett Porter [EMAIL PROTECTED] wrote: Ok, there seems to be some interest. I will spend some time putting the code into a suitable packaging / licensing structure and post it for a vote. There was some interest in a conversion tool on #maven this morning. Did anything happen with this? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: releasing verifier / core-integration-testing-support
I'm +1 for consolidating the helper and archetype/sample stuff into a SVN tree, then releasing all that stuff. I'd probably agree that the verifier needs to stay separate, though, since it's not specific to maven's ITs anymore. Also, (another tangent) we need to look into how we could start releasing the integration tests themselves alongside a maven release...not moving the ITs inside the various maven branches, but making sure there is an IT ball out there with a released version that describes the tests we used as criteria for that maven release...and the versions should probably correspond. In any case, that's a separate concern from consolidating/releasing the maven-core-it-specific libraries like the integration-test-helper and the archetype. -john Brett Porter wrote: On 15/09/2008, at 10:40 PM, Jason van Zyl wrote: It would still be separate. What I'm really suggesting is putting the helper (abstract test base class, used by both Maven's test suite and NMaven's test suite), in with the verifier and releasing them together. Shared is fine too, but I was thinking giving them their own trunk as a multi-module. I can go ahead and release the verifier on it's own, but the structure of the core-integration-testing is not conducive to releasing maven-integration-test-helper which is also needed. I think it makes more sense alongside the verifier. I don't really see much value in shuffling this around more right now. What would really help is to take the core-it-runner thing and put that in the same package and remove the duplication in the trunk and branches as that's really a separate module and doesn't belong with the rest of the code. And what would add even more value is knocking off some of these issues first: http://docs.codehaus.org/display/MAVEN/IT+Problems Tangent. Focus! :) I certainly don't want to move the verifier and second we change or add ITs which is happening fairly often now it just forces releasing, waiting for 3 days, people being out of sync. I just don't see it being worth it. It's easy in Hudson to run this stuff for our development purposes and CI. That's not what I'm aiming for. That can go back to a snapshot and stay there as soon as it changes, but I'd like to do a release so that NMaven doesn't require a snapshot. All I'm planning to do is: * release verifier * release maven-integration-test-helper (and the assoc archetypes/sample for good measure) The latter would be ugly (with tags 3 levels up and needing to release a parent without its modules, etc), so I made a proposal to put them altogether as they are bits reusable outside Maven Core integration testing, as with the verifier, as you said. Do you have a different suggestion? I figured in essence you agree with me since you started to pull the support away from the suite, it's an extension of that. I sent this to make sure I'm not inadvertently mucking with others running the ITs so if anyone else has some concerns that there's something I've missed, let me know. Any takers? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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: releasing verifier / core-integration-testing-support
I'm running on half a brain today (allergies), but I do want to make one point that I feel is pretty important: IMO we need to move away from generalized test plugins for use in the maven core ITs ASAP. Normal object-oriented design concerns don't apply well here, and factoring behavior into ever more abstract architecture does not serve the goal of clean, easy-to-debug integration tests. IMO the only infrastructure we need for integration testing maven is the verifier; everything else should be contained within the specific integration test that uses it. Sure, this will lead to a profusion of plugins, and probably will cost some time in terms of executing the integration test run, but these are not primary concerns of the integration test project...reliability and ease-of-debugging are. When we use a plugin for more than one integration test, it's inevitable that the logic in that plugin will be far more complex than is really needed to check the requirements for a particular integration test that uses it. This complexity is not helping us at all, and certainly the value of consolidating testing/verification logic from multiple integration tests is not greater than the problems caused when we have to chase bugs into these plugins...then try to fix the issue (which may be in the method of testing as much as in the main code in these cases) without causing collateral damage to other integration tests. If the only dependency for integration tests is the verifier, then there's not much point in moving it into its own SVN structure, IMO. -john --- John Casey Developer and PMC Member, Apache Maven (http://maven.apache.org) Member, Apache Software Foundation Blog: http://www.ejlife.net/blogs/buildchimp Brett Porter wrote: On 15/09/2008, at 10:22 AM, Jason van Zyl wrote: On 15-Sep-08, at 1:40 AM, Brett Porter wrote: Hi, To clear up some of the confusion about snapshots in the area I'd like to take the following steps: What confusion? 1) the answer to the question what's the current release of the verifier? (it's 1.0, but there's 1.1-SNAPSHOT and 1.2-SNAPSHOT floating around, we should just release the latest as it works). 2) in applying some patches I found these are also used by NMaven's trunk. It was looking for 1.0-SNAPSHOT of maven-integration-test-helper which is now 2.1-SNAPSHOT, though it has nothing to do with the Maven version. 3) the inheritance hierarchy of the support modules no longer matches the directory structure. 1) create /maven-integration-testing/trunk (+tags and branches) Those are there already, no? As I said, I'm suggesting a separate trunk for the bits that run maven test suites (verifier + maven-* in the support dir) vs the test suite itself (tests + support artifacts). 2) move maven-verifier and maven-integration-test-* from the recently separated core-integration-tests-support module into that trunk (this being a collection of things that help write integration tests that run Maven). Group ID org.apache.maven.itest to avoid confusion with the previous versions, and version 1.2-SNAPSHOT to align to the verifier You want to take maven-verifier out of shared? Yes, see above. 3) release the above multi-module project as 1.2 4) update core-integration-testing to use the above release and align the versions as a single multi-module project (this being a particular version of a whole test suite). Thoughts? I think you should defer to John and Shane's needs as Shane just got seriously hosed by mismatched versions and while trying to stabilize the trunk I would prefer to get some stable baseline before any swizzling happens. What happened was just oversight but Shane and I sat there for hours wondering what was going on until we released I was running the ITs from source and he was running the IT ball which were missing 10 ITs because no one was deploying it. Exactly, I am trying to establish a stable baseline everything can use. Having a few released artifacts will reduce the need to build things first. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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]
Cannot run in offline mode -- problem with maven-deploy-plugin ?
This is the error I get: [INFO] Installing C:\dev\eclipse\mops2.0\mops\pom.xml to C:\Documents and Settings\jxbrady\.m2\repository\com\putnam\mops\mops\2.0-SNAPSHOT\mops-2.0-SNAPSHOT.pom altDeploymentRepository = null [ERROR] The following mojo encountered an error while executing: Group-Id: org.apache.maven.plugins Artifact-Id: maven-deploy-plugin Version: 2.3 Mojo: deploy brought in via: packaging: pom While building project: Group-Id: com.putnam.mops Artifact-Id: mops Version: 2.0-SNAPSHOT From file: C:\dev\eclipse\mops2.0\mops\pom.xml Reason: System is offline. Cannot deploy artifact: com.putnam.mops:mops:pom:2.0-SNAPSHOT. I am trying to set up an internal repository and I have followed this sites reccomendations: http://stubbisms.wordpress.com/2008/08/28/maven-is-to-ant-as-a-nail-gun-is-to-hammer-and-nails-you-need-to-move-on/ Any help would be appreciated Thanks John -- View this message in context: http://www.nabble.com/Cannot-run-in-offline-modeproblem-with-maven-deploy-plugin---tp19495062p19495062.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] Release maven-plugins parent POM 12
I thought you wanted to get the parent v10 done before pushing out to all the plugins? I need one more vote for enforcer, then we can update v10 and stage that immediately. -Original Message- From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: Monday, September 15, 2008 8:30 AM To: Maven Developers List Subject: [VOTE] Release maven-plugins parent POM 12 Hi Here's another parent in need of a release. Diff for the pom.xml: http://svn.eu.apache.org/viewvc/maven/plugins/trunk/pom.xml?r1=646036r2 =695450diff_format=h Diff for the site.xml: http://svn.eu.apache.org/viewvc/maven/plugins/trunk/src/site/site.xml?r1 =630637r2=689071diff_format=h I have deployed a new SNAPSHOT as maven-plugins 12-20080915.122743-9. The vote will be open for 72 hours. -- Dennis Lundberg - 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: Cannot run in offline mode -- problem with maven-deploy-plugin ?
You're telling Maven that you are offline. Deploying is an Online behavior, therefore they are mutually exclusive. Also, this is a user list question as it doesn't relate to the development of Maven itself. -Original Message- From: jbrady3324 [mailto:[EMAIL PROTECTED] Sent: Monday, September 15, 2008 11:15 AM To: dev@maven.apache.org Subject: Cannot run in offline mode -- problem with maven-deploy-plugin ? This is the error I get: [INFO] Installing C:\dev\eclipse\mops2.0\mops\pom.xml to C:\Documents and Settings\jxbrady\.m2\repository\com\putnam\mops\mops\2.0-SNAPSHOT\mops-2 .0-SNAPSHOT.pom altDeploymentRepository = null [ERROR] The following mojo encountered an error while executing: Group-Id: org.apache.maven.plugins Artifact-Id: maven-deploy-plugin Version: 2.3 Mojo: deploy brought in via: packaging: pom While building project: Group-Id: com.putnam.mops Artifact-Id: mops Version: 2.0-SNAPSHOT From file: C:\dev\eclipse\mops2.0\mops\pom.xml Reason: System is offline. Cannot deploy artifact: com.putnam.mops:mops:pom:2.0-SNAPSHOT. I am trying to set up an internal repository and I have followed this sites reccomendations: http://stubbisms.wordpress.com/2008/08/28/maven-is-to-ant-as-a-nail-gun- is-to-hammer-and-nails-you-need-to-move-on/ Any help would be appreciated Thanks John -- View this message in context: http://www.nabble.com/Cannot-run-in-offline-modeproblem-with-maven-d eploy-plugin---tp19495062p19495062.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: releasing verifier / core-integration-testing-support
If the only dependency for integration tests is the verifier, then there's not much point in moving it into its own SVN structure, IMO. I think the verifier _is_ useful in Its outside of maven core itself. Case in point: Nexus. We should move the verifier to be a full-fledged plugin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-plugins parent POM 12
No, that was really someone elses itch. Like you said before, another parent release can be made later on for those who needs it. We need to release more often. Brian E. Fox wrote: I thought you wanted to get the parent v10 done before pushing out to all the plugins? I need one more vote for enforcer, then we can update v10 and stage that immediately. -Original Message- From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: Monday, September 15, 2008 8:30 AM To: Maven Developers List Subject: [VOTE] Release maven-plugins parent POM 12 Hi Here's another parent in need of a release. Diff for the pom.xml: http://svn.eu.apache.org/viewvc/maven/plugins/trunk/pom.xml?r1=646036r2 =695450diff_format=h Diff for the site.xml: http://svn.eu.apache.org/viewvc/maven/plugins/trunk/src/site/site.xml?r1 =630637r2=689071diff_format=h I have deployed a new SNAPSHOT as maven-plugins 12-20080915.122743-9. The vote will be open for 72 hours. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: releasing verifier / core-integration-testing-support
Brian E. Fox wrote: If the only dependency for integration tests is the verifier, then there's not much point in moving it into its own SVN structure, IMO. I think the verifier _is_ useful in Its outside of maven core itself. Case in point: Nexus. We should move the verifier to be a full-fledged plugin. We have something called Maven Verifier Plugin. To me, that sounds like a plugin wrapper around the shared Maven Verifier component, but that doesn't seem to be the case. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release maven-plugins parent POM 12
Alrighty then +1 from me. -Original Message- From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: Monday, September 15, 2008 2:08 PM To: Maven Developers List Subject: Re: [VOTE] Release maven-plugins parent POM 12 No, that was really someone elses itch. Like you said before, another parent release can be made later on for those who needs it. We need to release more often. Brian E. Fox wrote: I thought you wanted to get the parent v10 done before pushing out to all the plugins? I need one more vote for enforcer, then we can update v10 and stage that immediately. -Original Message- From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: Monday, September 15, 2008 8:30 AM To: Maven Developers List Subject: [VOTE] Release maven-plugins parent POM 12 Hi Here's another parent in need of a release. Diff for the pom.xml: http://svn.eu.apache.org/viewvc/maven/plugins/trunk/pom.xml?r1=646036r2 =695450diff_format=h Diff for the site.xml: http://svn.eu.apache.org/viewvc/maven/plugins/trunk/src/site/site.xml?r1 =630637r2=689071diff_format=h I have deployed a new SNAPSHOT as maven-plugins 12-20080915.122743-9. The vote will be open for 72 hours. -- Dennis Lundberg - 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: releasing verifier / core-integration-testing-support
You're right, and I forgot about the separation. I think the verifier needs to be a regular shared component (not plugin as I stated) -Original Message- From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: Monday, September 15, 2008 2:14 PM To: Maven Developers List Subject: Re: releasing verifier / core-integration-testing-support Brian E. Fox wrote: If the only dependency for integration tests is the verifier, then there's not much point in moving it into its own SVN structure, IMO. I think the verifier _is_ useful in Its outside of maven core itself. Case in point: Nexus. We should move the verifier to be a full-fledged plugin. We have something called Maven Verifier Plugin. To me, that sounds like a plugin wrapper around the shared Maven Verifier component, but that doesn't seem to be the case. -- Dennis Lundberg - 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: Build failed in Hudson: plugins-IT-with-maven-2.0.x ยป Maven Changes Report Plugin #422
Hi,
Someone can explain why this failed in hudson ?
The build.log of the it says :
Caused by: org.codehaus.plexus.component.composition.CompositionException:
Composition failed of field velocity in object of type
org.apache.maven.plugin.announcement.AnnouncementMojo because the
requirement
ComponentRequirement{role='org.codehaus.plexus.velocity.VelocityComponent',
roleHint='maven-changes-plugin', fieldName='velocity'} was missing
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:154)
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assembleComponent(FieldComponentComposer.java:73)
at
org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:68)
at
org.codehaus.plexus.DefaultPlexusContainer.composeComponent(DefaultPlexusContainer.java:1486)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:29)
... 25 more
Caused by:
org.codehaus.plexus.component.repository.exception.ComponentLookupException:
Component descriptor cannot be found in the component repository:
org.codehaus.plexus.velocity.VelocityComponentmaven-changes-plugin.
But the component declaration is here [1] and no failure for the others its.
Thanks,
--
Olivier
[1]
2008/9/15 Hudson [EMAIL PROTECTED]:
See
http://ci.sonatype.org/job/plugins-IT-with-maven-2.0.x/org.apache.maven.plugins$maven-changes-plugin/422/changes
--
[INFO]
[INFO] Building Maven Changes Report Plugin
[INFO]task-segment: [clean, deploy]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
http://ci.sonatype.org/job/plugins-IT-with-maven-2.0.x/org.apache.maven.plugins$maven-changes-plugin/ws/target
[INFO] [enforcer:enforce {execution: ensure-no-container-api}]
[INFO] [plugin:helpmojo {execution: generated-helpmojo}]
[INFO] Using 2 extractors.
[INFO] Applying extractor for language: java
[INFO] Extractor for language: java found 5 mojo descriptors.
[INFO] Applying extractor for language: bsh
[INFO] Extractor for language: bsh found 0 mojo descriptors.
[INFO] [modello:java {execution: standard}]
[INFO] outputDirectory:
http://ci.sonatype.org/job/plugins-IT-with-maven-2.0.x/org.apache.maven.plugins$maven-changes-plugin/ws/target/generated-sources/modello
[INFO] Working on model: src/main/mdo/changes.mdo
[INFO] Generating current version: 1.0.0
[INFO] [modello:xpp3-reader {execution: standard}]
[INFO] outputDirectory:
http://ci.sonatype.org/job/plugins-IT-with-maven-2.0.x/org.apache.maven.plugins$maven-changes-plugin/ws/target/generated-sources/modello
[INFO] Working on model: src/main/mdo/changes.mdo
[INFO] Generating current version: 1.0.0
[INFO] [modello:xpp3-writer {execution: standard}]
[INFO] outputDirectory:
http://ci.sonatype.org/job/plugins-IT-with-maven-2.0.x/org.apache.maven.plugins$maven-changes-plugin/ws/target/generated-sources/modello
[INFO] Working on model: src/main/mdo/changes.mdo
[INFO] Generating current version: 1.0.0
[INFO] [plugin:descriptor]
[INFO] Using 2 extractors.
[INFO] Applying extractor for language: java
[INFO] Extractor for language: java found 6 mojo descriptors.
[INFO] Applying extractor for language: bsh
[INFO] Extractor for language: bsh found 0 mojo descriptors.
[INFO] [remote-resources:process {execution: default}]
[INFO] [modello:xsd {execution: generate-xsd}]
[INFO] outputDirectory:
http://ci.sonatype.org/job/plugins-IT-with-maven-2.0.x/org.apache.maven.plugins$maven-changes-plugin/ws/target/classes/META-INF/changes/xsd
[INFO] Working on model: src/main/mdo/changes.mdo
[INFO] Generating current version: 1.0.0
[INFO] [plexus:merge-descriptors {execution: merge}]
[INFO] [resources:resources]
[INFO] Using encoding: 'UTF-8' to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 33 source files to
http://ci.sonatype.org/job/plugins-IT-with-maven-2.0.x/org.apache.maven.plugins$maven-changes-plugin/ws/target/classes
[INFO] [plexus:descriptor {execution: create-component-descriptor}]
[INFO] Discovered 1 component descriptors(s)
[INFO] [resources:testResources]
[INFO] Using encoding: 'UTF-8' to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 5 source files to
http://ci.sonatype.org/job/plugins-IT-with-maven-2.0.x/org.apache.maven.plugins$maven-changes-plugin/ws/target/test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
http://ci.sonatype.org/job/plugins-IT-with-maven-2.0.x/org.apache.maven.plugins$maven-changes-plugin/ws/target/surefire-reports
---
T E S T S
---
[vote] Release Maven 2.1.0-M1
Hi everyone, After fixing 70 issues and spending about 2 months going through release candidate after release candidate, we finally have a stable codebase! To that end, I'd like to put Maven 2.1.0-M1 up for a vote. The release notes are here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=14503 and the staged binary is here: http://people.apache.org/~jdcasey/stage/apache-maven/2.1.0-M1/org/apache/maven/apache-maven/2.1.0-M1 This vote will be open for 72h. Please vote +1/+0/-1. Here's my +1. Thanks, -john --- John Casey Developer and PMC Member, Apache Maven (http://maven.apache.org) Member, Apache Software Foundation Blog: http://www.ejlife.net/blogs/buildchimp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-plugins parent POM 12
+1 Thanks, Deng On Mon, Sep 15, 2008 at 8:29 PM, Dennis Lundberg [EMAIL PROTECTED] wrote: Hi Here's another parent in need of a release. Diff for the pom.xml: http://svn.eu.apache.org/viewvc/maven/plugins/trunk/pom.xml?r1=646036r2=695450diff_format=h Diff for the site.xml: http://svn.eu.apache.org/viewvc/maven/plugins/trunk/src/site/site.xml?r1=630637r2=689071diff_format=h I have deployed a new SNAPSHOT as maven-plugins 12-20080915.122743-9. The vote will be open for 72 hours. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
