ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: [ANNOUNCE] Apache IvyDE 2.0.0-final released
Date Fri, 17 Jul 2009 09:17:20 GMT

On Thu, 16 Jul 2009 15:08:35 -0700, Mitch Gitman <> wrote:
> Nicolas, thanks for your detailed response. Few quick follow-up
> questions...
> What is IvyDE's repository? Or maybe I should ask, where is it? Or should
> I
> even care?
> I know it's easy enough for me to verify this myself, but sometimes I
> don't
> trust my own eyes. Am I correct in supposing that the superlibrary
> would have to be open in Eclipse for the workspace resolve to work?


Technically (regarding the Java API of Ivy used by IvyDE), there is no
repository, just a resolver. But we can make the analogy. The repository of
IvyDE would be the set of opened Java project in your Eclipse workspace
which have an IvyDE classpath container configured (only having an ivy.xml
file is not sufficient).


> 2009/7/15 Nicolas Lalevée <>
>> On Tue, 14 Jul 2009 20:54:22 -0700, Mitch Gitman <>
>> wrote:
>> > I'm trying to understand the use case for the "Resolve in workspace"
>> > feature. Let me take a guess at a use case and illustrate what I do
> now
>> > without this feature, and perhaps Nicolas or someone else can fill in
> how
>> > this feature could be an alternative, or whether I'm completely
>> off-track.
>> >
>> > Let's say I have two projects that correspond to Ivy modules:
>> >
>> >    - superlibrary
>> >    - superwebapp: has an Ivy dependency on superlibrary
>> >
>> > And let's say I'm working on both projects within Eclipse. I want
>> > superwebapp to pick up the changes I'm making to superlibrary without
> my
>> > having to republish superlibrary to the Ivy repository. With
> superwebapp
>> > selected in Eclipse, I would go to Project-->Properties-->Java Build
>> > Path-->Projects tab, hit the Add button, and select superlibrary. Then
> I
>> > would go to the Order and Export tab and make sure that superlibrary
>> > appears
>> > above the IvyDE classpath container.
>> >
>> > Is the "Resolve in workspace" feature intended to provide an
> alternative
>> > to
>> > this procedure, or is there another use case? When it comes to IvyDE's
>> > involvement, what value is there in the superwebapp Eclipse project
>> > knowing
>> > about superlibrary being there in the Eclipse workspace as opposed to
>> just
>> > knowing about superlibrary through IvyDE's being able to locate the
> Ivy
>> > dependency in the repository?
>> As the superwebapp has a dependency on superlibrary, the resolve process
> is
>> extected to find an artifact of superlibrary in some repository. If you
> use
>> the workspace resolver, the superlibrary don't have to be resolved in a
>> real repository as it will be find in IvyDE's one. So you don't have to
> do
>> any publication of superlibrary before starting to resolve correctly
>> superwebapp. This is especially true for new projects.
>> Another thing in the setup you are suggesting is that the classpath in
> your
>> superwebapp will have a duplicate entry of superlibrary, the resolved
> jar
>> and the project. So as you described you will have to be careful about
>> ordering the classpath.
>> Last but not least, in the resolve process you are using, the ivy.xml of
>> superlibrary used in the resolve process of superwebapp is the last one
> you
>> published in a repository. The workspace resolver is using the one in
> your
>> workspace. So if you update a dependency of superlibrary, it won't be
>> visible to superwebapp unless you republish superlibrary, or unless you
> use
>> the workspace resolver ;)
>> So the resolve in workspace feature is not far from the setup you are
>> using, it is more automatic and less error prone.
>> Nicolas

View raw message