You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Peter Donald <pe...@apache.org> on 2002/05/01 13:46:30 UTC

Re: Ant extension, templatized build files

Hi,

On Wed, 1 May 2002 05:38, Chad Loder wrote:
> Hello. I am fairly new to ant, so please forgive me
> if this is an issue that's already been discussed
> (I did search the user and dev archives).

Templated build files are an important part of build process but at this stage 
ant-dev is unwilling to deal with it. Thus I would suggest that you go have a 
look at either 

* Centipede: http://krysalis.org/centipede/
* Maven: http://jakarta.apache.org/turbine/maven/

which offer more advanced build systems built on top of ant and partially 
implement templating like mechanisms.

-- 
Cheers,

Peter Donald


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Ant extension, templatized build files

Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Chad,

Yes, I recall seeing that message recently.  I did not take that as being a
"templating" enhancement to Ant and I didn't dig into it thoroughly because
of the Ant 1.5 release work I was doing.  My apologies.

So could you elaborate on how your proposal would work in a concrete way?

    Erik

----- Original Message -----
From: "Chad Loder" <cl...@acm.org>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Wednesday, May 01, 2002 5:28 PM
Subject: Re: Ant <project> extension, templatized build files


> At Wednesday 5/1/2002 05:04 PM -0400, you wrote:
> >I've never seen anyone post any design or patches for integrating any
kind
> >of templating into Ant's core.  So currently it would need to be built on
> >top of Ant.  I certainly welcome proposals and code patches that make it
> >more integrated - and can only comment on such after seeing it myself.
>
> The first message I sent on this thread is in fact such a
> design proposal. I really would welcome comments on it.
> I've requoted it here FYI.
>
> One constraining factor that I can think of is, how would you
> deal with an "extends=" attribute which contains property
> references?
>
> =============================================================
>  From my brief perusal of Project.java, it looks like
> this wouldn't be too hard to accomplish by adding
> something like:
>
>          private Project template;
>
> and then use this variable as a "last resort" for
> obtaining properties/task/references definitions not
> found in the "child" object.
>
> The syntax might look something like:
>
> <project name="r7" default="build" basedir="." extends="projtmpl.xml">
> </project>
>
> Is this an idea that has been broached before? Does it sound
> like a good idea, bad idea? Any obvious complications I might be
> overlooking?
> =============================================================
>
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Ant extension, templatized build files

Posted by Chad Loder <cl...@acm.org>.
At Wednesday 5/1/2002 05:04 PM -0400, you wrote:
>I've never seen anyone post any design or patches for integrating any kind
>of templating into Ant's core.  So currently it would need to be built on
>top of Ant.  I certainly welcome proposals and code patches that make it
>more integrated - and can only comment on such after seeing it myself.

The first message I sent on this thread is in fact such a
design proposal. I really would welcome comments on it.
I've requoted it here FYI.

One constraining factor that I can think of is, how would you
deal with an "extends=" attribute which contains property
references?

=============================================================
 From my brief perusal of Project.java, it looks like
this wouldn't be too hard to accomplish by adding
something like:

         private Project template;

and then use this variable as a "last resort" for
obtaining properties/task/references definitions not
found in the "child" object.

The syntax might look something like:

<project name="r7" default="build" basedir="." extends="projtmpl.xml">
</project>

Is this an idea that has been broached before? Does it sound
like a good idea, bad idea? Any obvious complications I might be
overlooking?
=============================================================



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Ant extension, templatized build files

Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Erik Hatcher" <ja...@ehatchersolutions.com>

> I know you're very interested!  :)  I wasn't really referring to you, of
> course.  The point is that in the Jakarta "culture", we all work on what
we
> want to work on and our actions speak louder than words - if you have an
> "itch to scratch", then you scratch it!
>
> Now that we have the pluggable ProjectHelper, do you see this as an area
> where this sort of thing can be accomplished?
>
> Certainly no one can stop you from the preprocessing possibilities such as
> XSLT and Velocity - those are all above Ant's core - so you can't blame
> veto's from stopping that from happening.  :)

Centipede doesn't do that, really.

The project descriptors generate properties with the new XmlProperty task
that we have contributed to Ant; it's pure Ant.

> I very much agree that Ant is not providing enough for a complete build
> environment.  The fact that others are filling these gaps is a good sign,
> especially that there is some competition going too. I just hope those
folks
> keep in touch with the ant-dev community so that we are aware of any hacks
> and workarounds that they are doing because of Ant architectural
> constraints. Their work (or pieces thereof) can be leveraged to bring into
> the core as their work matures, it seems.

Of course, as it has just been done for the XmlProperty task :-)

I'm also using the contrib stuff, and find the for-each task very useful,
BTW.

> There are other projects layered on top of Ant that folks could claim show
> that Ant isn't doing enough as well: CruiseControl, AntHill, Gump,
Vindico,
> and I'm sure several others. Under the hood of all of them is Ant though.
> We just need to be sure to be sensitive and cooperative to these other
> projects and make sure we play nicely with them.

IMO Ant is doing well, so well that other higher level project build on top
of it.

None of these projects want to replace Ant, the *use* Ant.

As long as Ant stays away from trying to be something in particular, it can
still have multiple uses.

Please resist the temptation of becoming a project system, and remain a task
execution engine, and Ant will thrive... forever! ;-)

Guve users-devs possibilities, don't enforce them. Just as you have always
done and are continuing to do.

> p.s. Did you say mutable properties?!   -1    :)))  (just kidding!)

Are you sure? ;-P

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Ant extension, templatized build files

Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
I know you're very interested!  :)  I wasn't really referring to you, of
course.  The point is that in the Jakarta "culture", we all work on what we
want to work on and our actions speak louder than words - if you have an
"itch to scratch", then you scratch it!

Now that we have the pluggable ProjectHelper, do you see this as an area
where this sort of thing can be accomplished?

Certainly no one can stop you from the preprocessing possibilities such as
XSLT and Velocity - those are all above Ant's core - so you can't blame
veto's from stopping that from happening.  :)

I very much agree that Ant is not providing enough for a complete build
environment.  The fact that others are filling these gaps is a good sign,
especially that there is some competition going too. I just hope those folks
keep in touch with the ant-dev community so that we are aware of any hacks
and workarounds that they are doing because of Ant architectural
constraints. Their work (or pieces thereof) can be leveraged to bring into
the core as their work matures, it seems.

There are other projects layered on top of Ant that folks could claim show
that Ant isn't doing enough as well: CruiseControl, AntHill, Gump, Vindico,
and I'm sure several others. Under the hood of all of them is Ant though.
We just need to be sure to be sensitive and cooperative to these other
projects and make sure we play nicely with them.

    Erik

p.s. Did you say mutable properties?!   -1    :)))  (just kidding!)



----- Original Message -----
From: "Peter Donald" <pe...@apache.org>
To: "Ant Developers List" <an...@jakarta.apache.org>; "Erik Hatcher"
<ja...@ehatchersolutions.com>
Cc: <dr...@paintyourselfsilly.com>
Sent: Wednesday, May 01, 2002 8:46 PM
Subject: Re: Ant <project> extension, templatized build files


On Thu, 2 May 2002 07:04, Erik Hatcher wrote:
> I think its an unfair generalization to say that ant-dev is "unwilling" to
> deal with it.

Historically it is fairly accurate. Go back to december-january archives in
2000-2001, then fastforward a few more months (where it was repeated again)
and then fastforward a few months again ...

> Perhaps "uninterested" is more accurate.

God no. I am VERY VERY VERY interested and have wanted this for ages (about
2
years). The way I would implement it has changed but not the desire to
implement it ;)

If this had been implemented then we would not even have this flame war on
general. (ie maven vs centipede/gump/forrest). The only reason these
projects
have come into existance is because ant is not providing all the necessary
pieces in a build environment. It is too much work to maintain complex build
files when you have oodles of very similar products and build processes.

> Is there some way
> in which we committers have made it more difficult to build the templating
> pieces on top?

vetoing it? Maybe not you but previous committers have done so and many a
flame war have focused on this issue. The required infrastructure has also
been vetoed a number of times (think mutable properties, scoping, etc).

> I've never seen anyone post any design or patches for integrating any kind
> of templating into Ant's core.

You haven't been round long enough. I have made proposals on a bunch of
different occasions. Everything from making the language dynamic evaluated
and constructed (effectively creating functions in ant) to preprocessing
(via
xslt, velocity) to inline expansion. The only one I haven't proposed for
ant1.x is inline expansion as I guess I learnt my lesson when I proposed the
two previous mechanisms ;)

The recent addition of DynamicTasks makes it possible to bypass many of the
limitations but others still remain.

--
Cheers,

Peter Donald




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Ant extension, templatized build files

Posted by Peter Donald <pe...@apache.org>.
On Thu, 2 May 2002 07:04, Erik Hatcher wrote:
> I think its an unfair generalization to say that ant-dev is "unwilling" to
> deal with it. 

Historically it is fairly accurate. Go back to december-january archives in 
2000-2001, then fastforward a few more months (where it was repeated again) 
and then fastforward a few months again ... 

> Perhaps "uninterested" is more accurate. 

God no. I am VERY VERY VERY interested and have wanted this for ages (about 2 
years). The way I would implement it has changed but not the desire to 
implement it ;)

If this had been implemented then we would not even have this flame war on 
general. (ie maven vs centipede/gump/forrest). The only reason these projects 
have come into existance is because ant is not providing all the necessary 
pieces in a build environment. It is too much work to maintain complex build 
files when you have oodles of very similar products and build processes.

> Is there some way
> in which we committers have made it more difficult to build the templating
> pieces on top?

vetoing it? Maybe not you but previous committers have done so and many a 
flame war have focused on this issue. The required infrastructure has also 
been vetoed a number of times (think mutable properties, scoping, etc).

> I've never seen anyone post any design or patches for integrating any kind
> of templating into Ant's core. 

You haven't been round long enough. I have made proposals on a bunch of 
different occasions. Everything from making the language dynamic evaluated 
and constructed (effectively creating functions in ant) to preprocessing (via 
xslt, velocity) to inline expansion. The only one I haven't proposed for 
ant1.x is inline expansion as I guess I learnt my lesson when I proposed the 
two previous mechanisms ;)

The recent addition of DynamicTasks makes it possible to bypass many of the 
limitations but others still remain.

-- 
Cheers,

Peter Donald


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Ant extension, templatized build files

Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 2 May 2002, Ara Abrahamian <ar...@yahoo.com> wrote:

> Do you have any plans to let us use a simple scripting language like
> rhino in Ant?

I could resort to RTFM 8-)  The task is even called <script>.

> <target name="blabla" depends="dada">
> 	<script language="rhino">
> 		if( project.getProperty("x.y.z").startsWith("foo") )
> 			....
> 	<script/>
> </target>

install BSF and rhino and replace "rhino" with "javascript".

Stefan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Ant extension, templatized build files

Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 2 May 2002, Ara Abrahamian <ar...@yahoo.com> wrote:

> can I use <script/> to add new mapper objects for examples?

No, they are Java only - at least right now.

Stefan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Ant extension, templatized build files

Posted by Ara Abrahamian <ar...@yahoo.com>.
Btw, to make it clearer (I know there's <script/> in optional.jar), can
I use <script/> to add new mapper objects for examples? The other days I
needed a specialized mapper type but I had to write java code,
compile/package/... it. And it's used only in one project.

Ara.

> -----Original Message-----
> From: Ara Abrahamian [mailto:ara_e_w@yahoo.com]
> Sent: Thursday, May 02, 2002 8:11 PM
> To: 'Ant Developers List'
> Subject: RE: Ant <project> extension, templatized build files
> 
> Btw, maybe completely offtopic, but...
> 
> Do you have any plans to let us use a simple scripting language like
> rhino in Ant? You know it's hard to program sophisticated builds with
> those if/unless/condition/blabla tags. I want to be able to do
something
> like this when needed:
> 
> <target name="blabla" depends="dada">
> 	<script language="rhino">
> 		if( project.getProperty("x.y.z").startsWith("foo") )
> 			....
> 	<script/>
> </target>
> 
> Or basically a simple scriplet mechanism for using in cases where the
> built-in xml-ish tasks can't help.
> 
> Or is it already implemented somewhere?
> 
> Cheers,
> Ara.
> 
> > -----Original Message-----
> > From: Erik Hatcher [mailto:jakarta-ant@ehatchersolutions.com]
> > Sent: Thursday, May 02, 2002 1:35 AM
> > To: Ant Developers List
> > Cc: drew@paintyourselfsilly.com
> > Subject: Re: Ant <project> extension, templatized build files
> >
> > I've never seen anyone post any design or patches for integrating
any
> kind
> > of templating into Ant's core.  So currently it would need to be
built
> on
> > top of Ant.  I certainly welcome proposals and code patches that
make
> it
> > more integrated - and can only comment on such after seeing it
myself.
> >
> > Ant 1.5 has decoupled ProjectHelper capability such that someone
could
> > change how the project model is built - it does not have to be built
> from
> > a
> > build.xml per se.  Thanks to Costin for that nice separation.  It
will
> be
> > interesting to see what comes out of it.
> >
> > For example, I believe Maven or Centipede could be modified to be a
> > ProjectHelperImpl and go straight from their project model to Ant's
> > internal
> > project object model, and bypass build.xml altogether.
> >
> > So, if there is something else about the Ant core that is
prohibiting
> or
> > constraining such templating, by all means bring it up.  And if
folks
> want
> > to toss out ideas about Ant core templating additions, I'm eager to
> hear
> > them.
> >
> > Drew, are you listening?  Have a look at the ProjectHelper stuff in
> Ant
> > 1.5
> > to see what kind of magic you can do there!
> >
> > As for your example of a build "component" - certainly its not
perfect
> at
> > the moment, but you can accomplish exactly what you describe using
> <ant> -
> > overriding properties and such.
> >
> >     Erik
> >
> > ----- Original Message -----
> > From: "Chad Loder" <cl...@acm.org>
> > To: "Ant Developers List" <an...@jakarta.apache.org>
> > Sent: Wednesday, May 01, 2002 3:29 PM
> > Subject: Re: Ant <project> extension, templatized build files
> >
> >
> > > Your email seem to suggest that templating must be built on top
> > > of ant, rather than into ant itself.  I looked at Maven and
> > > Centipede, downloaded them and played around with them.  To be
> > > honest I think they offer (or try to offer) much more than I
> > > need.
> > >
> > > Having thought about this some more, all I really want is to be
> > > able to define a target in one XML file (say, win32exe.xml).
> > > Then I could refer to it from other XML files, setting or
> > > overriding properties as necessary. I think I can do this with
> > > the <ant> built-in tasks.  Semantically it would be kind of weird,
> > > because as I understand it, the top-level element must be a
> > > <project> with a project name and so on...but if I can get the
> > > functionality I need this way, I'm not too worried about the
> > > semantics.
> > >
> > > What do you think?
> > >
> > >          c
> > >
> > > At Wednesday 5/1/2002 01:53 PM -0400, you wrote:
> > > >I think its an unfair generalization to say that ant-dev is
> "unwilling"
> > to
> > > >deal with it.  Perhaps "uninterested" is more accurate.  Is there
> some
> > way
> > > >in which we committers have made it more difficult to build the
> > templating
> > > >pieces on top?
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:   <mailto:ant-dev-
> > unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail: <mailto:ant-dev-
> > help@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 
> 
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Ant extension, templatized build files

Posted by Ara Abrahamian <ar...@yahoo.com>.
Btw, maybe completely offtopic, but...

Do you have any plans to let us use a simple scripting language like
rhino in Ant? You know it's hard to program sophisticated builds with
those if/unless/condition/blabla tags. I want to be able to do something
like this when needed:

<target name="blabla" depends="dada">
	<script language="rhino">
		if( project.getProperty("x.y.z").startsWith("foo") )
			....
	<script/>
</target>

Or basically a simple scriplet mechanism for using in cases where the
built-in xml-ish tasks can't help.

Or is it already implemented somewhere?

Cheers,
Ara.

> -----Original Message-----
> From: Erik Hatcher [mailto:jakarta-ant@ehatchersolutions.com]
> Sent: Thursday, May 02, 2002 1:35 AM
> To: Ant Developers List
> Cc: drew@paintyourselfsilly.com
> Subject: Re: Ant <project> extension, templatized build files
> 
> I've never seen anyone post any design or patches for integrating any
kind
> of templating into Ant's core.  So currently it would need to be built
on
> top of Ant.  I certainly welcome proposals and code patches that make
it
> more integrated - and can only comment on such after seeing it myself.
> 
> Ant 1.5 has decoupled ProjectHelper capability such that someone could
> change how the project model is built - it does not have to be built
from
> a
> build.xml per se.  Thanks to Costin for that nice separation.  It will
be
> interesting to see what comes out of it.
> 
> For example, I believe Maven or Centipede could be modified to be a
> ProjectHelperImpl and go straight from their project model to Ant's
> internal
> project object model, and bypass build.xml altogether.
> 
> So, if there is something else about the Ant core that is prohibiting
or
> constraining such templating, by all means bring it up.  And if folks
want
> to toss out ideas about Ant core templating additions, I'm eager to
hear
> them.
> 
> Drew, are you listening?  Have a look at the ProjectHelper stuff in
Ant
> 1.5
> to see what kind of magic you can do there!
> 
> As for your example of a build "component" - certainly its not perfect
at
> the moment, but you can accomplish exactly what you describe using
<ant> -
> overriding properties and such.
> 
>     Erik
> 
> ----- Original Message -----
> From: "Chad Loder" <cl...@acm.org>
> To: "Ant Developers List" <an...@jakarta.apache.org>
> Sent: Wednesday, May 01, 2002 3:29 PM
> Subject: Re: Ant <project> extension, templatized build files
> 
> 
> > Your email seem to suggest that templating must be built on top
> > of ant, rather than into ant itself.  I looked at Maven and
> > Centipede, downloaded them and played around with them.  To be
> > honest I think they offer (or try to offer) much more than I
> > need.
> >
> > Having thought about this some more, all I really want is to be
> > able to define a target in one XML file (say, win32exe.xml).
> > Then I could refer to it from other XML files, setting or
> > overriding properties as necessary. I think I can do this with
> > the <ant> built-in tasks.  Semantically it would be kind of weird,
> > because as I understand it, the top-level element must be a
> > <project> with a project name and so on...but if I can get the
> > functionality I need this way, I'm not too worried about the
> > semantics.
> >
> > What do you think?
> >
> >          c
> >
> > At Wednesday 5/1/2002 01:53 PM -0400, you wrote:
> > >I think its an unfair generalization to say that ant-dev is
"unwilling"
> to
> > >deal with it.  Perhaps "uninterested" is more accurate.  Is there
some
> way
> > >in which we committers have made it more difficult to build the
> templating
> > >pieces on top?
> >
> >
> >
> > --
> > To unsubscribe, e-mail:   <mailto:ant-dev-
> unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <mailto:ant-dev-
> help@jakarta.apache.org>
> >
> >
> 
> 
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Ant extension, templatized build files

Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
I've never seen anyone post any design or patches for integrating any kind
of templating into Ant's core.  So currently it would need to be built on
top of Ant.  I certainly welcome proposals and code patches that make it
more integrated - and can only comment on such after seeing it myself.

Ant 1.5 has decoupled ProjectHelper capability such that someone could
change how the project model is built - it does not have to be built from a
build.xml per se.  Thanks to Costin for that nice separation.  It will be
interesting to see what comes out of it.

For example, I believe Maven or Centipede could be modified to be a
ProjectHelperImpl and go straight from their project model to Ant's internal
project object model, and bypass build.xml altogether.

So, if there is something else about the Ant core that is prohibiting or
constraining such templating, by all means bring it up.  And if folks want
to toss out ideas about Ant core templating additions, I'm eager to hear
them.

Drew, are you listening?  Have a look at the ProjectHelper stuff in Ant 1.5
to see what kind of magic you can do there!

As for your example of a build "component" - certainly its not perfect at
the moment, but you can accomplish exactly what you describe using <ant> -
overriding properties and such.

    Erik

----- Original Message -----
From: "Chad Loder" <cl...@acm.org>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Wednesday, May 01, 2002 3:29 PM
Subject: Re: Ant <project> extension, templatized build files


> Your email seem to suggest that templating must be built on top
> of ant, rather than into ant itself.  I looked at Maven and
> Centipede, downloaded them and played around with them.  To be
> honest I think they offer (or try to offer) much more than I
> need.
>
> Having thought about this some more, all I really want is to be
> able to define a target in one XML file (say, win32exe.xml).
> Then I could refer to it from other XML files, setting or
> overriding properties as necessary. I think I can do this with
> the <ant> built-in tasks.  Semantically it would be kind of weird,
> because as I understand it, the top-level element must be a
> <project> with a project name and so on...but if I can get the
> functionality I need this way, I'm not too worried about the
> semantics.
>
> What do you think?
>
>          c
>
> At Wednesday 5/1/2002 01:53 PM -0400, you wrote:
> >I think its an unfair generalization to say that ant-dev is "unwilling"
to
> >deal with it.  Perhaps "uninterested" is more accurate.  Is there some
way
> >in which we committers have made it more difficult to build the
templating
> >pieces on top?
>
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Ant extension, templatized build files

Posted by Chad Loder <cl...@acm.org>.
Your email seem to suggest that templating must be built on top
of ant, rather than into ant itself.  I looked at Maven and
Centipede, downloaded them and played around with them.  To be
honest I think they offer (or try to offer) much more than I
need.

Having thought about this some more, all I really want is to be
able to define a target in one XML file (say, win32exe.xml).
Then I could refer to it from other XML files, setting or
overriding properties as necessary. I think I can do this with
the <ant> built-in tasks.  Semantically it would be kind of weird,
because as I understand it, the top-level element must be a
<project> with a project name and so on...but if I can get the
functionality I need this way, I'm not too worried about the
semantics.

What do you think?

         c

At Wednesday 5/1/2002 01:53 PM -0400, you wrote:
>I think its an unfair generalization to say that ant-dev is "unwilling" to
>deal with it.  Perhaps "uninterested" is more accurate.  Is there some way
>in which we committers have made it more difficult to build the templating
>pieces on top?



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Ant extension, templatized build files

Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
I think its an unfair generalization to say that ant-dev is "unwilling" to
deal with it.  Perhaps "uninterested" is more accurate.  Is there some way
in which we committers have made it more difficult to build the templating
pieces on top?

Ant *core* is still the engine that will be used at the lowest level of
templated build files.  I'm personally interested in the core engine at the
moment, and the meta/templating layer has not been something of interest to
me (yet).  There's room for us to all work at our own preferred layers, I
think.

I applaud these efforts, but don't categorize me as being "unwilling".  :))
I'm all for the evolution of layers on top of Ant.  Currently Maven and
Centipede are in the midst of a tug-of-war and its probably best to let the
dust settle a bit, unless you (meaning anyone listening) wants to jump in
and help out with one or both of these efforts.  Both are probably
self-admittedly "alpha" releases.

Both of these efforts generate some spectacular results and if your project
is fairly typical it can be built with Maven easily, it seems. I need to
research Centipede more to see what its capabilities are, but from what I
hear they are fairly similar.

    Erik



----- Original Message -----
From: "Peter Donald" <pe...@apache.org>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Wednesday, May 01, 2002 7:46 AM
Subject: Re: Ant <project> extension, templatized build files


Hi,

On Wed, 1 May 2002 05:38, Chad Loder wrote:
> Hello. I am fairly new to ant, so please forgive me
> if this is an issue that's already been discussed
> (I did search the user and dev archives).

Templated build files are an important part of build process but at this
stage
ant-dev is unwilling to deal with it. Thus I would suggest that you go have
a
look at either

* Centipede: http://krysalis.org/centipede/
* Maven: http://jakarta.apache.org/turbine/maven/

which offer more advanced build systems built on top of ant and partially
implement templating like mechanisms.

--
Cheers,

Peter Donald


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Ant extension, templatized build files

Posted by Peter Donald <pe...@apache.org>.
On Thu, 2 May 2002 02:28, Chad Loder wrote:
> Bummer. Sounds like this has already been discussed? 

discussed to death.

> Can
> you point me to any archived messages maybe, or just give
> a brief synopsis of why ant isn't willing to deal with it?

Part of the problem is that the current architecture of Ant does not support 
all that is required. Essentially we would need to delay evalution of a whole 
bunch of things, add in semantics for either scoping or overiding of 
properties/datatypes/taskdefs/typedefs/etc, add in a slightly different 
processing model ...

Some of these things are backwards incompatible and some have been blocked in 
the past. Even if this was not the case there has been several little flame 
wars regarding how to implement this that basically paralyzed progress. 

I would recomend you have a look at the existing projects as they are more 
likely to be imediately usable by you.

-- 
Cheers,

Peter Donald


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Ant extension, templatized build files

Posted by Chad Loder <cl...@acm.org>.
Peter,

Bummer. Sounds like this has already been discussed? Can
you point me to any archived messages maybe, or just give
a brief synopsis of why ant isn't willing to deal with it?

Thanks,
         c

At Wednesday 5/1/2002 09:46 PM +1000, you wrote:
>Hi,
>
>On Wed, 1 May 2002 05:38, Chad Loder wrote:
> > Hello. I am fairly new to ant, so please forgive me
> > if this is an issue that's already been discussed
> > (I did search the user and dev archives).
>
>Templated build files are an important part of build process but at this 
>stage
>ant-dev is unwilling to deal with it. Thus I would suggest that you go have a
>look at either
>
>* Centipede: http://krysalis.org/centipede/
>* Maven: http://jakarta.apache.org/turbine/maven/
>
>which offer more advanced build systems built on top of ant and partially
>implement templating like mechanisms.
>
>--
>Cheers,
>
>Peter Donald
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>