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

List:       tuscany-user
Subject:    Re: [SDO Java] IRC chat on release contents
From:       "kelvin goodson" <kelvin () thegoodsons ! org ! uk>
Date:       2008-02-08 16:14:21
Message-ID: 9deac9fd0802080814qcf8fdbek851180bbcfdd4a7f () mail ! gmail ! com
[Download RAW message or body]


Thanks for the summary Amita, comments below

On 07/02/2008, Amita Vadhavkar <amita.vadhavkar@gmail.com> wrote:
>
> Please see below complete summary of the IRC chat we had on 4,5,6th Feb.
> The
> next one is as specified in previous response.
>
> There was an IRC chat where me and Kelvin participated on Feb 4th, 5th and
> 6th , 2008
> for SDO Java 1.1-incubating release. Below is the summary.
>
> 1) license files under distribution and sdo-api need to be
> reviewed/corrected
> as well as copyright text fro sources/resources under sdo-api need to be
> reviewed/corrected based on latest from OSOA and based on when the
> source/resource
> files are changed.
>
> 2) SDO Java will follow the same strategy of providing LICENSE files under
> src\main\resources\META-INF as before
>
> 3) http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SDO+Java+Project
> is the place to find all unresolved JIRAs list marked for Java-SDO-next,
> Please see columns"Category" and "Comment" for summary of what was
> discussed
> in IRC.
>
> 4) Went through the list one by one and covered all JIRAs as below- ## are
> the ones which are important, need to discuss in detail on IRC and ML
> and see if can go in this release.
> **********************************************
> must have:-
> 1]1293 - important, patch is available, need to review and apply the
> patch,
> if somebody with OSGI expertise can pitch in, will be very helpful


I don't think this is what I meant to convey.  I'm happy we've had excellent
OSGi skills assisting in the production of this patch,  so I think what's
required is for me to carefully understand all that's been done here and to
apply the patch.

2]1063 - useful - Kelvin
> **********************************************
> nice to have:-
> 3]1862-workaround available in 1842 and no user issues on it so far


I don't think this is a nice to have,  I think it is a defer. Apologies if I
misled,  but there's a workaround in place,  and this sort of issue is an
unresolved topic for discussion in the spec.

4]1838-Amita will check the existing solution against the last comment from
> Ron in ASF JIRA comments - *Note* Please check Amita's comment in JIRA and
> respond.


I took a look at your investigations,  but won't have the time to analyse
them in depth before the IRC chat today.

*Kelvin's comment* If this facility for java serialization requires use of
> the SDOObjectOutputStream, document it in javadoc/website.
> ##5]1021 - + point is it's an omission from the spec, but it needs
> considerable work, important one - check in Friday IRC
> 6]257 - Paul have suggestions, partial fix. Amita need to check it and try
> to get it in the release.
> Resolved------->7]1514 - Amita - ML[das] and reassign comp to sdo-impl ->
> Kelvin will do it - give test case and track which revision(564600) did
> the
> change
> 8]1688 - Kelvin checking with Ron, check EMF fixes and see subclassing
> 9]1689 - similar to 1688 , Ron's comments on 1688, 1689 will be helpful
> 10]1835 - ML to Fuhwei - ask more details,what constraints apply, what
> investigation led to conclusion about "appinfo" - record these details in
> JIRA
> 11]1868 - patch available, test case available - Kelvin will look at it
>
> 12]1659 - linux surefire logs available, can check from that, in Kelvin's
> debian env could not reproduce the problem. if issue is not revealed by
> logs
> alone,
> then time required to recreate will be large.
>
> 13]1831 - Amita will check, looks useful, can have caveats in that once
> you've made something pluggable they might diverge
> and therefore a 3rd party version might rely on implementation details
> that
> are subject to change
> or they might miss out on fixes that we apply to the Tuscany version. If
> we
> made that clear that it was the users repsonsibility to
> take vcaar of these issues, then it sounds like a good commmunity type
> thing
> to do
>
> ##14]761 - check during next IRC-Kevin - put comment in jira if it is
> still
> a requirement-Amita
> what is the memory cost of having to init number of HelperContexts?
> Each one has at constrcution an instance of all HElpers that require to
> manage their own state -- i.e. not CopyHelper or
> EqualityHelper,  but all the others . The state of each of these helpers
> is
> not large until you start registering types
> so i think there would only be significant cost if there were  duplication
> in storage of metadata across typehelpers
> so the problem with multiple HelperContexts would be when loading XML
>
> 15]1182 - get tech findings from kelvin , see if anybody pops up, license
> side is clean, there are other examples of use of this in apache
>
> ##16]1361 - check on next IRC - *Kelvin* , check in IRC, easy, significant
> user impact
>
> 17]1360 -
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26306.html make
> comment in JIRA about both approached and apply 1360-Amita.patch.
> This was all the business where EMF has an issue that it cant handle the
> empty string as a valid enumeration. Make that comment in JIRA and then
> apply the 1360-Amita.patch. Wait for one day for Kelvin's response on ML ,
> i.e. till 7th Feb.


sorry,  didn't get to it.  I'm pretty sure that i was leaning towards your
approach, at least in the short term, because of the EMF deficiency that
surfaces in the more elegant approach.

**********************************************
> next release:-
> 18]1725-the scope is big and better justice can be given in next release,
> test schema is provided but no test code, javajet experience is useful
> here
> 19]1479 - Frank has suggested a workaround. And final solution can be
> supporting "large model" pattern similar to EMF
> 20]1180 - nothing done on spec, the workaround is not to use r/o
> properties
> 21]203 - minor JIRA with workaround and no watchers
> ##22]1002 - kelvin want to check on it in next irc, ideally should be
> resolved. so if time permits try to get it in this release.


this gives mixed messages since it is in the "next release" section.   I
think that's because I'd like to see it done, but can't imagine getting to
it in the short term.

23]1129
> 24]477- defering to see first the spec discussion, also there will be
> performance hit

25]1433 - there will be performance hit
> 26]182 - check with Sebasitien and Frank on ML and mark their responses in
> JIRA comment - Kelvin


I added the SCA Assembly Model component to the JIRA to bring this back on
the SCA radar

27]1817 - too big
> ##28]1038***- talk in next IRC - is imp and major, axis2 databinding
> 29]152 - good new feature
>
> 30]1192 - depends on 2.1.1 spec - more detailed comments -
> what it   requires is a specific list implementation ,so all demand
> created
> open content properties are
> created is-many = true, if you do a getList() on a property using string
> "foo" then a Property is created,
> and it must be referenced by the list, that measn that if the list
> contents
> is one,  then getInstanceProperties
> on the DataObject retursn the Property with name "foo". If the list is
> emptied, then getInstanceProperties does
> not retuen the prop with name foo, and then if the same list has a new
> value
> added to it,  then we still have hold
> of the original Property,  by virtue of the reference held in the list. so
> we woulld get == as true for the Property
> instance returned before and after the emptying of the list
>
> Is this already this way in Tuscany ? - not sure, need to check
>
> This is a clarification that will be in the 2.1.1 spec,  but it  wouldn't
> hurt if it worked that way in our impl
> Kelvin will take a look
>
> What is - alter behaviour such that the demand created property is
> available
> in the applications metadata after the load operation. ?
> What will change after load operation?
> There's a different emphasis there, there may be a mixture of two issues
> here
> We should wait until the 2.1.1 discussions have completed before we
> address
> this
>
> 31]1493 - ongoing discussion with Agfa to discuss how we might absorb some
> of the ways they address SDO issues
>
> 32]1685 - useful new addition
> 33]551 -  useful new addition
>
> "mostly" won't fix - need a confirmation on ML
> 34]67 - there has some work done in this area and JIRA is not clear on the
> particular issue. HelperContext came up after this issue. Some
> work done on DefaultHelperContext to work with thread local context. So,
> discuss and make appropriate comment in JIRA so the 2 watchers will
> get notification if the JIRA is closed as won't fix.
>
> 35]69 - first announce as summary on ML planning to close 67., 69 and then
> if noone objects, do it
> this is the only remaining subtask of 67,  that we decided we would close
> IIRC,  and see if anyone reopens it
> Please responde if there is some objection to close 67 and 69
>
> 36]832->dont close, defer, outside the SDO spec, at serialization the
> graph
> should be closed,and refs outside the closure of graph are broken,
> EMF doesnt have this restriction, and maybe in the future SDO won't,
> Fuhwei
> as acknowleged the fact that this is outside the spec,  and is
> asking for SPIs
>
> 37]1327 - Ask Fuhwei if this is for xsd2java or wsdl2java and mark change
> in
> comp/release, at present is marked Fix Version - SCA release
> 38]1918 - make comment, dont change anything else, has dependency on spec
>
> 39]1932 - mark as sdo next and is nice to have - its not too difficult to
> do,  and has some synergy
>   with the issue of enumeration facets we discussed earlier , lets see if
> anyone wants it on Friday
>
> 40]2014 - possible nice to have - kelvin will put a comment, David is
> looking at it.
> **********************************************
> Appreciate all help in getting all important JIRAs in this release
>
> 5) After Friday's IRC - based on the final discussion - will mark in ASF
> JIRA, the "must have" JIRAs for Java-SDO-1.1, till
> then all  discussed are marked for Fix Version "Java-SDO-Next". Also
> appropriate comments will be appended to JIRAs
>
> 6) Did not discuss any CTS JIRAs are these won't be part of the release.
>
> Kelvin, will you please see if by mistake I have missed any details?
>
> Regards,
> Amita
>
> On Feb 6, 2008 5:07 PM, kelvin goodson <kelvin@thegoodsons.org.uk> wrote:
>
> > Lets confirm this at the suggested time.
> >
> > Kelvin.
> >
> > On 05/02/2008, Jeff Davis <jdavis@hireright.com> wrote:
> > >
> > > The 9AM slot works for me, and I will try to attend.
> > >
> > > jeff
> > >
> > > On Mon, 2008-02-04 at 17:45 +0000, kelvin goodson wrote:
> > > > This is a follow-up invitation for you to influence the current SDO
> > Java
> > > > release content that Amita is managing.  We tried having an IRC slot
> > in
> > > > Amita's "working" day (actually starting at 9:30PM her time; summary
> > > posted
> > > > at [1]),  but didn't get participation,  which may have been due to
> > the
> > > > early start from a US West Coast perspective, so I will host another
> > > session
> > > > on Friday afternoon UK time, precise time to be confirmed,  but I
> > would
> > > > suggest 5PM GMT / 9AM PST.  Please post if you plan to attend,  or
> > would
> > > > attend if the time were different.
> > > >
> > > > I'm cross posting to tuscany-user and tuscany-dev here,  but please
> > > respond
> > > > to tuscany-user only, as I assume all who are subscribed to
> > tuscany-dev
> > > are
> > > > also subscribed to tuscany-user.
> > > >
> > > > We will use the usual Tuscany IRC channel  on server
> irc.freenode.net,
> > > > channel #Tuscany
> > > >
> > > > Kelvin.
> > > >
> > > > [1]
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200802.mbox/browser
> > >
> > > ---------------------------------------------------------------------
> > > 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]