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 libaries. 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 loaded. > 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-) Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
