Mailing-List: contact cayenne-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cayenne-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <20061010205409.7e77150f@localhost.localdomain>
References: <525d8e10610081940l4f4b993fu2b57ef5d4ca3fabb@mail.gmail.com>
 <ED676423-9A72-4139-AA66-7A26B093F207@objectstyle.org>
 <525d8e10610082145r4b287c0ap8e3fa161899ae6cd@mail.gmail.com>
 <BD5041CC-334E-4AB4-B835-AE066D388FB1@objectstyle.org>
 <20061010205409.7e77150f@localhost.localdomain>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <D5402E78-8A8F-41CD-AEA8-1832FC7AD997@objectstyle.org>
Content-Transfer-Encoding: 7bit
From: Andrus Adamchik <andrus@objectstyle.org>
Subject: Re: DataView status
Date: Tue, 10 Oct 2006 15:25:21 -0400
To: cayenne-dev@incubator.apache.org

On Oct 10, 2006, at 2:54 PM, Adrian Wiesmann wrote:
>> * If we (cayenne dev community) are to continue the development, as a
>> first step I suggest making Cayenne core independent of DV runtime.
>
> I would suggest to move DV "out of the way" so that it is not  
> hurting the
> normal Cayenne development. But please keep DataViews supported. I am
> currently in the process to switch to Cayenne 3.x because I absolutely
> need the Lifecycle Callbacks (generating uuid formated key when  
> creating a
> new object and updating the last_updated field before committing  
> changes).
>
> Because the SOBF tool is that much depending on DataViews I would very
> much like to see them at least not removed. I would hate to have to  
> redo
> everything I already programmed only because of DataViews being  
> removed
> from Cayenne.

This sounds like a reasonable strategy. I guess we can promise that  
much. But again, I appreciate if all interested parties could  
actually help us with DV maintenance. You probably know much more  
about DV than myself or any of the current committers anyways :-)

As the history shows (DV, JStaple and Rowan projects), there is lots  
of interest in Swing-related technologies in our community, but not  
nearly as much commitment. I suspect it is because Swing is not  
paying anyone's bills consistently (e.g. I may have a 2-month Swing  
project and then switch back to webapps, I believe that's the case  
with others too).

It would be cool if we could find one or more dedicated developers  
with a vision in this area to lead the Swing effort. But I'll keep  
dreaming...

> The SOBF tool (Security Officers Best Friend, Open Source tool for
> assessing information security risk)

I like your website :-)

Andrus