views:

443

answers:

1

Hey,

I've a large eclipse project with multiple junit classes. I'm trying to strike a balance between adding runtime resources to the eclipse project classpath, and the need to configure mutliple junit launch configurations.

I realise the default eclipse build classpath is inherited by all unit test configurations, but some of my tests require extra runtime resources. I could add these resources to the build classpath, but this does slow my overall project build time (since it has to keep more files in synch). I don't like the idea of including * resources and jars on the runtime classpath.

The two options that i have are these, the positive and negative cases as i see it are listed

1 : Add all runtime resources to eclipse classpath.

  • POS I can select a unit test and run it without having to configure the test classpath.
  • POS Extra resources on build classpath means eclipse slows down.
  • NEG More difficult to ensure each test uses the correct resources.

2 : Configure the classpath of each unit test

  • POS I know exactly what resources are being used by a test.
  • POS Smaller build classpath means quicker build and execution by eclipse.
  • NEG Its a pain having to setup multiple separate junit runtime classpaths.

Ideally i'd like to configure one base junit runtime configuration, which takes the default eclipse build classpath, adds extra runtime jars and resources. This configuration could then be reused by the specific junit test cases, Is anything like this possible?

Looking at a specific junit launch configuration which can be exported to a share project file

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<launchConfiguration type="org.eclipse.jdt.junit.launchconfig">
<stringAttribute key="bad_container_name" value="/CR-3089_5_1_branch."/>
<listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_PATHS">
<listEntry value="/CR-3089_5_1_branch/src/com/x/y/z/ParserJUnitTest.java"/>
</listAttribute>
<listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_TYPES">
<listEntry value="1"/>
</listAttribute>
<stringAttribute key="org.eclipse.jdt.junit.CONTAINER" value=""/>
<booleanAttribute key="org.eclipse.jdt.junit.KEEPRUNNING_ATTR" value="false"/>
<stringAttribute key="org.eclipse.jdt.junit.TESTNAME" value=""/>
<stringAttribute key="org.eclipse.jdt.junit.TEST_KIND" value="org.eclipse.jdt.junit.loader.junit4"/>
<stringAttribute key="org.eclipse.jdt.launching.MAIN_TYPE" value="com.x.y.z.ParserJUnitTest"/>
<stringAttribute key="org.eclipse.jdt.launching.PROJECT_ATTR" value="CR-3089_5_1_branch"/>
</launchConfiguration>

is it possible to extend/reuse this configuration, and parameterise the 'org.eclipse.jdt.launching.MAIN_TYPE' value?

I'm aware of the commons launch and jar manifest file solutions to configuring the classpath, but they both seem to assume that an ant build is run before the test can execute. I want to avoid any eclipse dependency on calling an ant target when refactoting code and executing tests.

Basically - What is the the easiest way to seperate and maintain the eclipse buildtime classpath and junit runtime classpaths?

+1  A: 

The first solution could be to separate completely the project from its unit tests:

  • one project for the current build
  • one project for JUnit tests (or several if different kind of classpath are involved): that project will have the first dev project in its dependencies, and will not have to specify the classpath from that development.

A cleaner way (because it would be used within Eclipse, but also outside Eclipse) would be to transform your project in a maven one, through m2eclipse for instance.
That way, maven can manage the dependency compositions of several projects in order to have the right classpath for the test task.

VonC
i don't have an option of starting from stratch and need to focus on the existing configuration i have.
emeraldjava
@emeraldjava: understood, making new project would be a nice way to isolate your issue, while m2eclipse would be pretty muck akin to restart from scratch. So hopefully my first option is helpful in your case.
VonC