> 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
<nicolas.lale...@hibnet.org> wrote:
> Maybe there are some transitive dependency which confuse the Workspace
> resolver. See at the end of the doc:
> http://ant.apache.org/ivy/ivyde/history/latest-milestone/cpc/workspace.html
>
>> In some setup, if you want to mix some resolver of your own and the
>> workspace resolver, and still want the transitive dependencies work nicely
>> between them, you may want to turn the resolve mode to dynamic:
>> • see the defaultResolveMode attribute of settings in the ivysettings.
>> • see the resolveMode attribute of module in the ivysettings.
>
> Nicolas
>
> Le 14 mai 2012 à 20:36, Matt Hurne a écrit :
>
>> On Mon, May 14, 2012 at 2:31 PM, Matt Hurne <m...@thehurnes.com> wrote:
>>> We are using Ivy to manage the dependencies of our projects on each
>>> other, and we're planning to use IvyDE as well. One of the resolvers
>>> we have in our Ivy configuration is used to publish our build
>>> artifacts to a local repository (with status "integration") so that
>>> they are available when building the projects that depend on them. In
>>> a clean environment, this repository is initially empty. If the local
>>> repository is empty and we configure IvyDE to resolve dependencies in
>>> the workspace, the projects do end up in the Ivy classpath containers
>>> of the projects that depend on them as expected. However, if we then
>>> build and publish the projects to the local repository and then
>>> perform a new resolve-all in Eclipse/IvyDE, the projects are removed
>>> from the Ivy classpath containers and the artifacts in the local
>>> repository take their places.
>>>
>>> Is this behavior expected/correct? Is there a way to ensure that
>>> IvyDE will always put workspace projects in the classpath container
>>> rather than artifacts with identical module revision IDs that exist in
>>> one of our configured repositories?
>>>
>>> If I were dealing with this type of scenario outside of Eclipse/IvyDE,
>>> I would look at putting the resolvers into a chain and using the
>>> "returnFirst" attribute to enforce a specific order. That's
>>> effectively what I'm looking to do with the workspace resolver. Is
>>> that possible?
>>
>>
>> I should have mentioned the following details about our environment:
>>
>> Windows XP 32bit
>> Eclipse 3.7 Indigo
>> IvyDE 2.2.0.beta1 with Ivy 2.2.0 (we had some other show-stopping
>> issues when using IvyDE with Ivy 2.3.0, so we installed Ivy 2.2.0
>> explicitly)
>>
>> In addition, when building projects using Ant we're using Ivy 2.2.0.
>>
>> Thanks,
>> Matt Hurne
>
