On 18 Jul 2002, Stefan Bodewig wrote: > On Wed, 17 Jul 2002, <[EMAIL PROTECTED]> 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 ant.properties 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/ant.properties ). > > 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/anttasks.properties, anttypes.properties. 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 type. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
