Re: move Ant task to Ant project ( was Contribution - anttask)
On Sat, 12 Jul 2003, Glen Mazza <[EMAIL PROTECTED]> wrote: > Perfectly understandable, as you would not want poorly maintained > optional tasks ending up degrading Ant's reputation as a build tool. It's not only a question of reputation. One of Ant's biggest burdens is backwards compatibility, and the more tasks we have, the more difficult it becomes. When we introduce a new task in a release we must be pretty sure that its public interface is a good one - which is pretty hard to do if you don't know the problem domain well enough. And certainly, if less bugs on custom tasks get reported against Ant, we stand a bigger chance to fix those reported against Ant's internals. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: move Ant task to Ant project ( was Contribution - anttask)
Thanks for the explanation Stefan. --- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > 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. I see. Perfectly understandable, as you would not want poorly maintained optional tasks ending up degrading Ant's reputation as a build tool. I was not thinking about this when I made the suggestion. > Not having followed the discussion leading up to > this, why would you > want to ship it with Ant rather than FOP? > My (limited world-view) thinking prior to your explanation was that when open-source projects hit The Big Time (tm), they get their own task directly into Ant. So I saw that as a goal for us in FOP 1.0. But with Sean pointing out the FOP version-specific nature of the FOP task, as well as your thanks-but-no-thanks-Ant-is-already-being-bogged-down-with-buggy-optional-tasks explanation have enlightened me on this issue: In FOP, and only in FOP, will the task be maintained. Thanks, Glen __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: move Ant task to Ant project ( was Contribution - anttask)
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. 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]
Re: move Ant task to Ant project ( was Contribution - anttask)
>BTW, it may be good to kill two birds with one stone >and have this task added directly to Apache Ant, as a >new Optional Task, using what we currently >have in our own codebase with Sean's improvements, >and/or modeled after the Xalan task already in >Ant. 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? However, I'd like to see this patch get incorporated into the "next" FOP release as soon as possible. I put quotes around "next" because I don't know which of the following options makes sense to the committers: 1) Put it in 0.20.5 I realize that 0.20.5 is at RC3 right now and that features aren't supposed to be added, but the impact of this change is relatively low. Especially, with the "force" option defaulting to true. 2) Put it in 0.20.5 + 1 (0.20.6?) The website says that 0.20.5 is the last "planned" release in the 0.20.x series. I don't know if the enhancement to the Ant task alone is worth doing a 0.20.6 release or what is the likelihood of a 0.20.6 release for other reasons. 3) Don't put it in the 0.20.x series. Please, please, don't pick this option. I am willing to investigate and (to the best of my ability) fix any reported bugs in the Ant task if that will help the committers decide to put it in a "sooner" release. > >That would have the added benefit of allowing us to >deprecate the Ant Task functionality currently in our >own code. I assume that if we targeted Ant 1.6, we would use the 0.20.x code base. 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. It also means that the Driver interface (or some other interface?) would have to be frozen. -- Sean -- --- M. Sean Gilligan: mailto:[EMAIL PROTECTED] Catalla Systems, Inc. : 831-439-9568 x11 --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
