views:

598

answers:

3

In Maven, you can have compile-time dependencies and test dependencies. This is a feature I love, and the M2Eclipse plugin makes this available in Eclipse, too, which is great. So if I add jmock.jar to my project as a test dependency, it will show up on the classpath for JUnit tests, but won't be present when I'm debugging the application itself.

This is exactly what I'd like to achieve now, but without M2Eclipse or Maven. Is there a way to do this in plain Eclipse? (Possibly without installing any plugins.)

+2  A: 

You could separate all your tests into another project and add the main project as a dependency (Project->Properties->Java Build Path->Projects->Add...)

Update: To avoid changing the original project structure, your test projects can use linked locations.

Create the test project as normal, you now need to create a linked resource to bring in the src/test/java folder. It is best to create it using a variable so that your projects can retain some platform independence. To create a new linked folder select New->Folder, input src in the folder name: field then click Advanced>>

Click Link to folder in the file system Click on Variables... to bring up the Select Path Variable dialogue.

If this is your first time, or you are linking to a new location select New... and give the variable a sensible name and path. If all your projects are located in c:\workspaces\foo** it makes sense to call the variable **WORKSPACE_ROOT and give it that path. If you have some other convention that is fine, but it makes sense to put a comment in the .project file so someone has a chance of figuring out what the correct value should be.

Assuming the values above you can now set a value of WORKSPACE_ROOT/[subject project name]/src on the input field

Once you confirm that you should see the src folder with a little arrow, and if you look in the .project file see something like this:

<linkedResources>
 <link>
  <name>src</name>
  <type>2</type>
  <locationURI>WORKSPACE_ROOT/esf-ns-core-rp/src</locationURI>
 </link><!--NOTE the WORKSPACE_ROOT variable points to the folder containing the subject project's sandbox-->
</linkedResources>

You can now add the src/test/java folder as a source location as normal.

Note you can also share just the src/test/java folder by changing the config to something like this:

<linkedResources>
 <link>
  <name>src/test/java</name>
  <type>2</type>
  <locationURI>WORKSPACE_ROOT/my-project/src/test/java</locationURI>
 </link>
</linkedResources>

This gives more control over the config, but you would have to repeat for src/test/resources, src/it/java etc.

You then set all the test dependencies only in the test project.

Very not pretty, but it does work (I've also used this where my test compliance level is different to the main compliance level, e.g. 1.5 for tests, but 1.4 for the target environment).

Rich Seller
I'm doing this in a large application, developed by many people. I hope that we can migrate to Maven soon, therefore I wouldn't mind dirty tricks (that can be removed once we are on Maven/M2Eclipse), but modifying the project structure that much is out of scope at this point.
Lóránt Pintér
I shamelessly copied some parts of your answer in mine (http://stackoverflow.com/questions/1470827/external-output-folder-in-eclipse/1470833#1470833), so +1 ;)
VonC
A: 

Actually if you look in eclipse as to how Maven integrates dependencies it will not make the difference in test or runtime dependencies your test libraries are always accessible.

Maven will keep the difference when packaging the application and when it generates the runtime classpath if maven has control over the execution of that part. When eclipse is concerned Maven simply adds them all without question to the eclipse build path.

Why is it you need to have this separated like so ? What will this help you acheive ?

Newtopian
This is as you described if you don't use the M2Eclipse plugin. But with the plugin installed the dependency scopes are indeed enforced.I'd need this separation because I'd like to use separate logging implementations for testing and for runtime. As SLF4J uses SPI to locate the actual implementation, I don't think adding two of them on the classpath would be a good idea.
Lóránt Pintér
I guess the maven builder does more magic than advertised then. Well based on what I see here your best option for now (until you get Maven) would be to hack your project structure as Rich stated below while keeping your folder structure intact. In this case, if not already like so, you might as well start right away to enforce the maven layout convention, this will ease transition later on.
Newtopian
I was not aware of the SLF4J library... thanks.. I used to create my own wrapper though my needs are modest I never sought other solutions. thanks
Newtopian
A: 

I'm afraid the answer is that you can't. There are 2 open issues which were postponed from 3.5 related to your problem:

Robert Munteanu