Re: Taking Ant To The Next Level.

2008-10-03 Thread Remie Bolte
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: [EMAIL PROTECTED] [EMAIL PROTECTED]
Main: +31 (0)20 465




On Mon, Aug 11, 2008 at 2:34 PM, Petar Tahchiev [EMAIL PROTECTED]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

backbase_logo_small.bmp

Re: AW: Ant @ CIServer TeamCity

2008-10-03 Thread Steve Loughran

[EMAIL PROTECTED] wrote:

Nice integration.

I like TeamCitys build agents. Has [EMAIL PROTECTED] some configured for 
different platforms (Linux, Windows)?

Because of the integration with Jira: is that something for Ivy? Is there an integration with Bugzilla? 


We should move Ant over to Jira too, perhaps. It makes x-filing bugs 
between ivy and other projects better, and has a fairly good experience 
*Except over very slow networks*.


1. Yahoo! are working with infrastructure on some build farm. Hadoop is 
their line of business app and they care about it never failing a test.


2. We are bringing up hudson at work on a set of machines, real and 
virtual. I could get it to build ant too, but you wont get to see the 
results, just get the mail. So much mail.

  -OS/X only works if someone is logged on
  -some of the linux VMs experience clock drift; this really makes a 
mess of a release process. Amazon AWS Auth doesnt even want to talk to 
you if your clock is 8 hours out, so there goes some of our functional 
tests, for example.





--
Steve Loughran  http://www.1060.org/blogxter/publish/5
Author: Ant in Action   http://antbook.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]