Its worth noting, I didnt do anything with the dependencies for the management console. They arent quite so easy to source and we are working on replacing the console, so the approach taken for thsoe will really be to eventually remove it rather than just change where we get them.
Robbie On 7 May 2012 13:05, Robbie Gemmell <robbie.gemm...@gmail.com> 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. > > 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
