Le 16 mai 2012 à 16:44, Matt Hurne a écrit :
>>> 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.
>
> Thanks, but I've resolved the issue. The "force" attribute of the
> resolver for the local repository was given a value of "true". When
> that's the case, BasicResolver.shouldReturnResolvedModule() returns
> false, effectively overriding the ChainResolver's returnFirst="true".
> With force="false" (the default) on the local resolver, the local
> resolver returns the module resolved by the WorkspaceResolver rather
> than overriding it, and resolves with IvyDE still include the
> appropriate Eclipse workspace projects in the Ivy classpath container
> rather than the artifacts in the local repository, which is what I
> want.
Thanks for sharing back. I'll write a note in the doc about that.
Nicolas
>
> Thanks,
> Matt Hurne
>
>
> On Tue, May 15, 2012 at 7:32 PM, Nicolas Lalevée
> <nicolas.lale...@hibnet.org> wrote:
>>
>> 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
>>>>>>>>>>>
>>>>>>>>>
>>>>>
>>
