Contribution - anttask rendering only when source is newer than target

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

Hello,

I'm new to this list, but have been using Fop to render a DocBook documentation suite for the last year.  I finally got around to using the Ant Task and created a patch to only render the output file(s) if they are older than the input .fo file(s).  I also added a "force" attribute modeled after the xslt/style Ant Task that allows this behavior to be disabled.

To be conservative, "force" is defaulted to "true" on the 0_20_2-maintain branch (for backward compatibility) and is defaulted to "false" on the HEAD.  ( I'd rather the default be "false" in both cases, but decided the change is more likely to be put in if it provides greater backward compatibility.)

I've made the changes to org.apache.fop.tools.anttasks.Fop on both the HEAD and 0_20_2-maintain branches.  I've also updated the anttask.xml documentation page to document the "force" attribute.  I have only tested the changes with the 0_20_2-maintain but the HEAD branch anttask is pretty much the same code as on 0_20_2-maintain.

Is there any interest in accepting this change?  Should I submit the patches to this mailing list?  The guidelines say that the patch should be submitted as a "diff", but should it be in the body of the message or as a text attachment(s)?

Regards,

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

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 ( was Contribution - anttask)

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

On Sat, 12 Jul 2003, Glen Mazza <gr...@yahoo.com> 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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: move Ant task to Ant project ( was Contribution - anttask)

[Glen Mazza <gr...@yahoo.com>]

Thanks for the explanation Stefan.

--- Stefan Bodewig <bo...@apache.org> wrote:
> On Thu, 10 Jul 2003, M. Sean Gilligan
> <se...@msgilligan.com> 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 <fop> 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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: move Ant task to Ant project ( was Contribution - anttask)

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

On Thu, 10 Jul 2003, M. Sean Gilligan <se...@msgilligan.com> 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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: move Ant task to Ant project ( was Contribution - anttask)

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

>BTW, it may be good to kill two birds with one stone
>and have this task added directly to Apache Ant, as a
>new <xslfo> Optional Task, using what we currently
>have in our own codebase with Sean's improvements,
>and/or modeled after the Xalan <xslt> 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:Sean_Gilligan@catalla.com
Catalla Systems, Inc.               : 831-439-9568 x11
---------------------------------------------------------------------------

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

Re: Contribution - anttask rendering only when source is newer than target

[Glen Mazza <gr...@yahoo.com>]

BTW, it may be good to kill two birds with one stone
and have this task added directly to Apache Ant, as a
new <xslfo> Optional Task, using what we currently
have in our own codebase with Sean's improvements,
and/or modeled after the Xalan <xslt> task already in
Ant.  

That would have the added benefit of allowing us to
deprecate the Ant Task functionality currently in our
own code.

Glen


--- "M. Sean Gilligan" <se...@msgilligan.com>
wrote:
> >M. Sean Gilligan wrote:
> >>Is there any interest in accepting this change?
> >
> >Yes.
> 
> Great!
> 
> >


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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

Re: Contribution - anttask rendering only when source is newer than target

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

>M. Sean Gilligan wrote:
>>Is there any interest in accepting this change?
>
>Yes.

Great!

>
>Commonly a patch should be submitted as an enhancment
>request in bugzilla,

Bug #21380 has the patch for the  0_20_2-maintain branch
Bug #21381 has the patch for the HEAD branch

I hope I did everything correctly.  Let me know if you need any more information.

Also, I made "force=true" the default option for 0_20_2-maintain, but if the committers feel that it is OK to "force=false" the default, I give an (uncounted) +1 to that approach.

(If someone is using external entities or something like that they'll have to add "force=true" to the ant task to get the behavior they want, but it is probably a fairly rare use-case.  Typically, Ant tasks, such as javac and xslt/style, use mod date dependencies by default.)

Please let me know if there is anything else I can do to help.

Regards,

Sean


-- 
---------------------------------------------------------------------------
M. Sean Gilligan                    : mailto:Sean_Gilligan@catalla.com
Catalla Systems, Inc.               : 831-439-9568 x11
---------------------------------------------------------------------------

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

Re: Contribution - anttask rendering only when source is newer than target

["J.Pietschmann" <j3...@yahoo.de>]

M. Sean Gilligan wrote:
> Is there any interest in accepting this change?

Yes.

>  Should I submit the patches
> to this mailing list?

Commonly a patch should be submitted as an enhancment
request in bugzilla, with the subject line starting
with [PATCH] so it stands a bit out.

>  The guidelines say that the patch should be submitted
> as a "diff", but should it be in the body of the message or as a text
> attachment(s)?

Add as attachment to the bugzilla entry.

J.Pietschmann



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