ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Open source ivy files project?
Date Wed, 16 Apr 2008 16:25:42 GMT
On Wed, Apr 16, 2008 at 4:29 PM, Archie Cobbs <> wrote:

> On Wed, Apr 16, 2008 at 1:38 AM, Xavier Hanin <>
> wrote:
> >  The link gives a 404, so I can only say what I think of the patch you
> > attached in your last e-mail. IMO, the patch quality is good overall.
> The patch has been updated a few times since I sent that email. New patch
> is
> here<
> view
> directly<
> >in
> SVN browser).
> > think it still requires some more test (I don't think there's a test of
> > m2resource for instance), and also some more comments in the code: I
> know
> > Ivy code itself is not a very good example, but including code means
> > maintaining it, and some more comments, especially in the xslt, may
> help.
> >
> I will add a m2resource access to the unit test and more code comments and
> update the patch.
> Besides the code quality, we need to evaluate the usefulness for the
> > community. ATM, even though I like the idea, it seems the number of
> people
> > interested is still low. Moreover, this resolver could be provided as a
> > plugin, and as such don't really *require* to be included in Ivy core.
> So
> > maybe you could start by providing it as an easy to use plugin, then
> we'd
> > integrate it in Ivy core once the community interest will be large
> enough.
> > We can still add a link or two in the official documentation (in the
> > resolvers and links page for instance) to favor the adoption. OTOH, I
> > encourage you to ping the ivy user mailing list about this project, you
> > can
> > even do it once a month to report progress and encourage people to join.
> > Blogging and announcing is also a good way to get traffic and raise a
> > community.
> I'd ask that you please reconsider this recommendation.

I'm widely open to reconsider this, but I'd like to get more people give
their opinion.

I think the new
> resolver is generically useful. Initial feedback on the ivy users list has
> been encouraging. Including this in 2.0 would be a new feature addition
> that
> people would appreciate and help show Ivy development and innovation is
> alive.
> Moreover, nobody is going to bother to download a separate plugin. Making
> this a plugin is equivalent to killing the idea. We want to encourage
> people
> to use Ivy, in whatever ways they want... not make it hard to do so.

IMO if the resolver is really useful, people will download it, especially if
you provide simple installation instructions. What would really change the
usage is if it were the default public resolver. Maybe one day, if the
repository gets larger than maven 2 repo... I really hope so!


> The builder resolver is generic and not at all tied to the RoundUp
> project,
> which is entirely separate. Contrast with the ivyrep resolver (which is
> included in Ivy) which although now deprecated was originally tied to a
> specific repository.
> Also, I've included unit tests, complete
> documentation<
> >,
> the code passes checkstyle, etc. I am already an Apache committer (from
> early Harmony project days) and am willing to maintain this little piece
> of
> the project.
> In short, if you think this is a good idea overall, I don't see what
> downside there is to going ahead and including it in Ivy now. The
> potential
> upside, however seems very positive. We need a well-organized community
> repository!
> > As I said in my previous e-mail I think better name consistency would
> > really
> > help. I don't have enough time to get actively involved ATM, but I'd be
> > happy to at least share my ideas, so ping me if you create a dedicated
> > mailing list (you can also use ivy user list at the beginning).
> >
> Thanks. Please consider adding to the RoundUp wiki site, especially the
> ModuleMaintainerGuidelines<
> your experience would be very valuable here.
> I will work on setting up a mailing list too.
> Thanks,
> -Archie
> --
> Archie L. Cobbs

Xavier Hanin - Independent Java Consultant

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