Two things:
- The current build is already able to build offline as soon as you have at
least done one build online before
- For the refactoring, it's only a vague idea now, the main purpose of the
refactoring is to clean code to make it easier for new people to get
involved. So I plan to focus on the classes which are the more obscure for
the moment, like the Ivy and IvyNode classes. I think it will be hard to get
help on this at least at the beginning.
Xavier
On 12/24/06, Eric Crahen <[EMAIL PROTECTED]> wrote:
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
