ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hurne <m...@thehurnes.com>
Subject Re: IvyDE seems to prefer artifacts in non-workspace-resolver over projects present in workspace
Date Tue, 15 May 2012 17:40:42 GMT
> 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 <matt@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.lalevee@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.lalevee@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 <matt@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
>>>>
>>

Mime
View raw message