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
+-- Proj1Service.java: interface that will be implemented
serviceimpl
+-- src
+-- Capitalizer.java: implements Proj1Service interface using services in jar1-v1.0.jar
+-- lib
+-- jar1-v1.0.jar
proj2
+-- src
+-- Proj2Consumer.java: uses an implementation of Proj1Service defined in serviceimpl, but, discovered via reflection.
+-- proj2-main.launch
All these projects are defined by using the Eclipse Plug-in descriptors, ie, build.properties and META-INF/MANIFEST.MF instead of .project files.
I don't have a dependency from the code in proj2/src to the libraries in serviceimpl/lib. There is a dependency from proj2/src to proj1/src. Since there is an internal dependency in the code in serviceimpl/src to its library jar1-v1.0.jar, I have to add a dependency in proj2-main.launch to the serviceimpl by adding the project in the Classpath tab of the Run Configurations dialog with the proj2-main launch configuration selected. This translates to the following ugly lines in proj2-main.launch:
<listEntry value="<?xml version="1.0" encoding="UTF-8" standalone="no"?> <runtimeClasspathEntry path="3" projectName="serviceimpl" type="1"/> "/> <listEntry value="<?xml version="1.0" encoding="UTF-8" standalone="no"?> <runtimeClasspathEntry internalArchive="/serviceimpl/lib/jar1-v1.0.jar" path="3" type="2"/> "/>
Notice that although I only select to add the serviceimpl project, it adds all the libraries explicitly which isn't intended. 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 serviceimpl in runtime configuration proj2-main.launch and on its libraries and having this translated to simply that in the *.launch files. Is that possible?
To enable potential repliers to have the same example I gave above, I placed the projects (there is no jar2 because it wasn't necessary for the example) in the file http://www.fileden.com/files/2008/4/5/1853347/how-to-remove-the-explicit-dependencies-to-other-projects-libraries-eclipse-launch-configs.zip.