> 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. 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 >>>> >>
