commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: Commons-logging 1.1 POM: why isn't servlet-api scope=provided ?
Date Wed, 24 Jan 2007 19:24:59 GMT
On Tue, 2007-01-23 at 16:54 -0500, Yoav Shapira wrote:
> Hola,
> 
> On 1/23/07, Craig McClanahan <craigmcc@apache.org> wrote:
> > That's a good step, but it's not sufficient for this case and does
> > > not provide the same functionality as add scope="provided."
> >
> >
> > Why?  The part of C-L that depends on the servlet API is indeed optional,
> 
> That's my bad wording.  Declaring the dependency as optional would
> actually be sufficient for my use-case.  However, as the Maven doc
> notes (http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html),
> optional dependencies are a stop-gap measure.  I think the
> scope="provided" is a bit cleaner and has clearer semantics to users.

I would agree with Craig's assessment of this - optional seems the
correct scope to me.

Well, actually, the dependency on servlet-api should probably be marked
both optional *and* provided, in that it is not needed in order to use
many JCL features, but if you do want to use the JCL "cleanup on webapp
unload" then the supporting jar is expected to be provided by the
surrounding environment. However as it's not possible to use both,
optional seems to more correctly describe the usage to me.

The linked page describes optional dependencies as a "stop-gap" compared
to splitting the project into submodules, not compared to using
"provided" scope. However splitting the servlet-related functionality of
JCL into a separate module/jar would just be silly - it's only one
class, and JCL is full of other optional dependencies anyway.

> 
> Either way, it looks like this is being addressed or will be shortly:
> thanks for the quick responses.  Now I just have to wait for the next
> JCL release ;)  Actually, if it's as simple as just packaging and
> updating the web site, I guess I could do it myself.

The only outstanding issue I know of is deciding how to do the actual
release build, because we want to support java 1.2, but JCL also
contains java.util.logging stuff that only builds with java1.4. In the
past, spearate compilers have been used to build various bits then the
results stitched together. I would prefer to build the lot with java 1.6
using -target 1.2 and then run the unit tests against this jar using
java1.2 to verify the results are usable but (a) need to figure out how
to do that, and (b) need to get agreement that it is an acceptable
approach.

Cheers,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message