My organization is looking into using Apache Ivy for dependency management in a multi-project configuration. We have a main project (call it MAIN) where most development takes place and a few helper library projects (call it LIBPROJ) which we keep in separate repositories. What we do right now is to build jars for the library projects when they change, and commit them to the main project, but this is a big headache and leads to project bloat.
It looks like using something like ivy is a good fit. We envision using our Jenkins server to automatically build a new library jar for LIBPROJ and publish it to ivy, then using a "latest.integration" version to automatically pull in the latest version of LIBPROJ into MAIN. But if we have to bisect to find out when an issue cropped up, how can this work?
The only way I can think to do this right now is to change the version of LIBPROJ we depend on in MAIN whenever a change is made to LIBPROJ, but that's not much better than checking in the jar itself.
The reason I'm concerned about this is because in the case of looking at old versions of MAIN, if I just check one out it won't be possible to build and run because it's requesting the latest build, even tho the revision I'm looking at right now might be days/weeks/months out of sync. This will break any kind of bisection tools (like in git or mercurial), which is something I really don't want to do.
Using dynamic revisions is a normal and powerful feature of ivy. Obviously you need to take care because the dependencies of new builds can potentially fail when 3rd party projects introduce incompatible changes.
My recommendations on usage:
- latest.release : For modules produced by the same company (or collaborating companies).
- latest.integration : For modules produced by other teams within the same project
The point here is managing change. Dynamic revisions are only used for internal dependencies and only closing collaborating teams can react quickly enough to build failures introduced by development builds.
For 3rd party open source dependencies I recommend setting the explicit version and periodically review them for upgrade.
Finally, if you have concerns about how to reproduce older builds an available solution is to commit a copy of the resolved ivy.xml when cutting the release. The ivy deliver task can do this.
<ivy:deliver deliverpattern="ivy-resolved.xml" pubrevision="${version}" status="release"/>
And don't forget that if you publish a module into your ivy repository, a copy of the resolved ivy file will be there as well.
Because of your last remark, you shouldn't be using latest.integration.
IMHO, the latest concept is particularly useful between projects in the same repositories, where you expect to clone/checkout them together.
I am using version numbers dependency in a case similar to yours. You could update the version number automatically, nonetheless.
you could create a script that (not my favorite):
1) builds the LIBPROJ libraries
2) then checkout the main and modifies the its dependency versions.
I, however, didn't encourage this when introducing IVY to my fellow colleagues. When you want a new version of LIBPROJ then create it and push it with a clear release.
Then change the dependency file in your MAIN.
1) It won't bloat of binaries.
2) creates sense of Tracking for which version is being used now.
3) Versioning.
