views:

41

answers:

1

In Eclipse it is possible to create launch configurations in a project, specifying the runtime dependencies from another project. A problem I found was that if you have a multiple project workspace, being possible that each project has its own libraries, it is easy to add explicit dependencies in a secondary project to libraries that are of another project and therefore subject to change.

An example of this problem follows:

proj1
    +-- src  
    +-- lib  
           +-- jar1-v1.0.jar  
           +-- jar2-v1.0.jar  
proj2  
    +-- src  
    +-- proj2-tests.launch

I don't have a dependency from the code in proj2/src to the libraries in proj1/lib. Nevertheless, I do have a dependency from proj2/src to proj1/src, although since there is an internal dependency in the code in proj1/src to its libraries jar1-v1.0.jar and jar2.v1.0.jar, I have to add a dependency in proj2-tests.launch to the libraries in proj1/lib. This translates to the following ugly lines in proj2-tests.launch:

<listEntry value="<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<runtimeClasspathEntry path="3" projectName="proj1" type="1"/>
"/>
<listEntry value="<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<runtimeClasspathEntry internalArchive="/proj1/lib/jar1-v1.0.jar" path="3" type="2"/>
"/>
<listEntry value="<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<runtimeClasspathEntry internalArchive="/proj1/lib/jar2-v1.0.jar" path="3" type="2"/>
"/>

This wouldn't be a big problem if there wasn't the need from time to time to evolve the software, upgrade the libraries and etc. Consider the common need to upgrade the libraries jar1-v1.0.jar and jar2-v1.0.jar to their versions v1.1. Consider that you have about 10 projects in one workspace, having about 5 libraries each and about 4 launch configurations. You get a maintenance overhead in doing a simple upgrade of a library, which normally must imply changes in files for which there wasn't the need for. Or maybe I'm doing something wrong...

What I would like to state is proj2 depends on proj1 and on its libraries and having this translated to simply that in the *.launch files. Is that possible?

A: 

Unless I am mistaken, if you add project1 to the build path of project2, the launcher for project2 will include the right classpath, even if the dependencies of project1 change:

alt text

(properties of project2, Java Build Path, tab "Projects")

VonC
Thanks for the answer. It would probably provide the required automation. Unfortunately I can't resort to that in my case because we use the Eclipse PDE dependencies to setup the Eclipse builds. My question was placed in the specific case of ArgoUML project and we have ArgoUML and ArgoEclipse. ArgoEclipse uses the Eclipse RCP files such as META-INF/MANIFEST.MF and friends. In "ArgoUML only" we use those only for the Eclipse build. So, although your solution is probably good for my plain answer posted above, it won't cut it for the specific problem I have.Should I create a new question?
euluis
@euluis: I would recommend a new question with those specific details (along with some screen captures and a more specific title), while you can close this question (by accepting the answer or posting an answer of your own)
VonC
Accepted. I'm building up a simplified example of my problem to place a new more specific question. Thanks.
euluis