Le 15 mai 2012 à 22:55, Matt Hurne a écrit :
>>> 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?
>
> Further reading and looking at the commit (revision 688097) that
> introduced the current line that calls isReturnFirst() leads me to
> believe that the idea is this: if the module found first in the chain
> should be returned, forcedRevision() is called to set a flag on the
> ResolvedModuleRevision called "force". Then when subsequent resolvers
> are called, they are passed the previously resolved
> ResolvedModuleRevision. It is apparently their responsibility to
> inspect the "force" flag on that revision, and if it is true, *not*
> resolve the module themselves, but rather return the previously
> resolved module instead. So it's not nearly as straightforward as I
> had originally expected (is it ever?!).
I have understood the rationale.
> I'll need to step through the code again, and pay more attention to
> what each resolver in the chain is doing. I'll have to pick this back
> up tomorrow. I'll let you know what I find!
If you could share a little bit more of your project configuration, I could try
to look into it too. Mailing lists are generally not appropriate to share
files, so if you want to share some, you are welcomed to open a Jira issue.
Nicolas
>
> Thanks,
> Matt Hurne
>
>
> On Tue, May 15, 2012 at 4:19 PM, Matt Hurne <m...@thehurnes.com> wrote:
>>> 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
>>>>>>>>>
>>>>>>>
>>>
