ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: [ANNOUNCE] Apache IvyDE 2.0.0-final released
Date Thu, 16 Jul 2009 22:08:35 GMT
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 project
would have to be open in Eclipse for the workspace resolve to work?

2009/7/15 Nicolas Lalevée <nicolas.lalevee@hibnet.org>

>
>
> On Tue, 14 Jul 2009 20:54:22 -0700, Mitch Gitman <mgitman@gmail.com>
> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message