incubator-easyant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Louis Boudart <jeanlouis.boud...@gmail.com>
Subject Re: Re : State of EasyAnt (was Re: Incubator PMC/Board report for Jan 2012 ([ppmc]))
Date Tue, 12 Jun 2012 06:22:38 GMT
Hi there,

Yesterday i've got time to work on a pretty anoying bug with ant when using
nested import and include (like in easyant) and extensionPoint.

This was my main priority until now to make easyant working fully with
extensionPoint. I will post the issue to ant today with a fix (hoping they
can include it quickly).

Then i will switch back to easyant and promise you cool news really soon. ;)
Le 3 avr. 2012 17:29, "Nicolas Lalevée" <nicolas.lalevee@hibnet.org> a
écrit :

>
> Le 20 mars 2012 à 14:51, Jean-Louis Boudart a écrit :
>
> > Fresh news, i've almost stabilized the version and recently commited it.
> > All plugins, buildtypes,  and core have been updated to remove phases.
>
> good !
>
> > Currently the build is broken on jenkins as trunk requires the most
> recent
> > plugins [1].
>
> This raise me some concerns about the "buildability" of easyant. How it is
> expected to be build ? This has consequence of the way we will release it
> (releasing source without being able to build has obviously no sense :) ).
>
>
> > What are the next steps before the release ?
> >
> >
> >   - Update the documentation to remove phases
> >
> >
> >   - Update plugin tutorial to explain how  you can write plugins using
> >   groovy (groovyfront) instead of XML
>
> I think it would be a nice to have but not a priority, the Groovy front is
> yet a proof of concept.
>
> >   - Create a short lifecycle to share common high level targets for end
> >   users such as compile, package, test (ideally a diagram of this short
> >   lifecycle on the documentation could be great)
> >
> >
> >   - Update the main class to display those high level target when
> invoking
> >   project help (easyant -p)
> >
> >
> >
> > We recently made some experimentation to enhance conflict and dependency
> > management between plugins.
> > For the details we've changed two things :
> >
> >   - We've introduced a second easyant's import task[2] which is aware of
> >   all plugins dependencies and can deal with conflict. Tthis task is
> >   considered as experimental. By default we use the old implementation
> for
> >   the moment.
> >   - We tried to limit target duplication by enforcing all plugins to use
> >   "import" instead of "include"[3].
> >
> > For the first point, I suggest to continue in this way on the next
> release.
> > We've spend too much time without releasing and we need to reactivate the
> > project.
> >
> > I'm personnaly not satisfied by the second point for many reasons :
> >
> >   - We initially made this change to avoid dupplication of
> >   "abstract-module" targets (like abstract-test-module). As we have no
> strong
> >   dependency management on plugins, when a someone use two test plugins
> for
> >   example (say junit and antunit) and both included abstract-test, you
> gets
> >   some side effects. All targets of this abstract modules gets
> dupplicated
> >   with two distinct prefix one for junit one for antunit. This is
> probably
> >   the only one case where moving from "include" to import" can make
> sense.
> >   Otherwise it does not answer fully our initial problem.
> >   - If we continue enhancing the conflict and dependency management on
> >   import task we will be able to solve the problem at resolution time
> >   - Targets are not prefixed ! Since the begining all plugins are
> >   "include"d with  a prefix, and all targets gets it. Exemple in javadoc
> >   plugin the target ":javadoc" is by default prefixed by the plugin
> name. As
> >   a end user you will call javadoc:javadoc. If we choose to use "import"
> >   mechanism instead of "include" will not have any prefix by default.
> This
> >   means when writting plugins you will need to manually put your own
> prefix
> >   on each target and cross the finger that no one has the same target
> name.
> >   This sounds terribly error prone for me and i really want to find a
> >   solution before the release. Any idea ?
> >
> > IMHO, we should get back to include as it was before and put all our
> effort
> > on the new easyant's import task.
>
> No objection.
>
> What about backward compatibility ?
> I am totally fine with breaking it. For now. Until we are satisfied with
> the general architecture of Easyant. To me the last point is about the
> plugin dependency you wrote about.
>
> Nicolas
>
>

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