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 <[email protected]> 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 <[email protected]> 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
>>> <[email protected]> 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
>>>>> <[email protected]> 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 <[email protected]> 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
>>>>>>
>>>>
