Bug 38282 - Multiple Java Build Paths
Summary: Multiple Java Build Paths
Status: RESOLVED WORKSFORME
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.1   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: 3.0 M1   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-05-30 15:59 EDT by Mark Addleman CLA
Modified: 2003-06-03 13:20 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Addleman CLA 2003-05-30 15:59:32 EDT
I'd like Eclipse to support a separate Java Build Path for each source folder. 
Most of my unit tests make use of jar files that shouldn't be part of the
regular source build.
Comment 1 Philipe Mulet CLA 2003-06-02 05:26:29 EDT
Can you be a little more descriptive on your source setup ?

The granularity of a build path is the project. You should consider 
reorganizing your sources into several projects instead.

Comment 2 Mark Addleman CLA 2003-06-02 13:18:37 EDT
I have a single project that acts as a client against two versions of a
protocol.  The protocol implementations share the same package, interface and
class names, but have differing parameter signatures and there are other
differences.  The client obviously needs to build against both.  The client has
a great deal of code that is shared between the two versions of the protocol, so
it doesn't make much conceptual sense to have two projects.  Further, having two
sets of identical source for the common code violates one and only once.

Right now, my project is structured so that each client side of the protocol is
in its own package and its own source folder.  That way, I can manually switch
between the two protocol version by editting the build path and changing the
referenced jars, but this is an irritating bit of manual work.

Maybe if there was a way to create sub-projects, this would work.  I could
create a master project that contained all of the common code and a sub-project
for each of the client protocol code.
Comment 3 Philipe Mulet CLA 2003-06-03 06:45:20 EDT
The latter was actually what I had in mind. Surface your current source folder 
into separate projects, which can then define their own individual classpaths. 
Also projects can be shared individually through source control, and thus 
probably would better fit your needs (protocols are likely evolving at a 
different pace than client code?).
Comment 4 Mark Addleman CLA 2003-06-03 13:00:34 EDT
Very good points.  I'll separate these into separate projects and see how well
it works.
Comment 5 Philipe Mulet CLA 2003-06-03 13:20:25 EDT
Hope it works for you.
Closing then, please reopen if necessary.