- ThirdParty
- commons-logging
- 1.0.0
- commons-logging.jar
- commons-logging-api.jar
- src.zip
- docs.zip
- 1.0.4
- commons-logging.jar
- commons-logging-api.jar
- src.zip
- docs.zip
- 1.0.0
- commons-lang
- 2.1
- commons-lang-2.1.jar
- src.zip
- docs.zip
- 2.1
- foo-bar
- 3.4
- foo-bar.jar
- src.zip
- docs.zip
- deps
- commons-logging.jar
- 3.4
- commons-logging
Monday, June 5, 2006
Auto generating eclipse user libraries
Our build system at work is a little archaic, but there just isn't any time to rewrite it with anything more modern. As a result, I have to do some elbow twisting to get eclipse running smoothly with it. One of these contortions has to do with organizing the third party libraries we depend on.I start off with a directory called ThirdParty, under which I have a top level directory for each third party lib we use, e.g. commons-logging. Each third party directory will then have a sub-directory for each version we use, under which will be the jars for that lib plus a src.zip and docs.zip which contain the src and javadocs for use in eclipse. I find it better to keep them as archive files as it makes checkouts from source control a lot quicker, and I only ever browse their contents from within eclipse, which has no problem doing so. The nice thing about using the version number directories is that then the ThirdParty tree can be excluded from tagging/branching/etc. Since we never delete from ThirdParty, and the build files which are versioned have the right version number directory they depend on, the sytem as whole ends up acting versioned.e.g.
Subscribe to:
Posts (Atom)