You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2006/10/02 20:43:22 UTC
spec/sdo API version issue
On irc this morning the question came up about which version of the
spec the spec/sdo API related to. The conclusion was 2.0.1 + a couple
of methods from 2.1 but not all.
Is this the case?
If so, are we allowed to release a jar which does not correspond to
an official version of the spec? I know this is major problem for
APIs from the JCP.
If we are, do we want to do this? Would "good netizenship" imply that
we should keep versions in sync with published versions?
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: spec/sdo API version issue
Posted by kelvin goodson <ke...@gmail.com>.
I have removed the offending APIs from the sdo-java-M2 branch
Regards, Kelvin
On 02/10/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> On Oct 2, 2006, at 1:42 PM, Frank Budinsky wrote:
>
> > I don't see this as a big deal, but if others feel strongly that it is
> > bad, then we can take the two offensive methods out of the TypeHelper
> > interface and cast to TypeHelperImpl in a couple of places. I'd
> > suggest we
> > just make this change in the release branch, so that the trunk is
> > still
> > set for 2.1.
>
> That would resolve all my concerns - thanks.
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: spec/sdo API version issue
Posted by Jeremy Boynes <jb...@apache.org>.
On Oct 2, 2006, at 1:42 PM, Frank Budinsky wrote:
> I don't see this as a big deal, but if others feel strongly that it is
> bad, then we can take the two offensive methods out of the TypeHelper
> interface and cast to TypeHelperImpl in a couple of places. I'd
> suggest we
> just make this change in the release branch, so that the trunk is
> still
> set for 2.1.
That would resolve all my concerns - thanks.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: spec/sdo API version issue
Posted by Frank Budinsky <fr...@ca.ibm.com>.
I don't see this as a big deal, but if others feel strongly that it is
bad, then we can take the two offensive methods out of the TypeHelper
interface and cast to TypeHelperImpl in a couple of places. I'd suggest we
just make this change in the release branch, so that the trunk is still
set for 2.1.
Frank.
Jeremy Boynes <jb...@apache.org> wrote on 10/02/2006 04:00:17 PM:
> On Oct 2, 2006, at 12:01 PM, Frank Budinsky wrote:
>
> > Jeremy Boynes <jb...@apache.org> wrote on 10/02/2006 02:43:22 PM:
> >
> >> On irc this morning the question came up about which version of the
> >> spec the spec/sdo API related to. The conclusion was 2.0.1 + a couple
> >> of methods from 2.1 but not all.
> >>
> >> Is this the case?
> > Yes.
> >
> >> If so, are we allowed to release a jar which does not correspond to
> >> an official version of the spec? I know this is major problem for
> >> APIs from the JCP.
> > I don't know of anything that says we aren't.
> >
> >> If we are, do we want to do this? Would "good netizenship" imply that
> >> we should keep versions in sync with published versions?
> > We are officially 2.0.1.
>
> I would think in that case the API signature should match 2.0.1
> rather than something undefined.
>
> > The only thing we've added from 2.1 is a couple of well marked new
> > methods
> > (names are still subject to change in the 2.1 spec). There is no
> > change to
> > any of the official 2.0.1 behavior. It shouldn't matter that we
> > added the
> > new methods since they won't affect users that don't call them.
> > They are
> > quite useful, however, for our own development.
>
> Can we just add those to our implementation rather than to the spec
> API (until we do spec 2.1 of course)? They do affect users of the
> spec API as code may compile against this version but not work with
> other implementations. Any other implementation would also be
> affected as they would have undefined methods which would prevent
> compilation.
>
> >
> > Our next release (M3) will officially move to the 2.1 interfaces,
> > but we
> > won't be fully 2.1 compliant (e.g., some methods will throw
> > UnsupportedOpertationException). For that matter, we're also not fully
> > 2.0.1 compliant now either.
>
> It's OK for our implementation to be incomplete or to offer
> additional features but I don't think we should bend the spec API
> like this.
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: spec/sdo API version issue
Posted by Jeremy Boynes <jb...@apache.org>.
On Oct 2, 2006, at 12:01 PM, Frank Budinsky wrote:
> Jeremy Boynes <jb...@apache.org> wrote on 10/02/2006 02:43:22 PM:
>
>> On irc this morning the question came up about which version of the
>> spec the spec/sdo API related to. The conclusion was 2.0.1 + a couple
>> of methods from 2.1 but not all.
>>
>> Is this the case?
> Yes.
>
>> If so, are we allowed to release a jar which does not correspond to
>> an official version of the spec? I know this is major problem for
>> APIs from the JCP.
> I don't know of anything that says we aren't.
>
>> If we are, do we want to do this? Would "good netizenship" imply that
>> we should keep versions in sync with published versions?
> We are officially 2.0.1.
I would think in that case the API signature should match 2.0.1
rather than something undefined.
> The only thing we've added from 2.1 is a couple of well marked new
> methods
> (names are still subject to change in the 2.1 spec). There is no
> change to
> any of the official 2.0.1 behavior. It shouldn't matter that we
> added the
> new methods since they won't affect users that don't call them.
> They are
> quite useful, however, for our own development.
Can we just add those to our implementation rather than to the spec
API (until we do spec 2.1 of course)? They do affect users of the
spec API as code may compile against this version but not work with
other implementations. Any other implementation would also be
affected as they would have undefined methods which would prevent
compilation.
>
> Our next release (M3) will officially move to the 2.1 interfaces,
> but we
> won't be fully 2.1 compliant (e.g., some methods will throw
> UnsupportedOpertationException). For that matter, we're also not fully
> 2.0.1 compliant now either.
It's OK for our implementation to be incomplete or to offer
additional features but I don't think we should bend the spec API
like this.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: spec/sdo API version issue
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Jeremy Boynes <jb...@apache.org> wrote on 10/02/2006 02:43:22 PM:
> On irc this morning the question came up about which version of the
> spec the spec/sdo API related to. The conclusion was 2.0.1 + a couple
> of methods from 2.1 but not all.
>
> Is this the case?
Yes.
> If so, are we allowed to release a jar which does not correspond to
> an official version of the spec? I know this is major problem for
> APIs from the JCP.
I don't know of anything that says we aren't.
> If we are, do we want to do this? Would "good netizenship" imply that
> we should keep versions in sync with published versions?
We are officially 2.0.1.
The only thing we've added from 2.1 is a couple of well marked new methods
(names are still subject to change in the 2.1 spec). There is no change to
any of the official 2.0.1 behavior. It shouldn't matter that we added the
new methods since they won't affect users that don't call them. They are
quite useful, however, for our own development.
Our next release (M3) will officially move to the 2.1 interfaces, but we
won't be fully 2.1 compliant (e.g., some methods will throw
UnsupportedOpertationException). For that matter, we're also not fully
2.0.1 compliant now either.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org