You are viewing a plain text version of this content. The canonical link for it is here.
Posted to easyant-dev@incubator.apache.org by "sbert.rousseau.ML@gmail.com" <sb...@gmail.com> on 2012/01/17 09:30:56 UTC
Re : State of EasyAnt (was Re: Incubator PMC/Board report for Jan 2012 ([ppmc]))
It's a very good news.
Have you got a date for the change between phase and extension point.
I think it is very important for users to have news on the site and a new release.
Sbert.
Envoyé depuis mon HTC
----- Reply message -----
De : "Jean-Louis Boudart" <je...@gmail.com>
Pour : <ea...@incubator.apache.org>
Objet : State of EasyAnt (was Re: Incubator PMC/Board report for Jan 2012 ([ppmc]))
Date : lun., janv. 16, 2012 11:18
Hi,
Sorry for the delay i've not been available as much as expected those last
months.
I'll be more available at the end of the week i think and i plan to finish
and commit the refactoring of phases.
As you pointed out we're in Apache Incubator since one year and we still
have not achieved our objectives.
I assume the main problem comes from our huge refactoring due to one of the
core developper who didn't sign the CLA. As a consequence we've removed lot
of features which were part of easyant (plugin documentation, some plugins,
etc..). It probably affects a bit the motivation of others, at least it is
my case, reimplementing stuff is not so fun (removing it either cc Nicolas
:p).
I still believe Apache is the place to be for EasyAnt i still plan to make
this project live and to create interaction with Ant and Ivy community.
To release the next version we need to finish our refactoring on phases and
update documentation (including plugins). Then i propose for a n+1release
(probably the 1.0) to provide a way to test plugins and to generate
documentation for plugins.
Cheers,
Le 9 janvier 2012 14:39, Nicolas Lalevée <ni...@hibnet.org> a
écrit :
>
> Le 6 janv. 2012 à 07:35, Stefan Bodewig a écrit :
>
> > Agreed, this needs to be done, but do we have any timeframe by which
> > this will be done or by which we call incubation failed? To some degree
> > I'm playing devil's advocate here, but eternal incubation is not an
> > option.
>
> I am starting to think it quite loud so I'll write it. If there is no much
> progress until the next report, 3 month from now, I'm thinking that we
> shouldn't bother Apache any longer. It would make a little more than one
> year of incubation. "One year" is a period mentioned on the
> incubator-general when there was a discussion about how long a podling
> should last. It was just a discussion there, not official, podling can last
> longer, but I think this is a good period length for podling to ask
> themself if they are not wasting ASF resources.
> And guys, it absolutely doesn't mean EasyAnt would be dead, it will just
> mean it is not enough active to demonstrate proper integration into the
> ASF. It can properly live back on easyant.org.
>
> Nicolas
>
>
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: Re : State of EasyAnt (was Re: Incubator PMC/Board report for Jan 2012 ([ppmc]))
Posted by Nicolas Lalevée <ni...@hibnet.org>.
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" <ni...@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
>>
>>
Re: Re : State of EasyAnt (was Re: Incubator PMC/Board report for Jan
2012 ([ppmc]))
Posted by Jean-Louis Boudart <je...@gmail.com>.
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" <ni...@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
>
>
Re: Re : State of EasyAnt (was Re: Incubator PMC/Board report for Jan 2012 ([ppmc]))
Posted by Nicolas Lalevée <ni...@hibnet.org>.
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
Re: Re : State of EasyAnt (was Re: Incubator PMC/Board report for Jan
2012 ([ppmc]))
Posted by Jean-Louis Boudart <je...@gmail.com>.
Fresh news, i've almost stabilized the version and recently commited it.
All plugins, buildtypes, and core have been updated to remove phases.
Currently the build is broken on jenkins as trunk requires the most recent
plugins [1].
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
- 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.
Note that ant-core 1.8.x seems to be buggy when using "include" and
extensionPoints. Though this can be patched if we all agree to go in this
way.
[1] https://svn.apache.org/repos/asf/incubator/easyant/plugins/trunk/
[2]
https://svn.apache.org/repos/asf/incubator/easyant/core/trunk/src/main/java/org/apache/easyant/tasks/ImportAntscripts.java
[3] http://ant.apache.org/manual/Tasks/import.html see the "How is <import>
different from <include>?" section
2012/1/17 Jean-Louis Boudart <je...@gmail.com>
> Changes in the code itself should be commited at the end of the week. And
> i will probably write a blog entry about this.
> Then to finalize the release the documentation needs to be updated and i
> don't know yet how many time will be required to update it.
>
> 2012/1/17 sbert.rousseau.ML@gmail.com <sb...@gmail.com>
>
> It's a very good news.
>>
>> Have you got a date for the change between phase and extension point.
>>
>> I think it is very important for users to have news on the site and a new
>> release.
>>
>> Sbert.
>>
>> Envoyé depuis mon HTC
>>
>> ----- Reply message -----
>> De : "Jean-Louis Boudart" <je...@gmail.com>
>> Pour : <ea...@incubator.apache.org>
>> Objet : State of EasyAnt (was Re: Incubator PMC/Board report for Jan 2012
>> ([ppmc]))
>> Date : lun., janv. 16, 2012 11:18
>>
>>
>> Hi,
>>
>> Sorry for the delay i've not been available as much as expected those
>> last
>> months.
>> I'll be more available at the end of the week i think and i plan to finish
>> and commit the refactoring of phases.
>>
>> As you pointed out we're in Apache Incubator since one year and we still
>> have not achieved our objectives.
>> I assume the main problem comes from our huge refactoring due to one of
>> the
>> core developper who didn't sign the CLA. As a consequence we've removed
>> lot
>> of features which were part of easyant (plugin documentation, some
>> plugins,
>> etc..). It probably affects a bit the motivation of others, at least it is
>> my case, reimplementing stuff is not so fun (removing it either cc Nicolas
>> :p).
>>
>> I still believe Apache is the place to be for EasyAnt i still plan to make
>> this project live and to create interaction with Ant and Ivy community.
>>
>> To release the next version we need to finish our refactoring on phases
>> and
>> update documentation (including plugins). Then i propose for a n+1release
>> (probably the 1.0) to provide a way to test plugins and to generate
>> documentation for plugins.
>>
>> Cheers,
>>
>>
>>
>> Le 9 janvier 2012 14:39, Nicolas Lalevée <ni...@hibnet.org> a
>> écrit :
>>
>> >
>> > Le 6 janv. 2012 à 07:35, Stefan Bodewig a écrit :
>> >
>> > > Agreed, this needs to be done, but do we have any timeframe by which
>> > > this will be done or by which we call incubation failed? To some
>> degree
>> > > I'm playing devil's advocate here, but eternal incubation is not an
>> > > option.
>> >
>> > I am starting to think it quite loud so I'll write it. If there is no
>> much
>> > progress until the next report, 3 month from now, I'm thinking that we
>> > shouldn't bother Apache any longer. It would make a little more than one
>> > year of incubation. "One year" is a period mentioned on the
>> > incubator-general when there was a discussion about how long a podling
>> > should last. It was just a discussion there, not official, podling can
>> last
>> > longer, but I think this is a good period length for podling to ask
>> > themself if they are not wasting ASF resources.
>> > And guys, it absolutely doesn't mean EasyAnt would be dead, it will just
>> > mean it is not enough active to demonstrate proper integration into the
>> > ASF. It can properly live back on easyant.org.
>> >
>> > Nicolas
>> >
>> >
>>
>>
>> --
>> Jean Louis Boudart
>> Independent consultant
>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>>
>
>
>
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: Re : State of EasyAnt (was Re: Incubator PMC/Board report for Jan
2012 ([ppmc]))
Posted by Jean-Louis Boudart <je...@gmail.com>.
Changes in the code itself should be commited at the end of the week. And i
will probably write a blog entry about this.
Then to finalize the release the documentation needs to be updated and i
don't know yet how many time will be required to update it.
2012/1/17 sbert.rousseau.ML@gmail.com <sb...@gmail.com>
> It's a very good news.
>
> Have you got a date for the change between phase and extension point.
>
> I think it is very important for users to have news on the site and a new
> release.
>
> Sbert.
>
> Envoyé depuis mon HTC
>
> ----- Reply message -----
> De : "Jean-Louis Boudart" <je...@gmail.com>
> Pour : <ea...@incubator.apache.org>
> Objet : State of EasyAnt (was Re: Incubator PMC/Board report for Jan 2012
> ([ppmc]))
> Date : lun., janv. 16, 2012 11:18
>
>
> Hi,
>
> Sorry for the delay i've not been available as much as expected those last
> months.
> I'll be more available at the end of the week i think and i plan to finish
> and commit the refactoring of phases.
>
> As you pointed out we're in Apache Incubator since one year and we still
> have not achieved our objectives.
> I assume the main problem comes from our huge refactoring due to one of the
> core developper who didn't sign the CLA. As a consequence we've removed lot
> of features which were part of easyant (plugin documentation, some plugins,
> etc..). It probably affects a bit the motivation of others, at least it is
> my case, reimplementing stuff is not so fun (removing it either cc Nicolas
> :p).
>
> I still believe Apache is the place to be for EasyAnt i still plan to make
> this project live and to create interaction with Ant and Ivy community.
>
> To release the next version we need to finish our refactoring on phases and
> update documentation (including plugins). Then i propose for a n+1release
> (probably the 1.0) to provide a way to test plugins and to generate
> documentation for plugins.
>
> Cheers,
>
>
>
> Le 9 janvier 2012 14:39, Nicolas Lalevée <ni...@hibnet.org> a
> écrit :
>
> >
> > Le 6 janv. 2012 à 07:35, Stefan Bodewig a écrit :
> >
> > > Agreed, this needs to be done, but do we have any timeframe by which
> > > this will be done or by which we call incubation failed? To some
> degree
> > > I'm playing devil's advocate here, but eternal incubation is not an
> > > option.
> >
> > I am starting to think it quite loud so I'll write it. If there is no
> much
> > progress until the next report, 3 month from now, I'm thinking that we
> > shouldn't bother Apache any longer. It would make a little more than one
> > year of incubation. "One year" is a period mentioned on the
> > incubator-general when there was a discussion about how long a podling
> > should last. It was just a discussion there, not official, podling can
> last
> > longer, but I think this is a good period length for podling to ask
> > themself if they are not wasting ASF resources.
> > And guys, it absolutely doesn't mean EasyAnt would be dead, it will just
> > mean it is not enough active to demonstrate proper integration into the
> > ASF. It can properly live back on easyant.org.
> >
> > Nicolas
> >
> >
>
>
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://incubator.apache.org/easyant/