Taskdef for XMLC (xmlc.enhydra.org)...

[David Li <da...@digitalsesame.com>]

Hi,

  Here are the taskdef for XMLC (xmlc.enhydra.org).

Both of them go under:

  src/main/org/apache/tools/ant/taskdefs/optional/enhydra

Additional to build.xml

For target check_for_optional_packages:

    <available property="xmlc.present"
classname="org.enhydra.xml.xmlc.commands.xmlc.XMLC"/>

For target compile:

      <exclude
name="org/apache/tools/ant/taskdefs/optional/enhydra/*.java"
unless="xmlc.present" />

David Li
DigitalSesame

Re: Taskdef for XMLC (xmlc.enhydra.org)...

[Jon Stevens <jo...@latchkey.com>]

on 12/12/2000 1:05 AM, "David Li" <da...@digitalsesame.com> 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 org.apache.ant.tools.taskdef.optional 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
code.

> Contributing that to XMLC would have the task resulted under some
> namespace like org.enhydra.xmlc.tools.ant.taskdef.something. 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
project.

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.

Good.

> 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.

Yes.

> 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
> org.apache.tools.ant.taskdef.optional 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 org.apache.tools.ant.taskdef.optional). 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.

thanks,

-jon

-- 
Honk if you love peace and quiet.

Re: Taskdef for XMLC (xmlc.enhydra.org)...

[David Li <da...@digitalsesame.com>]

Jon Stevens wrote:
> 
> on 12/9/2000 1:47 AM, "David Li" <da...@digitalsesame.com> wrote:
> 
> > Here are the taskdef for XMLC (xmlc.enhydra.org).
> 
> Why don't you contribute that to the XMLC project?
> 
> -1 on including yet another optional taskdef that should really be included
> with the primary project instead.
> 
> -jon
> 

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 org.apache.ant.tools.taskdef.optional 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. 

  Contributing that to XMLC would have the task resulted under some
namespace like org.enhydra.xmlc.tools.ant.taskdef.something. 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. 

  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.

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.

Open up a central registery for optional taskdef and the name space
org.apache.tools.ant.taskdef.optional 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 org.apache.tools.ant.taskdef.optional). This
way, I quickly browse the package I got and determine whether it
supports Ant or not.


David Li
DigitalSesame

Re: Taskdef for XMLC (xmlc.enhydra.org)...

[James Duncan Davidson <du...@x180.net>]

On 12/9/00 7:33 PM, "Jon Stevens" <jo...@latchkey.com> wrote:

> +1 for not including optional tool tasks that don't serve any real purpose
> for Ant directly and would in reality be better bundled with the original
> product that it serves.
> 
> The rest of the tasks that don't fall into that category above should go
> into a jakarta-ant-optional CVS repo (like the Perforce task). In other
> words put things in their proper place.

I agree in principle with this. My hope with Ant when it went out is that
tasks would be available from a multitude of sources. I didn't expect
everyone to want them in the core distro. This is one of the reasons that
I've been arguing for extensive modularization in tasks (being able to have
them in their own jar) and am looking forward to talking with Jon and some
other folks about CJAN -- so that we can have an ecology of tasks that
doesn't require all tasks to be developed and maintained here.

Of course the best place for these sorts of tasks is with the tool itself.
For example, Netbeans and Ant. Any open source/open dev project should be
easy. It's the Visual Ages of the world that are a little more difficult to
get things bundled with.

-- 
James Duncan Davidson                                        duncan@x180.net
                                                                  !try; do()

Re: Taskdef for XMLC (xmlc.enhydra.org)...

[Jon Stevens <jo...@latchkey.com>]

on 12/9/2000 5:52 PM, "Simeon H.K. Fitch" <si...@fitch.net> wrote:

> Jon,
> 
> I think that if you are going to -1 a task for an external tool, then
> you need to back it up with a recommendation for some metric that we can
> objectively use for determining inclusion/exclusion in Ant. Based on
> your statement above, one could speculate that you would lobby to remove
> all optional tasks,

+1 for not including optional tool tasks that don't serve any real purpose
for Ant directly and would in reality be better bundled with the original
product that it serves.

The rest of the tasks that don't fall into that category above should go
into a jakarta-ant-optional CVS repo (like the Perforce task). In other
words put things in their proper place.

> and possibly even some things like support for
> jikes, only because they provide support for tools that are developed
> outside of Sun or Jakarta.

Nope. See above clause.

> I can't believe that this is really the case
> with you. Therefore, I think you owe it to the submitter--doubly so
> since he is new to the group--the courtesy of a more substantiated
> argument against accepting his submission. Personally, I would love to
> have an XMLC task in Ant as I use Enhydra on one of my projects, and
> enhydra has a non-trivial user base. I certainly don't see it as any
> less worthy than, say, the ejb tasks, or the perforce support.

I'm not saying that the task isn't useful, I'm saying that the task should
be included with Enhydra, not with Ant.

> Comments like yours above do very little to serve the longer term
> interests of the group, and only succeed in driving off potentially
> highly effective contributors.

I don't get it, what is wrong with including the task with Enhydra? That
doesn't drive anyone away, it tells them the right location for where their
code should really live. Maybe that person will become more of an Enhydra
contributor.

One issue that you have paid absolutely no attention to is the fact that the
people contributing these tasks are not necessarily going to be the same
people who are going to have to support the tasks.

Given that I have been around these ASF projects nearly the longest of
anyone here, I have seen literally hundreds of people come and go and have
also been stuck with supporting code that people have contributed and then
disappeared on. Ex: <http://java.apache.org/spfc/>

I also feel that we will be forced to field questions on the Ant user/dev
lists for support of these optional tasks. That isn't cool with me either
since it takes away Ant's resources.

I have a ton of Ant tasks that could be included with Ant. I don't include
them because I don't feel they are necessary for the core of Ant. I put my
tasks where they belong...with the projects that they work with.

thanks,

-jon

Re: Taskdef for XMLC (xmlc.enhydra.org)...

["Simeon H.K. Fitch" <si...@fitch.net>]

Jon Stevens wrote:
> 
> on 12/9/2000 1:47 AM, "David Li" <da...@digitalsesame.com> wrote:
> 
> > Here are the taskdef for XMLC (xmlc.enhydra.org).
> 
> Why don't you contribute that to the XMLC project?
> 
> -1 on including yet another optional taskdef that should really be included
> with the primary project instead.

Jon,

I think that if you are going to -1 a task for an external tool, then
you need to back it up with a recommendation for some metric that we can
objectively use for determining inclusion/exclusion in Ant. Based on
your statement above, one could speculate that you would lobby to remove
all optional tasks, and possibly even some things like support for
jikes, only because they provide support for tools that are developed
outside of Sun or Jakarta. I can't believe that this is really the case
with you. Therefore, I think you owe it to the submitter--doubly so
since he is new to the group--the courtesy of a more substantiated
argument against accepting his submission. Personally, I would love to
have an XMLC task in Ant as I use Enhydra on one of my projects, and
enhydra has a non-trivial user base. I certainly don't see it as any
less worthy than, say, the ejb tasks, or the perforce support.

Comments like yours above do very little to serve the longer term
interests of the group, and only succeed in driving off potentially
highly effective contributors.

sim

Re: Taskdef for XMLC (xmlc.enhydra.org)...

[Jon Stevens <jo...@latchkey.com>]

on 12/9/2000 1:47 AM, "David Li" <da...@digitalsesame.com> wrote:

> Here are the taskdef for XMLC (xmlc.enhydra.org).

Why don't you contribute that to the XMLC project?

-1 on including yet another optional taskdef that should really be included
with the primary project instead.

-jon

-- 
Honk if you love peace and quiet.