You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Peter Reilly <pe...@gmail.com> on 2006/12/29 17:43:06 UTC
Proposed roadmap
* 1.7.x
- fix bugs
- implement some enhancement requests
- add some extra attributes to tasks/types
(for example fileset dir not present attribute)
- add some conditions/resources/filters/mappers
- junitize other optional tasks (i.e. allow
the needed thirdparty classes to be specified
when using the task)
- make checkstyle clean
- support more java5,6,7 features
* 1.8
- add classpath manipulation (classloader task)
- add logic/controlflow features from jsp/ant-contrib (for, if,
while, try, var etc)
- better scripting language support
- allow javascript and jruby to create tasks/types natively
(beanshell, groovy can do this currently).
- import improvements (url support, searchpath support)
- if/unless attributes with primative EL (expression language)
(ie if="${property.not.present}" will work as if="property.not.present")
- restricted types (i.e. roles)
- some simple build file generators (like seam-gen)
- xmlize the manual goals:
- pdf version output
- clean html output
- easy navigation
* 1.9
- add EL (?from jsp/jsf - properties or references?)
- unify properties and references
- integration with ivy/maven for dependence
- ?annotations for tasks?
* 2.0
- remove need of xml
- unify with maven
- unify with raven
- ant only runs on java5
- world peace
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Proposed roadmap
Posted by Jesse Glick <je...@sun.com>.
Kevin Jackson wrote:
>> * 1.9
>> - ?annotations for tasks?
>
> annotations might be nice, but now you['re] limited to java5+
http://backport175.codehaus.org/
if you didn't know about it.
-J.
--
jesse.glick@sun.com x22801 netbeans.org ant.apache.org
http://google.com/search?q=e%5E%28pi*i%29%2B1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Proposed roadmap
Posted by Peter Reilly <pe...@gmail.com>.
On 12/30/06, Kevin Jackson <fo...@gmail.com> wrote:
> > * 1.7.x
> > - fix bugs
> > - implement some enhancement requests
> > - add some extra attributes to tasks/types
> > (for example fileset dir not present attribute)
> > - add some conditions/resources/filters/mappers
> > - junitize other optional tasks (i.e. allow
> > the needed thirdparty classes to be specified
> > when using the task)
> > - make checkstyle clean
> > - support more java5,6,7 features
>
> - reduce size by splitting out optional tasks into antlibs
This would be more a 1.8 activity.
> - use antunit for testing and deprecate old BuildFileTests where appropriate
>
> >
> > * 1.8
> > - add classpath manipulation (classloader task)
> > - add logic/controlflow features from jsp/ant-contrib (for, if,
> > while, try, var etc)
>
> not sure I agree with adding control flow as it's better to do such
> things with a scripting language
I will try get a page describing reasons ready. I think that
using scripting languages in ant is great - but not for control
of task flow. Scripting is great for adding new tasks/types.
>
> > - better scripting language support
> > - allow javascript and jruby to create tasks/types natively
> > (beanshell, groovy can do this currently).
> > - import improvements (url support, searchpath support)
> > - if/unless attributes with primative EL (expression language)
> > (ie if="${property.not.present}" will work as if="property.not.present")
> > - restricted types (i.e. roles)
> > - some simple build file generators (like seam-gen)
>
> like the sound of this! something like 'ant webapp-gen' to create a
> starting point for a java webapp - would we use Velocity or some other
> tool or write everything in raw java?
I played with velocity a few years ago - did not like it.
>
> > - xmlize the manual goals:
> > - pdf version output
>
> urk - this one has been in Bugzilla for a very very long time, use
> docbook + fop (as I tried earlier), but people objected to docbook, so
> again we need to pick a technology for this
docbook looks a good bit verbose. I would rather something that
makes it easy to write manual pages with specific tags for
attributes/nested elements
and examples. DD had a xslt stylesheet (cannot find the bugzilla request at the
moment) which may be the way to go (however I have always found it
difficult to write/understand xslt). The xdocs project took the java
source and generated
html pages, but it was difficult to maintain, need to understand
velocity, and the
generated pages were hideous (in terms of html tags).
>
> > - clean html output
> > - easy navigation
> >
> > * 1.9
> > - add EL (?from jsp/jsf - properties or references?)
> > - unify properties and references
> > - integration with ivy/maven for dependence
> > - ?annotations for tasks?
>
> annotations might be nice, but now your limited to java5+
>
> >
> > * 2.0
> > - remove need of xml
>
> and replace with? We could use an alternate form for defining the
> tasks/targets etc, but what form would that take
It should be possible to define annotations for tasks/types to
remove the need for antlib.xml.
As regards build.xml, maybe support groovy?
>
> > - unify with maven
> > - unify with raven
> > - ant only runs on java5
> > - world peace
>
> Good list to get us thinking!
>
> Thanks,
> Kev
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Proposed roadmap
Posted by Kevin Jackson <fo...@gmail.com>.
> * 1.7.x
> - fix bugs
> - implement some enhancement requests
> - add some extra attributes to tasks/types
> (for example fileset dir not present attribute)
> - add some conditions/resources/filters/mappers
> - junitize other optional tasks (i.e. allow
> the needed thirdparty classes to be specified
> when using the task)
> - make checkstyle clean
> - support more java5,6,7 features
- reduce size by splitting out optional tasks into antlibs
- use antunit for testing and deprecate old BuildFileTests where appropriate
>
> * 1.8
> - add classpath manipulation (classloader task)
> - add logic/controlflow features from jsp/ant-contrib (for, if,
> while, try, var etc)
not sure I agree with adding control flow as it's better to do such
things with a scripting language
> - better scripting language support
> - allow javascript and jruby to create tasks/types natively
> (beanshell, groovy can do this currently).
> - import improvements (url support, searchpath support)
> - if/unless attributes with primative EL (expression language)
> (ie if="${property.not.present}" will work as if="property.not.present")
> - restricted types (i.e. roles)
> - some simple build file generators (like seam-gen)
like the sound of this! something like 'ant webapp-gen' to create a
starting point for a java webapp - would we use Velocity or some other
tool or write everything in raw java?
> - xmlize the manual goals:
> - pdf version output
urk - this one has been in Bugzilla for a very very long time, use
docbook + fop (as I tried earlier), but people objected to docbook, so
again we need to pick a technology for this
> - clean html output
> - easy navigation
>
> * 1.9
> - add EL (?from jsp/jsf - properties or references?)
> - unify properties and references
> - integration with ivy/maven for dependence
> - ?annotations for tasks?
annotations might be nice, but now your limited to java5+
>
> * 2.0
> - remove need of xml
and replace with? We could use an alternate form for defining the
tasks/targets etc, but what form would that take
> - unify with maven
> - unify with raven
> - ant only runs on java5
> - world peace
Good list to get us thinking!
Thanks,
Kev
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Proposed roadmap
Posted by Jesse Glick <je...@sun.com>.
Peter Reilly wrote:
> - xmlize the manual goals:
> - pdf version output
> - clean html output
> - easy navigation
And would be helpful for JavaHelp generation, too. Currently for
integration in NB I have a task to reverse-engineer the HTML manual's
structure, which is none too pretty.
> * 2.0
> - remove need of xml
> - unify with maven
> - unify with raven
> - ant only runs on java5
> - world peace
I don't suppose we can just skip 1.8 and 1.9? :-)
-J.
--
jesse.glick@sun.com x22801 netbeans.org ant.apache.org
http://google.com/search?q=e%5E%28pi*i%29%2B1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Proposed roadmap
Posted by Stefan Bodewig <bo...@apache.org>.
On Sat, 13 Jan 2007, Peter Reilly <pe...@gmail.com> wrote:
> I am thinking of replacing the current oata.taskdefs.ClassLoader
> with a task that *just* controls the coreloader.
This would make me a lot less scared by the task.
> I do not like the current custom PropertyHelpers:
Honestly, I'm not too familiar with their implementation, so I can't
defend them.
> * it to too drastic - replacing completly the property handler
I thought they supported chaining. So if it doesn't look like an EL
expression, delegate to the "other" PropertyHelper.
> * sub-projects are currently not supported
This is a problem, agreed.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Proposed roadmap
Posted by Peter Reilly <pe...@gmail.com>.
On 1/8/07, Stefan Bodewig <bo...@apache.org> wrote:
> On Fri, 29 Dec 2006, Peter Reilly <pe...@gmail.com> wrote:
>
> > * 1.8
> > - add classpath manipulation (classloader task)
>
> could that be done as an antlib or does it require support inside of
> the Ant core engine?
We need to fix the coreLoader stuff currently in ant.
This can be used to load in tasks/types and xml namespaced
loaded antlibs.
To work properly this needs:
* to use a copy-on-write mechanism - so that classloaders do not get modified
and so that sub-projects do not modify the core-loader of the main
project.
* inform ant-core ComponentHelper xmlns antlib autoresolver that the
coreLoader has
changed.
* works when using antcall, i.e. multiple calls do not change the coreloader.
* may need to optionally allow the coreloader to be not inherited in
sub-projects.
(i.e. an extra inherit arg - I think that by default the coreloader should be
inherited - this is not the default for references).
Doing this will solve a number of issues with optional packages
and with useablily of antlibs.
I am thinking of replacing the current oata.taskdefs.ClassLoader
with a task that *just* controls the coreloader.
Any other idea is to provide a generic per-task task/type loader. This
is done by hand at the moment for <junit> and <script>.
I have looked at others, but it is tedious and error-prone as
each optional task is different - some currently use the classpath
for different things - <jdepend> and <xslt> for example, and some
do not have a <classpath> but do have a large main task - <sshtask>/<scp>.
>
> > - add logic/controlflow features from jsp/ant-contrib (for, if,
> > while, try, var etc)
>
> inside of Ant's core? I'd prefer an antlib, which would lead to the
> question why we'd need one separate from ant-contrib, of course.
>
> > - allow javascript and jruby to create tasks/types natively
>
> what changes would be required for that?
>
> > - if/unless attributes with primative EL (expression language)
> > (ie if="${property.not.present}" will work as
> > if="property.not.present")
>
> can't we do that with custom PropertyHelpers, in some wierd way?
It would be better do this in in core ant. (I have been using facelets,
JSF and SEAM in a prototype and having EL and control tags and
attributes (repeat, if, for, rendered="#{not empty aComponent}") is
very pleasent).
Some work needs to be done to allow ant-core to be configured
to use this. I do not like the current custom PropertyHelpers:
* it to too drastic - replacing completly the property handler
* sub-projects are currently not supported
To be usefull, I think that EL should be part of ant-core, perhaps
with a task to enable/disable it.
>
> > * 1.9
> > - integration with ivy/maven for dependence
>
> what kind of integration beyond what Ivy currently provides do you
> envision?
I am not too sure - I do not have BroadBand at home
at the moment, so I cannot use maven to get a feel of
how one can use it. However I have noticed a lot of
projects have started to use it, and as far as I can
see it provides a number of usefull features
- dependence
- site documention
The ivy antlib may provide the dependence support
needed - but I think that ant will have to provide
an easy inbuilt way to download, install and use antlibs,
especially the antlibs on the ant site.
>
> > * 2.0
> > - remove need of xml
>
> alternatives to XML could and should be possible with custom
> ProjectHelpers, at least we should make it possible prior to 2.0
We have mentioned using custom ProjectHelpers, but I have not
seen any....
Peter
> (which also requires feeding the hungry and preventing the world
> climate from becoming even more troubled).
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Proposed roadmap
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 29 Dec 2006, Peter Reilly <pe...@gmail.com> wrote:
> * 1.8
> - add classpath manipulation (classloader task)
could that be done as an antlib or does it require support inside of
the Ant core engine?
> - add logic/controlflow features from jsp/ant-contrib (for, if,
> while, try, var etc)
inside of Ant's core? I'd prefer an antlib, which would lead to the
question why we'd need one separate from ant-contrib, of course.
> - allow javascript and jruby to create tasks/types natively
what changes would be required for that?
> - if/unless attributes with primative EL (expression language)
> (ie if="${property.not.present}" will work as
> if="property.not.present")
can't we do that with custom PropertyHelpers, in some wierd way?
> * 1.9
> - integration with ivy/maven for dependence
what kind of integration beyond what Ivy currently provides do you
envision?
> * 2.0
> - remove need of xml
alternatives to XML could and should be possible with custom
ProjectHelpers, at least we should make it possible prior to 2.0
(which also requires feeding the hungry and preventing the world
climate from becoming even more troubled).
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Proposed roadmap
Posted by Mark Claassen <mc...@ocie.net>.
Wow, I guess I have been look for World Peace in all the wrong places. :)
-----Original Message-----
From: Peter Reilly [mailto:peter.kitt.reilly@gmail.com]
Sent: Friday, December 29, 2006 11:43 AM
To: Ant Developers List
Subject: Proposed roadmap
* 1.7.x
- fix bugs
- implement some enhancement requests
- add some extra attributes to tasks/types
(for example fileset dir not present attribute)
- add some conditions/resources/filters/mappers
- junitize other optional tasks (i.e. allow
the needed thirdparty classes to be specified
when using the task)
- make checkstyle clean
- support more java5,6,7 features
* 1.8
- add classpath manipulation (classloader task)
- add logic/controlflow features from jsp/ant-contrib (for, if, while,
try, var etc)
- better scripting language support
- allow javascript and jruby to create tasks/types natively
(beanshell, groovy can do this currently).
- import improvements (url support, searchpath support)
- if/unless attributes with primative EL (expression language)
(ie if="${property.not.present}" will work as
if="property.not.present")
- restricted types (i.e. roles)
- some simple build file generators (like seam-gen)
- xmlize the manual goals:
- pdf version output
- clean html output
- easy navigation
* 1.9
- add EL (?from jsp/jsf - properties or references?)
- unify properties and references
- integration with ivy/maven for dependence
- ?annotations for tasks?
* 2.0
- remove need of xml
- unify with maven
- unify with raven
- ant only runs on java5
- world peace
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional
commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Proposed roadmap
Posted by Prashant Deva <pr...@gmail.com>.
Is there any timeline associated with the roadmap too?
--
Prashant Deva
Creator, ANTLR Studio, Virtual Ant
Founder, Placid Systems, www.placidsystems.com
Re: Proposed roadmap
Posted by Wolfgang Häfelinger <wh...@epo.org>.
>> It may be difficult to have an EL in ant as
>> the components/beans (properties and references)
>> are not bound by any naming
>> rules [..]
You have a similar problem in JSP as you are allowed
to define a config parameter named "foo-bar". EL will
treat ${initParam.foo-bar} as valueof(initParam.foo)
- valueof(bar) which is not what you want.
However, you can also use ${initParam['foo-bar']} for
names not bound to usual rules.
>> properties and references have different rules (
>> properties are not meant to be overwritten)
EL does not allow you to override properties (or
resources).
Btw, it would be rather handy to be able to override
properties. Here Ant could be a bit less dogmatic. Why
not adding an attribute to task property which overrides
if desired??
>> and have different namespaces (i.e. one can use the
>> same name for a property and for a reference).
EL must work on properties, references as well as on any
other data type .., i.e. the EL expression
${empty varname ? 'empty' : 'not empty'}
must universally work (as it does in JSP).
"Peter Reilly" <pe...@gmail.com>
03-01-2007 16:57
Please respond to
"Ant Developers List" <de...@ant.apache.org>
To
"Ant Developers List" <de...@ant.apache.org>
cc
Subject
Re: Proposed roadmap
On 1/3/07, Wolfgang Häfelinger <wh...@epo.org> wrote:
> >> 3. I dont actually like EL handling as the way
> >> any invalid bit the the expression switches the
> >> whole thing to null, instead of telling where
> >> you've left something undefined. That may just
> >> be the JSP2 implementation, of course,.
>
> I like this actually much more than the Ant way. Too
> many times I created funny directories like ${src.dir}
> et cetera. So I'm not going to miss this Ant "feature".
> It would anyhow only apply for those using EL, for all
> others, the old rule would apply (I assume here that
> you could define on a higher level to use EL or not ..).
It may be difficult to have an EL in ant as the components/beans
(properties and references) are not bound by any naming
rules - so spaces, dots even < and > are allowed:
<property name="<x>" value="x is this"/>
properties and references have different rules (properties
are not meant to be overwritten) and have different
namespaces (i.e. one can use the same name for a property
and for a reference).
Traditionally in ant one uses nested elements in place of an EL.
<condition property="trax.impl.present">
<or>
<and>
<isset property="javax.xml.transform.TransformerFactory"/>
<available classname="${javax.xml.transform.TransformerFactory}"
classpathref="classpath"/>
</and>
<available
resource="META-INF/services/javax.xml.transform.TransformerFactory"/>
</or>
</condition>
{from ant's build file}
but this can get a bit verbose.
>
> >> 1. I'm not sure how serious it was
>
> Deadly serious for me ;-) as well as I hope that Peter
> has not been joking with regards to "- add logic/control-
> flow features from jsp/ant-contrib (for, if, while, try,
> var etc)
>
> >> 2. its a traumatic change
>
> Kidding?
>
>
>
>
>
>
> Steve Loughran <st...@apache.org>
> 03-01-2007 14:58
> Please respond to
> "Ant Developers List" <de...@ant.apache.org>
>
>
> To
> Ant Developers List <de...@ant.apache.org>
> cc
>
> Subject
> Re: Proposed roadmap
>
>
>
>
>
>
> Wolfgang Häfelinger wrote:
> > * 1.9
> > - add EL (?from jsp/jsf - properties or references?)
> >
> > Since EL is a really cool feature and simplifies JSP development so
> much,
> > I
> > would like to give it a much higher priority (1.7.x)...
> >
>
> 1. I'm not sure how serious it was
> 2. its a traumatic change
> 3. I dont actually like EL handling as the way any invalid bit the the
> expression switches the whole thing to null, instead of telling where
> you've left something undefined. That may just be the JSP2
> implementation, of course,.
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Proposed roadmap
Posted by Peter Reilly <pe...@gmail.com>.
On 1/3/07, Wolfgang Häfelinger <wh...@epo.org> wrote:
> >> 3. I dont actually like EL handling as the way
> >> any invalid bit the the expression switches the
> >> whole thing to null, instead of telling where
> >> you've left something undefined. That may just
> >> be the JSP2 implementation, of course,.
>
> I like this actually much more than the Ant way. Too
> many times I created funny directories like ${src.dir}
> et cetera. So I'm not going to miss this Ant "feature".
> It would anyhow only apply for those using EL, for all
> others, the old rule would apply (I assume here that
> you could define on a higher level to use EL or not ..).
It may be difficult to have an EL in ant as the components/beans
(properties and references) are not bound by any naming
rules - so spaces, dots even < and > are allowed:
<property name="<x>" value="x is this"/>
properties and references have different rules (properties
are not meant to be overwritten) and have different
namespaces (i.e. one can use the same name for a property
and for a reference).
Traditionally in ant one uses nested elements in place of an EL.
<condition property="trax.impl.present">
<or>
<and>
<isset property="javax.xml.transform.TransformerFactory"/>
<available classname="${javax.xml.transform.TransformerFactory}"
classpathref="classpath"/>
</and>
<available
resource="META-INF/services/javax.xml.transform.TransformerFactory"/>
</or>
</condition>
{from ant's build file}
but this can get a bit verbose.
>
> >> 1. I'm not sure how serious it was
>
> Deadly serious for me ;-) as well as I hope that Peter
> has not been joking with regards to "- add logic/control-
> flow features from jsp/ant-contrib (for, if, while, try,
> var etc)
>
> >> 2. its a traumatic change
>
> Kidding?
>
>
>
>
>
>
> Steve Loughran <st...@apache.org>
> 03-01-2007 14:58
> Please respond to
> "Ant Developers List" <de...@ant.apache.org>
>
>
> To
> Ant Developers List <de...@ant.apache.org>
> cc
>
> Subject
> Re: Proposed roadmap
>
>
>
>
>
>
> Wolfgang Häfelinger wrote:
> > * 1.9
> > - add EL (?from jsp/jsf - properties or references?)
> >
> > Since EL is a really cool feature and simplifies JSP development so
> much,
> > I
> > would like to give it a much higher priority (1.7.x)...
> >
>
> 1. I'm not sure how serious it was
> 2. its a traumatic change
> 3. I dont actually like EL handling as the way any invalid bit the the
> expression switches the whole thing to null, instead of telling where
> you've left something undefined. That may just be the JSP2
> implementation, of course,.
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Proposed roadmap
Posted by Wolfgang Häfelinger <wh...@epo.org>.
>> 3. I dont actually like EL handling as the way
>> any invalid bit the the expression switches the
>> whole thing to null, instead of telling where
>> you've left something undefined. That may just
>> be the JSP2 implementation, of course,.
I like this actually much more than the Ant way. Too
many times I created funny directories like ${src.dir}
et cetera. So I'm not going to miss this Ant "feature".
It would anyhow only apply for those using EL, for all
others, the old rule would apply (I assume here that
you could define on a higher level to use EL or not ..).
>> 1. I'm not sure how serious it was
Deadly serious for me ;-) as well as I hope that Peter
has not been joking with regards to "- add logic/control-
flow features from jsp/ant-contrib (for, if, while, try,
var etc)
>> 2. its a traumatic change
Kidding?
Steve Loughran <st...@apache.org>
03-01-2007 14:58
Please respond to
"Ant Developers List" <de...@ant.apache.org>
To
Ant Developers List <de...@ant.apache.org>
cc
Subject
Re: Proposed roadmap
Wolfgang Häfelinger wrote:
> * 1.9
> - add EL (?from jsp/jsf - properties or references?)
>
> Since EL is a really cool feature and simplifies JSP development so
much,
> I
> would like to give it a much higher priority (1.7.x)...
>
1. I'm not sure how serious it was
2. its a traumatic change
3. I dont actually like EL handling as the way any invalid bit the the
expression switches the whole thing to null, instead of telling where
you've left something undefined. That may just be the JSP2
implementation, of course,.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Proposed roadmap
Posted by Steve Loughran <st...@apache.org>.
Wolfgang Häfelinger wrote:
> * 1.9
> - add EL (?from jsp/jsf - properties or references?)
>
> Since EL is a really cool feature and simplifies JSP development so much,
> I
> would like to give it a much higher priority (1.7.x)...
>
1. I'm not sure how serious it was
2. its a traumatic change
3. I dont actually like EL handling as the way any invalid bit the the
expression switches the whole thing to null, instead of telling where
you've left something undefined. That may just be the JSP2
implementation, of course,.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Proposed roadmap
Posted by Wolfgang Häfelinger <wh...@epo.org>.
* 1.9
- add EL (?from jsp/jsf - properties or references?)
Since EL is a really cool feature and simplifies JSP development so much,
I
would like to give it a much higher priority (1.7.x)...
it possible to
"Peter Reilly" <pe...@gmail.com>
29-12-2006 17:43
Please respond to
"Ant Developers List" <de...@ant.apache.org>
To
"Ant Developers List" <de...@ant.apache.org>
cc
Subject
Proposed roadmap
* 1.7.x
- fix bugs
- implement some enhancement requests
- add some extra attributes to tasks/types
(for example fileset dir not present attribute)
- add some conditions/resources/filters/mappers
- junitize other optional tasks (i.e. allow
the needed thirdparty classes to be specified
when using the task)
- make checkstyle clean
- support more java5,6,7 features
* 1.8
- add classpath manipulation (classloader task)
- add logic/controlflow features from jsp/ant-contrib (for, if,
while, try, var etc)
- better scripting language support
- allow javascript and jruby to create tasks/types natively
(beanshell, groovy can do this currently).
- import improvements (url support, searchpath support)
- if/unless attributes with primative EL (expression language)
(ie if="${property.not.present}" will work as
if="property.not.present")
- restricted types (i.e. roles)
- some simple build file generators (like seam-gen)
- xmlize the manual goals:
- pdf version output
- clean html output
- easy navigation
* 1.9
- add EL (?from jsp/jsf - properties or references?)
- unify properties and references
- integration with ivy/maven for dependence
- ?annotations for tasks?
* 2.0
- remove need of xml
- unify with maven
- unify with raven
- ant only runs on java5
- world peace
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org