ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hurne <>
Subject Re: IvyDE seems to prefer artifacts in non-workspace-resolver over projects present in workspace
Date Mon, 14 May 2012 18:36:17 GMT
On Mon, May 14, 2012 at 2:31 PM, Matt Hurne <> 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

In addition, when building projects using Ant we're using Ivy 2.2.0.

Matt Hurne

View raw message