Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ammulder@gmail.com designates
 66.249.82.229 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        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=tdPh1DO+5Rc1gCFEcq4t3C5b2NdmkCkw8KNAj8bNa1utOA8d8LNkUqidkGS1FqMmYJ3LbZm6ekc6kGIpV7lP2BDzn3VvdWmDYuOyDnx9NT+GjO03qDzWMKnGgxwUVqZv6eX2jXj9M6us9evgDlXFsib27fCNhjpzFRdch9fcJGc=
Message-ID: <74e15baa0608101256q4138b041i8290b06fb95b4b2b@mail.gmail.com>
Date: Thu, 10 Aug 2006 15:56:57 -0400
From: "Aaron Mulder" <ammulder@alumni.princeton.edu>
Sender: ammulder@gmail.com
To: dev@geronimo.apache.org
Subject: Re: Independently version transaction and connector
In-Reply-To: <DB899448-B49D-4218-A7C5-111C8282FC56@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <AE3954E7-43BB-45E4-A28A-3A144BEECC60@iq80.com>
	 <44DB37CB.4040405@hogstrom.org>
	 <F2804299-A8EC-45A8-A5EF-61109C7B73F0@iq80.com>
	 <44DB7C73.3020309@hogstrom.org>
	 <b23ecedc0608101218raa1b28au374b64aa232aff66@mail.gmail.com>
	 <40AF24C8-7737-49DD-A61A-B3315358F3CF@iq80.com>
	 <DB899448-B49D-4218-A7C5-111C8282FC56@yahoo.com>

I think it makes sense to put the non-G-specific core classes in a
separate module from the GBeans.  I don't feel strongly whether the
GBean module(s) should go in G or not, though I might perhaps lean
toward "in Geronimo".  I think the connector builder should definitely
stay in Geronimo.

Thanks,
    Aaron

On 8/10/06, David Jencks <david_jencks@yahoo.com> wrote:
> So, in principle I'm basically in favor of this, although I think it
> might make sense to version the tm and connector stuff together --
> not sure on that.
>
> My concerns on doing it now and additional questions to ponder are:
>
> -- These modules still depend on g. kernel due to gbeans.  I wonder
> if it would make more sense to wait for xbean-ization.
>
> -- the connector builder is not too likely to be useful to others so
> there's an argument for keeping it in geronimo
>
> We might want to think about moving the gbean wrappers to one or two
> separate modules that stay in g and moving the functional classes
> into independent modules.
>
> thanks
> david jencks
>
> > -dain
> >
> >
> > On Aug 10, 2006, at 12:18 PM, Guillaume Nodet wrote:
> >
> >> I think what Dain means is that these modules should be released
> >> often
> >> so that Geronimo would only use released version of these modules
> >> and not snapshots.
> >> The main thing being imho to release often so that other projects do
> >> not have to wait a full Geronimo release when a change occur to be
> >> able
> >> to use it.
> >>
> >> On 8/10/06, Matt Hogstrom < matt@hogstrom.org> wrote:
> >>
> >> Dain Sundstrom wrote:
> >> > On Aug 10, 2006, at 6:42 AM, Matt Hogstrom wrote:
> >> >
> >> >> I can see the difficulty pointed out by Jason and the benefit
> >> raised
> >> >> by Dain.  I've never liked versioning parts of Geronimo that
> >> rarely
> >> >> change and am all for making things more consumable externally.
> >> >>
> >> >> The proposal as it stands is fairly generic.  Is the idea to
> >> relocate
> >> >> Tx Manager and Connector to be top-level projects withing
> >> Geronimo and
> >> >> build separately or some kind of hybrid in the current tree.
> >> If we
> >> >> are going to release them independently then I think they
> >> should be
> >> >> top-level in Geronimo (and I know thats a lot more work).
> >> >
> >> > I wanted to get a general sense before discussing the details,
> >> since
> >> > there would be no point if were against independent versioning.
> >> I was
> >> > thinking we should put each them in a tree which is a peer to
> >> Geronimo
> >> > trunk.  I also think we should generally only use released
> >> versions of
> >> > the jars in Geronimo (i.e., no snapshots) for two reasons 1) it
> >> is much
> >> > easier to maintain from a build perspective and 2) is will push
> >> us to do
> >> > more frequent releases of them.
> >>
> >> Not sure I understand the last statement. (no snapshots)
> >>
> >> > -dain
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Cheers,
> >> Guillaume Nodet
> >
>
>