There are many ways to use Ivy and I may not be following best practices, but I think my method fits with the way my company works better. We have two repositories, daily and releases. daily contains the continuous and nightly builds while releases contains the released versions of all the modules. The daily repository is cleaned of any builds older than 1 week while the releases repo is never cleaned. This make it easy to determine what can be deleted to save disk space and what should not. I have a chain resolver that firsts looks for a user's local repo, then the daily, and then the releases. This would allow a patch release to only include a small portion of the modules that was originally released. The modules that are part of the patch would be built and stored in the daily repo, while everything else would come from the releases repo.
When I say "copy a complete dependency hierarchy", I am not saying to copy all versions of all configurations of all modules, which would be a complete copy. I could do that with cp -r. I only want the released versions of the modules, so it is a selective copy. Therefore, it is not unmaintainable. After all, we need to keep our release builds somewhere. Yes, we do have tags in the source code so we could reproduce them if need be, but it is more efficient to keep the release builds of everything to use as dependencies for patches as described above. --- Shawn Castrianni -----Original Message----- From: Mitch Gitman [mailto:[EMAIL PROTECTED] Sent: Saturday, October 25, 2008 11:29 AM To: [email protected] Subject: Re: copying a complete dependency hierarchy Shawn, at the risk of not addressing your immediate question, I would take a step back and ask whether you're really doing the right thing by doing an ivy:install on a release. What an ivy:install gives you is a whole other Ivy repository. Every time you do another install, you wind up with another enterprise repository. Not only does that verge on the unmaintainable, but you would probably find that the different repositories don't differ from each other by much. I believe the better way to lock down the dependencies on a release is to do so with the versions themselves, in combination with the branching provided by a version control system. Look at the "Dealing with integration versions" section of the "Best Practices" page: http://ant.apache.org/ivy/history/trunk/bestpractices.html That page presents two ways of dealing with ever-changing in-house dependencies. You could express integration dependencies using the changing attribute, much like Maven snapshots: <dependency org="exemplar" name="configuration" rev="2.3" changing="true" /> Or you could express integration dependencies by giving each one its own integration version: <dependency org="exemplar" name="configuration" rev="2.3.+" /> Once you're ready to do a release, you could create a release branch in your version control system, like Subversion. At this point, you would establish your concrete dependencies. For changing integration versions, this might look like: <dependency org="exemplar" name="configuration" rev="2.3.0" /> For integration versions that each get their own version, this might look like (where 59 is the arbitrary build you end up using): <dependency org="exemplar" name="configuration" rev="2.3.59.0" /> Note in each case that the depth of the version numbers extends one level. From 2.3 to 2.3.0; from 2.3.+ 2.3.59.0. One complication of this approach is that you wind up having to branch recursively down the dependency tree through all your in-house projects that constitute a release. On Fri, Oct 24, 2008 at 5:43 PM, Shawn Castrianni < [EMAIL PROTECTED]> wrote: > After we release, I would like to copy the entire dependency hierarchy (all > configurations of all modules) for the version that we actually released. I > tried using the install task by changing to the highest module in the > hierarchy and ran the install task specifying the version of that highest > level module that we released. This almost worked in that the > corresponding transitive dependencies were copied to my destination. > However, my top level module only has a subset of the configurations such > that it only grabs the corresponding subset of configurations for all > transitive modules. How can I get all configurations of all modules copied > over? > > --- > Shawn Castrianni > > ---------------------------------------------------------------------- > This e-mail, including any attached files, may contain confidential and > privileged information for the sole use of the intended recipient. Any > review, use, distribution, or disclosure by others is strictly prohibited. > If you are not the intended recipient (or authorized to receive information > for the intended recipient), please contact the sender by reply e-mail and > delete all copies of this message.
