On 10/27/00 5:29 AM, "Stefan Bodewig" <[EMAIL PROTECTED]> wrote:
> First of all, the number of people actually using Ant in their
> projects has outgrown all expectations - this is great and should also
> make us feel a little responsible for their projects.
Yep. It is quite amazing.
> My aim is that we are going to break them no more than _once_
> more. I.e. we should try to get a clear vision of what we want to
> achieve with Ant 2.0, *document* it and then stick to it, at least for
> the near future.
Yep. Ant was really released a bit rough from a "how it was designed"
standpoint.
> I think the process to get there might take some time. On the other
> hand there will be a couple of changes, bug fixes and new features
> that won't affect old build environments. I feel we should be prepared
> to have a Ant 1.3 release (or 1.2.1 or similar) and maybe even
> releases following that (though I hope not) to address this -
> personally I'd prefer to get to a shorter release cycle than we had.
I wouldn't mind planning on seeing 2.0 on the order of first quarter next
year. It's not something that has to happen sooner -- just better.
> This means we'd need to defer all things that could break older
> environments to a final step from Ant 1.x to 2.0, using a branch for
> that if necessary.
Instead of a branch, I'd like to see it in an ant-2.0 workspace. CVS
branches have proved to be clunky way of managing change of the order
needed.
> What I'd like to see for 2.0
> ============================
>
> (*) Switch to JAXP 1.1 and SAX2.
>
> Could happen in 1.3 as well if JAXP 1.1 should be ready by then.
Actually, I'd like to implement a mini parser that just knew Ant's
particular syntax and remove the need to depend on external libs. Yeah, I
know that sounds weird coming from the guy who is authoring the JAXP spec,
but... It would simplify bootstrapping and distribution.
Ok -- maybe that's a bit over the top.. But it's a thought.
> (*) Change of the property system one last time
>
> No matter what we do, there are still some things that need to be
> resolved and finalized. Mainly
>
> (1) Master projects overwriting properties in sub projects. Sometimes
> you want this to happen, in other cases you do so by accident. The
> easiest solution that doesn't change the behavior of current build
> files would be something like
>
> <property name="foo" value="bar" scope="file" />
>
> for properties that should not overwrite properties of the same name
> in sub builds. If you want to overwrite, use scope="global" which would
> need to be the default unless we want to break something existing.
>
> Alternatively add something like <localproperty> for what scope="file"
> would do.
Actually, I'd rather break with the past and just say that if I have a
property defined at a upper level, and it's not reassigned at a lower level,
then you get the upper level -- but if it is reassigned at a lower level --
you get the lower level. It's simple and to the point.
> (2) Do we want mutable properties or not? Regardless of what we come
> up with, we should document it and stick to it.
Yes. The build file defines the static representation of the build. However,
given a scripting system that has exposure to the tree of the build, it
should all be mutable (including the ability for scripts to remove/add tasks
-- and tasks to be able to go through the tree and affect things).
> (*) Use a consistent naming for attributes
>
> Instead of using srcdir, dir and basedir for the same thing, we should
> agree on one and use it throughout Ant.
Yep. The tasks can be cleaned up a bit.
> (*) Extension tasks
>
> Make extending Ant as simple as possible, i.e. drop a jar file in a
> specific directory (ANT_HOME/ext globally or ~/.ant/ext on a user by
> user basis).
Order: 1) specified pick up location in the build file
2) ~/.ant/ext
3) ANT_HOME/ext
> This jar file must include <taskdef>s to define the tasks, Schema
> files to describe the tasks and documentation in the XML format we
> agreed on.
In META-INF/anttask.xml
> (*) A GUI tool.
>
> Hope Anthill will really get on the way. Frederic, if you should need
> help (like a CVS space to live in), please let us know.
+1 -- Ant was always meant to have a tool on top of it.
> (*) Some kind of front end to satisfy the more complex needs of some
> users.
>
> This is where I'd see support for enhanced conditionals and other
> things. To quote Duncan: a tool that would be "to Ant what configure
> is to make".
Yep. In fact, I'd really be for making Ant simpler again in the presence of
a antconfig that could take care of things on a platform or other basis.
After all -- it seems that most modifications of properties and such are
wanted to deal with installation or user local items in the same way that
config is used for C based programs.
--
James Duncan Davidson [EMAIL PROTECTED]
!try; do()
