The Tuscany project needs a set of spec jars that matches the
Tuscany implementation.  These probably won't exactly match any
well-defined level of the spec, at least over the next few months
as the SCA spec evolves towards 1.0 and the SDO spec evolves
towards 2.1.  I think these spec jars should be versioned in
the same way as the Tuscany implementation because they are
effectively part of it.

It would be possible for Tuscany to (in addition) do as you
suggest and produce spec jars at various published levels of the
"moving target" SCA and SDO specs.  I don't think this would be
a good idea.  It should be the spec group that produces official
spec jars matching given stable levels of the spec, such as 1.0,
1.1, etc.  There's no reason for the spec group to produce jars
for intermediate draft levels such as 0.92 (because there is no
chance of applications being portable across implementations at
these intermediate draft levels).  Similarly I don't see a
reason why Tuscany would produce spec jars matching these
intermediate levels unless they were needed as part of the
Tuscany implementation.

  Simon

Jeremy Boynes wrote:
Simon Nash wrote:

I think the same reasoning should apply to the org.osoa jars.
We should not tie them to a particular SCA spec revision, such
as 0.92, while the spec is stil evolving.  For example, by the
time we release M2, the spec may be at 0.93 or later.  Also, not
all parts of the spec are currently at 0.92.  Some are at 0.95.
For SDO APIs, the spec level that we are supporting is a mix of
2.01 and 2.1.  I'm inclined to think we should just use
 1.0-incubating-SNAPSHOT
for the spec jars as well.



I think perhaps I wasn't quite clear enough. The "0.92" bit was really
just an example. What I was really trying to say was that the version
number for the spec jars should contain somewhere the version number of
the spec document that the jar related to. It would be completely
independent of the version of our implementation.

Following this convention, the version for the jars we released with M1
would change to
   0.9-incubating
as the Java C&I spec from November is "SCA Version 0.9, November 2005"

When the next draft is published, the version would then be bumped to
   0.92-incubating
or whatever the final version of that draft is.

We don't need to wait until M2 to version these jars - IMO their release
cycle should be tied to specification releases rather than our
implementation releases.

This would also mean that the SDO API jars had a different version
number, probably 2.01. Again this is different from what we support in a
particular implementation release.

The API jars should be a resource that can be used independently from
Tuscany. For example, someone should be able to compile against them and
know that their application would be portable to any other SCA
implementation (at least at the API level, whether it worked would be a
different issue).

--
Jeremy

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Simon C Nash   IBM Distinguished Engineer
Hursley Park, Winchester, UK   [EMAIL PROTECTED]
Tel. +44-1962-815156   Fax +44-1962-818999


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to