incubator-easyant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@hibnet.org>
Subject Re: Re : State of EasyAnt (was Re: Incubator PMC/Board report for Jan 2012 ([ppmc]))
Date Tue, 12 Jun 2012 18:46:36 GMT

Le 12 juin 2012 à 08:22, Jean-Louis Boudart a écrit :

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

I can't wait to know :)

Could you give me some hints about how to build easyant ?

Nicolas

> 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
View raw message