Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
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
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
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 Scokartgscok...@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'soutofdate 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-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
On Sat, Feb 18, 2012 at 11:02 AM, Gilles Scokart gscok...@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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
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 Athertonbr...@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'scompilerarg 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
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
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 Athertonbr...@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'scompilerarg 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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
2012/2/16 Nicolas Lalevée nicolas.lale...@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 to 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 nicolas.lale...@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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
On Thu, Feb 16, 2012 at 2:49 PM, Mansour Al Akeel mansour.alak...@gmail.com wrote: 2012/2/16 Nicolas Lalevée nicolas.lale...@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
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-devm=98934355711364w=2
[2] http://marc.info/?l=ant-devm=97593652718829w=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-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
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-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Le 16 févr. 2012 à 20:49, Mansour Al Akeel a écrit : 2012/2/16 Nicolas Lalevée nicolas.lale...@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 to 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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Mansour Al Akeel mansour.alak...@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
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
On Tue, Feb 14, 2012 at 8:13 AM, Stefan Bodewig bode...@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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
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. 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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Mansour Al Akeel mansour.alak...@gmail.com wrote on 02/13/2012 01:57:56 PM: From: Mansour Al Akeel mansour.alak...@gmail.com To: Ant Developers List dev@ant.apache.org Cc: Stefan Bodewig bode...@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 ca...@us.ibm.com IBM WebSphere Application Server WAS Release Engineering
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
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 mansour.alak...@gmail.com wrote on 02/13/2012 01:57:56 PM: From: Mansour Al Akeel mansour.alak...@gmail.com To: Ant Developers List dev@ant.apache.org Cc: Stefan Bodewig bode...@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 *ca...@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
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 mansour.alak...@gmail.com wrote on 02/13/2012 01:57:56 PM: From: Mansour Al Akeel mansour.alak...@gmail.com To: Ant Developers List dev@ant.apache.org Cc: Stefan Bodewig bode...@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 _ca...@us.ibm.com_ mailto:ca...@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
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 mansour.alak...@gmail.com wrote on 02/13/2012 01:57:56 PM: From: Mansour Al Akeel mansour.alak...@gmail.com To: Ant Developers List dev@ant.apache.org Cc: Stefan Bodewig bode...@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/**crossedhttp://jpf.sourceforge.net/crossedmy 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 _ca...@us.ibm.com_ mailto:ca...@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
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-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
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?
