jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [standard] Packaging suggestions
Date Mon, 01 Apr 2002 16:44:19 GMT


On Sun, 31 Mar 2002, Shawn Bayern wrote:

> Date: Sun, 31 Mar 2002 00:23:40 -0500 (EST)
> From: Shawn Bayern <bayern@essentially.net>
> Reply-To: Tag Libraries Developers List <taglibs-dev@jakarta.apache.org>
> To: Tag Libraries Developers List <taglibs-dev@jakarta.apache.org>
> Subject: Re: [standard] Packaging suggestions
>
> Hans,
>
> This all sounds good to me.  I'll try to incorporate all of these
> suggestions into Beta 2.  The CVS archive has a README.txt file, but we
> don't expose it in the binary distribution.
>
> Concerning the duplication between jstl.jar and standard.jar, the hope was
> that users wanting all of JSTL could simply install a single JAR
> (standard.jar), while developers of other implementations might want just
> the public, spec'd APIs (jstl.jar).  Perhaps we can include the latter in
> a subdirectory off the root, though; it's not what most users are
> interested in anyway.
>
> Thoughts?
>

One thing to keep in mind is that, in the future, the API classes part
(jstl.jar) will often be provided by the container but you can still use
different implementations.  I would suggest removing the API classes from
standard.jar and requiring current users to include both, and just remove
jstl.jar once the containers provide support (and a default
implementation).

If you look at the way the Java XML Pack and Java Web Services Developer
Pack are packaged, you'll see that we have done this with all of the XML
based APIs (jaxm-api.jar versus jaxm-ri.jar), for the same reason.

> Shawn

Craig


>
> On Fri, 29 Mar 2002, Hans Bergsten wrote:
>
> > * A README.txt file wold be nice, with the typical info about
> >    what it is, but more importantly, how to install it.
> > * At the top level in the standard binary distribution, there are
> >    only two JAR files: jstl.jar and standard.jar, which also includes
> >    all the same files as jstl.jar. I believe it would be much
> >    easier to install this if the top level (or better, a lib
> >    subdirectory) contained *all* JAR files needed to use the tag
> >    library (and the duplication of files in standard.jar and jstl.jar
> >    seems uncessary and possibly confusing). Now I have to unpack the
> >    standard-examples.war file to get all JAR files out of the
> >    WEB-INF/lib directory. I know this can be controversial, but you
> >    already include all JAR files, just not in a location where they
> >    are easy to find.
> > * Both at the top level and in the examples application, the
> >    TLD files are exposed as external files. I believe this may
> >    be a source of confusion. JSTL depends on JSP 1.2 and should
> >    therefore use the new TLD auto-discovery feature, which finds
> >    TLDs even in JAR files. I know that the overall Taglibs project
> >    guidelines say that the TLDs should be exposed like this, but
> >    the guidelines were written before JSP 1.2 was released and
> >    IMHO it's time to change them.
> > * The default URIs for all libraries still contain "ea" so they
> >    don't match the URIs in the Public Review spec draft. I believe
> >    it's time to drop the "ea" at this stage (it's Beta, not EA).
> >
> > With these changes, the README.txt file could say "to install JSTL,
> > just copy the JAR files in the lib directory to the WEB-INF/lib
> > directory for your web application. To use it in your pages, just
> > include a taglib directive with the appropriate default URI as
> > the uri attribute value." That seems a lot easier than today to me ;-)
>
>
> --
> To unsubscribe, e-mail:   <mailto:taglibs-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:taglibs-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:taglibs-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:taglibs-dev-help@jakarta.apache.org>


Mime
View raw message