Return-Path: Delivered-To: apmail-ant-dev-archive@www.apache.org Received: (qmail 9768 invoked from network); 3 Oct 2008 10:07:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 3 Oct 2008 10:07:09 -0000 Received: (qmail 41796 invoked by uid 500); 3 Oct 2008 10:07:07 -0000 Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 41464 invoked by uid 500); 3 Oct 2008 10:07:06 -0000 Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list dev@ant.apache.org Received: (qmail 41453 invoked by uid 99); 3 Oct 2008 10:07:06 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Oct 2008 03:07:06 -0700 X-ASF-Spam-Status: No, hits=3.2 required=10.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.200.172] (HELO wf-out-1314.google.com) (209.85.200.172) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Oct 2008 10:06:01 +0000 Received: by wf-out-1314.google.com with SMTP id 29so1539400wff.10 for ; Fri, 03 Oct 2008 03:06:35 -0700 (PDT) Received: by 10.142.142.16 with SMTP id p16mr300096wfd.143.1223028395171; Fri, 03 Oct 2008 03:06:35 -0700 (PDT) Received: by 10.143.44.16 with HTTP; Fri, 3 Oct 2008 03:06:35 -0700 (PDT) Message-ID: <66544f950810030306k49b769b6r7d273aafaffcb56a@mail.gmail.com> Date: Fri, 3 Oct 2008 12:06:35 +0200 From: "Remie Bolte" To: "Ant Developers List" Subject: Re: Taking Ant To The Next Level. In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_17005_29662344.1223028395165" References: X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_17005_29662344.1223028395165 Content-Type: multipart/alternative; boundary="----=_Part_17006_5379143.1223028395165" ------=_Part_17006_5379143.1223028395165 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi! In addition to this, I think it would be a good idea to look at namespacing as a method of dealing with backwards compatibility. Currently the ANT project doesn't seem to make use of the full potential of XML namespaces. There is no necessity to declare a namespace, so many projects will probably reside in the NULL namespace. Image the power of having a different namespace per ANT release. You can then have namespace specific parsers which can deal with version specific implementations of tasks: In the above example, we mix two ant implementations. The ANT distribution can contain both parsers and smart route the tags based on namespace. This would allow programmers to use old and new features at the same time, without fearing for backwards compatibilty. Of course there is a performance hit, but that is a descision you can leave to the developer. If it doesn't matter if a build process takes 1 or 2 hours, but upgrading is an issue because the code is mission critical, in this scenario they have the option to use new features that might enable them to perform tasks previously impossible. So far my initial 2 cents in this discussion. Since i'm new to this list (i've been following it for a while) i might have missed lots of discussions about this. If so, my sincere apologies. Cheers, Remie Bolte * Tools Engineer & Build manager* * BACKBASE*, "The Ajax Company" www.backbase.com Email : remie@backbase.com Main : +31 (0)20 4658888 On Mon, Aug 11, 2008 at 2:34 PM, Petar Tahchiev wrote: > Hi everybody, > > first of all I want to appologize to those who might consider this email as > a spam. > > Lately I have been thinking on the future of Ant, and I would like to share > with you my vision on > the matter (maybe about Ant 2.0). The way I see targets is like methods. > And > the way I see > build.xmls is like classes. So could it be possible that it looks like some > of the following: > > ================================================================= > > > > > > > > > > > > > > > > > > > > > > > > ================================================================= > > Now I know that one can achieve this with the current status of Ant, but > this is just a hint how it > can be done more flexible. There are a couple of things I would like to > highlight here: > 0) The inheritance of build.xmls, and mutability of properties from the > inheritance. > 1) The way one target calls the other one and passes certain values, not > all > the values by setting inheritAll="true" > 2) The new target task, which is flexble enough for target invocation. > > Once again, I know that one can use some code implemented in Groovy or > JavaScript (for instance) to achieve > this, but this is one of my visions for the future of Ant. > > What are yours? > > -- > Regards, Petar! > Karlovo, Bulgaria. > - - - - - - - - > | Author @ Manning Publications. > | Technical Consultant @ HP > | BGJUG-Bulgarian Java User Group Leader. > | Apache Jakarta PMC member. > | Jakarta Cactus Lead Developer. > | Blogger: http://weblogs.java.net/blog/paranoiabla/ > - - - - - - - - > Public PGP Key at: > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 > ------=_Part_17006_5379143.1223028395165 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi!

In addition to this, I think it would be a good idea to look at namespacing as a method of dealing with backwards compatibility.
Currently the ANT project doesn't seem to make use of the full potential of XML namespaces. There is no necessity to declare a namespace, so many projects will probably reside in the NULL namespace.

Image the power of having a different namespace per ANT release. You can then have namespace specific parsers which can deal with version specific implementations of tasks:

<ant22:project xmlns:ant21="http://ant.apache.org/2010/06/antproject" xmlns:ant22="http://ant.apache.org/2010/09/antproject">

  <ant22:condition property="available.for.22" value="true">
    <ant22:available dir="someDirectory" />
  </ant22:condition>

  <ant21:condition property="available.for.21" value="true">
    <ant21:available file="someDirectory" type="dir" />
  </ant21:condition>

  <ant22:target name="someTarget" if="available.for.22">
    <ant22:copy dir="someDir" todir="someOtherDir" />
    <ant21:copy todir="someOtherDir">
       <ant21:fileset dir="someDir" />
    </ant21:copy>
  </ant22:target>

</and22:project>

In the above example, we mix two ant implementations. The ANT distribution can contain both parsers and smart route the tags based on namespace. This would allow programmers to use old and new features at the same time, without fearing for backwards compatibilty. Of course there is a performance hit, but that is a descision you can leave to the developer. If it doesn't matter if a build process takes 1 or 2 hours, but upgrading is an issue because the code is mission critical, in this scenario they have the option to use new features that might enable them to perform tasks previously impossible.

So far my initial 2 cents in this discussion. Since i'm new to this list (i've been following it for a while) i might have missed lots of discussions about this. If so, my sincere apologies.

Cheers,

Remie Bolte

Tools Engineer & Build manager
 
 BACKBASE, "The Ajax Company"
www.backbase.com
 
Email    : remie@backbase.com
Main    : +31 (0)20 4658888




On Mon, Aug 11, 2008 at 2:34 PM, Petar Tahchiev <paranoiabla@gmail.com> wrote:
Hi everybody,

first of all I want to appologize to those who might consider this email as
a spam.

Lately I have been thinking on the future of Ant, and I would like to share
with you my vision on
the matter (maybe about Ant 2.0). The way I see targets is like methods. And
the way I see
build.xmls is like classes. So could it be possible that it looks like some
of the following:

=================================================================
<project name="Test" default="main" inherits="../../base-build.xml">

<target name="init" depends="">
  <!--The init target overrides the init from the base-build.xml and
changes the value of the property -->
 <property name="version" value="1.0"/>
</target>

<target name="print" accepts="version, args...">
  <echo message="version"/>
  <loop over="$.{args}" id="i">
     <echo message="$.{args}[i]"/>
  </loop>
</target>

<target name="print" depends="init">
  <!-- First execution -->
  <ant antfile="" target="init('version', {'first', 'second'})"/>

  <!-- Second execution-->
  <target name="init (${version}, NIL)"/>
</target>

</project>
=================================================================

Now I know that one can achieve this with the current status of Ant, but
this is just a hint how it
can be done more flexible. There are a couple of things I would like to
highlight here:
0) The inheritance of build.xmls, and mutability of properties from the
inheritance.
1) The way one target calls the other one and passes certain values, not all
the values by setting inheritAll="true"
2) The new target task, which is flexble enough for target invocation.

Once again, I know that one can use some code implemented in Groovy or
JavaScript (for instance) to achieve
this, but this is one of my visions for the future of Ant.

What are yours?

--
Regards, Petar!
Karlovo, Bulgaria.
- - - - - - - -
| Author @ Manning Publications.
| Technical Consultant @ HP
| BGJUG-Bulgarian Java User Group Leader.
| Apache Jakarta PMC member.
| Jakarta Cactus Lead Developer.
| Blogger: http://weblogs.java.net/blog/paranoiabla/
- - - - - - - -
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

------=_Part_17006_5379143.1223028395165-- ------=_Part_17005_29662344.1223028395165 Content-Type: image/bmp; name=backbase_logo_small.bmp Content-Transfer-Encoding: base64 Content-ID: <250072713@29092008-06C9> X-Attachment-Id: 0.1 Qk1IAgAAAAAAADYAAAAoAAAAEAAAAAsAAAABABgAAAAAABICAAASCwAAEgsAAAAAAAAAAAAA//// ////7/D+VFzyRk7xSVHxSFHxSFHxSFHxSFHxSFHxSFHxSFHxSFDxR0/xtLb5////////7u/+RU7x Nj/wMjvvLjjvLjjvLjjvLjjvLjjvLjjvLjjvMTvvND3vTVTx////////7u/+R0/xMjzvh432sLT5 rbH5rbH5rbH5rbH5rbH5rbD5fYP1NT7vO0Tw////////7u/+R0/xLjfvys37//////////////// ////////////zs/8MjzvPEXw////////7/D+SFDxND3wcXf0jJH2jJH2jJH2jJH2h4z2pqr4//// yMr7Mz3vPEXw////////7O3+RE3xOEHwKjTvJS/uJS/uJS/uJjDuHSftWF7y////yMr7Mz3vPEXw ////////naH4MDrvOkPwd331gIb1gIb1fYP1eX/1dHr0mJz3////yMr7Mz3vPEXw////5+j9Q0zx LDbvdHv0////////////////////////////////zs/7MjzvPEXw////hYr2LDbvPkfw3uD8//// uLz6oqb4pan4pan4pan4pan4pan4eH71Nj/wOkPw19n8OULwLTbvkpf2////09X7MzzvLTfvLznv LznvLznvLznvLznvND3vNj/wRU7xb3b0LjjvUVny8fL+/Pz/bHP0MjzvPEXwPEXwPEXwPEXwPEXw PEXwOkPwQUnwsrX5AAA= ------=_Part_17005_29662344.1223028395165--