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/06/23 06:08:39 UTC
Re: Object oriented builds
At 11:45 PM 6/22/2002 -0400, you wrote:
> I'm thinking at the API level now, not the XML representation.
>What I'd like to do is create a StandardJavaProject project which does all
>the basic stuff like init, clean, compile, jar, and javadoc. In slightly
>more advanced projects, I might want to use a XDocletProject, where all
>stays the same except a new "gensrc" target is added and the compile target
>is modified to depend on it and add the generated source directory to the
>compile and javadoc stage. Does that make sense?
In myrmidon this is the case. You can define "templates" for each of your
important build processes and then reuse them. For example you could do the
following
<template-def name="x-buildnumber">
<attribute name="file" type="java.io.File" default="build.number"/>
<logic>
<buildnumber file="@{file}"/>
<exec command="cvs commit @{file}"/>
</logic>
</template-def>
Then later in your build you just do
<x-buildnumber/> and it increments build number and commits it back to CVS.
Of course these templates can be as complex or simple as you want.
As the templates get larger or shared you will want them to be stored in a
library. So you create a separate XML file and then register them template
as a task with a special factory. Usually you register tasks via
<types>
<task name="buildnumber" impl="o.a.a.build.BuildNumber"/>
</types>
However when you are doing template tasks you need an extra attribute
("factory") to indicate how the tasks are created. (Note that this is not
entirely implemented in Myrmidon just yet I don't think - Adam?). So it
ends up looking like
<types>
<task name="x-buildnumber" impl="o/a/a/build/BuildNumber.template"
factory="template-factory"/>
</types>
The problem with the current implementation is that the template is loaded
into memory when it is declared which ends up using massive amounts of
memory when you are not using template. So in the future myrmidon will load
and cache templates at runtime.
The idea is to support all the functionality needed for meta build projects
like Centipede/Maven (but let them rigfht the actual templates).
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Object oriented builds
Posted by Peter Donald <pe...@apache.org>.
At 03:01 PM 6/23/2002 +1000, you wrote:
>Um, Pete, you haven't checked in the <template-def> task yet. All the other
>stuff is there - TemplateDef, TemplateTask, etc - just no TemplateDefTask.
Ug. I swear I will do it on thursday ;)
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Object oriented builds
Posted by Peter Donald <pe...@apache.org>.
On Sun, 23 Jun 2002 23:01, Stephane Bailliez wrote:
> ----- Original Message -----
> From: "Erik Hatcher" <ja...@ehatchersolutions.com>
>
> > Pretty cool. Thanks for the discussion on this.
>
> Does all this discussion means that there is no more vetoes for project and
> target inheritance in Ant 2 (see document) ? or that it is slightly altered
> ? It seems contradictory to me or I missed something.
Naah there is no project/target inheritance in myrmidon. I believe I may have
been one of the people who initially vetoed that feature. This is less
inheritance and all that jazz, it is just defining a task in
terms of other tasks.However I find it more useful to think of it as defining
a new "build process" as a task.
It would be possible to implement inheritance in myrmidon as it is all fairly
pluggable however we have not yet gone down that path to test things out.
--
Cheers,
Peter Donald
---------------------------------------------------
"It is easy to dodge our responsibilities, but we
cannot dodge the consequences of dodging our
responsibilities." -Josiah Stamp
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Object oriented builds
Posted by Stephane Bailliez <sb...@apache.org>.
----- Original Message -----
From: "Adam Murdoch" <ad...@apache.org>
>Those vetos are sooo old. I wonder if it'd still be vetoed, particularly
>since we've had things like maven come along to demonstrate how much more
>powerful it can be to define projects in high-level terms.
I failed to explain clearly my position about project and target
inheritance, but when I asked for it back in march 2001 it was because I
spent a good deal of time gumpifying all my company projects and setup
something like maven, so project inheritance could have been a good addition
to me and it was kind of evident. Now that a lot more people use Gump or
Maven, I guess it shows up more.
>Something we've done in myrmidon, is to make the project model as pluggable
as
>possible. So, even if, say, project/target inheritance is vetoed, it is
easy
>enough for someone to write their own project model that added it in. They
>could then chuck it in an antlib and share it with others.
>A decent templating solution might be a good middle ground between the ant1
>model, and built-in project/target inheritance. It could provide the tools
>you'd need to put together inheritance, without affecting the core project
>model.
Good stuff. It's even better.
Stephane
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Object oriented builds
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Adam Murdoch wrote:
> On Sun, 23 Jun 2002 23:01, Stephane Bailliez wrote:
>
>>Does all this discussion means that there is no more vetoes for project and
>>target inheritance in Ant 2 (see document) ? or that it is slightly altered
>>? It seems contradictory to me or I missed something.
>
>
> Those vetos are sooo old.
Agreed. They were useful to get a broad idea of what Ant2 could and
should do. Today I think implementation has overtaken some of the
original issues.
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Object oriented builds
Posted by Adam Murdoch <ad...@apache.org>.
On Sun, 23 Jun 2002 23:01, Stephane Bailliez wrote:
> ----- Original Message -----
> From: "Erik Hatcher" <ja...@ehatchersolutions.com>
>
> > Pretty cool. Thanks for the discussion on this.
>
> Does all this discussion means that there is no more vetoes for project and
> target inheritance in Ant 2 (see document) ? or that it is slightly altered
> ? It seems contradictory to me or I missed something.
Those vetos are sooo old. I wonder if it'd still be vetoed, particularly
since we've had things like maven come along to demonstrate how much more
powerful it can be to define projects in high-level terms.
Something we've done in myrmidon, is to make the project model as pluggable as
possible. So, even if, say, project/target inheritance is vetoed, it is easy
enough for someone to write their own project model that added it in. They
could then chuck it in an antlib and share it with others.
A decent templating solution might be a good middle ground between the ant1
model, and built-in project/target inheritance. It could provide the tools
you'd need to put together inheritance, without affecting the core project
model.
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Object oriented builds
Posted by Stephane Bailliez <sb...@apache.org>.
----- Original Message -----
From: "Erik Hatcher" <ja...@ehatchersolutions.com>
> Pretty cool. Thanks for the discussion on this.
Does all this discussion means that there is no more vetoes for project and
target inheritance in Ant 2 (see document) ? or that it is slightly altered
? It seems contradictory to me or I missed something.
Stephane
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Object oriented builds
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Pretty cool. Thanks for the discussion on this.
Erik
----- Original Message -----
From: "Peter Donald" <pe...@apache.org>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Sunday, June 23, 2002 12:08 AM
Subject: Re: Object oriented builds
> At 11:45 PM 6/22/2002 -0400, you wrote:
> > I'm thinking at the API level now, not the XML representation.
> >What I'd like to do is create a StandardJavaProject project which does
all
> >the basic stuff like init, clean, compile, jar, and javadoc. In slightly
> >more advanced projects, I might want to use a XDocletProject, where all
> >stays the same except a new "gensrc" target is added and the compile
target
> >is modified to depend on it and add the generated source directory to the
> >compile and javadoc stage. Does that make sense?
>
> In myrmidon this is the case. You can define "templates" for each of your
> important build processes and then reuse them. For example you could do
the
> following
>
> <template-def name="x-buildnumber">
> <attribute name="file" type="java.io.File" default="build.number"/>
> <logic>
> <buildnumber file="@{file}"/>
> <exec command="cvs commit @{file}"/>
> </logic>
> </template-def>
>
> Then later in your build you just do
>
> <x-buildnumber/> and it increments build number and commits it back to
CVS.
> Of course these templates can be as complex or simple as you want.
>
> As the templates get larger or shared you will want them to be stored in a
> library. So you create a separate XML file and then register them template
> as a task with a special factory. Usually you register tasks via
>
> <types>
> <task name="buildnumber" impl="o.a.a.build.BuildNumber"/>
> </types>
>
> However when you are doing template tasks you need an extra attribute
> ("factory") to indicate how the tasks are created. (Note that this is not
> entirely implemented in Myrmidon just yet I don't think - Adam?). So it
> ends up looking like
>
> <types>
> <task name="x-buildnumber" impl="o/a/a/build/BuildNumber.template"
> factory="template-factory"/>
> </types>
>
> The problem with the current implementation is that the template is loaded
> into memory when it is declared which ends up using massive amounts of
> memory when you are not using template. So in the future myrmidon will
load
> and cache templates at runtime.
>
> The idea is to support all the functionality needed for meta build
projects
> like Centipede/Maven (but let them rigfht the actual templates).
>
>
> Cheers,
>
> Peter Donald
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "Faced with the choice between changing one's mind,
> and proving that there is no need to do so - almost
> everyone gets busy on the proof."
> - John Kenneth Galbraith
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> --
> 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: Object oriented builds
Posted by Adam Murdoch <ad...@apache.org>.
On Sun, 23 Jun 2002 14:08, Peter Donald wrote:
> At 11:45 PM 6/22/2002 -0400, you wrote:
> > I'm thinking at the API level now, not the XML representation.
> >What I'd like to do is create a StandardJavaProject project which does all
> >the basic stuff like init, clean, compile, jar, and javadoc. In slightly
> >more advanced projects, I might want to use a XDocletProject, where all
> >stays the same except a new "gensrc" target is added and the compile
> > target is modified to depend on it and add the generated source directory
> > to the compile and javadoc stage. Does that make sense?
>
> In myrmidon this is the case. You can define "templates" for each of your
> important build processes and then reuse them. For example you could do the
> following
>
> <template-def name="x-buildnumber">
> <attribute name="file" type="java.io.File" default="build.number"/>
> <logic>
> <buildnumber file="@{file}"/>
> <exec command="cvs commit @{file}"/>
> </logic>
> </template-def>
Um, Pete, you haven't checked in the <template-def> task yet. All the other
stuff is there - TemplateDef, TemplateTask, etc - just no TemplateDefTask.
> As the templates get larger or shared you will want them to be stored in a
> library. So you create a separate XML file and then register them template
> as a task with a special factory. Usually you register tasks via
>
> <types>
> <task name="buildnumber" impl="o.a.a.build.BuildNumber"/>
> </types>
>
> However when you are doing template tasks you need an extra attribute
> ("factory") to indicate how the tasks are created. (Note that this is not
> entirely implemented in Myrmidon just yet I don't think - Adam?).
Not entirely. It's near the top of my ever-growing todo list, though.
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>