incubator-easyant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Louis Boudart <>
Subject Re: Roadmap and priorities
Date Tue, 01 Mar 2011 22:58:55 GMT
Le 24 février 2011 15:17, Nicolas Lalevée <> a
écrit :

> > In a second time we need to discuss about our old infrastructure.
> > Should we keep our redmine instance accessible ? Should we make a
> redirect
> > to the new website ?
> I think so. So users won't see outdated doc.
Not sure i got your answer :p
I assume you mean we should make a redirect to new website, and we don't
care about archives/history, am i wrong ?

> > Should we keep our own hudson instance (pointing to Apache Incubator
> > repository) ? or should we move to Apache one ?
> I'm in favor of using the ASF one. But we could also use that one.
> By the way, who owns it ? Does it cost ?
It's hosted on my own server (we share it with a friend). Cost isn't an
issue. We can use this sever if we have hosting needs that can't be handled
by Apache.

I'm also in favor of using ASF's one.

> >
> >   - Refactoring project structure : EasyAnt project is an all in one
> >   project creating easyant-core.jar + distribution. As Nicolas pointed
> out
> >   easyant distribution comes with a third-party repository containing all
> >   librairies used by easyant or nested plugins.  Original idea behind
> this was
> >   to have everything needed in the distribution. However as we have more
> and
> >   more plugins our third party is growing and making our distribution
> > heavy.  It's
> >   probably time to build an online repository for EasyAnt. Between 0.7
> and 0.8
> >   there was around 6 month, this was mostly due to new additionnal
>  plugin
> >   (maven-publication for example). Those additionnal plugin should not
> "lock"
> >   the release. Having an online repository should allow us to make
> release of
> >   plugins independently of easyant core (except if a plugin needs to use
> a
> >   recent feature of easyant-core).
> I agree with the decoupling.
> About its implementation, we'll need to discuss how we'll actually deploy
> it. I'm not sure apache "dist" fit well for that use.
> See the apache documentation about releasing under the ASF:

I'll open a new thread on this

> >   - Plugin conflict management (EASYANT-13 on jira) : Currently, plugins
> >   are resolved on the fly based on declaration in module.ivy/module.ant.
> >   Conflict between plugins is currently managed at ant level. However
> this is
> >   a huge limitation as a user can't override the version used of a given
> >   plugin in a buildtype for example. The best solution would be to bring
> this
> >   conflict management at ivy level (at resolve time) and let ivy manage
> at
> >   least conflict of redundant plugins / dependencies.
> To do that, we may need to change the way we are managing the dependencies
> between plugins.
> More than defining plugin dependencies within build scripts, define them in
> the ivy.xml associated with the plugin. This may need a dedicated thread
> too.
Not sure this is sufficient, but let's continue this on a new thread

> >   - Support Multi language as input (Pure XML Ant, Groovy through
> >   GroovyFront, Java through JavaFront) for plugins
> Same, as soon as the phases are out, I understand there won't be a need for
> a ProjectHelper anymore. So it would then be build in :)
Can't wait see it working :p

No objections on having a twitter account to publish announcement ?

Jean Louis Boudart
Independent consultant
Project Lead

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