Return-Path: 
 <dev-return-86815-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
X-Original-To: apmail-ant-dev-archive@www.apache.org
Delivered-To: apmail-ant-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id EB55292F1
	for <apmail-ant-dev-archive@www.apache.org>;
 Wed, 22 Feb 2012 19:05:52 +0000 (UTC)
Received: (qmail 37963 invoked by uid 500); 22 Feb 2012 19:05:52 -0000
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 37837 invoked by uid 500); 22 Feb 2012 19:05:52 -0000
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@ant.apache.org>
List-Help: <mailto:dev-help@ant.apache.org>
List-Post: <mailto:dev@ant.apache.org>
List-Id: "Ant Developers List" <dev.ant.apache.org>
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Delivered-To: mailing list dev@ant.apache.org
Received: (qmail 37829 invoked by uid 99); 22 Feb 2012 19:05:52 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Feb 2012 19:05:52 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [173.247.251.126] (HELO biz82.inmotionhosting.com)
 (173.247.251.126)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Feb 2012 19:05:45 +0000
Received: from [24.108.137.46] (port=63934 helo=[192.168.145.106])
	by biz82.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.69)
	(envelope-from <bruce@callenish.com>)
	id 1S0HVD-00085L-M5; Wed, 22 Feb 2012 11:05:23 -0800
Message-ID: <4F453C71.10905@callenish.com>
Date: Wed, 22 Feb 2012 11:05:21 -0800
From: Bruce Atherton <bruce@callenish.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Ant Developers List <dev@ant.apache.org>
CC: Dominique Devienne <ddevienne@gmail.com>,
 Gilles Scokart <gscokart@gmail.com>
Subject: Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
References: 
 <CAFvvX=a6iURwebprsUYDhtwcmNdwwbgr=88yfAiXpSuCOKFBuQ@mail.gmail.com>
 <87obtc1l08.fsf@v35516.1blu.de> <4F39559A.80003@callenish.com>
 <87haytzeoi.fsf@v35516.1blu.de> <4F3AAFD1.9050508@callenish.com>
 <0034F824-F1B4-4893-B835-65DC6226B4F7@hibnet.org>
 <4F3D5D39.1000603@callenish.com>
 <E4F33356-4D08-4AD1-BB8B-CA4976961552@hibnet.org>
 <4F3D8BB9.3040301@callenish.com>
 <CAFCRh-_Qem83DK2s-hK9NaNc4gq6W+WhP2nXizie8H7eE6n7rA@mail.gmail.com>
 <4F3EA58E.7060200@callenish.com>
 <CADLR5X+V2fP2Wx8n9kHTq9oNBBcyrqv6ptHaxVAaxeefn-3+8Q@mail.gmail.com>
 <CAFCRh-_nqzARck-fXiHnAwO+nEXmfkkDgDfDbMFXxDkP9epWXw@mail.gmail.com>
 <4F43FCEC.2040206@callenish.com>
In-Reply-To: <4F43FCEC.2040206@callenish.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse,
 please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com
X-AntiAbuse: Original Domain - ant.apache.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - callenish.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 

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