Return-Path: 
 <cxf-dev-return-3889-apmail-incubator-cxf-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-cxf-dev-archive@locus.apache.org
Received: (qmail 42910 invoked from network); 17 Aug 2007 11:51:07 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 17 Aug 2007 11:51:07 -0000
Received: (qmail 26678 invoked by uid 500); 17 Aug 2007 11:51:04 -0000
Delivered-To: apmail-incubator-cxf-dev-archive@incubator.apache.org
Received: (qmail 26663 invoked by uid 500); 17 Aug 2007 11:51:04 -0000
Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:cxf-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:cxf-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:cxf-dev@incubator.apache.org>
List-Id: <cxf-dev.incubator.apache.org>
Reply-To: cxf-dev@incubator.apache.org
Delivered-To: mailing list cxf-dev@incubator.apache.org
Received: (qmail 26654 invoked by uid 99); 17 Aug 2007 11:51:04 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Aug 2007 04:51:04 -0700
X-ASF-Spam-Status: No, hits=2.6 required=10.0
	tests=FM_FAKE_HELO_VERIZON,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of glen.mazza@verizon.net
 designates 206.46.252.48 as permitted sender)
Received: from [206.46.252.48] (HELO vms048pub.verizon.net) (206.46.252.48)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Aug 2007 11:51:23 +0000
Received: from [192.168.1.45] ([70.17.108.239])
 by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr
 3 2006)) with ESMTPA id <0JMX00B3S28995X1@vms048.mailsrvcs.net> for
 cxf-dev@incubator.apache.org; Fri, 17 Aug 2007 06:50:34 -0500 (CDT)
Date: Fri, 17 Aug 2007 07:50:33 -0400
From: Glen Mazza <glen.mazza@verizon.net>
Subject: Re: [Proposal] Sample Improvement
In-reply-to: <46C52FC2.7050005@iona.com>
To: cxf-dev@incubator.apache.org
Message-id: <1187351433.5781.26.camel@gmazza-desktop>
MIME-version: 1.0
X-Mailer: Evolution 2.10.1
Content-type: text/plain
Content-transfer-encoding: 7bit
References: <46B93B39.9060105@iona.com>	<200708081054.33845.dkulp@apache.org>
 <46BC053B.4010304@iona.com>	<46BC325B.4010004@iona.com>
 <1187193531.6058.101.camel@gmazza-desktop>	<46C3BA4A.1090204@iona.com>
 <1187291733.7604.81.camel@gmazza-desktop>	<46C52FC2.7050005@iona.com>
X-Virus-Checked: Checked by ClamAV on apache.org

Am Freitag, den 17.08.2007, 13:18 +0800 schrieb Jeff.Yu:

> Glen Mazza wrote:
> >>>
> >>> I think the listing of jar files needed should be explicitly listed via
> >>> <includes/> (even if there are 40 of them--remember this is only done
> >>> once in the common_build.xml), not *all* included but just having a few
> >>> left out via <excludes/>.  This also will provide us a crisp,
> >>> authoritative list of precisely what is needed to run CXF.  Using
> >>> excludes over time might result in unneeded jars getting into the WAR
> >>> files (i.e., we add a JAR file to the /lib directory but forget to
> >>> exclude it here.)
> >>>   
> >>>       
> >> Well, I don't think we need to list them, because in fact we include *all* the jars. Allowing me explain a little bit on this.
> >> Currently, we have two flavors CXF jar, one is all-in-one jar, called cxf-2.1-incubator.jar; the other is module-based jar, which is listed in the "${cxf.home}/modules",
> >> for the WARs, we used the module-based jars, so we need to exclude the all-in-one jar.
> >> The reason why I excluded those two servlet jars, because we deploy it into a servlet-container, there is no need to have these two servlet jars. 
> >>
> >>     
> >
> > Hmmm, in the lib directory there is a "needed jars" file, which
> > specifies a much smaller subset of all the jars in lib.
> >
> > The way I see it, is as follows, is you just need something like this:
> > <war>
> > ...
> > <lib dir="${lib.dir}">
> >    <include name="abc.jar"/>
> >    <include name="bcd.jar"/>
> >    ...
> > </lib>
> > ...
> > </war>
> >
> > For the time being, best to just include the jars needed by *any* of the
> > samples.  Later, perhaps, we can think of a cleaner design where we can
> > bring in JARs required of *all* samples, plus a few extra
> > sample-dependent jars, depending on the sample.
> >
> >
> >   
> 
> The reason that why you think the "WHICH_JARS" in the lib lists much smaller jars, is it uses the all-in-one jar as I said before. Well, I can update it to use the the all-in-one
> jar instead of module-based jars for the simplicity, but I still think list 40 more jars is not a good idea. If we want to make users clear which jars will be needed for their usage, 
> I think that is why the "WHICH_JARS" existed.
> 

With the exception of these jars in the cxf/lib directory:
(1) all-in-one jar
(2) the servlet-api jar
(3) the geronimo jar

Is it *really* the case that every other JAR in this directory needs to
go into the WAR's WEB-INF/lib directory for the servlet to operate?
(For example, do we really need the jetty jars in the WAR file?  The
velocity JARs?  The WHICH_JARS file indicates that we do not.)

The fact that there are already exceptions above (1-3) suggests to me
that the cxf/lib directory serves purposes other than as a pure
repository of JAR files necessary for a WAR to operate.  That's why an
explicit listing would have been helpful--a listing also allows us to do
a further analysis of which JARs we can take out, and it also provides
safety in case someone places a jboss or a glassfish jar in this lib
directory (it would not copy over, because it was not added to this
<include/> list.)

Perhaps we can look at this issue again later.

Thanks,
Glen