That would explain it; if it is checking that the modules build.xml file is newer than the Eclipse project files then only the common module would have prompted such a regeneration because its the only module level build.xml file that got updated by the Ivy related changes(that I can recall).
On 13 May 2012 16:05, Weston M. Price <[email protected]> wrote: > My bad, it appears there is a flag in common.xml that controls whether or not > to update the files. Not sure why it worked for common and not for client, > but flipping that flag and running the task again produced the correct > results. > > Regards, > > Weston > On May 13, 2012, at 10:44 AM, Weston M. Price 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]
