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 :) > 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]
