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
