You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Ron Gavlin <rg...@yahoo.com> on 2006/09/21 15:38:57 UTC
Tuscany SDO M2 candidate distribution
Kelvin,
We are interested in testing an SDO M2 release candidate distribution (both source and binary). Are you planning to create one? If so, do you have a target date for doing so?
Thanks in advance,
- Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Tuscany SDO M2 candidate distribution
Posted by kelvin goodson <ke...@gmail.com>.
I'm happy to take input on this. Creating a binary only distribution as a
first release candidate reduces the risk of me not meeting my target of
having a first candidate by tomorrow evening, but is that useful or is it
better to make having a source distribution a top priority? I'm guessing
that, given the speed with which Jeremy helped me configure the SDO binary
distribution that it may not be too big a deal to get the mechanism in place
with the right help, but it's going to take a bit longer if I have to
figure it out for myself. Unfortunately I have unavoidable commitments this
evening and over the weekend, so the scope for burning midnight oil to get
this done is limited :-(
Regards, Kelvin.
On 21/09/06, Ron Gavlin <rg...@yahoo.com> wrote:
>
> Kelvin,
>
> Thanks for the update. Do you plan to make a "release candidate" source
> distribution? If so, do you plan to make it in the same time frame as the
> binary one?
>
> Thanks,
>
> - Ron
>
> ----- Original Message ----
> From: kelvin goodson <ke...@gmail.com>
> To: tuscany-user@ws.apache.org; Ron Gavlin <rg...@yahoo.com>
> Sent: Thursday, September 21, 2006 9:48:24 AM
> Subject: Re: Tuscany SDO M2 candidate distribution
>
>
> Ron,
> I'm focussing on this with fervour at the moment, and my plan as it
> stood yesterday was to have a release candidate together by COB tomorrow,
> however, I'm struggling because of 1) the ASF requirements for a release
> are ill defined and 2) my lack of maven knowledge is making some trivial
> things take a long time. I'm planning on making use of the knowlege of
> colleagues from across the pond as soon as they appear and that should
> help
> things along.
>
> I do plan to make a source distribution, although currently we are only
> configured to make binary distributions.
> Regards, Kelvin.
>
> On 21/09/06, Ron Gavlin <rg...@yahoo.com> wrote:
> >
> > Kelvin,
> >
> > We are interested in testing an SDO M2 release candidate distribution
> > (both source and binary). Are you planning to create one? If so, do you
> have
> > a target date for doing so?
> >
> > Thanks in advance,
> >
> > - Ron
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
Re: dynamic containment in datagraphs
Posted by be...@agfa.com.
Hi Kelvin,
I think what Frank suggests is what we want. We will try the following.
(1) define one type "Bag". This type has two properties. "rootObject" a
single-valued property of type DataObject containing the root. The other,
"element", is a contained multi-valued property also of type DataObject.
(2) When transferring data always use the "Bag" type.
One drawback is that the Bag doesn't contain the metadata anymore of its
contents. So given a Bag you don't know what it is in it. But given that
for us, the bag is immediately used by the one who asks for it, this might
not be such a problem.
One reason why we don't want to define new types for each application,
form or even request is that that would make life much too complex for us.
For now, we are happy with subsets of our one model. And it is only that
single model that we want to document and maintain. Most of the models we
would make would differ only in details; defining dynamic types for all of
these would make it even more complex than it is now.
We already have a mapping to map our model onto the database so that
mapping takes care of most of the database/legacy pecularities that we
want to hide. So it's not such an issue to expose that model. Also, as we
need a powerful query facility, we don't want to stray to far from the
server-side model with yet another mapping. That would force us to
implement a query facility as well; something which we want to avoid if
possible.
W.r.t. the dynamic types, we are already using that. Parts of our model
are dynamic (as they depend for instance on region, customer, etc). These
parts we model using dynamic types.
thanks for the good replies!
Bert
"kelvin goodson" <ke...@gmail.com>
25/09/2006 15:26
Please respond to
tuscany-user@ws.apache.org
To
tuscany-user@ws.apache.org
cc
Subject
Re: dynamic containment in datagraphs
Hi Bert,
I was constructing a reply to your note, but Frank beat me to it ;-) So
what I want to ask is, is it acceptable for you to always have the
canonical
model that you use in your persistence layer present in the data graphs
that
the application sees, or are you trying to implement some kind of data
transfer object that abstracts away the shape of the persistence layer
such
that it is never visible to the application layer? (IIRC this is like a
session facade in J2EE?). If it's acceptable for you to build views onto
the canonical model using non-containment references then Frank's
suggestion
is fine. I was guessing that this was not the case.
I'm sure you've been thinking quite deeply about this so I may just be
having thoughts that you've already considered. If I understand your
problem
correctly, there are approaches to this which wouldn't need to be viewed
as
an extension to SDO. I think you want data transfer objects for which you
a) declare types dynamically
b) share those dynamic type definitions across layers
c) define a mapping between your dynamic types and the canonical model
used
by your persistence layer
a) can be done with, for example, XSDHelper.define() or
TypeHelper.define(),
b) the XSD or the graph of commonj.sdo.Type/Property instances passed to
the
methods above could be communicated between layers to make the type
systems
available to other layers
c) Here's the bit where I guess there's be some work to do, and therefore
potentially an area for extension, although my guess is it's best
implemented on top of SDO. There's the mapping definition to be done and
some logic would need to be implemented to act on the mapping. Before I
spend too much time thinking about the various ways to slice and dice this
let me just check with you that I'm reading between the lines correctly.
Regards, Kelvin.
On 25/09/06, Frank Budinsky <fr...@ca.ibm.com> wrote:
>
> Hi Bert,
>
> All that SDO requires is that every object being passed in a DataGraph
is
> in the DataGraph's container. If the types themselves form a containment
> graph on their own, then that's the simplest case. If instead, the
objects
> reference each other via non containment references, then it's the
> responsibility to the DAS to make sure that each object in the graph is
> ALSO the target of some containment reference. One way to do this is to
> simply use a special object as the root of the DataGraph that has direct
> containment references to the DataObjects of the graph and a maybe a
> non-containment reference to one of the contained DataObjects - the real
> root: This "dummy root object" simply acts as a container for the
objects
> in the graph. This root object could be a generic type, or alternatively
> an instance of a dynamically created type for the specific user model.
> Take a look at the way the Tuscany RDB DAS creates dynamic root types
like
> this.
>
> Frank
>
> bert.robben@agfa.com wrote on 09/25/2006 06:03:55 AM:
>
> > Hi all,
> >
> > I've a question on the usage of SDO datagraphs and the role of
> > containment.
> >
> > [Background]
> > In our application suite, we have a large datamodel consisting of
> several
> > hundreds of domain classes. Client applications typically want to
> download
> > data of a subset of the model. However, the exact definition of this
> > subset (i.e. which domain classes and which relations) can vary quite
a
> > lot depending on the application and also on configuration. We want to
> use
> > SDO to exchange data between client and server.
> >
> > [Problem]
> > To exchange data you need datagraphs.
> > Datagraphs require types that define a containment tree. [I have the
> > impression that this is in fact the definition of containment.]
> > Since clients can ask for very different subsets we need different
> > containment trees.
> > Containment is an integral part of a type, so we need also different
> > types. So, we need also different types.
> > One option is to use different namespaces for each subset. This helps
a
> > bit. However, in our case we would have a huge amount of namespaces.
> Also
> > since configuration can change the subset we would also need a kind of
> > dynamic namespace that is not defined at development time. This is
still
>
> > kind of feasible, but it is already getting complex. Then there is
also
> > the issue that different namespace means different type, which is also
> not
> > that nice.
> >
> > [Alternative]
> > What we are thinking of is some kind of extension to SDO to allow the
> > specification of containment outside of the type definition. You can
> > imagine this as providing a set of properties each time a datagraph is
> > created. This set of properties would define the containment relation,
> > i.e. the tree of data that defines the datagraph.
> >
> >
> > Any ideas about this?
> > Is this still inline with the ideas of SDO? Has this kind of
requirement
>
> > already been discussed somewhere?
> >
> >
> > Bert
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: dynamic containment in datagraphs
Posted by kelvin goodson <ke...@gmail.com>.
Hi Bert,
I was constructing a reply to your note, but Frank beat me to it ;-) So
what I want to ask is, is it acceptable for you to always have the canonical
model that you use in your persistence layer present in the data graphs that
the application sees, or are you trying to implement some kind of data
transfer object that abstracts away the shape of the persistence layer such
that it is never visible to the application layer? (IIRC this is like a
session facade in J2EE?). If it's acceptable for you to build views onto
the canonical model using non-containment references then Frank's suggestion
is fine. I was guessing that this was not the case.
I'm sure you've been thinking quite deeply about this so I may just be
having thoughts that you've already considered. If I understand your problem
correctly, there are approaches to this which wouldn't need to be viewed as
an extension to SDO. I think you want data transfer objects for which you
a) declare types dynamically
b) share those dynamic type definitions across layers
c) define a mapping between your dynamic types and the canonical model used
by your persistence layer
a) can be done with, for example, XSDHelper.define() or TypeHelper.define(),
b) the XSD or the graph of commonj.sdo.Type/Property instances passed to the
methods above could be communicated between layers to make the type systems
available to other layers
c) Here's the bit where I guess there's be some work to do, and therefore
potentially an area for extension, although my guess is it's best
implemented on top of SDO. There's the mapping definition to be done and
some logic would need to be implemented to act on the mapping. Before I
spend too much time thinking about the various ways to slice and dice this
let me just check with you that I'm reading between the lines correctly.
Regards, Kelvin.
On 25/09/06, Frank Budinsky <fr...@ca.ibm.com> wrote:
>
> Hi Bert,
>
> All that SDO requires is that every object being passed in a DataGraph is
> in the DataGraph's container. If the types themselves form a containment
> graph on their own, then that's the simplest case. If instead, the objects
> reference each other via non containment references, then it's the
> responsibility to the DAS to make sure that each object in the graph is
> ALSO the target of some containment reference. One way to do this is to
> simply use a special object as the root of the DataGraph that has direct
> containment references to the DataObjects of the graph and a maybe a
> non-containment reference to one of the contained DataObjects - the real
> root: This "dummy root object" simply acts as a container for the objects
> in the graph. This root object could be a generic type, or alternatively
> an instance of a dynamically created type for the specific user model.
> Take a look at the way the Tuscany RDB DAS creates dynamic root types like
> this.
>
> Frank
>
> bert.robben@agfa.com wrote on 09/25/2006 06:03:55 AM:
>
> > Hi all,
> >
> > I've a question on the usage of SDO datagraphs and the role of
> > containment.
> >
> > [Background]
> > In our application suite, we have a large datamodel consisting of
> several
> > hundreds of domain classes. Client applications typically want to
> download
> > data of a subset of the model. However, the exact definition of this
> > subset (i.e. which domain classes and which relations) can vary quite a
> > lot depending on the application and also on configuration. We want to
> use
> > SDO to exchange data between client and server.
> >
> > [Problem]
> > To exchange data you need datagraphs.
> > Datagraphs require types that define a containment tree. [I have the
> > impression that this is in fact the definition of containment.]
> > Since clients can ask for very different subsets we need different
> > containment trees.
> > Containment is an integral part of a type, so we need also different
> > types. So, we need also different types.
> > One option is to use different namespaces for each subset. This helps a
> > bit. However, in our case we would have a huge amount of namespaces.
> Also
> > since configuration can change the subset we would also need a kind of
> > dynamic namespace that is not defined at development time. This is still
>
> > kind of feasible, but it is already getting complex. Then there is also
> > the issue that different namespace means different type, which is also
> not
> > that nice.
> >
> > [Alternative]
> > What we are thinking of is some kind of extension to SDO to allow the
> > specification of containment outside of the type definition. You can
> > imagine this as providing a set of properties each time a datagraph is
> > created. This set of properties would define the containment relation,
> > i.e. the tree of data that defines the datagraph.
> >
> >
> > Any ideas about this?
> > Is this still inline with the ideas of SDO? Has this kind of requirement
>
> > already been discussed somewhere?
> >
> >
> > Bert
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
Re: dynamic containment in datagraphs
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Hi Bert,
All that SDO requires is that every object being passed in a DataGraph is
in the DataGraph's container. If the types themselves form a containment
graph on their own, then that's the simplest case. If instead, the objects
reference each other via non containment references, then it's the
responsibility to the DAS to make sure that each object in the graph is
ALSO the target of some containment reference. One way to do this is to
simply use a special object as the root of the DataGraph that has direct
containment references to the DataObjects of the graph and a maybe a
non-containment reference to one of the contained DataObjects - the real
root: This "dummy root object" simply acts as a container for the objects
in the graph. This root object could be a generic type, or alternatively
an instance of a dynamically created type for the specific user model.
Take a look at the way the Tuscany RDB DAS creates dynamic root types like
this.
Frank
bert.robben@agfa.com wrote on 09/25/2006 06:03:55 AM:
> Hi all,
>
> I've a question on the usage of SDO datagraphs and the role of
> containment.
>
> [Background]
> In our application suite, we have a large datamodel consisting of
several
> hundreds of domain classes. Client applications typically want to
download
> data of a subset of the model. However, the exact definition of this
> subset (i.e. which domain classes and which relations) can vary quite a
> lot depending on the application and also on configuration. We want to
use
> SDO to exchange data between client and server.
>
> [Problem]
> To exchange data you need datagraphs.
> Datagraphs require types that define a containment tree. [I have the
> impression that this is in fact the definition of containment.]
> Since clients can ask for very different subsets we need different
> containment trees.
> Containment is an integral part of a type, so we need also different
> types. So, we need also different types.
> One option is to use different namespaces for each subset. This helps a
> bit. However, in our case we would have a huge amount of namespaces.
Also
> since configuration can change the subset we would also need a kind of
> dynamic namespace that is not defined at development time. This is still
> kind of feasible, but it is already getting complex. Then there is also
> the issue that different namespace means different type, which is also
not
> that nice.
>
> [Alternative]
> What we are thinking of is some kind of extension to SDO to allow the
> specification of containment outside of the type definition. You can
> imagine this as providing a set of properties each time a datagraph is
> created. This set of properties would define the containment relation,
> i.e. the tree of data that defines the datagraph.
>
>
> Any ideas about this?
> Is this still inline with the ideas of SDO? Has this kind of requirement
> already been discussed somewhere?
>
>
> Bert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
dynamic containment in datagraphs
Posted by be...@agfa.com.
Hi all,
I've a question on the usage of SDO datagraphs and the role of
containment.
[Background]
In our application suite, we have a large datamodel consisting of several
hundreds of domain classes. Client applications typically want to download
data of a subset of the model. However, the exact definition of this
subset (i.e. which domain classes and which relations) can vary quite a
lot depending on the application and also on configuration. We want to use
SDO to exchange data between client and server.
[Problem]
To exchange data you need datagraphs.
Datagraphs require types that define a containment tree. [I have the
impression that this is in fact the definition of containment.]
Since clients can ask for very different subsets we need different
containment trees.
Containment is an integral part of a type, so we need also different
types. So, we need also different types.
One option is to use different namespaces for each subset. This helps a
bit. However, in our case we would have a huge amount of namespaces. Also
since configuration can change the subset we would also need a kind of
dynamic namespace that is not defined at development time. This is still
kind of feasible, but it is already getting complex. Then there is also
the issue that different namespace means different type, which is also not
that nice.
[Alternative]
What we are thinking of is some kind of extension to SDO to allow the
specification of containment outside of the type definition. You can
imagine this as providing a set of properties each time a datagraph is
created. This set of properties would define the containment relation,
i.e. the tree of data that defines the datagraph.
Any ideas about this?
Is this still inline with the ideas of SDO? Has this kind of requirement
already been discussed somewhere?
Bert
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Tuscany SDO M2 candidate distribution
Posted by kelvin goodson <ke...@gmail.com>.
Thanks Ron,
I'm sorting out the missing jars from the binary distribution now. The
source distro issue is going to take a bit more thinking, as I hadasome
issues with how to build an archive neatly from the way the projects are
organised in svn. I can see your point, and it was my initial intention to
distribute one archive. In discussion with Jeremy we decided upon the 2
part approach. I'll take another look at the issues I encountered and see
if I can see a way to address this.
Regards, Kelvin.
On 23/09/06, Ron Gavlin <rg...@yahoo.com> wrote:
>
> Kelvin,
>
> Thanks for your hard work putting together an RC1 distribution with both
> source and binaries. A few thoughts...
>
> 1. For the binary distribution, I didn't see the sdo tools and plugin
> classes. I would suggest each appear in a separate jar similar to how M1
> was packaged. So, there would be one binary zip with the suite of
> dependent jars plus individual jars for sdo-spec, sdo-impl, sdo-tools,
> and sdo-plugin.
>
> 2. For the source distribution, I found having two files named using
> sdo-impl and sdo-spec confusing. The confusion is due to the fact that
> sdo-impl truly means the sdo-impl component/project for the binary
> distribution but for the source distribution, sdo-impl really means
> sdo-impl + sdo-tools + sdo-plugin. In order to avoid such confusion, I
> would suggest you provide one source zip file containing source for
> sdo-spec, sdo-impl, sdo-tools, and sdo-plugin. I think this is clearer
> and more consistent.
>
> Thanks again,
>
> - Ron
>
> kelvin goodson wrote:
> > I posted a proposal to tuscany-dev a couple of days back
> > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg08105.html
> >
> > So my plan is to crank the handle on SDO Java and when its looking
> > good enough to post release candidates, I'll make them available on
> > people.apache.org/~kelvingoodson as has been done before for our C++
> > releases.
> >
> > Regards, Kelvin.
> >
> > On 21/09/06, Jeremy Boynes <jb...@apache.org> wrote:
> >> On Sep 21, 2006, at 8:32 AM, Ron Gavlin wrote:
> >>
> >> > Kelvin,
> >> >
> >> > Thanks for the update. Do you plan to make a "release candidate"
> >> > source distribution? If so, do you plan to make it in the same time
> >> > frame as the binary one?
> >> >
> >>
> >> I'm not sure what Kelvin is thinking here but for SCA I was not
> >> planning on doing this until we had a real "release candidate" -
> >> defined as being things that we were actually prepared to vote on.
> >>
> >> In the run up to that point I would build SNAPSHOT binary distros
> >> based on "allegedly good" SVN revisions - the corresponding source
> >> distro would be the content of the tree as of that revision.
> >>
> >> --
> >> Jeremy
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
Re: Tuscany SDO M2 candidate distribution
Posted by kelvin goodson <ke...@gmail.com>.
I have just posted to the tuscany-dev mailing list to indicate the
availablity of an RC1a distribution based on your comments Ron, thanks
again.
Regards, Kelvin.
On 23/09/06, Ron Gavlin <rg...@yahoo.com> wrote:
>
> Kelvin,
>
> Thanks for your hard work putting together an RC1 distribution with both
> source and binaries. A few thoughts...
>
> 1. For the binary distribution, I didn't see the sdo tools and plugin
> classes. I would suggest each appear in a separate jar similar to how M1
> was packaged. So, there would be one binary zip with the suite of
> dependent jars plus individual jars for sdo-spec, sdo-impl, sdo-tools,
> and sdo-plugin.
>
> 2. For the source distribution, I found having two files named using
> sdo-impl and sdo-spec confusing. The confusion is due to the fact that
> sdo-impl truly means the sdo-impl component/project for the binary
> distribution but for the source distribution, sdo-impl really means
> sdo-impl + sdo-tools + sdo-plugin. In order to avoid such confusion, I
> would suggest you provide one source zip file containing source for
> sdo-spec, sdo-impl, sdo-tools, and sdo-plugin. I think this is clearer
> and more consistent.
>
> Thanks again,
>
> - Ron
>
> kelvin goodson wrote:
> > I posted a proposal to tuscany-dev a couple of days back
> > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg08105.html
> >
> > So my plan is to crank the handle on SDO Java and when its looking
> > good enough to post release candidates, I'll make them available on
> > people.apache.org/~kelvingoodson as has been done before for our C++
> > releases.
> >
> > Regards, Kelvin.
> >
> > On 21/09/06, Jeremy Boynes <jb...@apache.org> wrote:
> >> On Sep 21, 2006, at 8:32 AM, Ron Gavlin wrote:
> >>
> >> > Kelvin,
> >> >
> >> > Thanks for the update. Do you plan to make a "release candidate"
> >> > source distribution? If so, do you plan to make it in the same time
> >> > frame as the binary one?
> >> >
> >>
> >> I'm not sure what Kelvin is thinking here but for SCA I was not
> >> planning on doing this until we had a real "release candidate" -
> >> defined as being things that we were actually prepared to vote on.
> >>
> >> In the run up to that point I would build SNAPSHOT binary distros
> >> based on "allegedly good" SVN revisions - the corresponding source
> >> distro would be the content of the tree as of that revision.
> >>
> >> --
> >> Jeremy
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
Re: Tuscany SDO M2 candidate distribution
Posted by Ron Gavlin <rg...@yahoo.com>.
Kelvin,
Thanks for your hard work putting together an RC1 distribution with both
source and binaries. A few thoughts...
1. For the binary distribution, I didn't see the sdo tools and plugin
classes. I would suggest each appear in a separate jar similar to how M1
was packaged. So, there would be one binary zip with the suite of
dependent jars plus individual jars for sdo-spec, sdo-impl, sdo-tools,
and sdo-plugin.
2. For the source distribution, I found having two files named using
sdo-impl and sdo-spec confusing. The confusion is due to the fact that
sdo-impl truly means the sdo-impl component/project for the binary
distribution but for the source distribution, sdo-impl really means
sdo-impl + sdo-tools + sdo-plugin. In order to avoid such confusion, I
would suggest you provide one source zip file containing source for
sdo-spec, sdo-impl, sdo-tools, and sdo-plugin. I think this is clearer
and more consistent.
Thanks again,
- Ron
kelvin goodson wrote:
> I posted a proposal to tuscany-dev a couple of days back
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg08105.html
>
> So my plan is to crank the handle on SDO Java and when its looking
> good enough to post release candidates, I'll make them available on
> people.apache.org/~kelvingoodson as has been done before for our C++
> releases.
>
> Regards, Kelvin.
>
> On 21/09/06, Jeremy Boynes <jb...@apache.org> wrote:
>> On Sep 21, 2006, at 8:32 AM, Ron Gavlin wrote:
>>
>> > Kelvin,
>> >
>> > Thanks for the update. Do you plan to make a "release candidate"
>> > source distribution? If so, do you plan to make it in the same time
>> > frame as the binary one?
>> >
>>
>> I'm not sure what Kelvin is thinking here but for SCA I was not
>> planning on doing this until we had a real "release candidate" -
>> defined as being things that we were actually prepared to vote on.
>>
>> In the run up to that point I would build SNAPSHOT binary distros
>> based on "allegedly good" SVN revisions - the corresponding source
>> distro would be the content of the tree as of that revision.
>>
>> --
>> Jeremy
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Tuscany SDO M2 candidate distribution
Posted by kelvin goodson <ke...@gmail.com>.
I posted a proposal to tuscany-dev a couple of days back
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg08105.html
So my plan is to crank the handle on SDO Java and when its looking
good enough to post release candidates, I'll make them available on
people.apache.org/~kelvingoodson as has been done before for our C++
releases.
Regards, Kelvin.
On 21/09/06, Jeremy Boynes <jb...@apache.org> wrote:
> On Sep 21, 2006, at 8:32 AM, Ron Gavlin wrote:
>
> > Kelvin,
> >
> > Thanks for the update. Do you plan to make a "release candidate"
> > source distribution? If so, do you plan to make it in the same time
> > frame as the binary one?
> >
>
> I'm not sure what Kelvin is thinking here but for SCA I was not
> planning on doing this until we had a real "release candidate" -
> defined as being things that we were actually prepared to vote on.
>
> In the run up to that point I would build SNAPSHOT binary distros
> based on "allegedly good" SVN revisions - the corresponding source
> distro would be the content of the tree as of that revision.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Tuscany SDO M2 candidate distribution
Posted by Jeremy Boynes <jb...@apache.org>.
On Sep 21, 2006, at 8:32 AM, Ron Gavlin wrote:
> Kelvin,
>
> Thanks for the update. Do you plan to make a "release candidate"
> source distribution? If so, do you plan to make it in the same time
> frame as the binary one?
>
I'm not sure what Kelvin is thinking here but for SCA I was not
planning on doing this until we had a real "release candidate" -
defined as being things that we were actually prepared to vote on.
In the run up to that point I would build SNAPSHOT binary distros
based on "allegedly good" SVN revisions - the corresponding source
distro would be the content of the tree as of that revision.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Tuscany SDO M2 candidate distribution
Posted by Ron Gavlin <rg...@yahoo.com>.
Kelvin,
Thanks for the update. Do you plan to make a "release candidate" source distribution? If so, do you plan to make it in the same time frame as the binary one?
Thanks,
- Ron
----- Original Message ----
From: kelvin goodson <ke...@gmail.com>
To: tuscany-user@ws.apache.org; Ron Gavlin <rg...@yahoo.com>
Sent: Thursday, September 21, 2006 9:48:24 AM
Subject: Re: Tuscany SDO M2 candidate distribution
Ron,
I'm focussing on this with fervour at the moment, and my plan as it
stood yesterday was to have a release candidate together by COB tomorrow,
however, I'm struggling because of 1) the ASF requirements for a release
are ill defined and 2) my lack of maven knowledge is making some trivial
things take a long time. I'm planning on making use of the knowlege of
colleagues from across the pond as soon as they appear and that should help
things along.
I do plan to make a source distribution, although currently we are only
configured to make binary distributions.
Regards, Kelvin.
On 21/09/06, Ron Gavlin <rg...@yahoo.com> wrote:
>
> Kelvin,
>
> We are interested in testing an SDO M2 release candidate distribution
> (both source and binary). Are you planning to create one? If so, do you have
> a target date for doing so?
>
> Thanks in advance,
>
> - Ron
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Tuscany SDO M2 candidate distribution
Posted by kelvin goodson <ke...@gmail.com>.
Ron,
I'm focussing on this with fervour at the moment, and my plan as it
stood yesterday was to have a release candidate together by COB tomorrow,
however, I'm struggling because of 1) the ASF requirements for a release
are ill defined and 2) my lack of maven knowledge is making some trivial
things take a long time. I'm planning on making use of the knowlege of
colleagues from across the pond as soon as they appear and that should help
things along.
I do plan to make a source distribution, although currently we are only
configured to make binary distributions.
Regards, Kelvin.
On 21/09/06, Ron Gavlin <rg...@yahoo.com> wrote:
>
> Kelvin,
>
> We are interested in testing an SDO M2 release candidate distribution
> (both source and binary). Are you planning to create one? If so, do you have
> a target date for doing so?
>
> Thanks in advance,
>
> - Ron
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>