- 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:
Post Comments (Atom)
This is very helpful, thanks! I hope to apply these awesome time-saving and IDE-enhancing tips to
ReplyDeleteSorry about that, the link is fixed now
ReplyDelete[...] we also need a good integration in to the IDE. The Ive Eclipse plugin is very poor, but I found a post in Swapfile of my brain with similar ideas… It’s time to put everything together. Technorati tags: java, [...]
ReplyDelete