I just read your last post more closely and this what you are already
talking about.
Do you have any specific goals for the refactoring you mentioned or is it
just like
a vague idea right now? I ask just to see if its possible for people in the
user community
to take up that work if they wanted to help move things along.
On 12/24/06, Eric Crahen <[EMAIL PROTECTED]> wrote:
I like the module idea very much. What do you think about an alternative
to the chicken and egg problem for ivy-core?
Is there a problem with distributing your dependencies as ant does?
What I mean by this is that Instead of relying on ivy directly always to
bootstrap its own dependencies it could be possible to modify the
build.xml
to first look in ${basedir}/lib for jars, test them with <available/>
tasks for
well known classes. In this way. Failing that *then* fall back on a self
bootstrap.
You could get a little fancy and attempt to use java-config if you wanted
to see if the dependency is already hanging around somewhere.
Whats nice about this is that you can have a way to work locally and not
deal with downloading anything. I can get all my stuff together, get on a
plane
and build from scratch w/ no network.
Or, this one would take more work, but the
bootstrap would be two stage. The first stage of the bootstrap could put
together a crude url resolver that uses only standard JRE stuff, just
enough
to contact the hand full of hosts to get the dependencies it needs. Its
like a
minimal, feature anemic Ivy. It uses this to fetch its full dependencies
and
then builds the rest of itself as a second stage.
Perhaps a combination of these two, when the minimal client fetches things
it stores them in ${basedir}/lib and tries to use those before it hits the
network.
Enabling people to build Ivy w/o a network connection.
This is nice because it lets you have the flexibility of #1. and you get
to keep
the purist approach of distributing only your code and fetching the
dependencies
from elsewhere.
If there is no license issue, the easiest thing to do might be to just
include the libraries
you need in the source tar balls.
On 12/23/06, Xavier Hanin <[EMAIL PROTECTED]> wrote:
>
> On 12/22/06, Maarten Coene <[EMAIL PROTECTED]> wrote:
> >
> > Or we could try the following:
> >
> > devide ivy into different parts:
> > - ivy-core: the core of ivy which uses standard JDK classes only (I'm
> not
> > sure this is possible at the moment)
> > - ivy-ant: the ant tasks
> > - ivy-ext: the extra functionality of ivy (like the different
> resolvers,
> > ...) which requires third-party libraries
> >
> > The ant build.xml can now compile 'ivy-core' and 'ivy-ant' without any
> > problem, because these parts don't need extra dependencies to be
> downloaded.
> > After the ivy-core and ivy-ant parts are compiled, they can be used to
>
> > download the dependencies of the ivy-ext part.
> >
> > This has the additional advantage that for building at least the
> > 'ivy-core' and 'ivy-ant' package, you don't have to be online
>
>
> The idea is very interesting, even if it's not straightforward to do,
> because for the moment Ivy core has build time dependencies on third
> party
> libraries like commons httpclient. But this could give a good direction
> to
> the refactoring I plan to do when I'll have more time (that is, when doc
> will be migrated, patches integrated, packages renamed, and other stuff
> I
> have to do like move IvyDE and IvyCruise to a new place (more about that
> in
> another mail).
>
> The only problem I see with this approach is that if you have a bug in
> the
> core, you may not be able to use the just built core to resolve your
> dependencies. So we have to be careful with this approach, to be able to
> use
> a downloaded core instead of a built one when necessary.
>
> Xavier
>
> Maarten
> >
> > ----- Original Message ----
> > From: Antoine Levy-Lambert <[EMAIL PROTECTED] >
> > To: [email protected]
> > Sent: Friday, December 22, 2006 2:31:42 PM
> > Subject: Re: 1.4 builds that don't depend on jayasoft.org being up?
> >
> > Hi,
> >
> > another possiblity for the old ivy releases would be to upload them to
> >
> > http://repo1.maven.org/maven/ivy/distributions
> > jars
> > poms
> >
> > This document explains how to create an upload bundle.
> > http://maven.apache.org/guides/mini/guide-ibiblio-upload.html
> >
> > It does not seem to explain how a distribution file should/could be
> > named in the upload bundle.
> >
> > The best way would be that Xavier creates the upload bundles and
> > enters a JIRA to get the old ivy versions uploaded.
> >
> > I will ask on repository@ how the distributions should be named
> > inside upload bundle jars.
> >
> > Regards,
> >
> > Antoine
> >
> >
> > On Dec 21, 2006, at 11:42 PM, Stefan Bodewig wrote:
> >
> > > On Fri, 22 Dec 2006, Antoine Levy-Lambert < [EMAIL PROTECTED]> wrote:
> > >
> > >> this should be possible.
> > >
> > > I don't think so.
> > >
> > >> the source and binary zips would go to
> > >> http://archive.apache.org/dist/ivy/
> > >
> > > And are reserved for Apache releases, which old releases of Ivy are
> > > not.
> > >
> > > Stefan
> >
> >
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
>
>
--
- Eric
--
- Eric
