On 3 May 2012 15:35, Rob Godfrey <[email protected]> wrote: > On 3 May 2012 16:20, Robbie Gemmell <[email protected]> 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: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
