On May 13, 2012, at 11:17 AM, Robbie Gemmell wrote: > On 13 May 2012 16:08, Weston M. Price <[email protected]> wrote: >> >> On May 13, 2012, at 11:05 AM, Robbie Gemmell wrote: >> >>> Do you mean ones you created ' yourself ', or ones generated with the >>> Ant Eclipse target Keith added to the build? >> The Ant Eclipse target. >>> >>> Either way, I should have actually thought to email about this, oops. >>> In order to allow Ivy to fully manage the contents of the directory >>> itself (letting it clean up whenever we change a dependency, for >>> example) the libs have now moved to a subdirectory, specifically from >>> qpid/java/lib to qpid/java/lib/required. As a result, you will need to >>> update your IDEs to provide the new locations. >>> >> Yep, see my previous mail. By default, I guess these files aren't >> automatically updated. You would think the Ant Eclipse tasks would have been >> able to detect a fundamental change like the introduction of Ivy and the >> library dependencies but, I guess not. >> > > I think its due to how it checks if it needs to update or not. I'm > think a little commit should take care of that for people using this > (basically nudging the build.xml files enough to update them). > >>> I dont use the Ant Eclipse project generation, but it didnt actually >>> occur to me to check that it still worked either..I'll do that now. >>> >> I usually don't, but I was interested in what it actually did and the output >> it produced. Seems to be fairly useful once the files are generated >> correctly. >> > > It is definitely useful if it matches your project layout preferences, > but I'm awkward :) LOL. One of the most useful parts of it would be in order to get the debugger up and running quickly which is about the only time I really use Eclipse anyway.
Regards, Weston >> Regards, >> >> Weston >>> Robbie. >>> >>> On 13 May 2012 15:44, Weston M. Price <[email protected]> wrote: >>>> One thing I did notice, once this change went in, a few of the java >>>> projects, client especially, don't seem to see the updated dependency >>>> location in the Eclipse .classpath files. The common project seems ok, but >>>> client does not. >>>> >>>> Regards, >>>> >>>> Weston >>>> On May 7, 2012, at 8:33 AM, Weston M. Price wrote: >>>> >>>>> >>>>> 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] >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
