Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 90414 invoked from network); 12 Jan 2007 19:53:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Jan 2007 19:53:05 -0000 Received: (qmail 63229 invoked by uid 500); 12 Jan 2007 19:53:06 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 63190 invoked by uid 500); 12 Jan 2007 19:53:06 -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 63179 invoked by uid 99); 12 Jan 2007 19:53:06 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Jan 2007 11:53:06 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of ammulder@gmail.com designates 66.249.92.175 as permitted sender) Received: from [66.249.92.175] (HELO ug-out-1314.google.com) (66.249.92.175) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Jan 2007 11:52:57 -0800 Received: by ug-out-1314.google.com with SMTP id m2so1089124ugc for ; Fri, 12 Jan 2007 11:52:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=g4xZHnQA3f0f4zE17mkR/Azpfo38CraFR86G2awKdDOYBaeU+guC0hUbN4F/m00lr2Y1IQ/9rFEh9eTuf5jCg3Joey9DlppgKzHA/MWsvalPIl2paSA757yegg/dB7sDTIGTT6HKkaBL3JWEBXtBZq9HgqOaBbFsw88Jhs+pwco= Received: by 10.82.138.6 with SMTP id l6mr197199bud.1168631554917; Fri, 12 Jan 2007 11:52:34 -0800 (PST) Received: by 10.82.120.2 with HTTP; Fri, 12 Jan 2007 11:52:34 -0800 (PST) Message-ID: <74e15baa0701121152s6a00954fr7aa8c2515c1d43ea@mail.gmail.com> Date: Fri, 12 Jan 2007 14:52:34 -0500 From: "Aaron Mulder" Sender: ammulder@gmail.com To: dev@geronimo.apache.org Subject: Re: Assemblies assemblies everywhere and which one to ship? In-Reply-To: <051CF56C-2490-4DBA-BAA0-D3DA0576D2C8@planet57.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <33031AF9-A74F-4CD0-943D-4CCB27D192E1@hogstrom.org> <19e0530f0701091938x3c5360e8jc4b69f8a4c33f119@mail.gmail.com> <5eb405c70701102101ob118dbapae8b478de1e408d0@mail.gmail.com> <90B8A20C-5730-4201-A585-22F6BC09BF04@yahoo.com> <475CC78B-E9DA-42D0-AD29-0E5E8E88FB25@hogstrom.org> <833C4BE2-0280-465F-AFF6-0D99700B734C@hogstrom.org> <499B6A1B-489E-4DE9-9D9F-693CB99F47F5@planet57.com> <21df75940701120857h2aa24167j2af057624d65e0c1@mail.gmail.com> <051CF56C-2490-4DBA-BAA0-D3DA0576D2C8@planet57.com> X-Google-Sender-Auth: d1584476acbff8b2 X-Virus-Checked: Checked by ClamAV on apache.org You can install a plugin from the command line deploy tool -- just use the "install-plugin" command point it to the CAR file. The down side is that if that plugin has dependencies, they will be resolved against a remote repository (as listed in the plugin metadata). So you'd presently have to pluginize all the dependencies and install them in "just the right order" to avoid hitting a remote repo. One of the items on the plugin todo list is to support something like a ZIP file where everything attempts to resolve against the contents of the ZIP before going to remote repositories. For purposes of an installer, you could extract all the "source JARs" to a directory formatted like a Maven 2 repo, and then use a file:/// URL as the remote repository. I think the problem there is that the remote repository listed in the plugin metadata presently overrides the location the plugin was actually loaded from. It should be easy enough to add some kind of flag to reverse that so the "current" repository gets priority during an install. Thanks, Aaron On 1/12/07, Jason Dillon wrote: > How easy is it to install a set of plugins from the command-line? > > And don't plugins require a remote repository to hold the archives? > While I think that this is good to allow installation of custom > plugins, I don't think its good to use a remote repo to install > system components. I'd rather ship everything in one assembly, and > then have a simple command-line tool to allow customization of what > is installed. > > I'm no expert on how plugins currently work, but it is my > understanding that it is not that easy to configure a server to use a > set of plugins from he command-line (or driven off of a configuration > file). For build automation and TCK testing it would be a PITA to > require the console and then need to automate clicks to setup the > right configuration for testing. > > Eventually... I think that everything (except the core kernel and > deployment system) should be in some self-contained plugin, which > could be zipped up in an archive, or as a set of xmls and jars which > could be deployed into the server. > > My understanding is that we are not really to that point yet, > hopefully once 2.0 is out we can focus on some of these usability and > configuration issues. > > --jason > > > On Jan 12, 2007, at 11:57 AM, Paul McMahan wrote: > > > On 1/12/07, Jason Dillon wrote: > >> If we do start shipping 8 (or more) different assemblies... which > >> I think is > >> crazy, then we probably don't want to hook them all up to the > >> default build, > >> as it will just cause it take longer and longer to run. > >> > >> We really need to get plugins functional so that we can build one > >> assembly. > >> > >> Please... :-) > > > > AFAIK the plugin functionality already works sufficiently well to > > support this approach. And the infrastructure should already be in > > place as well since the plugin repository catalogs at > > geronimo.apache.org point to maven repos where the Geronimo CARs get > > published. > > > > Granted we've only used plugins for installing applications so far and > > really haven't tried using plugins to install or replace core jee5 > > services, so there may be missing functionality that needs our > > attention. Only way to know for sure is to identify each config that > > should be provided as plugin, map out its dependencies, and add a > > geronimo-plugin.xml to the CAR file that maven builds. Then update > > the plugin catalog so when that CAR gets published to the maven repo > > it will be installable as a plugin. There are several examples in > > trunk/configs. > > > > Best wishes, > > Paul > > >