ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Splitting up optional.jar
Date Thu, 18 Jul 2002 14:52:20 GMT
On 18 Jul 2002, Stefan Bodewig wrote:

> On Wed, 17 Jul 2002, <> wrote:
> > Since <junit> won't work without junit.jar, I think it would be much
> > better if the task would be included in junit.jar in the first place
> > ( and maintained by junit people ).
> Some historic trivia (you may already have been unsubscribed when
> <junit> has been added).  When Thomas Hass and I wrote <junit>, JUnit
> hasn't been an open source project, we had no choice of where to put
> the stuff.  If it had been, we would have lobbied for it, especially
> since they've been using Ant to build JUnit since Ant's very early
> days.

I was never 'unsubscribed' - just had too much work, little
time and bigger itches ( and flame wars ).
My point is that if we can do the right thing, we should - i.e
try to move the tasks that are clearly just a wrapper for some
external package back into that package.

With a small enahncement to the <taskdef> or with <antlib> the
tasks can be loaded automatically ( so no need to explicitely
taskdef junit, same behavior as now ).

> > So I think all dependency, version, etc should go to MANIFEST.
> Could live with that, but would prefer to have all information in a
> single place.

We can store all the info in the XML, and generate the MANIFEST 
and properties out of it. 

But I want to be sure the standard is used so we can interoperate
with other tools, and that 'simple things are simple' - for
most people MANIFEST and should be simple enough.
> > The task=classname should go in a properties file ( and I think
> > we should settle on a default location and name - like
> >  META-INF/ ).
> That doesn't work if you want to ship data-types as well, you'd end up
> with two property files.  This is why I prefer a single XML file that
> can be used to define tasks and types at the same time.

2 properties file is not bad - META-INF/,

If we stop making the distinction between task and types ( i.e allow 
tasks at top level ) there is no need for 2 properties files, 
if something extends Task or has execute() it is a task, if not 


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

View raw message