I have had a further play, and updated the build to pull down ivy and the dependencies automatically, with support for selecting between using a maven2 repo (defaulting to central, url configurable) or a flat directory of jars on the filesystem (defaulted to qpid/java/localfs_repo but is configurable). It defaults to the maven repo unless overriden with -Divy.default.resolver=localfs in which case it wont touch the maven repo.
Initial attempt available for preview at: http://svn.apache.org/repos/asf/qpid/branches/dep_removal/ I have some further tweaks to make around cache dirs and retrieval of optional dependencies, but whats there now is basically ready to go so check it out. I plan to put it on trunk tomorrow. Robbie On 3 May 2012 15:42, Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > On 3 May 2012 15:35, Rob Godfrey <rob.j.godf...@gmail.com> wrote: >> On 3 May 2012 16:20, Robbie Gemmell <robbie.gemm...@gmail.com> wrote: >>> Hi everyone, >>> >>> I took a tiny little look at using Ivy for dependencies last night in >>> order to allow removing dependencies in the Java tree from the repo. I >>> have thought we should do this for a long time, and I'm sure most of >>> the people who come across our source think the same. >>> >>> Having Ivy just download the dependencies (whilst being driven by Ant) >>> and then using our existing Ant build otherwise unchanged is very >>> easy, so I think that even if we don't spend any time improving >>> anything else we should at least do that for the jars it is easily >>> possible to. >>> >>> I would like to propose that we make this improvement, and wondered >>> what others think? If noone objects I would like to make it happen >>> sometime next week. >>> >> >> I'm very much in favour of removing the need to keep copies of the >> jars in our subversion. >> >> A couple of quick questions... >> >> will we be adding a way to get ivy to only check a local directory for >> the required Jars? I believe this is possible, and by doing so we >> should be alleviate any concerns that people might have about >> downloading dependencies from the internet (in this way people could >> maintain their local directory - possibly checked in to their own >> subversion), and point the build at this when they wish to assemble >> their builds? >> > > I believe so, yes. We can add an ivysettings.xml file to allow > overriding the default search locations and enable specifying > alternative sources, e.g. a corporations internal repository mirrors > or a local file based repository. > >> Second, and somewhat related - is there an easy way (my brief reading >> of ivy documentation made me think there was) of specifying the >> dependencies such that transitive dependencies are not automatically >> resolved? I'm not sure if we wish to configure that by default, but >> that would be the closest to what we have now. > > From my reading last night I believe I remember seeing an option to do > that, yes. > >> >> I'll be really glad to remove the need to have all the jars checked in >> to every branch if we can assure ourselves that we can get the same >> level of control of which Jars are included in the build. >> >> Cheers, >> Rob >> >>> >>> As a test of this, I made a quick change (snippet below) to our >>> existing ivy.xml file (currently used for deploying maven artifacts >>> for our releases, in concert with the upload.xml build file) that >>> would have it grab a couple of our existing dependencies (jars only, >>> and excluding a sub dependency we already have a different version of) >>> using some new targets in the build.xml file which I ripped almost >>> entirely from the existing upload.xml stuff. >>> >>> - <dependencies/> >>> + <dependencies> >>> + <dependency org="commons-lang" name="commons-lang" rev="2.2"> >>> + <include type="jar"/> >>> + </dependency> >>> + <dependency org="commons-cli" name="commons-cli" rev="1.0"> >>> + <include type="jar"/> >>> + <exclude name="commons-logging"/> >>> + </dependency> >>> + </dependencies> >>> >>> This allowed me to remove those 2 dependency jars from the lib dir, >>> and made the process of gathering the dependencies and running the >>> build as follows: >>> 1. Run 'ant download-ivy' (necessary if you don’t have Ivy installed >>> in one of Ant's supported lib areas already). >>> 2. Run 'ant resolve' and find that the jars are eventually present in >>> the lib dir again. >>> 3. Run whichever build command you would normally. >>> >>> (combining all 3 into 'ant download-ivy resolve <normal commands>' >>> would also work, but steps 1 and 2 could just be transparently >>> incorporated into the standard build sequence if desired). >>> >>> Robbie >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org >>> For additional commands, e-mail: dev-h...@qpid.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org >> For additional commands, e-mail: dev-h...@qpid.apache.org >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
