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 2]1063 - useful - Kelvin ********************************************** nice to have:- 3]1862-workaround available in 1842 and no user issues on it so far 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. *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/[EMAIL PROTECTED]/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. ********************************************** 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. 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 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 <[EMAIL PROTECTED]> wrote: > Lets confirm this at the suggested time. > > Kelvin. > > On 05/02/2008, Jeff Davis <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
