ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Stevens <>
Subject Re: Taskdef for XMLC (
Date Tue, 12 Dec 2000 18:03:32 GMT
on 12/12/2000 1:05 AM, "David Li" <> wrote:

> Jon,
> I thought about that. I send it to Ant instead of XMLC project is that
> I'd like to get a centreal namespace for all the taskdef I am using.
> Having it in is a gooc namespace
> prefix for it. There is no naming standard for a Ant taskdef and it's
> hard to find out whether a tool I am using support Ant or not.

It is very easy to see if your tool is a taskdef or not. You have the source

> Contributing that to XMLC would have the task resulted under some
> namespace like It's hard
> to find. We have a discussion thread on the enhydra mailing list and we
> found out there are 3 or 4 different XMLC's taskdef. I think this is a
> awful waste in an open source project having people keep reinventing the
> weel. 

That is because the XMLC project is obviously run incorrectly then. Bad
project management and documentation is not the responsibility of Ant's

If it were up to me, I would have put up a nice big web page that defined
what the task was and how to use it. I would have also added it into the
build process for XMLC.

If those things aren't done...well, it is an OSS project and you have the
power to help modify or fork it.

> From other posts to this thread, I can see how you may not want that
> to be included in the official Ant's distribution. Yes, I may donate the
> codes and lose my interest to maintain it 3 months from now. And this is
> going to cause headaches for the maintainer of Ant. I fully respect
> that.


> So, let's define the problem we are facing here.
> 1. There is no convinient way to look up whether a tool is supported by
> Ant or not. For example, I have to posted to XMLC's mailing list a
> couple times before someone tstart talking about the taskdef they have
> written for Xmlc. There is no central repository for such information or
> a well known namespace to look for it in a package I got.

That has absolutely no meaning here. Like I said above, bad project
management on behalf of the XMLC people is not our problem.

> 2. Having all the optional codes in the official Ant will definitely
> cause a lot of headache.


> So, I think some guideline to support optional taskdef developers can
> solve the problem.

Read my email titled "[PROPOSAL] Optional Tasks".

> Open up a central registery for optional taskdef and the name space
> for those taskdefs. I see this as
> a simple page on the Ant's site with records on the optional taskdefs
> written and where they namespace are. (preferablely all optional
> taskdefs can fall under the This
> way, I quickly browse the package I got and determine whether it
> supports Ant or not.

That is why I proposed exactly the same thing. It is so nice to see others
coming to the same conclusions.



Honk if you love peace and quiet.

View raw message