You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason Dillon <ja...@planet57.com> on 2007/03/04 05:06:47 UTC
forceVersion for maven-install-plugin?
Any comments on adding a 'forceVersion' param to the maven-install-
plugin, which will for all artifacts (including attached) to be
installed with the given version?
I'm thinking this would be really helpful for testing maven plugins,
so that in the pre-integration-test phase, one could use the m-
install-p to force all artifacts to be installed with a 'testing'
version, then in the 'integration-test' phase run the m-invoker-p to
execute a set of maven projects to test/validate the plugin works as
expected, and then once that passes, the normal m-install-p execution
will install the real versions of the artifacts into the repository.
This would allow the src/it/**/pom.xml files to use <version>testing</
version> for all of the plugin artifacts, and would prevent broken
artifacts (which don't pass tests) from making it into the local repo
cache (and thus available to other projects).
For example:
----8<----
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<executions>
<execution>
<phase>pre-integration-test</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<forceVersion>testing</forceVersion>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-invoker-plugin</artifactId>
<executions>
<execution>
<phase>integration-test</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<projectsDirectory>${pom.basedir}/src/
it</projectsDirectory>
<pomIncludes>
<pomInclude>**/pom.xml</pomInclude>
<!-- all of these poms use <version>testing</version> -->
</pomIncludes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
---->8----
I've been digging around trying to figure out how to test my
plugins... so far I have not found a single example that just works
out of the box... I've gotten the groovy-maven-plugin ( http://
svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/groovy-maven-plugin/ )
to work *almost* as I'd like... the only exception is that right now
I have to hard-code the version of the plugin being tested in each
src/it/**/pom.xml... which I would really like to avoid.
I've seen a few other plugins use the maven-plugin-management-
plugin... but I've no idea what it does... same thing with maven-plug-
it-plugin... both look like they might do something along the lines
to allow src/it/**/pom.xml to not need hardcoded plugin versions...
but I really can't tell.
Anyways... I think simply adding a 'forceVersion' to the maven-
install-plugin should solve this... and not introduce more plugins to
support/maintain.
--jason
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: forceVersion for maven-install-plugin?
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I guess I don't see any harm in this, although I wouldn't add it only to
make tests of plugins work. That's a bigger issue that should be solved
correctly.
-----Original Message-----
From: jason.dillon@gmail.com [mailto:jason.dillon@gmail.com] On Behalf
Of Jason Dillon
Sent: Wednesday, March 14, 2007 7:52 PM
To: Maven Developers List
Subject: Re: forceVersion for maven-install-plugin?
Hrm... still no comments about this :-(
I'm going to try and whip up a patch for the maven-install-plugin to
implement this. And then hopefully someone will have a comment, or
maybe it will just get committed for the next release.
The alternative is to write yet another plugin to do this... which I'd
rather avoid. But given that no one has made a peep about this... I'm
not so sure that even with a patch that this will make it in to be
usable anytime in the nearish future... but maybe I'm wrong...
--jason
On 3/5/07, Jason Dillon <ja...@planet57.com> wrote:
> No comments? Is there another way to get specific 'testing' versions
> of artifacts installed into the local repo before the install phase?
>
> --jason
>
>
> On 3/3/07, Jason Dillon <ja...@planet57.com> wrote:
> > Any comments on adding a 'forceVersion' param to the maven-install-
> > plugin, which will for all artifacts (including attached) to be
> > installed with the given version?
> >
> > I'm thinking this would be really helpful for testing maven plugins,
> > so that in the pre-integration-test phase, one could use the m-
> > install-p to force all artifacts to be installed with a 'testing'
> > version, then in the 'integration-test' phase run the m-invoker-p to
> > execute a set of maven projects to test/validate the plugin works as
> > expected, and then once that passes, the normal m-install-p
execution
> > will install the real versions of the artifacts into the repository.
> >
> > This would allow the src/it/**/pom.xml files to use
<version>testing</
> > version> for all of the plugin artifacts, and would prevent broken
> > artifacts (which don't pass tests) from making it into the local
repo
> > cache (and thus available to other projects).
> >
> > For example:
> >
> > ----8<----
> > <build>
> > <plugins>
> > <plugin>
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-install-plugin</artifactId>
> > <executions>
> > <execution>
> > <phase>pre-integration-test</phase>
> > <goals>
> > <goal>run</goal>
> > </goals>
> > <configuration>
> > <forceVersion>testing</forceVersion>
> > </configuration>
> > </execution>
> > </executions>
> > </plugin>
> >
> > <plugin>
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-invoker-plugin</artifactId>
> > <executions>
> > <execution>
> > <phase>integration-test</phase>
> > <goals>
> > <goal>run</goal>
> > </goals>
> > <configuration>
> > <projectsDirectory>${pom.basedir}/src/
> > it</projectsDirectory>
> > <pomIncludes>
> > <pomInclude>**/pom.xml</pomInclude>
> > <!-- all of these poms use <version>testing</version> -->
> > </pomIncludes>
> > </configuration>
> > </execution>
> > </executions>
> > </plugin>
> > </plugins>
> > </build>
> > ---->8----
> >
> > I've been digging around trying to figure out how to test my
> > plugins... so far I have not found a single example that just works
> > out of the box... I've gotten the groovy-maven-plugin ( http://
> > svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/groovy-maven-plugin/ )
> > to work *almost* as I'd like... the only exception is that right now
> > I have to hard-code the version of the plugin being tested in each
> > src/it/**/pom.xml... which I would really like to avoid.
> >
> > I've seen a few other plugins use the maven-plugin-management-
> > plugin... but I've no idea what it does... same thing with
maven-plug-
> > it-plugin... both look like they might do something along the lines
> > to allow src/it/**/pom.xml to not need hardcoded plugin versions...
> > but I really can't tell.
> >
> > Anyways... I think simply adding a 'forceVersion' to the maven-
> > install-plugin should solve this... and not introduce more plugins
to
> > support/maintain.
> >
> > --jason
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: forceVersion for maven-install-plugin?
Posted by Jason Dillon <ja...@planet57.com>.
Hrm... still no comments about this :-(
I'm going to try and whip up a patch for the maven-install-plugin to
implement this. And then hopefully someone will have a comment, or
maybe it will just get committed for the next release.
The alternative is to write yet another plugin to do this... which I'd
rather avoid. But given that no one has made a peep about this... I'm
not so sure that even with a patch that this will make it in to be
usable anytime in the nearish future... but maybe I'm wrong...
--jason
On 3/5/07, Jason Dillon <ja...@planet57.com> wrote:
> No comments? Is there another way to get specific 'testing' versions
> of artifacts installed into the local repo before the install phase?
>
> --jason
>
>
> On 3/3/07, Jason Dillon <ja...@planet57.com> wrote:
> > Any comments on adding a 'forceVersion' param to the maven-install-
> > plugin, which will for all artifacts (including attached) to be
> > installed with the given version?
> >
> > I'm thinking this would be really helpful for testing maven plugins,
> > so that in the pre-integration-test phase, one could use the m-
> > install-p to force all artifacts to be installed with a 'testing'
> > version, then in the 'integration-test' phase run the m-invoker-p to
> > execute a set of maven projects to test/validate the plugin works as
> > expected, and then once that passes, the normal m-install-p execution
> > will install the real versions of the artifacts into the repository.
> >
> > This would allow the src/it/**/pom.xml files to use <version>testing</
> > version> for all of the plugin artifacts, and would prevent broken
> > artifacts (which don't pass tests) from making it into the local repo
> > cache (and thus available to other projects).
> >
> > For example:
> >
> > ----8<----
> > <build>
> > <plugins>
> > <plugin>
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-install-plugin</artifactId>
> > <executions>
> > <execution>
> > <phase>pre-integration-test</phase>
> > <goals>
> > <goal>run</goal>
> > </goals>
> > <configuration>
> > <forceVersion>testing</forceVersion>
> > </configuration>
> > </execution>
> > </executions>
> > </plugin>
> >
> > <plugin>
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-invoker-plugin</artifactId>
> > <executions>
> > <execution>
> > <phase>integration-test</phase>
> > <goals>
> > <goal>run</goal>
> > </goals>
> > <configuration>
> > <projectsDirectory>${pom.basedir}/src/
> > it</projectsDirectory>
> > <pomIncludes>
> > <pomInclude>**/pom.xml</pomInclude>
> > <!-- all of these poms use <version>testing</version> -->
> > </pomIncludes>
> > </configuration>
> > </execution>
> > </executions>
> > </plugin>
> > </plugins>
> > </build>
> > ---->8----
> >
> > I've been digging around trying to figure out how to test my
> > plugins... so far I have not found a single example that just works
> > out of the box... I've gotten the groovy-maven-plugin ( http://
> > svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/groovy-maven-plugin/ )
> > to work *almost* as I'd like... the only exception is that right now
> > I have to hard-code the version of the plugin being tested in each
> > src/it/**/pom.xml... which I would really like to avoid.
> >
> > I've seen a few other plugins use the maven-plugin-management-
> > plugin... but I've no idea what it does... same thing with maven-plug-
> > it-plugin... both look like they might do something along the lines
> > to allow src/it/**/pom.xml to not need hardcoded plugin versions...
> > but I really can't tell.
> >
> > Anyways... I think simply adding a 'forceVersion' to the maven-
> > install-plugin should solve this... and not introduce more plugins to
> > support/maintain.
> >
> > --jason
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: forceVersion for maven-install-plugin?
Posted by Jason Dillon <ja...@planet57.com>.
No comments? Is there another way to get specific 'testing' versions
of artifacts installed into the local repo before the install phase?
--jason
On 3/3/07, Jason Dillon <ja...@planet57.com> wrote:
> Any comments on adding a 'forceVersion' param to the maven-install-
> plugin, which will for all artifacts (including attached) to be
> installed with the given version?
>
> I'm thinking this would be really helpful for testing maven plugins,
> so that in the pre-integration-test phase, one could use the m-
> install-p to force all artifacts to be installed with a 'testing'
> version, then in the 'integration-test' phase run the m-invoker-p to
> execute a set of maven projects to test/validate the plugin works as
> expected, and then once that passes, the normal m-install-p execution
> will install the real versions of the artifacts into the repository.
>
> This would allow the src/it/**/pom.xml files to use <version>testing</
> version> for all of the plugin artifacts, and would prevent broken
> artifacts (which don't pass tests) from making it into the local repo
> cache (and thus available to other projects).
>
> For example:
>
> ----8<----
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-install-plugin</artifactId>
> <executions>
> <execution>
> <phase>pre-integration-test</phase>
> <goals>
> <goal>run</goal>
> </goals>
> <configuration>
> <forceVersion>testing</forceVersion>
> </configuration>
> </execution>
> </executions>
> </plugin>
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-invoker-plugin</artifactId>
> <executions>
> <execution>
> <phase>integration-test</phase>
> <goals>
> <goal>run</goal>
> </goals>
> <configuration>
> <projectsDirectory>${pom.basedir}/src/
> it</projectsDirectory>
> <pomIncludes>
> <pomInclude>**/pom.xml</pomInclude>
> <!-- all of these poms use <version>testing</version> -->
> </pomIncludes>
> </configuration>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
> ---->8----
>
> I've been digging around trying to figure out how to test my
> plugins... so far I have not found a single example that just works
> out of the box... I've gotten the groovy-maven-plugin ( http://
> svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/groovy-maven-plugin/ )
> to work *almost* as I'd like... the only exception is that right now
> I have to hard-code the version of the plugin being tested in each
> src/it/**/pom.xml... which I would really like to avoid.
>
> I've seen a few other plugins use the maven-plugin-management-
> plugin... but I've no idea what it does... same thing with maven-plug-
> it-plugin... both look like they might do something along the lines
> to allow src/it/**/pom.xml to not need hardcoded plugin versions...
> but I really can't tell.
>
> Anyways... I think simply adding a 'forceVersion' to the maven-
> install-plugin should solve this... and not introduce more plugins to
> support/maintain.
>
> --jason
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] MINSTALL-37 WAS forceVersion for maven-install-plugin?
Posted by Jason Dillon <ja...@planet57.com>.
On May 2, 2007, at 7:09 PM, Brian E. Fox wrote:
>> Its not really that close to install:install-file, since
>> install:install deals with attached artifacts as well as the primary
>> artifact. To get the same affect with install:install-file with a
>> project which has many attached artifacts, then you'd need to
>> configure an execute of install:install-file per artifact. Much
>> easier to simply have one execution with a forceVersion set IMO.
>
> Thanks for pointing that out, I hadn't considered that.
>
>> I guess I don't really care too much, and if I do start caring, then
>> I will just fork this plugin. Though really I don't see how adding a
>> little bit of flexibility to this plugin really hurts anyone.
>
> Normally I agree, (take a look at all the params in mdep) however
> given
> that this is a core plugin, changes to these goals are nearly
> equivalent
> to new features of maven itself. I think it deserves a closer look,
> that's all.
I understand :-)
--jason
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [VOTE] MINSTALL-37 WAS forceVersion for maven-install-plugin?
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>Its not really that close to install:install-file, since
>install:install deals with attached artifacts as well as the primary
>artifact. To get the same affect with install:install-file with a
>project which has many attached artifacts, then you'd need to
>configure an execute of install:install-file per artifact. Much
>easier to simply have one execution with a forceVersion set IMO.
Thanks for pointing that out, I hadn't considered that.
>I guess I don't really care too much, and if I do start caring, then
>I will just fork this plugin. Though really I don't see how adding a
>little bit of flexibility to this plugin really hurts anyone.
Normally I agree, (take a look at all the params in mdep) however given
that this is a core plugin, changes to these goals are nearly equivalent
to new features of maven itself. I think it deserves a closer look,
that's all.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] MINSTALL-37 WAS forceVersion for maven-install-plugin?
Posted by Jason Dillon <ja...@planet57.com>.
On May 2, 2007, at 5:30 PM, Brian E. Fox wrote:
> I'm looking at the remaining open issues in MINSTALL. This one
> http://jira.codehaus.org/browse/MINSTALL-37 has had some unresolved
> discussion in the past. For easy reading, please see here:
> http://www.nabble.com/forceVersion-for-maven-install-plugin--
> tf3341272s1
> 77.html#a9292710
>
> In summary, Jason D is attempting to use a new flag in install to
> force
> a version to "testing". This is to be bound to a pre-integration-
> testing
> phase to make the plugin he's building get installed and available to
> the IT tests (to work around an invoker issue).
>
> Regardless of the use case, I'm leary about adding this flag to the
> install plugin because I can see people trying to use this to
> incorrectly force maven around some version (or version-less) scheme.
> That being said, I'm mainly only worried about this being used to
> influence the invocation of the goal in the default lifecycle and I
> can
> see that it might be handy once in a while. I think perhaps a new goal
> that extended install:install and added this parameter would be a good
> compromise.
>
> I'm not sure what this new goal would be called and I think it
> essentially becomes very close to install:install-file once
> MINSTALL-30
> is fixed except it is easier to bind in the pom.
Its not really that close to install:install-file, since
install:install deals with attached artifacts as well as the primary
artifact. To get the same affect with install:install-file with a
project which has many attached artifacts, then you'd need to
configure an execute of install:install-file per artifact. Much
easier to simply have one execution with a forceVersion set IMO.
> I'd like to move the discussion to a head and I think that since
> this is
> a core plugin, it deserves a vote. I see 3 options:
>
> [] add forceVersion to install:install
> [] add new goal that extends install:install and includes forceVersion
> [] close MINSTALL-37 as won't fix and direct to use install:install-
> file
> if needed.
>
> Here's my vote:
> [-1 (non veto)] add forceVersion to install:install
> [+0] add new goal that extends install:install and includes
> forceVersion
> [+1] close MINSTALL-37 as won't fix and direct to use
> install:install-file if needed.
I guess I don't really care too much, and if I do start caring, then
I will just fork this plugin. Though really I don't see how adding a
little bit of flexibility to this plugin really hurts anyone.
--jason
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[VOTE] MINSTALL-37 WAS forceVersion for maven-install-plugin?
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I'm looking at the remaining open issues in MINSTALL. This one
http://jira.codehaus.org/browse/MINSTALL-37 has had some unresolved
discussion in the past. For easy reading, please see here:
http://www.nabble.com/forceVersion-for-maven-install-plugin--tf3341272s1
77.html#a9292710
In summary, Jason D is attempting to use a new flag in install to force
a version to "testing". This is to be bound to a pre-integration-testing
phase to make the plugin he's building get installed and available to
the IT tests (to work around an invoker issue).
Regardless of the use case, I'm leary about adding this flag to the
install plugin because I can see people trying to use this to
incorrectly force maven around some version (or version-less) scheme.
That being said, I'm mainly only worried about this being used to
influence the invocation of the goal in the default lifecycle and I can
see that it might be handy once in a while. I think perhaps a new goal
that extended install:install and added this parameter would be a good
compromise.
I'm not sure what this new goal would be called and I think it
essentially becomes very close to install:install-file once MINSTALL-30
is fixed except it is easier to bind in the pom.
I'd like to move the discussion to a head and I think that since this is
a core plugin, it deserves a vote. I see 3 options:
[] add forceVersion to install:install
[] add new goal that extends install:install and includes forceVersion
[] close MINSTALL-37 as won't fix and direct to use install:install-file
if needed.
Here's my vote:
[-1 (non veto)] add forceVersion to install:install
[+0] add new goal that extends install:install and includes forceVersion
[+1] close MINSTALL-37 as won't fix and direct to use
install:install-file if needed.
Vote for 72 hrs.
-----Original Message-----
From: Jason Dillon [mailto:jason.dillon@gmail.com] On Behalf Of Jason
Dillon
Sent: Wednesday, March 14, 2007 11:29 PM
To: Maven Developers List
Subject: Re: forceVersion for maven-install-plugin?
FYI, I've created a JIRA issue with the patch here:
http://jira.codehaus.org/browse/MINSTALL-37
I'd appreciate it if this could get applied and new snaps
deployed... :-)
--jason
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: forceVersion for maven-install-plugin?
Posted by Jason Dillon <ja...@planet57.com>.
FYI, I've created a JIRA issue with the patch here:
http://jira.codehaus.org/browse/MINSTALL-37
I'd appreciate it if this could get applied and new snaps
deployed... :-)
--jason
On Mar 14, 2007, at 7:08 PM, Jason Dillon wrote:
> I quickly mocked up the forceVersion with the groovy-maven-plugin
> and it works very well. Here is the g-m-p pom:
>
> http://rifers.org/paste/jdillon/show/3939
>
> One of the src/it poms:
>
> http://rifers.org/paste/jdillon/show/3938
>
> And the change to InstallMojo:
>
> http://rifers.org/paste/jdillon/show/3940 (full src)
> http://rifers.org/paste/jdillon/show/3941 (just the diff)
>
> With this change for forceVersion, then none of the src/it/*/
> pom.xml files need to know anything about the current plugins
> version, as they just assume that artifacts with version "testing"
> are the latest.
>
> Normal install:install works as expected, so that once all of the
> integration tests pass, the normal version of the artifacts make it
> into the repository. Also, since "testing" is not a SNAPSHOT, the
> invoker runs a tad bit faster since it doesn't have to resolve
> SNAPSHOTS for the plugin being tested.
>
> And... one can simple `mvn -Dit install` after a clean checkout and
> clean repo and the build will perform as expected.
>
> * * *
>
> I think this is pretty easy/simple and should always work. Unless
> you know of a better/simpler way... I'd like to get this change
> into the maven-install-plugin.
>
> --jason
>
>
> On Mar 14, 2007, at 5:29 PM, Jason van Zyl wrote:
>
>>
>> On 3 Mar 07, at 11:06 PM 3 Mar 07, Jason Dillon wrote:
>>
>>> Any comments on adding a 'forceVersion' param to the maven-
>>> install-plugin, which will for all artifacts (including attached)
>>> to be installed with the given version?
>>>
>>
>> Why not just use test repositories? You can hack this with a
>> settings but is now easy to do in 2.1 expressly for the purpose of
>> making testing easier. Do you need to force a version if using
>> test repositories was simple?
>>
>> Jason.
>>
>>> I'm thinking this would be really helpful for testing maven
>>> plugins, so that in the pre-integration-test phase, one could use
>>> the m-install-p to force all artifacts to be installed with a
>>> 'testing' version, then in the 'integration-test' phase run the m-
>>> invoker-p to execute a set of maven projects to test/validate the
>>> plugin works as expected, and then once that passes, the normal m-
>>> install-p execution will install the real versions of the
>>> artifacts into the repository.
>>>
>>> This would allow the src/it/**/pom.xml files to use
>>> <version>testing</version> for all of the plugin artifacts, and
>>> would prevent broken artifacts (which don't pass tests) from
>>> making it into the local repo cache (and thus available to other
>>> projects).
>>>
>>> For example:
>>>
>>> ----8<----
>>> <build>
>>> <plugins>
>>> <plugin>
>>> <groupId>org.apache.maven.plugins</groupId>
>>> <artifactId>maven-install-plugin</artifactId>
>>> <executions>
>>> <execution>
>>> <phase>pre-integration-test</phase>
>>> <goals>
>>> <goal>run</goal>
>>> </goals>
>>> <configuration>
>>> <forceVersion>testing</forceVersion>
>>> </configuration>
>>> </execution>
>>> </executions>
>>> </plugin>
>>>
>>> <plugin>
>>> <groupId>org.apache.maven.plugins</groupId>
>>> <artifactId>maven-invoker-plugin</artifactId>
>>> <executions>
>>> <execution>
>>> <phase>integration-test</phase>
>>> <goals>
>>> <goal>run</goal>
>>> </goals>
>>> <configuration>
>>> <projectsDirectory>${pom.basedir}/src/
>>> it</projectsDirectory>
>>> <pomIncludes>
>>> <pomInclude>**/pom.xml</
>>> pomInclude> <!-- all of these poms use <version>testing</version>
>>> -->
>>> </pomIncludes>
>>> </configuration>
>>> </execution>
>>> </executions>
>>> </plugin>
>>> </plugins>
>>> </build>
>>> ---->8----
>>>
>>> I've been digging around trying to figure out how to test my
>>> plugins... so far I have not found a single example that just
>>> works out of the box... I've gotten the groovy-maven-plugin
>>> ( http://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/groovy-
>>> maven-plugin/ ) to work *almost* as I'd like... the only
>>> exception is that right now I have to hard-code the version of
>>> the plugin being tested in each src/it/**/pom.xml... which I
>>> would really like to avoid.
>>>
>>> I've seen a few other plugins use the maven-plugin-management-
>>> plugin... but I've no idea what it does... same thing with maven-
>>> plug-it-plugin... both look like they might do something along
>>> the lines to allow src/it/**/pom.xml to not need hardcoded plugin
>>> versions... but I really can't tell.
>>>
>>> Anyways... I think simply adding a 'forceVersion' to the maven-
>>> install-plugin should solve this... and not introduce more
>>> plugins to support/maintain.
>>>
>>> --jason
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: forceVersion for maven-install-plugin?
Posted by Jason Dillon <ja...@planet57.com>.
I quickly mocked up the forceVersion with the groovy-maven-plugin and
it works very well. Here is the g-m-p pom:
http://rifers.org/paste/jdillon/show/3939
One of the src/it poms:
http://rifers.org/paste/jdillon/show/3938
And the change to InstallMojo:
http://rifers.org/paste/jdillon/show/3940 (full src)
http://rifers.org/paste/jdillon/show/3941 (just the diff)
With this change for forceVersion, then none of the src/it/*/pom.xml
files need to know anything about the current plugins version, as
they just assume that artifacts with version "testing" are the latest.
Normal install:install works as expected, so that once all of the
integration tests pass, the normal version of the artifacts make it
into the repository. Also, since "testing" is not a SNAPSHOT, the
invoker runs a tad bit faster since it doesn't have to resolve
SNAPSHOTS for the plugin being tested.
And... one can simple `mvn -Dit install` after a clean checkout and
clean repo and the build will perform as expected.
* * *
I think this is pretty easy/simple and should always work. Unless
you know of a better/simpler way... I'd like to get this change into
the maven-install-plugin.
--jason
On Mar 14, 2007, at 5:29 PM, Jason van Zyl wrote:
>
> On 3 Mar 07, at 11:06 PM 3 Mar 07, Jason Dillon wrote:
>
>> Any comments on adding a 'forceVersion' param to the maven-install-
>> plugin, which will for all artifacts (including attached) to be
>> installed with the given version?
>>
>
> Why not just use test repositories? You can hack this with a
> settings but is now easy to do in 2.1 expressly for the purpose of
> making testing easier. Do you need to force a version if using test
> repositories was simple?
>
> Jason.
>
>> I'm thinking this would be really helpful for testing maven
>> plugins, so that in the pre-integration-test phase, one could use
>> the m-install-p to force all artifacts to be installed with a
>> 'testing' version, then in the 'integration-test' phase run the m-
>> invoker-p to execute a set of maven projects to test/validate the
>> plugin works as expected, and then once that passes, the normal m-
>> install-p execution will install the real versions of the
>> artifacts into the repository.
>>
>> This would allow the src/it/**/pom.xml files to use
>> <version>testing</version> for all of the plugin artifacts, and
>> would prevent broken artifacts (which don't pass tests) from
>> making it into the local repo cache (and thus available to other
>> projects).
>>
>> For example:
>>
>> ----8<----
>> <build>
>> <plugins>
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-install-plugin</artifactId>
>> <executions>
>> <execution>
>> <phase>pre-integration-test</phase>
>> <goals>
>> <goal>run</goal>
>> </goals>
>> <configuration>
>> <forceVersion>testing</forceVersion>
>> </configuration>
>> </execution>
>> </executions>
>> </plugin>
>>
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-invoker-plugin</artifactId>
>> <executions>
>> <execution>
>> <phase>integration-test</phase>
>> <goals>
>> <goal>run</goal>
>> </goals>
>> <configuration>
>> <projectsDirectory>${pom.basedir}/src/
>> it</projectsDirectory>
>> <pomIncludes>
>> <pomInclude>**/pom.xml</
>> pomInclude> <!-- all of these poms use <version>testing</version> -->
>> </pomIncludes>
>> </configuration>
>> </execution>
>> </executions>
>> </plugin>
>> </plugins>
>> </build>
>> ---->8----
>>
>> I've been digging around trying to figure out how to test my
>> plugins... so far I have not found a single example that just
>> works out of the box... I've gotten the groovy-maven-plugin
>> ( http://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/groovy-
>> maven-plugin/ ) to work *almost* as I'd like... the only exception
>> is that right now I have to hard-code the version of the plugin
>> being tested in each src/it/**/pom.xml... which I would really
>> like to avoid.
>>
>> I've seen a few other plugins use the maven-plugin-management-
>> plugin... but I've no idea what it does... same thing with maven-
>> plug-it-plugin... both look like they might do something along the
>> lines to allow src/it/**/pom.xml to not need hardcoded plugin
>> versions... but I really can't tell.
>>
>> Anyways... I think simply adding a 'forceVersion' to the maven-
>> install-plugin should solve this... and not introduce more plugins
>> to support/maintain.
>>
>> --jason
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: forceVersion for maven-install-plugin?
Posted by Jason Dillon <ja...@planet57.com>.
Hrm... I though I replied to this mail hours ago... but looks like I
didn't...
> Ok, we've got different approaches here. I'll line them out to
> summarize:
I appreciate you taking the time :-)
> Mine:
> - use an integration testing plugin like maven-it-plugin to run
> test projects
> placed in src/it/*/pom.xml against the current artifact, which is
> not installed
> in any repository yet.
> - The embedder is fed the current artifact and the src/it/*
> projects in the reactor,
> where the current artifact is marked to be skipped during the build.
>
> Note: the IT projects don't have to specify a <version> for any
> <plugin> they're testing,
> since the version tag is optional. If absent, the latest version
> will be used,
> or the version from the reactor. MNG-1677 currently prevents maven
> from using a plugin
> from the reactor, though normal artifacts work.
Do you have an example of this working somewhere I can look at?
Something that I can checkout, and build... and get all of the src/it
magic working?
I looked through a few different plugins, some use snaps of plugins
which aren't published anywhere, some use plugins I can't even find
the source code for.
If you have a working example, I would love to look at it... at the
end of the day... I don't care how I get this work, as long as I get
it working ;-)
> Your approach:
> - bind a modified install plugin to the pre-integration-test phase
> to install
> the artifact with a different version in the local repository
> - run the invoker plugin to fork maven to build src/it/*.pom, using
> the local repository,
> remote repositories etc (IMHO an uncontrolled environment).
What is uncontrolled?
> If your approach works, go for it. Here are some other comments
> wrt. your problems:
> - use the install:install-file mojo; you can specify the path to
> the artifact in target/
> and the version you want to use - no need for a forceVersion
> parameter.
Yes, this is an option, though its a bit more pom configuration than:
<configuration>
<forceVersion>testing</forceVersion>
</configuration>
But, its worth a short... though I still think that forceVersion may
come in handy every now and then...
> - if you hardcode the version to install ('testing') in the pom, i
> see no harm
> in specifying that version in src/it/*/pom.xml aswell
Ya, that was how I was going to ensure that what I just built was
actually what was used by the child mvn invocations.
> - perhaps the staging mojo (can't remember which plugin) is of use;
> it temporarily
> installs the plugin in the local repository, backing up what's there;
> after the integration test, it restores the local repository.
I could have sworn I replied to this now... maybe Alzheimer's is
setting in or something...
I don't really care about uninstalling the "testing" artifacts... IMO
thats just too much complexity for these simple tests.
--jason
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: forceVersion for maven-install-plugin?
Posted by Jason Dillon <ja...@planet57.com>.
Kenny, when you get a chance I'd love to see an example of the maven-
it-plugin in action.
For now, I've just configured my projects to use install:install-
file, which appears to be working fine (at the cost of a bit more
complicated configuration).
--jason
On Mar 16, 2007, at 3:58 AM, Kenney Westerhof wrote:
>
> Ok, we've got different approaches here. I'll line them out to
> summarize:
>
> Mine:
> - use an integration testing plugin like maven-it-plugin to run
> test projects
> placed in src/it/*/pom.xml against the current artifact, which is
> not installed
> in any repository yet.
> - The embedder is fed the current artifact and the src/it/*
> projects in the reactor,
> where the current artifact is marked to be skipped during the build.
>
> Note: the IT projects don't have to specify a <version> for any
> <plugin> they're testing,
> since the version tag is optional. If absent, the latest version
> will be used,
> or the version from the reactor. MNG-1677 currently prevents maven
> from using a plugin
> from the reactor, though normal artifacts work.
>
> Your approach:
> - bind a modified install plugin to the pre-integration-test phase
> to install
> the artifact with a different version in the local repository
> - run the invoker plugin to fork maven to build src/it/*.pom, using
> the local repository,
> remote repositories etc (IMHO an uncontrolled environment).
>
> If your approach works, go for it. Here are some other comments
> wrt. your problems:
> - use the install:install-file mojo; you can specify the path to
> the artifact in target/
> and the version you want to use - no need for a forceVersion
> parameter.
> - if you hardcode the version to install ('testing') in the pom, i
> see no harm
> in specifying that version in src/it/*/pom.xml aswell
> - perhaps the staging mojo (can't remember which plugin) is of use;
> it temporarily
> installs the plugin in the local repository, backing up what's there;
> after the integration test, it restores the local repository.
>
> Jason Dillon wrote:
>> On Mar 15, 2007, at 2:38 AM, Kenney Westerhof wrote:
>>> Jason Dillon wrote:
>>>> How does a test repository help? I still need to configure in
>>>> my src/it/*/pom.xml the version of the plugin I'm testing.
>>>
>>> The latest plugin will be used, which is usually what you're
>>> testing.
>>> If the test repository does not contain other versions of the
>>> plugin,
>>> the one you're testing will be used.
>> Yes, I know... *BUT* that means the current version must be
>> configured in the src/it/* poms... which I do not want to have to
>> maintain/update. And when there is no artifact for that version
>> already in the repo then execution of src/it will fail when
>> executed from the integration-test phase.
>>>> Maybe I don't understand what you mean by "test repositories".
>>>
>>> It's basically -Dmaven.repo.local=/tmp/foo/ - an empty repository
>>> only used for the build.
>> Right, that doesn't help solve any problem.
>
> Sure it does, it solves the problem you described above: having to
> specify
> a version in the src/it/ poms. If there's only 1 version available
> in the
> local repository (/tmp/foo), that one will be used. so you don't
> have to
> specify the version.
>
>>>> I just want my src/it/*/pom.xml to *always* use the right
>>>> version of the plugin (ie. that which was just compiled). I
>>>> don't want to have to go updating poms each time I make a new
>>>> release to use the new version.
>>>
>>> This has nothing to do with versions, actually. See below.
>> See comment above... it has everything to do with versions. :-P
>
> See comment above. ;)
>
>>> Maven is very careful
>>> not to make artifacts available that have failing tests.
>>> If test fails, package won't run.
>>> If integration-test fails (after package), install won't run.
>> Right... and I like that *feature* but to run integration tests my
>> plugin I need it to be in the repository so it will resolve...
>
> With your approach, requiring the use of the local repo, yes. With
> mine, no. ;)
>
>>> The problem here is MNG-2677 (originally MNG-870): maven can't
>>> resolve plugins
>>> from the reactor.
>> Um... no... I agree MNG-2677 is a problem... and I'm still waiting
>> for that to get fixed for the Geronimo build... but that is *not*
>> the problem here. src/it/* tests are *not* run from the reactor,
>> nor do I want them to be run from the reactor.
>
> There are 2 reactors: the main build reactor, and the reactor created
> by the maven-it-plugin which contains the artifact to test and the
> test projects.
> So then it _is_ a problem if you take that approach.
>
>>> I wrote the maven-it-plugin a while ago (at the time of writing
>>> MNG-870),
>>> which will run an embedded maven on src/it/*/pom.xml (which was
>>> later turned
>>> into the embedder). This embedded maven would recognize the just
>>> built plugin
>>> from the reactor, and not use the version from the local repository.
>> I'm using the maven-invoker-plugin and aside from this version
>> issue I'm really happy with it.
>
> Ok. You could also use the verifier (shared/maven-verifier). That
> one also
> forks maven (or runs it embedded if you choose). We use it in the
> core-integration-tests.
>
> >>> If you can explain a better way to achieve the desired result
> I'm all
>>>> ears... but so far this is the only solution I can think of
>>>> which will work 100% of the time.
>>>
>>> The proper way would be to explicitly run the tests against
>>> target/${artifact},
>>> and not let it poms resolve it from the local or remote
>>> repositories.
>> Um... no... these are *integration tests* they are meant to test/
>> verify that integration with Maven works. And to do that, the
>> artifacts being tested need to get picked up/configured in the
>> normal way.
>
> They are, just not from the local repo but from a predefined path.
> I think
> we've established that maven can run plugins from local and remote
> repositories
> so you don't have to test that ;)
>
>>> So, versions for plugins are not needed in src/it/*/pom.xml. And
>>> even if you do
>>> specify one, you can't be certain that the version matches the
>>> artifact being
>>> built, and even worse, you can't be certain the artifact just
>>> built is being used.
>> Um... I don't get what you mean here at all... by using
>> forceVersion, running that in pre-integration-test, I can be 100%
>> certain that the code being tested *is* the code that was just built.
>
> It's one way to do it, yes, overwriting the existing plugin in the
> local repository.
> But if the integration test fails, and some project uses your
> plugin without a version
> specified, it could use the faulty 'testing' plugin in the local
> repository. That's
> something maven tries to avoid - placing artifacts in the local
> repo that haven't
> passed the tests.
>> * * *
>> I'm happy to keep talking about this... and maybe I can convince
>> you/someone that this is the simplest solution... though I suppose
>> at the end of the day if the Maven dev team isn't interested in
>> applying the patch I made, I will be forced to make a new plugin
>> to do the same thing... which I'd like to avoid.
>
> If you can convince us, we'll apply the patch, but there are some
> drawbacks.
> There are other discussions going on how to get all the different
> integration
> test methods sorted out in just one approach, where this one is a
> solution
> to a problem we're having with one of them, which was already
> solved in another
> mojo.
>
> Anyway I think it's a good thing to get the discussion going again
> so we can sort
> this out. I really think maven should provide an easy means of
> integration testing
> plugins and other artifacts, preferrably without polluting the
> local repository ;)
>
> -- Kenney
>
>> --jason
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: forceVersion for maven-install-plugin?
Posted by Jason Dillon <ja...@planet57.com>.
On Mar 16, 2007, at 3:58 AM, Kenney Westerhof wrote:
> Ok, we've got different approaches here. I'll line them out to
> summarize:
>
> Mine:
> - use an integration testing plugin like maven-it-plugin to run
> test projects
> placed in src/it/*/pom.xml against the current artifact, which is
> not installed
> in any repository yet.
> - The embedder is fed the current artifact and the src/it/*
> projects in the reactor,
> where the current artifact is marked to be skipped during the build.
Do you have a working example of this I can look at? (ie. something
I can checkout and build w/o any modifications to see how this works)?
> Your approach:
> - bind a modified install plugin to the pre-integration-test phase
> to install
> the artifact with a different version in the local repository
> - run the invoker plugin to fork maven to build src/it/*.pom, using
> the local repository,
> remote repositories etc (IMHO an uncontrolled environment).
How is this uncontrolled?
> If your approach works, go for it. Here are some other comments
> wrt. your problems:
> - use the install:install-file mojo; you can specify the path to
> the artifact in target/
> and the version you want to use - no need for a forceVersion
> parameter.
True, though IMO forceVersion is a little easier ;-)
> - if you hardcode the version to install ('testing') in the pom, i
> see no harm
> in specifying that version in src/it/*/pom.xml aswell
That is what I want to do... I want to use "testing" for the version
of my artifacts to be tested, and then use "testing" for all versions
in the src/it poms.
> - perhaps the staging mojo (can't remember which plugin) is of use;
> it temporarily
> installs the plugin in the local repository, backing up what's there;
> after the integration test, it restores the local repository.
I looked into some plugin that was using this... but couldn't get it
to build, nor could I find the snaps or source for the plugin it was
using to do the stage. But I really don't think its all that useful
to install, then uninstall. If the "testing" version is installed,
it can stay in the repo for all I care.
--jason
> Jason Dillon wrote:
>> On Mar 15, 2007, at 2:38 AM, Kenney Westerhof wrote:
>>> Jason Dillon wrote:
>>>> How does a test repository help? I still need to configure in
>>>> my src/it/*/pom.xml the version of the plugin I'm testing.
>>>
>>> The latest plugin will be used, which is usually what you're
>>> testing.
>>> If the test repository does not contain other versions of the
>>> plugin,
>>> the one you're testing will be used.
>> Yes, I know... *BUT* that means the current version must be
>> configured in the src/it/* poms... which I do not want to have to
>> maintain/update. And when there is no artifact for that version
>> already in the repo then execution of src/it will fail when
>> executed from the integration-test phase.
>>>> Maybe I don't understand what you mean by "test repositories".
>>>
>>> It's basically -Dmaven.repo.local=/tmp/foo/ - an empty repository
>>> only used for the build.
>> Right, that doesn't help solve any problem.
>
> Sure it does, it solves the problem you described above: having to
> specify
> a version in the src/it/ poms. If there's only 1 version available
> in the
> local repository (/tmp/foo), that one will be used. so you don't
> have to
> specify the version.
>
>>>> I just want my src/it/*/pom.xml to *always* use the right
>>>> version of the plugin (ie. that which was just compiled). I
>>>> don't want to have to go updating poms each time I make a new
>>>> release to use the new version.
>>>
>>> This has nothing to do with versions, actually. See below.
>> See comment above... it has everything to do with versions. :-P
>
> See comment above. ;)
>
>>> Maven is very careful
>>> not to make artifacts available that have failing tests.
>>> If test fails, package won't run.
>>> If integration-test fails (after package), install won't run.
>> Right... and I like that *feature* but to run integration tests my
>> plugin I need it to be in the repository so it will resolve...
>
> With your approach, requiring the use of the local repo, yes. With
> mine, no. ;)
>
>>> The problem here is MNG-2677 (originally MNG-870): maven can't
>>> resolve plugins
>>> from the reactor.
>> Um... no... I agree MNG-2677 is a problem... and I'm still waiting
>> for that to get fixed for the Geronimo build... but that is *not*
>> the problem here. src/it/* tests are *not* run from the reactor,
>> nor do I want them to be run from the reactor.
>
> There are 2 reactors: the main build reactor, and the reactor created
> by the maven-it-plugin which contains the artifact to test and the
> test projects.
> So then it _is_ a problem if you take that approach.
>
>>> I wrote the maven-it-plugin a while ago (at the time of writing
>>> MNG-870),
>>> which will run an embedded maven on src/it/*/pom.xml (which was
>>> later turned
>>> into the embedder). This embedded maven would recognize the just
>>> built plugin
>>> from the reactor, and not use the version from the local repository.
>> I'm using the maven-invoker-plugin and aside from this version
>> issue I'm really happy with it.
>
> Ok. You could also use the verifier (shared/maven-verifier). That
> one also
> forks maven (or runs it embedded if you choose). We use it in the
> core-integration-tests.
>
> >>> If you can explain a better way to achieve the desired result
> I'm all
>>>> ears... but so far this is the only solution I can think of
>>>> which will work 100% of the time.
>>>
>>> The proper way would be to explicitly run the tests against
>>> target/${artifact},
>>> and not let it poms resolve it from the local or remote
>>> repositories.
>> Um... no... these are *integration tests* they are meant to test/
>> verify that integration with Maven works. And to do that, the
>> artifacts being tested need to get picked up/configured in the
>> normal way.
>
> They are, just not from the local repo but from a predefined path.
> I think
> we've established that maven can run plugins from local and remote
> repositories
> so you don't have to test that ;)
>
>>> So, versions for plugins are not needed in src/it/*/pom.xml. And
>>> even if you do
>>> specify one, you can't be certain that the version matches the
>>> artifact being
>>> built, and even worse, you can't be certain the artifact just
>>> built is being used.
>> Um... I don't get what you mean here at all... by using
>> forceVersion, running that in pre-integration-test, I can be 100%
>> certain that the code being tested *is* the code that was just built.
>
> It's one way to do it, yes, overwriting the existing plugin in the
> local repository.
> But if the integration test fails, and some project uses your
> plugin without a version
> specified, it could use the faulty 'testing' plugin in the local
> repository. That's
> something maven tries to avoid - placing artifacts in the local
> repo that haven't
> passed the tests.
>> * * *
>> I'm happy to keep talking about this... and maybe I can convince
>> you/someone that this is the simplest solution... though I suppose
>> at the end of the day if the Maven dev team isn't interested in
>> applying the patch I made, I will be forced to make a new plugin
>> to do the same thing... which I'd like to avoid.
>
> If you can convince us, we'll apply the patch, but there are some
> drawbacks.
> There are other discussions going on how to get all the different
> integration
> test methods sorted out in just one approach, where this one is a
> solution
> to a problem we're having with one of them, which was already
> solved in another
> mojo.
>
> Anyway I think it's a good thing to get the discussion going again
> so we can sort
> this out. I really think maven should provide an easy means of
> integration testing
> plugins and other artifacts, preferrably without polluting the
> local repository ;)
>
> -- Kenney
>
>> --jason
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: forceVersion for maven-install-plugin?
Posted by Kenney Westerhof <ke...@apache.org>.
Ok, we've got different approaches here. I'll line them out to summarize:
Mine:
- use an integration testing plugin like maven-it-plugin to run test projects
placed in src/it/*/pom.xml against the current artifact, which is not installed
in any repository yet.
- The embedder is fed the current artifact and the src/it/* projects in the reactor,
where the current artifact is marked to be skipped during the build.
Note: the IT projects don't have to specify a <version> for any <plugin> they're testing,
since the version tag is optional. If absent, the latest version will be used,
or the version from the reactor. MNG-1677 currently prevents maven from using a plugin
from the reactor, though normal artifacts work.
Your approach:
- bind a modified install plugin to the pre-integration-test phase to install
the artifact with a different version in the local repository
- run the invoker plugin to fork maven to build src/it/*.pom, using the local repository,
remote repositories etc (IMHO an uncontrolled environment).
If your approach works, go for it. Here are some other comments wrt. your problems:
- use the install:install-file mojo; you can specify the path to the artifact in target/
and the version you want to use - no need for a forceVersion parameter.
- if you hardcode the version to install ('testing') in the pom, i see no harm
in specifying that version in src/it/*/pom.xml aswell
- perhaps the staging mojo (can't remember which plugin) is of use; it temporarily
installs the plugin in the local repository, backing up what's there;
after the integration test, it restores the local repository.
Jason Dillon wrote:
> On Mar 15, 2007, at 2:38 AM, Kenney Westerhof wrote:
>> Jason Dillon wrote:
>>> How does a test repository help? I still need to configure in my
>>> src/it/*/pom.xml the version of the plugin I'm testing.
>>
>> The latest plugin will be used, which is usually what you're testing.
>> If the test repository does not contain other versions of the plugin,
>> the one you're testing will be used.
>
> Yes, I know... *BUT* that means the current version must be configured
> in the src/it/* poms... which I do not want to have to maintain/update.
> And when there is no artifact for that version already in the repo then
> execution of src/it will fail when executed from the integration-test
> phase.
>
>
>>> Maybe I don't understand what you mean by "test repositories".
>>
>> It's basically -Dmaven.repo.local=/tmp/foo/ - an empty repository
>> only used for the build.
>
> Right, that doesn't help solve any problem.
Sure it does, it solves the problem you described above: having to specify
a version in the src/it/ poms. If there's only 1 version available in the
local repository (/tmp/foo), that one will be used. so you don't have to
specify the version.
>>> I just want my src/it/*/pom.xml to *always* use the right version of
>>> the plugin (ie. that which was just compiled). I don't want to have
>>> to go updating poms each time I make a new release to use the new
>>> version.
>>
>> This has nothing to do with versions, actually. See below.
>
> See comment above... it has everything to do with versions. :-P
See comment above. ;)
>> Maven is very careful
>> not to make artifacts available that have failing tests.
>> If test fails, package won't run.
>> If integration-test fails (after package), install won't run.
>
> Right... and I like that *feature* but to run integration tests my
> plugin I need it to be in the repository so it will resolve...
With your approach, requiring the use of the local repo, yes. With
mine, no. ;)
>> The problem here is MNG-2677 (originally MNG-870): maven can't resolve
>> plugins
>> from the reactor.
>
> Um... no... I agree MNG-2677 is a problem... and I'm still waiting for
> that to get fixed for the Geronimo build... but that is *not* the
> problem here. src/it/* tests are *not* run from the reactor, nor do I
> want them to be run from the reactor.
There are 2 reactors: the main build reactor, and the reactor created
by the maven-it-plugin which contains the artifact to test and the test projects.
So then it _is_ a problem if you take that approach.
>> I wrote the maven-it-plugin a while ago (at the time of writing MNG-870),
>> which will run an embedded maven on src/it/*/pom.xml (which was later
>> turned
>> into the embedder). This embedded maven would recognize the just built
>> plugin
>> from the reactor, and not use the version from the local repository.
>
> I'm using the maven-invoker-plugin and aside from this version issue I'm
> really happy with it.
Ok. You could also use the verifier (shared/maven-verifier). That one also
forks maven (or runs it embedded if you choose). We use it in the core-integration-tests.
>>> If you can explain a better way to achieve the desired result I'm all
>>> ears... but so far this is the only solution I can think of which
>>> will work 100% of the time.
>>
>> The proper way would be to explicitly run the tests against
>> target/${artifact},
>> and not let it poms resolve it from the local or remote repositories.
>
> Um... no... these are *integration tests* they are meant to test/verify
> that integration with Maven works. And to do that, the artifacts being
> tested need to get picked up/configured in the normal way.
They are, just not from the local repo but from a predefined path. I think
we've established that maven can run plugins from local and remote repositories
so you don't have to test that ;)
>> So, versions for plugins are not needed in src/it/*/pom.xml. And even
>> if you do
>> specify one, you can't be certain that the version matches the
>> artifact being
>> built, and even worse, you can't be certain the artifact just built is
>> being used.
>
> Um... I don't get what you mean here at all... by using forceVersion,
> running that in pre-integration-test, I can be 100% certain that the
> code being tested *is* the code that was just built.
It's one way to do it, yes, overwriting the existing plugin in the local repository.
But if the integration test fails, and some project uses your plugin without a version
specified, it could use the faulty 'testing' plugin in the local repository. That's
something maven tries to avoid - placing artifacts in the local repo that haven't
passed the tests.
>
> * * *
>
> I'm happy to keep talking about this... and maybe I can convince
> you/someone that this is the simplest solution... though I suppose at
> the end of the day if the Maven dev team isn't interested in applying
> the patch I made, I will be forced to make a new plugin to do the same
> thing... which I'd like to avoid.
If you can convince us, we'll apply the patch, but there are some drawbacks.
There are other discussions going on how to get all the different integration
test methods sorted out in just one approach, where this one is a solution
to a problem we're having with one of them, which was already solved in another
mojo.
Anyway I think it's a good thing to get the discussion going again so we can sort
this out. I really think maven should provide an easy means of integration testing
plugins and other artifacts, preferrably without polluting the local repository ;)
-- Kenney
>
> --jason
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: forceVersion for maven-install-plugin?
Posted by Jason Dillon <ja...@planet57.com>.
On Mar 15, 2007, at 2:38 AM, Kenney Westerhof wrote:
> Jason Dillon wrote:
>> How does a test repository help? I still need to configure in my
>> src/it/*/pom.xml the version of the plugin I'm testing.
>
> The latest plugin will be used, which is usually what you're testing.
> If the test repository does not contain other versions of the plugin,
> the one you're testing will be used.
Yes, I know... *BUT* that means the current version must be
configured in the src/it/* poms... which I do not want to have to
maintain/update. And when there is no artifact for that version
already in the repo then execution of src/it will fail when executed
from the integration-test phase.
>> Maybe I don't understand what you mean by "test repositories".
>
> It's basically -Dmaven.repo.local=/tmp/foo/ - an empty repository
> only used for the build.
Right, that doesn't help solve any problem.
>> I just want my src/it/*/pom.xml to *always* use the right version
>> of the plugin (ie. that which was just compiled). I don't want to
>> have to go updating poms each time I make a new release to use the
>> new version.
>
> This has nothing to do with versions, actually. See below.
See comment above... it has everything to do with versions. :-P
>> And even more important... the "install" phase happens *before*
>> the "integration-test" phase, so I still need a way to get the
>> artifacts into the repository before my integration-tests fire.
>
> No, install happens AFTER the integration test phase.
Right, I mistyped that sorry.
> Maven is very careful
> not to make artifacts available that have failing tests.
> If test fails, package won't run.
> If integration-test fails (after package), install won't run.
Right... and I like that *feature* but to run integration tests my
plugin I need it to be in the repository so it will resolve...
> Even if you were able to supply/override that testing version,
> the tests will fail since the artifact is not yet in the local
> repository.
> If you run again (and have a previous testing version in the local
> repo),
> the version from the local repo will be tested, not the version in
> target/.
Um... no... the build compiles stuff, then makes a jar, then installs
the artifact into the repo with a "testing" version for all its
artifacts, then runs integration-tests, where all child poms use
"testing" as the plugins version, if that passes, then the normal
install:install happens which puts the _real_ version into the repo,
else per-normal if the integration-tests failed, no _real_ version is
installed into the local repo.
> The problem here is MNG-2677 (originally MNG-870): maven can't
> resolve plugins
> from the reactor.
Um... no... I agree MNG-2677 is a problem... and I'm still waiting
for that to get fixed for the Geronimo build... but that is *not* the
problem here. src/it/* tests are *not* run from the reactor, nor do
I want them to be run from the reactor.
> I wrote the maven-it-plugin a while ago (at the time of writing
> MNG-870),
> which will run an embedded maven on src/it/*/pom.xml (which was
> later turned
> into the embedder). This embedded maven would recognize the just
> built plugin
> from the reactor, and not use the version from the local repository.
I'm using the maven-invoker-plugin and aside from this version issue
I'm really happy with it.
> So even with proper versions you still have a problem, since
> install is NOT run
> before integration-test, and hence the plugin is NOT available in
> the local
> repository.
Um right... which is why forceVersion is needed here ;-)
>> If you can explain a better way to achieve the desired result I'm
>> all ears... but so far this is the only solution I can think of
>> which will work 100% of the time.
>
> The proper way would be to explicitly run the tests against target/$
> {artifact},
> and not let it poms resolve it from the local or remote repositories.
Um... no... these are *integration tests* they are meant to test/
verify that integration with Maven works. And to do that, the
artifacts being tested need to get picked up/configured in the normal
way.
> So, versions for plugins are not needed in src/it/*/pom.xml. And
> even if you do
> specify one, you can't be certain that the version matches the
> artifact being
> built, and even worse, you can't be certain the artifact just built
> is being used.
Um... I don't get what you mean here at all... by using forceVersion,
running that in pre-integration-test, I can be 100% certain that the
code being tested *is* the code that was just built.
* * *
I'm happy to keep talking about this... and maybe I can convince you/
someone that this is the simplest solution... though I suppose at the
end of the day if the Maven dev team isn't interested in applying the
patch I made, I will be forced to make a new plugin to do the same
thing... which I'd like to avoid.
--jason
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: forceVersion for maven-install-plugin?
Posted by Kenney Westerhof <ke...@apache.org>.
Jason Dillon wrote:
> How does a test repository help? I still need to configure in my
> src/it/*/pom.xml the version of the plugin I'm testing.
The latest plugin will be used, which is usually what you're testing.
If the test repository does not contain other versions of the plugin,
the one you're testing will be used.
>
> Maybe I don't understand what you mean by "test repositories".
It's basically -Dmaven.repo.local=/tmp/foo/ - an empty repository
only used for the build.
> I just want my src/it/*/pom.xml to *always* use the right version of the
> plugin (ie. that which was just compiled). I don't want to have to go
> updating poms each time I make a new release to use the new version.
This has nothing to do with versions, actually. See below.
>
> And even more important... the "install" phase happens *before* the
> "integration-test" phase, so I still need a way to get the artifacts
> into the repository before my integration-tests fire.
No, install happens AFTER the integration test phase. Maven is very careful
not to make artifacts available that have failing tests.
If test fails, package won't run.
If integration-test fails (after package), install won't run.
Even if you were able to supply/override that testing version,
the tests will fail since the artifact is not yet in the local repository.
If you run again (and have a previous testing version in the local repo),
the version from the local repo will be tested, not the version in target/.
The problem here is MNG-2677 (originally MNG-870): maven can't resolve plugins
from the reactor.
I wrote the maven-it-plugin a while ago (at the time of writing MNG-870),
which will run an embedded maven on src/it/*/pom.xml (which was later turned
into the embedder). This embedded maven would recognize the just built plugin
from the reactor, and not use the version from the local repository.
So even with proper versions you still have a problem, since install is NOT run
before integration-test, and hence the plugin is NOT available in the local
repository.
> If you can explain a better way to achieve the desired result I'm all
> ears... but so far this is the only solution I can think of which will
> work 100% of the time.
The proper way would be to explicitly run the tests against target/${artifact},
and not let it poms resolve it from the local or remote repositories.
So, versions for plugins are not needed in src/it/*/pom.xml. And even if you do
specify one, you can't be certain that the version matches the artifact being
built, and even worse, you can't be certain the artifact just built is being used.
When MNG-870 was resolved (which later regressed), I succesfully ran integration
tests on the current artifact with the maven-it-plugin, so I think the easiest
and best solution here is to just fix MNG-2677.
-- Kenney
> Specifically what I mean is to add an execution of the
> maven-install-plugin:install w/forceVersion=testing to the
> "integration-tests" profile in the pre-integration-test phase. So this
> can be used with `mvn -Dit` to build and run integration tests, kinda
> like this:
>
> http://svn.codehaus.org/mojo/trunk/mojo/groovy-maven-plugin/pom.xml
>
> Though ^^^ does not have any install bits. This works, but will fail if
> you don't `mvn install` first to get something into the local repo...
> and requires all src/it/*/pom.xml files to have the version of the
> plugin. I suppose this could be avoided with parent poms etc... but
> these are supposed to be simple stand-along poms... and adding parents
> into the mix just complicates things way too much. Much better to
> simple get know "testing" versions of the artifacts into the local repo
> _before_ the integration-test phase.
>
> --jason
>
>
> On Mar 14, 2007, at 5:29 PM, Jason van Zyl wrote:
>
>>
>> On 3 Mar 07, at 11:06 PM 3 Mar 07, Jason Dillon wrote:
>>
>>> Any comments on adding a 'forceVersion' param to the
>>> maven-install-plugin, which will for all artifacts (including
>>> attached) to be installed with the given version?
>>>
>>
>> Why not just use test repositories? You can hack this with a settings
>> but is now easy to do in 2.1 expressly for the purpose of making
>> testing easier. Do you need to force a version if using test
>> repositories was simple?
>>
>> Jason.
>>
>>> I'm thinking this would be really helpful for testing maven plugins,
>>> so that in the pre-integration-test phase, one could use the
>>> m-install-p to force all artifacts to be installed with a 'testing'
>>> version, then in the 'integration-test' phase run the m-invoker-p to
>>> execute a set of maven projects to test/validate the plugin works as
>>> expected, and then once that passes, the normal m-install-p execution
>>> will install the real versions of the artifacts into the repository.
>>>
>>> This would allow the src/it/**/pom.xml files to use
>>> <version>testing</version> for all of the plugin artifacts, and would
>>> prevent broken artifacts (which don't pass tests) from making it into
>>> the local repo cache (and thus available to other projects).
>>>
>>> For example:
>>>
>>> ----8<----
>>> <build>
>>> <plugins>
>>> <plugin>
>>> <groupId>org.apache.maven.plugins</groupId>
>>> <artifactId>maven-install-plugin</artifactId>
>>> <executions>
>>> <execution>
>>> <phase>pre-integration-test</phase>
>>> <goals>
>>> <goal>run</goal>
>>> </goals>
>>> <configuration>
>>> <forceVersion>testing</forceVersion>
>>> </configuration>
>>> </execution>
>>> </executions>
>>> </plugin>
>>>
>>> <plugin>
>>> <groupId>org.apache.maven.plugins</groupId>
>>> <artifactId>maven-invoker-plugin</artifactId>
>>> <executions>
>>> <execution>
>>> <phase>integration-test</phase>
>>> <goals>
>>> <goal>run</goal>
>>> </goals>
>>> <configuration>
>>>
>>> <projectsDirectory>${pom.basedir}/src/it</projectsDirectory>
>>> <pomIncludes>
>>> <pomInclude>**/pom.xml</pomInclude>
>>> <!-- all of these poms use <version>testing</version> -->
>>> </pomIncludes>
>>> </configuration>
>>> </execution>
>>> </executions>
>>> </plugin>
>>> </plugins>
>>> </build>
>>> ---->8----
>>>
>>> I've been digging around trying to figure out how to test my
>>> plugins... so far I have not found a single example that just works
>>> out of the box... I've gotten the groovy-maven-plugin (
>>> http://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/groovy-maven-plugin/
>>> ) to work *almost* as I'd like... the only exception is that right
>>> now I have to hard-code the version of the plugin being tested in
>>> each src/it/**/pom.xml... which I would really like to avoid.
>>>
>>> I've seen a few other plugins use the
>>> maven-plugin-management-plugin... but I've no idea what it does...
>>> same thing with maven-plug-it-plugin... both look like they might do
>>> something along the lines to allow src/it/**/pom.xml to not need
>>> hardcoded plugin versions... but I really can't tell.
>>>
>>> Anyways... I think simply adding a 'forceVersion' to the
>>> maven-install-plugin should solve this... and not introduce more
>>> plugins to support/maintain.
>>>
>>> --jason
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: forceVersion for maven-install-plugin?
Posted by Jason Dillon <ja...@planet57.com>.
How does a test repository help? I still need to configure in my src/
it/*/pom.xml the version of the plugin I'm testing.
Maybe I don't understand what you mean by "test repositories".
I just want my src/it/*/pom.xml to *always* use the right version of
the plugin (ie. that which was just compiled). I don't want to have
to go updating poms each time I make a new release to use the new
version.
And even more important... the "install" phase happens *before* the
"integration-test" phase, so I still need a way to get the artifacts
into the repository before my integration-tests fire.
If you can explain a better way to achieve the desired result I'm all
ears... but so far this is the only solution I can think of which
will work 100% of the time.
Specifically what I mean is to add an execution of the maven-install-
plugin:install w/forceVersion=testing to the "integration-tests"
profile in the pre-integration-test phase. So this can be used with
`mvn -Dit` to build and run integration tests, kinda like this:
http://svn.codehaus.org/mojo/trunk/mojo/groovy-maven-plugin/pom.xml
Though ^^^ does not have any install bits. This works, but will fail
if you don't `mvn install` first to get something into the local
repo... and requires all src/it/*/pom.xml files to have the version
of the plugin. I suppose this could be avoided with parent poms
etc... but these are supposed to be simple stand-along poms... and
adding parents into the mix just complicates things way too much.
Much better to simple get know "testing" versions of the artifacts
into the local repo _before_ the integration-test phase.
--jason
On Mar 14, 2007, at 5:29 PM, Jason van Zyl wrote:
>
> On 3 Mar 07, at 11:06 PM 3 Mar 07, Jason Dillon wrote:
>
>> Any comments on adding a 'forceVersion' param to the maven-install-
>> plugin, which will for all artifacts (including attached) to be
>> installed with the given version?
>>
>
> Why not just use test repositories? You can hack this with a
> settings but is now easy to do in 2.1 expressly for the purpose of
> making testing easier. Do you need to force a version if using test
> repositories was simple?
>
> Jason.
>
>> I'm thinking this would be really helpful for testing maven
>> plugins, so that in the pre-integration-test phase, one could use
>> the m-install-p to force all artifacts to be installed with a
>> 'testing' version, then in the 'integration-test' phase run the m-
>> invoker-p to execute a set of maven projects to test/validate the
>> plugin works as expected, and then once that passes, the normal m-
>> install-p execution will install the real versions of the
>> artifacts into the repository.
>>
>> This would allow the src/it/**/pom.xml files to use
>> <version>testing</version> for all of the plugin artifacts, and
>> would prevent broken artifacts (which don't pass tests) from
>> making it into the local repo cache (and thus available to other
>> projects).
>>
>> For example:
>>
>> ----8<----
>> <build>
>> <plugins>
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-install-plugin</artifactId>
>> <executions>
>> <execution>
>> <phase>pre-integration-test</phase>
>> <goals>
>> <goal>run</goal>
>> </goals>
>> <configuration>
>> <forceVersion>testing</forceVersion>
>> </configuration>
>> </execution>
>> </executions>
>> </plugin>
>>
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-invoker-plugin</artifactId>
>> <executions>
>> <execution>
>> <phase>integration-test</phase>
>> <goals>
>> <goal>run</goal>
>> </goals>
>> <configuration>
>> <projectsDirectory>${pom.basedir}/src/
>> it</projectsDirectory>
>> <pomIncludes>
>> <pomInclude>**/pom.xml</
>> pomInclude> <!-- all of these poms use <version>testing</version> -->
>> </pomIncludes>
>> </configuration>
>> </execution>
>> </executions>
>> </plugin>
>> </plugins>
>> </build>
>> ---->8----
>>
>> I've been digging around trying to figure out how to test my
>> plugins... so far I have not found a single example that just
>> works out of the box... I've gotten the groovy-maven-plugin
>> ( http://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/groovy-
>> maven-plugin/ ) to work *almost* as I'd like... the only exception
>> is that right now I have to hard-code the version of the plugin
>> being tested in each src/it/**/pom.xml... which I would really
>> like to avoid.
>>
>> I've seen a few other plugins use the maven-plugin-management-
>> plugin... but I've no idea what it does... same thing with maven-
>> plug-it-plugin... both look like they might do something along the
>> lines to allow src/it/**/pom.xml to not need hardcoded plugin
>> versions... but I really can't tell.
>>
>> Anyways... I think simply adding a 'forceVersion' to the maven-
>> install-plugin should solve this... and not introduce more plugins
>> to support/maintain.
>>
>> --jason
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: forceVersion for maven-install-plugin?
Posted by Jason van Zyl <ja...@maven.org>.
On 3 Mar 07, at 11:06 PM 3 Mar 07, Jason Dillon wrote:
> Any comments on adding a 'forceVersion' param to the maven-install-
> plugin, which will for all artifacts (including attached) to be
> installed with the given version?
>
Why not just use test repositories? You can hack this with a settings
but is now easy to do in 2.1 expressly for the purpose of making
testing easier. Do you need to force a version if using test
repositories was simple?
Jason.
> I'm thinking this would be really helpful for testing maven
> plugins, so that in the pre-integration-test phase, one could use
> the m-install-p to force all artifacts to be installed with a
> 'testing' version, then in the 'integration-test' phase run the m-
> invoker-p to execute a set of maven projects to test/validate the
> plugin works as expected, and then once that passes, the normal m-
> install-p execution will install the real versions of the artifacts
> into the repository.
>
> This would allow the src/it/**/pom.xml files to use
> <version>testing</version> for all of the plugin artifacts, and
> would prevent broken artifacts (which don't pass tests) from making
> it into the local repo cache (and thus available to other projects).
>
> For example:
>
> ----8<----
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-install-plugin</artifactId>
> <executions>
> <execution>
> <phase>pre-integration-test</phase>
> <goals>
> <goal>run</goal>
> </goals>
> <configuration>
> <forceVersion>testing</forceVersion>
> </configuration>
> </execution>
> </executions>
> </plugin>
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-invoker-plugin</artifactId>
> <executions>
> <execution>
> <phase>integration-test</phase>
> <goals>
> <goal>run</goal>
> </goals>
> <configuration>
> <projectsDirectory>${pom.basedir}/src/
> it</projectsDirectory>
> <pomIncludes>
> <pomInclude>**/pom.xml</pomInclude>
> <!-- all of these poms use <version>testing</version> -->
> </pomIncludes>
> </configuration>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
> ---->8----
>
> I've been digging around trying to figure out how to test my
> plugins... so far I have not found a single example that just works
> out of the box... I've gotten the groovy-maven-plugin ( http://
> svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/groovy-maven-
> plugin/ ) to work *almost* as I'd like... the only exception is
> that right now I have to hard-code the version of the plugin being
> tested in each src/it/**/pom.xml... which I would really like to
> avoid.
>
> I've seen a few other plugins use the maven-plugin-management-
> plugin... but I've no idea what it does... same thing with maven-
> plug-it-plugin... both look like they might do something along the
> lines to allow src/it/**/pom.xml to not need hardcoded plugin
> versions... but I really can't tell.
>
> Anyways... I think simply adding a 'forceVersion' to the maven-
> install-plugin should solve this... and not introduce more plugins
> to support/maintain.
>
> --jason
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org