Hmm, I'm confused. Are you saying there's supposed to already be a
copy of this in the jar? It isn't in CVS at META-INF (http://
cvs.apache.org/viewcvs.cgi/jakarta-taglibs-sandbox/rdc/src/META-INF/)
but maybe it's placed there by a build process?
Since META-INF is the location required by the 2.4 spec, it would be
nice if this is where it lived, and the build process copied it
wherever else folks wanted it for convenience.
Congrats on committer status Rahul!
Stu
On Jul 10, 2005, at 4:10 PM, Rahul P Akolkar wrote:
Stu Robertson <[EMAIL PROTECTED]> wrote on 07/10/2005 04:07:29 PM:
<snip/>
One question though. Why is the tld included outside of the taglib
jar? The 2.4 specification allows them to be in the jar, at META-
INF/
taglib.tld. I found that WAS 6 has trouble dealing with it elsewhere
if the tag classes and tagx files are in a jar. For my build I've
moved it to the jar itself, which solves the issue.
<snap/>
Put simply, that is how the taglibs build has it set up.
<reiterate>
There is a copy in taglibs-<taglib>.jar/META-INF/taglib.tld, which is
where the spec says it should reside if the taglib is deployed in an
archived form. There is another copy sitting outside the jar as
<taglib>-examples.war/WEB-INF/taglibs-<taglib>.tld, which is where the
spec says it should reside if the taglib is deployed in an unarchived
form.
</reiterate>
Removing the copy in WEB-INF/ might indeed be necessary for certain
containers if the taglib is deployed using an archived form. Apart
from
the fact that the TLD outside the jar makes for easier human/dev
consumption, does anyone have more insight into why there are two
TLDs in
the example wars?
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
