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

> Putting the Fop task directly in Ant would be great.  I would really
> like to see that happen.  I suppose we could get it in Ant 1.6 if we
> submit it soon.  Does anyone know what the criteria is for inclusion
> as a "Core" or "Optional" task within Ant?  What work would be
> required on our part?

Actually, it is not too likely to get accepted at all (I'm an Ant
committer and PMC member, but I'm just speaking for myself here - some
of it still is speculation).

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

Currently we are adding the infrastructure for something we call Ant
libraries.  Self contained jars that you need to put into ANT_HOME/lib
(to be defined) and all tasks/data-types contained within will get
discovered by Ant on startup.  This will make deploying third party
tasks even easier than it is now.  First parts of this will be
available in 1.6.

It's pretty likely that we'll even break up our current set of tasks
in the future and ship Ant with only a minimal amount of tasks - the
rest will go into separately maintained and separately released Ant

Some more comments.

> 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, it must not rely on any unreleased code.
So if Ant 1.6 was released tomorrow, any FOP task in Ant would have to
work with 0.20.5rc3a - any unreleased dependency like CVS HEAD is
completely out of question.

> I don't know how it is done for other Ant tasks with external
> dependencies, but I suppose the Ant task would check to see if
> org.apache.fops.apps.Driver is on the classpath before preceding.

Currently Ant simply tries to load all task classes (in 1.5.x at
startup in 1.6 this will get delayed until you try to use the task).

If there a dependency on org.apache.fops.apps.Driver in the task and
the class is not available, Ant will catch the NoClassdefFoundError
and simply proceed, making the task unavailable.  If you then try to
run the task, your build will fail - at the point where you try to run
the task.

<taskdef> is different than the tasks that ship with Ant in that it
will cause the build to fail immediately when the class cannot be

> It also means that the Driver interface (or some other interface?) 
> would have to be frozen.

Which seems a very good argument to keep the task with FOP, IMHO.

You'd adapt the task to the interface as necessary and people will
always have a working combination of FOP and the task.  Otherwise
you'd end up with documentation that says "this task requires FOP
0.20.4 or later, but won't work with 1.0".  The "but won't work with
1.0" part is rather difficult to add after a release of the task.  8-)


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

Reply via email to