Re: move Ant task to Ant project

["M. Sean Gilligan" <se...@msgilligan.com>]

>Over the past months (no, years) we've spent a lot of time maintaining
>optional tasks and fixing bugs in them, more time than we spent on
>improving Ant itself.  As a consequence you'll find a big reluctance
>with Ant developers to accept any new tasks at all.

I see the problem.

>  In particular if
>the new tasks relies on a third-party tool/library that is an open
>source project itself.  We'd probably send you back to FOP.
>
>Not having followed the discussion leading up to this, why would you
>want to ship it with Ant rather than FOP?

The advantages to shipping with Ant are that it would become more of a "standard" and get more exposure and usage.  It is also nice to have all the task documentation accessible through the single (frames-based) web page.

I know from experience that a user is more likely to start using an Ant task that is built in to Ant, even if it requires external Jars.  I've been using <xslt> for months, but only recently began using the Fop ant task.

>
>Currently we are adding the infrastructure for something we call Ant
>libraries.  ... This will make deploying third party
>tasks even easier than it is now.

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

Also, it might make sense to have a recommended mechanism for having multiple implementations implement the same Ant task.  I'm sure you  must have this mechanisms for <javac> and it looks like <xslt> uses Trax.  If there were a standardized <xslfo> task it is conceivable that people might want to use a processor other than Fop.

Is there a link that I can look at to see the work in progress in this area?
>
>> I assume that if we targeted Ant 1.6, we would use the 0.20.x code
>> base.
>
>If it wants to be in Ant 1.6,

I'm sorry my message really had two *subjects* and I only put one in the subject line.  I was trying to say that we should put the changes into the Fop project and begin the process of submitting to Ant.  The three "options" were for putting the patch into a Fop release.  (I suspected that the Ant committers would feel more comfortable with including a task that had been "shipping" for some time.)

-- Sean

-- 

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: move Ant task to Ant project

[Stefan Bodewig <bo...@apache.org>]

On Fri, 11 Jul 2003, M. Sean Gilligan <se...@msgilligan.com> 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-)

Stefan

Footnotes: 
[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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org