- David Williams: Y
- Naci Dai: N
- Raghunathan Srinivasan: Y
- Neil Hauge: Y
- Tim deBoer: Y
- Kaloyan Raev: Y
Announcements and General Business
- What about that JPA Diagram Editor!?
Now on track?
Recommend to start "move to Dali" process in January.
Will move to Dali Project (not subproject) and follow social conventions. Seperate feature for packaging. Prereqs Graphiti. Needs to "get up on" JPA 2.0 in months ahead, before Indigo.
- EclipseCon Coordination?
OSGi Enterprise Tools?
(Nitin plans to propose something for JSDT)
Some ideas kicked around. Kaloyan encouraged to submit something about OSGi Enterprise Tools Project ... even if exact content not finalized for month or two. Neil likely to submit tutorial covering JPA 2.0 and JAXB, mabye standalone vs. web app, maybe pull in a web services angle. Via email, Naci likely to propose something to the effect of "using WTP with other Eclipse projects (such as maven)". General agreement that the large "what is and how to use WTP" was getting "old hat".
- Who's to build OSGi Enterprise Tools?
Is it a good candidate for GIT repository?
No firm decisions (or discussions) ... but, leaning towards GIT.
- Can we review that so called "non-standard" part of OSGi
Enterprise Tools? (i.e. educate me :)
Does it "compete" with one of the standards?
Is it just a "defacto" standard (technique) before there were standards?
Non-standard since it depends on a specific run-time container, running on equinox. It did sound like it has "been around" a long time, so to some extent, a defacto standard. Also sounded like (from what I heard) did not "compete" with an OSGi standard (though ... that might be a matter of conceptual debate ... for some people, any alternative, to some extent, competes with people using the standard.). I did emphasize that doing Virgo/Gemini specific stuff does not violate the "vendor neutrality" rules at Eclipse Foundation, since they are part of Eclipse Foundation. (Though, there is a perception that it is "vendor specific". I guess since new, and I guess since primarily one-vendor dominiated projects?). But, for the non-standard "app model" issues, it makes sense to exclude those, since those specs are actively being worked on, and while we want to support the development of the spec, we do not want to prempt the spec with an implementation, that might make it harder to come up with a good spec., or to move to the spec., if its different than a current implementation.
Future Agenda items
- Retrospect Helios quick maintenance release. Does it mean we weren't ready to release? Any way to improve timing in future?
- Disuss our model and assignments of "PMC Roles". Do they still make sense?
Back to meeting list.
Please send any additions or corrections to David Williams.