Le 15 mai 2012 à 19:40, Matt Hurne a écrit : >> Ok, that makes some sense. After adding resolveMode="dynamic" to my >> <settings>, I do see that the <dependency> elements of the delivered >> ivy files include a resolved rev attribute as well as a revConstraint >> attribute, such as: >> >> <dependency org="com.acme" name="thingamajig" rev="20120515131106" >> revConstraint="latest.integration" conf="default->default"/> > > Not that it helps me much, but I should clarify that the <dependency> > elements in the delivered Ivy files look the same regardless of the > resolve mode configured; the revConstraint is included with a value of > "latest.integration" either way. So it's my understanding that the > resolve mode doesn't have a direct effect on the delivered Ivy files, > but rather which of the revision-related attributes in those delivered > Ivy files is used in future resolves.
exactly. Nicolas > > Matt Hurne > > > On Tue, May 15, 2012 at 1:26 PM, Matt Hurne <m...@thehurnes.com> wrote: >>> Have you tried to set it on the "settings" element in the ivysettings ? >> >> I hadn't before, but just did: >> >> <settings defaultResolver="default-chain" defaultResolveMode="dynamic" >> defaultConflictManager="latest-revision" >> circularDependencyStrategy="error" /> >> >> Unfortunately this did not solve the problem for me. IvyDE was able >> to resolve projects in the workspace prior to any of them being built >> and published to the local repository, but after they were built and >> published and I did a "resolve all" in Eclipse, the project references >> were replaced with the published artifacts. So this worked better >> than when I added a <modules> section to my ivysettings to set the >> resolve mode, but no better than if I just left the resolve mode as >> the default across the board. >> >> >>> When you publish your artifacts into your local repository, Ivy does a >>> "deliver" of the ivy.xml of your project. If there is any range version in >>> your dependencies, Ivy fix them as the one resolved during the build. So >>> the next time a resolve happens and that module is found in you repository, >>> Ivy will resolved the previously-resolved revision, the fixed one, not the >>> original range version. Setting the resolve mode to dynamic change this >>> behavior; it will use the range rather than the resolved version. Look at >>> your ivy.xml in the local repository, you'll see some extra attributes in >>> your dependency, if you have any range version. >> >> Ok, that makes some sense. After adding resolveMode="dynamic" to my >> <settings>, I do see that the <dependency> elements of the delivered >> ivy files include a resolved rev attribute as well as a revConstraint >> attribute, such as: >> >> <dependency org="com.acme" name="thingamajig" rev="20120515131106" >> revConstraint="latest.integration" conf="default->default"/> >> >> Note that we are not specifying revisions in our modules' ivy files at >> the moment, so Ivy appears to set the revision to the publication data >> and time when delivering each Ivy file. For example: >> >> <info organisation="com.acme" module="thingy" >> revision="20120515131237" status="integration" >> publication="20120515131237"> >> >> Not sure where to go from here. Do you have any additional thoughts? >> Thanks for your time thus far! >> >> Matt H >> >> >> On Tue, May 15, 2012 at 5:01 AM, Nicolas Lalevée >> <nicolas.lale...@hibnet.org> wrote: >>> >>> Le 14 mai 2012 à 22:38, Matt Hurne a écrit : >>> >>>>> Maybe there are some transitive dependency which confuse the Workspace >>>>> resolver. See at the end of the doc: >>>>> http://ant.apache.org/ivy/ivyde/history/latest-milestone/cpc/workspace.html >>>>> >>>>>> In some setup, if you want to mix some resolver of your own and the >>>>>> workspace resolver, and still want the transitive dependencies work >>>>>> nicely between them, you may want to turn the resolve mode to dynamic: >>>>>> • see the defaultResolveMode attribute of settings in the >>>>>> ivysettings. >>>>>> • see the resolveMode attribute of module in the ivysettings. >>>> >>>> Yes, I had seen that before sending my original note to the list since >>>> it did seem relevant. I added a <modules> element to the >>>> ivysettings.xml like: >>>> >>>> <modules> >>>> <module organisation="com.company" name="*" resolveMode="dynamic"/> >>>> </modules> >>>> >>>> After doing so, IvyDE seemed unable to resolve a given project's >>>> dependencies at all, including projects in the workspace, even with an >>>> empty local repository. I'm not sure what to make of that; >>> >>> I don't either. Have you tried to set it on the "settings" element in the >>> ivysettings ? >>> >>>> to be >>>> honest, I don't really understand what difference it should have made. >>>> Any chance you can elaborate? >>> >>> When you publish your artifacts into your local repository, Ivy does a >>> "deliver" of the ivy.xml of your project. If there is any range version in >>> your dependencies, Ivy fix them as the one resolved during the build. So >>> the next time a resolve happens and that module is found in you repository, >>> Ivy will resolved the previously-resolved revision, the fixed one, not the >>> original range version. Setting the resolve mode to dynamic change this >>> behavior; it will use the range rather than the resolved version. Look at >>> your ivy.xml in the local repository, you'll see some extra attributes in >>> your dependency, if you have any range version. >>> >>> Nicolas >>> >>>> >>>> Thanks, >>>> Matt Hurne >>>> >>>> >>>> On Mon, May 14, 2012 at 4:28 PM, Nicolas Lalevée >>>> <nicolas.lale...@hibnet.org> wrote: >>>>> Maybe there are some transitive dependency which confuse the Workspace >>>>> resolver. See at the end of the doc: >>>>> http://ant.apache.org/ivy/ivyde/history/latest-milestone/cpc/workspace.html >>>>> >>>>>> In some setup, if you want to mix some resolver of your own and the >>>>>> workspace resolver, and still want the transitive dependencies work >>>>>> nicely between them, you may want to turn the resolve mode to dynamic: >>>>>> • see the defaultResolveMode attribute of settings in the >>>>>> ivysettings. >>>>>> • see the resolveMode attribute of module in the ivysettings. >>>>> >>>>> Nicolas >>>>> >>>>> Le 14 mai 2012 à 20:36, Matt Hurne a écrit : >>>>> >>>>>> On Mon, May 14, 2012 at 2:31 PM, Matt Hurne <m...@thehurnes.com> wrote: >>>>>>> We are using Ivy to manage the dependencies of our projects on each >>>>>>> other, and we're planning to use IvyDE as well. One of the resolvers >>>>>>> we have in our Ivy configuration is used to publish our build >>>>>>> artifacts to a local repository (with status "integration") so that >>>>>>> they are available when building the projects that depend on them. In >>>>>>> a clean environment, this repository is initially empty. If the local >>>>>>> repository is empty and we configure IvyDE to resolve dependencies in >>>>>>> the workspace, the projects do end up in the Ivy classpath containers >>>>>>> of the projects that depend on them as expected. However, if we then >>>>>>> build and publish the projects to the local repository and then >>>>>>> perform a new resolve-all in Eclipse/IvyDE, the projects are removed >>>>>>> from the Ivy classpath containers and the artifacts in the local >>>>>>> repository take their places. >>>>>>> >>>>>>> Is this behavior expected/correct? Is there a way to ensure that >>>>>>> IvyDE will always put workspace projects in the classpath container >>>>>>> rather than artifacts with identical module revision IDs that exist in >>>>>>> one of our configured repositories? >>>>>>> >>>>>>> If I were dealing with this type of scenario outside of Eclipse/IvyDE, >>>>>>> I would look at putting the resolvers into a chain and using the >>>>>>> "returnFirst" attribute to enforce a specific order. That's >>>>>>> effectively what I'm looking to do with the workspace resolver. Is >>>>>>> that possible? >>>>>> >>>>>> >>>>>> I should have mentioned the following details about our environment: >>>>>> >>>>>> Windows XP 32bit >>>>>> Eclipse 3.7 Indigo >>>>>> IvyDE 2.2.0.beta1 with Ivy 2.2.0 (we had some other show-stopping >>>>>> issues when using IvyDE with Ivy 2.3.0, so we installed Ivy 2.2.0 >>>>>> explicitly) >>>>>> >>>>>> In addition, when building projects using Ant we're using Ivy 2.2.0. >>>>>> >>>>>> Thanks, >>>>>> Matt Hurne >>>>> >>>
