Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 88422 invoked from network); 2 Apr 2005 15:43:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 2 Apr 2005 15:43:18 -0000 Received: (qmail 26311 invoked by uid 500); 2 Apr 2005 15:43:11 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 26261 invoked by uid 500); 2 Apr 2005 15:43:10 -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 Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 26248 invoked by uid 99); 2 Apr 2005 15:43:10 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from adsl-209-233-18-245.dsl.snfc21.pacbell.net (HELO buttons.boynes.com) (209.233.18.245) by apache.org (qpsmtpd/0.28) with ESMTP; Sat, 02 Apr 2005 07:43:10 -0800 Received: from [192.168.37.193] (unknown [192.168.37.193]) by buttons.boynes.com (Postfix) with ESMTP id 0A30A128B3 for ; Sat, 2 Apr 2005 07:43:06 -0800 (PST) Message-ID: <424EBD78.2090105@apache.org> Date: Sat, 02 Apr 2005 07:42:48 -0800 From: Jeremy Boynes User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@geronimo.apache.org Subject: Re: Splitting up geronimo-system References: <424C4968.5030408@apache.org> In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Dain Sundstrom wrote: > I'm a bit confused about what specifically you are proposing to move. > For example, would it be the full logging stuff or just the logging > initializer code? > Everything that is not pertinent; system has become a junk drawer for "stuff that needs to happen early" and "stuff that might be done by a couple of configs". It's getting a bit like the common module (which could also use a clean out). Take logging - the needs of a command line tool are different from those of a daemon (e.g. a command line tool runs and exits so you don't need to be able to change properties whilst it is running which simplifies things). But now both client and server are using the same mechanisms as defined in system. > Also, are we going to loose reuse if we start moving this code to > configuration packaging modules? I would assume that if we move the > command line stuff to one the packaged configuration, and another needed > the same command line code it would need to make a copy of the source code. > Most of the reuse in that example comes from commons-cli - the rest is specific to the command being run which by its nature is not reusable. I think there's quite a bit more like that. What got me thinking about this was wanting to add command line options to the server (e.g. so you can pass a list of configs in a file) and seeing that I would be conflicting with other stuff in Daemon. -- Jeremy