views:

301

answers:

1

I have a basic web application (dynamic web project in eclipse) with an associated EAR project. I am trying to make sure that my junit test code stays out of the deployment EAR file.

In my web project I have a source folder called "src" and one called "test". I need to keep the .class files from the "test" source folder OUT of the EAR when I export it using eclipse.

I know this is trivial using ant but seems impossible using eclipse.. right click project and export the ear file.. the test classes are always included.

If I manually edit the .setting/org.eclipse.wst.common.component.xml file to remove the tag associated with the test folder it works but if some other developers change anything related to the build path, it gets regenerated...

Am I missing something obvious.. I've googled like crazy to no avail.. checked eclipse's docs and am at a loss..

A: 

It doesn't seem to be directly possible, which is bizarre. Here's a couple of workarounds you could try.

Note I'd move the java files from the web project to a Java project (this is probably a good practice to follow anyway). Either way create another "test" Java project and move the test sources to that project. Your test project declares the "main" Java project as a dependency so it has access to the types for testing, but isn't included in the war, so the test classes won't be deployed.

Alternatively if you want to keep the sources in one project, you can configure the test project to use linked resources. I've posted another answer that shows how you can use linked resources to share source locations across projects. With this approach the test sources still aren't on the build path for the main project, so won't be bundled in the jar, but are physically located in the project so source control is simpler.

Rich Seller
aha! linked resources.. that does appear to be a good compromise. no test.class files make it to the ear that way in my quick test.. I still would 'prefer' to keep test code with the project but.. alas..Thanks for the tip!
tim
So a little more thorough testing shows this really is not much different from removing the test folder from the build path. I cant actually "run" the test from eclipse unless it is on the build path tho...
tim
you can run the tests in the "test" project instead, where the tests are on the source path
Rich Seller
agreed.. where I work they tend to make lots of projects for a given application.. one in particular has 9 projects.. 4 of which are EJB projects.. If you do the seperate project approach, I would think you get one giant messy unit test project with all the other projects' classpath entries or lots of little unit test projects.. one for each production project? Have you any thoughts on this? I haven't actually tried it, probably need to.
tim
I'm not certain exactly what you mean. If I understand the comment correctly, here's how I do it. Each project has its unit tests defined in its src/test java source location. Integration tests for projects may be defined in a separate project, but there should be no need for unit tests to be defined externally to the project.
Rich Seller
Sounds like you understand the comment.. I would do it the same way you describe but for the fact that where I work.. They 'insist' that ear files be prepared for deployment by a different group of folks (not programmers or technical people). They insist on having this group of peoople use RAD to right click and export the EAR file, the problem is if you have test code in the project it will get exported with the ear using this approach.
tim
the unit tests can be in an entirely separate project, they don't need to be in the ear project. Re the build in RAD, if you're using Maven, why wouldn't you have the Ear built with Maven on a dedicated server?
Rich Seller
I am making some progress on convincing them of the value of ANT scripts at which point the whole thing becomes trivial anyway
tim
So currently we dont use ant or maven but am working on convincing mgmt to change that.. I agree w/out ant/maven the seperate project must be the way to go.
tim