I don't think it is a burden to just call the annotation processor with
a different
factory. This is very simple and costs just another target in a builld
file, if you will.
I was able to do this quite easily when I wanted a different deliverable
from the
current processor.
A developer is capable of producing a processor that meets their
requirements if more than
what is already provided is needed.
In addition given that we have no way to qualify facelet support at the
moment
providing this facelet tld and other artifacts by default would mean
that our delivery mechanism would
have to prune out pieces that we cannot qualify.
-rick
Gregory Murphy wrote:
> Jason Lee wrote:
>
>> With this change, then, the standard JSF and JSP files (.tld,
>> faces-config.xml) will be generated by passing in one factory to the
>> processor, and the Facelets support file (webuijsf.taglib.xml) will be
>> generated in a second instantiation of the processor, either in the same
>> task or a different one? What if one were able to pass in a list of
>> factories to apt, and do everything in one pass? I'm not sure I see the
>> value in making the Facelets support generation a separate tasks. IMO,
>> the file should awalys be generated (thus generating should be made as
>> painless as possible). If the end user isn't using Facelets, there is
>> no run-time dependency on Facelets jars; there is only 21.4KB of disk
>> space "wasted."
>
>
> I was assuming that one would want to build "either - or": either a
> standard JSF library, or a library that works with Facelets. It sounds
> like you would prefer that there be just a single library, which can
> work in either a JSP environment or a Facelets environment. I take
> your point about efficiency.
>
> Ultimately, the decision about how best to integrate Woodstock with
> Facelets is one of policy as well engineering. There is an
> architecture group that meets to discuss such matters, I'll ask them
> for their input.
>
> // Gregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_woodstock.dev.java.net
> For additional commands, e-mail: dev-help_at_woodstock.dev.java.net
>