m2eclipse and pom-packaged integration testing module: alternatives?

[stug23]

I recently filed a JIRA related to changes that were made in m2eclipse between 0.9.8 and 0.9.9 that result in problems when importing a multimodule project that contains a pom-packaged module used for integration testing.

Here are related JIRAs (the first one [1751] is the one I recently filed):

<https://issues.sonatype.org/browse/MNGECLIPSE-1751> "Closed -- duplicate of 1695"

<https://issues.sonatype.org/browse/MNGECLIPSE-1695> "Open -- Duplicate of 1670"

<https://issues.sonatype.org/browse/MNGECLIPSE-1670>

This problem relates to a situation where the build runs correctly in Eclipse using the Maven Embedder (3.x), but the resultant Eclipse projects have missing .classpath and inconsistent .project files which causes the Eclipse projects to be unusable with respect to normal Eclipse operations.

The concern that I am raising here is with regard to whether a valid Maven build (via Run As ...) should not also result in a consistent state with respect to the functionality of the corresponding Eclipse projects.

In the JIRA I asked:  "What is the recommended best practice for a module devoted to integration testing? If it should not be pom-packaged, what is the recommended solution? I know that at one point there was discussion of Maven supporting the convention src/it/java out of the box – is this still a possibility? Or is there another recommended solution?"

I would be interested in learning how others have defined an integration test module. What packaging did you use? If you used jar-packaging did you simply accept the jar generated by the module as "okay" to produce, even though it isn't really a build product of interest when integration testing?

Note that one additional purpose of isolating the integration tests in a separate module is so that the module can be placed into a profile, and hence be able to be run optionally by activating the profile.

[stug23]

Note that the idea of using a pom-packaged integration testing module mentioned in this posting is based on Chapter 4.13 "Testing J2EE Application" in the Better Builds with Maven book:

<http://www.maestrodev.com/better-build-maven>

The PDF is here:  <http://repo.exist.com/dist/maestro/1.7.0/BetterBuildsWithMaven.pdf>

[jvanzyl]

On 2009-10-06, at 8:09 PM, stug23 wrote:

>
> Note that the idea of using a pom-packaged integration testing module
> mentioned in this posting is based on Chapter 4.13 "Testing J2EE
> Application" in the Better Builds with Maven book:
>
> <http://www.maestrodev.com/better-build-maven>
>
> The PDF is here:
> <http://repo.exist.com/dist/maestro/1.7.0/BetterBuildsWithMaven.pdf>
>

Yah, that's just a bad idea. But I'll answer in your other thread.  
It's really a work around at best, and abuse in the worst case. Pom  
packaging is specifically meant for aggregation. Maven internally  
should have made the lifecycle there immutable.

> --
> View this message in context: http://www.nabble.com/m2eclipse-and-pom-packaged-integration-testing-module%3A-alternatives--tp25779590p25779842.html
> Sent from the Maven Eclipse - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[jvanzyl]

On 2009-10-06, at 7:30 PM, stug23 wrote:

>
> I recently filed a JIRA related to changes that were made in m2eclipse
> between 0.9.8 and 0.9.9 that result in problems when importing a  
> multimodule
> project that contains a pom-packaged module used for integration  
> testing.
>
> Here are related JIRAs (the first one [1751] is the one I recently  
> filed):
>
> <https://issues.sonatype.org/browse/MNGECLIPSE-1751> "Closed --  
> duplicate of
> 1695"
>
> <https://issues.sonatype.org/browse/MNGECLIPSE-1695> "Open --  
> Duplicate of
> 1670"
>
> <https://issues.sonatype.org/browse/MNGECLIPSE-1670>
>
> This problem relates to a situation where the build runs correctly in
> Eclipse using the Maven Embedder (3.x), but the resultant Eclipse  
> projects
> have missing .classpath and inconsistent .project files which causes  
> the
> Eclipse projects to be unusable with respect to normal Eclipse  
> operations.
>
> The concern that I am raising here is with regard to whether a valid  
> Maven
> build (via Run As ...) should not also result in a consistent state  
> with
> respect to the functionality of the corresponding Eclipse projects.
>

How Maven works on the CLI and what we do in M2Eclipse is really the  
only thing holding back the 1.0. There are things are we want to be  
more strict in Maven. For example I don't know how anyone ever arrived  
at doing integration tests with a packaging=pom. And that you read  
that in a book purported to be written by Maven developers I find  
surprising because the packaging=pom has a very specific purpose in  
Maven and that's for module aggregation. Anything else and you're  
really stepping outside the bounds of it's intended use.

> In the JIRA I asked:  "What is the recommended best practice for a  
> module
> devoted to integration testing? If it should not be pom-packaged,  
> what is
> the recommended solution? I know that at one point there was  
> discussion of
> Maven supporting the convention src/it/java out of the box – is this  
> still a
> possibility? Or is there another recommended solution?"
>

Look at all the Maven integration tests or Nexus integration tests.  
Many of them are separate modules and the sources are just in src/test/
java. They are just tests. We don't really care that a jar might be  
produced. We definitely don't use packaging=pom and that's frankly  
never even crossed my mind. It's a complete hack if you ask me.

> I would be interested in learning how others have defined an  
> integration
> test module. What packaging did you use? If you used jar-packaging  
> did you
> simply accept the jar generated by the module as "okay" to produce,  
> even
> though it isn't really a build product of interest when integration  
> testing?
>

Yes.

So if anything in Maven 3.x we will probably make that more strict so  
that people can't do weird things like this. I'm definitely not going  
to plan a lot of engineering work and contort the internals of  
M2Eclipse to support this quite frankly. I would suggest you live with  
packaging=jar. I'm not convinced using packaging=pom for integration  
testing is useful, and probably using it in the long run for something  
it wasn't intended for is harmful.

> Note that one additional purpose of isolating the integration tests  
> in a
> separate module is so that the module can be placed into a profile,  
> and
> hence be able to be run optionally by activating the profile.
>
>
> --
> View this message in context: http://www.nabble.com/m2eclipse-and-pom-packaged-integration-testing-module%3A-alternatives--tp25779590p25779590.html
> Sent from the Maven Eclipse - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email