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<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
---------------------------------------------------------------------
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
