For this example, I am going to start a plugin for Eclipse, and have 2 separate jar management projects. Having separate projects managing your jars is nice in the sense that you can create a project that contains all of the necessary jars that you need to reference in a plugin (say, for example, all the Apache Commons jars – or at least a bunch of them) which then allows you to check in a project into CVS that everyone can then use as a dependent project for their plugin/app.
So, lets start a jar management plugin:
Start by going to File -> New -> Other. Under Plugin Development select Plugin Project and click Next.
Give your project a name (here it is NewJarManagementPlugin), and click Next.
Your plugin project should now have an ID, Name and a Version. Uncheck everything under Plugin Options , and make sure that the radio button under ‘Rich Client Application’ is set to No.
Click Finishto create the new plugin project. Your Package Explorer should now look similar to this:
There a couple of things that you can do right now since there won’t be any source code in this project. Delete the srcdirectory, and then open your build.properties file and delete the lines containing:
source.. = . output.. = .
Now, let’s add our Apache Commons jars that we think we may need. Start by creating a new directory under the root of
NewJarManagementPlugin called lib and copy the jars into it:
We now want these jars to be on the build path, so open the lib directory and select all of the jars. Right-click and select Build Path -> Add to Build Path.
We have now set up the structure of this plug-in, now lets make sure the building of it is set up properly. Currently, your package explorer should look like:
Double-clicking on the MANIFEST.MF file will open a multi-tabbed editor with several tabs along the bottom. Select the Runtime tab. We will first deal with the Classpatharea to the bottom right of the pane:
Click on the Add button and in the dialog that appears, open the libdirectory and select all of the jars. Make sure that the ‘Update the Build Path’ is checked:
Upon clicking Ok, your Classpath area of the Runtimetab should look like:
Next is the Exported Packages on the same tab (Runtime):
Clicking on the Add button will open a dialog. I feel that you should export everything if we want to start using these as projects that others can rely on. Select everything and then Ok:
Exported Packagesshould now look like:
Congratulations! There is your first jar management plugin. We will create a second one following the steps above (without all the images) for some Batik/SVG jars. Once we have followed the same steps, our Package Explorer should look like:
How does this help us? Well, as soon as you have several Eclipse projects to support a product, you will likely end up with more than one project requiring the same jar. Are you going to copy it into each project? We really shouldn’t. We should try to be smart about our dependencies. Ideally, we should be able to put ourselves into a situation such as:
Ideally, we would like to have a dependency graph similar to that above. The items in green show the deployable code with their mandatory dependencies. The red items are test code and test dependencies. You will note that I added four dotted dependencies from test code directly to the jar management plugins. These may or may not exist depending on the contents of the plugins, and how you have your dependencies set up. For example, a set of database jars likely does not have test code running against them, but may be required for the actual tests, or at the very least for setup/teardown. Also, Eclipse can have a plugin re-exporta set of dependencies so that the database jars would be exposed to the test code from the server app. We no longer have a direct dependency on a jar management plugin, but rather an indirect or transitive in nature.
<to be continued…>