Added by Justin Deoliveira, last edited by Justin Deoliveira on Jan 24, 2006

Labels

 
(None)

1. Release Update
2. GeoAPI - Feature / Covergage + EMF

<Jody_> (goes to get coffee, they have powdered coffee in this country. Kind of like training wheels on a motorbike...
<jdeolive> anyone have any agenda items
<jdeolive> 1) Release
<bnordgren> feature / emf / coverage
<Jody_> byrce yo ubetter tag in Jesse, although justin here can help w/ the code generation
<jdeolive> i also know my way around emf
<jdeolive> not as well as jesse mind you
<Jody_> and get the book
<Jody_> right agenda - I mostly want to know when 2.2 goes out, or at least goes branch, and when 2.3 goes crazy...
<bnordgren> I really wanted to get a handle on how you perceived the EMF/Feature
<bnordgren> integration? Just use EClass/Object inside GT?
<Jody_> oh dear, I better get that coffee ...
<bnordgren> We ca ntalk at a better time. I just wanted to get the ball rolling.
<Jody_> I am going to think about how to be articulate as they work through the agenda .. do we need to tag in chorner
<Jody_> (for release)
<chorner> M3 or 1.1?
<jdeolive> ok, i am a bit confused, so ...
<jdeolive> 1) Geotools Release 2.2
<jdeolive> last i heard martin was almost ready to go, just wanted permission to change some source tags or something
<jdeolive> last week he showed up a bit late so maybe he will do teh same this week
<jdeolive> does anyone else have anything about release?
<jdeolive> I have one
<Jody_> well is it ready? Martin asked module maintainers to check the blocking items in Jira.
<jdeolive> after we release, do we want to create a 2.2 branch, and go crazy on trunk (I think this was brought up before)
<jdeolive> or do we want to create a 2.3.x branch and merge onto trunk in controlled intervals
<jdeolive> ie expression, then filter, then feature, etc...
<iant_> My only care is that trunk builds most days
<bnordgren> Either way: develop on a branch and merge in a controlled fashion.
<jdeolive> agreed
<Jody_> controlled intervals, but we can only have 2: Expression/Filter and then Feature/FeatureType/Schema
<bnordgren> ...then coverage
<Jody_> byrce depending on your timelines you may want coverage to go first? I have yet to hear specific target dates out of geoserver for the community schema work ...
<bnordgren> End of Feb. coverage should be (better be) wrapped.
<bnordgren> Coverage should depend on Feature/FeatureType, but needs only form,
<bnordgren> not function.
<jdeolive> ok so getting back to release, lets wait to hear from martin
<Jody_> well I think martin is waiting for module maintainers to close their Jira issues (or put them off)
<jdeolive> we pretty much have started on the second
<jdeolive> 2) feature / emf / coverage
<jdeolive> in email?
<Jody_> no in jira, he wants them closed up, moved off, or bugs fixed (just like it was a release)
<jdeolive> no i mean did he ask in email, i have been following his emails and must have missed that
<jdeolive> last i heard he was set to go on RC1
<Jody_> I remember reading it, don't think it was a private email ...
<iant_> can someone give me a quick intro to what EMF is?
<Jody_> EclipseModelingFramework
<Jody_> java interfaces (or XMLSchema, or Object Model ) go in
<Jody_> and java code (very good code) comes out
<Jody_> the good part is it is stable in the face updates, ie wont lose your work.
<Jody_> Working with such a tool is a step towards "model driven design" where changing your
<Jody_> model is actually useful. So you end up doing it.
<bnordgren> (don't forget that you can build a type programmatically, w/o generating code.)
<Jody_> That is true, their "type system" is actually dynamic
<Jody_> almost method for method in agreenment with FeatureType / Feature (simple case)
<Jody_> where we have FeatureType they have EClass, Feature is EObject
<Jody_> getAttribute is eGet and so on
<Jody_> the tricky thing is because they generate code (using something called JET) they can generate out switch statements for the eGet / eSet implementations
<Jody_> so the performance is way better then reflection
<iant_> sounds good
<Jody_> very good
<bnordgren> wayy better than writing it myself.
<Jody_> It is very tempting to throw EMF at the XMLSchemas and let GeoAPI go hang....
<iant_> is there a good reference page I should check out?
<bnordgren> www.eclipse.org/EMF
<Jody_> sort of, I would recommend a book (there is a lot to take in)
<Jody_> byrce you did get a book right?
<bnordgren> oops, I think it's a small "emf"
<bnordgren> (no book yet. Wanted to make sure it was worth it. New edition coming out soon.)
<Jody_> Should also note that EMF (and JET) is not eclipse specific, they are normal java jars one can play with
<Jody_> So let me paint a picture
<Jody_> a motivation beyond bryce not working to hard
<Jody_> In JUMP (yes the evil) it is very easy to get your custom object model on a map
<bnordgren> (hey, that's good enough for me!)
<Jody_> this is something where geotools is horrible
<Jody_> I have tried for a year to get custom Feature instances out of our datastores, we are getting closer but we are not there yet.
<iant_> me too
<Jody_> Now in the case where the custom object model is based on EMF (very likely given how good it is)
<jdeolive> you guys might want to take this up over im if we want to keep the meeting to an hour
<Jody_> we can very quickly implement getAttribute based on eGet and not have to pay a performance overhead...
<Jody_> add in an adapter from EClass to FeatureType are we are good to go.
<Jody_> (that is it justin I am done)
<jdeolive> feel free to continue, no other agenda items, its just you were shaping up for a serious rant
<jdeolive>
<iant_> ok I'm on rhe right page now - I'll try to do some hard reading this week
<bnordgren> Given the adapter, I can roll on coverages. Just need the form to be stable.
<Jody_> Well the best thing you can do (anyone can do) is review the feature model as it lurches into the mainstream
<bnordgren> For more info why I looked at EMF, see my "Feature type" paper on the ISO 19123 page...
<iant_> I need a way to build XIMA docs for geoserver so this might be the way to go
<Jody_> It would be a good long term move for geotools, especially if geoapi balks at getting a new feature model. We would have no more reason to chase down that goal...
<Jody_> however if geoapi is willing to play ball, I would like to see how far they can go (I get more though reviews on geoapi interfaces) and it is nice to share that kind of pain
<jdeolive> i have a question
<jdeolive> could be silly
<jdeolive> but why use emf for geoapi if its all interfaces
<jdeolive> i mean isn't the big win interfaces to code in minutes
<jdeolive> or are we talking about the geotools implementation
<jdeolive> sorry, just been catching up on the email thread between you guys
<bnordgren> they are kinda tied together. THe interfaces specify the capabilities.
<bnordgren> For custom features which have methods, one must extend both
<Jody_> if we had EClass instead of FeatureType it would be very easy for people to generate, and interact with FeatureTypes from a varity of sources
<bnordgren> FeatureType and Feature to ensure that the data and the methods
<Jody_> You can make a EClass directly from an XMLSchema, no java code required (and use it)
<bnordgren> were synchronized. A lot of dumb template code.
<bnordgren> Also, via TC/211, you should be able to serialize the schema
<bnordgren> separately from instance objects.
<Jody_> kinda like WFS DescribefeatureType for schema and getFeatures for features eh?
<CIA-11> 03magnasound * r17710 10udig/community/lavila/plugins/org.cgiar.cip.diva.analysis.SelectRecordsbyQuery/src/org/cgiar/cip/diva/analysis/SelectRecordsbyQuery/SelectRecordsQueryUI.java:
<bnordgren> Yup.
<Jody_> byrce you will always have a hard sell on the ISO standards around here - because we never see them
<bnordgren> Ideally, I want to see custom Feature objects go from UML to GT
<Jody_> If you do want us to play (indeed I would not mind), you (or someone) will need to make interfaces in a venue like geoapi
<bnordgren> with no interaction.)
<Jody_> Kinda the cost of doing open source work, at least geoapi provides a venue
<bnordgren> 19123 is already in pending.
<bnordgren> all we need is implementation.
<Jody_> yes - and thanks
<bnordgren> OGC already straddles "freee" and "not free". It will pr4obably only
<bnordgren> get worse.
<Jody_> agreed
<bnordgren> (martin did 19123. I did squat.: )
<Jody_> in anycase agenda is done - I must sleep. EMF should work out, just ask for help when you get to adapaters (aka they are not listeners)
<bnordgren> Righto.
<jdeolive> alright, does anyone have anything else they want to bring up
<bnordgren> "Corrupt Content Alerts"
<bnordgren> anyone else get them?
<iant_> does anyone know where James logged into to get irc acess from work?
<Jody_> cholmes may know, he uses the same trick
<jdeolive> alright, thanks for the meeting guys

January 2006
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

2.2-RCO (Release Candidate) is Out
IRC Logs January 16th