jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <Craig.McClana...@eng.sun.com>
Subject Re: cvs commit: jakarta-taglibs/xsl-tags/examples/lib -Newdirectory
Date Wed, 12 Apr 2000 00:27:56 GMT
rubys@us.ibm.com wrote:

> Anil wrote:
> >What is the harm in dealing with this with a set of instructions or a list
> >of external dependencies? People should read that, download the
> appropriate
> >jars and then proceed to either build or run it.
> >
> >Clearly if we have db tags, people are going to have to install a
> database.
> >We can't really check that in, can we? :-)
>
> +1
>
> Rereading Craig's post, I'm guessing that he thought I was objecting to the
> tag libs using xerces instead of another xml parser.  (I was a bit terse
> ;-)) I have no issue there.  I wouldn't even have an issue if the taglibs
> were to depend on a closed source product with a proprietary API - I might
> not choose to use it, but I wouldn't otherwise object.
>
> What I object to is the checking in of jar files.  Does this issue need to
> be rehashed?
>

It was only discussed on PMC.  Therefore, it would be appropriate to record the
rationale here for posterity in the mailing list archives.

An issue for me is the "out of the box" experience of people who download
Jakarta stuff, and then try to build it.  The more steps we put in the way, the
less easy this is -- and the more chances for people to make mistakes.  A
blanket prohibition on checking in JAR files for any reason counts as "one more
step" for each dependency.  It's important that we agree this cost is worth it.

At least one of Sam's concerns (feel free to chime in with others) was
arbitrary dependence on particular versions of particular libraries, and what
happens when you try to combine these things in one web-app.  His preference is
that you just document *all* external dependencies, and require you to download
and install those pieces separately.

A case in point is "servlet.jar", which you will need to compile any custom tag
libraries.  Currently, the build scripts require you to declare an environment
variable (SERVLET_JAR) that points at the servlet.jar file you got with your
servlet container, or otherwise modify them to set the servlet.jar property.

As you can imagine, I'm not as adamant as Sam is about checking in jar files,
but I'm willing to listen.  What I don't want to do is make absolutist
prohibitions on what can be checked in without documenting the reasoning so
that others can understand.  Then, we can add the rationale and reasoning to
the project documentation and point at it when the inevitable questions come up
later.

>
> - Sam Ruby

Craig



Mime
View raw message