Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer;
  b=MbiOBsgxyza2BkKShXrNVrIP49gX5lpLJ6jKepcxcTm58LzR9M/ih8VBoN7668kAqK5atVRTYGEqZ80vCKHyo3qrP43zAp23zxXwGYfrbIABcF6VAhGALQ1AwcnXKjMoqCkTP09yfX+K4hcErvthjb4I74Ju2Kf78v6DXJZCcno=
  ;
Message-Id: <A06154B8-F8DD-4F93-9724-FD1140FC54EB@yahoo.com>
From: David Jencks <david_jencks@yahoo.com>
To: "Geronimo Dev List \(JIRA\)" <dev@geronimo.apache.org>,
  dev@tranql.codehaus.org
In-Reply-To: <4AB8FEE6.7090808@apache.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: Proposed tranql svn reorganization
Date: Tue, 22 Sep 2009 10:17:04 -0700
References: <47F76D72-8DEB-4FC6-962D-9CD43F55F102@yahoo.com>
 <5e7fd1eb0909212035v344065b2o2fa716fc31d5e421@mail.gmail.com>
 <fbab58220909212039y4ad29372w16aaae0ba6f06ed0@mail.gmail.com>
 <58E8B253-3AFA-4901-8D71-6825C98CD643@yahoo.com>
 <4AB8FEE6.7090808@apache.org>


On Sep 22, 2009, at 9:44 AM, Donald Woods wrote:

> Flat structure like spec sounds good.
>
> Would there also be a common tranql-parent POM, or would they all  
> use genesis?

I think a tranql-parent, like there is now.  Tranql is not a geronimo  
subproject, despite most of the discussion about it being here rather  
than on the tranql dev list where it should be, so I'm not in favor of  
using the geronimo parent pom for it.

thanks
david jencks

>
>
> -Donald
>
>
> David Jencks wrote:
>> On Sep 21, 2009, at 8:39 PM, Rex Wang wrote:
>>>
>>>
>>> 2009/9/22 Jack Cai <greensight@gmail.com <mailto:greensight@gmail.com 
>>> >>
>>>
>>>    I think it's a good idea. A small problem that I see is currently
>>>    all the vendor connectors have different version numbers. If we
>>>    are going to put them under the same folder, shall we bump them  
>>> to
>>>    the same version?
>>>
>>> So, if I update one vendor and change its version, I should update  
>>> all the vendors' version?
>> Since the vendor wrappers are not built together, there is no need  
>> for them to have the same version.
>> I was actually thinking further of:
>> - combining connector and connector-ra into a folder, perhaps  
>> "generic"
>> - removing the "vendors" folder and having generic, derby, db2,  
>> postgres,.... next to one another.
>> But even if we keep the vendors folder the versions don't have to  
>> be related.
>> thanks
>> david jencks
>>>
>>> -Rex
>>>
>>>
>>>    -Jack
>>>
>>>
>>>    On Tue, Sep 22, 2009 at 4:41 AM, David Jencks
>>>    <david_jencks@yahoo.com <mailto:david_jencks@yahoo.com>> wrote:
>>>
>>>        I've been irked for a while with the tranql svn organization
>>>        and just bit myself by not being careful enough to check the
>>>        extent of the changes IDEA made.  I'd like to reorganize svn
>>>        to make life clearer and simpler.
>>>
>>>        1. There are basically 2 projects, the query language itself
>>>        which is not really under active development at the moment,
>>>        and the j2ca connector framework which occasionally gets
>>>        tweaked.  I'd like to separate them.
>>>
>>>        2. We have a lot of foo/bar/trunk type directories.  Our
>>>        experience in the geronimo specs projects is that maven 2 has
>>>        no problem with separately versioned subprojects all under  
>>> trunk.
>>>
>>>        So, I'd like to propose
>>>
>>>        ql/
>>>        +/branches
>>>        +/tags
>>>        +/trunk
>>>
>>>        ra/
>>>        +/branches
>>>        +/tags
>>>        +/trunk
>>>
>>>
>>>        Under ra/trunk we'd have connector, connector-ra, and the
>>>        individual vendor directories such as derby, oracle, etc.
>>>
>>>        Thoughts?  In particular does anyone think moving the  
>>> existing
>>>        tags will cause problems?
>>>
>>>        thanks
>>>        david jencks
>>>
>>>
>>>