On Fri, 11 Jul 2003, M. Sean Gilligan <[EMAIL PROTECTED]> wrote:

> The advantages to shipping with Ant are that it would become more of
> a "standard" and get more exposure and usage.

Sure.  In the early days Ant used to absorb tasks from each and every
problem domain to get more exposure itself.  I fully understand that.

On the other hand, we are already receiving complaints that there are
too many tasks in Ant, so that newbies wouldn't have a chance to learn
them all (as if they had to, but that's a different question).

> One suggestion for Ant libraries - it would be nice to have a task
> "name registry" so that the task names can be standardized.

That's going to be hard.

It's more likely that you can attach an XML namespace to each ant
library and that name clashes get resolved by using namespaces.
Consider container specific implementations of jspc, it's probably
better to have <websphere:jspc> and <tomcat:jspc> than forcing each of
them to register with some registry and choose some unique name.

> Also, it might make sense to have a recommended mechanism for having
> multiple implementations implement the same Ant task.

See some support classes in Ant's util.facade package.  The mechanism
could probably be improved, but at least it is already in use for
<javac> and <rmic> (and <jspc> IIRC).

> and it looks like <xslt> uses Trax.

Historically Ant's <xslt> task predates TraX - or at least Xalan-J-2.
Therefore Ant supports some pluggable mechanism in <xslt> that needs
to be retained for backwards compatibilty (there is a custom
implementation for Exolab's AdaptX processor that I'm aware of).

> If there were a standardized <xslfo> task it is conceivable that
> people might want to use a processor other than Fop.

The most difficult part is probably going to be to define a "common"
interface for the different processors.

> Is there a link that I can look at to see the work in progress in
> this area?

For the built-in support for "facade" tasks, see the util/facade
package.  This has been more or less untouched since Ant 1.5 IIRC.
For a task using it, see <javac>.

The antlib stuff is building up momentum currently.  The series of
steps leading to is may be best followed by this bugzilla report[1] and
the archives of ant-dev, I'd recomment MARC[2] for this, look for
"antlib" as subject.

> I'm sorry my message really had two *subjects* and I only put one in
> the subject line.

Oh, two is a rather small number for threads that I'm involved in 8-)

> (I suspected that the Ant committers would feel more comfortable
> with including a task that had been "shipping" for some time.)

I'd suspect the reaction would be "stay where you are, you already
have a home".  8-)


[1]  http://issues.apache.org/bugzilla/show_bug.cgi?id=19897
[2]  http://marc.theaimsgroup.com/?l=ant-dev&r=1&w=2

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to