[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tuscany-user
Subject:    Re: [Cross Subproject Discussion] options for SDO Java in Apache
From:       Simon Nash <nash () apache ! org>
Date:       2008-02-16 15:44:54
Message-ID: 47B704F6.3090800 () apache ! org
[Download RAW message or body]

It would be good to keep this discussion on tuscany-user and not have it
intermingled across the tuscany-user and tuscany-dev lists.

Other comments inline.

   Simon

ant elder wrote:
> On Feb 15, 2008 10:39 AM, Mike Edwards <mike.edwards.inglenook@gmail.com>
> wrote:
> 
>> Folks,
>>
>> A few observations inline.
>>
>> Ron Gavlin wrote:
>>> I think consolidating the two SDO implementations under a single
>>> implementation would be good for the entire Apache SDO community. My
>> concern
>>> would be that no Tuscany SDO features be lost in the transition. The
>>> new implementation should provide most of what I can currently achieve
>>> using both EMF and Tuscany SDO. For example, EMF features like
>> integrated validation should be
>>> available in the new implementation before the old implementation is
>> dumped. It might be a good idea to poll the Tuscany SDO community to
>> identify the EMF features currently being used by Tuscany SDO community. It
>> might also be interesting to poll the Eclipse EMF SDO 1.0 community and
>> ask the same question. Maybe many of the existing Tuscany SDO test cases
>> could be re-written for either 1). the new implementation  or 2). the CTS,
>> to minimize the loss of functionality during the transition.
>>
>> There is a fundamental tension here which I think it is important to
>> recognise.
>>
>> On the one hand, we want to ensure a lively and progressive Apache SDO
>> community that continually extends the capabilities of SDO to better
>> suit the needs of users.  Innovation is a bit part of this story.
>>
>> On the other hand, we're trying to promote an open (and open source)
>> approach to the standardization of the SDO interfaces, to help ensure
>> consistent implementation of SDO across products both commercial and
>> open source.  There is a JSR and a set of activities taking place in
>> OASIS for this.  Part of that work is to produce an RI and a TCK, open
>> to all.  However, an RI must be just that - an exemplary implementation
>> of the specification, the whole specification and nothing but the
>> specification.  Similarly, the TCK must be testing compliance of
>> implementations with the specification, the whole specification and
>> nothing beyond the specification.  This demands limitations on innovation.
>>
>> So, there is some careful work required in building both forward-looking
>> innovative capabilities and at the same time creating somewhat rigid RIs
>> and TCKs, which are inevitably tied to specific versions of a
>> specification.  I think that the proposal to have a second SDO project
>> in Apache is regarded as one way to approach these conflicting
>> requirements.  It may not be the only way, but at least it would provide
>> clear dividing lines that both contributors and users can understand
>> easily.
>>
>> It will take some careful thought to combine these aspects within one
>> project in a way that works for all contributors and for all users.
>>
+1.  This will be one of the biggest challenges in bringing these two
SDO efforts together.

>> One of the reasons that Tuscany is NOT an RI and does NOT contain a TCK
>> for SCA is because it fosters freedom in the implementation of new
>> capabilities that go well beyond the current SCA specifications.  Some
>> of these will feed into future "standard specifications", I'm sure.
>>
+1.  I think it's important to retain this freedom for Tuscany to
innovate and not be constrained to exactly match any particular level
of the specs that it implements.

>>> >From my perspective, the priorities for Apache SDO moving forward should
>> be:
>>> 1. Align Apache SDO with the JAXB specification.
>>> The static SDO implementation should be JAXB-compliant.
>>>
>>> 2. Align Apache SDO with the JPA specification. It should be simple to
>> use a OpenJPA to persist SDO graphs.
>>> 3. Provide data binding support for popular Java open source WS stacks,
>> especially Axis2 and CXF.
>> Yes, all good innovative stuff.
>>
>> I could toss in a few more, such as having an SDO implementation for
>> JavaScript to address AJAX applications.
>>
>> But how to square this with the RI and TCK with fixed functions matching
>> the SDO 2.1 specification?
>>
> 
> Its also important to recognize that Apache is about community and projects
> need a scope that is broad enough to foster a community.
> 
> To maintain an active community there needs to be something to keep
> developers participating after the 2.1.1 RI is done, otherwise why even do
> this at Apache?  If a goal is to continually extend the capabilities of SDO
> and to feed innovation into future versions of specifications then thats
> going to work better if there is a single SDO community not communities
> split between separate Apache projects.
 >
I agree that a sustainable project community would need something beyond
just doing the RI for SDO 2.1.1.  This could be to continue as an RI for
future SDO spec levels, or it could be to branch out in innovative ways
beyond any current or in-progress SDO specification.  I suspect that
trying to do both of these at the same time would be quite a stretch and
could lead to neither goal being achieved very well.  If the proposers of
the new project could indicate which of these they expect to be the main
focus, I think that would be helpful.

>                                         Other Apache projects have managed
> to produce RIs without splitting the work out into a seperate project so i'm
> sure the same could be done here - separate builds or SVN branches or sub
> projects under the one SDO TLP.
> 
I'd be interested to know which of the two approaches I described above
has been taken by these other projects.  Have any been able to successfully
combine both aspects?

   Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]