incubator-easyant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: Roadmap and priorities
Date Thu, 24 Feb 2011 14:17:26 GMT

Le 24 févr. 2011 à 13:16, Jean-Louis Boudart a écrit :

> Hi easyanters,
> Let's start a new thread to discuss about roadmap and main priorities for
> next months/releases.
> Here are my suggestions :
> *About migration itself*
> We've migrated mailling list and statuted to turn read only the old one.
> We've imported the source code without history into incubator repository.
> EasyAnt project has been created and initialized with all open tickets at
> However current situation is a bit complex as we're still "in transition"
> between old infrastructure and new one.
> IMHO the main priority is to move the website (or at least to have a real
> one instead of a redmine instance :p). The website needs to be easy to
> update and provide link to all important resources (issues management, svn,
> mailling list, donwloads).

I'll come with a proposal (for using xooki of course :)) very soon as soon as I figure out
some minor point.

> 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.

> Should we keep our old SVN with all history accessible ?

Yes please. The IP from Jason is still not resolved. After that it may be deleted, but it
won't hurt if it will be still on line.

> 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 ?

> *About easyant itself*
> We already realized part of 0.9 perimeter (see JIRA for more details). I
> voluntary didn't affect unresolved tickets to 0.9 so it's time to discuss
> about changes that should be included here.
> Some open ideas (in order of priority) :
>   - 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:

>   - Provide a way to make "distributable build"  : When using
>   "distributable build" you bring all resources you need to build the project
>   (plugins/buildtypes, project dependencies)  in the project structure. You
>   can imagine this as a "local" project repository. Then you can distribute
>   your project with this "local project repository", and people would be able
>   to rebuild  it from everywhere.
>   - Get rid of phases in favor of extensionPoint (see
> to
>   get more details)

I agree, these topics is about big moves and needs to be addressed first.
Actually I'll also add the next point.

> Things we can do later (in a future releases)
>   - 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.

>   - MultiModule project summary
> (EASYANT-9<> on
>   jira) : Idea here is to make a short summary (the build order of
>   submodule for example) before running targets to submodules. At the end it
>   should also display some information like build status of each roject and
>   execution time)
>   - Working in offline mode

I think this will be somehow included in the second point above

>   - 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 :)

> *About easyant4e (eclipse plugin)*
> Having an integration with common IDE like eclipse is a MUST have feature.
> If we want to seduce users we need to answer this (in particular on
> enterprise projects).
> I don't think there is much to do to release a beta of the eclipse plugin.
> So releasing at least a beta as soon as possible would be great.

It will have its own release cycle too, yes.

> *
> About organisation and communication
> *In the early stages of easyant i was dreaming of respecting as much as
> possible the rule "release early, release often". In the last month i have
> been less active than i expected. Refactoring the directory structure and
> having an online repository to release plugin in an independant way of
> easyant-core itself would help us a lot.
> Now that we reach Apache Incubator we should take the opportunity to do our
> main refactoring (get rid of Phases in favor of extensionPoint). Even if we
> would do our best to make it transparent for users it will have a short
> impact on plugins so plugin writter would probably wait our refactoring
> before playing with easyant.
> After that it will be easier to make communication about easyant project.
> I suggest the following things to promote easyant  :
>   - register a twitter account to publish "hot news" and release
>   announcement (login/password will be shared on easyant-private)
>   - organize online meeting (for example on IRC) to discuss about easyant
>   future (missing feature, bugs, enhancement). This does not intent to replace
>   the ML ! I'm volunteer of making a summary of this kind of online meeting on
>   the ML.

I tend to prefer mailing list. Even if I'm nearly always online ready to discuss, I'm often
"interrupted" by colleagues for my pay job. For instance while writing this email I got interrupted
and I didn't waste any of your time waiting me to finish my sentences :)
And not everybody here is on the same time zone, keeping architectural discussion on the mailing
list will keep everybody in touch.

I'm still happy about random chatting on irc thought :)


View raw message