On May 7, 2012, at 8:05 AM, Robbie Gemmell wrote: > 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. > Excellent stuff. Thanks Robbie.
Weston > Robbie > > On 3 May 2012 15:42, Robbie Gemmell <[email protected]> wrote: >> 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
