Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 86685 invoked from network); 6 Aug 2007 20:16:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Aug 2007 20:16:19 -0000 Received: (qmail 50908 invoked by uid 500); 6 Aug 2007 20:16:17 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 50863 invoked by uid 500); 6 Aug 2007 20:16:17 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 50852 invoked by uid 99); 6 Aug 2007 20:16:17 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Aug 2007 13:16:17 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [69.147.95.82] (HELO smtp119.plus.mail.sp1.yahoo.com) (69.147.95.82) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 06 Aug 2007 20:16:04 +0000 Received: (qmail 95229 invoked from network); 6 Aug 2007 20:15:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer; b=5S8TOw7ZP+vpepCzWmMO4XbL9Y8Ezt+HPo8LEGSWu2JIguJ4l8eJz/JE9Qnz+jFqV76IBQYWcGsPL+jGUxjtv7Q5GaPhvuryuU8LhawPeN/xuFTKNYyTzn1XimEKWld4NoSol0ZAEiUwsENFrRzjNcoNaWUQf3U5Y9VB1To3BjE= ; Received: from unknown (HELO ?192.168.1.101?) (david_jencks@67.102.173.8 with plain) by smtp119.plus.mail.sp1.yahoo.com with SMTP; 6 Aug 2007 20:15:50 -0000 X-YMail-OSG: uaiDnDIVM1kUHz.g42FtdYWnICg0LFd1gwVVragICNHMQ2RU3xCrU94Se0KDCzZ2Ue8UaYbjVA-- Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <33BF7851-7913-4291-91C0-439E061CBC0D@planet57.com> <62A6EEF4-253D-4419-933B-E84EB81AD9BD@yahoo.com> <1EE3CA35-E9B7-4756-B322-D228D81E1B70@planet57.com> <46B7536B.3070809@apache.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5D41F119-141A-48FE-B42E-841284A228F3@yahoo.com> Content-Transfer-Encoding: 7bit From: David Jencks Subject: Re: Splitting up the server into a few more chunks Date: Mon, 6 Aug 2007 13:15:51 -0700 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.752.3) X-Virus-Checked: Checked by ClamAV on apache.org On Aug 6, 2007, at 12:43 PM, Paul McMahan wrote: > On Aug 6, 2007, at 12:59 PM, Donald Woods wrote: > >> we should consider the more drastic changes, like moving the base >> Admin Console support (via Pluto 1.2) out to /plugins > > I really like that idea for a couple of reasons - > - it allows us to keep the admin console that's currently at > server/trunk/applications/console in place until the new extensible > admin console is ready and can scale up from minimal to full JEE5 > functionality plus debug views, etc. > - I like the idea of streamlining server/trunk for JEE5 stuff and > moving the optional stuff elsewhere > > My only reservation (and its no biggie) is that using the location / > plugins for optional stuff is misleading since there will be stuff > in server/trunk that's required for JEE5 (i.e. not optional) but > implemented as plugins like tomcat, jetty, amq, openejb, etc. > Calling something a plugin is a statement about its packaging and > deployment mechanism, and not whether it is required or optional. > > So maybe "/opt" or some such would be a better place to put the > extensible admin console, tuscany (eventually), directory server, > samples, roller, etc... > >> and start moving the Portlets into the actual modules/configs that >> they administer.... > > I like this idea from a conceptual point of view since it keeps > things neat and well organized. But I am not sure how to implement > it since the main geronimo components are typically packaged in > JARs, and the admin portlets for a component have to be packaged in > a WAR (that's just the way that pluto works). i.e. a JAR can't > contain a WAR. > > Some options I can think of: > - use EAR as the packaging format for all geronimo components and > package the admin WARs inside them > - maintain geronimo components and their admin WARs separately. > bind them at deployment time via the plugin installer's dependency > resolution or by some enhancement to the maven car plugin > - package the geronimo components as WARs so the admin portlets > can be merged with them. (seems like the tail wagging the dog) > - follow some organizational structure like in your previous email > where each geronimo component has a module, config, and (now) WAR > subdirectory > > Just brainstorming here... I think we want to use "plugin groups" which IIRC is already implemented in some way. So I see a typical feature (say jetty support) as having 3 plugins: - runtime jetty (geronimo-jetty6 module + jetty car) - deploy time jetty (geronimo-jetty6-builder + jetty-deployer car) - admin jetty (war with jetty admin portlets) To keep it simple I'm purposefully forgetting about wadi clustering support. I think you should be able to install (1), (1 and 3) (1 and 2) or (1 2 and 3). thanks david jencks > > > Best wishes, > Paul