Do you mean ones you created ' yourself ', or ones generated with the Ant Eclipse target Keith added to the build?
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. 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. 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]
