> Each time I read the ChainResolver I am bit confused by the "return first"
> condition, which doesn't return. I am not sure here what should be the code
> path.
Yeah...according to the documentation, once the module is found in a
given resolver in the chain resolvers that haven't yet been used
should be skipped altogether. The code doesn't seem to be written
that way; it seems to use all of the resolvers regardless of
returnFirst (in addition to seemingly returning the module found last,
not first). I feel like I must be missing something here. Am I?
> Just a hint: what happens if you remove from your ivysettings the
> defaultConflictManager ?
I just removed the defaultConflictManager from my ivysettings and went
through the clean->resolve before building and publishing->build and
publish->resolve again process, and the result is the same; after the
publish and re-resolve the workspace projects are replaced in the Ivy
classpath container by the artifacts in the repository. Isn't
latest-revision the default when the attribute is omitted anyway?
Thanks,
Matt Hurne
On Tue, May 15, 2012 at 3:02 PM, Nicolas Lalevée
<nicolas.lale...@hibnet.org> wrote:
>
> Le 15 mai 2012 à 20:51, Matt Hurne a écrit :
>
>> So I've attached a debugger and have been stepping through the
>> resolves. As far as I can see, there is a ChainResolver that includes
>> both the workspace resolver and then our default resolver (which is
>> itself a chain resolver). The workspace resolver finds the module in
>> the workspace and returns it to the ChainResolver, and then our
>> resolver also finds the module (in the repository) and returns it to
>> the ChainResolver. The ChainResolver appears to discard the module
>> resolved by the workspace resolver in favor of the module returned by
>> our resolver instead.
>>
>> Here's the relevant snippet from
>> org.apache.ivy.plugins.resolver.ChainResolver.java starting with line
>> 102 (also recall this is Ivy 2.2.0):
>>
>> ResolvedModuleRevision previouslyResolved = mr;
>> data.setCurrentResolvedModuleRevision(previouslyResolved);
>> mr = resolver.getDependency(dd, data);
>> if (mr != previouslyResolved && isReturnFirst()) {
>> mr = forcedRevision(mr);
>> }
>>
>>
>> When this code is dealing with our resolver, the first line sets
>> previouslyResolved to the module we want (the module that represents
>> the project in the workspace). The third line sets mr to the module
>> in the repository (the one we don't want). In this case, mr does not
>> equal previouslyResolved and isReturnFirst() is true. The body of the
>> if statement is executed, which just sets mr to the forcedRevision()
>> version of itself. Is that right? Shouldn't the body of the if
>> statement be:
>>
>> mr = forcedRevision(previouslyResolved); ???
>>
>> or perhaps just:
>>
>> mr = previouslyResolved; ???
>>
>>
>> I don't fully grok the purpose of forcedRevision(), so maybe that's
>> what is throwing me off?
>
> Each time I read the ChainResolver I am bit confused by the "return first"
> condition, which doesn't return. I am not sure here what should be the code
> path.
>
> Just a hint: what happens if you remove from your ivysettings the
> defaultConflictManager ?
>
> Nicolas
>
>
>>
>> Thanks,
>> Matt Hurne
>>
>>
>> On Tue, May 15, 2012 at 1:40 PM, Matt Hurne <m...@thehurnes.com> wrote:
>>>> 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
>>>>>>>
>>>>>
>
