You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Bruce Atherton <br...@callenish.com> on 2012/02/13 19:25:30 UTC
NIO 2.0 == Ant 2.0? was Re: Java NIO support
I actually wanted to discuss Java 7 on the list. I went through its
features a while ago and got really excited when I read through NIO 2.0.
It does so much that Ant has to struggle with, and so much that Ant
can't do.
I spent some time starting to implement a very simple (only a few tasks)
new version of Ant that started from Java 7. Personal issues have taken
me out of the game for a while, but I've still been wondering, could
Java 7 and NIO 2.0 be a good reason to create Ant 2.0?
I realize I am violating "Shut up and show me the code". While I
personally won't be able to help much for the foreseeable future, I've
seen communities be revitalized by creating a new codebase. It attracts
new committers who have been annoyed by the previous bug/feature
combinations and get excited about the possibilities of helping to
create a new codebase. Cocoon did it twice, although I wouldn't
recommend that because the people attracted by Cocoon 2.2 went away
because they felt their efforts were wasted thanks to Cocoon 3.0.
It could be a way to sweep away the kind of cruft that is holding up the
release and to redesign Ant to reflect all the lessons learned about how
to build software in the last 10 years. Or it could be I'm the only one
who read through the NIO 2.0 features and instantly thought about
rewriting Ant.
What do you guys think about it?
On 2/5/2012 11:25 PM, Stefan Bodewig wrote:
> On 2012-02-05, Mansour Al Akeel wrote:
>
>> I have been looking and developing some custom task for ant, for the last
>> few days. I noticed that ant tasks don't use java.io directly. I am
>> assuming this is due to the way java.io.File behave on different platforms,
>> and the support for patterns .... etc.
> You must not forget that parts of Ant have been written at a time where
> Java2 was too new to require it as runtime environment.
>
>> However, now with java 7, we have the Path class that is very convenient to
>> use. I think having this will make writing tasks easier, by cuting down the
>> steps to convert between ants Path and java.nio.file.Path.
>> Are there any interests ?
> Yes, there is.
>
> Just now we have voted to accept Java5 (yes, 5, not 7) as our minimum
> requirement for Ant's trunk following the upcoming 1.8.3 release. This
> means we can not use Java7 features directly.
>
> One approach that may be possible is to write a FileUtils replacement
> using Java7 features. Almost all file system interactions of Ant go
> through FileUtils and Ant's core could detect at runtime whether Java7
> is around and use the matching FileUtils class.
>
> 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: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 16 févr. 2012 à 20:49, Mansour Al Akeel a écrit :
> 2012/2/16 Nicolas Lalevée <ni...@hibnet.org>
>
>>
>>
>> I cannot talk about Gradle because I never really understand the real
>> motive apart from the apparent cool groovy language features.
>>
>> On the other hand, Easyant is about using Ant on steroïds. The idea is
>> basically sharing Ant build scripts.
>> Each time I have to make a build of a Java webapp, I don't write my
>> build.xml from scratch each time. I look up for an old project I used to
>> work on, I copy its build and keep the interesting parts, I rehack the
>> build scripts. So with some convention and for very similar projects, we
>> could share theses scripts. Easyant does "just" this with Ivy.
>>
>
> I used gradle and don't see the reason for it except for the multi module
> support. And yes, it's slow. For a continuous build like (on file change,
> compile, build, and let jrebel reload), It's tooooo slow for me.
>
> I understand that easyant makes reusable build available, but I think the
> multi project support (in gradle), the groovy feature (in gradle), and the
> reusable tasks (in easyant), can all be done with antlib. Why did their
> teams created a new build system, rather than antlib ?
Easyant doesn't per se provide reusable tasks, that is effectively the role of antlibs, but it better provides a standard build workflow, it provides targets. Extension points which makes target reusable were introduced in Ant after some prototyping in Easyant actually.
I guess that a proper multi project support involves some build workflow management, so working with targets. I doubt it is feasible with just antlibs.
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by "Steele, Richard" <ri...@steelezone.net>.
On Thu, Feb 16, 2012 at 2:49 PM, Mansour Al Akeel <mansour.alakeel@gmail.com
> wrote:
> >
> > 2012/2/16 Nicolas Lalevée <ni...@hibnet.org>
> >
> > implementation are, but a 1s launch (bash script and jvm launch included)
> > would be to too long for me.
> >
>
Agreed.
> > And this is why I suggested java plugin framework in a previous email
> (assuming it is faster than OSGI). I read that there are some fast OSGI
> implementations. Didn't try anything yet.
>
I'm neither an OSGi fan or bigot, but in my experience OSGi itself, as a
specification, does not imply poor performance. There are some aspects of
the OSGi runtime package wiring specification that are NP-complete, but
this typically doesn't hurt real performance unless you have a system of
thousands of bundles like Eclipse. I would hope something like Ant never
got that far. In particular, loading the actual OSGi runtime is very fast,
on the order of milliseconds. Keep in mind that the original OSGi runtime
environment was (and still is) embedded systems with limited memory and
CPU. How the application is designed, such as the degree of modularity, is
ultimately the biggest determinant of performance. To that end I don't
know if we could compare an (as yet unknown) standard Java modularity
system) to OSGi, but I would be surprised if the native system was
significantly more performant--unless it gave up some of the invaluable
features that OSGi provides.
As an aside, and speaking of Eclipse, you would want to keep in mind how to
embed an Ant containing an OSGi runtime inside Eclipse. This isn't
impossible, but it could lead to some interesting classloader hierarchies.
Rich
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Mansour Al Akeel <ma...@gmail.com>.
2012/2/16 Nicolas Lalevée <ni...@hibnet.org>
>
>
> I cannot talk about Gradle because I never really understand the real
> motive apart from the apparent cool groovy language features.
>
> On the other hand, Easyant is about using Ant on steroïds. The idea is
> basically sharing Ant build scripts.
> Each time I have to make a build of a Java webapp, I don't write my
> build.xml from scratch each time. I look up for an old project I used to
> work on, I copy its build and keep the interesting parts, I rehack the
> build scripts. So with some convention and for very similar projects, we
> could share theses scripts. Easyant does "just" this with Ivy.
>
I used gradle and don't see the reason for it except for the multi module
support. And yes, it's slow. For a continuous build like (on file change,
compile, build, and let jrebel reload), It's tooooo slow for me.
I understand that easyant makes reusable build available, but I think the
multi project support (in gradle), the groovy feature (in gradle), and the
reusable tasks (in easyant), can all be done with antlib. Why did their
teams created a new build system, rather than antlib ?
This is my question.
>
> > Is there something wrong with antlib ? Would OSGI be more convenient and
> > appealing for programmers to create and contribute their plugins rather
> > than writing their own build system ? Derivatives of eclipse exists, but
> > mainly they are just bundles of different plugins. Is this because it's
> > OSGI ?
>
> I like this idea of using of modular framework to handle properly
> modularity.
> But what I wouldn't like is having a longer bootstrapping of Ant. For
> instance gradle is boring long to launch, even for printing the inline
> help. The groovy frontend of Ant suffers for the same issues, unusable for
> me. I don't have much experience with OSGi systems, I don't know how fast
> some
>
> 2012/2/16 Nicolas Lalevée <ni...@hibnet.org>
>
> implementation are, but a 1s launch (bash script and jvm launch included)
> would be to too long for me.
>
> And this is why I suggested java plugin framework in a previous email
(assuming it is faster than OSGI). I read that there are some fast OSGI
implementations. Didn't try anything yet.
> Nicolas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 15 févr. 2012 à 20:05, Mansour Al Akeel a écrit :
> Another thing I don't understand about the current Ant. Why there are
> derivatives from ant and they are gaining popularity ? I am talking about
> gradle and easyant.
>
> Gradle adds mutli project support, and easyant sets some conventions (I
> didn't use it). I am wondering what makes the author go with a new build
> system, if things like this can be done with antlib. And why would users
> switch to these systems. I like writing my custom tasks and wrap them in an
> antlib. But why others are not doing the same to add multi project support,
> or set some conventions ?
I cannot talk about Gradle because I never really understand the real motive apart from the apparent cool groovy language features.
On the other hand, Easyant is about using Ant on steroïds. The idea is basically sharing Ant build scripts.
Each time I have to make a build of a Java webapp, I don't write my build.xml from scratch each time. I look up for an old project I used to work on, I copy its build and keep the interesting parts, I rehack the build scripts. So with some convention and for very similar projects, we could share theses scripts. Easyant does "just" this with Ivy.
> Is there something wrong with antlib ? Would OSGI be more convenient and
> appealing for programmers to create and contribute their plugins rather
> than writing their own build system ? Derivatives of eclipse exists, but
> mainly they are just bundles of different plugins. Is this because it's
> OSGI ?
I like this idea of using of modular framework to handle properly modularity.
But what I wouldn't like is having a longer bootstrapping of Ant. For instance gradle is boring long to launch, even for printing the inline help. The groovy frontend of Ant suffers for the same issues, unusable for me. I don't have much experience with OSGi systems, I don't know how fast some implementation are, but a 1s launch (bash script and jvm launch included) would be to too long for me.
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Bruce Atherton <br...@callenish.com>.
On 2/15/2012 5:48 PM, Bruce Atherton wrote:
> I've read a blog post that said that one of the requirements that has
> been adopted is OSGI compatibility...
>
Here is the post I mentioned:
http://osgithoughts.blogspot.com/2011/05/java-se-8-modularity-requirements.html
It brings up a good point: a system architected with modularity in mind
is fundamentally different from a system that isn't. Ant 1.x is modular,
but there are many different kinds of modularity introduced over time
and it can be hard to keep track of which files need to be modified to
add a particular build file element. Some are pluggable, some load from
a properties list, etc. Sometimes, particularly for backward API
compatibility, you need to add a new element to more than one place and
it can be easy to miss one.
Having a single module system for the whole system that is compatible
with what is expected in Java 8, with the option of plugging OSGI in to
replace it, seems like a good solution to me. When Java 8 is the lowest
supported JVM of Ant 2 (sometime 5 years from now based on previous
experience) we can drop our solution and use whatever is bundled as the
default.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Bruce Atherton <br...@callenish.com>.
Those changes you have sound useful. Good luck with getting them
cleared, I'm sure a number of people would appreciate having access to
those hooks.
I think adding the standard packaging and deployment mechanism of Java 8
to Antlibs once 8 comes out makes a lot of sense. Once that happens
someone could give the results from testing with some of the standard
JARs that Ant Users prefer. Or perhaps the JRE will bundle one that
everyone uses by default.
That is if it makes it into the release. JSR 277 and JSR 294 had high
hopes to start that process but they are both now marked as inactive.
Project Jigsaw[1] appears to be an important target for Java 8[2] and
I've read a blog post that said that one of the requirements that has
been adopted is OSGI compatibility. So hopefully it will.
[1] http://openjdk.java.net/projects/jigsaw/
[2] http://openjdk.java.net/projects/jdk8/
On 2/15/2012 4:05 PM, Jeffrey E Care wrote:
>
> The only problem I have with the antlib mechanism is that you have to
> specifically call out the antlib(s) you want to use. That's not a problem
> in build.xmls, as I would think that most people would want the namespace
> binding; but consider things like version information& diagnostics
> providers: presently there's no hook for an antlib to contribute to the
> version information or diags, even if the JAR containing the antlib is in
> Ant's lib directory (or elsewhere on the classpath). Fortunately for these
> cases META-INF/services provides a good enough mechanism. I have a
> contribution for Ant that will add hook points for antlibs to contribute
> to the version info& diags but I can't seem to get it cleared through IBM
> legal :(
>
> I don't know of a compelling reason to add a heavyweight plugin mechanism
> like OSGi.
>
> --
> JEC
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Jeffrey E Care <ca...@us.ibm.com>.
Mansour Al Akeel <ma...@gmail.com> wrote on 02/15/2012 02:05:28
PM:
> Is there something wrong with antlib ? Would OSGI be more convenient and
> appealing for programmers to create and contribute their plugins rather
> than writing their own build system ? Derivatives of eclipse exists, but
> mainly they are just bundles of different plugins. Is this because it's
> OSGI ?
The only problem I have with the antlib mechanism is that you have to
specifically call out the antlib(s) you want to use. That's not a problem
in build.xmls, as I would think that most people would want the namespace
binding; but consider things like version information & diagnostics
providers: presently there's no hook for an antlib to contribute to the
version information or diags, even if the JAR containing the antlib is in
Ant's lib directory (or elsewhere on the classpath). Fortunately for these
cases META-INF/services provides a good enough mechanism. I have a
contribution for Ant that will add hook points for antlibs to contribute
to the version info & diags but I can't seem to get it cleared through IBM
legal :(
I don't know of a compelling reason to add a heavyweight plugin mechanism
like OSGi.
--
JEC
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Mansour Al Akeel <ma...@gmail.com>.
Another thing I don't understand about the current Ant. Why there are
derivatives from ant and they are gaining popularity ? I am talking about
gradle and easyant.
Gradle adds mutli project support, and easyant sets some conventions (I
didn't use it). I am wondering what makes the author go with a new build
system, if things like this can be done with antlib. And why would users
switch to these systems. I like writing my custom tasks and wrap them in an
antlib. But why others are not doing the same to add multi project support,
or set some conventions ?
Is there something wrong with antlib ? Would OSGI be more convenient and
appealing for programmers to create and contribute their plugins rather
than writing their own build system ? Derivatives of eclipse exists, but
mainly they are just bundles of different plugins. Is this because it's
OSGI ?
This is really another reason that makes me think about forking ant beside
introducing NIO2. I agree with Jesse, there's inconsistency dealing with
different Resource.
With regard to backward compatibility, It is good idea to keep it as "Nice
to have", and try to maintain it as much as possible. The one thing I am
confident it's critical, is the simplicity. For example, I came back to ant
because I wanted to write a task that will be triggered when a file
changes. I was not able to do this with gradle:
http://forums.gradle.org/gradle/topics/runnig_task_programmatically
probably it's a bit early to start thinking about a rewrite. But just to
check available ideas.
On Tue, Feb 14, 2012 at 2:35 PM, Bruce Atherton <br...@callenish.com> wrote:
>
>
> On 2/13/2012 2:55 PM, Jesse Glick wrote:
>
>> On 02/13/2012 01:25 PM, Bruce Atherton wrote:
>>
>>> could Java 7 and NIO 2.0 be a good reason to create Ant 2.0?
>>>
>>
>> While the new java.nio.file.* APIs are indeed valuable for a tool like
>> Ant, I hardly think a fork or major rewrite is required to take advantage
>> of them. As Stefan pointed out, it would be as easy as creating a new
>> FileUtils subclass, and for now compiling it conditionally.
>>
>
> Required, no. If there is not enough interest in creating an Ant 2 then
> everything will be fine staying with Ant 1.x. We've been doing it through
> massive changes in the Java libraries and we can keep doing it the same
> way. If there aren't enough people interested in doing the work then we
> should just drop it.
>
> But I've talked about a few of the advantages I see in dropping backward
> API compatibility and doing a major refactoring. Let me list a few more.
>
> My biggest problem with Ant is the many ways that files are dealt with. It
> is all over the map. This isn't anyone's fault, it happened because of
> hysterical porpoises, but both our users and ourselves have to deal with
> the fallout.
>
> Users have to deal with understanding the differences between paths and
> filelists and filesets and dirsets and resources. They have to come to
> grips with how <include> and <exclude> don't work like selectors. Filters
> aren't much better since there are different ways that they can work.
>
> We have it a bit easier because under the covers most things have been
> normalized. Resources, for example. But thanks to API compatibility that
> brings its own problems. For example, we have two completely separate yet
> very similar set of classes for Selectors, one for FileSelectors and one
> for ResourceSelectors. Fix a bug in one, did you remember to fix it in the
> other? Does it matter if users of the FileSelector APIs still have the bug?
>
> Or look at the utility classes. How many methods, or lines of extra code
> in methods that should be relatively simple, are devoted to dealing with
> edge cases and these hangers on from our past?
>
> All of these things were an itch bad enough that I started to scratch it,
> but for now I won't be doing any coding at all for a while. Maybe, though,
> there are others who are as bothered by these things as I am who are
> looking for a scratching post.
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Bruce Atherton <br...@callenish.com>.
On 2/13/2012 2:55 PM, Jesse Glick wrote:
> On 02/13/2012 01:25 PM, Bruce Atherton wrote:
>> could Java 7 and NIO 2.0 be a good reason to create Ant 2.0?
>
> While the new java.nio.file.* APIs are indeed valuable for a tool like
> Ant, I hardly think a fork or major rewrite is required to take
> advantage of them. As Stefan pointed out, it would be as easy as
> creating a new FileUtils subclass, and for now compiling it conditionally.
Required, no. If there is not enough interest in creating an Ant 2 then
everything will be fine staying with Ant 1.x. We've been doing it
through massive changes in the Java libraries and we can keep doing it
the same way. If there aren't enough people interested in doing the work
then we should just drop it.
But I've talked about a few of the advantages I see in dropping backward
API compatibility and doing a major refactoring. Let me list a few more.
My biggest problem with Ant is the many ways that files are dealt with.
It is all over the map. This isn't anyone's fault, it happened because
of hysterical porpoises, but both our users and ourselves have to deal
with the fallout.
Users have to deal with understanding the differences between paths and
filelists and filesets and dirsets and resources. They have to come to
grips with how <include> and <exclude> don't work like selectors.
Filters aren't much better since there are different ways that they can
work.
We have it a bit easier because under the covers most things have been
normalized. Resources, for example. But thanks to API compatibility that
brings its own problems. For example, we have two completely separate
yet very similar set of classes for Selectors, one for FileSelectors and
one for ResourceSelectors. Fix a bug in one, did you remember to fix it
in the other? Does it matter if users of the FileSelector APIs still
have the bug?
Or look at the utility classes. How many methods, or lines of extra code
in methods that should be relatively simple, are devoted to dealing with
edge cases and these hangers on from our past?
All of these things were an itch bad enough that I started to scratch
it, but for now I won't be doing any coding at all for a while. Maybe,
though, there are others who are as bothered by these things as I am who
are looking for a scratching post.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Jesse Glick <je...@oracle.com>.
On 02/13/2012 01:25 PM, Bruce Atherton wrote:
> could Java 7 and NIO 2.0 be a good reason to create Ant 2.0?
While the new java.nio.file.* APIs are indeed valuable for a tool like Ant, I hardly think a fork or major rewrite is required to take advantage of them. As Stefan
pointed out, it would be as easy as creating a new FileUtils subclass, and for now compiling it conditionally. Whenever we drop JDK 5 and 6 support and require JDK 7
(which BTW is soon to be available for all major platforms when the Mac version is released), it will be simple to make that be the standard impl.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Jeffrey E Care <ca...@us.ibm.com>.
Bruce Atherton <br...@callenish.com> wrote on 02/13/2012 01:25:30 PM:
> I actually wanted to discuss Java 7 on the list. I went through its
> features a while ago and got really excited when I read through NIO 2.0.
> It does so much that Ant has to struggle with, and so much that Ant
> can't do.
>
> I spent some time starting to implement a very simple (only a few tasks)
> new version of Ant that started from Java 7. Personal issues have taken
> me out of the game for a while, but I've still been wondering, could
> Java 7 and NIO 2.0 be a good reason to create Ant 2.0?
>
> ...
>
> It could be a way to sweep away the kind of cruft that is holding up the
> release and to redesign Ant to reflect all the lessons learned about how
> to build software in the last 10 years. Or it could be I'm the only one
> who read through the NIO 2.0 features and instantly thought about
> rewriting Ant.
I think you have to enumerate what you want to accomplish with a complete
rewrite and what the compelling reasons are for such an undertaking.
I agree that there are many compelling features in NIO 2 that I would like
to see leveraged in Ant but I have to say that I'm not seeing a straight
line from NIO 2 to a complete rewrite of Ant. For a less drastic approach
maybe we could re-write only those tasks that would benefit the most from
NIO 2's features. Put them in a different package and perhaps even put
them in their own antlib.
Putting task implementations to the side, what is there in the core of Ant
that would benefit from NIO 2 or other parts of JDK 7?
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 16 févr. 2012 à 21:08, Bruce Atherton a écrit :
> It has but not for quite a long time. Look in the archives from 2001 to 2003 for "Mutant"[1] which Conor proposed, and "Myrmidon"[2] which Peter Donald proposed back in 2000. You can still find them in the svn repository[3], [4].
>
> I think there was so much discussion on a new design of Ant that everyone just got exhausted talking about it. As I recall what finally brought it to a halt was Costin Manolache saying "Just refactor what you have while retaining backward compatibility."
>
> The general agreements that I remember, although I haven't trawled the mailing list to find references, were that backward binary compatibility could only be broken through an Ant 2.0 release, and that Ant 2.0 should do everything in its power to be build file compatible. The thinking then was an XSLT file could be provided if necessary although at this point I think we could provide an <upgrade-buildfile> task even if it just ran an XSLT, should that prove necessary. But I don't think it should be required if possible, at least not for several minor releases.
I agree, the build file should be maintained compatible. As I wrote earlier a "version" tag should do the trick if new features need to break it a little bit, no version tag would mean it is a <2.0 build file.
> This is a new group of Ant developers, though, and they may make different decisions than the ones back then did. If we find volunteers willing to step forward to help with the code. I can do the infrastructure things like setting up a place to put everything in subversion, perhaps in ant/sandbox/{some code name}. Any suggestions? All I can think of is pezant or something similarly punny. It could just be ant2proposal.
If it goes further, I will be happy to keep a eye around and discuss about it but I won't be able to write any code.
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Bruce Atherton <br...@callenish.com>.
It has but not for quite a long time. Look in the archives from 2001 to
2003 for "Mutant"[1] which Conor proposed, and "Myrmidon"[2] which
Peter Donald proposed back in 2000. You can still find them in the svn
repository[3], [4].
I think there was so much discussion on a new design of Ant that
everyone just got exhausted talking about it. As I recall what finally
brought it to a halt was Costin Manolache saying "Just refactor what you
have while retaining backward compatibility."
The general agreements that I remember, although I haven't trawled the
mailing list to find references, were that backward binary compatibility
could only be broken through an Ant 2.0 release, and that Ant 2.0 should
do everything in its power to be build file compatible. The thinking
then was an XSLT file could be provided if necessary although at this
point I think we could provide an <upgrade-buildfile> task even if it
just ran an XSLT, should that prove necessary. But I don't think it
should be required if possible, at least not for several minor releases.
This is a new group of Ant developers, though, and they may make
different decisions than the ones back then did. If we find volunteers
willing to step forward to help with the code. I can do the
infrastructure things like setting up a place to put everything in
subversion, perhaps in ant/sandbox/{some code name}. Any suggestions?
All I can think of is pezant or something similarly punny. It could just
be ant2proposal.
As for whether it is a runtime issue, as far as I know the only problem
with libraries is the bootstrap build. If Ant 2's bootstrap build is
done by Ant 1 there is no problem with adding any libraries you want to
the core of Ant 2. If it is self-hosted then Ant 2 needs to be capable
of running without any external libraries.
This is why the Ant 1.x codebase has a Java tar and zip and bzip2
implementation hosted within it, even though Apache Commons has superior
implementations of all of them. Ant source is distributed in these
formats so Ant needs a bootstrap way to get at it. Stefan maintains the
compress AntLib for exactly this reason, so Ant can have access to a
really good, full featured compression library.
[1] http://marc.info/?l=ant-dev&m=98934355711364&w=2
[2] http://marc.info/?l=ant-dev&m=97593652718829&w=2
[3]
http://svn.apache.org/viewvc/ant/core/tags/ANT_152_FINAL/proposal/mutant/
[4] http://svn.apache.org/viewvc/ant/core/tags/ANT_141/proposal/myrmidon/
On 2/13/2012 1:30 PM, Mansour Al Akeel wrote:
> interesting info. It looks like the idea of the redesign has been discussed
> a lot in the past.
> Another good point, is to have ant independent of any external libraries.
> However, I am wondering if this applies to run time environment ?
> For example, writing a core ant (mainly build.xml parser), as an osgi
> bundle. And collection of bundles for Javac, Java, Copy,... etc. would:
>
> 1- be independent of any external libraries and relies on JRE to build.
> 2- allow integration with IDEs.
> 3- allow to compile and build the build system, without a build system (ie,
> using bootstrap). or like you said "self-building".
>
> Would this be acceptable idea ? A core bundle, and extra bundles for basic
> tasks. A bundle for ivy (maybe). We can even have a bundle to install
> additional bundles remotely....
> And with Java7 NIO the performance will be fine.
>
> comments ?
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Mansour Al Akeel <ma...@gmail.com>.
interesting info. It looks like the idea of the redesign has been discussed
a lot in the past.
Another good point, is to have ant independent of any external libraries.
However, I am wondering if this applies to run time environment ?
For example, writing a core ant (mainly build.xml parser), as an osgi
bundle. And collection of bundles for Javac, Java, Copy,... etc. would:
1- be independent of any external libraries and relies on JRE to build.
2- allow integration with IDEs.
3- allow to compile and build the build system, without a build system (ie,
using bootstrap). or like you said "self-building".
Would this be acceptable idea ? A core bundle, and extra bundles for basic
tasks. A bundle for ivy (maybe). We can even have a bundle to install
additional bundles remotely....
And with Java7 NIO the performance will be fine.
comments ?
On Mon, Feb 13, 2012 at 4:04 PM, Bruce Atherton <br...@callenish.com> wrote:
> This brings up a point to consider if a rewrite is desired. Ant has always
> avoided relying on external libraries because it is usually the first thing
> in the build chain. It can't have any dependencies itself if it is to be
> self-building. There are tasks that require external libraries to be
> compiled, yes, but they are all optional. That is why there is a bootstrap
> build before the full build. The only libraries you can rely on being there
> are the ones that ship with the JRE.
>
> This could change in Ant 2 if people wanted but I think we'd need a
> strategy for it. For example, there was a lot of talk at one point about
> moving the package name from org.apache.tools.ant.* to org.apache.ant.*.
> Doing this would allow both Ant 1.x and Ant 2 to exist in the same program
> (like IDEs), and it would allow a bootstrap Ant 1.x to build Ant 2. Doing
> that would allow the use of libraries.
>
> I'm sure there could be other solutions as well, but I don't think anyone
> should automatically assume that non-optional libraries will be available
> until it is decided that that will happen. Assuming anything happens.
>
>
> On 2/13/2012 12:02 PM, Jeffrey E Care wrote:
>
>> Mansour Al Akeel <ma...@gmail.com> wrote on 02/13/2012
>> 01:57:56 PM:
>>
>> > From: Mansour Al Akeel <ma...@gmail.com>
>> > To: Ant Developers List <de...@ant.apache.org>
>> > Cc: Stefan Bodewig <bo...@apache.org>
>> > Date: 02/13/2012 01:58 PM
>> > Subject: Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
>> >
>> > Bruce,
>> > In fact I was thinking about the same thing. The idea of forking Ant and
>> > rewrite parts of it to use Java 7 NIO, and introduce java plugin frame
>> > work http://jpf.sourceforge.net/**crossed<http://jpf.sourceforge.net/crossed>my mind few times.
>>
>>
>> Why JPF instead of OSGi or whatever extensibility mechanism is working
>> it's way through the JCP for Java 8? IMO the idea of basing an Ant re-write
>> on some dubiously supported clone of Eclipse's plugin mechanism from 8
>> years ago isn't very appealing.
>> ______________________________**______________________________**
>> ______________________________**__
>> Jeffrey E. (Jeff) Care
>> _carej@us.ibm.com_ <ma...@us.ibm.com>
>>
>> IBM WebSphere Application Server
>> WAS Release Engineering
>>
>>
>> WebSphere Mosiac
>> WebSphere Brandmark
>>
>>
>>
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Bruce Atherton <br...@callenish.com>.
This brings up a point to consider if a rewrite is desired. Ant has
always avoided relying on external libraries because it is usually the
first thing in the build chain. It can't have any dependencies itself if
it is to be self-building. There are tasks that require external
libraries to be compiled, yes, but they are all optional. That is why
there is a bootstrap build before the full build. The only libraries you
can rely on being there are the ones that ship with the JRE.
This could change in Ant 2 if people wanted but I think we'd need a
strategy for it. For example, there was a lot of talk at one point
about moving the package name from org.apache.tools.ant.* to
org.apache.ant.*. Doing this would allow both Ant 1.x and Ant 2 to exist
in the same program (like IDEs), and it would allow a bootstrap Ant 1.x
to build Ant 2. Doing that would allow the use of libraries.
I'm sure there could be other solutions as well, but I don't think
anyone should automatically assume that non-optional libraries will be
available until it is decided that that will happen. Assuming anything
happens.
On 2/13/2012 12:02 PM, Jeffrey E Care wrote:
> Mansour Al Akeel <ma...@gmail.com> wrote on 02/13/2012
> 01:57:56 PM:
>
> > From: Mansour Al Akeel <ma...@gmail.com>
> > To: Ant Developers List <de...@ant.apache.org>
> > Cc: Stefan Bodewig <bo...@apache.org>
> > Date: 02/13/2012 01:58 PM
> > Subject: Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
> >
> > Bruce,
> > In fact I was thinking about the same thing. The idea of forking Ant and
> > rewrite parts of it to use Java 7 NIO, and introduce java plugin frame
> > work http://jpf.sourceforge.net/crossed my mind few times.
>
> Why JPF instead of OSGi or whatever extensibility mechanism is working
> it's way through the JCP for Java 8? IMO the idea of basing an Ant
> re-write on some dubiously supported clone of Eclipse's plugin
> mechanism from 8 years ago isn't very appealing.
> ____________________________________________________________________________________________
>
> Jeffrey E. (Jeff) Care
> _carej@us.ibm.com_ <ma...@us.ibm.com>
> IBM WebSphere Application Server
> WAS Release Engineering
>
>
> WebSphere Mosiac
> WebSphere Brandmark
>
>
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Mansour Al Akeel <ma...@gmail.com>.
good point Jeff.
I just though about the performance. I am not sure what would be the
performance for JPF compared to OSGI. But your are very correct. That's why
we discuss this on the mailing list. In all cases, these are just thoughts,
and I don't know if there's enough interest in these ideas.
On Mon, Feb 13, 2012 at 3:02 PM, Jeffrey E Care <ca...@us.ibm.com> wrote:
> Mansour Al Akeel <ma...@gmail.com> wrote on 02/13/2012 01:57:56
> PM:
>
> > From: Mansour Al Akeel <ma...@gmail.com>
> > To: Ant Developers List <de...@ant.apache.org>
> > Cc: Stefan Bodewig <bo...@apache.org>
> > Date: 02/13/2012 01:58 PM
> > Subject: Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
> >
> > Bruce,
> > In fact I was thinking about the same thing. The idea of forking Ant and
> > rewrite parts of it to use Java 7 NIO, and introduce java plugin frame
> > work http://jpf.sourceforge.net/ crossed my mind few times.
>
> Why JPF instead of OSGi or whatever extensibility mechanism is working
> it's way through the JCP for Java 8? IMO the idea of basing an Ant re-write
> on some dubiously supported clone of Eclipse's plugin mechanism from 8
> years ago isn't very appealing.
> ____________________________________________________________________________________________
> Jeffrey E. (Jeff) Care
> *carej@us.ibm.com* <ca...@us.ibm.com>
> IBM WebSphere Application Server
> WAS Release Engineering
>
> [image: WebSphere Mosiac]
> [image: WebSphere Brandmark]
>
>
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Jeffrey E Care <ca...@us.ibm.com>.
Mansour Al Akeel <ma...@gmail.com> wrote on 02/13/2012 01:57:56
PM:
> From: Mansour Al Akeel <ma...@gmail.com>
> To: Ant Developers List <de...@ant.apache.org>
> Cc: Stefan Bodewig <bo...@apache.org>
> Date: 02/13/2012 01:58 PM
> Subject: Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
>
> Bruce,
> In fact I was thinking about the same thing. The idea of forking Ant and
> rewrite parts of it to use Java 7 NIO, and introduce java plugin frame
> work http://jpf.sourceforge.net/ crossed my mind few times.
Why JPF instead of OSGi or whatever extensibility mechanism is working
it's way through the JCP for Java 8? IMO the idea of basing an Ant
re-write on some dubiously supported clone of Eclipse's plugin mechanism
from 8 years ago isn't very appealing.
____________________________________________________________________________________________
Jeffrey E. (Jeff) Care
carej@us.ibm.com
IBM WebSphere Application Server
WAS Release Engineering
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Mansour Al Akeel <ma...@gmail.com>.
Bruce,
In fact I was thinking about the same thing. The idea of forking Ant and
rewrite parts of it to use Java 7 NIO, and introduce java plugin frame
work http://jpf.sourceforge.net/ crossed my mind few times.
On Mon, Feb 13, 2012 at 1:25 PM, Bruce Atherton <br...@callenish.com> wrote:
> I actually wanted to discuss Java 7 on the list. I went through its
> features a while ago and got really excited when I read through NIO 2.0. It
> does so much that Ant has to struggle with, and so much that Ant can't do.
>
> I spent some time starting to implement a very simple (only a few tasks)
> new version of Ant that started from Java 7. Personal issues have taken me
> out of the game for a while, but I've still been wondering, could Java 7
> and NIO 2.0 be a good reason to create Ant 2.0?
>
> I realize I am violating "Shut up and show me the code". While I
> personally won't be able to help much for the foreseeable future, I've seen
> communities be revitalized by creating a new codebase. It attracts new
> committers who have been annoyed by the previous bug/feature combinations
> and get excited about the possibilities of helping to create a new
> codebase. Cocoon did it twice, although I wouldn't recommend that because
> the people attracted by Cocoon 2.2 went away because they felt their
> efforts were wasted thanks to Cocoon 3.0.
>
> It could be a way to sweep away the kind of cruft that is holding up the
> release and to redesign Ant to reflect all the lessons learned about how to
> build software in the last 10 years. Or it could be I'm the only one who
> read through the NIO 2.0 features and instantly thought about rewriting Ant.
>
> What do you guys think about it?
>
> On 2/5/2012 11:25 PM, Stefan Bodewig wrote:
>
>> On 2012-02-05, Mansour Al Akeel wrote:
>>
>> I have been looking and developing some custom task for ant, for the last
>>> few days. I noticed that ant tasks don't use java.io directly. I am
>>> assuming this is due to the way java.io.File behave on different
>>> platforms,
>>> and the support for patterns .... etc.
>>>
>> You must not forget that parts of Ant have been written at a time where
>> Java2 was too new to require it as runtime environment.
>>
>> However, now with java 7, we have the Path class that is very convenient
>>> to
>>> use. I think having this will make writing tasks easier, by cuting down
>>> the
>>> steps to convert between ants Path and java.nio.file.Path.
>>> Are there any interests ?
>>>
>> Yes, there is.
>>
>> Just now we have voted to accept Java5 (yes, 5, not 7) as our minimum
>> requirement for Ant's trunk following the upcoming 1.8.3 release. This
>> means we can not use Java7 features directly.
>>
>> One approach that may be possible is to write a FileUtils replacement
>> using Java7 features. Almost all file system interactions of Ant go
>> through FileUtils and Ant's core could detect at runtime whether Java7
>> is around and use the matching FileUtils class.
>>
>> 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: Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)
Posted by Bruce Atherton <br...@callenish.com>.
Unit testing has long been considered important for Ant. A published
report a few years ago (can't find it now) showed our code coverage was
among the highest of the open source projects that they reported on, as
I recall. It has often happened that committers push back on code
submissions asking that unit tests be included.
Other types of tests are welcome too, though. Integration tests such as
you suggest for plugins, functional tests across classes. My own
preference in development generally is to create a regression test for
each bug report before fixing it to make sure it doesn't come back to
bite us. But of course all of that is up to the people who make code
submissions. The overhead of maintaining a large testing suite in open
source projects tends to limit them to unit tests + some other tests for
expected pain points.
> How easy is't to unit test additional plugins. When you rely a lot on
> context, you need to create a similar context for testing.
> Is't going to be easy ? Writing and testing tasks independently will
> allow a lot of plugins to exist.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)
Posted by Mansour Al Akeel <ma...@gmail.com>.
On Sat, Feb 18, 2012 at 6:03 PM, Bruce Atherton <br...@callenish.com> wrote:
> I have similar thoughts on the high level abstract view of Ant. Here is how
> I see it:
>
> 1. Command Line Processor
> 2. Build File Parser
> 3. Dependency Tree Resolver
> - This is essentially a Dependency Injection/IOC system, but with late
> binding (Unknown Element) and modification through things like macros done
> in later phases
> 4. Dependency Analyzer
> - Generates the queue of ProjectComponents to execute incrementally based
> on if/unless and dependencies
> 5. Execution Engine
> - May call back into 2, 3, or 4
> 6. Monitoring System
> - logs, BuildEvents, etc)
>
> Note that this is just conceptual and not reflecting how things are actually
> implemented in Ant 1.
>
> As I understand Gilles suggestion, he'd like to see something more like
> this:
>
> 1. Command Line Processor
> 2. Build File Parser
> 3. Translation into State Machine
> 4. Execution of State Machine
> - This can modify itself as it processes. This would include resolving
> UnknownElement, deleting transitions based on if/unless, allowing the
> altering and additions of transitions to control new dependencies, inserting
> macro subtrees, parsing and adding new build files, etc, etc.
How easy is't to unit test additional plugins. When you rely a lot on
context, you need to create a similar context for testing.
Is't going to be easy ? Writing and testing tasks independently will
allow a lot of plugins to exist.
> 5. Monitoring System (logs, BuildEvents, etc)
>
> This design looks a lot simpler to me than the first one. As I think about
> it more I'm starting to like it.
>
> As for automating parallelism, if you know what resources are needed and in
> which state, and you know which ProjectComponents will get the resources
> into that state for you, then it is possible for an application to determine
> which ones can run in parallel rather than sequentially. Obviously there is
> a lot of handwaving in there.
>
>
> On 2/18/2012 1:13 PM, Mansour Al Akeel wrote:
>>
>> Bruce,
>>
>> The current design is simple, and proven successful and easy to
>> maintain. Here's a quick pseudo:
>>
>> 1- parse the build file, initializing all the "DataStructures" and
>> references to the tasks and macros. Populate them all to the running
>> context. Maybe OSGI has something like this.
>>
>> 2- if there's sub modules declared then do the same, and populate them
>> all the current context, adding name space to the references for the
>> tasks in the sub modules. For example assuming the current project has
>> a task called "build", then the one for the sub module will be
>> "submodule1:build". (assuming you want multi module support built-in
>> and not added by an OSGI bundle).
>>
>> 3- If you want parent project support then we can do the same.
>>
>> 4- Depeding on the task called, execute the corresponding task and
>> pass it an object of the Data Structure you want to process. The
>> reason for this is to make it easy to unit test it.
>>
>> 5- additional tasks and dataType can be added through OSGI bundles.
>> For example, let's say I want a task to compile a war file, I can just
>> extend the dataStructure (TypeDef, or any other name), with default
>> values. Write my task, and test the execute method by passing it a
>> reference to my WarDataStructure. Initializing a task requires only
>> the path to the current directory. So instead of passing an object of
>> type (Project), I will just it a path, and it knows the path it should
>> execute in. (This is for multi module).
>>
>> 6- A generic data structure can be used (ie, hashmap) and passed to
>> execute method. This has a copy of all the data initialized in the
>> build file.
>>
>>
>> 7- I am not sure what you mean by parallelism, but I am assuming
>> running more that one task at the same time. This can be added through
>> bundles, but then again, we will run into the same issue like Gradle.
>> If you want a task to run continuously on even (ie, a file change),
>> then you have to write a different task to do so, as parallelism
>> requires a flag to tell if a task has been executed or not. I think
>> the way ant doing it already is the best (ie. using<parallel>).
>>
>> Trying to keep the core as simple as possible, will make maintenance
>> easy, and prevent bugs. Once a bundle proven useful and required
>> always by the users, then it can be merged with the core.
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)
Posted by Bruce Atherton <br...@callenish.com>.
I have similar thoughts on the high level abstract view of Ant. Here is
how I see it:
1. Command Line Processor
2. Build File Parser
3. Dependency Tree Resolver
- This is essentially a Dependency Injection/IOC system, but with
late binding (Unknown Element) and modification through things like
macros done in later phases
4. Dependency Analyzer
- Generates the queue of ProjectComponents to execute incrementally
based on if/unless and dependencies
5. Execution Engine
- May call back into 2, 3, or 4
6. Monitoring System
- logs, BuildEvents, etc)
Note that this is just conceptual and not reflecting how things are
actually implemented in Ant 1.
As I understand Gilles suggestion, he'd like to see something more like
this:
1. Command Line Processor
2. Build File Parser
3. Translation into State Machine
4. Execution of State Machine
- This can modify itself as it processes. This would include
resolving UnknownElement, deleting transitions based on if/unless,
allowing the altering and additions of transitions to control new
dependencies, inserting macro subtrees, parsing and adding new build
files, etc, etc.
5. Monitoring System (logs, BuildEvents, etc)
This design looks a lot simpler to me than the first one. As I think
about it more I'm starting to like it.
As for automating parallelism, if you know what resources are needed and
in which state, and you know which ProjectComponents will get the
resources into that state for you, then it is possible for an
application to determine which ones can run in parallel rather than
sequentially. Obviously there is a lot of handwaving in there.
On 2/18/2012 1:13 PM, Mansour Al Akeel wrote:
> Bruce,
>
> The current design is simple, and proven successful and easy to
> maintain. Here's a quick pseudo:
>
> 1- parse the build file, initializing all the "DataStructures" and
> references to the tasks and macros. Populate them all to the running
> context. Maybe OSGI has something like this.
>
> 2- if there's sub modules declared then do the same, and populate them
> all the current context, adding name space to the references for the
> tasks in the sub modules. For example assuming the current project has
> a task called "build", then the one for the sub module will be
> "submodule1:build". (assuming you want multi module support built-in
> and not added by an OSGI bundle).
>
> 3- If you want parent project support then we can do the same.
>
> 4- Depeding on the task called, execute the corresponding task and
> pass it an object of the Data Structure you want to process. The
> reason for this is to make it easy to unit test it.
>
> 5- additional tasks and dataType can be added through OSGI bundles.
> For example, let's say I want a task to compile a war file, I can just
> extend the dataStructure (TypeDef, or any other name), with default
> values. Write my task, and test the execute method by passing it a
> reference to my WarDataStructure. Initializing a task requires only
> the path to the current directory. So instead of passing an object of
> type (Project), I will just it a path, and it knows the path it should
> execute in. (This is for multi module).
>
> 6- A generic data structure can be used (ie, hashmap) and passed to
> execute method. This has a copy of all the data initialized in the
> build file.
>
>
> 7- I am not sure what you mean by parallelism, but I am assuming
> running more that one task at the same time. This can be added through
> bundles, but then again, we will run into the same issue like Gradle.
> If you want a task to run continuously on even (ie, a file change),
> then you have to write a different task to do so, as parallelism
> requires a flag to tell if a task has been executed or not. I think
> the way ant doing it already is the best (ie. using<parallel>).
>
> Trying to keep the core as simple as possible, will make maintenance
> easy, and prevent bugs. Once a bundle proven useful and required
> always by the users, then it can be merged with the core.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)
Posted by Mansour Al Akeel <ma...@gmail.com>.
Bruce,
The current design is simple, and proven successful and easy to
maintain. Here's a quick pseudo:
1- parse the build file, initializing all the "DataStructures" and
references to the tasks and macros. Populate them all to the running
context. Maybe OSGI has something like this.
2- if there's sub modules declared then do the same, and populate them
all the current context, adding name space to the references for the
tasks in the sub modules. For example assuming the current project has
a task called "build", then the one for the sub module will be
"submodule1:build". (assuming you want multi module support built-in
and not added by an OSGI bundle).
3- If you want parent project support then we can do the same.
4- Depeding on the task called, execute the corresponding task and
pass it an object of the Data Structure you want to process. The
reason for this is to make it easy to unit test it.
5- additional tasks and dataType can be added through OSGI bundles.
For example, let's say I want a task to compile a war file, I can just
extend the dataStructure (TypeDef, or any other name), with default
values. Write my task, and test the execute method by passing it a
reference to my WarDataStructure. Initializing a task requires only
the path to the current directory. So instead of passing an object of
type (Project), I will just it a path, and it knows the path it should
execute in. (This is for multi module).
6- A generic data structure can be used (ie, hashmap) and passed to
execute method. This has a copy of all the data initialized in the
build file.
7- I am not sure what you mean by parallelism, but I am assuming
running more that one task at the same time. This can be added through
bundles, but then again, we will run into the same issue like Gradle.
If you want a task to run continuously on even (ie, a file change),
then you have to write a different task to do so, as parallelism
requires a flag to tell if a task has been executed or not. I think
the way ant doing it already is the best (ie. using <parallel>).
Trying to keep the core as simple as possible, will make maintenance
easy, and prevent bugs. Once a bundle proven useful and required
always by the users, then it can be merged with the core.
On Sat, Feb 18, 2012 at 2:48 PM, Bruce Atherton <br...@callenish.com> wrote:
> Of course you are right, and initially parallelism and distributed builds
> will probably not be in the initial alpha release (unless it is on someones
> scratching list). Just getting something to run existing build files
> reliably will be fine.
>
> But you have suggested that we tag build files that require Ant 2 features
> with something that identifies them as requiring Ant 2. I think this is
> reasonable for the leap from Ant 1 to Ant 2, but one thing HTML has shown is
> that version numbers are an anti-pattern, which is why the DOCTYPE for HTML5
> has done away with them (although that introduced its own "version" ie. no
> version). What is important is the list of features that are needed to
> interpret and run the file correctly.
>
> One can imagine a version tag listing Ant 2 as a minimum for a build file
> with an attribute for a comma separated list of the features that are
> required from Ant for the build. With this and the kind of packaging system
> that OSGI and possibly Java 8 will introduce, Ant could dynamically
> configure itself to load the parallelizing implementation of the state
> machine or the distributed implementation.
>
> So long as the design is flexible enough that the kinds of usecases that
> Dominique and Gilles are suggesting can be implemented eventually, then the
> KISS principle can still be followed.
>
> I would also note that features like DSLs for custom builds, automatic
> parallelism, and distribution to a fault tolerant cluster are exactly the
> kinds of features that would allow many users that I know of to justify
> allocating resources to rewrite major build scripts.
>
>
> On 2/18/2012 11:26 AM, Mansour Al Akeel wrote:
>>
>> Keeping it simple, is a great idea.
>> I am not sure if introducing parallelism is a good idea or if it's
>> easy to implement and maintain.
>>
>> If it is design is modular, I think all these can be added as plugins.
>> Performance ??!!
>>
>>
>> On Sat, Feb 18, 2012 at 1:47 PM, Bruce Atherton<br...@callenish.com>
>> wrote:
>>>
>>> This too I find a great idea. Multicores mean we need more ways of
>>> exploiting parallelism, particularly if they can be identified
>>> automatically
>>> by the application.
>>>
>>> For backward compatibility it would have to be optional, though, either
>>> specified on the command line or at the build file level or using a
>>> different kind of target tag. Of course, the additional information you
>>> suggest on targets would make that the case anyway, but in some cases I
>>> think we might be able to automate it based just on what we have if the
>>> build system is written properly so that dependencies on targets that
>>> provide needed resources are explicitly identified.
>>>
>>> Too many build systems in my experience rely on the order the
>>> dependencies
>>> are resolved on a higher order target rather than explicitly identifying
>>> dependencies on the targets that they are required on. This despite the
>>> fact
>>> that we have some language somewhere that you can't rely on the order of
>>> resolution of the dependencies. Sometimes that has proved a requirement
>>> to
>>> avoid targets that depended on each other, but I've seen it used as a
>>> shortcut instead far too often.
>>>
>>> Creating Ant clusters is also a great idea, at least to plan for. Perhaps
>>> something like Zookeeper to coordinate builds and a message bus like
>>> ActiveMQ or perhaps better QPid to schedule and report back to other
>>> nodes
>>> on the results.
>>>
>>> The idea of turning the dependency tree into a state machine is also
>>> interesting. It would combine the tree and the resolving of the tree with
>>> execution of tasks into a single entity. I worry, though, that some
>>> flexibility in our current system might be lost if the two portions are
>>> combined into one. Perhaps not. It could also introduce the possibility
>>> of
>>> cycles. Currently the dependency tree gets executed as a DAG but there
>>> have
>>> been a lot of requests for looping which a state machine could more
>>> easily
>>> support.
>>>
>>> On 2/18/2012 2:02 AM, Gilles Scokart wrote:
>>>>
>>>> For me, one feature for a 2,0 would be a different style of dependency
>>>> tree that would allow better parallel execution (on the same machine,
>>>> or why not on distributed machines).
>>>> I see the 'targets' being more declarative, becoming a state
>>>> transition saying : I need this resources in that state, I will use
>>>> this other resources (and I don't want the to change during my
>>>> execution, and I will produce this other resources in that other
>>>> state.
>>>>
>>>> The dependency tree would be an logical engine finding the shortest
>>>> path to go to the desired state, using parallel/distributed processing
>>>> when possible.
>>>>
>>>> That's what I miss with existing build system : I want to go as
>>>> quickly as possible to a desired build state (from a current state).
>>>>
>>>>
>>>>
>>>> Gilles Scokart
>>>>
>>>>
>>>>
>>>> On 17 February 2012 20:07, Bruce Atherton<br...@callenish.com> wrote:
>>>>>
>>>>> It doesn't require a rewrite, but a rewrite could simplify integrating
>>>>> a
>>>>> usecase like this as well as integrating other features that we already
>>>>> have
>>>>> into it and making them simpler and unified inthe code. I agree the
>>>>> usecase
>>>>> is an excellent one which could simplify the lives of exactly the type
>>>>> of
>>>>> users I am talking about.
>>>>>
>>>>> It sounds like you are suggesting that the dependency tree be
>>>>> extensible
>>>>> and
>>>>> modifiable, perhaps manipulable, within targets as well so long as that
>>>>> part
>>>>> of the tree hasn't run yet. In a sense that is what macros do because
>>>>> they
>>>>> allow you to swap in some static block of tasks to replace a single
>>>>> task.
>>>>> There is also the feature from EasyAnt for changing target
>>>>> dependencies.
>>>>> But
>>>>> what I'm hearing is that you want more flexibility than that.
>>>>>
>>>>> Something to walk the existing dependency tree, perhaps, with
>>>>> conditional
>>>>> behaviors to modify the metadata on existing element such as
>>>>> dependencies
>>>>> and if/unless, replacing the element with another or a subtree (perhaps
>>>>> itself dynamically walked and created), adding branches, perhaps
>>>>> deleting
>>>>> elements or subtrees. Kind of like what we can do with a tree of files
>>>>> and
>>>>> directories already. Does that sound like what the design you'd like to
>>>>> see
>>>>> would have?
>>>>>
>>>>> And perhaps it could encompass providing both the macro and target
>>>>> dependency changes to the tree as well, along with any other code we
>>>>> have
>>>>> that alters the dependency tree. I'm not sure which of the various ways
>>>>> to
>>>>> call back into Ant do this. I'm sure there are other examples in the
>>>>> codebase.
>>>>>
>>>>> I'm not familiar enough with this part of the code any more to know
>>>>> whether
>>>>> there is already a single elegant solution in Ant 1 that all the code
>>>>> which
>>>>> modifies the dependency tree shares, but given our BC requirements I
>>>>> doubt
>>>>> it.
>>>>>
>>>>> One example of a FileSystemProvider that Java 7 suggests in its API
>>>>> docs
>>>>> is
>>>>> a "memory" file system, one identified by the URL "memory://". Perhaps
>>>>> our
>>>>> dependency tree could be a kind of file system, then we could reuse
>>>>> vast
>>>>> swathes of code we already have, both in the standard class libraries
>>>>> and
>>>>> in
>>>>> Ant itself. Just an idea off the top of my head.
>>>>>
>>>>>
>>>>> On 2/17/2012 5:53 AM, Dominique Devienne wrote:
>>>>>>
>>>>>> 2012/2/17 Bruce Atherton<br...@callenish.com>:
>>>>>>>
>>>>>>> A lot of companies have their own, internally written build file
>>>>>>> generators
>>>>>>> just so their build systems are consistent and exactly what they
>>>>>>> want.
>>>>>>> Our
>>>>>>> Related Projects and External Tools page has some of these that were
>>>>>>> made
>>>>>>> public, I suspect.
>>>>>>>
>>>>>>> Surely there is a better way than requiring users of Ant to write
>>>>>>> generators
>>>>>>> to deal with the complexity and keep it customized.
>>>>>>
>>>>>> At one point I did write a build(s) (XSLT-based) generator
>>>>>> specifically for a large and hairy project. Later I rewrote the whole
>>>>>> thing with macrodefs. But my point is that I don't view build
>>>>>> generators as bad, in fact it often helps IMHO to have a declarative
>>>>>> custom DSL (in XML in my case, so read "DSL" with a grain of salt)
>>>>>> that's used as the input for generating Ant build fragments, and have
>>>>>> those fragments be able to "insert" them into the target graph. I've
>>>>>> also long felt Ant needed generalized if/unless/os (and my own
>>>>>> extensions like ifTrue, unlessTrue, when) on any "XML tag" (or
>>>>>> UnknownElement if you prefer), just read the recent "add if/unless to
>>>>>> <javac>'s<compilerarg>" thread.<macrodef> is nice, but you can't
>>>>>> use
>>>>>> it for arbitrary, *and conditional*, XML "fragments" inside tasks. All
>>>>>> those things you can often do more easily with a generator, but that's
>>>>>> often cumbersome, doesn't play well with IDEs, etc... I guess I'm
>>>>>> saying I've often wished for generator-like features as a built-in
>>>>>> part of Ant. Do you see what I'm saying? Ant now does late
>>>>>> "conversion" from UnkownElement to actual configuration of the Java
>>>>>> code it maps to, and a way to influence/transform that almost AST-like
>>>>>> graph would make Ant more powerful and flexible, perhaps at the
>>>>>> expense of creating "dialects" unreadable to someone not familiar with
>>>>>> them. Given Ant's XML roots, perhaps a tighter built-in integration
>>>>>> with XSLT to dynamically "rewrite" the build at runtime/buildtime
>>>>>> would be one way to achieve what I envision (notwithstanding the talks
>>>>>> of non-XML front-ends of course).
>>>>>>
>>>>>> Stepping of my soapbox now :) What I'm saying has nothing to do with
>>>>>> Java7, nor necessarily require a rewrite either. --DD
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>> ---------------------------------------------------------------------
>> 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: Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)
Posted by Bruce Atherton <br...@callenish.com>.
Of course you are right, and initially parallelism and distributed
builds will probably not be in the initial alpha release (unless it is
on someones scratching list). Just getting something to run existing
build files reliably will be fine.
But you have suggested that we tag build files that require Ant 2
features with something that identifies them as requiring Ant 2. I think
this is reasonable for the leap from Ant 1 to Ant 2, but one thing HTML
has shown is that version numbers are an anti-pattern, which is why the
DOCTYPE for HTML5 has done away with them (although that introduced its
own "version" ie. no version). What is important is the list of features
that are needed to interpret and run the file correctly.
One can imagine a version tag listing Ant 2 as a minimum for a build
file with an attribute for a comma separated list of the features that
are required from Ant for the build. With this and the kind of packaging
system that OSGI and possibly Java 8 will introduce, Ant could
dynamically configure itself to load the parallelizing implementation of
the state machine or the distributed implementation.
So long as the design is flexible enough that the kinds of usecases that
Dominique and Gilles are suggesting can be implemented eventually, then
the KISS principle can still be followed.
I would also note that features like DSLs for custom builds, automatic
parallelism, and distribution to a fault tolerant cluster are exactly
the kinds of features that would allow many users that I know of to
justify allocating resources to rewrite major build scripts.
On 2/18/2012 11:26 AM, Mansour Al Akeel wrote:
> Keeping it simple, is a great idea.
> I am not sure if introducing parallelism is a good idea or if it's
> easy to implement and maintain.
>
> If it is design is modular, I think all these can be added as plugins.
> Performance ??!!
>
>
> On Sat, Feb 18, 2012 at 1:47 PM, Bruce Atherton<br...@callenish.com> wrote:
>> This too I find a great idea. Multicores mean we need more ways of
>> exploiting parallelism, particularly if they can be identified automatically
>> by the application.
>>
>> For backward compatibility it would have to be optional, though, either
>> specified on the command line or at the build file level or using a
>> different kind of target tag. Of course, the additional information you
>> suggest on targets would make that the case anyway, but in some cases I
>> think we might be able to automate it based just on what we have if the
>> build system is written properly so that dependencies on targets that
>> provide needed resources are explicitly identified.
>>
>> Too many build systems in my experience rely on the order the dependencies
>> are resolved on a higher order target rather than explicitly identifying
>> dependencies on the targets that they are required on. This despite the fact
>> that we have some language somewhere that you can't rely on the order of
>> resolution of the dependencies. Sometimes that has proved a requirement to
>> avoid targets that depended on each other, but I've seen it used as a
>> shortcut instead far too often.
>>
>> Creating Ant clusters is also a great idea, at least to plan for. Perhaps
>> something like Zookeeper to coordinate builds and a message bus like
>> ActiveMQ or perhaps better QPid to schedule and report back to other nodes
>> on the results.
>>
>> The idea of turning the dependency tree into a state machine is also
>> interesting. It would combine the tree and the resolving of the tree with
>> execution of tasks into a single entity. I worry, though, that some
>> flexibility in our current system might be lost if the two portions are
>> combined into one. Perhaps not. It could also introduce the possibility of
>> cycles. Currently the dependency tree gets executed as a DAG but there have
>> been a lot of requests for looping which a state machine could more easily
>> support.
>>
>> On 2/18/2012 2:02 AM, Gilles Scokart wrote:
>>> For me, one feature for a 2,0 would be a different style of dependency
>>> tree that would allow better parallel execution (on the same machine,
>>> or why not on distributed machines).
>>> I see the 'targets' being more declarative, becoming a state
>>> transition saying : I need this resources in that state, I will use
>>> this other resources (and I don't want the to change during my
>>> execution, and I will produce this other resources in that other
>>> state.
>>>
>>> The dependency tree would be an logical engine finding the shortest
>>> path to go to the desired state, using parallel/distributed processing
>>> when possible.
>>>
>>> That's what I miss with existing build system : I want to go as
>>> quickly as possible to a desired build state (from a current state).
>>>
>>>
>>>
>>> Gilles Scokart
>>>
>>>
>>>
>>> On 17 February 2012 20:07, Bruce Atherton<br...@callenish.com> wrote:
>>>> It doesn't require a rewrite, but a rewrite could simplify integrating a
>>>> usecase like this as well as integrating other features that we already
>>>> have
>>>> into it and making them simpler and unified inthe code. I agree the
>>>> usecase
>>>> is an excellent one which could simplify the lives of exactly the type of
>>>> users I am talking about.
>>>>
>>>> It sounds like you are suggesting that the dependency tree be extensible
>>>> and
>>>> modifiable, perhaps manipulable, within targets as well so long as that
>>>> part
>>>> of the tree hasn't run yet. In a sense that is what macros do because
>>>> they
>>>> allow you to swap in some static block of tasks to replace a single task.
>>>> There is also the feature from EasyAnt for changing target dependencies.
>>>> But
>>>> what I'm hearing is that you want more flexibility than that.
>>>>
>>>> Something to walk the existing dependency tree, perhaps, with conditional
>>>> behaviors to modify the metadata on existing element such as dependencies
>>>> and if/unless, replacing the element with another or a subtree (perhaps
>>>> itself dynamically walked and created), adding branches, perhaps deleting
>>>> elements or subtrees. Kind of like what we can do with a tree of files
>>>> and
>>>> directories already. Does that sound like what the design you'd like to
>>>> see
>>>> would have?
>>>>
>>>> And perhaps it could encompass providing both the macro and target
>>>> dependency changes to the tree as well, along with any other code we have
>>>> that alters the dependency tree. I'm not sure which of the various ways
>>>> to
>>>> call back into Ant do this. I'm sure there are other examples in the
>>>> codebase.
>>>>
>>>> I'm not familiar enough with this part of the code any more to know
>>>> whether
>>>> there is already a single elegant solution in Ant 1 that all the code
>>>> which
>>>> modifies the dependency tree shares, but given our BC requirements I
>>>> doubt
>>>> it.
>>>>
>>>> One example of a FileSystemProvider that Java 7 suggests in its API docs
>>>> is
>>>> a "memory" file system, one identified by the URL "memory://". Perhaps
>>>> our
>>>> dependency tree could be a kind of file system, then we could reuse vast
>>>> swathes of code we already have, both in the standard class libraries and
>>>> in
>>>> Ant itself. Just an idea off the top of my head.
>>>>
>>>>
>>>> On 2/17/2012 5:53 AM, Dominique Devienne wrote:
>>>>> 2012/2/17 Bruce Atherton<br...@callenish.com>:
>>>>>> A lot of companies have their own, internally written build file
>>>>>> generators
>>>>>> just so their build systems are consistent and exactly what they want.
>>>>>> Our
>>>>>> Related Projects and External Tools page has some of these that were
>>>>>> made
>>>>>> public, I suspect.
>>>>>>
>>>>>> Surely there is a better way than requiring users of Ant to write
>>>>>> generators
>>>>>> to deal with the complexity and keep it customized.
>>>>> At one point I did write a build(s) (XSLT-based) generator
>>>>> specifically for a large and hairy project. Later I rewrote the whole
>>>>> thing with macrodefs. But my point is that I don't view build
>>>>> generators as bad, in fact it often helps IMHO to have a declarative
>>>>> custom DSL (in XML in my case, so read "DSL" with a grain of salt)
>>>>> that's used as the input for generating Ant build fragments, and have
>>>>> those fragments be able to "insert" them into the target graph. I've
>>>>> also long felt Ant needed generalized if/unless/os (and my own
>>>>> extensions like ifTrue, unlessTrue, when) on any "XML tag" (or
>>>>> UnknownElement if you prefer), just read the recent "add if/unless to
>>>>> <javac>'s<compilerarg>" thread.<macrodef> is nice, but you can't use
>>>>> it for arbitrary, *and conditional*, XML "fragments" inside tasks. All
>>>>> those things you can often do more easily with a generator, but that's
>>>>> often cumbersome, doesn't play well with IDEs, etc... I guess I'm
>>>>> saying I've often wished for generator-like features as a built-in
>>>>> part of Ant. Do you see what I'm saying? Ant now does late
>>>>> "conversion" from UnkownElement to actual configuration of the Java
>>>>> code it maps to, and a way to influence/transform that almost AST-like
>>>>> graph would make Ant more powerful and flexible, perhaps at the
>>>>> expense of creating "dialects" unreadable to someone not familiar with
>>>>> them. Given Ant's XML roots, perhaps a tighter built-in integration
>>>>> with XSLT to dynamically "rewrite" the build at runtime/buildtime
>>>>> would be one way to achieve what I envision (notwithstanding the talks
>>>>> of non-XML front-ends of course).
>>>>>
>>>>> Stepping of my soapbox now :) What I'm saying has nothing to do with
>>>>> Java7, nor necessarily require a rewrite either. --DD
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
> ---------------------------------------------------------------------
> 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: Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)
Posted by Mansour Al Akeel <ma...@gmail.com>.
Keeping it simple, is a great idea.
I am not sure if introducing parallelism is a good idea or if it's
easy to implement and maintain.
If it is design is modular, I think all these can be added as plugins.
Performance ??!!
On Sat, Feb 18, 2012 at 1:47 PM, Bruce Atherton <br...@callenish.com> wrote:
> This too I find a great idea. Multicores mean we need more ways of
> exploiting parallelism, particularly if they can be identified automatically
> by the application.
>
> For backward compatibility it would have to be optional, though, either
> specified on the command line or at the build file level or using a
> different kind of target tag. Of course, the additional information you
> suggest on targets would make that the case anyway, but in some cases I
> think we might be able to automate it based just on what we have if the
> build system is written properly so that dependencies on targets that
> provide needed resources are explicitly identified.
>
> Too many build systems in my experience rely on the order the dependencies
> are resolved on a higher order target rather than explicitly identifying
> dependencies on the targets that they are required on. This despite the fact
> that we have some language somewhere that you can't rely on the order of
> resolution of the dependencies. Sometimes that has proved a requirement to
> avoid targets that depended on each other, but I've seen it used as a
> shortcut instead far too often.
>
> Creating Ant clusters is also a great idea, at least to plan for. Perhaps
> something like Zookeeper to coordinate builds and a message bus like
> ActiveMQ or perhaps better QPid to schedule and report back to other nodes
> on the results.
>
> The idea of turning the dependency tree into a state machine is also
> interesting. It would combine the tree and the resolving of the tree with
> execution of tasks into a single entity. I worry, though, that some
> flexibility in our current system might be lost if the two portions are
> combined into one. Perhaps not. It could also introduce the possibility of
> cycles. Currently the dependency tree gets executed as a DAG but there have
> been a lot of requests for looping which a state machine could more easily
> support.
>
> On 2/18/2012 2:02 AM, Gilles Scokart wrote:
>>
>> For me, one feature for a 2,0 would be a different style of dependency
>> tree that would allow better parallel execution (on the same machine,
>> or why not on distributed machines).
>> I see the 'targets' being more declarative, becoming a state
>> transition saying : I need this resources in that state, I will use
>> this other resources (and I don't want the to change during my
>> execution, and I will produce this other resources in that other
>> state.
>>
>> The dependency tree would be an logical engine finding the shortest
>> path to go to the desired state, using parallel/distributed processing
>> when possible.
>>
>> That's what I miss with existing build system : I want to go as
>> quickly as possible to a desired build state (from a current state).
>>
>>
>>
>> Gilles Scokart
>>
>>
>>
>> On 17 February 2012 20:07, Bruce Atherton<br...@callenish.com> wrote:
>>>
>>> It doesn't require a rewrite, but a rewrite could simplify integrating a
>>> usecase like this as well as integrating other features that we already
>>> have
>>> into it and making them simpler and unified inthe code. I agree the
>>> usecase
>>> is an excellent one which could simplify the lives of exactly the type of
>>> users I am talking about.
>>>
>>> It sounds like you are suggesting that the dependency tree be extensible
>>> and
>>> modifiable, perhaps manipulable, within targets as well so long as that
>>> part
>>> of the tree hasn't run yet. In a sense that is what macros do because
>>> they
>>> allow you to swap in some static block of tasks to replace a single task.
>>> There is also the feature from EasyAnt for changing target dependencies.
>>> But
>>> what I'm hearing is that you want more flexibility than that.
>>>
>>> Something to walk the existing dependency tree, perhaps, with conditional
>>> behaviors to modify the metadata on existing element such as dependencies
>>> and if/unless, replacing the element with another or a subtree (perhaps
>>> itself dynamically walked and created), adding branches, perhaps deleting
>>> elements or subtrees. Kind of like what we can do with a tree of files
>>> and
>>> directories already. Does that sound like what the design you'd like to
>>> see
>>> would have?
>>>
>>> And perhaps it could encompass providing both the macro and target
>>> dependency changes to the tree as well, along with any other code we have
>>> that alters the dependency tree. I'm not sure which of the various ways
>>> to
>>> call back into Ant do this. I'm sure there are other examples in the
>>> codebase.
>>>
>>> I'm not familiar enough with this part of the code any more to know
>>> whether
>>> there is already a single elegant solution in Ant 1 that all the code
>>> which
>>> modifies the dependency tree shares, but given our BC requirements I
>>> doubt
>>> it.
>>>
>>> One example of a FileSystemProvider that Java 7 suggests in its API docs
>>> is
>>> a "memory" file system, one identified by the URL "memory://". Perhaps
>>> our
>>> dependency tree could be a kind of file system, then we could reuse vast
>>> swathes of code we already have, both in the standard class libraries and
>>> in
>>> Ant itself. Just an idea off the top of my head.
>>>
>>>
>>> On 2/17/2012 5:53 AM, Dominique Devienne wrote:
>>>>
>>>> 2012/2/17 Bruce Atherton<br...@callenish.com>:
>>>>>
>>>>> A lot of companies have their own, internally written build file
>>>>> generators
>>>>> just so their build systems are consistent and exactly what they want.
>>>>> Our
>>>>> Related Projects and External Tools page has some of these that were
>>>>> made
>>>>> public, I suspect.
>>>>>
>>>>> Surely there is a better way than requiring users of Ant to write
>>>>> generators
>>>>> to deal with the complexity and keep it customized.
>>>>
>>>> At one point I did write a build(s) (XSLT-based) generator
>>>> specifically for a large and hairy project. Later I rewrote the whole
>>>> thing with macrodefs. But my point is that I don't view build
>>>> generators as bad, in fact it often helps IMHO to have a declarative
>>>> custom DSL (in XML in my case, so read "DSL" with a grain of salt)
>>>> that's used as the input for generating Ant build fragments, and have
>>>> those fragments be able to "insert" them into the target graph. I've
>>>> also long felt Ant needed generalized if/unless/os (and my own
>>>> extensions like ifTrue, unlessTrue, when) on any "XML tag" (or
>>>> UnknownElement if you prefer), just read the recent "add if/unless to
>>>> <javac>'s<compilerarg>" thread.<macrodef> is nice, but you can't use
>>>> it for arbitrary, *and conditional*, XML "fragments" inside tasks. All
>>>> those things you can often do more easily with a generator, but that's
>>>> often cumbersome, doesn't play well with IDEs, etc... I guess I'm
>>>> saying I've often wished for generator-like features as a built-in
>>>> part of Ant. Do you see what I'm saying? Ant now does late
>>>> "conversion" from UnkownElement to actual configuration of the Java
>>>> code it maps to, and a way to influence/transform that almost AST-like
>>>> graph would make Ant more powerful and flexible, perhaps at the
>>>> expense of creating "dialects" unreadable to someone not familiar with
>>>> them. Given Ant's XML roots, perhaps a tighter built-in integration
>>>> with XSLT to dynamically "rewrite" the build at runtime/buildtime
>>>> would be one way to achieve what I envision (notwithstanding the talks
>>>> of non-XML front-ends of course).
>>>>
>>>> Stepping of my soapbox now :) What I'm saying has nothing to do with
>>>> Java7, nor necessarily require a rewrite either. --DD
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)
Posted by Bruce Atherton <br...@callenish.com>.
This too I find a great idea. Multicores mean we need more ways of
exploiting parallelism, particularly if they can be identified
automatically by the application.
For backward compatibility it would have to be optional, though, either
specified on the command line or at the build file level or using a
different kind of target tag. Of course, the additional information you
suggest on targets would make that the case anyway, but in some cases I
think we might be able to automate it based just on what we have if the
build system is written properly so that dependencies on targets that
provide needed resources are explicitly identified.
Too many build systems in my experience rely on the order the
dependencies are resolved on a higher order target rather than
explicitly identifying dependencies on the targets that they are
required on. This despite the fact that we have some language somewhere
that you can't rely on the order of resolution of the dependencies.
Sometimes that has proved a requirement to avoid targets that depended
on each other, but I've seen it used as a shortcut instead far too often.
Creating Ant clusters is also a great idea, at least to plan for.
Perhaps something like Zookeeper to coordinate builds and a message bus
like ActiveMQ or perhaps better QPid to schedule and report back to
other nodes on the results.
The idea of turning the dependency tree into a state machine is also
interesting. It would combine the tree and the resolving of the tree
with execution of tasks into a single entity. I worry, though, that some
flexibility in our current system might be lost if the two portions are
combined into one. Perhaps not. It could also introduce the possibility
of cycles. Currently the dependency tree gets executed as a DAG but
there have been a lot of requests for looping which a state machine
could more easily support.
On 2/18/2012 2:02 AM, Gilles Scokart wrote:
> For me, one feature for a 2,0 would be a different style of dependency
> tree that would allow better parallel execution (on the same machine,
> or why not on distributed machines).
> I see the 'targets' being more declarative, becoming a state
> transition saying : I need this resources in that state, I will use
> this other resources (and I don't want the to change during my
> execution, and I will produce this other resources in that other
> state.
>
> The dependency tree would be an logical engine finding the shortest
> path to go to the desired state, using parallel/distributed processing
> when possible.
>
> That's what I miss with existing build system : I want to go as
> quickly as possible to a desired build state (from a current state).
>
>
>
> Gilles Scokart
>
>
>
> On 17 February 2012 20:07, Bruce Atherton<br...@callenish.com> wrote:
>> It doesn't require a rewrite, but a rewrite could simplify integrating a
>> usecase like this as well as integrating other features that we already have
>> into it and making them simpler and unified inthe code. I agree the usecase
>> is an excellent one which could simplify the lives of exactly the type of
>> users I am talking about.
>>
>> It sounds like you are suggesting that the dependency tree be extensible and
>> modifiable, perhaps manipulable, within targets as well so long as that part
>> of the tree hasn't run yet. In a sense that is what macros do because they
>> allow you to swap in some static block of tasks to replace a single task.
>> There is also the feature from EasyAnt for changing target dependencies. But
>> what I'm hearing is that you want more flexibility than that.
>>
>> Something to walk the existing dependency tree, perhaps, with conditional
>> behaviors to modify the metadata on existing element such as dependencies
>> and if/unless, replacing the element with another or a subtree (perhaps
>> itself dynamically walked and created), adding branches, perhaps deleting
>> elements or subtrees. Kind of like what we can do with a tree of files and
>> directories already. Does that sound like what the design you'd like to see
>> would have?
>>
>> And perhaps it could encompass providing both the macro and target
>> dependency changes to the tree as well, along with any other code we have
>> that alters the dependency tree. I'm not sure which of the various ways to
>> call back into Ant do this. I'm sure there are other examples in the
>> codebase.
>>
>> I'm not familiar enough with this part of the code any more to know whether
>> there is already a single elegant solution in Ant 1 that all the code which
>> modifies the dependency tree shares, but given our BC requirements I doubt
>> it.
>>
>> One example of a FileSystemProvider that Java 7 suggests in its API docs is
>> a "memory" file system, one identified by the URL "memory://". Perhaps our
>> dependency tree could be a kind of file system, then we could reuse vast
>> swathes of code we already have, both in the standard class libraries and in
>> Ant itself. Just an idea off the top of my head.
>>
>>
>> On 2/17/2012 5:53 AM, Dominique Devienne wrote:
>>> 2012/2/17 Bruce Atherton<br...@callenish.com>:
>>>> A lot of companies have their own, internally written build file
>>>> generators
>>>> just so their build systems are consistent and exactly what they want.
>>>> Our
>>>> Related Projects and External Tools page has some of these that were made
>>>> public, I suspect.
>>>>
>>>> Surely there is a better way than requiring users of Ant to write
>>>> generators
>>>> to deal with the complexity and keep it customized.
>>> At one point I did write a build(s) (XSLT-based) generator
>>> specifically for a large and hairy project. Later I rewrote the whole
>>> thing with macrodefs. But my point is that I don't view build
>>> generators as bad, in fact it often helps IMHO to have a declarative
>>> custom DSL (in XML in my case, so read "DSL" with a grain of salt)
>>> that's used as the input for generating Ant build fragments, and have
>>> those fragments be able to "insert" them into the target graph. I've
>>> also long felt Ant needed generalized if/unless/os (and my own
>>> extensions like ifTrue, unlessTrue, when) on any "XML tag" (or
>>> UnknownElement if you prefer), just read the recent "add if/unless to
>>> <javac>'s<compilerarg>" thread.<macrodef> is nice, but you can't use
>>> it for arbitrary, *and conditional*, XML "fragments" inside tasks. All
>>> those things you can often do more easily with a generator, but that's
>>> often cumbersome, doesn't play well with IDEs, etc... I guess I'm
>>> saying I've often wished for generator-like features as a built-in
>>> part of Ant. Do you see what I'm saying? Ant now does late
>>> "conversion" from UnkownElement to actual configuration of the Java
>>> code it maps to, and a way to influence/transform that almost AST-like
>>> graph would make Ant more powerful and flexible, perhaps at the
>>> expense of creating "dialects" unreadable to someone not familiar with
>>> them. Given Ant's XML roots, perhaps a tighter built-in integration
>>> with XSLT to dynamically "rewrite" the build at runtime/buildtime
>>> would be one way to achieve what I envision (notwithstanding the talks
>>> of non-XML front-ends of course).
>>>
>>> Stepping of my soapbox now :) What I'm saying has nothing to do with
>>> Java7, nor necessarily require a rewrite either. --DD
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
> ---------------------------------------------------------------------
> 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: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Bruce Atherton <br...@callenish.com>.
Ok, that was a bad example. It was far too much a programmer point of
view rather than a user's. Plus it lost formatting. Let me try again
with a (hopefully) clearer example of what I think you are talking about.
<artifacts name="simple-lib">
<artifact name="create-dirs" target="create-simple-lib-dirs">
<rollback name="remove-dirs" target="delete-resource-tree" />
</artifact>
<artifact name="get-java-src" target="svn-checkout-java-src" depends="create-dirs">
<property name="src-up-to-date" value="true" />
<rollback name="remove-java-src" target="delete-java-src" />
</artifact>
<artifact name="update-java-src" target="svn-up-java-src" if="java-src-present, checkin-detected">
<property name="src-up-to-date" value="true" />
<rollback name="remove-java-src" target="delete-java-src" />
</artifact>
<artifact name="compile-java-src" target="javac-compile-src" depends="${src-up-to-date}">
<!-- Note that the property in depends REQUIRES Ant to find a way to make it true or fail -->
<rollback name="remove-java-classes" target="delete-java-classes" />
</artifact>
<artifact name="jar-java-classes" target="create-jar" if="java-classes-present">
<rollback name="remove-lib-jar" target="delete-generated-lib" />
</artifact>
<artifact name="install-lib" target="install-lib-jar" if="generated-jar-present">
<rollback name="remove-installed-lib" target="delete-installed-lib" />
</artifact>
</artifacts>
<resource name="bzip2-lib" artifacts="simple-lib" path="src/main/org/apache/tools/bzip2/**" />
<resource name="mail-lib" artifacts="tested-lib" path="src/main/org/apache/tools/mail/**" />
<resource name="tar-lib" artifacts="simple-lib" path="src/main/org/apache/tools/tar/**" />
<resource name="zip-lib" artifacts="simple-lib" path="src/main/org/apache/tools/zip/**" />
<resource name="ant" artifacts="ant-build" path="src/main/org/apache/tools/ant/"
depends="bzip2-lib,mail-lib,tar-lib-zip-lib">
...
</resource>
Based on the dependencies in the resources, Ant could run separate build
threads (or on different machines) for each of the simple-lib resources
following the artifact patterns. I changed mail-lib to a different
artifact pattern (one that would presumably include checking out,
compiling, and running unit tests and possibly generate a code coverage
report) but I didn't bother showing it.
Since the ant-build relies on the others, it couldn't be scheduled until
the others had finished (or had generated all the artifacts needed for a
particular stage of the ant build).
Substitutions for properties in the targets would come from the tags and
attributes from the artifacts and resources that were applied to the
particular target, much like parameters in macros. Resources could
override targets and other things in artifacts as needed, and be
arbitrarily complex in terms of the resources they described which means
targets that worked this way would need a way of combining artifact
information with multiple paths.
You could even imagine the command line supporting this style for
calling build targets, like:
ant zip-lib - build the zip-lib
ant zip-lib:update-java-src - Do everything up to an update to the source code on the zip-lib
ant zip-lib::update-java-src - Only do an update on the Java source assuming the previous steps have run
or perhaps the syntax would be separate flags:
ant -resource=zip-lib -up-to=update-java-src
ant -resource=zip-lib -only=update-java-src
Anyway, this is obviously sketchy but I put it up for discussion. Is
this the kind of thing you guys have been talking about, or have I
missed the mark?
On 2/21/2012 12:22 PM, Bruce Atherton wrote:
> It sounds like you are both are on a similar wavelength. Let me see if
> I understand.
>
> A new style of build (while maintaining the old style, of course)
> would be to declare some combination of resources to have similar
> states and transitions between states. So something like this (just as
> an example of a made-up syntax):
>
> <states>
> <state name="no-java-src" newstate="curr-src-present"
> detect="${no-java-src-present}">
> <transition target="checkout-java-src" />
> </state>
> <state name="out-of-date" newstate="curr-src-present"
> detect="${java-src-present}">
> <transition target="update-java-src" />
> </state>
> <state name="curr-src-present" newstate="compiled-java-src">
> <transition target="compile-java-src" />
> </state>
> <state name="curr-src-present" newstate="no-java-src">
> <transition target="remove-java-src" />
> </state>
> </states>
>
> <resources>
> <path="src/main/org/apache/tools/**/*.java" />
> <statechange from="no-java-src" to="curr-src-present" />
> <statechange from="out-of-date" to="curr-src-present" />
> <statechange from="curr-src-present" to="compiled-java-src" />
> <statechange from="curr-src-present" to="no-java-src" />
> </resources>
>
> and so on. The statechanges here are single steps from state to state,
> but presumably the from and to statechanges could be many steps away
> and Ant would find the best (for some value of best - fewest nodes,
> least cost?) DAG from one to the other.
>
> Then to run the build you identify some combination of resources and
> states you want to end up in gathered together in another target or
> something similar. Is that the idea?
>
> On 2/19/2012 1:26 PM, Dominique Devienne wrote:
>> On Sat, Feb 18, 2012 at 11:02 AM, Gilles Scokart<gs...@gmail.com>
>> wrote:
>>> For me, one feature for a 2,0 would be a different style of dependency
>>> tree that would allow better parallel execution (on the same machine,
>>> or why not on distributed machines).
>> Agreed. I was in fact thinking of this one as well when I wrote my
>> "integrated build generator/manipulator".
>>
>>> I see the 'targets' being more declarative, becoming a state
>>> transition saying : I need this resources in that state, I will use
>>> this other resources (and I don't want the to change during my
>>> execution, and I will produce this other resources in that other
>>> state.
>> Yep, with the modulo that I see 'targets' in a fine-grained way, i.e.
>> you know the graph of actions to transition all input files/resources
>> and come up with the optimum way to achieve the stated goals given the
>> hardware resources (single cpu computer, multi-core computer, grid of
>> computers). That's basically Makefile territory in a way, and similar
>> to what Peter's<outofdate> does as well. Right now Ant's targets
>> typically deal with "macro" dependencies (build all .class file before
>> building all .jar ones), and not "micro" dependencies at the file
>> level, so the opportunities to do stuff in parallel are lessened IMHO.
>> One reason Ant doesn't care much about this kind of parallelism is
>> that Javac is fast-enough and cannot be distributed really, and it's
>> the compilation of native languages like C++ that benefit most from
>> those, and that's not Ant's territory in fact.
>>
>>> The dependency tree would be an logical engine finding the shortest
>>> path to go to the desired state, using parallel/distributed processing
>>> when possible.
>>>
>>> That's what I miss with existing build system : I want to go as
>>> quickly as possible to a desired build state (from a current state).
>> Have you read the 4 part series about how Google does its builds?
>> Below's a link to part#4. --DD
>>
>> http://google-engtools.blogspot.com/2011/10/build-in-cloud-distributing-build.html
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Bruce Atherton <br...@callenish.com>.
It sounds like you are both are on a similar wavelength. Let me see if I
understand.
A new style of build (while maintaining the old style, of course) would
be to declare some combination of resources to have similar states and
transitions between states. So something like this (just as an example
of a made-up syntax):
<states>
<state name="no-java-src" newstate="curr-src-present"
detect="${no-java-src-present}">
<transition target="checkout-java-src" />
</state>
<state name="out-of-date" newstate="curr-src-present"
detect="${java-src-present}">
<transition target="update-java-src" />
</state>
<state name="curr-src-present" newstate="compiled-java-src">
<transition target="compile-java-src" />
</state>
<state name="curr-src-present" newstate="no-java-src">
<transition target="remove-java-src" />
</state>
</states>
<resources>
<path="src/main/org/apache/tools/**/*.java" />
<statechange from="no-java-src" to="curr-src-present" />
<statechange from="out-of-date" to="curr-src-present" />
<statechange from="curr-src-present" to="compiled-java-src" />
<statechange from="curr-src-present" to="no-java-src" />
</resources>
and so on. The statechanges here are single steps from state to state,
but presumably the from and to statechanges could be many steps away and
Ant would find the best (for some value of best - fewest nodes, least
cost?) DAG from one to the other.
Then to run the build you identify some combination of resources and
states you want to end up in gathered together in another target or
something similar. Is that the idea?
On 2/19/2012 1:26 PM, Dominique Devienne wrote:
> On Sat, Feb 18, 2012 at 11:02 AM, Gilles Scokart<gs...@gmail.com> wrote:
>> For me, one feature for a 2,0 would be a different style of dependency
>> tree that would allow better parallel execution (on the same machine,
>> or why not on distributed machines).
> Agreed. I was in fact thinking of this one as well when I wrote my
> "integrated build generator/manipulator".
>
>> I see the 'targets' being more declarative, becoming a state
>> transition saying : I need this resources in that state, I will use
>> this other resources (and I don't want the to change during my
>> execution, and I will produce this other resources in that other
>> state.
> Yep, with the modulo that I see 'targets' in a fine-grained way, i.e.
> you know the graph of actions to transition all input files/resources
> and come up with the optimum way to achieve the stated goals given the
> hardware resources (single cpu computer, multi-core computer, grid of
> computers). That's basically Makefile territory in a way, and similar
> to what Peter's<outofdate> does as well. Right now Ant's targets
> typically deal with "macro" dependencies (build all .class file before
> building all .jar ones), and not "micro" dependencies at the file
> level, so the opportunities to do stuff in parallel are lessened IMHO.
> One reason Ant doesn't care much about this kind of parallelism is
> that Javac is fast-enough and cannot be distributed really, and it's
> the compilation of native languages like C++ that benefit most from
> those, and that's not Ant's territory in fact.
>
>> The dependency tree would be an logical engine finding the shortest
>> path to go to the desired state, using parallel/distributed processing
>> when possible.
>>
>> That's what I miss with existing build system : I want to go as
>> quickly as possible to a desired build state (from a current state).
> Have you read the 4 part series about how Google does its builds?
> Below's a link to part#4. --DD
>
> http://google-engtools.blogspot.com/2011/10/build-in-cloud-distributing-build.html
>
> ---------------------------------------------------------------------
> 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: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Dominique Devienne <dd...@gmail.com>.
On Sat, Feb 18, 2012 at 11:02 AM, Gilles Scokart <gs...@gmail.com> wrote:
> For me, one feature for a 2,0 would be a different style of dependency
> tree that would allow better parallel execution (on the same machine,
> or why not on distributed machines).
Agreed. I was in fact thinking of this one as well when I wrote my
"integrated build generator/manipulator".
> I see the 'targets' being more declarative, becoming a state
> transition saying : I need this resources in that state, I will use
> this other resources (and I don't want the to change during my
> execution, and I will produce this other resources in that other
> state.
Yep, with the modulo that I see 'targets' in a fine-grained way, i.e.
you know the graph of actions to transition all input files/resources
and come up with the optimum way to achieve the stated goals given the
hardware resources (single cpu computer, multi-core computer, grid of
computers). That's basically Makefile territory in a way, and similar
to what Peter's <outofdate> does as well. Right now Ant's targets
typically deal with "macro" dependencies (build all .class file before
building all .jar ones), and not "micro" dependencies at the file
level, so the opportunities to do stuff in parallel are lessened IMHO.
One reason Ant doesn't care much about this kind of parallelism is
that Javac is fast-enough and cannot be distributed really, and it's
the compilation of native languages like C++ that benefit most from
those, and that's not Ant's territory in fact.
> The dependency tree would be an logical engine finding the shortest
> path to go to the desired state, using parallel/distributed processing
> when possible.
>
> That's what I miss with existing build system : I want to go as
> quickly as possible to a desired build state (from a current state).
Have you read the 4 part series about how Google does its builds?
Below's a link to part#4. --DD
http://google-engtools.blogspot.com/2011/10/build-in-cloud-distributing-build.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Gilles Scokart <gs...@gmail.com>.
For me, one feature for a 2,0 would be a different style of dependency
tree that would allow better parallel execution (on the same machine,
or why not on distributed machines).
I see the 'targets' being more declarative, becoming a state
transition saying : I need this resources in that state, I will use
this other resources (and I don't want the to change during my
execution, and I will produce this other resources in that other
state.
The dependency tree would be an logical engine finding the shortest
path to go to the desired state, using parallel/distributed processing
when possible.
That's what I miss with existing build system : I want to go as
quickly as possible to a desired build state (from a current state).
Gilles Scokart
On 17 February 2012 20:07, Bruce Atherton <br...@callenish.com> wrote:
> It doesn't require a rewrite, but a rewrite could simplify integrating a
> usecase like this as well as integrating other features that we already have
> into it and making them simpler and unified inthe code. I agree the usecase
> is an excellent one which could simplify the lives of exactly the type of
> users I am talking about.
>
> It sounds like you are suggesting that the dependency tree be extensible and
> modifiable, perhaps manipulable, within targets as well so long as that part
> of the tree hasn't run yet. In a sense that is what macros do because they
> allow you to swap in some static block of tasks to replace a single task.
> There is also the feature from EasyAnt for changing target dependencies. But
> what I'm hearing is that you want more flexibility than that.
>
> Something to walk the existing dependency tree, perhaps, with conditional
> behaviors to modify the metadata on existing element such as dependencies
> and if/unless, replacing the element with another or a subtree (perhaps
> itself dynamically walked and created), adding branches, perhaps deleting
> elements or subtrees. Kind of like what we can do with a tree of files and
> directories already. Does that sound like what the design you'd like to see
> would have?
>
> And perhaps it could encompass providing both the macro and target
> dependency changes to the tree as well, along with any other code we have
> that alters the dependency tree. I'm not sure which of the various ways to
> call back into Ant do this. I'm sure there are other examples in the
> codebase.
>
> I'm not familiar enough with this part of the code any more to know whether
> there is already a single elegant solution in Ant 1 that all the code which
> modifies the dependency tree shares, but given our BC requirements I doubt
> it.
>
> One example of a FileSystemProvider that Java 7 suggests in its API docs is
> a "memory" file system, one identified by the URL "memory://". Perhaps our
> dependency tree could be a kind of file system, then we could reuse vast
> swathes of code we already have, both in the standard class libraries and in
> Ant itself. Just an idea off the top of my head.
>
>
> On 2/17/2012 5:53 AM, Dominique Devienne wrote:
>>
>> 2012/2/17 Bruce Atherton<br...@callenish.com>:
>>>
>>> A lot of companies have their own, internally written build file
>>> generators
>>> just so their build systems are consistent and exactly what they want.
>>> Our
>>> Related Projects and External Tools page has some of these that were made
>>> public, I suspect.
>>>
>>> Surely there is a better way than requiring users of Ant to write
>>> generators
>>> to deal with the complexity and keep it customized.
>>
>> At one point I did write a build(s) (XSLT-based) generator
>> specifically for a large and hairy project. Later I rewrote the whole
>> thing with macrodefs. But my point is that I don't view build
>> generators as bad, in fact it often helps IMHO to have a declarative
>> custom DSL (in XML in my case, so read "DSL" with a grain of salt)
>> that's used as the input for generating Ant build fragments, and have
>> those fragments be able to "insert" them into the target graph. I've
>> also long felt Ant needed generalized if/unless/os (and my own
>> extensions like ifTrue, unlessTrue, when) on any "XML tag" (or
>> UnknownElement if you prefer), just read the recent "add if/unless to
>> <javac>'s<compilerarg>" thread.<macrodef> is nice, but you can't use
>> it for arbitrary, *and conditional*, XML "fragments" inside tasks. All
>> those things you can often do more easily with a generator, but that's
>> often cumbersome, doesn't play well with IDEs, etc... I guess I'm
>> saying I've often wished for generator-like features as a built-in
>> part of Ant. Do you see what I'm saying? Ant now does late
>> "conversion" from UnkownElement to actual configuration of the Java
>> code it maps to, and a way to influence/transform that almost AST-like
>> graph would make Ant more powerful and flexible, perhaps at the
>> expense of creating "dialects" unreadable to someone not familiar with
>> them. Given Ant's XML roots, perhaps a tighter built-in integration
>> with XSLT to dynamically "rewrite" the build at runtime/buildtime
>> would be one way to achieve what I envision (notwithstanding the talks
>> of non-XML front-ends of course).
>>
>> Stepping of my soapbox now :) What I'm saying has nothing to do with
>> Java7, nor necessarily require a rewrite either. --DD
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Bruce Atherton <br...@callenish.com>.
It doesn't require a rewrite, but a rewrite could simplify integrating a
usecase like this as well as integrating other features that we already
have into it and making them simpler and unified inthe code. I agree the
usecase is an excellent one which could simplify the lives of exactly
the type of users I am talking about.
It sounds like you are suggesting that the dependency tree be extensible
and modifiable, perhaps manipulable, within targets as well so long as
that part of the tree hasn't run yet. In a sense that is what macros do
because they allow you to swap in some static block of tasks to replace
a single task. There is also the feature from EasyAnt for changing
target dependencies. But what I'm hearing is that you want more
flexibility than that.
Something to walk the existing dependency tree, perhaps, with
conditional behaviors to modify the metadata on existing element such as
dependencies and if/unless, replacing the element with another or a
subtree (perhaps itself dynamically walked and created), adding
branches, perhaps deleting elements or subtrees. Kind of like what we
can do with a tree of files and directories already. Does that sound
like what the design you'd like to see would have?
And perhaps it could encompass providing both the macro and target
dependency changes to the tree as well, along with any other code we
have that alters the dependency tree. I'm not sure which of the various
ways to call back into Ant do this. I'm sure there are other examples in
the codebase.
I'm not familiar enough with this part of the code any more to know
whether there is already a single elegant solution in Ant 1 that all the
code which modifies the dependency tree shares, but given our BC
requirements I doubt it.
One example of a FileSystemProvider that Java 7 suggests in its API docs
is a "memory" file system, one identified by the URL "memory://".
Perhaps our dependency tree could be a kind of file system, then we
could reuse vast swathes of code we already have, both in the standard
class libraries and in Ant itself. Just an idea off the top of my head.
On 2/17/2012 5:53 AM, Dominique Devienne wrote:
> 2012/2/17 Bruce Atherton<br...@callenish.com>:
>> A lot of companies have their own, internally written build file generators
>> just so their build systems are consistent and exactly what they want. Our
>> Related Projects and External Tools page has some of these that were made
>> public, I suspect.
>>
>> Surely there is a better way than requiring users of Ant to write generators
>> to deal with the complexity and keep it customized.
> At one point I did write a build(s) (XSLT-based) generator
> specifically for a large and hairy project. Later I rewrote the whole
> thing with macrodefs. But my point is that I don't view build
> generators as bad, in fact it often helps IMHO to have a declarative
> custom DSL (in XML in my case, so read "DSL" with a grain of salt)
> that's used as the input for generating Ant build fragments, and have
> those fragments be able to "insert" them into the target graph. I've
> also long felt Ant needed generalized if/unless/os (and my own
> extensions like ifTrue, unlessTrue, when) on any "XML tag" (or
> UnknownElement if you prefer), just read the recent "add if/unless to
> <javac>'s<compilerarg>" thread.<macrodef> is nice, but you can't use
> it for arbitrary, *and conditional*, XML "fragments" inside tasks. All
> those things you can often do more easily with a generator, but that's
> often cumbersome, doesn't play well with IDEs, etc... I guess I'm
> saying I've often wished for generator-like features as a built-in
> part of Ant. Do you see what I'm saying? Ant now does late
> "conversion" from UnkownElement to actual configuration of the Java
> code it maps to, and a way to influence/transform that almost AST-like
> graph would make Ant more powerful and flexible, perhaps at the
> expense of creating "dialects" unreadable to someone not familiar with
> them. Given Ant's XML roots, perhaps a tighter built-in integration
> with XSLT to dynamically "rewrite" the build at runtime/buildtime
> would be one way to achieve what I envision (notwithstanding the talks
> of non-XML front-ends of course).
>
> Stepping of my soapbox now :) What I'm saying has nothing to do with
> Java7, nor necessarily require a rewrite either. --DD
>
> ---------------------------------------------------------------------
> 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: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Dominique Devienne <dd...@gmail.com>.
2012/2/17 Bruce Atherton <br...@callenish.com>:
> A lot of companies have their own, internally written build file generators
> just so their build systems are consistent and exactly what they want. Our
> Related Projects and External Tools page has some of these that were made
> public, I suspect.
>
> Surely there is a better way than requiring users of Ant to write generators
> to deal with the complexity and keep it customized.
At one point I did write a build(s) (XSLT-based) generator
specifically for a large and hairy project. Later I rewrote the whole
thing with macrodefs. But my point is that I don't view build
generators as bad, in fact it often helps IMHO to have a declarative
custom DSL (in XML in my case, so read "DSL" with a grain of salt)
that's used as the input for generating Ant build fragments, and have
those fragments be able to "insert" them into the target graph. I've
also long felt Ant needed generalized if/unless/os (and my own
extensions like ifTrue, unlessTrue, when) on any "XML tag" (or
UnknownElement if you prefer), just read the recent "add if/unless to
<javac>'s <compilerarg>" thread. <macrodef> is nice, but you can't use
it for arbitrary, *and conditional*, XML "fragments" inside tasks. All
those things you can often do more easily with a generator, but that's
often cumbersome, doesn't play well with IDEs, etc... I guess I'm
saying I've often wished for generator-like features as a built-in
part of Ant. Do you see what I'm saying? Ant now does late
"conversion" from UnkownElement to actual configuration of the Java
code it maps to, and a way to influence/transform that almost AST-like
graph would make Ant more powerful and flexible, perhaps at the
expense of creating "dialects" unreadable to someone not familiar with
them. Given Ant's XML roots, perhaps a tighter built-in integration
with XSLT to dynamically "rewrite" the build at runtime/buildtime
would be one way to achieve what I envision (notwithstanding the talks
of non-XML front-ends of course).
Stepping of my soapbox now :) What I'm saying has nothing to do with
Java7, nor necessarily require a rewrite either. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Bruce Atherton <br...@callenish.com>.
On 2/16/2012 2:36 PM, Nicolas Lalevée wrote:
> Le 16 févr. 2012 à 20:47, Bruce Atherton a écrit :
>
>> I'd hope to go further than that in backwards compatibility. I work with a lot of companies that are:
>>
>> a) resistant to learning new things unless there is a good reason for it (such as the migration from Apache HTTP Server from 1.x to 2.x to resolve security issues)
>>
>> b) have a number of separate Ant build scripts that follow different standards in different areas of the company, particularly if they have
>>
>> and c) need to have a justification to allocate resources to upgrade and change a working build to use new features, which standardizing builds across the organization using new features in a major release that simplify the build system may offer them.
> I don't know conclusion you're having there. Such companies shouldn't worry about any new major version, because they actually do want to stick with the old one for stability purpose. I guess that the companies which would be troubled is the ones which want to keep up with the releases, migrations from one version to another should not be too painful.
No, you are right that these companies need a good reason to upgrade.
What I am saying is that the pain that is caused by trying to make minor
modifications to large complicated build systems, combined with having
multiple large build systems that do very different things and the
difficulty in dealing with these major changes in operating, is the
thing that can cause at least some of them to dedicate the resources to
standardize on something simpler. But I haven't found any that are
interested in considering a new build system. They know Ant. Any
upgrades they want to do in their own time. That is why I think backward
compatibility is so important. They can roll out an upgrade to Ant 2,
make sure everything works as expected, and then in their own time roll
out a simplified, standardized build to each of the systems they are
currently running it.
>
> Well, again, I think it's already there, no need to wait for an Ant 2.0 :)
> If you add the groovy-front.jar in Ant's boot classpath, write a build.groovy, then a launch of ant with no parameter on the command line will execute your groovy build script. See ProjectHelperRepository.getProjectHelperForBuildFile(Resource)
I've got a lot of customers with the kinds of Ant build systems I am
talking about. Precisely zero of them use anything other than an XML
format for the build. Downloading extra bits to do funky things is not
in their DNA. Some of them are forbidden to use Ant Contrib because it
hasn't been through a security audit.
I used to think we are living in a Maven world and that Ant was fine
being just in maintenance mode. Since I've been helping these customers
integrate my product with their systems, including their build systems,
I've come to realize that there is still a very strong need for Ant out
there, and that they are hurting from the complexity of it. Some of the
complexity is from build systems that were written pre-macrodef and they
haven't seen that one feature as compelling enough to commit to a
rewrite. Some use macros, though, and things are still pretty complicated.
I think this is Ant's market: places that don't want the dependency
features of Maven and require complete control over exactly how their
build is done. A lot of companies have their own, internally written
build file generators just so their build systems are consistent and
exactly what they want. Our Related Projects and External Tools page has
some of these that were made public, I suspect.
Surely there is a better way than requiring users of Ant to write
generators to deal with the complexity and keep it customized.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 16 févr. 2012 à 20:47, Bruce Atherton a écrit :
> I'd hope to go further than that in backwards compatibility. I work with a lot of companies that are:
>
> a) resistant to learning new things unless there is a good reason for it (such as the migration from Apache HTTP Server from 1.x to 2.x to resolve security issues)
>
> b) have a number of separate Ant build scripts that follow different standards in different areas of the company, particularly if they have
>
> and c) need to have a justification to allocate resources to upgrade and change a working build to use new features, which standardizing builds across the organization using new features in a major release that simplify the build system may offer them.
I don't know conclusion you're having there. Such companies shouldn't worry about any new major version, because they actually do want to stick with the old one for stability purpose. I guess that the companies which would be troubled is the ones which want to keep up with the releases, migrations from one version to another should not be too painful.
> You are right about the plugin parser architecture in Ant 1.x, but one of the problems with it is that there is nothing shipped by default. What I meant was that I would love it if Ant 2 also represented a point where new builds could think about using a new build format automatically, just based on file extension or a flag on the command line. That might encourage new projects to adopt it.
Well, again, I think it's already there, no need to wait for an Ant 2.0 :)
If you add the groovy-front.jar in Ant's boot classpath, write a build.groovy, then a launch of ant with no parameter on the command line will execute your groovy build script. See ProjectHelperRepository.getProjectHelperForBuildFile(Resource)
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Bruce Atherton <br...@callenish.com>.
Oops, accidental deletion.
On 2/16/2012 11:47 AM, Bruce Atherton wrote:
>
> b) have a number of separate Ant build scripts that follow
> different standards in different areas of the company, particularly if
> they have acquired other companies with their own Ant builds.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Bruce Atherton <br...@callenish.com>.
I'd hope to go further than that in backwards compatibility. I work with
a lot of companies that are:
a) resistant to learning new things unless there is a good reason
for it (such as the migration from Apache HTTP Server from 1.x to 2.x to
resolve security issues)
b) have a number of separate Ant build scripts that follow
different standards in different areas of the company, particularly if
they have
and c) need to have a justification to allocate resources to upgrade and
change a working build to use new features, which standardizing builds
across the organization using new features in a major release that
simplify the build system may offer them.
You are right about the plugin parser architecture in Ant 1.x, but one
of the problems with it is that there is nothing shipped by default.
What I meant was that I would love it if Ant 2 also represented a point
where new builds could think about using a new build format
automatically, just based on file extension or a flag on the command
line. That might encourage new projects to adopt it.
On 2/16/2012 10:57 AM, Nicolas Lalevée wrote:
> Le 14 févr. 2012 à 20:02, Bruce Atherton a écrit :
>
>> On 2/14/2012 6:13 AM, Stefan Bodewig wrote:
>>> This will lead us to the discussion of what Ant2 would be. A rewritten
>>> Ant that remains compatible (or mostly so) on the build file level or
>>> something quite different?
>>>
>> My opinion.
>>
>> I think we need at least an option for being backwards compatible at the build file level and it should be the default for quite a while after an initial 2.0 release.
> A simple trick can be a declaration of a "version" attribute which would declare the minimum Ant version required to run the build file, and also declare how it should be interpreted. This is how it works for the ivy.xml for instance.
>
>> I'd hope, though, that a redesign would have a fully pluggable parser so that even with the first release there was an option to use something other than XML.
> I think you can already today, there are some experiments which show it works [1] [2]. The names of the classes of Ant may not be explicit, but I think the abstraction is there.
>
> Nicolas
>
> [1] http://svn.apache.org/repos/asf/ant/sandbox/javafront/
> [2] http://svn.apache.org/repos/asf/ant/sandbox/groovyfront/
>
>
> ---------------------------------------------------------------------
> 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: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 14 févr. 2012 à 20:02, Bruce Atherton a écrit :
> On 2/14/2012 6:13 AM, Stefan Bodewig wrote:
>>
>> This will lead us to the discussion of what Ant2 would be. A rewritten
>> Ant that remains compatible (or mostly so) on the build file level or
>> something quite different?
>>
>
> My opinion.
>
> I think we need at least an option for being backwards compatible at the build file level and it should be the default for quite a while after an initial 2.0 release.
A simple trick can be a declaration of a "version" attribute which would declare the minimum Ant version required to run the build file, and also declare how it should be interpreted. This is how it works for the ivy.xml for instance.
> I'd hope, though, that a redesign would have a fully pluggable parser so that even with the first release there was an option to use something other than XML.
I think you can already today, there are some experiments which show it works [1] [2]. The names of the classes of Ant may not be explicit, but I think the abstraction is there.
Nicolas
[1] http://svn.apache.org/repos/asf/ant/sandbox/javafront/
[2] http://svn.apache.org/repos/asf/ant/sandbox/groovyfront/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Bruce Atherton <br...@callenish.com>.
On 2/14/2012 6:13 AM, Stefan Bodewig wrote:
>
> This will lead us to the discussion of what Ant2 would be. A rewritten
> Ant that remains compatible (or mostly so) on the build file level or
> something quite different?
>
My opinion.
I think we need at least an option for being backwards compatible at the
build file level and it should be the default for quite a while after an
initial 2.0 release. I'd hope, though, that a redesign would have a
fully pluggable parser so that even with the first release there was an
option to use something other than XML.
I actually think build file compatibility should be a feature of the
first alpha. Here is how I thought it might be achieved using the change
in namespace that would allow Ant1 and Ant2 to coexist:
Phase 1: Ant 2 handles a tag if it knows how, otherwise passes it to Ant
1. Originally all the infrastructure would call Ant 1 but that would
gradually change as more facilities were developed for Ant 2.
Phase 2: Ant 2 can do most things, but there are a few concepts and tags
that are foreign to it that it needs to pass to Ant 1. Ant 1 comes with
Ant 2 but only in the bootstrap form.
Phase 3: Ant 2 can emulate enough of Ant 1 that it isn't necessary to
ship it, but it is an option for those who want to run in compatibility
mode or use an <ant-one> tag or similar.
Basically I am talking about an aggressive refactoring with no thought
to backwards API compatibility. That compatibility has tied our hands
from doing a real refactoring for a decade.
I agree with you that our tasks are fully debugged. They should be
reused as much as possible. I would imagine that as far as tasks were
concerned, a simple massaging before moving them to a new package would
be all that was required, to take away cruft and to use a new style for
defining tasks. And to move calls to the infrastructure over to the new one.
What I started to implement was to make everything that is visible in a
build file an immutable property, tasks and selectors and conditions,
everything. They would all be POJOs with annotations to indicate how
they are exposed to the dependency tree. The annotations would be a
dependency on Ant that may not be desirable or possible for legacy
classes, so a base proxy class could be extended to provide the
annotations and automatically call into a reference POJO for behaviour.
Creating a PropertyProxy from the POJOs to make them immutable could
likewise be done. Any @Modifiable method on the Task would simply not do
anything or throw an exception.
Making everything a property would have an effect on what "immutable"
means. It would mean that it was not the value of the property that was
immutable, but the behaviour. So calling <tstamp> would always set
TSTAMP to the current time, and the available task and condition would
return true or false depending on whether a file exists at this point in
the build. Given how dependencies are currently resolved I can't think
of a way this change would affect the ordering of the build. Of course
if you set the value to an Ant1 style property the value becomes
immutable, so backward compatibility would be maintained.
Some might not like this change. Personally, before macros I found far
too many "time1", "time2", "thisfileexists1" in my build files. After,
the fact I have to create macros to handle this basic functionality is
just an irritant. But it is an irritant I would love to see removed from
our lives.
Anyway, those are my thoughts on backward compatibility. I would love to
see more discussion about this.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Matt Benson <gu...@gmail.com>.
On Tue, Feb 14, 2012 at 8:13 AM, Stefan Bodewig <bo...@apache.org> wrote:
> On 2012-02-13, Bruce Atherton wrote:
>
>> I spent some time starting to implement a very simple (only a few
>> tasks) new version of Ant that started from Java 7. Personal issues
>> have taken me out of the game for a while, but I've still been
>> wondering, could Java 7 and NIO 2.0 be a good reason to create Ant
>> 2.0?
>
> There are things in NIO2 that can be added via FileUtils one way or the
> other, but it could also make us rethink our concept of Resources
> (although nio2's Path looks too limited for that).
>
> If we really want to take the burden of redesigning Ant on us then it
> certainly wouldn't only be NIO2 but also revolutionary things like
> generics. OTOH there will always be a reason to wait longer (lambdas,
> modules).
>
> I fully understand that throwing away the existing cruft can set free
> new energy. Personally I enjoy working on the Commons Antlib way more
> than working on the built-in Zip/Tar tasks because I could design them
> from a fresh start while the later have accumulated features with big
> care for API backwards compatibility.
>
> To me the strength of Ant (as it is) is in its tasks. The tasks are
> proven pieces of code that have been tested by an incredibly big amount
> of people. And even if we have about 200 bug reports open, most tasks
> do what they are supposed to do and do so very well. Any rewritten Ant
> would have a long way to reach the same level of stability. The same is
> true for the Compress Antlib vs the core tasks, of course.
>
>> It could be a way to sweep away the kind of cruft that is holding up
>> the release and to redesign Ant to reflect all the lessons learned
>> about how to build software in the last 10 years.
>
> This will lead us to the discussion of what Ant2 would be. A rewritten
> Ant that remains compatible (or mostly so) on the build file level or
> something quite different?
>
It would be very beneficial to have Ant 2 remain compatible at the
build file level if for no other reason than to facilitate testing of
v2 tasks: AntUnit-based tests should continue to pass, and as we've
seen, the vast majority of Ant's unit tests are expressible in the
AntUnit style.
Agreed that a v2 could allow us to cast off accumulated baggage. The
core of the redesign would be the most important thing to get right.
I suspect that the concept of a Resource would be closer to the core
(hindsight and all that) and would be interface-based. TBH, I've
never looked closely at nio1, let alone 2, until just now, but after a
quick look at java.nio.file.Path I confess that I don't immediately
see what it lacks that we would need.
Matt
> 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: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Posted by Stefan Bodewig <bo...@apache.org>.
On 2012-02-13, Bruce Atherton wrote:
> I spent some time starting to implement a very simple (only a few
> tasks) new version of Ant that started from Java 7. Personal issues
> have taken me out of the game for a while, but I've still been
> wondering, could Java 7 and NIO 2.0 be a good reason to create Ant
> 2.0?
There are things in NIO2 that can be added via FileUtils one way or the
other, but it could also make us rethink our concept of Resources
(although nio2's Path looks too limited for that).
If we really want to take the burden of redesigning Ant on us then it
certainly wouldn't only be NIO2 but also revolutionary things like
generics. OTOH there will always be a reason to wait longer (lambdas,
modules).
I fully understand that throwing away the existing cruft can set free
new energy. Personally I enjoy working on the Commons Antlib way more
than working on the built-in Zip/Tar tasks because I could design them
from a fresh start while the later have accumulated features with big
care for API backwards compatibility.
To me the strength of Ant (as it is) is in its tasks. The tasks are
proven pieces of code that have been tested by an incredibly big amount
of people. And even if we have about 200 bug reports open, most tasks
do what they are supposed to do and do so very well. Any rewritten Ant
would have a long way to reach the same level of stability. The same is
true for the Compress Antlib vs the core tasks, of course.
> It could be a way to sweep away the kind of cruft that is holding up
> the release and to redesign Ant to reflect all the lessons learned
> about how to build software in the last 10 years.
This will lead us to the discussion of what Ant2 would be. A rewritten
Ant that remains compatible (or mostly so) on the build file level or
something quite different?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org