[m2] maven-plugin-testing-tools and unit testing plugins critically broken...

[Barrie Treloar <ba...@gmail.com>]

See http://jira.codehaus.org/browse/MECLIPSE-192

maven-plugin-testing-tools builds the test jar by mangling the pom
info to include the test version and then run BuiltTool.executeMaven()
with the "package" phase to create the test jar.

The side effect of this is to put test artifacts into
D:\ide\workspace\maven\maven-eclipse-plugin\target\classes which is
not good.

I can see no work around for this situation except to use a different
mechanism for testing.

I noticed that there has been discussion about cleaning up the various
invokers/unit testing frameworks that are sprouting up.

The particular failures for the eclipse plugin are probably because
they should be integration tests and not unit tests.

Anyone have suggestions?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [m2] maven-plugin-testing-tools and unit testing plugins critically broken...

[Barrie Treloar <ba...@gmail.com>]

On 12/21/06, John Casey <ca...@gmail.com> wrote:
> They definitely should be integration tests, not unit tests. Something as
> time-consuming as a maven build shouldn't really be used during unit
> testing. In the case of the eclipse plugin, the fact that it was running
> these builds during unit testing causes the issue where the testing version
> of the plugin gets deployed. That's not to say that the plugin testing tools
> shouldn't be able to handle this use case (IMO).
>
> To address this, I've modified the maven-plugin-testing-tools so they make a
> copy of the plugin project directory, then mangle/install the plugin from
> there for testing. This separates the target directories of the main build
> and the test-staging build one doesn't step on the other's feet. I've tested
> this with a plugin that has maven builds in the integration-test phase, and
> manually inspected the target/classes/META-INF/maven/plugin.xml to verify
> that everything is still intact after integration testing. However, the
> reason this (deploying the testing version) will only happen when test
> builds are run during unit testing is that by the time integration testing
> happens, the plugin jar is already present, and the target/classes/**
> directory structure is just leftovers.

Making them integration tests would solve the problem.
Alternatively these unit tests can be run after the package phase
since the artifact has already been created, which really indicates
they are integration tests since you need the installed plugin to run
the tests.

I can't find the thread I read recently about attempting to clean up
integration testing or plugin testing. The closest I can find it
http://www.nabble.com/forum/ViewPost.jtp?post=7996314&framed=y&skin=177

There was talk about consolidating the different invokers/embedders for testing.
Might be time to start a new thread on that...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [m2] maven-plugin-testing-tools and unit testing plugins critically broken...

[John Casey <ca...@gmail.com>]

They definitely should be integration tests, not unit tests. Something as
time-consuming as a maven build shouldn't really be used during unit
testing. In the case of the eclipse plugin, the fact that it was running
these builds during unit testing causes the issue where the testing version
of the plugin gets deployed. That's not to say that the plugin testing tools
shouldn't be able to handle this use case (IMO).

To address this, I've modified the maven-plugin-testing-tools so they make a
copy of the plugin project directory, then mangle/install the plugin from
there for testing. This separates the target directories of the main build
and the test-staging build one doesn't step on the other's feet. I've tested
this with a plugin that has maven builds in the integration-test phase, and
manually inspected the target/classes/META-INF/maven/plugin.xml to verify
that everything is still intact after integration testing. However, the
reason this (deploying the testing version) will only happen when test
builds are run during unit testing is that by the time integration testing
happens, the plugin jar is already present, and the target/classes/**
directory structure is just leftovers.

-john

On 12/20/06, Barrie Treloar <ba...@gmail.com> wrote:
>
> See http://jira.codehaus.org/browse/MECLIPSE-192
>
> maven-plugin-testing-tools builds the test jar by mangling the pom
> info to include the test version and then run BuiltTool.executeMaven()
> with the "package" phase to create the test jar.
>
> The side effect of this is to put test artifacts into
> D:\ide\workspace\maven\maven-eclipse-plugin\target\classes which is
> not good.
>
> I can see no work around for this situation except to use a different
> mechanism for testing.
>
> I noticed that there has been discussion about cleaning up the various
> invokers/unit testing frameworks that are sprouting up.
>
> The particular failures for the eclipse plugin are probably because
> they should be integration tests and not unit tests.
>
> Anyone have suggestions?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>