You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Matt Hurne <ma...@thehurnes.com> on 2012/05/14 20:31:55 UTC
IvyDE seems to prefer artifacts in non-workspace-resolver over
projects present in workspace
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?
Thanks,
Matt Hurne
Re: IvyDE seems to prefer artifacts in non-workspace-resolver over projects present in workspace
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 15 mai 2012 à 19:40, Matt Hurne a écrit :
>> 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.
exactly.
Nicolas
>
> Matt Hurne
>
>
> On Tue, May 15, 2012 at 1:26 PM, Matt Hurne <ma...@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
>> <ni...@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
>>>> <ni...@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 <ma...@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
>>>>>
>>>
Re: IvyDE seems to prefer artifacts in non-workspace-resolver over projects present in workspace
Posted by Nicolas Lalevée <ni...@hibnet.org>.
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
> <ni...@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 <ma...@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
>>>> <ni...@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 <ma...@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 <ma...@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
>>>>>>>> <ni...@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
>>>>>>>>>> <ni...@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 <ma...@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
>>>>>>>>>>>
>>>>>>>>>
>>>>>
>>
Re: IvyDE seems to prefer artifacts in non-workspace-resolver over
projects present in workspace
Posted by Matt Hurne <ma...@thehurnes.com>.
>> 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,
Matt Hurne
On Tue, May 15, 2012 at 7:32 PM, Nicolas Lalevée
<ni...@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 <ma...@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
>>> <ni...@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 <ma...@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 <ma...@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
>>>>>>> <ni...@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
>>>>>>>>> <ni...@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 <ma...@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
>>>>>>>>>>
>>>>>>>>
>>>>
>
Re: IvyDE seems to prefer artifacts in non-workspace-resolver over projects present in workspace
Posted by Nicolas Lalevée <ni...@hibnet.org>.
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 <ma...@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
>> <ni...@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 <ma...@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 <ma...@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
>>>>>> <ni...@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
>>>>>>>> <ni...@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 <ma...@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
>>>>>>>>>
>>>>>>>
>>>
Re: IvyDE seems to prefer artifacts in non-workspace-resolver over
projects present in workspace
Posted by Matt Hurne <ma...@thehurnes.com>.
>> 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'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!
Thanks,
Matt Hurne
On Tue, May 15, 2012 at 4:19 PM, Matt Hurne <ma...@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
> <ni...@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 <ma...@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 <ma...@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
>>>>> <ni...@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
>>>>>>> <ni...@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 <ma...@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
>>>>>>>>
>>>>>>
>>
Re: IvyDE seems to prefer artifacts in non-workspace-resolver over
projects present in workspace
Posted by Matt Hurne <ma...@thehurnes.com>.
> 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
<ni...@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 <ma...@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 <ma...@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
>>>> <ni...@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
>>>>>> <ni...@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 <ma...@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
>>>>>>>
>>>>>
>
Re: IvyDE seems to prefer artifacts in non-workspace-resolver over projects present in workspace
Posted by Nicolas Lalevée <ni...@hibnet.org>.
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 <ma...@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 <ma...@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
>>> <ni...@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
>>>>> <ni...@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 <ma...@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
>>>>>>
>>>>
Re: IvyDE seems to prefer artifacts in non-workspace-resolver over
projects present in workspace
Posted by Matt Hurne <ma...@thehurnes.com>.
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?
Thanks,
Matt Hurne
On Tue, May 15, 2012 at 1:40 PM, Matt Hurne <ma...@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 <ma...@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
>> <ni...@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
>>>> <ni...@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 <ma...@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
>>>>>
>>>
Re: IvyDE seems to prefer artifacts in non-workspace-resolver over
projects present in workspace
Posted by Matt Hurne <ma...@thehurnes.com>.
> 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 <ma...@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
> <ni...@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
>>> <ni...@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 <ma...@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
>>>>
>>
Re: IvyDE seems to prefer artifacts in non-workspace-resolver over
projects present in workspace
Posted by Matt Hurne <ma...@thehurnes.com>.
> 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
<ni...@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
>> <ni...@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 <ma...@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
>>>
>
Re: IvyDE seems to prefer artifacts in non-workspace-resolver over projects present in workspace
Posted by Nicolas Lalevée <ni...@hibnet.org>.
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
> <ni...@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 <ma...@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
>>
Re: IvyDE seems to prefer artifacts in non-workspace-resolver over
projects present in workspace
Posted by Matt Hurne <ma...@thehurnes.com>.
> 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; to be
honest, I don't really understand what difference it should have made.
Any chance you can elaborate?
Thanks,
Matt Hurne
On Mon, May 14, 2012 at 4:28 PM, Nicolas Lalevée
<ni...@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 <ma...@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
>
Re: IvyDE seems to prefer artifacts in non-workspace-resolver over projects present in workspace
Posted by Nicolas Lalevée <ni...@hibnet.org>.
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 <ma...@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
Re: IvyDE seems to prefer artifacts in non-workspace-resolver over
projects present in workspace
Posted by Matt Hurne <ma...@thehurnes.com>.
On Mon, May 14, 2012 at 2:31 PM, Matt Hurne <ma...@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