ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Oxspring" <roxspr...@yahoo.com>
Subject Re: Did somebody say Shut up and Write? :)
Date Thu, 28 Dec 2000 22:31:07 GMT
Something like the following then?

<target name="buildTasks">
    <javac src="com/myco/project/tasks/MyTask.java"/>
    <load name="mytask" classname="com.myco.project.tasks.MyTask"/>
</target>
<target name="buildName" depends="bulidTasks">
    <mytask foo="bar"/>
    <javac src="com/myco/project/**/*.java">
</target>

The syntax is stolen from antfarm which looks like it could handle this
situation well, although i've not had time to try it.  I think this sort of
functionality would be great - especially for task developers so that the
compile & test can be easily combined into a single run of a single ant
file.

Also after having a look around the proposals, my two favourites are the JDD
(Anteater?) one and Antfarm.  The startup code for AntFarm is great, and the
mechanisms for loading task libraries (xml wise) are also good.  However I
think that there is a lot that can be taken from James' "set building"
ideas, and conceptually at least the idea of a workspace
containing/referencing lots of projects/modules is great.  The frANTic
proposal seems a bit too radical for the moment; I'm not entirely convinced
of how much its needed, and so maybe it could be left for version 3.0.  As
far as the myrmidon thing is concerned, I won't comment until I get a
successful compile ;-).

Finally a thought for the future - how about an "expected version" attribute
in the top level tag in the xml files.  This could then be used to make sure
the defaults are set as they were in the expected version, throw an error if
an old version of ant is being used, and even to decide on a particular XSL
transform to cope with the major version changes.

Keep up the good work,

Rob

----- Original Message -----
From: "Peter Vogel" <pvogel@arsin.com>
To: <ant-dev@jakarta.apache.org>
Sent: Thursday, December 28, 2000 6:39 PM
Subject: RE: Did somebody say Shut up and Write? :)


> I think you have the mistaken impression that I was talking about
> core ant, I wasn't.  I was referring to the ant customizations that
> are done locally (i.e. task extensions, etc.) and that might be
> specific to a particular development project.
>
> I agree, one way to approach the problem is to say that the CM group
> (assuming there is one, and that is frequently not the case) maintains
> the official toolset and any extension required to successfully build
> the product must be officially supported by the CM group.  It does
> imply that CM must have a clean mechanism for propagating new versions of
> ant to all development groups (otherwise you have a real mess).
>
> I was thinking more in terms of what I believe would be a more efficient
> use model, namely, extensions to ant that are required to build the
product
> are a part of the product tree, and ant builds them first and integrates
> those extensions before beginning the actual product build.  By having the
> extensions to ant as a part of the tree, we also ensure that the correct
> version of ant is used for any build, since the ant changes are tagged
along
> with the rest of the product build.  This is what I do all the time with
> perl-based builds (or perl-wrapped builds) but the "update" issue doesn't
> exist with perl because perl "compiles" extension modules on the fly, so
as
> long as the .pm is in the tree, perl is happy with it.
>
> -Peter
>
>
> > -----Original Message-----
> > From: Scotte Zinn [mailto:szinn@patronix.com]
> > Sent: Thursday, December 28, 2000 6:56 AM
> > To: ant-dev@jakarta.apache.org
> > Subject: RE: Did somebody say Shut up and Write? :)
> >
> >
> > IMHO, this kind of feature seems to have nothing to do with building
> > product, and shouldn't be part of ant itself.  The CM group should
> > manage/define the 'official' toolset.  Others, (i.e., the
> > developers) may
> > have their own local mods, which is fine, as long as they
> > either aren't
> > required for the 'official' build, or are accepted by the CM
> > group.  Having
> > a tool that modifies itself may hinder the mandate of the CM
> > group which is
> > to build any past version of the product at any time exactly.
> >
> > If a -selfupdate kind of feature is requested, maybe it
> > should be a task
> > unto itself and a Build.xml (or whatever it is going to be
> > called) is part
> > of the distribution that will provide the updated information.
> >
> > This suggests another kind of extensibility: namely, the
> > ability to write a
> > java class that is used by a custom command-line switch.
> >
> > -- Scotte
> >
> > > -----Original Message-----
> > > From: James Duncan Davidson [mailto:duncan@x180.net]
> > > Sent: Thursday, December 28, 2000 2:28 AM
> > > To: ant-dev@jakarta.apache.org
> > > Subject: Re: Did somebody say Shut up and Write? :)
> > >
> > >
> > > On 12/27/00 11:11 PM, "Diane Holt" <holtdl@yahoo.com> wrote:
> > >
> > > > Actually, I would expect whatever "group" (even if it's
> > > only an individual
> > > > just working privately) "owns" Ant to -not- necessarily
> > > have an up-to-date
> > > > version of Ant. I would expect them to only update the version (or
> > > > possibly only certain source-files) for specific reasons
> > and only at
> > > > acceptable points in time. For example, I currently have a
> > > mixture of
> > > > 1.2alpha, some straight 1.2, some post-1.2, plus some
> > > in-house mods. When
> > > > 1.3 becomes available, I'll review what's changed, see if
> > > there's anything
> > > > that I want/need, and if there is, determine when would be
> > > a good time to
> > > > (either fully or partially) update.
> > >
> > > One way of handling this is to have an ant.conf file that is
> > > part of the
> > > distro. One of the properties of this file could be something like
> > > 'udpateserver=http://jakarta.apache.org/ant/latestversion".
> > > This location
> > > could have a pointer to where the latest version was along
> > > with version
> > > number, etc.
> > >
> > > Then, in an installation like yours, you could change that
> > -- thereby
> > > changing the action of `ant -selfupdate` to only grab your version.
> > >
> > > .duncan
> > >
> > > --
> > > James Duncan Davidson
> > > duncan@x180.net
> > >
> > >     !try; do()
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: ant-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: ant-dev-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


Mime
View raw message