From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1F31q7-0007C1-BM for garchives@archives.gentoo.org; Sun, 29 Jan 2006 01:58:51 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k0T1wMbQ019223; Sun, 29 Jan 2006 01:58:22 GMT Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.61]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k0T1wLDH019796 for ; Sun, 29 Jan 2006 01:58:21 GMT Received: from 146-115-26-214.c3-0.abr-ubr1.sbo-abr.ma.cable.rcn.com (HELO [192.168.1.104]) ([146.115.26.214]) by smtp01.mrf.mail.rcn.net with ESMTP; 28 Jan 2006 20:58:21 -0500 X-IronPort-AV: i="4.01,231,1136178000"; d="scan'208"; a="159627263:sNHT24166460" Message-ID: <43DC1E35.6060005@gentoo.org> Date: Sat, 28 Jan 2006 20:45:25 -0500 From: Joshua Nichols User-Agent: Mail/News 1.5 (X11/20060118) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-java@gentoo.org MIME-Version: 1.0 CC: gentoo-java@lists.gentoo.org Subject: Re: Fwd: [gentoo-java] webapp-config & Java References: <20060125205026.GF4249@toucan.gentoo.org> <306bf010601260130w7c2740f4o@mail.gmail.com> <20060126205422.GI4249@toucan.gentoo.org> <43D94573.6070500@gentoo.org> <1138324764.29596.28.camel@procyon.operationaldynamics.com> <306bf010601270354i6be394cct@mail.gmail.com> <306bf010601270355o901310ei@mail.gmail.com> In-Reply-To: <306bf010601270355o901310ei@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 7b2ba78b-ccaf-48e6-8fda-94347fe03a18 X-Archives-Hash: c380a6cc07c97330d31cec5cde95bbc9 Jose Gonzalez Gomez wrote: > ---------- Forwarded message ---------- > From: *Jose Gonzalez Gomez* > > Date: 27-ene-2006 12:54 > Subject: Re: [gentoo-java] webapp-config & Java > To: Andrew Cowie > > > 2006/1/27, Andrew Cowie < andrew@operationaldynamics.com > >: > > On Thu, 2006-26-01 at 16:56 -0500, Joshua Nichols wrote: > > > Following the spirit of not using bundled jars for building, this > leads > > me to think that it would be better to explode the wars, and > replace the > > jars contained within with symlinks to the jars on the system. > > Note that some app-servers can't/won't deal with an exploded war/ear. > > > I think this issue has more to do with solving the issues with java > builds based in ant or maven than finding bundled jars... currently > almost every Java package out there is built using either ant or maven > (please, some Java Gentoo developer correct me if I'm wrong). In the > case of maven, jar dependencies are not bundled with source files, > they are specified as dependencies in the project descriptors. In the > case of web applications, those dependencies are downloaded from > binary repositories, and bundled in the WEB-INF/lib directory of the > war file at build time. The obvious solution (don't know if easy to > implement, I remember some discussion here regarding this) is to > intercept in some way the maven dependency resolution mechanism and > instead of downloading binary jars, take jars from the java packages > already installed by Gentoo. You are right that most things build using maven and/or ant. We don't currently build packages using maven due to the downloading-random-jars bit. But the solution to that isn't really relevant to this particular discussion, although feel free to revive the previous thread on that matter. > In case you still want to go the explode/replace way, as Andrew tells, > you won't be able to use symlinks, as some app-servers can't deal with > exploded archives. You should replace those jars with jars present on > the system, and then repackage and deploy the archive. I see this more > unnatural than the previous solution, although maybe easier to do. Perhaps we should first figure out which, if any, web containers / app servers don't support explodedness, before discounting this method. There is a very good reason for going the exploded-war-with-symlinked-jars path: you'd always be using the most up to date versions of the jars that have been installed on your system. Case in point, I recall a security vulnerability recently with struts. Now, if you were deploying an unexploded webapp with a vulnerable version of struts, then you'd still have the vulnerability in your webapp even after updating to a non-vulnerable version of struts. This wouldn't happen if we went the exploded-war-with-symlinked-jars, and at most you may have to restart the webapp and / or web container. - Josh -- gentoo-java@gentoo.org mailing list