ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: myrmidon questions
Date Wed, 16 Jan 2002 10:00:03 GMT

> From: Peter Donald []
> On Wed, 16 Jan 2002 15:09, Adam Murdoch wrote:
> > What needs to be done so we can start switching on the Ant 1 
> tasks?  Having
> > myrmidon build itself would be a very good thing.
> Well heres the things that need to be done in the order I was going to do 
> them in. However you should feel free to do them if you want ;)
> * refactor and clean (and understand) all the different types of 
> path parsing 
> code there is in ant. Most of it has been pushed into 
> ant.util.FileUtils and 
> util.PathTokenizer. All this needs to be done according to one consistent 
> scheme.

I've just been doing this exact thing - extracting the parsing code for use in my VFS proposal.
 And making it extensible, to deal with FS specific naming.  Currently, naming is pretty tightly
coupled with the VFS stuff at the API level, but that's easy enough fixed, if necessary.

Generally speaking, the VFS layer is the perfect place for file naming.  Certainly it would
give you somewhere to get consistent behaviour happening.

I'm very close to submitting an initial proposal to the list.  Let me get something written
up, and we can see if it fits in with what you're planning.

> * refactor Path/scanner objects to use new path code and to work under 
> myrmidon

It might be interesting to port these to the VFS API - particularly given a lot of what these
types do (parsing, searching, etc), would be better pushed behind the API.

> * Convert some tasks that use Path/scanner to see if it works (I 
> was thinking 
> of converting ant.taskdefs.file.*)

These would fit the VFS API ideally.

> * create a service similar to ExecManager/ExecMetaData for launching java 
> programs. This would determine whether it was necessary to fork 
> and take all 
> the required parameters (like ClassPath, classname or jarname, etc).
> * create an AbstractNativeTask (for tasks that do execs to work with)
> * create an AbstractJavaTask (for tasks that launch java progs to 
> work with)
> * refactor above tasks to work with the AbstractNativeTask
> * build some tasks that make use of java launching service (maybe 
> the java, 
> jdepend or junit tasks)
> after this the majority of the tasks could be cleaned up and reworked for 
> myrmidon as appropriate. So we convert any tasks that we will 
> need in short 
> term.
> After that we have hopefully come up with a semi-generic architecture for 
> facade tasks (like javac/jspc/etc) in which case we can try 
> converting the 
> javac task acorss to myrmidon. 
> Then we need to create a more reusable and extensible dependency 
> architecture 
> so that we can just pass in a list of input and mapping between 
> inputs and 
> outputs and then get those items that need to be updated (ie 
> compiled, copied 
> etc). To test this out I was going to use the zip/jar/ear tasks 
> as first line 
> and then move onto refactoring javac to use it.

I've been tinkering with this (including persisting the dependency info, and colouring too)
in the C/C++ task.  Needs generalising, but might be something useful to steal there.

> At that point it should be possible to self host and build a 
> majority of the 
> jakarta projects (about 80%). So we can create an XSLT sheet to transform 
> ant1 to myrmidon projects. Then we can hopefully (with or without 
> a bit of 
> arm twisting) get GUMP to run nightly builds of all the projects it works 
> with and gradually we can refine myrmidon and the transform sheet 
> until it is 
> fully operational and easily upgradable.

This is an excellent plan.

Can I make one suggestion: Move self-hosting up as early as possible.  A lot of this stuff
is refactoring, and can be done after self-hosting happens.  There's plenty of good reasons
for self-hosting as early as possible.

If myrmidon can build itself, then it can build an awful lot of other things too (like Ant
1 for example).  Which means people can start trying it out.  I certainly would for a lot
of my builds (well, only if you can talk the intellij people into writing a plug-in for it
:).  Having people use it can only do good things.

Self-hosting would also make a good test while the refactoring is happening.  As would GUMP


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message