IRC Logs June 9th

Agenda:

  1. What is up
  2. Param Proposal
  3. GeoTools 2.5.0 timings
  4. mvn gdal dependency

Action items:

  • Param Proposal accepted
  • We need to plan out GeoTools 2.5.0 release candidate this month (after talking to Eclesia)
  • Simboss will remove the ascii grid dependency from rendering testing

jgarnett: 0) what is up
aaime|dinner: put
aaime|dinner: (sorry,was trying to run putty on my desktop)
jgarnett: jgarnett - getting ready for several udig training courses; helping out everyone and accomplishing nothing
***groldan param proposal, arcsde dispose, arcsde versioning tunning
jgarnett: aaime_dinner: get
jgarnett: (ftp like IRC but slower)
aaime|dinner is now known as aaime
***aaime random bug fixing waiting for the next paid work shower to hit
simboss left the room (quit: Remote closed the connection).
groldan: nex topic?
aaime: yo
jgarnett: 1) param proposal
jgarnett: groldan / gdavis ...
groldan: hi
groldan: http://docs.codehaus.org/display/GEOTOOLS/Extend+DataStoreFactorySpi.Param
groldan: that's the proposal page
groldan: to extend the datastore parameters to hold on more metadata
groldan: like if its a password parameter, etc
jgarnett: review: proposal looks great - thanks for putting up with both me and the geotools process (I feel like both have slowed you down groldan). We need to identify the doc pages to change (gdavis you have some already?) and create a Jira issue ...
jgarnett: but mostly I want both of you to be happy and working together.
aaime: I've quickly scanned thru it and I have a question for each alternative
groldan: shoot
aaime: (can I go?)
aaime: For the first proposal, if isPassword is so important that it warrants a convinience accesso method... why not make it a field?
aaime: (and besides, that method is very NPE prone)
jgarnett: good point; why do we need an access method?
groldan: (yeah, do not take into account the NPE'ness of it
groldan: it'll be coded just fine)
groldan: I'm not sure we really need an access method to be honest
jgarnett: also you probably want to have a hint if the parameter is a credential (and should not be stored in plain text); ie do we need to account for user name?
aaime: For the second proposal, trying to apply Parameter<T> everywhere may make that class more rigid and more brittle
jgarnett: let's remove the method then; less code is easier.
aaime: brittle: over time since it'll try to be more things to more client usages, and
mauricio left the room (quit: Remote closed the connection).
aaime: rigid: once you allow a certain kind of usage you'll be stuck with it
groldan: it'll be just a little more code to clients: ((Boolean)getParameterMetadata(Param.IS_PASSWORD)).booleanValue()
jgarnett: gdavis what do you think? Is the <T> helping at all? I cannot really see how it can help myself ... I suspect a lot of times people will just have a List<Parameter<?>> ...
aaime: groldan, null checks (wink)
groldan: that's a reason for the utility method so
aaime: you'll need a if in all calling points
aaime: any way to embed that specific extraction code inside the param key itself?
groldan: yet, my first idea was to just make it a boolean field
groldan: but using the map just alings in further moving to the common Parameter class
groldan: right?
gdavis_: we use it for Map<Parameter<type>>
aaime: a map of parameters all of the same type? usefulness of it?
jgarnett: um anything wrong with doing a test for Boolean.TRUE.equals( param.metadata.get( IS_PASSWORD) ) ?
jgarnett: aaime++
aaime: jgarnett, good one
jgarnett: gdavis where do you have that Map<Parameter<type>>; aaime may of spotted a bug for us...
gdavis_: ProcessFactory
gdavis_: public Map<String,Parameter<?>> getParameterInfo();
jgarnett: aaime I would be happy with public final Class<?> type; but it does not bother me too much if people want to document their type up front.... what do you think?
aaime: beware of generics, they might bite (wink)
jgarnett: I find that Map<String,Parameter<?>> documents pretty well what is happening.
aaime: (http://www.theserverside.com/news/thread.tss?thread_id=49473)
gdavis_: yah, I dont see any problem with it...
jgarnett: warning on generics is good; but we are stuck with them somehwere - ie public final Class<?> type vs Parameter<?> ..
aaime: sure there is no problem as long as you use them in simple ways
jgarnett: but yeah; we can lose the Parameter<T> if you want.
jgarnett: okay so can we vote on this now? groldan has been waiting weeks...
jgarnett: aaime do you want me to remove the <T> first?
jgarnett: gdavis and groldan you are both happy? that is what my vote depends on ... getting a jira and listing the documentation pages should be done; but I can trust you guys will do that.
aaime: Hmm... tell you the truth, I don't know
groldan: I am
aaime: my readings around the net seem to suggest generics usage is good if you use them sparingly
aaime: and can turn into a nightmare otherwise
aaime: but I really don't have enough expertise on it to have an opinion of my own
gdavis_: sounds good to me
aaime: let's try with a simple test. Is adding the parameter going to spot some bugs for us or not?
jgarnett: it has made our demo code easier to follow
jgarnett: but does not really help anyone in the "dynamic" case ...
jgarnett: so I like the generic from the perspective of writing user docs
jgarnett: but I understand it does not provide any information that is not already there...
aaime: oh well, I raised my concern, if you don't see any problem with it, just keep the param
jgarnett: +1
groldan: I'm obviously a community +1
simboss n=chatzill@89-97-166-106.ip18.fastwebnet.it entered the room.
groldan: anyone else?
gdavis_: +1 from me
gdavis_: if my vote counts (smile)
groldan: it counts as community support, just like mine
groldan: but we need two more psc to decide
aaime: +1
groldan: okay it seems we don't have more pmc around
groldan: simboss are you?
jgarnett: simboss ping? we need you
jgarnett: we may have to drop ianturton; been too long since he has voted.
groldan: I'll update the page with your votes and ask on the ml for more otherwise
groldan: as to keep the meeting going on
jgarnett: thanks
jgarnett: 2) GeoTools 2.5.0 timings
groldan: okay, lets do that, thanks all for your feedback and support
jgarnett: aaime the floor is yours...
aaime: Just trying to look around and see how things are looking for a 2.5.0-rc1 release
aaime: since we'd need to cut 1.7.0-rc1
jgarnett: well I am in a panic
aaime: and I would like to do so before Eclesia hits gt2 with the SE changes (which seem to be massive)
jgarnett: I have a list of technical debt piling up on all sides...
aaime: Hmm... anything new we did not have when we released 2.4.0^
jgarnett: .. I am less woried about Eclesia's changes; but I agree we had one goal for 2.5 - and that was feature model. it is time to cut a release.
simboss: jgarnett
aaime: jgarnett, I am because when it hits, it may destabilize for some time rendering
simboss: fighting with the internet connection (smile)
aaime: GeoServer cannot enter RC with that change on the radar
jgarnett: aaime - the feature collection side seems to have gotten more complicated - even since 2.4.0. I wish jdeolive would go ahead with his proposal to clean up feature collection.
groldan: buf, that'd be awesome
aaime: I did not notice any worsening (if worsening was possible at all)
jgarnett: agreed; aaime there is no way we can accept a massive change right now; eclesia would have to wait on a branch until we get to RC status
aaime: yep, but afaik he need to complete that work within one month
jgarnett: I see; well since he is not at a meeting; and is having trouble emailing it is very kind of you to speak for him
aaime: I'd prefer to find a solution that suits all our needs instead of starting a fight
jgarnett: (and helpful for planning)
jgarnett: yep
jgarnett: okay; so we should do two things:
jgarnett: a) set a target at one month
jgarnett: b) check with eclesia about that target; is it good enough for him ...
jgarnett: is a month a good timeline for a RC as far as geoserver is concerned?
groldan: hmmm... two weeks after the code sprint...
aaime: officially, we had to cut 1.7.0-rc1 by the end of this week... unfortunately I'm not able to discuss this with the gs pmc
groldan: or so
aaime: since the gs-devel ml is not receiving mails...
jgarnett: It would be nice from a udig standpoint; I mostly want to test raster symbolizer support and fix up a few feature type building issues - but udig is very happy to be on trunk again.
aaime: jgarnett, the new UI will be on the 2.0.x series
aaime: that's why we'd need to cut the rc before the sprint
jgarnett: aaime; I understand. and to start on that you kind of need 1.7 to fork off prior?
jgarnett: can geoserver 1.7.x and geoserver trunk both track geotools trunk for a little bit?
aaime: Uh?
simboss: guys quick stupid question, where is the proposal page for eclesia's work?
jgarnett: ie is the deadline 1 month for eclesia; and 1 week for geoserver?
jgarnett: he just wrote it recently
ggesquiere n=gesquier@arl13-3-88-169-136-131.fbx.proxad.net entered the room.
aaime: jgannett, yes, it could be possible, thought I'm scared by the possibilities of someone breaking solid some code
jgarnett: it is not complete yet; I think we have all been asking him ...
jgarnett: http://docs.codehaus.org/display/GEOTOOLS/Upgrading+styles
aaime: I mean, when you cut a "stable" release you make a clear statement that no major experiments need to go on
simboss: so let me recap, we know that there 1 month deadline, but we don't even have a proposal page for the work? nice! (smile)
jgarnett: note I am much happier with that page; then the work that has been happening on geoapi. I think this page represents progress and communication.
aaime: guys, I believe he has a 1 month deadling, I'm not certain
jgarnett: okay; thanks aaime ... and simboss.
jgarnett: I am more worried about geoserver plans right now; since we have aaime here to speak for them.
aaime: jgarnett, yeah, I don't have a solid story here
aaime: because we still lack at least one proposal and one relatively big change in gt2
aaime: the wicket ui proposal for gs
aaime: and the feature speedup code in gt
jgarnett: lets just treat eclesia's work as starting out; and he will talk to us about planning once his proposal page is ready ... a proposal being ready gives us a two week window for planning. And it is not the worst thing in the world if he wants to get organized before talking to us...
jgarnett: okay so we have a solid bit of gt work? ie feature speedup code in gt?
aaime: we yes, we do not want to release gs 1.7.0 much slower than 1.6.x, you know
aaime: but I don't know how far jdeolive is with it
jgarnett: so it sounds like we cannot make a decision today; but we can talk informally ... it is good to know what geoserver needs as part of a 2.5.RC
jgarnett: I talked to jdeolive and he implemented a "fast" feature.
aaime: yeah, that's why I wanted to talk about it, to gather some impressions, opinions
jgarnett: but most of the time was spent in some very slow / correct validation code in SimpleFeatureTypeBuilder; we are going to need to turn that puppy off.
jgarnett: We only put that validation check in there as a sanity check during the transition; it is now time to take off the training wheels.
aaime: anyways, that would be it for me
jgarnett: So I am not sure I expect change proposals for this work; just responsible development.
aaime: I don't see any major negative reaction and I'm releaved... now if only I could organise a talk in gs land...
jgarnett: ie; the api is holding up; we have testing and performance to do.
aaime: jgarnett, correct, no api change, no proposal need
jgarnett: okay; for our planning we will expect a branch / RC in a matter of weeks (depending on how we can serve you and eclesia)
jgarnett: cool. if you are happy we can move on.
aaime: yep
jgarnett: 3) mvn gdal dependency
jgarnett: okay this one is me...
jgarnett: thanks to everyone for taking part in a difficult email thread.
jgarnett: I wanted to ask if the technical issue (ie a dependency in renderer that shoudl not be there) has been resolved?
simboss: to be honest the main technical issue here
simboss: was the lack of knowledge of the topic from the people who started the mailing thread
jgarnett: (going to run mvn dependency:tree in rendering and see for myself)
simboss: since there was/is no gdal dependency
jgarnett: okay so this is a education / communication problem rather than a technical one?
simboss: the only problem, if we really want to find one
simboss: is that the rastersymbolizer work
simboss: uses in its tests
simboss: I repeat, in its tests,
simboss: the asciigrid imagereader from imageio-ext
simboss: to read a small esri ascii grid
aaime: we have two problems afaik, one is that the dependency to arcgrid is not using test scope as it should, the other is that the same dep is a snapshot
simboss: we are going to take two actions
simboss: (yep)
simboss: 1> give the dependency test scope
simboss: daniele already did this
simboss: 2> next week I will spend a few hours on converting the asci grid to a rw file
simboss: so that we don't need to depdend on anything
jgarnett: got it
simboss: but again, I would ask people to check thing before generating confusion
simboss: since this is not the first time that I see
simboss: and I found it
simboss: at least strange
simboss: this minor issue with asciigrid
simboss: has nothing to do with gdal
simboss: or any native dependencies
jgarnett: okay thank you both for updating me on this.
jgarnett: I am sure that I have lept to conclusions myself; so I am not going to be too grumpy.
jgarnett: thanks for taking the time to resolve this; and to eclesia for noticing the problem.
jgarnett: that should be it for the meeting?
aaime: yep
jgarnett: thanks muchy; I will post.
jgarnett: and we ended on time.
groldan: cool, bye all
jgarnett: simboss we missed your vote on the param proposal above.
simboss: sorry about that
jgarnett: if you could look at the page and bug groldan if you have questions? we need your vote to continue.
groldan: simboss http://docs.codehaus.org/display/GEOTOOLS/Extend+DataStoreFactorySpi.Param
simboss: do you have a quick link
simboss: ah great (smile)
groldan: it'd be kind if you could
aaime: jgarnett, I missed a bit there... which alternative did we choose? (wink)
groldan: 1 for 2.4.x
groldan: 2 for trunk
aaime: ah

IRC Logs June 2

0) what is up
1) update headers
2) DataStoreFactory.Param for passwords

acuster: btw, jgarnett medii decided to contribute under the umbrella of Geomatys
acuster: he decided signing an aggreement was way too much work, the slacker
jgarnett: yeah I saw that on email; thanks.
jgarnett: so agenda is open for another couple minuets; what do people want to talk about today?
acuster: java 7!
***acuster has been watching google tech talks
jgarnett: (I remember some topics from the geoserver meeting being aimed at the geotools code base ...)
jgarnett: but mostly last week was build hell around these parts.
acuster: looks like the File tools are going to be great
acuster: copy/move/symlinks...
jgarnett: .. cannot find links to last weeks IRC meeting for geoserver (sigh)
acuster: shall we get this over with?
jgarnett: yep
jgarnett: 0) what is up
vheurteaux left the room.
***dwins links to last weeks GeoServer meeting log: <dwinslow> Do we need to have GeoServer generate the super-overlays itself, or is it safe to assume we can rely on GWC for creating parent documents that link the proper tiles?
dwins: http://geoserver.org/display/GEOS/2008/05/27
acuster: acuster — learning how to code 101, setting up a system for geometries
***dwins learns the difference between shift+insert and middle click (tongue)
jgarnett: jgarnett - sorting out feature events (I wish Feature actually had a FeatureId rather than a string!), we are down to daily uDig 1.1 releases, and then I have my day job.
vheurteaux n=vheurtea@85.170.87.197 entered the room.
gdavis_: gdavis: still working on WPS module and tweaking the XSD/bing stuff for WPS. With the recent xsd module name fixes I can now work on getting the gt-wps module committed (in unsupported)
jgarnett: Right the idea was to let DataStoreFactory.Param subclass for passwords; groldan did you want to grab a agenda topic for that?
groldan: right
acuster: desruisseaux---waiting for his computer to reach its breakpoint
acuster: the poor man won't leave his aging laptop
groldan has changed the topic to: 0) What's up? 1) update headers 2) DataStoreFactory.Param for passwords
groldan: done (smile)
jgarnett: okay lets get this party started....
jgarnett: 1) update headers
jgarnett: I am hoping acuster? Or someone? has good news for us in the form of a script.
acuster: not quite yet
jgarnett: (my hopes are dashed!)
acuster: we are hammering it out, cedric keeps getting more sophisticated and then chases down bugs
acuster: we're trying to keep it more broadly useable
acuster: i.e. in english
acuster: so sometime this week it should chew through metadata and referencing
acuster: I'd like to commit all these scripts /helper classes
acuster: to the svn
acuster: for example in some utility directory in build/ or some such
acuster: any objections to that?
jgarnett: sounds fine; but
acuster: e.g. the svndumpfilter scripts
jgarnett: I don't want to be too distracted getting a perfect script; ie a search and replace in eclipse followed by a manual check would also work.
jgarnett: (ie results matter, and a manual check is still needed right?)
acuster: yes
acuster: we have some more serious constraints on this end
acuster: i.e. Martin wants his name written out just exactly so
acuster: with little flowers all around it
acuster: no, seriously it should be soon
acuster: I'll post it tomorrow and you can hack it in another direction for your needs
acuster: (or at least test what works/doesn't work for you)
acuster: anything else?
desruisseaux: Jody: Search and replace doesn't work.
desruisseaux: The work to done is a little bit more complex than that.
desruisseaux: But Cédric is almost done.
wolf i=woberghe@hoas-fe35dd00-150.dhcp.inet.fi entered the room.
jgarnett: deruisseaux; you are correct; it only does 70% of the work.
jgarnett: or perhaps less?
acuster: we want to get warnings when wierd things are encountered
jgarnett: okay; so in terms of project planning we wanted to get done by now so we could put ourselves up for graduation at the next board meeting right?
acuster: ah, indeed
***acuster goes looking for the script as is
jgarnett: acuster++ yeah I can see how that would be good; it would save some time on the manual check ... but the idea is to do the manual check (updating the headers before the manual check is fine, but the manual check is still needed)
desruisseaux: Jody, it does less than 70% of the work. I wanted the script to take in account the dates in the (C) statements and move the copyright holders as @author when they are not already there.
jgarnett: okay for me I can just stay tuned for email; and we will miss out on graduating this month.
acuster: http://pastebin.stonekeep.com/3254
jgarnett: I would like to get the core library and plugins sorted; and then start the gradudation process.
acuster: when is the meeting?
jgarnett: I will check; or someone can ask on #osgeo channel
jgarnett: http://wiki.osgeo.org/wiki/Board_of_Directors
jgarnett: June 6th
acuster: yeah, not for this month
acuster: first day of summer was our fallback deadline
jgarnett: On a related note I am "mentor" for Deegree and they are going to finish in a couple of weeks.
acuster: poor Cameron who wanted us done in 3months
jgarnett: moving on?
jgarnett: 2) DataStoreFactory.Param
jgarnett: groldan this one is yours...
groldan: hi, take this as background http://jira.codehaus.org/browse/GEOS-1793
groldan: the thing is, we need a way to identify a datastore param that holds a password
groldan: so the configuration system can store it encrypted, not show it up on ui's as clear text, etc
groldan: and the less friction path seems to be just to add a "password" field to DataStore.Param
jgarnett: This is the same problem we have in the unsupported/process API; ie tell me some more details about this parameter so I can treat it correctly.
groldan: DataStoreFactory.Param, I mean
jgarnett: groldan can you review the approach here: http://svn.geotools.org/trunk/modules/unsupported/process/src/main/java/org/geotools/process/Parameter.java
groldan: the Map?
jgarnett: I would not mind moving this interface into wider use; and making DataStoreFactorySPI.Param extend it.
jgarnett: combo of Map + document keys
groldan: and what about 2.4.x
acuster: yeah, we should never store passwords, at least not until we have a serious security system in place
jgarnett: And what about 2.4.x? Why not add the Map there; you are breaking API so you may as well break API in a way that is method compatible with "the future" ?
groldan: jgarnett: I don't quite see why the same parameter object shall be used for the process and datastore api
jgarnett: because they are both the same design; ie
jgarnett: lets document what the keys mean when the user interface gives us them.
jgarnett: In both cases we need enough information to make "widgets" on screen to communicate with the user...
jgarnett: Note you can do what you need right now just by "handling" the text and parse and toString methods...
groldan: hmmm.. wonder about loosing cohesion too
groldan: and would you be doing this on 2.4.x too?
jgarnett: DataStoreFactorySpi.Param.text is human readable? DataStoreFactorySpi.Param.parse( text ) converts it to the internal representation. This is what we did for geoserver to "prevent" the need for extra flags describing what the data was for...
groldan: I don't want to do one thiing on the branch and another on trunk
jgarnett: so you have a choice right?
groldan: so you're suggesting parse(text) and text() to take the responsibility of encrypting and decrypting?
jgarnett: a) use parse, text, toString methods (ie stick with the current plan for geoserver)
jgarnett: b) add a field isPassword?
jgarnett: c) add a Map allowing isPassword, isHidden, isASmallFish etc...
jgarnett: you can review if (a) works for you ...
groldan: I don't think they text() and parse() should do so, will we put pluggable cryptography algorithms on it?
jgarnett: if not (given a choice between (b) and (c) ) I ask you to consider (c) in order to match what we are doing for WPS
sfarber left the room.
jgarnett: note you probably want to "encrypt" username and password; so you are not talking a single isPassword flag right?
groldan: hmmm you're increasing the scope of this
groldan: Param already has a lot of fields, most of the time with defaults
groldan: if we go with c)
jgarnett: I am sick of people saying that (sad) I am trying to explore your problem with you ... trying to see a solution that will last us more than a couple minuets ...
groldan: where you put that Param class? un org.geotools.util?
jgarnett: I have had that feedback a couple times now; I don't mind that we are all on deadlines ... but really?
groldan: I understand Jody, I'm wondering if c) is good enough though
jgarnett: groldan you are right; we don't know if (c) is good enough
jgarnett: we did do a bunch of experiments for WPS on this topic
jgarnett: tried out java beans etc...
jgarnett: but to proof is in the pudding and WPS has not shipped yet.
groldan: for example, then we'll have to configure community schema related datastores, which have a lot more configuration than Param can handle
jgarnett: Where is DataAccess.Param now? Can we take it out as a seperate class called Parameter?
groldan: I need something that works both for trunk and 2.4.x
jgarnett: good question ...
jgarnett: For community schema one of your parameters is going to be an rather interesting complete object (say DataMappings) I would hope? But I doubt you will be able to reduce it to a single String anymore. Ie parse and text methods would also fail you?
groldan: exactly
groldan: right now there's a single param poiting to a mappings file
groldan: that could well keep being like this
groldan: or people may start needing more flexibility (you tried java beans already, for example)
jgarnett: so how does this solution not work on 2.4.x? Take DataStoreFactory.Param and rather than (b) add a boolean isCredential field choose (c) add a filed metadata of type Map
groldan: as said last week on the geoserver meeting, I could either go for an extra boolean field or for a metadata Map
groldan: inside DataAccessFactory.Param
jgarnett: note if you add them as methods; isPassword() and isUser() you can be forward compatible with a Map metadata solution.
jgarnett: okay so you will write up a proposal on this then Gabriel?
groldan: and that's all the flexibility I need
groldan: does it need a proposal?
jgarnett: and we can talk about this without wasting IRC time...
jgarnett: it is an API change; with intergration concerns for WPS work
jgarnett: basically we want to reuse any and all user interface code we make based on parameter / conneciton handling.
jgarnett: so you are exposed to a lot of requirements; so proposal all the way..
groldan: I'm really hesitant of spending two more weeks on deciding this
groldan: to be honest
groldan: but ok
jgarnett: so decide; and write up a proposal so we can approve it?
jgarnett: it is not like you can just patch this gabriel; it is an API change .
groldan: understood, really
jgarnett: but I agree if this takes two weeks to decide we are doing it wrong; I am sorry you did not have a proposal for todays meeting (I thought you were on it after last weeks geoserver meeting?)
rraffin n=RomainRa@lns-bzn-51f-62-147-196-37.adsl.proxad.net entered the room.
groldan: me too, apologies about that, too much grief with arcsde
rraffin left the room ("$> wall ciao").
jgarnett: yeah; me 2
jgarnett: that is it for agenda topics ... shall we end early?
groldan: ok for me
jgarnett: I will post the logs...

IRC Logs for May 26

Agenda:
0) what is up
1) commit access for Lucus
2) switch to JSR-275 for Units support
3) hg repo of trunk
4) header cleanup phase I
5) iso 19108 temporal support

jgarnett: meeting time (smile)
jgarnett has changed the topic to: 0) what is up
gdavis_: topic: get commit access for lreed who is helping me with the process related work
jgarnett has changed the topic to: 0) what is up 2) commit access
desruisseaux has changed the topic to: 0) what is up 1) commit access 2) switch from JSR-108 to JSR-275
acuster has changed the topic to: 0) what is up 1) commit access 2) switch from JSR-108 to JSR-275 3) hg repo of trunk
jgarnett: acuster++
acuster: http://hg.geomatys.fr/cgi-bin/hgwebdir.cgi
acuster: http://hg.geomatys.fr/cgi-bin/hgwebdir.cgi/geotools/trunk is up to date
acuster: all the others are in transition
acuster has changed the topic to: 0) what is up 1) commit access 2) switch from JSR-108 to JSR-275 3) hg repo of trunk 4) Header cleanup, phase I
acuster: shall we?
desruisseaux: Topic 0) Whats up
desruisseaux: Martin: looks like I'm about to finish org.geotools.image.io.mosaic at last.
gdavis_: gdavis: working away at wps module (still not committed)
jgarnett: jgarnett: balancing a couple udig projects (yeah training more people), helping wps work along; and wonder when SE1.1 will hit geoapi mailing list in earnest
acuster: acuster: getting deeper into geometry, lots of open questions there; hg repo looks like it will work
jgarnett: 1) commit access
jgarnett: gdavis this one is yours...
gdavis_: yes
gdavis_: I'd like to get commit access for lreed
gdavis_: who is helping me with the process/wps work
gdavis_: he would be committing to the wps xsd/beans modules
gdavis_: and the wps module
gdavis_: which shouldn't affect anything else
gdavis_: do I need to send any kind of formal email or anything for this?
acuster: surely jody's magical developer's guide has the answer to that one
aaime: Hi
aaime: I believe we don't have anything about this case in the dev guide
jgarnett: I think cameron wrote the first draft of the developers guide; I am hoping for a magical user guide.
jgarnett: we have the "PMC member approval" to start an unsupported module; perhaps the same deal will work for adding a developer to an unsupported module?
aaime: seems sensible to me
aaime: thought it's not the same
aaime: it's the closest we have
gdavis_: so what do I need to do then?
aaime: zzzzz....
acuster: ask jody for the nod,
gdavis_: ok
acuster: get mr reed? to sign the contributor agreement
acuster: ask the refractions admin to make the account
acuster: next? martin?
gdavis_: thnx
desruisseaux: JSR-275
desruisseaux: I can performs the switch this week
acuster: (as you can see we make up the rules as we go along)
desruisseaux: (or next week)
desruisseaux: Can I process?
desruisseaux: It will be incompatible change for anyone using javax.units
desruisseaux: It is actually quite a significant change.
desruisseaux: I guess that those who don't use directly javax.units will not be affected.
desruisseaux: The steps would be
jgarnett: (aside: gdavis can you get the nod from someone other than me, want approval to be clear, if you can also have Lucus ask on the email list we will have a record of the exchange. The big thing is to have read the developers guide and understand how not to break the build)
desruisseaux: 1) Make the change on GeoAPI
desruisseaux: 2) Reflect the change in GeoTools implementation.
desruisseaux: So any objection if I process this week?
jgarnett: Sounds great
desruisseaux: (I will send an email on the mailing list if nobody object on this IRC)
jgarnett: as someone who has done this experiment on a branch I am very confident in the result.
jgarnett: 3) update the user guide
jgarnett: (ie please don't forget documentation...)
desruisseaux: Yes (I always forget the user guide...)
desruisseaux: Objections?
desruisseaux: Counting to 3...
desruisseaux: 1
desruisseaux: 2....
desruisseaux: 3....
desruisseaux: Okay I will send an email.
jgarnett: send the email and we will try and vote on it promptly.
desruisseaux: Thanks (smile)
jgarnett: 3) hg repo of trunk
aaime: what changes are we talking about?
desruisseaux: (will do)
aaime: (sorry to be slow)
jgarnett: acuster this sounds like you ...
jgarnett: aaime the JSR-108 units package is old and dead and we are the only project still using it
desruisseaux: Andrea: the switch from the withdrawns JSR-108 to the JSR-275 (its replacement)
jgarnett: JSR-275 is kind of like JScience without the political baggage (and just focused on less scope)
jgarnett: So the definition of Unit and Measure classes.
aaime: Ok
acuster: jsr-275 has both units (the names of the sizes) and other richer structures such as measures( a unit + a value)
jgarnett: It was one of those things that had to wait until Java 5... and it is really nice to work with.
desruisseaux: It is a significant changes for anyone using javax.units. Those who don't use thies classes should not be affected.
jgarnett: (I think it is the only JSR-XXX code contribution I have liked since Java 1.4)
simboss n=chatzill@host204-206-dynamic.36-79-r.retail.telecomitalia.it entered the room.
acuster: simboss do you use javax.units?
simboss: ciao acuster
acuster: going once, twice, ....
simboss: it should be used in some of the gridcoverage plugins
acuster: 3) hg repo: There's a new repo conversion of geotools here: http://hg.geomatys.fr/cgi-bin/hgwebdir.cgi/geotools/trunk/
acuster: hg clone http://hg.geomatys.fr/cgi-bin/hgwebdir.cgi/geotools/trunk/ trunk should get it on anyone's disk if they want it
jgarnett: not sure I understand acuster
jgarnett: what is hg
acuster: a similar clone is coming for geoapi
acuster: mercurial
acuster: also you can look at the changes with colored diffs
jgarnett: http://en.wikipedia.org/wiki/Mercurial_(software)
acuster: the addresses will be cleaned up when we get the time
jgarnett: so is this a fork? or just a nice way to look at svn?
acuster: every step is a fork
desruisseaux: It is synchronized on GeoTools SVN.
acuster: actually I'm doing it mostly to work on geometry
acuster: I expect I'll break geoapi
jgarnett: you saw that gdavis does not mind if gt-geometry goes back to unsupported...
acuster: so I can have a 'public' geoapi that will not be 2.5-SNAPSHOT
desruisseaux: It is a mirror of GeoTools SVN synchronized every hours which allow Mercurial users to get the sourcE.
acuster: but yeah, that trunk won't get any changes to it
acuster: it's upstream
acuster: just for fun/instruction/learning about distributed revisionning
jgarnett: okay
simboss: I would like to add an item for iso19108
jgarnett: I worry about us starting to fork off as individual teams again
desruisseaux: Just to repeat myself: it is a mirror of Geotools SVN, not a fork.
jgarnett: it was a long hard year when simboss was off on a branch and I don't want to repeate the experience if we can avoid it.
jgarnett has changed the topic to: 0) what is up 1) commit access 2) switch from JSR-108 to JSR-275 3) hg repo of trunk 4) Header cleanup, phase I 5) iso19108
acuster: 4) Header cleanup
acuster: Cedric has a java class that looks for issues and resolves some of them
jgarnett: So can we run a script? and get 90% of the way there ...
acuster: I expect that we'll start on metadata/referencing later this week
acuster: paying pretty close attention to what's going on
acuster: to make sure the script is well behavedd
acuster: I've changed the script header to Geotools – An Open from Geotools – The Open
acuster: I know Jody prefered the rightmost
acuster: apparently James Macgill preferred the less aggressive "an'
acuster: I don't really care much if someone feels strongly
jgarnett: I only care that it is "GeoTools" not Geotools
acuster: oh, good
jgarnett: I think we voted on the tag at some point before SF ate our project history
acuster: I had thought the other was the way
simboss: I think we de-facto "the" toolkit
simboss: we are
acuster: yeah, so no need to claim to be
jgarnett: The logo on our web page says: GeoTools - The open source Java GIS toolkit
acuster: okay, hands up then: Vote is "I like and want to keep "The" "
acuster: acuster: -0
jgarnett: +1 I like it nice and strong and confident (wink)
simboss: +1
aaime: +0
desruisseaux: I prefer "an"...
desruisseaux: Well, count me +0
acuster: "The" wins!
desruisseaux: (or 0 without the + actually)
acuster: unopposed
acuster: I'm done, next?
simboss: iso19108
desruisseaux: One of our guy has implemented the majority of interfaces
desruisseaux: (well, I didn't had the time to look at them yet)
desruisseaux: (which is why we didn't proposed to commit them)
desruisseaux: In my mind, ISO 19108 is pretty close to referencing.
simboss: it must be(smile)
jgarnett: um I fall asleep when ISO is mentioned; can someone remind me what ISO 19108 is about? Is this the time thing...
desruisseaux: It is not accidental that we groupped them int the "referencing" in GeoAPI.
simboss: temporal
desruisseaux: http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/temporal/package-summary.html
simboss: I agree martin, that's why I asked alessio to stop and tell the mailing list
desruisseaux: I can ask Mehdi to commit in some "spike" or "unsupported" directory if peoples wish...
aaime: if that helps collaboration I have no problems with that
simboss: well, we pretty much need this in place, the un/marshalling part can wait a bit
jgarnett: Is there any overlap with Joda time? Or is this our own thing ...
desruisseaux: So you suggest to commit the classes without the jaxb part?
simboss: so alessio can hold a couple of days for this committ and then we can try to coordinate
simboss: well, alessio started to implement this wrapping joda time
simboss: (which was my next question)
simboss: but as I understand you guys hae been using only date-time
simboss: do yuo feel confident about that?
desruisseaux: We want on date/time only for now. It is not a definitive decision. We expect to revisit that when Joda will be bundled in the JDK (which is planed).
desruisseaux: But we though that introducing new dependencies close to the referencing level would be a sensitive issue.
simboss: it is not definitive but it can be a strong decision at least for the moment
simboss: it is going to pass some time before jdk 1.0 goes mainstream for JEE
aaime: jdk 1.0 (smile)
simboss: ops
desruisseaux: I have not looked at the code yet, so I don't know the amount of overlaps with Joda. If it appears that Data/Calendar/DateFormat can do the work for now, then I'm tempted to try.
simboss: 1-7
desruisseaux: Keeping in mind that we will change anyway.
jgarnett: Joda is being written up as a formal JSR is it not?
desruisseaux: Yes
desruisseaux: JSR-310
desruisseaux: (if my memory serve me right)
simboss: (I'll go have a deep look afterward)
desruisseaux: But class names, packages, etc. are not the same.
aaime: the "trouble" is that Joda is... what, an extra 500kb dep?
desruisseaux: There is also slight API difference.
simboss: well, let's put it this way
jgarnett: Martin so far it is mostly you who perfers waiting for JSRs; I have found java code growth the be crazy in recent years; lost all repsect for them with log4j was skipped.
simboss: if there is a considerable amount of work already done using date-time-calendar
simboss: I think it make sense to leverage on that for the moment
simboss: without reimplement from scratch using joda
simboss: but still I think it might be worth to check anyway
desruisseaux: I'm not sure that it involve that much reimplementation. We need to look at the code
desruisseaux: (I haven't)
desruisseaux: ISO 19108 is mostly about TemporalReferenceSystem
desruisseaux: There is slight overlaps with Joda, but maybe not that much.
desruisseaux: Given that Mehdi has already finished an implementation on top of Calendar, I would like to start with that.
simboss: np
desruisseaux: Then we could looks in that code if there is any stuff not suffisient
desruisseaux: or we can try to quantify the amount of work that could be delegated to Joda.
simboss: np
simboss: alessio and daniele have scheduled some time to work on that anyway
desruisseaux: Okay
simboss: hence if we think that it might be worth moving to joda right away
simboss: we can do that and then you can
simboss: do a code review
desruisseaux: Well, if using Calendar for implementing ISO 19108 implies 20 kb of code, it may be worth to keep this approach compared to add a 500 kb dependencies. But if the amount of duplicated code is more like 200 kb, then this is an other story.
desruisseaux: We will see
desruisseaux: I'm done...
jgarnett: so can we expect a proposal one way or another as agreement / experimentation occurs on the mailing list?
desruisseaux: I will ask Mehdi to write one tomorrow.
jgarnett: thanks muchly
simboss: well, I am pretty much opne to anything here
jgarnett: that is probably it for the meeting; thanks for ending on time everyone.
simboss: so yeah, you have the floor now on this
desruisseaux: thanks (smile)
simboss: to trigger the discussion/work
simboss: ah btw
simboss: I finally had some time to look at the equal/hash classes vs HashUtil
simboss: I preferred to remove the two classes
simboss: and to use Utilities
simboss: since the most interesting methods are already there
simboss: one annotation though, should we provide an intial seed for hashcoding simple fields?
simboss: like a nice prime number?
desruisseaux: Usually I try to use a initial seed different for each class.
desruisseaux: (increase the chance that "empty" instances of different classes do not collide)
jgarnett: (sad I thought of another topic)
jgarnett: Is there any interest in figuring out what happened with jaxb?
desruisseaux: I often use the (int) serialversionUID just because my brain is not a good random number generator.
aaime: I believe jdeolive is trying to get rid of jaxb deps from his modules
simboss: does the javadocs state something about this?
aaime: by reusing some of the jaxme classes and putting them in a custom made jar
simboss: jusr for users
simboss: ?
desruisseaux: I'm not sure, but I can add that.
jgarnett: yeah it is an odd thing; it is like we need our dummy jax-b module to be "provided" but then eclipse does not really recognize that and we get conflicts...
desruisseaux: (starting NetBeans...)
jgarnett: As I understand the jaxb classes were used for this same topic (ie understanding dates)
aaime: jgarnett, correct
acuster: what was the deal? he was using jaxb but not using it at the same time?
aaime: parsing and encoding date/time/blah in the format used by XML
aaime: acuster, not for parsing
aaime: not for encoding
aaime: just as a way to get proper date handling afaik
aaime: the actual parsing/encoding is Eclipse XSD + custom code
jgarnett: acuster there was no difference btween the compile and runtime env. in eclipse. So he ended up with both classes on the classpath when parsing... and got tripped up.
***jdeolive is catching up
jdeolive: yes, i am having to remove the jaxb dependencies which is a pretty big pain
jdeolive: but i am left with little choice
acuster: so it was used during compile but can't be used at runtime?
desruisseaux: Just a slight note about hash: I inversed the argument order compared to HashcodeUtil in the hope to make more readable chained call for those who want. Eg: hash(field1, hash(field2, hash(field3, initialSeed))) compared to hash(hash(hash(initialSeed, field1), field2), field3). Well, not sure it is really more readable, but anyway putting the seed last allow us to make it an optional argument...
desruisseaux: ...if we override the hash methods with flavors without seeds.
aaime: acuster, in Eclipse compile/test/runtime classpath are one
simboss: desruisseaux
simboss: that's the approach i was going to take in thos two classes
desruisseaux: I think that Adrian has been able to get Eclipse running the test with some classpath settings in the IDE?
simboss: i.e. using overridden methods with empty seed
simboss: no seed
aaime: desriusseaux, yes, but you have to redo the whole process of fixing the classpath manually after every mvn eclipse:eclipse
jdeolive: yeah that works but its hardly optimal
aaime: change a single dep in a pom and you're screwed
jdeolive: plus you have to do it for every test configuration
desruisseaux: It leads me to an other proposal (maybe longer plan). What about breaking the build in 2 or 3 parts, rather than building the whole GeoTools project in one bunch? It is becoming bigger and bigger...
acuster: yeah, that would suck
desruisseaux: If there is a build focusing on metadata + referencing + epsg plugins for example, it would be easier to hack the build in order to produces different flavors (with / without jaxb, all in one fat jar, skimed versions, etc...)
acuster: still I don't quite get the design that uses a lib to compile and then conflicts with it during the run; sounds very fragile
aaime: desriusseaux, yeah, I've been thinking about that (as well with others)
aaime: yet I fear we'd end up having, among the "parts" or gt2
aaime: the same relationship gs has with gt
aaime: dependencies on snapshots that you have to build on your machine
aaime: because you need this or that fix
jdeolive: i agree with adrian, seperating the buld to get around an issue with one part of the library conflicting with another seems a bad idea
jgarnett: martin your ideas have merit; but I was not going to worry about it until after we graduate (too many moving parts this month)
acuster: with religiously regular releases (RRR) it might be workable
desruisseaux: Yes Jody, I think your approach is safer.
jgarnett: we still need to bundle up metadata+referencing+geoapi+epsg-hsql as a single download and see if the result is worth the effort.
aaime: acuster, for the specific gs case, we can probably depend on a stable gt2 release for one week
jgarnett: acuster++ RRR would be great.
aaime: hardly longer than that
aaime: even with monthly releases
desruisseaux: Hudson may be of some help.
desruisseaux: It can deploy.
acuster: right but that's the top of the stack no?
acuster: metadata has been rock solid for a long time now
acuster: referencing issues seem to be calming down
acuster: now that there are all the right 'my axis is before yours' hooks in place
jgarnett: Yes and no; referencing was solid until it got jaxb dependencies; refering needs to be cleaned up at the factory spi level before I can show it to others ... there is always work to be done.
aaime: we're having quite some issues with multithreaded access
jgarnett: but your point is a good one; we should be able to "deploy" parts of our stack seperatly
aaime: people using GeoServer in anger are being hit
jgarnett: aaime my code from last year fixes it; but I need some of martin's time to debug one bit of functionality (lookup by id)
jgarnett: and now I have no customer to pay for it; so it is listed as technical debt.
aaime: jgarnett, yes, but I understand your changes were deep?
jgarnett: if we roll out something based on my classes backed on to h2 we can test with out impacting others
jgarnett: my changes were
jgarnett: a) renaming things so I could tell what they were for
jgarnett: b) setting up object pools to handle the concurreny load
aaime: jgarnett, if I find a way to stop sleeping during the night and work isntead I'll have a look (wink)
jgarnett: c) looking at the caching code and stress testing
jgarnett: understood aaime
acuster: that code landed but is not being used?
jgarnett: aaime you made an h2 port before right?
aaime: (sorry, I'm really that busy (wink) )
jgarnett: if you can do it again I can just change which super class it extends
jgarnett: and we can try out my infastructure...
aaime: jgarnett, you don't get how busy TOPP people are these days (wink)
jgarnett: aaime i know you are that busy; but when you want to solve it give me a coupl days notice - I am that busy too
aaime: Ok ok
aaime: well, time to get some sleep for me
jgarnett: thanks for the chat.
aaime: I need to get up at 6am tomorrow
acuster: hmm, that seems less like bug fixing and more like a whole new functionality
aaime: acuster, right, but that seems to be necessary in order to make the code scale on very high concurrent loads?
acuster: ok
aaime: (I don't know, I'm trusting what other people say and the issue we're seeing in 1.6.x where Jody's code has not landed)
acuster: is there a bug report on all this? It's the first I hear of these issues
aaime: yes
aaime: http://jira.codehaus.org/browse/GEOS-1876
acuster: and I'm not sure they invalidate the idea of having a stable referencing layer released separate from the feature level layer
jgarnett: acuster; you are right that is why I was paid for 4 months to do the work ...
jgarnett: martin gave me lots of careful reviews; and my code is done.
aaime: I really have to go
jgarnett: I have one bug with ReferencedObject lookup or something.
jgarnett: - http://docs.codehaus.org/display/GEOTOOLS/Improve+CRSAuthority+Concurrency+Caching+and+Connection+Use
***acuster fades as well
jgarnett: night
jgarnett: has anyone posted the logs ...
aaime left the room.
jalmeida n=jalmeida@189.62.58.87 entered the room.
jgarnett: suppose that is me then...

Weekly IRC 2008.05.19

Weekly IRC 2008 May 19

  1. what is up
  2. we're moving to mvn 2.0.9
  3. Graduation work: headers, review.txt
    #"Fix Versions" in JIRA

. desruisseaux has changed the topic to: Weekly IRC 0) what is up 1) we're moving to mvn 2.0.9 2) Graduation work: headers, review.txt 3) "Fix Versions" in JIRA
<desruisseaux> Shall we start?
<aaime> sure
<desruisseaux> 0) What is up
. aaime bug fixing for the releases, running CITE tests, and making the releases
<desruisseaux> Martin: MosaicImageReader again (working on the special case where the grid is regular - no need for an RTree in this case)
<acuster> acuster — starting on isogeometry module; looking into Hg -> subversion pathways
. groldan is hacking hard on ArcSDE, implementing per connection command queue
<acuster> chorner, dwins elizard ggesquiere hbullen mgrant pramsey vheurteaux ?
<pramsey> ?
<vheurteaux> yep ! hello
<desruisseaux> What is up
<vheurteaux> boring things non GT related (sad)
<acuster> weekly IRC meeting if you all want to pitch in
<acuster> going twice....
<desruisseaux> 1) We are moving to mvn 2.0.9
<acuster> we have cedric's patch waiting
<acuster> I'm planning to apply it tomorrow so I don't have to think about it anymore
<acuster> so everyone should be using maven 2.0.9 now
<acuster> that's all
<groldan> does it mean the build won't work anymore with < 2.0.9?
<groldan> ah ok
<desruisseaux> It is likely to continue to work
<acuster> not sure
<desruisseaux> (I means likely to continue to work with 2.0.8)
<acuster> but 2.0.9 will be our default
<desruisseaux> But using 2.0.9 would be more determinist.
<groldan> okay, cool
<desruisseaux> 2) Graduation work
<acuster> We are ready for the final push
<acuster> module maintainers will be responsible to update all headers and the review.txt files
<acuster> also I'd like to review where the data in sample data came from
<acuster> and get data with overlapping data with non-identical projections in the shapfile group
<acuster> sorry
<groldan> yeah, I got rid of all sample data in sde some time ago just because I didn't remember where it came from
<acuster> and get overlapping data with non-identical projections in the shapfile group
<acuster> for the modules of you three what's a reasonable deadline for this work?
<aaime> Eh, officially I'm the maintainer of postis-versioning only
<aaime> and can help on rendering and jdbc
<aaime> but that's it I guess
<acuster> okay, the plan is to push a bunch out now and use that to pressure the slower folk
<acuster> that's all I guess
<groldan> at one time I thought the review was meant to be done by someone else than the module maintainer?
<groldan> but I might be wrong
<acuster> ooo, I like the idea
<acuster> okay, so we'll revisit this once we get some modules done
<acuster> next?
<groldan> sure
<groldan> ?
<groldan> desruisseaux: I guess floor is yours?
<desruisseaux> JIRA
<desruisseaux> More precisely "Fix version" in JIRA description.
<desruisseaux> Can we let it to "unknown" when the reality is that we don't know?
<groldan> so your concern on the ml makes sense
<groldan> and yes, we seem not to have a policy about that?
<desruisseaux> A while ago the policy was to always set a fix versions on the basis that task without fix version fall in a black hole.
<desruisseaux> Maybe it is true for task without assignee.
<groldan> I wonder how much more work that would be for someone like andrea, who gets almost every issue reported assigned to him
<groldan> but that's in geoserver
<groldan> in geotools things may be a bit different
<aaime> From where I stand they are exactly the same
<aaime> I have so many issues assigned to myself
<aaime> that everything not exactly in the next release jira will be completely ignored
<aaime> black hole effect
<aaime> Stuff in the next release will be at least looked at, not necessarily fixed, mind that
<groldan> what I can say is that it is already hard to go thru the next version list and decide what one can actually achieve
<desruisseaux> Not sure if we are allowed to have a "maintainer-by-maintainer" policy. But on my side, I look from time to time to the list of tasks I'm assigned too. So even if they are not scheduled for every releases, I see them.
<desruisseaux> I also tend to look at every tasks reported against metadata and referencing modules, so tasks for those one do not fall in black hole neither.
<aaime> I don't see a problem with a "maintainer to maintainer" approach
<desruisseaux> May take a long while however (unfortunatly...)
<aaime> Yeah, for me it's different, my main responsibility is to keep GeoServer going forward
<aaime> anything that's not 100% in that topic basically does not exist
. simboss_ is now known as simboss
<aaime> also, I'm not maintainer of anything besides postgis versioning
<aaime> but in fact I keep up other modules whose main maintainer is missing or is someone else
<desruisseaux> Then, if nobody object, I will try to setup more accurate "fix versions" for metadata and referencing. It may implies many "unknown" fix versions. I would suggest to keep them as is if nobody object...
<groldan> right, you do, and its worring there are such a number of almost-orphaned modules
<aaime> I surely won't complain
<aaime> each maintainer is free to manage the issues of his modules as he sees fits imho
<desruisseaux> Thanks. I'm done then...
<groldan> and what about the main ones
<groldan> which have various maintainers
<aaime> groldan, same
<groldan> same thing?
<groldan> I see
<aaime> too many maintainers, no maitaner
<groldan> so in the end it would be just a mean of being more picky, just like what you were asking about issue reporting aaime
<groldan> ie, just do care
<aaime> Eh, yeah, the thing is that the number of issues vs the number of developers is simply overwhelming
<aaime> while the devs are already filled solid of other work
<aaime> so basically stuff that's moving is stuff that some way or the other has some commercial sponsoring behind it
<aaime> like it or not...
<groldan> right
<aaime> desruisseaux, stupid question
<desruisseaux> Andrea, yes?
<aaime> do you think it would be possible to make streaming renderer participate in the go-1 architecture?
<desruisseaux> I can ask to Johan
<aaime> you have pluggable renderers, right?
<desruisseaux> Yes
<desruisseaux> There is a "Renderer" interface for that.
<desruisseaux> Johan has separated "Canvas" and "Renderer" exactly for the purpose of plugin different rendereR.
<aaime> and "renderer" is something that can draw anything, like decoration, north arrow, map scale?
<desruisseaux> Renderer is basically a collection of implementation-dependant Graphic (this is the GO-1 design), and a Graphic can draw anything like a decoration, north arrow, map scale.
<desruisseaux> Canvas take care of referencing stuff (which is renderer-independant, so can be leverage accross different renderer).
<aaime> so it may be sitting in geographic space, or in "paper" space
<desruisseaux> One or the other.
<aaime> Ok, interesting
<aaime> thanks for answering
<desruisseaux> The renderer give the opportunity to draw in "objective" or "display" space (again the "objective" and "display" are GO-1 terminology)
<desruisseaux> As Graphic choice.
<desruisseaux> (typo: At Graphic choice)
<acuster> we done?
. acuster decides we are and goes to post the logs
<desruisseaux> Yes on my side.
<aaime> done

2.5-M2 Released

The GeoTools 2.5-M2 milestone release is available for download.

The GeoTools 2.5 series has been updated to use Java 5, and has undergone many improvements. This release is centered around making a new Feature model available. The new feature model is based on formal GeoAPI interfaces and allows the library to work complex data structures.

Since this is the first time the Feature model is being made available to the public this release should be considered alpha. Both the GeoServer and uDig projects have successfully migrated, so you are in good company.

Features from 2.5-M2:

  • JAXB bindings for the metadata module (ie support for ISO 19139 documents)
  • FeatureAccess super class for DataStore, allowing data access using ISO

Features from 2.5-M1:

  • Change over to GeoAPI SimpleFeature
  • Support GetGMLObject
  • Preview of new Swing Widgets (and a warm welcome to Eclesia)
Weekly IRC 5 May 2008

Weekly IRC meeting: 5 may 2008
0) what is up
1) svn cleanup
2) 2.5-M2
3) inccubation
4) FeatureCollection aggregated functions
5) backport paging to 2.4.x

<jgarnett> okay lets go ... although I had hoped to hear from simboss...
<jgarnett> 0) what is up
ggesquiere (n=gesquier@arl13-3-88-169-136-131.fbx.proxad.net) has joined #geotools
<acuster> acuster — cleaning svn; looking into mercurial
<desruisseaux> Martin: MosaicImageReader and postgrid.
<jgarnett> jgarnett - looking at Process discussion from last week and updating the codebase, trying to rememeber what was going on w/ ArcSDE now that I can run tests, annoying Eclesia with geoapi feedback when it sounds like he is on a deadline.
<Eclesia> jsorel : removed some swing widget that will not be supported in the futur
<groldan> groldan: adding tests to geoserver wms, quite stuck on static stuff
<acuster> no deadline, merely a distinct urge to make progress
<acuster> anyone else?
<jgarnett> simboss ping (smile)
<jgarnett> 1) svn cleanup
<jgarnett> acuster and/or martin ?
<acuster> afabiani, Awp_ chorner dwins elizard ggesquiere hbullen jdeolive mgrant ?
aaime (n=aaime@host97-45-dynamic.3-87-r.retail.telecomitalia.it) has joined #geotools
<acuster> me
<afabiani> hi
<Awp_> it wasn't me
aaime has changed the topic to: 0) what is up 1) svn cleanup 2) 2.5-M2 3) inccubation 4) FeatureCollection aggregated functions
<acuster> any of you want to give us a quick what is up?
<acuster> going once...
<acuster> okay gone
<acuster> SVN cleanup
<acuster> hmm, I even wrote up a page on what I'm doing
<acuster> in summary
<acuster> we start with the repo, use svnadmin to get a dump
<acuster> run that through svndumpfilter a bunch of times
<acuster> that gets rid of 1) most of udig 2) big files 3) lots of stuff we don't care about, e.g. .cvsignore files
<acuster> we go from 3.0GB to 1.4GB or so
<jgarnett> (link to page?)
<acuster> then we run the dump through a java class to pick up all the files which were duplicates
<acuster> http://docs.codehaus.org/display/GEOTOOLS/Svn+Cleanup+2008
<acuster> all the files which were added as duplicates
<acuster> only we don't do anything if they were added in the same commit
<acuster> because fixing that would be hard and error prone
<acuster> anyhow,
<acuster> we are good to go
<acuster> we need from you all (1) a go ahead (2) a date or date range where we can do this work
<acuster> how does this week work for everyone?
<desruisseaux> Fine for me.
<aaime> yap
<groldan> for how long it will mean having no svn?
<jgarnett> how does it work with refractions sys admin?
<acuster> groldan, I'm guessing 24 hours probably less
<groldan> cool
<acuster> jgarnett, I need to clear it with them when I get a sense from the gt community what works here
<acuster> I have no idea of GS or uDig deadlines in the near future
<acuster> also I need to coordinate with you jody to work out the permission stuff
<acuster> okay, people seem willing to do it. I'll contact refractions and get a date from them, then send out a confirm email
<acuster> if it causes a time conflict for anyone at that point, yell loudly
<aaime> Hem... deadlines... groldan, what was the planned release date for gs 1.6.4?
<acuster> I'd like to do it wed/thrusday
<aaime> end of this week, or end of next week?
<groldan> I'm not really sure, guess end of week?
<groldan> this one I guess
<aaime> acuster, are you planning to do the work during the week or during weekend?
<acuster> week
<acuster> since it depends on refractions
<aaime> Hmm.... ok, then we cannot cut 2.4.3 on Friday I guess
<jgarnett> acuster I am away for the weekend+monday; refractions sys admin can also do permissions if needed.
<acuster> ok
<acuster> aaime, groldan is this week a bad idea for you?
<acuster> is next week better?
<groldan> hmmm I thought I could afford a day without gt svn, not sure about andrea
<aaime> ah, me too
<aaime> the problem is the timed gs release
<aaime> next week is probably going to work better for us, yes
<aaime> I'm asking our release manager just to make sure
<aaime> (crazy times at gs)
<groldan> acuster: waiting till next week would be killer for you?
<acuster> okay, I will now aim to take svn down for 24 hours the 13,14, or 15th
<acuster> nope
<acuster> glad to work around your schedule
<acuster> that's all, next.
<jgarnett> 2) 2.5-M2
<groldan> that's reliefing so, thanks
<jgarnett> I tried to release this last week; and got stuck on some work simboss was doing; I would like to try again this week ...
<jgarnett> is there anything else that is going to hold me up?
<groldan> yes
<jgarnett> (the goal here is to make a milestone release so some uDig developers can evaulate switching to trunk...)
<groldan> I need to add unit tests for the paging + querycapabilities stuff
<jgarnett> okay; can you ping me when done?
<groldan> planning to do that tomorrow though
<acuster> why does that block a release?
<jgarnett> I don't really mind why (my guess is gabriel does not trust the code until unit tests are in place?)
<groldan> not sure if it should, because there might be a couple regressions/new bugs we don't know about
<acuster> if jody can wait, it's all good
<acuster> the uDig folk are chomping at the bit though
<jgarnett> It is only a milestone release; if it "works" then it is worthwhile me making "SDK" releases available for uDig developers (so they can migrate to trunk)
<groldan> anyway, if jody is planning to do it this week I can put a hardline myself of tomorrow
<acuster> great
<jgarnett> moving on ...
<groldan> okay, I would preffer you wait for it so
<groldan> since udig uses a lot of postgis
<groldan> which's what I touched
<jgarnett> understood; also that functionality would make a great tableview :-P
<jgarnett> 3) incubbation
<jgarnett> no progress to report; I see some (c) headers have been updated ...
<acuster> do we need to schedule a big push for that?
<jgarnett> this is really in the hands of module maintainers right now....
<jgarnett> we do
<jgarnett> a search and replace would be a good start.
<acuster> that sound scarily lazy
<acuster> desruisseaux, how are your modules on the review.txt front?
<acuster> anyone else know where they stand on their modules?
groldan has changed the topic to: 0) what is up 1) svn cleanup 2) 2.5-M2 3) inccubation 4) FeatureCollection aggregated functions 5) backport paging to 2.4.x
<desruisseaux> I don't think that anything changed since the review.txt files has been wrote.
<desruisseaux> (I means, it seems to me that the pool of developper in metadata, referencing and coverage has not changed)
<acuster> which means what? are you ready for graduation?
<desruisseaux> If graduation == changing headers, yes.
<acuster> that's pretty much all that left
<jgarnett> graduation == changing headers & review of code
<acuster> we can smell the OSGeo on the horizon
<acuster> anyone else?
<acuster> can we give ourself a deadline?
<acuster> ourselves
<jgarnett> I have not looked at any of my modules recently; a deadline would be fine.
<acuster> end of the month?
<acuster> June 21st (i.e. summer)?
<desruisseaux> Maybe: target end of the month, and see at that point where we are?
<jgarnett> let's go for summer; the smart thing would be to look when the next OSGeo meeting is .... and plan to finish our requirements two weeks previously; to give the iccubation committee a chance to review our work.
ggesquiere_ (n=gilles@arl13-3-88-169-136-131.fbx.proxad.net) has joined #geotools
<jgarnett> Let's try and write up our incubation stuff up at the end of the month; it will be a good test of where we are.
<acuster> good
<jgarnett> 4) FeatureCollection aggregation functions
<jgarnett> aaime ?
<aaime> Yes
<aaime> summary: feature collection has some aggregate functions
<aaime> like disticnt/min/max/average and so on
<aaime> they are implemented as fc visitors on the standard fc
<aaime> but for the jdbc fc, no, they are encoded as sql
<aaime> unfortunately that encoding is done once for all db in a way that breaks postgis (among other)
<aaime> and that breaks if the expression passed as an argument is not a simple PropertyName
<aaime> I need to fix it
<jgarnett> thinking ...
<jgarnett> can the different datastores; list PostGIS
ggesquier (n=gesquier@arl13-3-88-169-136-131.fbx.proxad.net) has joined #geotools
<jgarnett> implement their own FC? I think PostGIS already does ...
<aaime> it's empty and unused
<aaime> (but yes, it's there)
<aaime> moreover, that would not solve the problem of encoding an expression like "attribute + 10"
<jgarnett> ah; it origionally was the one that had the visitor stuff encoded as SQL
<jgarnett> and it was pulled up and shared.
<aaime> My point is that we can keep it shared
<jgarnett> okay
<aaime> we alrady have factored out ds differences in SqlBuilder/FilterToSql
<aaime> but sqlbuilder does not expose that functinality in a useful way
ggesquiere_ has quit (Client Quit)
<aaime> I would just need a encode(Expression) method in SQLBuilder and I could implement it the right way
<aaime> so that the col names are escaped according to the db needs and
<aaime> so that complex expressions are encoded properly as well
<aaime> but to do so, I need to add a method to an interface
<desruisseaux> I need to go before the rain... Bye all!
desruisseaux has quit ("ChatZilla 0.9.81 Firefox 2.0.0.14/2008042015")
<aaime> Now, SQLBuilder is one of those interfaces that are public
<aaime> but not really "published"
<aaime> it's not like our end user docs speak about them
<aaime> so I was wondering, can I add the encode(Expression) method to the interface
<aaime> without going thru a proposal?
<aaime> (and I need it for the 2.4.x series)
aaime listens to this resounding silence
<acuster> you could probably persuade jody if you promised him some fodder for the user docs
<aaime> fodder? (smile) what's that?
<acuster> stuff
<acuster> food technically
<aaime> http://en.wikipedia.org/wiki/Fodder
<acuster> alegorically, material
<acuster> cannon fodder ---soldiers to get killed by cannons
<jgarnett> thinking ...
<jgarnett> aaime; this JDBC stuff is a contract between you and the subclasses of JDBCDataStore
<jgarnett> it is not really user facing code is it?
<aaime> no
<jgarnett> then personally I don't care too much.
<aaime> it's not meant to be, yet of course the interface of SQLbuilder is public
<aaime> So it's ok for me to add that method?
<aaime> +1 for me
<aaime> jgarnett, jdeolive? vote?
<jdeolive> +0 I have not followed this issue
<acuster> sounds good
<simboss> +1
<jgarnett> +1
<acuster> in your email, you spoke of not having time to do the right thing.
<jgarnett> aaime; there is another way - volunteer to be the jdbc module maintainer (smile)
<acuster> if that's true, any chance you could lay out what that would be for future reference
<aaime> acuster, this way I can do it right
<acuster> great
<aaime> there were other "right" options that were more expensive than this one
<aaime> jgarnett, not ready to give up the last bit of my spare time (wink)
<jgarnett> (hey I gotta try)
<jgarnett> moving on ...
<jgarnett> 5) backporting paging to 2.4.x
<jgarnett> Now this one is user facing groldan
<groldan> more jdeolive's actually
<groldan> but anyways
<jgarnett> so tell me why we are considering this? (hint it involves you being paid and 2.5.x being a long way away)
<acuster> lol
<groldan> sort of
<jdeolive> jgarnett: yes
<acuster> do we have a sense of where the OGC is with their various proposals on this issue?
Eclesia bye ++
<jdeolive> jgarnett: and its only adding api... which we have allowed in teh past on a stable branch
Eclesia (n=sorel@mtd203.teledetection.fr) has left #Geotools
<aaime> acuster, OGC side stepped the issue
<jgarnett> I have tired to limit us to adding functionality (additional plug-ins etc...) and not api in the past.
<jgarnett> but your point is taken.
jdeolive laughs when people talk abotu enforcing backwards compatability in geotools
<jdeolive> but your point is taken as well
<jgarnett> 2.4.x does not have an user docs; but I would like to ask that we behave a bit better once 2.5.x series goes out.
<jgarnett> so how about this gabriel; you do the work; and you write a nice note about it in the release notes; explaining that we are very bad etc...
<groldan> I can do the work and add some doco, won't say we're bad though
<jgarnett> lol
<jgarnett> well we are at least treading in a gray area
<jgarnett> possibly at night.
<acuster> the puritan vs the latin
<acuster> groldan, you have what you need?
<acuster> are we done?
<groldan> I have what I need, if that means constantly moving on a gray area (tongue)
ggesquiere has quit (No route to host)
<groldan> okay thanks for the exception on behalf of the ones doing this paid work
<acuster> money talks, eh?
<groldan> and there are three minutes left for the end of the meeting yet
<groldan> acuster: that you already know
<groldan> that's how geotools goes forward I guess
<groldan> </meeting>?
<acuster> indeed

0) what is up 1) paging 2) Hello to SoC H2 student

18 <aaime> Hi?
19 <aaime> zero topic meeting?
19 * jdeolive loves those kinds of meetings (smile)
20 <aaime> lol
20 *** jdeolive sets the channel topic to "Weekly IRC: 0) what is up 1) configuration".
20 <dwins> i've asked the student I'm mentoring to stop by and say hello this week, should I tell him to come back when people are around?
20 <dwins> (for gsoc)
20 <aaime> shouldn't we talk/vote about paging?
20 <aaime> groldan?
20 <jdeolive> oops
20 * jdeolive forgot what day it is (smile)
20 *** jdeolive sets the channel topic to "Weekly IRC: 0) what is up".
20 <groldan> hi, got distracted hacking paging
20 <aaime> jdeolive: ha ha (smile)
20 <groldan> yeah, add paging as topic please
21 *** aaime sets the channel topic to "Weekly IRC: 0) what is up 1) paging".
21 <aaime> anything else? we're already 20 minutes deep into the meeting hour
22 <aaime> acuster, groldan, jdeolive, jgarnett
22 <aaime> anything else?
22 <groldan> not here
22 <jdeolive> not sure if jody is around today... he may be stuck moving
22 <aaime> aah right
22 --> simboss has joined this channel (n=chatzill@host201-203-dynamic.27-79-r.retail.telecomitalia.it).
23 --> wohnout has joined this channel (n=wohnout@kolej-mk-60.zcu.cz).
24 <dwins> aaime: can you add 'say hello to the SoC student working on H2' as a topic as well?
25 *** aaime sets the channel topic to "Weekly IRC: 0) what is up 1) paging 2) Hello to SoC H2 student".
26 <aaime> who's running the meeting? (wink)
26 <groldan> I thought you (smile)
26 <aaime> eh, I knew I would end up doing it (wink)
26 <aaime> Ok
26 <aaime> 0) What's up
27 * aaime flying low by at a high speed with DuckHawk project
27 * groldan hacking on paging
28 <simboss> doing nothing (smile)
28 <acuster> acuster — writing a file to clean the SVN dump
28 * jdeolive is working on rewriting component wms spec
29 * groldan does not understand what jdeolive is doing
29 <jdeolive> the spec as written is confusing and ambigious... so ogc is getting topp to make it so that it is not
30 <groldan> cool, thanks for the clarification
30 <jdeolive> np
30 <groldan> next topic?
30 <aaime> 1) paging
31 <groldan> okay, I was hoping to ask for a vote
31 <groldan> and was going to test postgis but the meeting time catched me up
31 *** aaime is now known as gt-meetbot.
31 <jdeolive> HAHA
31 <groldan> yet, I'm leaving QueryCapabilities.getFilterCapabilities() out of the picture by now, since its being an unexpected scope increase
32 <gt-meetbot> groldan, it was something requested by Jody as a condition to let the proposal go afaik
32 <groldan> do we have enough PMC around for a vote? guess not, but does anybody read the proposal?
32 <gt-meetbot> I wrote most of it... does it count as reading? (wink)
32 <groldan> thanks gt-meetbot, yeah, it was about having a default implementation with everything set to false
33 <simboss> groldan can I ask a quick question?
33 <groldan> sure
33 <simboss> do you mention
33 *** gt-meetbot is now known as gt-clown.
33 <groldan> gt-meetbot: that certainly count, I wish I have more bots that write them
33 <simboss> I have playing a little bit lately
33 <simboss> with ebXML registries
33 <simboss> where paging is part of the spec
33 <groldan> having a lot of xml fun so (smile)
34 <simboss> (using JAXR (smile) )
34 <jdeolive> i am weary of introducing new api...
34 <jdeolive> it is indeed scope increase
34 <jdeolive> not saying its a bad idea
34 <groldan> so you have some recommendation about paging?
34 <jdeolive> but it might be good to seperate out
34 <simboss> paging there is implemented using offset and maxelement
34 <groldan> how thar relates to CSW 2.0 paging? the same?
34 <simboss> I quickly scanned through the proposal
34 <simboss> of feature paging
35 <simboss> and there was no mention of maxelements/maxresult/numofelementshit or whatever you want to call it
35 <gt-clown> zzzzz
35 <groldan> maxFeatures?
35 <gt-clown> that was the idea
36 <gt-clown> keep on using maxFeatures, it's already there
36 <simboss> k then I scanned it too quickly (smile)
36 <simboss> thx
36 <groldan> we're reusing Query.maxFeatures for that concept
36 <simboss> question answered
36 <gt-clown> it may well be non mentioned at all (it's already in the query api)
36 <groldan> and I'm more about to call offset startIndex
36 <groldan> and let offset/limit as jdbc jargon
36 <simboss> startIndex is better IMHO
37 <gt-clown> maybe startFeature
37 <gt-clown> startFeatureIndex
37 <gt-clown> (to better match maxFeatures?)
37 <gt-clown> (offset/limit --> sql jargon)
37 <jdeolive> gt-clown: did we figure out what wfs 2.0 calls it?
37 <groldan> may be, though everybody seemed to worry about having a name reflecting some existing spec
37 *** gt-clown is now known as aaime.
38 <aaime> They don't call it at all
38 <aaime> results are treated like a linked list of pages
38 * jdeolive is going to start calling andrea "changling"
38 <aaime> Odo please
38 <jdeolive> haha
38 <aaime> you specify maxFeatures, the feature collection returned has a link to the next page
38 <jdeolive> i see
38 <jdeolive> alrighty
38 <groldan> yeah, they don't use it, just assume you start at the fist "page" and then follow server generated "links"
38 <groldan> no random access to pages
39 <jdeolive> i see
39 <aaime> (we can always add that as our custom vendor option for GET requests, people would love us if we do)
40 <groldan> and wfs 5.0 will include it
40 <jdeolive> anyways, to sum up, i am +1, no real preference on startIndex vs startFeatureIndex, but -1 on QueryCapabilities for now
40 <jdeolive> I think it should have its own proposal
40 <groldan> what do you do to know if the sorting will work?
41 <groldan> just catch up an exception?
41 <jdeolive> hope and pray
41 <jdeolive> the same thing we do with everything else in teh datastore api (smile)
41 <jdeolive> dont get me wrong
41 <jdeolive> i like the idea of QueryCaps... just think its a larger issue
41 <jdeolive> and dont want it to hold up paging
41 <groldan> it is if we include FilterCaps, which I'm leaving out so far
41 <aaime> remember it was not there to start with
41 <aaime> Jody asked for it
41 <aaime> in order to let the proposal get a +1
43 <jdeolive> right, and what i am saying is we should tell Jody to start a seperate proposal
43 <aaime> (in my first version of the proposal caps were not there)
43 <groldan> okay, in the mean time I'll make sure I get an end to end test ready
43 <aaime> sure, asking does not cost much
43 <groldan> and since we're in trunk, we can go with a minimal caps (ie, without filter)
44 <aaime> but given he warnted us it's probably better to ask before starting to commit
44 <groldan> and let depuring QueryCaps be another proposal
44 --> gdavis_ has joined this channel (n=gdavis@mail.refractions.net).
44 <groldan> jdeolive: would that work for you?
44 <jgarnett> hello - I am with a customer today (so am missing most of this meeting)
44 <jdeolive> groldan: yup, works for me
44 <groldan> hi Jody
44 <groldan> quick recap for you
45 <groldan> talking about paging
45 <groldan> we want to get minimal with QueryCapabilities
45 <groldan> ie, FilterCapabilities is being too much an scope increase
45 <groldan> but as we're on trunk we could start minimal
45 <groldan> and let QueryCaps mature as another propoasl
45 <groldan> sal
46 <jgarnett> bleck
46 * jdeolive misunderstood, his suggestion was to forgot QueryCaps all together for now
46 <groldan> that gives jdeolive's +1, otherwise he's -1
46 <jgarnett> I understand that QueryCaps is a larger scope
46 <jgarnett> however I would like to see either that; or someone taking the time to fix the existing datastores.
46 <jdeolive> if people really want QueryCaps right now i could be persuaded... but it seems unnecessary to me at the moment
46 <jgarnett> (ie I don't want to see datastores continue to suck; I was offering QueryCaps as a compromise)
47 <groldan> jdeolive: the gain I see is we won't need to change code later even if QueryCaps gets more methods
47 <jgarnett> I would be happier with doing the work to all the datastores; ...
47 <jdeolive> jgarnett: its a big changes... involves changing datastore implementations and client code
47 <jdeolive> it should not be taken lightly
48 <jgarnett> understood; so what change costs less?
48 <jdeolive> groldan: fair enough... so what does a minimal QueryCaps cover?
48 <jdeolive> just paging?
48 <jgarnett> FilterCaps? or fixing the DataStores?
48 <jgarnett> what I don't want is "half of paging"
49 <jgarnett> (ie the alternative presented earlier, Query2 with a FeatureSource2 is the least impact way of supporting Paging, ie new functionality = new method, new interface just like with GetObjectById)
49 <groldan> jdeolive: a minimal QueryCaps to cover isOffsetSupported() and supportsSorting(SortBy[])
49 <jgarnett> jdeolive; how would you do "just paging"?
49 <jdeolive> jgarnett: sorry, but its a reality of our datastore api at the moment, and its been worked around, you start chagning impelemtnations, work arounds stop working
50 <jdeolive> jgarnett: ok, i could go for that
50 <jdeolive> sorry, i mean groldan: i can go for that
51 <jgarnett> jdeolive; I got a few minuets to talk - we went over this on a couple of geoserver meetings. I don't mind what is done so long as it is complete - I am sick of half done work (like this StyleVisitor changes).
51 <jgarnett> groldan++ I can go for that too.
51 <groldan> cool, that's what I can too with the given timeframe (smile)
51 <jdeolive> jgarnett: i know, and i agree
51 <jdeolive> but drastic changes done work
51 <jdeolive> dont work
51 <jgarnett> yep.
51 <jdeolive> they lead to headaches
51 <jdeolive> its a big job... that is all i am saying
52 <jdeolive> putting it as a blocker to doing paging is a bad idea imho
52 <jdeolive> i am bnot saying it should not be done
52 <jgarnett> so what did we wend up with here; GetCaps with a single method isOffsetSupported() ?
52 <jgarnett> (looking for the proposal link...)
52 <groldan> paging implies sorting
53 <groldan> http://docs.codehaus.org/display/GEOTOOLS/Feature+paging+and+Query+capabilities
53 <groldan> so I mean isOffsetSupported(); and boolean supportsSorting(SortBy[]);
53 <jgarnett> makes sense.
53 <jgarnett> groldan are you going to update this page now? and call a vote during the meeting .... or are we expecting an email.
54 <groldan> nope, rigth away
54 <aaime> +1 for paging + limited caps
55 <jdeolive> +1
55 <jgarnett> +1 (you are updating the page now then?)
57 <groldan> done
57 <groldan> gonna add the votes now, thanks all
57 <jgarnett> QueryCapabilities as an abstract class please?
57 <simboss> +0
58 <jgarnett> for even as a final class; it is only a datastructure with fixed intent...
58 <groldan> not an interface
59 <jgarnett> sorry groldan; I am not sure when FilterCaps turned into an interface (it is in the proposal page)
59 <groldan> hmmm filtercaps is an interface afaik
59 <groldan> and I understood you wanted the same trick than for Query, ResourceInfo, etc
00 <jgarnett> I thought it was going to be a final class, or at least an abstract class - so that we can add more methods to it over time.
00 <jgarnett> (and not break everyone)
00 <aaime> he did want to avoid the same mistake as Query afaik
00 <groldan> yet, I was wondering if there's overlap in intent between ResourceInfo and QueryCaps
00 <jgarnett> not so much
00 <jgarnett> resourceInfo is about the data
01 <groldan> I see
01 <jgarnett> QueryCaps is about the FeatureSource API and how much you can trust it (ie interacting with the data)
01 <jgarnett> we got only a few more minuets; can we move on to the next agenda topic...
01 <jgarnett> or do you need more groldan?
02 <groldan> I'm gonna change to QueryCaps as an abstract class with no setters
02 <groldan> if that's what you meant
02 <jgarnett> 2) Hello to SoC H2 student
03 <wohnout> Hello that's me (smile)
03 <jgarnett> welcome!
03 * dwins lets wohnout do the talking
03 <wohnout> I have project to make spatial index to H2 database
04 <groldan> cool, welcome, btw
04 <wohnout> It should be great if it will be done
04 <wohnout> and I hope that I will make it (smile)
04 <groldan> so do you have a plan?
05 <aaime> wohnout, did you notice people were talking about your project in the H2 mailing list?
06 <wohnout> aaime: yes. I write there some info about me
06 * dwins was conveniently cc'ed on that thread
06 <wohnout> groldan: not so detailed but I have some ideas. I was talking to dwins and jdeolive today.
06 <jgarnett> I have a silly question; where is this work going to take place? As a geotools unsupported module? (and if so can i ask that we bring this one up to supported status before the end of the summer)
07 <aaime> jgarnett, I think we should've stated that as a condition before the student accepted
07 <aaime> raising the bar after the fact does not seem fair
09 <groldan> but what's the intent, being in geotools code base or another place?
09 <jgarnett> that was more my question, where is the work going to live.
09 <groldan> and if the former, we should help him as much as possible to, even if not getting to supported status, as close as possible
10 <groldan> (ie, by providing code reviews etc)
10 <-- DruidSmith has left this server (Read error: 113 (No route to host)).
11 <aaime> wohnout, do you understand what we're talking about?
11 <wohnout> I'm new to geotools ocde so I don't know how to answer (smile)
11 * dwins gets the impression that summer of code projects often have their own project on code.google.com
11 <wohnout> *code
11 <aaime> dwins, if they are stand alone, yes
12 <aaime> if this one heavily depends on gt2 api it's going to be easier to have it as an unsupported module in gt2
12 <-- gdavis_ has left this server (Remote closed the connection).
13 <dwins> sure
13 <dwins> but shouldn't gt2 use the database rather than the other way around?
13 <wohnout> I was looking on H2 module in gt2 and I have feeling that is not maintained by anybody
13 <jgarnett> well met wohnout; I gota run but it has been great to "meet" you online.
14 <jgarnett> jdeolive maintains the H2 module; but has not brought it over to be part of the standard "plugins" for geotools.
14 <wohnout> same to you
14 <aaime> wohnout, jdeolive here is the maintainer of that module
14 <aaime> wohnout, so the plan is to work on h2 codebase to provide a better spatial index
14 <aaime> and not to try and leverage the one alrady there?
15 <dwins> we have been discussing how the spatial index in h2 doesn't work well for non-point data
15 <aaime> if so, can I suggest a good book?
15 <aaime> "spatial databases" by Rigaux, Scholl, Voisard
15 <groldan> indeed
15 <aaime> has a few chapters on spatial indexes
16 <groldan> (though I may have read just 1/6 of it)
16 <wohnout> I think that this should be something above h2...
16 <aaime> groldan, me too
16 <groldan> but you had too much to do to finish it, I was not understanding (tongue)
17 <aaime> well, indexes usually are integrated with the db for good reasons
17 <aaime> thought of course integrating requires more work
17 <aaime> ah, sqlite rencetly got a spatial extension
17 <aaime> you may want to have a look at it
18 <aaime> http://www.gaia-gis.it/spatialite/
18 <wohnout> ok will take a look on it
19 <aaime> (not sure it has a spatial index, but people were speaking highly of it at a recent conference)
20 <groldan> so that's it? go with our best wishes wohnout.
20 <groldan> should we call for a wrap, or do you want to say anything else?
21 <wohnout> thanks
21 <wohnout> no that's all
21 <groldan> okay, welcome aboard again
21 <groldan> bye all, bed time here
22 <aaime> Who's posting the logs?
23 <groldan> okay, that can be my good action of the day, I'll post them
23 * aaime loves groldan

IRC logs, April 21 2008

Summary:
0) what is up
1) SoC
2) Process
3) Maven 2.0.9
4) proposals

jgarnett: meeting time?
gdavis: yes
jgarnett: (if I can ask someone else to run the meeting; I am too stupid / slow today)
jgarnett: ...
jgarnett: agenda items
Eclesia: process proposal
jgarnett has changed the topic to: 0) what is up 1) SoC 2) Process
jgarnett: please change the topic to add an agenda item...
desruisseaux has changed the topic to: 0) what is up 1) SoC 2) Process 3) Maven 2.0.9
jgarnett: Martin are you content to talk about Range via email? Or do we need to say anything .. I would like to write up a page for the user guide when we have it sorted out.
desruisseaux: Jody, sire
desruisseaux: (sure)
jgarnett: okay, I was expecting andrea to talk about his many proposals last week. At the very least they have all been voted on by now ...
jgarnett: lets go
jgarnett: 0) what is up
desruisseaux: I'm still working on NumberRange, trying to get it working with generic. But it would be more "weak" generic than what we previously has (a little bit like java.util.Collection which have a contains(Object) method, not contains(E))
jgarnett: jgarnett - installing arcsde and oracle and battling version hell between them
gdavis: gdavis: finishing up the process module and starting the gt-wps module, which is much like the wms module but for wps requests
jgarnett: (aside: martin I know how you can do that one better; but you may need to sacraface some of your constructors to get there...) Subject for after meeting ..
desruisseaux: (Jody: no need to sacrifice constructors - the problem is not there).
desruisseaux: (I means, I deprecate constructors, but they can be removed in next releases rather than now)
jgarnett: aaime did you have anything for the agenda? we are already moving ....
desruisseaux: No, new NumberRange<Integer>( 1, 1 ) can work.
jgarnett: 1) SoC
ggesquiere [n=gilles@ALyon-152-1-142-149.w86-209.abo.wanadoo.fr] è entrato nella stanza.
jgarnett: Deadline is passed; we will get students some time this week (I think...)?
jgarnett: So we will need all hands on deck answering the user list etc....
jgarnett: that is about all - thanks to Mentor's for volunteering; and to the many applicants - a lot of interesting ideas all around.
jgarnett: anyone else ...
jgarnett: 2) Process
jgarnett: gdavis ...
gdavis: ok regarding process module, we need to sort out the following concerns: process as beans, runnable, using ISO 19111 parameter as a base for ours, removing the hint attributes from the parameter class.
jgarnett: I think I can do this quickly:
jgarnett: - process parameters as beans; good idea - we tried it and it does not work a) internationalization support is terrible b) metadata such as FeatureType or CRS cannot be communicated
aaime: hum....
jgarnett: - Runnable can be considered; but it goes against the idea of a ProcessListener
jgarnett: - using ISO 19111 parameter was terrible the one time we tried it for a dynamic service; I never want to see that again.
aaime: can you elaborate at bit on each one?
Eclesia: I dont understand your agument against runnable
jgarnett: I think a lot of this discussion has been going on via IRC; we need to send emails to the list now and again...
desruisseaux: Jody, I never understood what didn't worked for you regarding ISO 19111 parameter. Could you post on email (or on a wiki page) an example please?
jgarnett: - http://docs.codehaus.org/display/GEOTDOC/ProgressListener
desruisseaux: I don't understand neither the argument against Runnable.
jgarnett: shows how to use a progress listener
sfarber: simboss, you want to prod more PMC into voting on the RS prop?
jgarnett: the trick here is that the listener is provied by the code that actually runs the thing
jgarnett: if we seperate that ( with a setProgressListener) we needless open up the door to mistakes and deadlock.
sfarber: (oops, thought we were in agenda-gathering phase. I'll shut up now)
jgarnett: Eclesia; it is a coding style choice - not a technical limitation.
desruisseaux: Jody, why? It is common to have "addFooListener" methods in worker classes (e.g. ImageReader.addImageProgressListener(...))
desruisseaux: After all, more than one listeners may be interrested to known about the progress...
jgarnett: martin; about ISO19111 parameters; I spent two months with you sorting it out; and we made a WMS GridCoverageExchange that used it. But the result was so crazy that we could not build a user interface based on the provided ParameterGroupDescriptor and ParameterGroup objects.
aaime: desriusseaux, yes, it's the swing style, and it needs special handilng to avoid memory leaks
aaime: (example: http://www.javalobby.org/java/forums/t19468.html)
jgarnett: martin you are correct; that is common; the style of programming I showed for ProgressListener is as much a bout "flow control" and the ability to interrupt as it is about reporting progress.
desruisseaux: So why not a Process.addProgressListener(...) method? (using WeakReference or not at Process implementor choice)?
jgarnett: Basically I want the code that "starts" the Thread to also provide the ProgressListener. Giving the responsibility to anyone else is a mistake ...
jgarnett: the easiest API way to enforce this is by using a process( ProgressListener control); method
jgarnett: so yes martin; the approach you describe works; using ProgressListener as a parameter works as well - and forces the programmer starting the Thread to take responsibility (ie the goal here is to assign responsibility to the correct programmer)
desruisseaux: Jody, I disagree. A Swing widget may be interrested to known about the progress but may not want to start it itself. The progress would be rendered in some widget in Swing threads. The process could be started by any other threads.
desruisseaux: Jody, there is my use case:
jgarnett: I understand; however I don't agree - it is the interupt case that gets me.
acuster [n=acuster@rab34-2-82-230-29-3.fbx.proxad.net] è entrato nella stanza.
jgarnett: please continue martin ...
desruisseaux: 1) A process is to be run in some background thread.
desruisseaux: 2) We want to monitor progress in a Swing widget.
pramsey ha abbandonato la stanza (quit: ).
desruisseaux: 3) We want to give the process to a java.util.concurrent.Executor, which will start the process in some threads that it control itself
desruisseaux: (i.e. using a ThreadPool)
desruisseaux: So we create the Process
desruisseaux: Swing register itself as a listener
jgarnett: okay so I understand your use case; and being a control freak of an API designer I want to ensure that the code that is handling all the threads is forced to know what is going on with respect to monitoring and canceling the thread.
desruisseaux: We submit the Process to the Executor, which will start it later as it see fit.
jgarnett: So if you had a "ProcessManager" model; the ProcessManagerView may very well use a swing based progress listener to do the work; but I want to force the programmer to keep there head up and make that judgement call.
aaime: desruisseax, you could get what you want by creating a wrapper around the process that turns it into a Runnable
aaime: jgarnett, having a single listener seems limiting thought
jgarnett: I had not thought explicitly about java.util.concurrent.Executor; I would be surprised if they did not have some of these facilities already.
jgarnett: aaime you are correct; the limitation is on purpose.
aaime: why?
desruisseaux: My goal is to get a Process framework fitting nicely in java.util.concurrency
jgarnett: (note all of this is a set of tradeoffs; I don't mind negotiating on this ... )
jgarnett: I am drawing a hard line here to make sure I am understood.
jgarnett: martin that was not listed as one of the goals for this work; it may be a useful goal - do you have some time to devote towards it?
aaime: I do understand the memory leak issue, I've been caught more than once in it with non trivial listener setups
desruisseaux: I can work with Eclesia
jgarnett: one of my goals is to intergrate with workflow engines and eclipse jobs for example ...
aaime: but I don't understand the single listener limit
desruisseaux: Memory leek seems a separated issue to me.
aaime: desriusseaux, given how common they are with swing, I'd say it's a design mistake
aaime: (see also http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4147808)
***Eclesia agree with aaime
Eclesia: a normal listener system would be better than a monitor
jgarnett: aaime; the single listener limit is just a choice; between limiting code to a single listener (you can always write a ProgressDispatchListener) and avoiding setProgressListener ....
jgarnett: so let me ask Eclesia; you understand the ProgressListener approach now? And you would simply like to use more than one ProgressListener?
aaime: jgarnett, that limitation could of course be removed using a dispatcher but it's annoying... why can't you accept a "Listerer..." param
jgarnett: I also should ask if what I am trying to do here is too subtle? is my point not comming across.
desruisseaux: A paranoiac code would need to invokes getProgressListener before setProgressListener, and creates come CompoundProgressListener if the former returned a non-null value. A addProgressListener(...) method is simplier.
Eclesia: yes, i would like more, I was kind of "foreced" to used monitor
Eclesia: forced*
jgarnett: yes; that was my goal
jgarnett: to force you to use monitor; and thus respect the workflow engine or user.
jgarnett: the other aspect to this is that what we have here is not a normal listener; the idea is to decompose the listener with sublisteners as code is delegates to other code.
desruisseaux: Jody what you call Monitor looks like this interface, or do I'm wrong?
desruisseaux: http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html
Eclesia: handling a listener list is not a hard thing...
jgarnett: yes
desruisseaux: Basically I strongly feel that one of the top priority of a process framework would be to fit nicely in the java.util.concurrent package.
jgarnett: and it was not the point.
jgarnett: new Runnable()

Unknown macro: {jgarnett}

jgarnett: moving on one of my priorities is to make sure that I can fit into a workflow engine with some form of job control.
jgarnett: as such I need some kind of callback object.
jgarnett: Is the fact that this is called "Listener" the source of confusion?
desruisseaux: Jody, a wrapper add conceptual weight... More concept to handle for the developper rather than the one he is used to == more complexity...
jgarnett: you are correct
jgarnett: however a wrapper is almost always required
desruisseaux: Why?
jgarnett: see SwingWorker for just such a wrapper
jgarnett: Runnable is also a wrapper; you are not often making those directly ...
jgarnett: because code requires parameters; flow control; and output
desruisseaux: If it is in order to get the result of some computation, java.util.concurrent.Callable do just that.
jgarnett: Runnable usually depends on object fields; or final parameters for the input; and sideeffects for the output.
desruisseaux: Java.util.concurrent gives you everything needed for getting an output object.
desruisseaux: Callable is like Runnable but returns a value.
jgarnett: martin we are missing something
jgarnett: how do I stop a runnable
desruisseaux: Future.get() can be invoked in any thread, wait for Callable to finish his works and returns that value.
jgarnett: that is all I want to know.
desruisseaux: Jody, you stop a runnable with Future.cancel() !!
desruisseaux: http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html#cancel(boolean)
jgarnett: Note Callable.call() is another example of a wrapper that is similar to Runnable; ie similar problem.
jgarnett: good now we are making progress
desruisseaux: Callable doesn't need to be a wrapper. Any developper can implements it directly if he wish
gdavis: if it has a cancel feature, im fine with using runnable
jgarnett: it does
jgarnett: martin can we make something that reports Progress using an extention of Future? or is that already done somewhere ...
desruisseaux: We could extends Future
desruisseaux: I have no objection to that.
jgarnett: Approach of Future is exactly the same approach as that used by ProgressListener; code that sets up the work is responsible for taking responsibility about its flow control.
jgarnett: I notice that SwingWorker now implements Future
jgarnett: so that may infact show a good approach.
aaime: but it keeps separate control and notification
aaime: you need to listeners for progress
aaime: (progress tracking)
jgarnett: http://java.sun.com/javase/6/docs/api/javax/swing/SwingWorker.html shows how to do Future and a Swing Progress bar together.
desruisseaux: We submit a Callable (or Runnable) object to an Executor, which will start the process in whatever thread it wish. Executor gives us in return a Future object that we can use for cancelling or getting the result.
aaime: would that fit in the Eclipse process control mechanism?
aaime: (with GeoServer I'm hands free, I can use whatever java API)
jgarnett: we still need a bit of glue code; for when the progress & future is delegated to other code (does anyone know what I am talking about here?)
jgarnett: aaime eclipse Job is very simple (on the level of Runnable + ProgressMonitor)
jgarnett: so we can make it work with whatever we end up with
jgarnett: I am more concerned about some of the process engines; I am not aware of anyone that uses Future yet.
desruisseaux: I use it.
desruisseaux: MosaicImageWriter use it in order to write many tiles in parallel.
sfarber: I used it too, to do pipelining so as to avoid the geoserver overload bug. It was pretty easy to get ahold of, and sort-of 'just worked' for the rather complex threading tasks that were put in front of it.
desruisseaux: I'm considering to use it in MosaicImageReader as well (reads many tiles in parallel) but this is more tricky.
jgarnett: still focus is on the Java programmer making processes; I would much rather only the workflow engine writer has to be smart (cause they only need to do it once)
simboss: hi guys, sorry I am late
jgarnett: martin and saul; do you use ProgressListener; or any other glue code in geoapi / geotools ?
aaime: sfarber, what was that? "geoserver oveload bug"? Never heard of it...
sfarber: It's the bug you've just found with DRobinson.
sfarber: (I'm pretty sure)
desruisseaux: In the case of MosaicImageWriter, I use ImageWriteListener (forgot the exact name) since it is the listener I'm supposed to use. But the principle is close to identicaL.
jgarnett: okay
aaime: (sfarber, sorry, where is the patch for that?? )
jgarnett: so martin we will look at this; and revise the proposal if we can make it work.
sfarber: jgarnett: no I haven't used the geotools 'progressListener' class before. But I've used other versions of the same concept.
jgarnett: I don't see any downchecks right now.
jgarnett: as for beans vs iso parameters; we are pretty stuck on that stuff - they both don't meet our requirements.
desruisseaux: 10 minutes left to the meeting...
desruisseaux: Well, I suggest to focus on one topic at time.
jgarnett: yeah lets move on; take the rest to email - good discussion however. Should we call a breakout IRC on this? because we gotta get moving...
desruisseaux: Could we start with Future, and revisit parameter later?
gdavis: well i cant move forward without some decisions on all these things...
jgarnett: yes; what we have now works for parameter.
jgarnett: so we can proceed with what we have now.
gdavis: ok
jgarnett: 3) maven 2.0.9
jgarnett: martin over to you?
gdavis: have we pretty much decided to use runnable then?
desruisseaux: I would said that the decision for now is to try to fit into java.util.concurrent for everything except parameters.
desruisseaux: java.util.concurrent said nothing about parameters, so we can revisit this issue later.
desruisseaux: So yes, lets try to use either Runnable or Callable (at your choice)
gdavis: ok
acuster: what are the processes for?
desruisseaux: http://java.sun.com/javase/6/docs/api/java/util/concurrent/Callable.html
acuster: i.e. how complex?
desruisseaux: Maven 2.0.9
Eclesia: acuster: http://docs.codehaus.org/display/GEOTOOLS/Process+proposal
simboss: guys I would ask some feedback on the RS proposal before we close the meeting since it has been floating around for a while now
desruisseaux: Cédric tried a build and got no problem
jgarnett: grab an agenda item?
Eclesia: ther are exemples at the beginning of the page
jgarnett ha scelto come argomento: 0) what is up 1) SoC 2) Process 3) Maven 2.0.9 4) proposals
simboss: thx
desruisseaux: Any objection if we put Maven 2.0.9 as a requirement?
desruisseaux: Doing so (after removing the plugins version that are now declared by Maven) produces an upgrate of a bunch of plugins.
desruisseaux: We are using some olds plugins versions.
desruisseaux: Letting Maven select the plugins versions may help us to get the upgrate them from time to time.
acuster: I don't object but I'd like to stop maven creep
desruisseaux: (typo: to update them)
acuster: i'm tired of everyone being on different mavens and not knowing why stuff is broken
DruidSmith ha abbandonato la stanza (quit: Read error: 110 (Connection timed out)).
desruisseaux: (for info, Andrian may be refering to aggregated javadoc not working when building with Java 5. It work with Java 6 only and nobody known why)
aaime: on 2.4.x it seems to works with java5 (that's how I build the aggregated jdocs for 2.4.x releases)
desruisseaux: It was used to work before, but Adrian has spent one days trying to get it on trunk, and the only way that seems to work is with Java 6...

desruisseaux: Nevertheless, my hope is that nailing down the pluging to the versions "recommanded" by Maven releases starting at Maven 2.0.9 may help to make the build a little bit less chaotic.
desruisseaux: (this is just a hope though)
desruisseaux: By chaotic I means things that was used to work and doesn't work anymore like javadoc...
desruisseaux: Any opinions?
sfarber: desruisseaux and acuster: can you try your changes before requiring this?
desruisseaux: Yes we tried.
simboss: btw, as a side note maven >= 2.0.8 has a few interesting bug fixes for doing offline builds
sfarber: I mean, just make the local mods to the pom.xml files, run it with maven 2.0.9 and see if it works!
desruisseaux: Yes we tries and it worked.
simboss: when snapshots are involved
desruisseaux: (typo we tried).
sfarber: ok, so the data point is:
jpfiset ha abbandonato la stanza.
sfarber: * maven mvn >=2.0.9 + martin and acuster's changes = working javadocs and building
acuster: nope, not so lucky
sfarber: I think that's clearer than "my hope is that nailing down the pluging to the versions "recommanded" by Maven releases starting at Maven 2.0.9 may help to make the build a little bit less chaotic."
desruisseaux: by "it worked" I means the build is successful, but aggregated javadoc is still working only with java 6.
desruisseaux: However I feel it as a step in the good direction.
aaime: hmmm... what improvements do we get (solid ones, things that did not work before and work now, or things that work faster)?
desruisseaux: None I can see right now.
aaime: (since experience is showing that we find out issues only when everybody switches)
desruisseaux: Simplier pom.xml.
acuster: what version of maven is cannonical today?
***acuster bets there are many
acuster: I was on 2.0.8
aaime: me too
simboss: same here
aaime: what worries me is not really switching to 2.0.9, it's changing the pom
desruisseaux: Oh I forgot! One possible benefit.
desruisseaux: After the Maven plugin upgrates, we got warning telling us that some of our modules will not build anymore in a future Maven version.
aaime: erk
desruisseaux: We got the warning after the plugin upgrate, not the maven upgrate itself.
jgarnett: back
desruisseaux: The warnings tell us what need to be reviewed and maybe modified in our pom.xml.
jgarnett: I just updated from maven 2.0.5 to 2.0.8 in the last month.
desruisseaux: So having too old plugins is maybe not a good idea.
acuster: martin can we split this out?
desruisseaux: May be easier to upgrates the plugins a little bit more frequently, and relying on Maven 2.0.9 and future version for that may make it easier.
acuster: ask for concesus on the move to 2.0.9
acuster: then ask for what the feeling is for changing the pom.xml?
acuster: and when downstream users have time to test builds
desruisseaux: Fine for me.
desruisseaux: So the proposal it: ask peoples to move to maven 2.0.9 now but do not update the pom.xml yet
aaime: Martin, maybe create a patch, a jira issue, and then ask people to try it out
desruisseaux: And update the pom.xml a little bit later?
desruisseaux: Okay.
aaime: works for me
acuster: anyone object to moving to 2.0.9?
aaime: (thought without a changed pom no-one will really forced to move to 2.0.9 I guess)
acuster: going, going ...
jgarnett: thinking
jgarnett: I am willing to try it
The [i=3f5eed82@gateway/web/ajax/mibbit.com/x-7300a1f6eebe1f03] è entrato nella stanza.
jgarnett: can we do another thing when we try on the weekend; it to avoid downtime?
jgarnett: (or is everyone feeling lucky)
The ha abbandonato la stanza (quit: Client Quit).
aaime: Do we really have a maven version that people have to use? Afaik we just have a recommendation in the release guide?
DruidSmith [n=DruidSmi@pool-71-181-172-190.sctnpa.east.verizon.net] è entrato nella stanza.
jgarnett: occasionally our build just does not work; if you do not go with the maven version in the developers guide
jgarnett: (ie I just want to list what is tested and working)
desruisseaux: We will create a JIRA task tomorrow, ask volunter to try and maybe edit the pom.xml in a weekend if we got the permission to then.
desruisseaux: I'm done.
aaime: cool
acuster: good
acuster: btw,
acuster: I changed some javadoc stuff today
jgarnett: okay
jgarnett: meeting time is up
jgarnett: but I really wanted to hear from simboss and aaime about the proposal storm last week
acuster: as in using references to javadoc 5 not 1.4
jgarnett: do either of you want to take the floor?
acuster: just a heads up for anyone that notices things changed
aaime: jgarnett, sorry, my sql proposal is dead in the water implementation wise
simboss: jgarnett: just a reminder about the RS proposal
jgarnett: your sql proposal?
aaime: I'm on a paid project for the next 2 weeks
aaime: sld proposal, sorry
jgarnett: okay
Eclesia: simboss : do you follow SE1.1 or a mix between SLD1.0 and SE ?
simboss: SE 1.1 and SLD 1.0
simboss: are basically the same thing
jgarnett: We checked SE1.1 as part of the review of his proposal.
simboss: as far as rasterSymbolizer is involved
jgarnett: simboss do you have everything you need? ie enough votes ... enough discussion etc...
simboss: actually
jgarnett: (http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support)
simboss: I wanted to ask martin if he had some time to review a bit the the proposal
jgarnett: I only see two votes ...
simboss: since last time he expressed some cocnerns
simboss: I think that we are at a stage now
simboss: that we can port to trunk
simboss: and narrow down remainig concerns while there
simboss: this thing has been sitting on a branch for enough time
simboss: risk is to lose it
sfarber: I really agree with simboss here.
sfarber: And I really need the RS work for better SDE raster support.
jgarnett: so what do we need votes from aaime, jdeolive, martin and yourself?
jdeolive: i know little of it... but i looked it over and like dit
jdeolive: +1 from me
aaime: sorry, I did not manage to review the classes that's why I did not vote
jgarnett: sweet
jgarnett: +0 then aaime?
simboss: as I say in the proposal I really need people to test this work
simboss: the combinations for RasterSymbolizer are a lot
simboss: even thought the code coverage is >= 70%
jgarnett: simboss I have paid work to make a bit of a user interface for this stuff
simboss: I would like to have someone like sfarber hitting on it
jgarnett: the moment I have that I will get more testing than I know what to do with.
desruisseaux: Just a quick note: Eclesia is working on expressing Symbology Encoding 1.1 as GeoAPI interfaces. He feels that such SE interfaces would naturally fit in a raster symbolizer. He asks if there is any chance to wait for one week until the SE 1.1 specifications is expressed as GeoAPI interfaces?
simboss: cool
jgarnett: martin I checked against the SE 1.1 proposal; there are no new ideas here for RS work.
simboss: the interface for RasterSymbolizer are the same
jgarnett: So Eclesia's work should not effect this.
Eclesia: you forget the function problem
aaime: (or, if it affects it, changes are that it will break gt2 api?)
simboss: but I am keen to check eclesia work (especially the widgets )
desruisseaux: It would effect if we wish to use a common set of interfaces
jgarnett: Eclesia; I don't think there is a function problem; but we need to have this conversation on the geoapi list ...
simboss: is there a proposal for this?
Eclesia: SE clearly separate FeatureTypeStyle from coverageStyle at the beginning, and later in the specification a concept of Function is used
simboss: to have an idea about the impact?
Eclesia: and i haven't clearly defined this "function"
desruisseaux: Is there any chance that Simone could look at the proposed interfaces, comment, etc. and see if it would be doable to implement some of them?
jgarnett: aaime I hope to make geotools interfaces extend the geoapi ones; and unlike with filter not switch over.
Eclesia: I could comit what i've done so far on geoapi, simboss could have a look
desruisseaux: Note that it doesn't prevent Simone to move the work on trunk if he wish
jgarnett: Function is the same as Filter 1.1 function; but has the optional concept of a "default" value to use if the function implementation is not found (a very smart move). There is also a list of optional functions they recommend implementing.
simboss: what if we do this
simboss: I port to trunk
simboss: so that sfarber and jgarnett can start testing
simboss: and when eclesia is ready
aaime: I don't see why a proposal that has been in the works for month should be stopped by one that does not even have a wiki page (just my 2 cents)
simboss: I help with adapting
simboss: aaime +1
jgarnett: aaime you are correct; that is why I checked the SE 1.1 just to see if there was anything to learn.
jgarnett: (it not related to Eclesia's work; as part of reviewing Simone's work)
aaime: if the Eclesia work gets a successfull proposal we can adapt the raster symbolizer wokr
aaime: I think we'll have to adapt various other stuff (or not)?
simboss: aaime: that's why I asked for a proposal page
desruisseaux: Expressing ISO standars as interfaces and proposing a new set of interfaces (from our own mind) is not the same process...
aaime: there are a few things that are new in SE 1.1 so to handle those parsers, style factory, styled shape painter and whatnot will have to be changed
simboss: or does the proposal pain applies only to some people ;-( ?
aaime: ISO interfaces must be voted like anything else
simboss: (note that pain was not a typo )
desruisseaux: Andrea, if so it should be voted by OGC working group, not by us.
aaime: I won't allow the usage of geoapi to circumvent the proposal process
aaime: by us too
jgarnett: understood; traditionally we have adopted geoapi interfaces when they were ready. Just like with the feature proposal. Same deal here.
aaime: since gt2 is not giont to implement any random idea that comes up with geoapi
aaime: we're the only implementor
desruisseaux: Not accurate Andrea.
aaime: geoapi is just a way few people use to control gt2 in my vision
desruisseaux: Referencing: JScience
desruisseaux: Geometry: Geoxygen
simboss: geoxygne is quite dead,
aaime: nevertheless, implementing it must be a free choice
simboss: it is not hte best example ever
aaime: not an imposition
jgarnett: on the positive side we are trying to have more controls on the geoapi side; I don't want to see the project confused by interfaces without a public implementation again.
simboss: and I agree with aaime here
simboss: changing the interface should be strongly discussed
jgarnett: yep
jgarnett: um; this upgrade to SE has been on the technical debpt page for a long time
acuster: is geotools still aiming to implement OGC/ISO ?
desruisseaux: You means changing the interfaces in the RS proposal?
simboss: the most successfull FOSS4g libraries
jgarnett: I went over that plan with Eclesia a few weeks ago.
Eclesia: ok, so i'll do SE in geoapi and if it's not to far from geotools, will make an update? is that so ?
simboss: do not even implement most OGC interface
aaime: Eclesia, you make a proposal
aaime: just like everybody else does
Eclesia: i made a jira task in geoapi
aaime: far or close it's not the matter at stake
jgarnett: Eclesia I was recommending you update the geotools interfaces first; and then "pull up" the geoapi interfaces.
jgarnett: basically don't develop the geoapi interfaces in isolation directly from the specification.
Eclesia: it's geotools that must align on OGC specification not the contrary..
jgarnett: stay in geotools with the safety/sanity check of running code.
desruisseaux: I would said the opposite: right it as close of specification as possible. Only after see if we need to make extensions.
aaime: we do not "must", we choose, it's different
desruisseaux: (typo: write it as close...)
aaime: and choose == proposal + pmc vote
vheurteaux: simboss: one of the purpose of GT2 is to follow OGC interfaces no?
jgarnett: indeed; please note that geotools style objects have been checked against SLD 1.0; there will be a very small difference between them in SE 1.1. That difference is what we need to talk about.
vheurteaux: in my understanding it's why it jump from 1.x to 2.x
aaime: vherteaux, as long as they are sane and they don't break existing software, yes
jgarnett: perhaps because I performed the check of geotools style vs SLD 1.0 I am more comfortable?
aaime: but we're not OGC monkey
simboss: vheurteaux: to be honest 1> I do not care much about OGC interface 2> who decides when to switch?
simboss:
jgarnett: the PMC does; when we have a proposal to vote on.
simboss: jgarnett: exact OGC does not pay me
jgarnett: indeed; OGC (and thus GeoAPI) simply gives me food for thought.
aaime: switching to geoapi filter was one of these "follow ogc" decisions and we're still paying the consequences (or a badly managed transition)
jgarnett: When I like their thoughts and we have a proposal to implement; we go.
simboss: but anyway if Eclesia proposal is strong, I see no reason why we should not accept it
aaime: simboss++
jgarnett: aaime not too sure about that; we had solid WFS 1.1. needs; the problems we encountered were due to scope; and we tried to inflict the process proposal thing on geotools to cut down on that.
jgarnett: lets give the proposal process a chance to handle SE 1.1
jgarnett: (it will be a good test)
aaime: that is my whole point
desruisseaux: Referencing, after the switch to ISO 19111, has been one of the most stable module in geotools because we made a big effort to follow ISO specification. Those guys have more expertise than we have and their specification are ofter wiser than what we would have imagined on our own. A module is more stable if it has been designed in such a way that it can meet needs that we even didn't...
desruisseaux: ...imagined today, and following the work of real expert groups help us a lot to reach this goal.
simboss: it is just that switching interfaces is, IMHO, a bit step and it is good to at least know everybodu about it
aaime: I'm not against ISO or OGC per se
aaime: I'm just saying that regardeless where proposals do come from, they have to be discussed
simboss: guys: sorry to interrupt but unless I see a proposal
simboss: I will vote -1 regardless of the idea
simboss: because I don't see why I had to spend night to refactor
simboss: my work
simboss: and wait for approval
aaime: desrisseaux, "real expert group" have shown to be able and make very silly decisions due to lack or real world involvement
desruisseaux: Sometime they fail andrea, but often they success. You should also admit that.
simboss: otherwise
aaime: j2ee v2, wcs 1.0 -> 1.1 transition, inability to handle real world symbolization are just a few examples
simboss: IMHO all this dioscussion is pure phylosophy
simboss: changes require proposal and vote
desruisseaux: ISO 19111 is much wiser than what I would have imagined on my own.
aaime: of how an "expert group" can screw up big time
desruisseaux: ISO 19107 is way above the capacity of my little brain.
jgarnett: hrm; this is a good discussion; but I would like to bring the meeting to a close soon. I am looking forward to Eclesia's work; geoapi really needs the help and I am glad someone is getting a chance to fix it up.
aaime: which is very very scary by itself, if not even you can handle it, who's going to be able and use it?
aaime: desriusseaux, if you don't like it this way, make a proposal asking that gt2 follows blindly whatever ISO or OGC thing comes out and let's count the votes pro or cons
jgarnett: Eclesia I will be glad to review your work; Martin said you had a couple of weeks on this topic? From my own experience with ISO19107 it may take a bit longer.
desruisseaux: ISO 19107 is hard because it try to adress a hard topic. The fact that the earth is spherical and 3D really brings a lot of complication - but this is real world and handling that fact needs a much higher expertise than I have...
jgarnett: you are correct martin; SE 1.1. is easier
Eclesia: My work is on SE1.1 , ISO19117 portrayal and GO-1
jgarnett: but often what took me some time was thinking through how to make good consistent interfaces from these specifications.
jgarnett: fun fun
aaime: My point is not to bash OGC or ISO, it's jsut that anything using them is no different than any other work -> it needs a positively voted proposal
acuster: hg, bzr or git will render this whole discussion irrelveant
aaime: acuster, if you want to fork gt2 you don't need any of them?
***Eclesia is not making this for fun, we have needs behind those specifications
jgarnett: agreed aaime; it is how we run the project. I give equal weight to designs that have shown success (success may be running code that is a joy to use; or success may be a ISO stamp of approval showing that a group has been able to sort through more compromizes than I can image....)
acuster: open source is a fork
aaime: if you want to make an official gt2 release with that stuff otherwise the tools do not help
aaime: a proposal is still needed
acuster: proposals are only needed to change existing api
acuster: as per the developer docs
aaime: right
vheurteaux: just to understand things guys
jgarnett: right; the existing api in this case is GeoTools LineSymbolizer; we would be asking it to extend a geoapi class.
acuster: but I don't care one way or another, it's a good few years before we're even close to having working code
vheurteaux: is GeoAPI dependant to GT ?
aaime: no
acuster: i.e. a GIS
aaime: it's not
aaime: but GT uses it so we have to decide wheter we do follow it or not
aaime: if Spring screws up big time in 3.0 geoserver will stop using it
vheurteaux: ok, but Eclesia is working only on the GeoAPI part ATM
aaime: vherteaux, and that is the business of whoever is managing geoapi
aaime: the proposal will be needed when you want to implement those interfaces in gt2
jgarnett: vhrurteaux; if I was mangaging I would ask Eclesia to start from GeoTools interfaces (since they represent an encoding of SLD 1.0 that works and has been checked)
vheurteaux: so the proposal must be done in order to be used in a GT project (ie. RS)
jgarnett: add in the new stuff for SLD 1.1
jgarnett: and pull up all the get methods into a super class in geoapi.
jgarnett: (low risk all around)
aaime: the proposal must be made even when gt2 starts using geoapi sld stuff as well
aaime: since it changes the gt2 api
Eclesia: my actually classe are a merge between geoapi SLD and GeoTools styling
jgarnett: then I would present a change proposal;
jgarnett: - to add the SE 1.1 methods to getools
jgarnett: - to add in the extends section
vheurteaux: ok I see...
jgarnett: Eclesia; yes - and the two are almost identical; except where geoapi screwed up (by following a version of SLD that was never published)
jgarnett: ie geoapi has two mistakes: a version of SLD that was never published; and two copies of the style interfaces (one based around Feature, and one based around Graphic). We can do better ... and it is a nice bit of work.
desruisseaux: The style interfaces in Graphic should probably be removed.
jgarnett: (so far from talking to eclesia I see two "interesting" sections for the proposal; with actual new ideas that will be of benifit to Filter, and the idea of inline graphics)
desruisseaux: We already talked about that issue at OGC meeting.
jgarnett: yes;
jgarnett: but this is turning into a geoapi meeting.
aaime: oh well, the issues are serious
jgarnett: and we have kept the geotools meeting going on longer than I can personally aford to give it.
jgarnett: aaime; so serious it is worth starting from the proven geotools base.
jgarnett: (which is holding up very well; I just went over it with a Java 5 stick last month)
jgarnett: http://docs.codehaus.org/display/GEOTOOLS/Technical+Debt#TechnicalDebt-UpgradeStyletoSLD1.1
simboss: guys sorry bother but could we come to a conclusion ?
jgarnett: conclusion; meeting over; I would like to review Eclesia's work on the geoapi list.
simboss: yeah and the RS proposal?
jgarnett: and I am confident that the most this will do to geotools is give us SE1.1.
jgarnett: RS proposal is a seperate matter; you have enough votes.
jgarnett: I checked it against SE 1.1
aaime: indeed, without -1 on it
aaime: you can start merging it
jgarnett: (and martin has a chance to do that as well; since he has not voted yet)
aaime: 3 days have passed since the proposal has been upgraded, no?
simboss: even a bit more
jgarnett: yep; means you can commit; the window for feedback is a little longer - but not much.
aaime: (was that two weeks?)
simboss: Eclesia: is there any chance you could wirte something about what you are doing
Eclesia: (two weeks not much compare to more than 3months for the process )
sfarber ha abbandonato la stanza.
Eclesia: you can review the jira task simboss
simboss: eclesia
Eclesia: i'll commit in the next days
aaime: Eclesia, you're right, but yet you could have started working on it after the required time passed
simboss: sorry
simboss: but looking at jira
simboss: is something I will not do
aaime: there's a reason we put a limit of 2 weeks on feedback
aaime: to avoid proposals being stalled by lack of feedback
simboss: because I have no time
Eclesia: i'll remember that, you can sure of it
simboss: just a smal page with some directions would help
aaime: the proposal process is there on a wiki page for everybody to read
simboss: exact
aaime: I'm not popping up rules out of a magic hat
acuster: proposals are great
aaime: http://docs.codehaus.org/display/GEOT/GeoTools+change+proposal
aaime: I would not go so far as to say they are great but they work better than not having them
aaime: from the wiki page:
aaime: "To avoid stagnation by lack of interest/time from community members the following assurances are provided:
aaime: svn access for changes is granted within 3 days from the proposal
aaime: proposal is accepted 'automatically' within 15 days (unless objections are raised) "
jgarnett: Eclesia you can start with the plan I had to upgrade Style to SLD 1.1 if you want
acuster: they are the closest we ever get to design documents for now

IRC Logs April 14th

Agenda:
0) what is up
1) mvn vs jar names
2) dynamic sld graphics
3) SoC
4) arcsde
5) mvn vs jar names (revisit)

jgarnett has changed the topic to: 0) what is up 1) mvn vs jar names 2) dynamic sld graphics 3) arcsde
jgarnett: okay we are 15 mins into the meeting timeslot; can we start ...
aaime: sure
jgarnett: 0) what is up
***aaime trying to cram up proposals to make gt2 move a little
aaime: (if nobody stops me next thing is modular rendering)
***groldan is doing geoserver bug fixing and ensuring WFS output formats do use CoordinateSequence
***jdeolive is doing geosearch stuff and starting to play with geoserver config again
jgarnett: jgarnett; uDig can now render polygonsymbolizers from an SLD file again - happiness. Starting in on gabriel's mad plan to switch ArcSDE over to using commands in a queue rather than locks around connections.
***Eclesia improving style editor widget for SE
desruisseaux: Martin: revisiting the +/-180° longitude and +/-90°latitude limit in MapProjection, recently modified from MapProjection to a simple warning. It has more implication, like making CRS.transform(Envelope, ...) more paranoiac (they need to check if we cross the 180° limit).
desruisseaux: (typo: from MapProjectionException to simple warning)
simboss_ is now known as simboss
jgarnett: (reminds me Ecleisa; a lot of the scary code I found for style / expression stuff was in your classes :-D Try and use the SLD utility class so we can share hacks)
jgarnett: 1) mvn vs jar names
jgarnett: I think this is actuall a formal proposal from martin now?
desruisseaux: I write a wiki page with current situation, and the proposal that Jody suggested me in an IRC last Friday.
desruisseaux: (looking for the URL...)
jgarnett: page is not under "proposals" ... go fish.
desruisseaux: http://docs.codehaus.org/display/GEOTOOLS/Module+renaming
jdeolive: i did not like the alternative of renaming all directories
desruisseaux: I do not like renaming directory neither...
jgarnett: jdeolive++ I agree, what did you think about just renaming the "leaf" directories?
jdeolive: i am also thinking we might want to consider the point where the ends do not justify the means on this one...
jdeolive: no, i dont like that either
desruisseaux: Continuing: I do not like renaming directory neither, but I wonder if it would be the less trouble-prone solution.
jdeolive: i dont like having to add all this complexity into our build and module structure
jgarnett: I am not sure that "Module renaming" is the goal here; the goal seems to be to make our project a bit more normal with respect to maven? So more maven plug-ins work ...
jdeolive: just to get a particular report or artifact to "work"
desruisseaux: "mvn site" is not the only Maven plugin which could benefit from a layout 100% conformant to Maven expectation. Last time tried some other plugins was working better with Maven conformant structure (I admit that I don't remember which one... was a long time ago)
desruisseaux: Renaming directory make directory names uglier, but the build simplier since it allows us to remove all custom settings
jdeolive: so what was the problem with just removing the gt2-prefix?
desruisseaux: (<finalName>, <scm>, <url> and the like)
jdeolive: naming conflicts?
aaime: yes, various of them
desruisseaux: They were this H2 name conflict that I didn't spotted before commit (because we don't use H2 on our side...)
aaime: between moduels in gt2 (wfs datastore and wfs model)
ggesquiere [n=gilles@arl13-3-88-169-136-131.fbx.proxad.net] entered the room.
aaime: and with other projects
jdeolive: ok, so lets just rename those modules and tell people that they cant have two modules with teh same name in geotools
aaime: plus look on maven... most of the time each jar brings the proejct name along
jdeolive: not sure i undrestand the h2 one?
jdeolive: aaime++
jdeolive: that seems to be java standard for major prijects like spring
aaime: h2-2.5-SNAPHOST : datastore
jdeolive: why dont they have tehse issues? or do they?
aaime: h2-1.0-snapshot: h2 itself
zzorn left the room (quit: Remote closed the connection).
aaime: major projects are not using maven afaik
jdeolive: ok, so lets rename h2 then
aaime: (not sure)
desruisseaux: I think that Glassfish use Maven (not sure...)
jdeolive: they must in some wat to get there artifacts into the maven repos\
jdeolive: wat = way
aaime: jdeolive, not sure they are doing that
aaime: there may be some non developer type that does it
jdeolive: ok... they must have fun with snapshot versions then
jdeolive: regardless
aaime: I asked various times to have jars pushed into the maven repos (not for major porjects thought)
jgarnett: jdeolive++ you are correct we could rename "h2" as "data-h2" or "h2-plugin"
desruisseaux: "h2-store"?
jgarnett: or "geotools-h2"; but then the temptation is to be consistent.
jdeolive: how abotu h2-spatial
jgarnett: jdeolive++
desruisseaux: Yes I like h2-spatial
jdeolive: cool
aaime: this is spring: http://springframework.cvs.sourceforge.net/springframework/spring/
aaime: still using cvs, and still using ant
desruisseaux: (h2-plugin would be inconsistent with other plugins; we don't put -plugin suffix everywhere)
SamHiatt: I'd vote on that name.
jgarnett: for the main library modules we run into the trouble that our module names are pretty generic; "main.jar" and so on ...
jdeolive: agreed
SamHiatt: I mean, I'd vote Yes to that name.
desruisseaux: But on the proposal issue: we have a choice:
jgarnett: http://springframework.cvs.sourceforge.net/springframework/spring/maven/ has the list of "spring-aop" etc...
desruisseaux: 1) rename directory - ugly but really lead to the simpliest and less troublesome Maven setting we could have.
jgarnett: back in a second.
***Eclesia must go ++
desruisseaux: 2) Keep current state (with h2 renaming) - better directory name but requires Maven hacking
Eclesia left the room.
aaime: here is wicket: http://svn.apache.org/repos/asf/wicket/trunk/
aaime: prefix in the dir names
aaime: (using maven as we do)
jdeolive: i definitley vote for 2
aaime: I prefer 1 I think
desruisseaux: Jody?
aaime: this is hibernate: http://anonsvn.jboss.org/repos/hibernate/core/trunk/
aaime: (flat names)
jdeolive: aaime: is your reason for vorting on 1 so we can have maven artifacts prefixed with gt?
aaime: so that it's easier to deal with maven
aaime: maven is very fragile
aaime: so I expect troubles if we try to work in a way different than it expects
jdeolive: ok, i have a question
jdeolive: for martin
jgarnett: back
desruisseaux: Yes Andrea, Maven is very fragile. This is the reason I'm tempted by 2 while I would normally prefer solution 1.
jdeolive: what was the original issue?
desruisseaux: Oups, opposite
jdeolive: that brought about the original renaming?
aaime: making mvn site work
desruisseaux: Tempted by 1 will I would prefer 2 if Maven was more solid
jgarnett: hibernate confused me a bit; do they actually have a core.jar ?
desruisseaux: "mvn site" among other, but not only.
acuster [n=acuster@rab34-2-82-230-29-3.fbx.proxad.net] entered the room.
aaime: jgarnett, no, in the repos, they have prefixed names
desruisseaux: I wonder how they get prefixed names in the repository...
aaime: so they are in the same situation as us... but with a twist... I don't see anything that makes the prefixes for the repo
aaime: my guess: manual process or automated with a script other than maven
jdeolive: question, what do we need site for?
aaime: all the reports maven generates end up in site
acuster has changed the topic to: 0) what is up 1) mvn vs jar names 2) dynamic sld graphics 3) arcsde 4) graduation status 5) project updates
aaime: javadoc, coverage, dependencies, ....
jdeolive: sure
jdeolive: but those reports work just fine
jdeolive: or maybe i am wrong
aaime: if you run them on a single module, yes
aaime: not if you try to make a full build
jdeolive: so you cant generate javadocs for a full build?
desruisseaux: javadoc and all site
aaime: javadocs do work, other do not
desruisseaux: and there is other mojo plugins that I tried a while ago that doesn't like non-standard layout
jdeolive: coverage erports work
jdeolive: i have done them before
desruisseaux: (don't remember which one - maybe it was the one listing the todo tasks, or last svn commits, etc.)
aaime: wow, never managed to?
aaime: cobertura crashed, the commercial one had issues as well
jdeolive: anyways... the point i am getting to is my original
jdeolive: is this really worth it
desruisseaux: I would claim that yes
desruisseaux: As Andrea point out, Maven is very fragile
jdeolive: ok... well all the reports i deem necessary work...so i would say no
desruisseaux: mvn site is not the only plugin having trouble with non-standard layout
aaime: we have lots of confused users that could enjoy a good mvn:site result
jgarnett: aaime for hibernate-core can we see how they did the prefixed names in the repos ?
desruisseaux: The links are broken, unless you put <url> declaration in every pom.xml
aaime: jgarnett, yes, it seems they did
desruisseaux: And experience show that we always endup with wrong URL declared in pom.xml
jdeolive: these issues seem more like maven bugs to me
desruisseaux: Yes definitively, we have trouble with Maven being fragile.
desruisseaux: Note that I'm fine with either solution 1 or 2. The solution that I would like to avoid is what we had before...
jgarnett: looking at how hibernate pulled it off.
jdeolive: not sure i woudl call it fragile... just because some obscure thing with site generation does not work...
desruisseaux: I looked at the pom.xml and didn't found a clue...
jdeolive: i mean... thats probably why a lot of projects do not use the site stuff
jgarnett: http://anonsvn.jboss.org/repos/hibernate/core/trunk/src/assembly/ has a couple hacks that look similar to what we need? they morph things into a different shape for deployment ?
aaime: I still dont' get how they manage to add the prefixes
desruisseaux: Well, in the case of hibernate the JAR are prefixed in the repo simply because their artifactID are prefix. So hibernate is doing what we did before.
desruisseaux: (typo: their artifactID are prefixed)
aaime: yeah. Whilst on the other side wicket is generating their site with mvn site
aaime: so they added the prefixes
desruisseaux: So they have a directory/artifactID mismatch, like we did.
jdeolive: my preference is we leave things the way we had them before
jdeolive: it seems silly to me to jump through all these hoops for a non-necessary maven feature
jdeolive: but ... that is why we have a PSC
jgarnett: martin they have a bunch of site.xml stuff; is that what they use to untangle mvn site:site
desruisseaux: I feel it necessary...
aaime: (wicket site is generated by maven, incredible as it it, it's true... or at least it was before they switched to apache... not sure now)
jdeolive: desruisseaux: i my definition of necessary is "the project wont run without it"
jgarnett: I am halfway between
desruisseaux: It is valuable then...
jgarnett: we cannot afford another two days downtime
jgarnett: but the project should not really be running without code coverage results either.
jdeolive: jgarnett: come on
desruisseaux: And again, "mvn site" is not the only plugin.
jgarnett: I spend a couple days a year getting coverage results. Not saying this a is a great reason jdeolive; just admitting it is the truth.
desruisseaux: In the way we had before, we need more declaration in every pom.xml. Most peoples do not keep those declarations up-to-date.
jdeolive: thats life with maven...
desruisseaux: More than one pom.xml had wrong <scm> or <url> declaration.
jdeolive: it seems we used to do what most projects do
jdeolive: so i am against all of this
jdeolive: so consider my vote a -1
desruisseaux: Yes thats life with Maven. My hope was to simplify our life by relying on maven defaults.
***jdeolive is bowing out of conversation
jgarnett: from my stand point we are bit stuck here are we not? This proposal is not clear cut ready to go; and we made a mistake by trying to remove prefixes last week without a proposal (and without understanding the consequences)
aaime: jgarnett++
jgarnett: so what are we left with ... we have 10 mins left and some more agenda items that are also important.
jgarnett: martin your proposal as written will work?
jgarnett: and does not involve renaming any directories
jgarnett: can we use it until such time as <finalName> is fixed in maven?
aaime: jgarnett, the fix maybe 6 monts or 2 years away
jdeolive: submit a patch it worked for me with the eclipse plugin
aaime: maven bug fixing is even worse than gt2 one
jgarnett: good points all
jgarnett: The alternative proposal (where you rename leaf projects)
aaime: jdeolive, heh, I tried to work on maven a bit but really, that project has a serious documentation problem
jgarnett: has two down sides; merges are hard - and makes working on geotools expensive for everyeone.
aaime: I could not even find the javadocs...
jgarnett: and it does not completely fix the problem does it?
desruisseaux: I should fix it completly I believe
desruisseaux: The alternative proposal would leads to a 100% Maven default compliant layout.
jdeolive: until the next problem comes up
aaime: jgarnett, do you merge from the root of the modules? I usually do it inside th module otherwise it's too slow
desruisseaux: Next problem are less likely with default layout than default one.
desruisseaux: (typo: than custom one)
jdeolive: thats a naive view, considering that there are 3 other major projects that depend on geotools
jgarnett: aaime I do not understand the question ... "merge from the root of the modules"
aaime: jgarnett, I usually do merges inside the module that has the modifications
jgarnett: next question; both proposal end up with the same artifact names do they not?
aaime: so changing the name is just a matter or movign to a different directory
aaime: if you merge from the root of the gt2 codebase on the contrary
desruisseaux: No, the alternative proposal would have only "gt-" prefix, not "gt-lib" or "gt-ext".
aaime: changing names will make merge fail
jgarnett: oh I see see; svn merge; I usually merge from root; except when merging from 2.2.x - in which case I cry.
acuster has changed the topic to: 0) what is up 1) mvn vs jar names 2) dynamic sld graphics 3) arcsde
aaime: jgarnett, that's way too slow for me
aaime: (from the root)
aaime: it takes minutes before the merge starts
jgarnett: interesting; I did not know that aaime.
aaime: that's why I did not care about renamed directgories
jdeolive: i would rather wait minutes then have to run the command for 80 different modules
jgarnett: guys I need to wrap up this topic; can we return to it at the end of the meeting?
desruisseaux: Jody has fast network connection since he is close to the svn server...
aaime: jdeolive, right, but when do you have such massive changes?
aaime: (do you backport them?)
jdeolive: when you move classes and things like imports change it can happen easily
jgarnett: jdeolive++
jgarnett: guys I am going to move us to the next agenda item...
aaime: correct... (never happened to me thought, since I'm more of a bug fix man than a refactor the world one)
jgarnett: martin I will be happy to talk about this a bit more after.
jdeolive: i agree 80 is unlikely, but 10 is not
desruisseaux: Jody, okay.
jdeolive: different strokes for different folks
jgarnett: 2) dynamic sld graphics
jgarnett: understood; but
jgarnett: http://docs.codehaus.org/display/GEOTOOLS/Dynamic+SLD+Graphic+objects
jgarnett: there we go...
jgarnett: this one is you aaime
aaime: well, the proposal says it all
jgarnett: (and also a nice user who has been sending us lots of email and trying out alternatives in code)
aaime: the problem is making Mark and ExternalGraphic easily extensible
jgarnett: I have seen three approaches; the one andrea has written up is good ... and mostly I want to see this problem solved.
aaime: and allow feature attributes to be used in the definition of the symbol name
aaime: or the url that points to it
aaime: without breaking the SLD standard
aaime: or our object
wolf [n=wolf@hoasb-ff0add00-126.dhcp.inet.fi] entered the room.
wolf: hi
aaime: it all boils down to a creative use of CQL expressions templates withing the names specified in
aaime: the sld
aaime: as proposed
aaime: it allows to support extensible symbols in both marks and external graphics
aaime: generate charts, both locally and using a remote server
aaime: use a fully programmatic driven symbol set like mil2525b
aaime: and generally speaking allowing everybody to create plugins for whatever format they fancy
jgarnett: Hi wolf will put you down next
aaime: thought I'm personally interested in waht's easily reached thrur internet
jgarnett has changed the topic to: 0) what is up 1) mvn vs jar names 2) dynamic sld graphics 3) SoC 4) arcsde
wolf: jgarnett: ack
aaime: that is, symbols and fonts
aaime: that internet is full of
aaime: and that we cannot use nowadays
aaime: The hard part imho is not writing the parsers, but writing the symbosl
aaime: so we want to leverage what's already out there
aaime: that's it
aaime: questions? observations?
jgarnett: aaime; I only had one bit of feedback (that I sent to email); I suspect when the OGC does solve this problem they will use <PropertyName> and not CQL ... does not matter too much to me either way.
jgarnett: other than that lets rock and roll.
aaime: when they do
aaime: we can just have the factories receive the resolved expressions
jgarnett: We have a user slated to give us some MIL2525B stuff, so that will help vet the system with a real world example.
jgarnett: aaime++
sbenthall [n=seb@cpe-66-108-80-238.nyc.res.rr.com] entered the room.
aaime: but... we have an alternative... preparse the url so that they become expressions themselves
aaime: (did not think about this one in fact, could be interesting)
cholmes [n=cholmes@cpe-66-108-80-238.nyc.res.rr.com] entered the room.
aaime: say we take the url with embedded cql expression and we turn it into an OGC Expression
aaime: that we pass to the factories along with the Feature
aaime: (we use the string concatenation functions and the parsed cql expressions to make it up)
jgarnett: The data structure right now already holds an Expression
jgarnett: (at least last I looked)
aaime: that would require changing the parser... sigh
jgarnett: parser already generates a literal expression
jgarnett: you can use a visitor to attack that and do you CQL subst
aaime: yeah, but the parsing needed to turn mil2525://$

Unknown macro: {myatt}

into an expression is nothing like standard sld parsing...
aaime: thought... yeah, it's doable
jgarnett: nope I am wrong sorry man
jgarnett: it is a URL
aaime: ah, for ExternalGraphics, yes
jgarnett: (I was getting confused with WellKnownName which is already an expression
aaime: yeah, it's an attribute, so an Expression does not make sense
jgarnett: okay moving on ... can we call a vote on this so aaime can get to work
jgarnett: jgarnett +1
aaime: sure, if there are no objections...
CIA-31: groldan 2.4.x * r29926 geotools/modules/library/main/src/ (3 files in 2 dirs): GEOT-1769, Use CoordinateSequence to write down GML2 coordinate lists, instead of Coordinate[]
aaime: aaime +1
aaime: and... that's it?
jgarnett: aaime I am a bad person; I left the meeting run over time.
aaime: well, let's move the vote to the ml then
simboss: poor aaime
jgarnett: jdeolive voted on email
aaime: simboss... poor what... you have a vote you know?
simboss: yep
simboss: I like this thing
simboss: I actually worked on something similar for nato
aaime: and? or... but?
simboss: but of course they never released it
simboss: I have to read the proposal
aaime: ok, voting on mail is good then
simboss: I am sure your approach is much better than mine
simboss: one curiosity
aaime: ha, who knows
simboss: did you look at APP6?
grrrrr [n=groldan@217.130.79.209] entered the room.
simboss: beside milstd2525b I mean
aaime: no, what's that?
jgarnett: okay next ...
simboss: similar simbolozgy
jgarnett: 3) SoC
jgarnett: wolf you have the floor
groldan left the room (quit: Nick collision from services.).
simboss: just more complex
aaime: I did not look into mil2525b either, theunsgis did that
grrrrr is now known as groldan
jgarnett: We are trying to see if the April 18th deadline is all we need to know about.
wolf: Okay, you need to decide on what projects you want
SamHiatt: desruisseaux: you still here?
wolf: preferrably by tomorrow 12:00 UTC
desruisseaux: Hi Samuel
SamHiatt: I was trying to build pg last night...
SamHiatt: had problems with the new gt renaming stuff...
acuster: hey sam, we're in a meeting right now, if you can wait a second
desruisseaux: Oups, sorry.
SamHiatt: Do you think If I rolled back to before the changes that I will be able to build?
wolf: Google has set a dealine on 19th april 07:00 UTC for assigning mentors, but just to be safe we want to do it on the 17th
SamHiatt: acuster: sorry! I thought the meeting was done! :Z
wolf: any more questions concerning SoC?
jgarnett: So 17th = tomorrow at noon?
wolf: no
simboss: today is 14th
wolf: tomorrow is 15 th
jgarnett: "wolf: preferrably by tomorrow 12:00 UTC"
simboss:
CIA-31: saul.farber * r29927 geotools/gt/modules/plugin/wms/src/main/java/org/geotools/data/ (2 files in 2 dirs): two minor code cleanups
jgarnett: So simboss you seem to be the man with the plan this year; what do we need to do? Make sure the projects we like have mentors? And vote them up ...
wolf: that is a very strict preferrably Like I'll bite you if don't make it
acuster: SamHiatt, try on #geomatys ("/join #geomatys")
jgarnett: and here I thought his bark was all we had to fear.
simboss: well I have found 2 projects which are interesting
wolf: Once I get the list of proposals each project wants (in order of preference) I'll adjust the scores
simboss: one actually is more like acontribution
simboss: the pyramid jdbc plugin
simboss: the second one is from a guy here in italy
simboss: he want to try and integrate better jpeg and png support
simboss: through jmagick+imagemagick
jgarnett: so simboss can we take this to email; and actually talk about the proposals? or is this going to be a case of no time?
simboss: yeah I can do that
jgarnett: (we are 15 mins over meeting time; and two agenda topics to go ...)
jgarnett: 4) arcsde
CIA-31: groldan * r29928 geotools/gt/modules/library/main/src/ (3 files in 2 dirs): GEOT-1769
sfarber [n=sfarber@88-149-177-23.static.ngi.it] entered the room.
jgarnett: gabriel asked me to warn people I was hacking arcsde datastore
jgarnett: I am starting to implement the plan he talked about on IRC a couple of weeks back.
aaime: what's the mad plan about?
jgarnett: So I will ping groldan and sfarber as I go.
aaime: (30 word summary?)
groldan: here
jgarnett: the idea is that locking the connection is killing gabriels happiness; and he wants to switch to a queue.
jgarnett: I need to make arcsde datastore run with only one connection; so I need to let the "metadata queries" use the current transaction / connection
jgarnett: (ie asking about table info etc...)
aaime: hmmm... what is the transaction-connection relationship in SDE? in jdbc is 1-1
groldan: sde connections are not thread safe, we use sde native transactions held at a connection, we need to access a connection concurrently, locking a connection for the lifetime of a FeatureIterator is hard to maintain and a performance killer
jgarnett: so even with all of that we have two ways in which arcsde datastore works; transactions for work; and AUTO_COMMIT for getFeatureInfo( typeName )
jgarnett: I need to narrow the gap and have them share the same connection.
jgarnett: (there is a big IRC discussion about this design here http://docs.codehaus.org/display/GEOTOOLS/2008/03/24/IRC+Logs+March+24)
jgarnett: it is what I will be working from.
aaime: where do you set the current connection? pass as a parameter, use it as an "in the environamet" param like a thread local?
groldan: its at the transaction state
jgarnett: Think a runnable that takes a connection as a parameter
jgarnett: this is mostly a warning; I am sure I will have questions as I go; I well send all email to the devel-list as it happens.
jgarnett: 1) mvn vs jar names part ][
groldan: the idea is to divide execution units in as tiny bits as possible and enqueue them, that provides for a more granular use of the connection, as oppossed to blocking the connection until a FeatureIterator is fully traversed
aaime: groldan, I get that... this seems to be doable only in read only access thought?
groldan: why?
aaime: well, transaction need to be isolated
aaime: if you have a long transaction running you cannot share the same connection with other transactions no?
groldan: executions units are: "fetch a feature", "insert a feature", etc. All of them work with the active transaction
groldan: okay
aaime: right, so you cannot share the same connection between differetn transactions, no?
groldan: addFeatures() is an execution unit per se
jgarnett: aaime I am only planning to share a connection for the read-only activities; ie the ones used by ArcSDEDataStore to look at metadata.
groldan: but its ok because a getFeature called while an addFeature is in progress needs to wait till addFeatures returns
groldan: so the queue still works?
aaime: groldan, what if you're scrolling with a feature iterator?
aaime: using that damn thing you don't know if you're reading or writing
groldan: not quite getting the point
aaime: probably me neither
aaime: too used to jdbc way of doing things
aaime: never mind
groldan: in jdbc you have different transaction isolation levels
groldan: right?
jgarnett: yes
aaime: that's not my point
groldan: okay
aaime: in jdbc you cannot allow two transactions to access the same connection
groldan: so I don't get it
groldan: here neither
aaime: but if you're using a feature writer or a feature iterator
groldan: its all about how you define the bounds of your transaction (the runnable)
aaime: you need to keep the connection "locked"
jgarnett: what is hard here aaime; is that jdbc connections are pretty threadsafe?
jgarnett: arcsde connections are not
jgarnett: so we need to wrap them in a lock or face death
jgarnett: gabriel wants to use a queue rather than a lock.
aaime: no, the fact that once you open a connection for a transaction, you cannot share it anymore
groldan: so aaime what you describe maps to a certain "transaction isolation level"?
jgarnett: I though you can share the connection with another thread?
aaime: sorry, so the problem is multiple threads trying to acecss the same transaction concurrently?
jgarnett: yes; that is the problem
aaime: (only if the other thread is using the same transaction)
groldan: the point of using a queue rather than a lock is that the connection is gonna be used by a single thrad, even when serving multiple threads
jgarnett: multiple threads; one connection; how not to screw up
aaime: aah, sorry, I was thinking about geoserver where different threads = different users = different transactions
simboss_ [n=chatzill@host253-202-dynamic.37-79-r.retail.telecomitalia.it] entered the room.
jgarnett: okay moving on?
groldan: yeah, its a per transaction queue
aaime: I guess your case is udig, multiple threads, one writing, the other rendering, but all against the same connection
sfarber left the room (quit: Read error: 104 (Connection reset by peer)).
groldan: yes
aaime: yeah sorry for bothering
jgarnett: desruisseaux ping?
desruisseaux: Jody, yes?
jgarnett: 1) mvn vs jar names
desruisseaux: yes
groldan: np, trying to explain it really helps
aaime: (not really sure jdbc connections are suposed to be thead safe thought... never mind, go on)
jgarnett: stack.pop()
jgarnett: Is everyone sick of this topic? I am really tempted to rollback the changes until we have a clear direction that will work; is that a horrible idea desruisseaux?
***aaime jumps out of the window
jgarnett: (good thing aaime is on the ground floor)
desruisseaux: If we roll back, does it means that this issue will be forgetten?
aaime: jgarnett, do you remember the iron bars at the window? ouch!
groldan: aaime: mind moving to #geoserver?
jgarnett: and here I though aaime was skinny
jgarnett: martin I don't think this will be forgotten; if I was scheduling stuff I would tackle this right before we release 2.5.0 (or 3.0.0).
jgarnett: ie we have so many problems right now on trunk with functionality; interrupting anything for a few days to sort out some build problems just upsets everyone.
sfarber [n=sfarber@88-149-177-23.static.ngi.it] entered the room.
jgarnett: It would also help to arrive at this with a proposal we know works; in this meeting we ended up discussing a bunch of "What-ifs" and we had no way to vote +1
CIA-31: groldan 2.4.x * r29929 geotools/modules/library/main/src/main/java/org/geotools/gml/producer/GeometryTransformer.java: organize imports in GeometryTransformer
jgarnett: so a couple of questions:
jgarnett: - Even with this proposal we still have a bunch of work unaccounted for; updating the user guide examples etc... is this something we can get funding / time for?
desruisseaux: In this particular case, it may be difficult to know if a proposal work before we try it on trunk, since some problem appears when peoples user the dependency. For example we couldn't have spotted the h2 conflict on our side since we don't have any project using h2...
jgarnett: - Lining up with maven expectations is a good thing; we will run into less problems.
jgarnett: right; so now that we tried it once we have a second test to try... that maven-ant-tasks script.
jgarnett: um and I still cannot deploy? being able to deploy probably needs to be another test.
desruisseaux: I have been able to deploy last friday.
aaime: It would be nice if all jars had always the same name, no matter how they are genreated
jgarnett: I was unable to deploy today ... see email.
aaime: (nice == really required...)
desruisseaux: I means, I have run "mvn deploy" after the prefix removal and it worked for me.
aaime: jgarnett, looked at the mail, the error message means nothing to me...
desruisseaux: If we want the same JAR name both in the repository and in the target/binaries directory, then it would be a push for alternative proposal (renaming directory) or a rollback.
jgarnett: thanks... I was clueless as well so I asked for help. I could deploy last week.
jgarnett: martin I think that is what we want.
jgarnett: I would personally rollback;
jgarnett: and then schedule this proposal for the "release candidate"
jgarnett: and make sure we have enough hands on deck to do the documentation and so on.
jgarnett: But I also want to understand the hibernate build process; since they seem to have it working ...
aaime: jgarnett, they do not generage mvn site afaik
desruisseaux: Release candidate would be too late, because it let too few time to spot the problems. It also means that we have to live months without daily site and javadoc.
jgarnett: I don't know how much flexibility you hae in scheduling martin?
SamHiatt: nice one aaime
jgarnett: well noticed aaime
***aaime checks out hibernate and sees what the heck comes out of mnv:site
desruisseaux: We could do that later too, but I would really love to have site and javadoc generated every days as soon as we can...
jgarnett: agreed martin
jgarnett: (I am not sure if that gets through since this has been such a heated topic; having mvn site working is a very good goal - it costs me days a year not having access to the coverage reports)
aaime: +1 me too... site is good
jgarnett: so I want to see how to get that at not too high a cost
aaime: test coverage?
aaime: why?
jgarnett: I had thought renaming the folders was too high a cost; but apparently it is not the case for aaime.
wolf left the room ("Konversation terminated!").
jgarnett: because I often have to meet test coverage requirements for a deliverable.
aaime: I see
aaime: jgarnett, yes, it's a by product of how svn network protocol works
aaime: it does lots of tiny reqeusts for merges and updates
jgarnett: so as I understand it geoserver and udig are working right now
aaime: so if I know where the change occurred, I can cut down most of them
jgarnett: but with known problems.
aaime: down from one minutes to a few seconds
jgarnett: (that is interesting aaime; later I may ask you for an example)
jgarnett: aaime we are pretty sure we want the gt-main.jar style in the repository right?
jgarnett: You can use martin's jar collector to fetch things out in the right shape.
desruisseaux: I would be okay for a rollback if there is good chance that this topic do not fall in a black hole for months or years...
aaime: imho yes... that's what everybody is diong
aaime: and frankly
aaime: would you like a main.jar in your classpath?
aaime: main of what?
aaime: if you depend on 20 external libraries, think if every one did the same
aaime: nice, hibernate does not build out of the box... they must have a damn private repo
desruisseaux: Well, as Jody point out, we don't have this problem when using jar-collector. But this is a non-standard solution.
jgarnett: understood; and the maven "answer" is not that cool; it asks that you keep a directory structure around to keep stuff straight.
jgarnett: so martin; even though udig and geoserver can probably be made to work
jgarnett: I honestly think we need to put gt-main.jar into the repository for end users
jgarnett: we could negotiate
jgarnett: if we can make monthly releases for users that would help offset this.
jgarnett: but I would like some more users at some stage :-D
simboss left the room (quit: Connection timed out).
simboss_ is now known as simboss
desruisseaux: In this case, and if we want a directory layout matching the module name, there is no other choice than renaming directories...
jgarnett: I would like to agree on that; aaime what do you think?
aaime: jgarnett, found hibernate secret sauce: they are still not using maven
aaime: they only have it on trunk
aaime: but they are releasing from a stable branch using ant
jgarnett: The remaining questions for me come down to timing.
jgarnett: but how do they release to the maven repository?
jgarnett: using the maven-ant-tasks to deploy?
jgarnett: (or some other madness)
aaime: no idea
aaime: manually I believe, this pom is made up, it has no parent: http://repo1.maven.org/maven2/org/hibernate/hibernate/3.2.6.ga/hibernate-3.2.6.ga.pom
aaime: wicket does it with maven, but they renamed the dirs
aaime: http://svn.apache.org/repos/asf/wicket/trunk/
aaime: thing is, they have a very simple structure compared to gt2
jgarnett: question in the wicket pom.xml they have
jgarnett: <moduleSets> <moduleSet> <includes> <include>org.apache.wicket:wicket</include>
jgarnett: what is that syntax for include ?
aaime: dunno... the modules tag is standard
jgarnett: oh that was in wicket-assembly-all.xml
aaime: don't know... never tried to make a maven assembly
jgarnett: does assembly have anything to do with what is deployed?
aaime: I don't believe so... it's for releasing no?
desruisseaux: It put the JAR a single ZIP file.
desruisseaux: (including dependencies)
jgarnett: If I look here
jgarnett: http://mvnrepository.com/artifact/org.hibernate/hibernate/3.2.6.ga
jgarnett: it really looks like hiberante is deploying a single jar
aaime: yeah, they modularized it on trunk only
aaime: all of the other hibernate-something in maven repo are completely separated projects
jgarnett: yeah; okay - reminded that you said that already.
aaime: different version numbers and different svn
jgarnett: so martin it looks like we are boiling down to a single worhtwhile proposal
jgarnett: can we update that page; and include the steps for updating the user guide.
jgarnett: and aaime can you think of a good time to try this again for geoserver?
desruisseaux: Okay, will do tomorrow.
aaime: wondering... would be fixing mvn:site so hard? Or else, do we have reproted an issue there?
aaime: jgarnett, don't know, I haven't been working on gs trunk for ... a month maybe
jgarnett: I wondered as well andrea; but my guess is mvn site:site gathers up so many reports; that any of them could break us.
aaime: you break it, I won't even notice unless you break the build hard
jgarnett: I see; well uDig is using trunk hard; and I lose billable hours and have to have a meeting whenever trunk goes down for days
aaime: yet today I was working on it... trying to reduce build times (unacceptable long)
jgarnett: So I would like a couple days warning; and to try this out on a weekend next time.
desruisseaux: Fixing patially mvn:site is tedious but doable. One of my issue is that it requires explicit <scm> and <url> declarations that nobody maintains, and which always become wrong with time.
desruisseaux: But even if we get partial mvn:site, some reports will work and some other reports will not.
aaime: desriusseaux, yeah, but I was thinking for or a real bug fix in the maven site code, not a workaournd?
desruisseaux: Each reports is an independant plugin, so whatever or not is a plugin-by-plugin question.
aaime: yeah, ok, I get it, everybody just assumes users follow the maven standard practices
desruisseaux: Some assumes, other do not...
jgarnett: agreed; remember we had a lot more success when we renamed the src/main/Java folders .... it pays to not push the maven plug-ins beyond the defaults
jgarnett: (as sad a statement as that is)
aaime: jgarnett, really? I always wondered why
aaime: (why we changed, that is)
aaime: now that was really breaking merges, since you had to do two separate merges for each fix (one for the src, the other for tests)
jgarnett: I ended up having a lot less maven trouble after the change.
jgarnett: heh; I still mege from 2.2.x
desruisseaux: For having default (make pom.xml simplier and more reliable), but also for making some room for other language if we wish (I admit we are not yet there, but I was thinking about SQL, PhP or JavaScripts...)
jgarnett: wow the main stream press are on to us: http://arstechnica.com/news.ars/post/20080414-googles-kml-map-markup-language-now-an-official-standard.html
aaime: ok, I'm out of here.. bed time
jgarnett: aaime just a sec
jgarnett: I was trying to see about timing;
aaime: erk...k
jgarnett: you are telling me you don't care - and it is up to me?
desruisseaux: I will post an email tomorrow about the module name issue.
jgarnett: ie my request for a few days warning?
aaime: timing?
jgarnett: ie when should we do this...
aaime: I said I personally don't care
aaime: but other developer will care, and a lot
aaime: ask jdeolive
jgarnett: okay
desruisseaux: I will post an email tomorrow. Would it be okay Jody?
jgarnett: so martin; should we roll back the prefix change?
jgarnett: And then work through this proposal process ....
jgarnett: (that is what I am trying to figure out)
jgarnett: do we limp along right now; or do we rollback ...
desruisseaux: Could it be a question in my tomorrow email?
jgarnett: yes it can
jgarnett: okay thanks for the extra long meeting of doom
jgarnett: good luck with your symbol hacking aaime
jgarnett: (I am looking forward to it)
aaime: thanks
jgarnett: I can post the logs...
desruisseaux: Thanks all for your patience.
sfarber left the room.
aaime left the room.

IRC Logs April 7th

Agenda:

  1. what is up
  2. GeoTools 2.4.2 release
  3. update headers
  4. gt2- prefix removal
  5. progress module
  6. postgrid in gt2

SamHiatt: Martin: I was considering bringing up PG in the meeting to see what other people's interest in it is... and to discuss how to frame the module, once it moves to geotools.
ggesquiere left the room (quit: Client Quit).
desruisseaux: Sure if you wish
ggesquiere [n=gilles@arl13-3-88-169-136-131.fbx.proxad.net] entered the room.
desruisseaux: But I'm not sure that it is mature enough...
aaime [n=aaime@82.56.105.98] entered the room.
desruisseaux: (would probably be an unsupported module for a while...)
jgarnett: morning
jgarnett: meeting time?
jgarnett: (we moved it an hour earlier; ie now; did we not?)
desruisseaux: yes
aaime: yap
gdavis [n=gdavis@mail.refractions.net] entered the room.
jgarnett: sweet
jgarnett: aside: thanks for the email over the weekend aaime - I will try and stay a bit more on target with udig stuff.
jgarnett has changed the topic to: 0) what is up
aaime: np, sorry for being mad
aaime has changed the topic to: 0) what is up 1) GeoTools 2.4.2 release
jgarnett: it is okay; I have broad sholders; a share of the blame; and I know it is a frustrating topic.
desruisseaux: Topic: gt2- prefix removal in module names
user451 [n=user451@mail.refractions.net] entered the room.
jgarnett: Anyone know if exclisa is around today? It would be fun to talk process stuff with him...
desruisseaux: I don't known...
jgarnett: aside: aaime I was reviewing filtervistors stuff over the weekend and liked what I saw of postgis-versioned module.
jgarnett has changed the topic to: 0) what is up 1) GeoTools 2.4.2 release 2) update headers
aaime: jgarnett, eh, as they say, plan to redo once
aaime: with some modifications to the query support I could do it better
desruisseaux has changed the topic to: 0) what is up 1) GeoTools 2.4.2 release 2) update headers 3) gt2- prefix removal
aaime: without making it postgis specific at al
jgarnett: indeed
gdavis: Topic: unsupported/process module committed
jgarnett: well it would be fun to see the same api backed on to arcsde versioning madness
jgarnett has changed the topic to: 0) what is up 1) GeoTools 2.4.2 release 2) update headers 3) gt2- prefix removal 4) progress module
aaime: jgarnett, yes, that's a reason I did not try to push the versioning interfaces into gt2-api
aaime: (lack of 2nd and 3rd implementation of the concept)
jgarnett: oh: I did look at the renderer; there are a few hacks to check if query was implemented (with respect to reprojection), I cannot tell if they are used - but they exist.
aaime: any other topic?
jgarnett: aaime++ yeah; I think we have 3 clients for the process module so I am hopeful this one will work; but also wanting to check on Eclesia.
jgarnett: I think we better start...
jgarnett: 0) what is up
desruisseaux: Martin: full time on postgrid...
***aaime trying to get geotools 2.4.2 out of the door
jgarnett: jgarnett - hacking up process module with gdavis; going to build a swing user interface for fear of putting too much information in javadocs where it would be ignored.
gdavis: gdavis: same as jgarnett
SamHiatt: whooops... I'm not really away.
SamHiatt: Too late to add a topic?
aaime: no, if it's a quick one
CIA-31: jgarnett * r29830 geotools/gt/modules/unsupported/process/src/ (15 files in 10 dirs): code review of process module part 4, finally with example and test case
SamHiatt: Just concerning how to fram the postgrid stuff once it makes it to gt-unsupported
aaime has changed the topic to: 0) what is up 1) GeoTools 2.4.2 release 2) update headers 3) gt2- prefix removal 4) progress module 5) postgrid in gt2
jgarnett: 1) GeoTools 2.4.2 release
jgarnett: aaime floor is yours
aaime: Any objection for me to go and release?
aaime: (any solid objection)
desruisseaux: All right on my side
jgarnett: sounds good.
aaime: ok
SamHiatt: why would I object?
jgarnett: (If you had a few moments to look at GeoServerOnlineTest case (and see if I am missing something stupid) it would make me happy - I hate the WFSDataStore not working)
CIA-31: jdeolive * r29831 /geotools/tags/2.4.2/: Tagging gt2 2.4.2
jgarnett: do you need any help on the release aaime? Jira and what not...
aaime: (that is really me using jdeolive account)
jdeolive: its /me twin from the alternate universe
jgarnett: aaime++ good way to confuse svn blame.
aaime: jgarnett, announcements as usual beat the hell out of me
jgarnett: anything else for this topic?
aaime: jgarnett, sorry, I'm using a shared VM
jgarnett: okay ping me when you have the anouncement text ready; sending email is a good "Waiting for the build" task.
aaime: I'll do... tomorrow
jgarnett: so ... next topic?
aaime: now I don't even know if I have enough time to make a deploy so that Mike can release GeoServer
aaime: yap
jgarnett: 2) update headers
jgarnett: martin and acuster answered some of my questions last week
jgarnett: so if we have some hot shot with regular expressions
jgarnett: we should be able to get 90% of the library in one shot...
jgarnett: (I think we are now the only origional inccubation progject still going ...)
jgarnett: link is here: http://docs.codehaus.org/display/GEOTOOLS/Graduate+from+OSGeo
jgarnett: we need a search replace for (C) ********, GeoTools Project Managment Committee (PMC)
jgarnett: (C)

Unknown macro: {1}

, Open Source Geospatial Foundation (OSGeo)
jgarnett: (or whatever the syntax is...)
jgarnett: any takers?
SamHiatt: I might be able to help with that...
aaime: SamHiatt, do you have committer access?
aaime: (in any case, you could try to setup an ant script to do the rename and have someone else run it)
SamHiatt: However, I'm probably not the best candidate for the job at the moment...
aaime: I guess no one is better than the only candidate
jgarnett: note; we still have to review the result; but no sense working hard.
SamHiatt: Haha...
jgarnett: I think eclipse search and replace can handle it; I may try later.
jgarnett: SamHiatt can I email you if I fail?
SamHiatt: No, I am not a GT committer...
jgarnett: fair'nuff
desruisseaux: I may ask Cédric to help me on this one for the metadata, referencing and coverage module, and ask peoples if we run the script on other modules. But not right now...
SamHiatt: jgarnett:
jgarnett: thanks...
SamHiatt: sounds good...
jgarnett: 3) gt2-prefix removal
jgarnett: martin? I think ...
SamHiatt: I was planning on doing the same kind of thing.
SamHiatt:
desruisseaux: Cédric refreshed the gt2-prefix-removal branch.
desruisseaux: I think we are ready for a merge with trunk
jgarnett: so what does that actually mean? we need to change our maven dependencies in geoserver?
desruisseaux: But I probably need to remind what it is about
desruisseaux: and what would be the consequence.
desruisseaux: Yes, the Maven depencies would need to be updated.
aaime: what was the status for the eclipse users? (since that was the blocker last time)
desruisseaux: Eclipse can now include the version in the module name
jgarnett: I thought jdeolive found some magic setting.
jdeolive: yes
jdeolive: there is a property you can set to se the pattern to be used for the eclipse projection name
desruisseaux: This is not a very robust workaround, but it would work as long as Geotools's main doesn't have the same version number than Geoserver's main.
jdeolive: i think you could use the groupid to get around it
desruisseaux: Maybe, I don't know about the Eclipse plugin...
desruisseaux: (I'm on Netbeans)
desruisseaux: As a side note, GeoAPI site is now generated every day by Hudson (since last week).
desruisseaux: The goal of this gt2-prefix removal is to do the same with GeoTools
jdeolive: doing maven eclipse:eclipse -DprojectNameTemplate=[groupId].[artifactId]
jdeolive: woudl do it
jgarnett: so we would need to modify our developers guide instructions justin?
jgarnett: I will do so now...
desruisseaux: Thanks Justin Sound like a much cleaner approach than version number.
jdeolive: np
aaime: which version of the eclipse plugin does support that?
jgarnett: (or can we bake that setting into the pom.xml ?)
jdeolive: yup
jdeolive: butn ot eveyone might want it through
aaime: (in gt2 we have declard version numbers, we're not using "lastest and greatest")
jdeolive: aaime: correct
jdeolive: i think we might need to upgrade the version of the eclipse plugin
jdeolive: which might mean people have to upgrade maven
jdeolive: what is the current receommended version?
aaime: release guide says 2.0.5
aaime: but I've been using 2.0.8 for the latest releases I made
SamHiatt: I'm on 2.0.8...
desruisseaux: I'm on 2.0.8 as well
desruisseaux: (linux box)
jgarnett: (updated http://docs.codehaus.org/display/GEOT/2.5.8+Maven+Eclipse+Plugin+Goals)
jgarnett: I think everyone is actually using 2.0.8 now...but email asking if we could switch to 2.0.8 did not get any response.
SamHiatt: (sorry... maybe off topic, but... does anyone have a problem with the latest maven-surefire-plugin?)
jgarnett: aaime; if that is what you are using for release
aaime: yep
jgarnett: I will update the developers guide instructions now.
desruisseaux: (Samuel: no issue with surefire on my side lately)
SamHiatt: (I have to specify version 2.3.1 to prevent build failures)
SamHiatt: (oh, well...)
aaime: (SamHiatt, sometimes we see "failure to load main class from surefirexxx.jar" on the build server)
desruisseaux: So is there any objection about going ahead with the gt2- prefix removal in module name?
aaime: (but it's random)
aaime: not really... what was the advantage again?
SamHiatt: (Hmmm... thx)
aaime: some site generation issue right?
desruisseaux: When generation the web site with "mvn install", URL are broken if the module name doesn't match exactly the directory name.
desruisseaux: (typo: when generating...)
desruisseaux: (typo: with "mvn site")
aaime: right right
jgarnett: did you not have a question about the "xsd" group of modules?
desruisseaux: Yes
desruisseaux: Actually Justin gave his agreement a while ago, but we wanted to verify that it was still possible (maybe the situation has changed).
desruisseaux: The xsd child projects have name like "xml-core", which doesn't match the directory name because of the "xml" prefix.
CIA-31: jdeolive * r29832 /geotools/tags/2.4.2/ (97 files in 97 dirs): Changed version number to 2.4.2
desruisseaux: The proposal was to put those child modules in a "org.geotools.xml" groupID, and remove the "xml-" prefix from the artifactID.
jdeolive: desruisseaux: yeah i agreed with that
jdeolive: and still like the idea
desruisseaux: Just two details (would like to known your preference):
desruisseaux: groupID: "org.geotools.xml" or "org.geotools.xsd"?
desruisseaux: (since the parent module is "xsd"...à)
jdeolive: right... hmmm... no huge preferemce... i think xml is more logical... but then i think there would be a collision with teh old xml module
jdeolive: since the root pom would be org.geotools.xml and so would the old module in library
jdeolive: woudl it not?
desruisseaux: At your choice...
jdeolive: lets stick with xsd
desruisseaux: Okay
jdeolive: that way we dont have to change any modules names
jgarnett: sweet
desruisseaux: Second minor details: should we add a "xsd-" prefix in the JAR name?
desruisseaux: (would be: gt-lib-ext-...)
desruisseaux: sorry
desruisseaux: gt-lib-xsd-...
desruisseaux: (assuming the XSD modules are in "library", I don't remember)
jdeolive: nope, extension
desruisseaux: Thanks. Would be gt-ext-xsd...jar then
jdeolive: would this just be for release artifacts?
desruisseaux: This is just the JAR name
desruisseaux: The module name don't have any prefix.
desruisseaux: But we use Maven <finalName> construct for adding those prefix automatically in JAR names only.
jdeolive: is this the same name as the jar will have in teh local maven repo?
jdeolive: that will still be just artifactId-version.jar correct?
desruisseaux: Yes
jdeolive: cool
jdeolive: yeah i am fine with that
desruisseaux: Okay, we will go ahead with that then. Thanks!
jgarnett: 4) progress module
jdeolive: desruisseaux: suggestion
jgarnett: opps
desruisseaux: Yes?
jdeolive: we might want to clear out old artifacts in the online repositories, at RR and the one youg uys mirror
desruisseaux: Yes I agree
jdeolive: cool
ticheler [n=ticheler@87.1.7.2] entered the room.
CIA-31: jdeolive * r29833 /geotools/tags/2.4.2/README.html: Updated README file
jgarnett: may make checking out and building an older udig impossible..
desruisseaux: But it may be safe to wait a few weeks, until uDig and Geoserver (at least) updated their dependencies.
jgarnett: not sure that we care?
jdeolive: agreed
jdeolive: see mailing list, user confusion
jgarnett: we can update udig the moment you are done.
jdeolive: and our builds might keep kicking along not updating geotoosl aritfacts
jgarnett: okay ... moving on?
jgarnett: 4) progress module
jgarnett: gdavis you have the floor
SamHiatt: I ain't away!
gdavis: so the process module is committed under unsuported currently
gdavis: with the interfaces, etc, and currently one implemented process
gdavis: I guess I'm looking for any feedback on what's currently there
gdavis: if anyone wants to try making another process and see if they run into any walls or problems
gdavis: if not I will continue on
SamHiatt: What kinds of modules are in there?
gdavis: also, i will be making 2 new modules next
aaime: the new ones, and the old ones without a maintainer
gdavis: one for a wps client, and one to hold beans/bindings
gdavis: does anyone have any feedback about where the beans/bindings should live?
jgarnett: (the beans may exist in geoserver; which is currently providing a home to wfs 1.1 beans as I understand it?)
aaime: what binding framework are you going to use?
aaime: jgarnett, correct, thought it would be better to move all those bindings to gt2
gdavis: which is why we thought we should do that for this module from teh start
aaime: so you're using xml-xsd bindings?
gdavis: yes
gdavis: should I be making a new module just for the beans/bindings?
jgarnett: kudos to jdeolive on the documentation btw - it really helps
aaime: Ok. Remember to ask before creating those two modules (the procedure is alays the same)
aaime: (jgarnett, if someone wonders who's bombing lists.refractions.net, that's me doing the deploy)
jgarnett: understood; I can give an update on server hell after the meeting
gdavis: ok, I think I've done my spiel
jgarnett: anything else on the process side of things? I do wish Eclesia was here as having three clients to drive the api would really help my trust.
gdavis: i would welcome any feedback anyone has after looking over the current process api
jgarnett: okay moving on ...
desruisseaux: I can ask Eclesia tomorrow if he can contact you Jody
jgarnett: 5) postgrid in gt2
aaime: SamHiatt, this is yours
jgarnett: (thanks martin; it would really help; we will try and have a swing example for him)
SamHiatt: So I just wanted to quickly share my ideas for PG
SamHiatt: At the FOSS4G 07 Geomatys was the only group I found doing anything to organize and serve nD coverages...
SamHiatt: I would hope that by the time FOSS4G08 rolls around that we will have PostGrid somehow integrated into GT so that GT can boast of having an ND solution for Grid Coverages.
jgarnett: I got a couple of questions
SamHiatt: IFREMER, as well as my group, Ecocast, will have some cool stuff to show by then...
jgarnett: I have been watching this work take shape over a while ..
jgarnett: and I have it in my mind that I was going to check it out
jgarnett: when two things happened:
jgarnett: - some kind of geoapi interfaces were set up for me to review
jgarnett: - some kind of data access api was actually agreed on by simone and martin
jgarnett: Are either of these things in store? If not how do you expect to interrate with geotools?
desruisseaux: I can bring some more point here:
jgarnett: the current solution of client code making use of GridFormatReader scares me
desruisseaux: Jody has raised one of the issue that I see with postgrid integration with GT.
desruisseaux: The issues are:
SamHiatt: I should point out here that I don't know the details....
mcoudert [n=mcoudert@AAnnecy-256-1-12-49.w90-10.abo.wanadoo.fr] entered the room.
desruisseaux: - For now PostGrid avoid any use of GridFormatReader. It interact directly with ImageIO. I don't know it it is acceptable for GeoTools (for sure it is not an example of what to do).
desruisseaux: The plan was to refactor it when some kind of GridCoverageStore would be ready, but we are not yet there.
aaime: right right
aaime: we should find some time to define a GridCoverageStore indeed
aaime: I think everybody wants it
aaime: it's just that nobody seems to have time
SamHiatt: I would be interested in being involved in that discussion.
aaime: SamHiatt, everybody would
SamHiatt: Can you point me to any past discussions/wikis on the issue so I can get up to speed?
aaime: we need someone that takes the time to do the heavy lifting or
aaime: of setting up a proposal
desruisseaux: 2) Postgrid test suite is hard to setup. It could take a while before a postgrid integrated in GT has a test suite run at "mvn install" time.
aaime: creating a prototype implementation
aaime: desriusseaux, that would only mean it would take a while before it goes into supported land
jgarnett: simone already agreed to this approach: http://docs.codehaus.org/display/GEOTOOLS/GridAccess+based+on+WCS+Specification
simboss: I am planning to put ou something before the end of the month
SamHiatt: desruisseaux: I plan on fixing the test suite, at least for my case...
SamHiatt: perhaps I could help with that.
aaime: jgarnett, I like the general idea (based on WCS)
simboss: we are doing some work to support Eo time series for ESA
jgarnett: but was sad when it was not discussed and accepted at the same time as groldan's data access stuff.
aaime: but the names are scary
jgarnett: The names?
aaime: GridAccess... arg, reminds me of the dreaded DataAccess
jgarnett: (ah
jgarnett: I don't care about the names this instant
SamHiatt: this sounds cool.
jgarnett: more that developers can set aside some time to work together)
jgarnett: Honestly "Raster" rather than "Grid" may be better all around for everyone
aaime: moreover, there is no metadata access there, which is bad (we lakc the equivalent of DataStore.getSchema())
SamHiatt: I agree, jgarnett;
jgarnett: indeed; page is there to record what people think are a good idea.
simboss: well if samhiatt ha some time
aaime: Grid comes from the specs thought
simboss: has
simboss: he can start throwing some ideas up on the wili
simboss: wiki
SamHiatt: I'll read up on the issue and offer my input.
desruisseaux: Maybe because Raster is typically though as 2D while grid can be ND?
simboss: as a start
aaime: SamHiatt, you subscribed to the ml?
SamHiatt: I'll start throwing my ideas all over the wali.
jgarnett: cool; thanks guys - I am happy to review (I am so tired of this problem frustrating everyone)
aaime: (since it's a better place to discuss, wiki is better to store the results of the discussion)
jgarnett: martin had a second issue... where did it go?
desruisseaux: I'm here
SamHiatt: Ok, so "raster" isn't the best either.
desruisseaux: The second issue was test suite hard to setup.
SamHiatt: I like the idea of "ND Coverage" or something
aaime: (the 3d equivalent of raster being voxel)
sfarber [n=sfarber@88-149-177-23.static.ngi.it] entered the room.
jgarnett: any thoughts on that one martin?
SamHiatt: aaime, I think I am on the ml...
SamHiatt: but I don't have time to keep up with much of it.
aaime: nice
jgarnett: set up the database on the build server or something ... or boil all the setup steps into a java class people can run.
desruisseaux: A third issue is that current postgrid code still have strong links with its original purpose, which was to perform statistical analysis that may not be of general interrest. So some part would probably need to be trimmed down, but it may take a little while before it can be separated without breaking the statistical stuff.
aaime: SamHiatt, I just don't want the wiki page to degerate on a comment mess
SamHiatt: VoxelAccess?
jgarnett: martin you may be able to hide the stats stuff behind gdavis's process module.
jgarnett: (just a thought)
desruisseaux: Yes sure I should look at time, but the usual problem is that I'm slow...
zzorn [n=zzorn@212.16.103.33] entered the room.
zzorn_ [n=zzorn@212.16.103.33] entered the room.
jgarnett: so we are a few mins past meeting time; just a warning that we need to wrap up.
jgarnett: darn ...
jgarnett: SoC
zzorn left the room (quit: Read error: 104 (Connection reset by peer)).
jgarnett: deadline was today; there are lots of proposals for people to review this week.
SamHiatt: Cool...
jgarnett: Something we can take out to the mailing list this year; one email thread per proposal?
jgarnett: You are done SamHiatt?
SamHiatt: Yeah, sounds great!
jgarnett: okay thanks for the efficient meeting everyone. happy hacking.
jgarnett: I will post the logs.
aaime: thanks
SamHiatt: Thanks!
aaime: 2.4.2 is up on the repos
SamHiatt: Yay!
aaime: I'll do the rest of the release procedure tomorrow

IRC Logs March 31

-1) chatter as people arrive one hour early due to time switch
0) what is up
1) SoC deadline extended
2) svn cut off
3) IRC one hour earlier; motion passed!
4) WPS module, Process module

acuster: when's the meeting?
acuster: 1/2 hour or 1 1/2 hour?
jgarnett: 1.5 hours I think?
jgarnett: meeting expressed in GMT right?
jgarnett: GMT does not have DST to the best of my knowledge.
***acuster thought it was UMT that stayed fixed
jgarnett: not sure myself.
jgarnett: I will be online at both times
acuster: for you it should be the same time as it was last week
acuster: so 1.5 hours it is
jgarnett: okay
gdavis: jgarnett
gdavis: what is the URL to that WPS page?
jgarnett: finding it ...
jgarnett: http://docs.codehaus.org/display/GEOTOOLS/Process+proposal
jgarnett: (it was not listed under proposals
jgarnett: as Eclesia was being shy)
jgarnett: I will move it now
jgarnett: since we are actually interested...
gdavis: thanks
jgarnett: It is not really written up as a "Proposal"
jgarnett: there is a specific template
jgarnett: with
jgarnett: - status - so we can see what the votes were
jgarnett: - tasks - so we can be sure people actually have the full amount of work accounted for (documentation and tests often get left out)
jgarnett: feel free to edit that page; fix the examples or whatever.
gdavis: ok
jgarnett: also comments are good.
jgarnett: Parameter.filter may be useful; so we can specify length( value ) < 255 for example
jgarnett: you may need to review ProgressListener to understand how this works; but you know Eclipse ProgressMonitor.
jgarnett: (http://docs.codehaus.org/display/GEOTDOC/ProgressListener)
gdavis: thnks
jgarnett: so a geoserver process engine
jgarnett: would make its own "ProgresListener"
jgarnett: and use that to stop the job
jgarnett: for figure out status.
jgarnett: basically a callback object.
gdavis: right
jgarnett: that keeps things from being insance when writing a your process.
jgarnett: we have adaptors in uDig
jgarnett: from eclipse ProgressMonitor to this ProgressListener api
acuster: jgarnett, did you get feedback from Tyler as to who he has (c) assignment forms for?
acuster: or are we working from intent?
groldan n=groldan@217.130.79.209 entered the room.
ralbertini n=ralberti@88-139-140-12.adslgp.cegetel.net entered the room.
ralbertini left the room.
jgarnett: hello
jgarnett: acuster
ralbert3 n=ralberti@88-139-140-12.adslgp.cegetel.net entered the room.
jgarnett: we are working from the internet page here (http://docs.codehaus.org/display/GEOTOOLS/GeoTools+Contributor+Status)
jgarnett: it contains a green (tick) next to each person who has told me they are sending tyler a document.
jgarnett: that is enough to call the list this month.
jgarnett: Let's check with tyler after we have given people a chance to panic.
acuster: ok
jgarnett: I sent an email out; seems we are culling about half the accounts?
jgarnett: The good news is we have a bout 40 contributors that are active enough to a) respond and b) sign a document.
***acuster didn't realize udig was on 2.2
jgarnett: (oh wait that includes organizations; one green (tick) per document sent to osgeo central)
acuster: that's a long way back
jgarnett: yeah.
jgarnett: well we could not keep up
jgarnett: given the QA on 2.3.
jgarnett: sad for the udig development community however.
acuster: looks like everyone is going to be asking you for help on udig
jgarnett: less time for geotools that is for sure.
desruisseaux n=chatzill@mtd203.teledetection.fr entered the room.
jgarnett: hi Martin
jgarnett: I wrote a Range class
jgarnett: but have not committed it yet.
jgarnett: :-D
aaime n=aaime@host146-41-dynamic.6-87-r.retail.telecomitalia.it entered the room.
desruisseaux: Hello Jody
jgarnett: thought I would give you a chance to panic first.
aaime: ?
jgarnett: I cannot tell if the meeting starts now; or in an hour.
jgarnett: Range is the only reason referencing depends on JAI
jgarnett: as such it keeps our referencing jars from being used in OpenJUMP (and indeed lots of places).
ralbert3 left the room (quit: Client Quit).
jgarnett: It was almost dropped for a server app at refractions (a geocoder) because of the JAI thing.
desruisseaux: I think you can commit you class. The next step would be to spot the place where there is explicit dependency to Range (not to a subclass like MeasurementRange)
jgarnett: martin has a bug report somewhere.
ralbertini n=ralberti@88-139-140-12.adslgp.cegetel.net entered the room.
jgarnett: understood; I am going to get myself happy with the test cases first.
desruisseaux: Thanks (smile)
jgarnett: Do you know if it actually occurs as a dependency in client code? The use of Range?
jgarnett: javax.jai.util.Range that is.
desruisseaux: Not sure - we really need to search. But I believe that most dependencies are toward NumberRange or MeasurementRange.
jgarnett: also if we don't use subtract; I may not implement it.
jgarnett: cool.
jgarnett: part of my motivation was the nice graph gabriel emailed about
jgarnett: from a gvSig presentation.
jgarnett: http://www.osgeo.org/tyler/event/espana_sig_libre_2008
jgarnett: http://www.osgeo.org/files/tyler/images/siglibre_foss_sig_relacion.html
jgarnett: pretty silly graph
jgarnett: but reminds me that we can do a lot of good
jgarnett: if we can carve off referencing jars as a seperate download for others
jgarnett: (and thus start them on the road of using geotools)
jgarnett: so is the meeting now? or in an hour?
groldan: hi
groldan: I just assumed it is in an hour
groldan: though got alert just in case
jgarnett: cool
jgarnett: groldan the geoserver 1.7.0-alpha1 released
jgarnett: that was done today
jgarnett: was that done with GeoTools trunk?
groldan: since nobody said anything regarding it, it made sense the actual meeting time not to change
groldan: yup
jgarnett: sweet
jgarnett: I want to see if I can use that for udig walkthough 1
jgarnett: (since it should not lock up on shapefile layers)
groldan: go with my bless
jgarnett: heh; go with a QA run to see if it works
jgarnett: (a lot of the transaction stuff seems stuffed with geoserver later than 1.4.1; I can no longer parse the TransactionResponse documents!)
groldan: uDig was doing pretty well for the "normal" stuff last time I tried
groldan: besides the known broken bits
jgarnett: could not edit as per walkthough 2
jgarnett: did you try?
jgarnett: (shapefile editing woudl deadlock geoserver)
groldan: I tried some edits through geoserver->arcsde
jgarnett: that sounds promissing.
groldan: not sure about shp
jgarnett: any word on your arcsde hacking?
groldan: (sad)
jgarnett: (shp is a complete rewrite on geotools trunk now; needs lots of testing)
groldan: one thing for gt-wfs on trunk + udig
acuster: jgarnett, can you flesh out your 'required cleanup on gt trunk' email? It would serve as a good start to 2.5 final, no?
groldan: last change I did was to revert the wfs plugin to use 1.0 protocol as default
groldan: ping me if that doesnt work
jgarnett: confused; which email list... oh; what GeoTools 2.5 needs fixed for uDig to be happy
jgarnett: ah
jgarnett: it does not work; see GeoServerOnlineTest
jgarnett: when that passes uDig is happy with GeoServer.
jgarnett: You need a geoserver running on local host.
jgarnett: It now runs all the tests except the last one
jgarnett: looks like deleting a feature produces a bad TransactionResponse that cannot be parsed.
groldan: me is back to hack mode
***groldan forgot the /
acuster: martin has: review of work on referencing by Refractions and by the SoC student; changing module names to drop the gt2 prefix
acuster: prior to 2.5
aaime: prior to relasing 2.5 we need to get back the 2.4 performance
aaime: releasing a 3 times slower gt2 is not good advertising
desruisseaux: Which parts is slower?
aaime: the new feature model
acuster: jgarnett, how do we deal with cedric who is covered by geomatys but has not sent in a doc?
acuster: jgarnett, do I add him to your list anyhow?
desruisseaux: Actually Cédric as signed and sent the agreement.
desruisseaux: (typo: as --> has)
acuster: added;
jgarnett: back
jgarnett: as long as he has sent me an email
jgarnett: then I will place a (tick) next to his name.
jgarnett: martin if you know he has sent the document can you send me an email?
***acuster is adding him
jgarnett: I did not do this stuff on the email list as people occasionally tag in their managers; or have company level concerns. I could also not use the admin list as managers and so on would not of been subscribed.
desruisseaux: Will ask Cédric to send the email tomorrow (just to be sure).
jgarnett: thanks muchly.
vheurteaux: jgarnett: document sended 2 weeks ago
vheurteaux: for Cédric
simboss: ciao all
simboss: I am a bit late (sad)
acuster: early
jgarnett: trying to catch up with the comments;
acuster: jody: martin is sending you an email
jgarnett: simboss you are a bit early.
simboss: early? then I can leave and come back late (smile)
jgarnett: indeed.
simboss: forgot about the time change
aaime: jgarnett, is it holiday in Canada?
aaime: (today?)
jgarnett: nope
jgarnett: I think we just have a DST thing
jgarnett: for europe right?
acuster: EST
jgarnett: today is not a holiday.
acuster: or some such
acuster: http://en.wikipedia.org/wiki/Central_European_Summer_Time
aaime: jgarnett, yes, we switched to daylight savings yesterday
jgarnett: so the question is
jgarnett: or was
jgarnett: does our meeting time switch? and the answer I think was no ...
jgarnett: I am interested in martins feedback on referencing factory stuff;
jgarnett: SoC was given until April 7th for students.
desruisseaux: I have not yet looking at referencing things, but it is something I would like to do before the 2.5 release if it can fit in the timeframe...
desruisseaux: (typo: not yet looked...)
jgarnett: understood
jgarnett: yeah it would be good to sort that our for the 2.5 timeframe.
jgarnett: thnk it is already marked as technical debt?
desruisseaux: Could you remind me the URL for technical debts please?
desruisseaux: (searching right now just in case I remind it by myself...)
jgarnett: http://docs.codehaus.org/display/GEOTOOLS/Technical+Debt
desruisseaux: Thanks
jgarnett: nope
jgarnett: not listed; I was focused on stuff that had nobody paying attention.
jgarnett: You at least knew about the referencing factory stuff.
jgarnett: acuster: I have updated this page - http://docs.codehaus.org/display/GEOTOOLS/2.5.x
desruisseaux: Thanks (smile) Editing the page...
jgarnett: to list the stuff for uDig acceptance.
desruisseaux: (as a matter of principle)
jgarnett: just a sec I will list the udig acceptance things in order of priority.
desruisseaux: No problem, I will wait
ralbertini left the room (quit: Read error: 110 (Connection timed out)).
CIA-24: dadler 2.4.x * r29745 geotools/modules/unsupported/db2/src/ (13 files in 3 dirs): GEOT-1753 - use WKB
jgarnett: oh not to worry martin; I was editing the 2.5.x page for acuster
jgarnett: and I am done now; except the site seems slow.
jgarnett: note cedric was already listed with a (tick) next to his name...
jgarnett: back in a bit; going to grab food before the meeting (yum!)
jgarnett: acuster I am happy with the 2.5.x page now; it shows what is needed for uDig to "be happy" with 2.5.x
ticheler n=ticheler@87.1.30.71 entered the room.
jgarnett: lots of people today.
acuster has changed the topic to: IRC Meeting – 0) What is up
jgarnett: meeting time? agenda topics etc...
acuster has changed the topic to: IRC Meeting 31 March 2008 – 0) What is up
jgarnett has changed the topic to: IRC Meeting – 0) What is up 1) SoC deadline extended
jgarnett has changed the topic to: IRC Meeting – 0) What is up 1) SoC deadline extended 2) svn cut off
desruisseaux: Topic: can we move the IRC time one hour earlier?
desruisseaux has changed the topic to: IRC Meeting – 0) What is up 1) SoC deadline extended 2) svn cut off 3) IRC one hour earlier?
acuster: clap, clap, clap martin. Yep, that's how you set the topic
desruisseaux: Thanks Adrian (smile)
desruisseaux: (Adrian just learned me /help as well (smile) My knowledge of IRC is minimalist...)
jgarnett: gdavis ping?
jgarnett: well it looks like it is time to start?
gdavis: hi
jgarnett: gdavis was going to talk abit about WPS / Process stuff; but he does not seem to be at his computer.
gdavis: im here
jgarnett: oh; you are here - want to grab a topc?
gdavis: should I just edit the title myself?
gabb n=groldan@217.130.79.209 entered the room.
jgarnett: yep
groldan left the room (quit: Nick collision from services.).
gabb is now known as groldan
gdavis: !topic
gdavis: er
gdavis: how do I do that?
jgarnett: type in your window 4) xxxx
jgarnett: and I will add it (smile)
gdavis: 4) discuss WPS module
gdavis: uh
jgarnett has changed the topic to: IRC Meeting – 0) What is up 1) SoC deadline extended 2) svn cut off 3) IRC one hour earlier 4) WPS module
jgarnett: okay lets start
jgarnett: 0) what is up
desruisseaux: Martin: works on postgrid...
acuster: acuster — reviewing Name/NameImpl;GenericName;QName; trying to get back to feature
jgarnett: jgarnett; I am bashing my head against uDig trunk (as such I am fixing things randomly as they stop me in geotools trunk; thanks for everyone for putting up with a raft of filter changes last week). I have also identified javax.jai.util.Range as the only reason referencing needs JAI - as such I am writing up a replacement so we can carve referencing off as a seperate download for JTS powered projects.
gdavis: gdavis: planning new WPS/Process modules
***aaime working on some commercial stuff for TOPP
***groldan have been fixing bugs for 1.6.3, no gt/geoserver today yet though
jgarnett: cool
jgarnett: 1) SoC Deadline
jgarnett: has been extended; mentors visit the page and see if any geotools projects have come in I guess.
jgarnett: I had a paniced student asking about GeoIRC on the weekend.
jgarnett: anyone else?
desruisseaux: Not on my side
jgarnett: (http://code.google.com/soc/2008/mentor_home.html)
jgarnett: wow there are lots more available today
jgarnett: (last week there was like one)
jgarnett: I think students have been given another week; shall we discuss these on the email list as we find them?
jgarnett: unless there are any students here who would like to say hi.
jgarnett: I see a KML reader for GeoTools (smile)
jgarnett: H2 spatial index
jgarnett: Raster polygonizer for GeoTools
jgarnett: and some udig / geoserver specific stuff.
jgarnett: moving on ...
jgarnett: 2) svn cut off
jgarnett: today is the day ... we have 40 people left after the cut off. If your name is not on the list send me email.
jgarnett: 35 people will be cut; most of them are SF Ids that have not been heard of in years.
jgarnett: List is here: http://docs.codehaus.org/display/GEOTOOLS/GeoTools+Contributor+Status
acuster: thanks for all the hard work jody
jgarnett: For those of you with new employees; team members; ideas for new modules etc... there are a few extra steps to getting commit access (most important is sending a contributors agreement away to OSGeo central).
jgarnett: acuster did we ever update the developers guide to your satisfaction?
jgarnett: I also wanted to ask if you had talked to Bryce about Public Domain code...
acuster: ?
acuster: no, but I'll talk to him; either way we are in the clear since the code is in the public domain
jgarnett: Developersg Guide; instructions on how we run our project; need to make sure the GeoTools Contributors Agreement is covered.
jgarnett: understood.
acuster: ah
acuster: I'll look into that
jgarnett: This page: http://docs.codehaus.org/display/GEOT/2+Committers
jgarnett: seems to have it ...
jgarnett: any other comments? I won't even touch updating our headers this week :-D
jgarnett: thanks acuster.
jgarnett: 3) IRC one hour earlier
jgarnett: This one is you martin.
aaime: me too! (smile)
aaime: I'd like to move the meeting one hour earlier me too, if possible
desruisseaux: Given the change in European time, would peoples agree about an IRC one hour later?
jgarnett: can we leave this thing at some kind of fixed time; and not have to change due to DST?
desruisseaux: (so it stay at the same hour for european)
jgarnett: I will agree; but I would like it to remain a fixed time...
simboss: +2
groldan: +1
simboss: (smile)
jgarnett: I understand this is more of an issue for europe since this is around supper time.
jgarnett: is there a time that would work for you guys; even when the clock switches back?
desruisseaux: It is 22h00 in France.
desruisseaux: (22h35 right now)
aaime: yep
jgarnett: So in the fall; if it is 20:35 in france; would that be okay?
jgarnett: ie we take it back an hour now
jgarnett: and then DST kicks in and kicks it back another hour.
aaime: not for me (wink)
jgarnett: (just a question)
desruisseaux: Earlier would be nice, but I though that we were late in order to allow Australian to assist (I believe it is something like 6h00 AM for them?) Do we still have Australian around?
jgarnett: I don't really want to cycle the meeting time twice a year like we have been doing.
jgarnett: mleslie is in australia now
jgarnett: mleslie ping?
aaime: jgarnett, why? I don't see the issue
aaime: it just happens twice a year?
jgarnett: actually 4 times a year; since we have different days for switching in NA and EU now
jgarnett: and the topic comes up as each group is confused.
jgarnett: so I can vote +0 on this one; and +0 again in the fall.
aaime: I would not find it less confusing if
jgarnett: just wanted to see if there was a time that would work year round.
acuster: right now we have 8:00 UTC/GMT
aaime: we used a fixed gmt time (wink)
acuster: or I should say 20:00
aaime: anyways, +1 on moving the meeting one hour earlier
jgarnett: that is what the developers guide says
jgarnett: http://docs.codehaus.org/display/GEOT/3.1+Internet+Relay+Chat
jgarnett: http://www.timeanddate.com/worldclock/fixedtime.html?day=9&month=1&year=2006&hour=20&min=0&sec=0&p1=0
aaime: jgarnett, I've found that site to lie lately
desruisseaux: I'm +1 for our hour earlier of course. Anyone know if we have Australian around to ask for?
aaime: wrong DST for USA afaik or something like that
jgarnett: mleslie but he is asleep it seems. so no awake australians.
jgarnett: so question
aaime: Australia should be moving to solar time soon afaik
jgarnett: looks like the vote is carried.
aaime: (if it did not already do that)
jgarnett: do we need to update the developers guide page above? or is it already correct.
aaime: (it's the beginning of fall there)
acuster: the guide needs to change, the link should die (as a live link)
acuster: if the time moved, that is
jgarnett: okay so vote is done; motion carried etc... can someone volunteer to update the page (smile)
jgarnett: (to whatever link is needed)
jgarnett: 4) WPS module
jgarnett: gdavis this one is yours...
gdavis: ok, so I am currently planning to create 2 new modules for WPS related work. The initial idea is outlined by Jody here: http://docs.codehaus.org/display/GEOTOOLS/Process+proposal
aaime: wps module in geotools? client?
gdavis: I plan to create one module called process for a simple Process API to define processes. A second module called wps will use this new module to build up support for the WPS spec.
jgarnett: (actually that idea is for a process api; Eclisia is the origional guy)
gdavis: ok
gdavis: the process api is basically interfaces for creating processes, not necessarily wps specific
gdavis: the wps module will use this
jgarnett: anyone know where Eclesia is?
aaime: not sure I understand why there is a wps specific module in geotools, unless you're plannign to make a wps client?
gdavis: i will be making a wps client, in udig
groldan: I guess the idea is to produce a process framework in geotools, that a geoserver plugin service could wrap as a wps?
jgarnett: correct aaime; same style as wms client code (no abstraction)
gdavis: right
aaime: and the same module would be used by a geoserver wps service?
gdavis: yes
aaime: wow, that's a first, should be interesting to look at (wink)
jgarnett: and the "wps" client code would be used by geoserver when chaining
gdavis: anyways, these are the first steps towards a fully working wps service
aaime: (a module used both by clinet and server side that's not a datastore, that is)
acuster: [ meeting time updated on web page ]
jgarnett: ah; you guys never did WMS chaining?
aaime: thanks a lot acuster
jgarnett: (like cubewerxs?)
aaime: WMS cascading you mean?
jgarnett: yeah; forgot what they called it.
aaime: We don't have the concept of a WMS layer in geoserver configuration
aaime: so no
jgarnett: okay cool.
aaime: it's not a feature type
aaime: and not strictly a coverage either
aaime: we would need to develop a whole new set of config classes and UI
jgarnett: so gdavis; you need a thumbs up from a geoserver PMC memeber to start.
jgarnett: and a wiki page or something for the module you are building
jgarnett: (same thing you did for unsupported/geometry)
gdavis: geoserver wiki page?
CIA-24: desruisseaux * r29746 geotools/gt/modules/library/coverage/src/main/java/org/geotools/coverage/grid/GridGeometry2D.java: Removed the getGridSize2D() method in order to keep the API simplier - this somewhat trivial method doesn't seem to worth its weight.
aaime: wow, wait, for the gt2 modules he needs a gt2 pmc member
jgarnett: do you want to send an email to geotools-devel when you got the wiki page set up?
jgarnett: bleck
jgarnett: sorry
aaime: the psc geoserver member is neended to make up a new geoserver community module
gdavis: yes. I will do that
jgarnett: aaime what is the procedure to start a geoserver communit module? do we need a formal GSIP? or just a thumbs up ...
aaime: just a thumbs up
jgarnett: (sorry if this is off topic for todays meeting)
aaime: you'll need a gsip to turn that into an official service
jgarnett: okay got it.
aaime: yet, better talk openly and widely
aaime: before that
jgarnett: for geotools you need to meet a bunch of QA hoops.
aaime: otherwise the gsip may turn into a nightmare
aaime: if the psc does not accept it
jgarnett: we have all seen it happen.
jgarnett: okay any other questions gdavis?
jgarnett: We are looking forward to this work.
gdavis: nope, i will get to work on the wiki page and then email the list
jgarnett: sweet.
aaime: gdavis, in all you're doing keep in mind a simple thing
aaime: you're dong the work and we're grateful
gdavis: yes, the geotools side will be quite simple
aaime: but someone else will have to maintain it long term
gdavis: (geoserver too)
jgarnett: I feel I should ask a seperate PMC member to review your wiki page etc; since I was involved in scoping out the origional collaboration between uDig and PuzzleGIS.
aaime: so you have to try and please those someone elses too
acuster: lol, 'quite simple'
acuster: it's harder than that
jgarnett: (note for the project scope page - http://udig.refractions.net/confluence/display/HACK/WPS - we have making the geotools api "simple" as a top priority)
aaime: usual application of the 20/80 rule
acuster: ah, good; as long as you are not expecting doing that to be simple
gdavis: ok, I will send off a list email soon with a wiki page you can look at
gdavis: thanks guys
aaime: np
acuster: we done?
acuster: wohoo!
aaime: yap
jgarnett: I can send the logs

IRC Logs March 24

Agenda:

  1. what is up
  2. SoC
  3. GeoTools contirbutor agreement
  4. arcsde datastore command design

<jgarnett> How are you andrea?
<aaime> it's holiday in Italy, not sure about other countries
<aaime> sick, my throat hurts
<jgarnett> is it warm enough for you to play tennis these days?
<aaime> and sick, my hope in Struts2 was demolished by a couple of days investigation
<jgarnett> We just had a storm; so the sky is scrubbed clean
<aaime> jgarnett, it is all year, I play indoor during winter
<jgarnett> that is interesting; the struts 2 part ... were they not bold enough?
<sfarber> yo, meeting time?
<aaime> jgarnett, not really, it's just that there is no tool support
<aaime> would you write java code with notepad?
<jgarnett> you had to do struts 1 in notepad.
<jgarnett> but I agree it is nobodies preference.
<aaime> well, jsp alternatives (freemarker) lack editors that can do html and the templating at the same time
<jgarnett> did you ever try the eclipse Web Tools plug-ins ?
<aaime> I have it installed, but we need to move away from jsp in order to have a pluggable UI
<jgarnett> I have not looked into struts 2 enough to know what they did different this time around.
<jgarnett> hrm
<jgarnett> well lets start the meeting...
<jgarnett> floor is open for agenda topics.
<aaime> I cannot think of any
<jgarnett> Saul I wanted to chat with you or gabriel to see what was going on w/ arcsde datastore; is gabriel realling moving to a command based system like WFSDatastore?
<aaime> dunno
<jgarnett> I was working at the same time as him and kept tripping up.
<jgarnett> hard to know with out email from him...
<aaime> 3...2...1
<aaime> ...0
<jgarnett> 1) what is up

  • aaime sick of java web frameworks (other than Wicket)
    <jgarnett> jgarnett - enjoying the holiday; looking into ESRI Web 2.0 about face; thinking about finishing up the user guide if we have some SoC students to read it.
  • groldan enjoying holiday too
    <jgarnett> okay moving on ...
    <jgarnett> 1) SoC
    <jgarnett> Simone was nice enough to get us a page going
    <jgarnett> I wonder if there are any students here today?
    <jgarnett> So far the difference for me has been a bunch of private emails asking how to install geotools.
    <jgarnett> Anyone else run into a SoC student?
    <aaime> not me
    <groldan> nope
    <jgarnett> http://docs.codehaus.org/display/GEOTOOLS/Summer+of+Code+2008
    <sfarber> jgarnett, sure thing. Let's chat after meeting?
    <jgarnett> If last time is any indication we won't get much until the last couple hours before the deadline; If I can ask everyone to mind the user list this week and do not hesitate to fix any of the documentation.
    <jgarnett> this will be a quick meeting
    <jgarnett> 2) svn cut off
    <jgarnett> I have gotten emails returned by most of the active developer community now
    <aaime> mail sent, hope it gets to destination
    <jgarnett> and surprisingly a lot of the inactive devel community. It has been really nice to hear how people are doing in their various paths in in life.
    <aaime> any interesting story?
    <jgarnett> So the good news is we will still have enough developers to continue after the svn cut off :-D
    <jgarnett> the list is here
    <jgarnett> http://docs.codehaus.org/display/GEOTOOLS/Summer+of+Code+2008
    <bullenh> uhh..
    <jgarnett> oops
    <jgarnett> http://docs.codehaus.org/display/GEOTOOLS/Graduate+from+OSGeo
    <jgarnett> yeah!
    <jgarnett> (sorry new firefox beta is occasionally tripping up)
    <jgarnett> It was nice to hear that RobA is enjoyig his new position; that Sanjay still exists and so on...
    <aaime> (new firefox beta is working a lot better for me than the old stable )
    <jgarnett> I also got a lot of feedback from those that are really happy about the OSGeo direction; excited that they will find an easier time getting funding for GeoTools work etc...
    <bullenh> (I really find the new gui much better in it)
    <jgarnett> the kind of thing that we considered when we joined; but have since lost excitement over.
    <jgarnett> So next Monday we will try and restrict svn access; and then we can update our headers.
    <desruisseaux> Thanks for doing that Jody!
    <desruisseaux> (I means contacting all those peoples)
    <jgarnett> well thanks for waiting; feel I delayed everything a bit doing it myself.
    <jgarnett> a mistake I won't repeat with the headers
    <jgarnett> So that may be it for the meeting ...
    <jgarnett> shall I post the logs; or just open up the floor for a general chat?
    <desruisseaux> I can not stay toonight on my side...
    <sfarber> jgarnett: you've got gabriel and me here...wanna talk arcsde?
    <desruisseaux> Bye all
    <jgarnett> well thanks for staying thus far.
    <jgarnett> sure
    <aaime> bye
    <groldan> sure
    <jgarnett> gabriel what are your plans for arcsde?
    =-= jgarnett has changed the topic to "0) what is up 1) SoC 2) One week till svn cut off 3) arcsde chat"
    <groldan> right now it should be editing versioned tables
    <groldan> next step is
    <groldan> to improve the threading handling a big deal
    <sfarber> from my end the current list is:
    <groldan> since the current approach is error prone and hard to maintain
    <sfarber> * support lots more arcsde raster types
    <sfarber> (float, double, colormapped 1-byte, non-colormapped 1-byte, etc)
    <groldan> the general idea is to control the threads sde operations are run at, in order to be able to execute more granular units of work concurrently
    <groldan> instead of locking a connection since a FC iterator is open until its closed
    <groldan> with that, we're joy
    <sfarber> * re-do the raster test suite in junit 4 style and taking a cue from gabriel so that the test load their own data.
    <sfarber> that's all from me: groldan:
    <jgarnett> I have not looked at JUnit 4 yet; it seems Andrea was all gung-ho to switch.
    <groldan> what do you gain redoing in junit4?
    <jgarnett> the work I was trying to do gabriel may be related to what you are doing. gabriel.
    <jgarnett> I was trying to put arcsde datastore on a diet
    <sfarber> with the connection locking are you proposing to override the SeStreamOp locking methods?
    <jgarnett> and make it still work when only one thread is available.
    <aaime> jgarnett, switch to junit4 completed
    <groldan> jgarnett: indeed, what you're trying to achiece may only be possible with something like that
    <aaime> you can use it in your modules
    <aaime> (just needed a change of version in 2 dependencies)
    <jgarnett> so I was capturing this as a subclass of arcsdedatastore; and then look at all the little methods and make the read-only ones reuse the existing connection
    <jgarnett> aaime is the junit4 something you want to just do for the whole library? Or is it more serious than that.
    <groldan> sfarber: looking for sestreamop lock methods...
    <aaime> we already have it for the whole library
    <aaime> junit4 contains junit3 classes as well
    <sfarber> ok, so the thread synchronization is going to be something that's enforced at the gt2-arcsde code level?
    <aaime> you can use both at the same time
    <groldan> what locking methods are those?
    <sfarber> groldan: one sec...let me get a little bit out and I think it'll be clear
    <jgarnett> (gabriel I agree; I think I should wait until after your work is done? Or at least review your design rather than guess. For a moment I was thinking you were doing something like the WFSDataStore transaction state diff where it keeps a list of "commands" and then applies them on the result as it is sreamed...
    <jgarnett> Do you have any design stuff we can read? Or just read the code ...
    <groldan> jgarnett: yes, it'd be of help to get you aborad to get to use a single connection, once that's possible
    <sfarber> so, groldan, you're proposing that everyone writing code at the gt2-arcsde datastore code level use a set of methods internal to the the datastore code to coordinate and use connections correctly?
    <groldan> nope
    <groldan> that's all arcsde plugin business
    <groldan> the thing is as follows (in my understanding):
    <groldan> -sde connections are not thread safe, yet a single thread can run various operations over it, which's what jgarnet needs
    <groldan> -we're handling transactions with sde native transactions, ie, held in the connection
    <groldan> so any transactional operation plus queries over a FeatureStore need to use the same connection
    <groldan> and often they're called concurrently
    <groldan> so the plan is to run all the operations over a connection in a single thread, which will allow
    <groldan> for a more granular locking
    <groldan> and hopefully the thing is gonna be easy with the java.util.concurrent.Executors framwork
    <jgarnett> thinking
    <jgarnett> single thread per Transaction you mean? A little command queue for each thread ...
    <groldan> yup
    <jgarnett> okay I am starting to get it
    <groldan> that's the only way I can see to avoid the performance overhead and maintainance nightmare right now
    <jgarnett> so I wasted a couple of days last week But now at least I can try and plan to take part later on ... provided you can tell me when that is?
    <sfarber> groldan:
    <groldan> I'm waiting for cholmes' go ahead, once I get it it'll take three work days
    <groldan> sfarber?
    <jgarnett> gabriel / saul should we of asked for a proposal / design doc for this?
    <groldan> hmm... I guess not?
    <jgarnett> okay; if it will help I can be available for the QA side of things at the end of your 3 days.
    <groldan> sounds good, sure
    <sfarber> ok groldan, so how will this affect someone calling "ArcSDEPooledConnection.getConnection()" a lot
    <groldan> gonna keep communication open on the mailing list
    <groldan> you wondering how will it affect the gce side of the fence?
    <groldan> which reminds me, Saul, we need to figure out what to do about DataStore.dispose()
    <jgarnett> if I can guess; it would be come ArcSDEPooledConnection.executeWithConnection( new ConnectionRunnable(){
    <jgarnett> void run( Connection )
    Unknown macro: { <jgarnett> ... <jgarnett> }
    <jgarnett> );
    <jgarnett> or something like that ...
    <groldan> something like that
    <groldan> ideally ArcSDEPooledConnection should stop extending SeConnection
    <sfarber> Err, can you be really specific? I'm not really so worried about the gce stuff (I mean, que sera, sera) but I'm just curious about what the nature of getting/executing connections will be and how it will change.
    <groldan> and provide a ArcSDEPooledConnection.execute(ArcSDECommand);
    <groldan> interface ArcSDECommand
    Unknown macro: { void execute(SeConnection conn);}
    <groldan> as to speak
    <sfarber> ahh. Ok, just like HibernateTemplate in spring?
    <groldan> extending seconnection is something that may be worth to stop doing, as it'd simplify unit testing
    <groldan> I mean, unit testing
    <groldan> dunno about HibernateTemplate in Spring, Saul
    <sfarber> So what, specifically, does this solve? How does it solve the "featureiterator holds open connection" problem?
    <groldan> but as long as it starts to make sense for you, I'm glad
    <sfarber> yeah, it makes sense.
    <groldan> it solves the featureiterator problem
    <groldan> but phrase it like: "featureiterator holds lock over connection" problem, instead
    <groldan> think of the following:
    <groldan> uDig is our best test bench for this
    <groldan> you have 5 sde layers in uDig
    <groldan> edit one
    <groldan> udig sets the same Transaction for the 5 FeatureStores
    <groldan> the ArcTransactionState grabs a connection and holds it, since the connection manages the native transaction
    <groldan> udig calls one addFeatures and 5 (or 6) getFeatures, concurrently
    <groldan> right now, the addFeatures operation is an atomic operation
    <groldan> but querying the 5 layers and iterating over them are not
    <groldan> each iteration consists of a number of atomic operations, say, every next()
    <groldan> but right now we're forced to wait until one iterator is fully traversed until another one is open
    <groldan> with this change, we can still serve the 5 iterators concurrently, or interleaved
    <groldan> since we can call a fetch command on each next() invocation
    <groldan> rather than grabbing the lock when opening the iterator and releasing it when closing it
    <jgarnett> understood; that is why I wanted this to settle down before I try the "single connection mode" - since may of the "get metadata" requests I would like to handle as atomic operations.
    <groldan> makes sense?
    <sfarber> groldan: I'm still a bit confused. In the end you open a SeQuery against an SeConnection object, and until you've closed that SeOuery you can't use that SeConnection for anything else, right?
    <groldan> not right
    <jgarnett> so if you can leave some kind of .exectureReadonly( ... ) method in there it will help; since I can use a connection regardless of if a transaction has been started or not.
    <sfarber> ahh, ok.
    <groldan> the problem is you have to do that in the same thread
    <groldan> so the queue per thread commands
    <jgarnett> guys ping me when done and I will post the longs
    <sfarber> So you're saying that in the same thread (but ONLY in the same thread) you can open a number of SeQuery objects against ONE SeConnection object and read from each query out of order and it will work?
    <groldan> if get two concurrent getFeature requests and try to execute the SeQuery from the calling threads, you'll get a SeException
    <groldan> I mean, while an SeStreamOp is open by one thread, no other thread can open an SeStreamOp
    <groldan> BUT a single thread can have up till 24 SeStreamOp open at same time
    <sfarber> So the lock policies listed at http://edndoc.esri.com/arcsde/9.2/api/japi/docs/index.html
    <groldan> (24 is a server side configurable thing afaik)
    <sfarber> aren't really relevant? We can't just set SE_UNPROTECTED_POLICY and let ArcSDE trust us that we won't do anything too screwey?
    <sfarber> yup, I've definitely run across the streams/connection setting before.
    <groldan> about the policies
    <groldan> I guesss they don't solve our problem
    <groldan> trylock fails if another thread is using the connection
    <groldan> lock choses a random waiting one
    <groldan> we need a predictable queue
    <groldan> but I might be convinced otherwise
    <groldan> yet, one way or the other, the change applies in that it isolates this problem in a single point, rather than being a concern to deal with every time you use a connection?
    <sfarber> sure, ok that makes sense.
    <sfarber> So, in the end, the change is something like this:
    <sfarber> OLD WAY:
    <sfarber> ArcSDEPooledConnection con = pool.getConnection();
    <sfarber> //do stuff with con
    <sfarber> con.close();
    <sfarber> wait...
    <sfarber> I missed an important parT!
    <sfarber> OLD WAY:
    <sfarber> ArcSDEPooledConnection con = pool.getConnection();
    <sfarber> con.lock();
    <sfarber> SeQuery q = new SeQuery(con);
    <sfarber> q.execute();
    <sfarber> con.getLock().release(0;
    <sfarber> con.lock();
    <sfarber> q.close();
    <sfarber> con.unlock();
    <sfarber> con.close();
    <sfarber> and now the NEW WAY:
    <sfarber> // doing something in a method...
    <sfarber> ArcSDEPooledConnection con = pool.getConnection();
    <sfarber> con.execute( new ArcSDECommand()
    Unknown macro: { <sfarber> public void execute(SeConnection con)
    Unknown macro: { <sfarber> SeQuery q = new SeQuery(con); <sfarber> q.execute(); <sfarber> //blah blah <groldan> more or less <sfarber> q.close(); <sfarber> }
    <groldan> I'd better say}
    <groldan> conn = pool.getConnection();
    <jgarnett> ie this is what they mean when they say "closure" for Java; the same reason I keep trying to use FeatureVisitor
    <jgarnett> a couple more things gabriel
    <jgarnett> use an abstract super class for your ArcSDECommand
    <jgarnett> and provide methods to create SeQuery etc...
    <groldan> ah, sorry, you talking about SeQuery, me thinking of ArcSDEQuery
    <groldan> yes, that's right Saul
    <jgarnett> that way you can clean them up after.
    <jgarnett> less client code == better
    <groldan> yup
    <sfarber> so the implementation of con.execute() is that it can "store up" these ArcSDECommand objects and run them out of order, or synchronize them in a one-thread-per-actual-connection implementation?
    <groldan> if I were able to provide a full facade to arcsde that's be ideal, but wont have that much time I guess
    <groldan> sfarber: not planning to run them out of order
    <groldan> but in the invocation order, as seen by each calling thread
    <jgarnett> gabriel you are still going to have "fun" when having several queues going on different "Transactions" right?
    <sfarber> ok, makes sene. This is mostly purely to solve the problem of connection locking and getting all the commands executed in one thread, rather than every bit of "direct-to-sde" client code running at the SeConnection synchronization stuff willy-nilly.
    <groldan> different transactions means different connections
    <jgarnett> are you thinking of a single queue? ie to preserve order across transactions (ie why bother) or multiple queues one per transaction.
    <groldan> since the transaction state holds the connection
    <groldan> one per transaction, the connection handles the native transaction, a geotools transaction is tied to a sde transaction throught the transaction state
    <groldan> GTTransaction-->ArcTransactionState->ArcSdePooledConnection-->command queue
    <jgarnett> understood
    <jgarnett> so I get where you are going gabriel
    <jgarnett> saul how are you doing?
    <sfarber> eh, I'm still a bit fuzzy on how ArcTransactionState relates to arcsde native transactions, but I'm not too worried about it. I'm happy about the command-based callback system.
    <jgarnett> gabriel I am thinking hard about the single case now
    <jgarnett> basically set up a datastore with a single command queue
    <jgarnett> and have two kinds of commands; one for read only and one for read-write
    <sfarber> However, it's going to take a lot of re-coding! It'll take me a while to get everything back and working after the change.
    <jgarnett> and use that to figure out when to schedule them
    <jgarnett> it may just be a matter of building up the queues; and then letting them "go" as they have a connection made available.
    <groldan> you mean for the maxConnections=1 case?
    <jgarnett> yes I do
    <groldan> well we have a timeout parameter, how long to wait for an available connection
    <jgarnett> It is almost like these things are comming in with Transaction.ANY
    <jgarnett> I want them schedule on whomever is "next"; possibly budging in line since they do not represent modifications.
    <groldan> the thing would be, to make transactions as short lived as possible
    <groldan> hmmm I feel like in a trap here...
    <sfarber> hey guys, I gotta bail. I'm glad we talked this through. It would have been a shock otherwise!
    <sfarber> catch you all later.
    <groldan> ok
    <groldan> you want udig running with a single connection
    <groldan> but I wonder how does that play with the way udig handles transactions
    <groldan> lets see.. (just thinking)
    <groldan> if all the sde layers have the same transaction set (which is what happens right now I guess?)
    <groldan> we should be gold
    <groldan> then, say there's no transaction in course... and you hit refresh
    <groldan> the sde will get N concurrent getFeature requests, with Transaction.AUTO_COMMIT
    <groldan> that means they're free to ask for their own connections
    <groldan> so
    <jgarnett> hi gabriel; sorry was distracted building 2.2.x - I don't mean you to be trapped; and this goal may not be possible.
    <jgarnett> in udig all the arcsde layers for a map use the same transaction.
    <jgarnett> indeed all the arcsde layers ever should use Transaction.AUTO_COMMIT until they have need to modify data.
    <groldan> no, I don't say trapped in a bad sense
    <groldan> it should be possible indeed
    <groldan> I'm just trying to figure out the exact scenario
    <groldan> so, in in autocommit mode and the pool has a single connection
    <groldan> you're tied to have enough luck as the pool.timeOut parameter is high enough as to allow serializing all the getFeature requests
    <groldan> makes sense?
    <jgarnett> correct; single connection until you start editing
    <jgarnett> after that single connection for the Map
    <jgarnett> (but I still would like all the "book keeping" commands to go out on that connection .... even though right now they are AUTO_COMMIT
    <jgarnett> they really should be DO_NOT_CARE)
    <jgarnett> and then if the user opens a second map
    <jgarnett> that is when they are stuck; and run out of connections.
    <jgarnett> for my customer it is more important that the number of connections be low - and 1 if possible.
    <jgarnett> right now I think I am at 1 for AUTO_COMMIT, and 1 per map
    <groldan> mean you're being able to do that?
    <groldan> and your customer should consider using WFS to keep the connection count under control for multiple users
    <groldan> (kidding, I know we already talked about that)
    <jgarnett> heh
    <jgarnett> well make geoserver faster!
    <jgarnett> okay let me wrap up the logs; thanks for the chat.
    <groldan> thanks you
    <jgarnett> (did you understand what I was thinking you were up to? keep the queue of commands in memory and use it to postporcess the feature reader)
    <jgarnett> and then execute the entire set of modifications in one go
    <jgarnett> like wfsdatastore does.
    <groldan> I understand, but I'm not going to have the energy to do that I guess
    <jgarnett> fair enough!
    <jgarnett> enjoy the rest of your holiday
    <groldan> ditto
    <groldan> (though something tells me that could be a sort of stratagy object since the execution is gonna be isolated to a single point?)
    <jgarnett> better yet; subclass of DataStore
    <jgarnett> DataStoreFactory makes the decision
    <jgarnett> (I already started that side of it; but I will now delay further work until I hear from you)
    <jgarnett> consider it a BIG stratagy object.
    <groldan> and sets one or other executor, using composition instead of hineritance
    <jgarnett> either works ... I was just trying to poke fun at using stratagy everywhere; one of the main feedbacks on uDig is that code should "make up its mind" rather than delegate out responsibility all the time.
    <groldan> ok, I'll try to keep your goal in mind for the design, though won't be able to enforce your use case
    <jgarnett> make it easier to follow / debug.
    <jgarnett> good good
IRC Logs March 17th

Agenda:

  1. what is up
  2. svn cut off
  3. SoC

jdeolive: is it meeting time?
aaime n=aaime@87.11.55.223 entered the room.
simboss: I thinjk so
simboss: jdeolive
jdeolive: hi simboss
simboss: ciao justin
jdeolive: cool, ping aaime , jgarnett , dwinslow , desruisseaux , vheurteaux
aaime: Hi
dwinslow: hi
jdeolive: anyone have any agenda items?
vheurteaux: hi
desruisseaux: No agenda item on my side
jdeolive: jgarnett?
***jdeolive thinks this might turn out to be a short meeting
desruisseaux: I have topic for some future IRC (module renaming, svn cleanup...), but it is for an undetermined future since I'm not yet free for those tasks...
jgarnett: hello
jgarnett: back now
jdeolive: hi jody
jdeolive: do you have any agenda items?
jgarnett: thinking
jgarnett: Eclesia cannot make it today
jgarnett: was asking about the process proposal
jgarnett: I think he has enough to start on; some WPS work may revise the interfaces he defines later
jgarnett: but that can be later.
jgarnett: So if he actually puts it to the vote (say via email) then I am pretty happy with it.
jgarnett: ArcSDE build hell and otherwise?
jgarnett: is garbriel and/or saul around for an update?
jgarnett: apparently not ... so I agree this will be a short meeting.
jgarnett: So lets just do the 0) what is up ... 1) svn cut off
jgarnett has changed the topic to: 0) what is up 1) svn cutoff warning
jgarnett: 0) what is up
desruisseaux: Only topic I could bring is that Andrea reported a failure in Resample2D. The fault is a change that I did recently (hunting for an IndexOutBoundException in MlibWarpPolynomialOpImage.computeTile) and will try to bring Resampler2D back to its previous state (or close to it) toonight.
acuster n=chatzill@pro75-1-82-67-202-232.fbx.proxad.net entered the room.
jgarnett: cool
jgarnett: jgarnett - arcsde single connection mode experiment; will end today one way or another.
jgarnett: anyone else doing anything ...
jgarnett: ... cool library must be done then.
jgarnett: 1) svn cut off
jgarnett: There is about two weeks before svn access will be turned off; so send your GeoTools contributor agreements in.
desruisseaux: Thanks for sending the emails Jody
jgarnett: (of if you have some kind exception situtation talk to a PMC member)
cliff n=chatzill@216.16.230.194 entered the room.
acuster: jgarnett: what does it mean that a few people cannot legally sign the doc?
***acuster thought we had structured the doc for those people as well
cliff left the room.
jgarnett: see the wiki page
jgarnett: at least one of the (error) is for us gov. works which are public domain
jgarnett: we are welcome to do anything with those contributions etc...
acuster: yeah, but they should read the doc
acuster: it should work for them as well
jgarnett: okay we should ask them to do that; let me find the indivudual
jgarnett: Bryce Nordgen; and his employeer (US Forest Service) got back to me saying they cannot legally sign the document.
jgarnett: (ie a red x )
jgarnett: Do you have Mr. Nordgen's contact information?
acuster: yeah, when I get back to work I'll contact him
jgarnett: um...
acuster: he seems to be the only one\
jgarnett has changed the topic to: 0) what is up 1) svn cutoff warning 2) SoC
jgarnett: so when the end of the month comes; we will go over the svn access list
jgarnett: and comment out peoples names?
jgarnett: 2) SoC
jgarnett: simboss do you have some words for us about our hopeful SoC experience?
simboss: well besides creating the page
simboss: I have not done much so far
simboss: too busy
simboss: (smile)
jgarnett: I updated the timeline
jgarnett: Currently the "Proposed Ideas
simboss: thx about that
jgarnett: is all about last years projects....
jgarnett: ... so we need help; as far as I know students are going to be looking at this today.
jgarnett: (ie today was the deadline)
jgarnett: http://docs.codehaus.org/display/GEOTOOLS/Summer+of+Code+2008
simboss: what do you mean by
jgarnett: oh wait we get to find out now if osgeo was accepted; and start talking to students today....
simboss: proposed ideas are all about last year's project?
jgarnett: correct; those are all links to the projects we accepted last year are they not?
simboss: nope
jgarnett: (also on the #osgeo channel; osgeo is accepted)
simboss: those are ideas I just dropped there
simboss: (yeah I kjnow .-) )
jgarnett: doh; you are right ... I am stupid; I was confused because mentors were listed
jgarnett: (we don't do the mentor thing for a while; stends come up with the ideas after all...)
jgarnett: those are some interesting ideas!
simboss: well, feel free to update the page
simboss: they would be
simboss: the problem is finding people
simboss: it is going to be hard to find someone in western europe
simboss: for the moeny they give
simboss: (smile)
simboss: euro is too strong
jgarnett: lol
jgarnett: try for eastern europe then...
jgarnett: (simboss is complaining about being rich? must be nice...)
simboss: I am not rich
simboss: (not yet (smile) )
jgarnett: (I am teasing....)
jgarnett: so everyone has a google id; they are going to add us to the list for osgeo
jgarnett: and then we can start reviewing student applications.
simboss: anyway, you are right we should really target eastern europe
jgarnett: Last time was harder; because the student submissions were in the google site (and not around for us to talk about w/ the community)
jgarnett: does that matter?
simboss: not so sure about it
jgarnett: Thanks for organizing last week simboss; it was needed!
jgarnett: That is probbaly it for the meeting?
simboss: I guess so
acuster: ciao all
vheurteaux: ciao acuster
jgarnett: I will post the logs

IRC Logs March 10th

Agenda Items:

  1. What is up
  2. jaxb proposal
  3. default values
  4. svn cut off

Action items:

  • waiting on votes for from jdeolive and ianT
  • Svn access will be cut off at the end of march for anyone that has not signed a GeoTools Contribution Agreement

desruisseaux: Agenda topic: JAXB annotations on metadata - vote?
jgarnett has changed the topic to: 0) what is up 1) jaxb proposal .... x) svn cut off
Daniele n=chatzill@host23-197-dynamic.37-79-r.retail.telecomitalia.it entered the room.
Daniele left the room (quit: Client Quit).
simone n=chatzill@host23-197-dynamic.37-79-r.retail.telecomitalia.it entered the room.
aaime n=aaime@host212-40-dynamic.1-87-r.retail.telecomitalia.it entered the room.
desruisseaux: We have 2 agenda topic. Anyone else has other ones?
aaime: default values and validation?
Eclesia n=Administ@ACaen-157-1-114-235.w90-17.abo.wanadoo.fr entered the room.
jgarnett has changed the topic to: 0) what is up 1) jaxb proposal 2) default values .... x) svn cut off
desruisseaux: Are we ready to begin?
jgarnett: yes; Martin I am fielding some udig questions can you run the meeting today please?
desruisseaux: Will try (I'm not as good as you - don't even know how to change the topic!)
desruisseaux: Si 0) whats up
desruisseaux: On my side: martin) Looks like that I finally got a first version of ImageMosaicReader working. Performances seem good.
desruisseaux: (tried on Nasa's BlueMarble)
aaime: Nice. Is that working against postgrid, seagis?
aaime: I mean, is that something we can try out somehow?
desruisseaux: It is used for postgrid, but it is independant of it.
desruisseaux: (typo: used by)
Eclesia: Johann sorel : i found how to code widget so that they can be inserted in netbeans gui editor, most of the widget are now ready for that
desruisseaux: Yes, it is just a javax.imageio.ImageReader implementation.
groldan n=groldan@217.130.79.209 entered the room.
jgarnett: jgarnett - udig version hell
***aaime fighting functional testing against live data directories in geosever
simone: how do you store the tile index martin?
jgarnett: jgarnett - should be positive, intergrating some greate german translations for udig
simone: simone: doing non-geotools work (sad)
desruisseaux: Not ImageMosaicReader's business. This is user responsability to create a set of Tile objects. On my case I do that on Postgrid side. You can do that using a Shapefile if you wish.
desruisseaux: A Tile object provides the informations needed by MosaicImageReader.
***groldan doing 80-20 ArcSDE work (80% the time trying to get an instance to connect to, 20% working)
jgarnett: heh; you guys should grab an agenda item!
simone: jgarnett: weren't you answering udig questions (smile)
You are now known as repressed
simone: (tongue)
desruisseaux: Can we move to agenda topic 1?
desruisseaux: I assume that the answer is yes...
desruisseaux: Proposal: http://docs.codehaus.org/display/GEOTOOLS/JAXB+annotations
desruisseaux: Reminder: no new dependencies
desruisseaux: Only drawback I could see: would increase the size of metadata JAR.
jgarnett: only part missing is who does the tasks.
desruisseaux: Mostly Cédric
You are now known as jgarnett
desruisseaux: He have done almost everything
jgarnett: Specifically I am interested in who does the documentation tasks; something that has been a sticking point on the last several proposals.
desruisseaux: Vincent (vheurteaux), can we give this task to Cédric too?
desruisseaux: I assume that we just need indication about how to parse and format XML from a Metadata object?
vheurteaux: yep!
jgarnett: correct; you have the tasks already on the page - I just wanted to make sure a body was associated with the work.
desruisseaux: (actually I believe that Cédric already started some documentation draft)
desruisseaux: Well - Cédric everywhere.
jgarnett: (and it is not like they need to be long; just enough of a code example that users can start asking real questions on the mailing list)
jgarnett: what is his confluence id?
desruisseaux: (looking...)
desruisseaux: Seems to be cedricbr
vheurteaux: cedricbr
desruisseaux: So can we call for a vote?
jgarnett: okay with that accounted for I can vote +1
desruisseaux: Thanks (smile)
simone: +ò
simone: ops (smile)
desruisseaux: +1 on my side too of course
simone: +0
jgarnett: we have not managed to get a vote out of IanT for a while; perhaps via email.
jgarnett: aaime ping?
jgarnett: jdeolive ping?
aaime: Sorry
simone: I have a question though
desruisseaux: Yes?
simone: how this work compare to using hibernate or something like it
desruisseaux: Similar idea
simone: xmlbeans
simone: I mean, does it preclude usage of an alternate framework?
jgarnett: no it does not
simone: most people don't use JAXB
simone: at least afaik (smile)
desruisseaux: I can't be sure that I'm understanding right because JAXB is a new technology for me and I don't master it. But from what I have understood, I have the feeling that JAXB is like JDBC : as set of standard interfaces (actually standards annotations) allowing different vendors to plugin their own implementations.
pramsey n=pramsey@S01060014515fec41.gv.shawcable.net entered the room.
desruisseaux: Java 6 is bundled with an implementation, but if I'm understanding right we are not forced to use that implementation.
simone: jgarnett: say we would want to use hibernate, we would have to use xml fescriptors
jgarnett: simone my experience is mixed; a lot of people use jaxb on the "intranet" side of things; especially for SOAP/WSDL side of things. They just treat it as part of java and hope the xml stuff never has to be looked at.
simone: we could not use annotations, right?
jgarnett: simone you could use annotations; the annotations do not collide or anything (they are only metadata)
simone: k
simone: just curios...
aaime: anyways +1 for me
desruisseaux: Thanks (smile)
groldan: is there a iso19139 document made out of a Metadata object somewhere to have a look at it?
groldan: out of a MetadataImpl I mean
desruisseaux: Cédric have some. Do you want me to ask him to post it on the mailing list before vote?
jgarnett: I am hoping to see that as part of a test case / code example.
groldan: an attachment to the proposal may be?
groldan: and no, I'm not saying I want to see to beleave (before voting)
desruisseaux: No problem (smile) I woudl have considered that as something perfectly normal and legitimate anyway.
desruisseaux: I will ask him tomorrow to post his examples as attachment to the proposal page.
groldan: not sure, may be like requiring the job to be complete beforehand
groldan: I'm just curious to see the product of it
groldan: and if the jaxb tech plays well with namespaces and prefixes and the like
desruisseaux: Actually the job is already mostly completed - we wanted to make sure that it was doable before to make this proposal.
groldan: yeah that's smart too (smile)
desruisseaux: I know that he have namespace - I can't said if they are all right since I'm not a XML specialist, but to a novice like me they looks like honest namespaces.
groldan: question: what do you do regarding InternationalString and Text elements?
desruisseaux: Cédric is working on it right now (smile) (I means today - he will continue tomorrow)
groldan: I mean, is there a way to encode FreeText elements in more than one locale?
desruisseaux: Yes
desruisseaux: Since today
groldan: wow, cool
groldan: +1 vote here, community support (wink)
vheurteaux: (smile)
desruisseaux: He showed me a working example. He is now tracking a bug in unmarshalling of FreeText with more than one local.
groldan: you never had the feeling InternationalString needed a getLocales():Set<Locale> method?
desruisseaux: Yes
jgarnett: martin did you do the proper ISO thing for InternationalString? As I recall their was a general solution that could be applied to GetCapabilities documenets and the like. Declare the default langauge in the header; and use some kind of tag in the middle of the free text sections for each langauage.
desruisseaux: The problem is that Set<Local> is hard to implements on top of java.util.ResourceBundle.
groldan: yup
groldan: that's why I had to make my own InternationalString implementation a while ago, working with Hibernate
simboss_away n=chatzill@host23-197-dynamic.37-79-r.retail.telecomitalia.it entered the room.
desruisseaux: Jody - I'm not familiar with that. But we will look at it - peoples here are pretty sensitive to localization, so I guess that this topic will get attention.
groldan: sorry for the disruption, continue with the meeting
jgarnett: we can talk about it after the meeting
desruisseaux: One a related topic, Cédric will need a SVN write access in order to commit his work.
desruisseaux: He would do that very progressively, begining with only small bit in to let time for peoples to review if they wish (rather than big bunch of commits)
jgarnett: martin you will need to nominate him like normal; and review his work.
jgarnett: (as usual this is mostly a test to see if the developers guide has been read)
desruisseaux: All right
desruisseaux: Thanks for the vote on the metadata proposal. I'm done.
jgarnett: 2) default values
jgarnett: aaime you have the fllor
jgarnett: floor.
aaime: Ah, this is just to summarize my mails about default values and validatio of last week
aaime: since I got no answers to the last one
aaime: To sum up, forcing default values into non nullable fields is a behaviour we have in 2.4.x too
jdeolive left the room (quit: Read error: 110 (Connection timed out)).
aaime: and removing it would break some modules
aaime: in particular MIF
aaime: yet validation can be removed easily and will cause no damage
aaime: (besides one test that needs fixing)
aaime: I'm curious of one thing tought
aaime: all the information needed for validation is stored into Feature and Property
aaime: so why do we use an external utility class to make validation?
aaime: Wouldn't it make sense to have an isValid() method in both Property and Feature?
simboss_away is now known as simboss
simone left the room (quit: "ChatZilla 0.9.81 Firefox 2.0.0.12/2008020121").
aaime: hmmm... any reaction?
groldan: thinking...
groldan: I guess it would make sense, and also would make sense isValid delegates to the helper class (smile)
jgarnett: thinking ...
aaime: sleeping...
groldan: like to alleviate the task for different implementations..
jgarnett: I would like to remove validation; unless the user asks for it. The default value is available; so if a DataStore wants to make use of it when null is not an option than that is fine. It should probably issue a warning when substing in the default value?
jgarnett: You could add an isValid() method; we have done something similar in the past.
jgarnett: you have a trade off between making methods on the interfaces
jgarnett: (and having to write down the contract for them in javadocs so everyone gets it right)
jgarnett: or making methods as static utility functions; that just depend on the interfaces
jgarnett: so there is no chance of implementors screwing it up.
jgarnett: For this first cut
jgarnett: (ie 2.5)
jgarnett: I would like to keep the interfaces as small as possible
aaime: ah, now I get it, thanks for explainig
jgarnett: after we have some experience on the ground we can consider dragging some of the more populat methods into the mix.
jgarnett: (and when we do the javadocs will say what static utility function is called - ie a very strict definition; but still allowing for optimization - the one reason to place methods on a class api after all)
jgarnett: jgarnett: jdeolive mode off
jgarnett: aaime was that the discussion you needed? if so we really should move on ...
aaime: more or less
aaime: I mean, no one spoke their minds about default values
aaime: but I'm not forcing anyone to do so
aaime: we can go on
jgarnett: hrm; my mind was already spoke
jgarnett: 3) svn cut off
jgarnett: how does the end of the month sounds?
aaime: sounds good, what about snail mail issues?
jgarnett: ie everyone who has not sent in their paper work is shut out
aaime: you cut people that did not give you confirmation by mail right?
jgarnett: we can take peoples word that they have sent in the mail
jgarnett: at least for a few weeks...
aaime: (i.e., there is no guarantee that my mail will get there in time, I waited some packages from Amazon for over 2 months)
jgarnett: we don't need to be mean.
jgarnett: we just need to keep moving.
jgarnett: - http://docs.codehaus.org/display/GEOTOOLS/Graduate+from+OSGeo
desruisseaux: I'm fine with end of March cutoff.
jgarnett: the list is going okay; we have 2 rejections on hand, and david adler is talking to IBM
aaime: 2 rejections?
jgarnett: both rejections allow us access via LGPL so it is not a stress.
aaime: should we be worried?
jgarnett: Byrce always had to reject; his work is in the public domain.
desruisseaux: Which part of the code is affected by the rejections?
jgarnett: David Zwiers has always been clear about not signing (c) away.
jgarnett: we can do an audit and see
jgarnett: audit tools:
jgarnett: - http://cia.vc/stats/project/geotools
jgarnett: - http://www.ohloh.net/projects/3405
jgarnett: we also got a few "huh?
jgarnett: messages from the likes of FrankW who cannot remember what they contributed.
aaime: if it's just an ant build file
aaime: it's not there anymore anyways
jgarnett: audit of david zwiers: http://www.ohloh.net/projects/3405/contributors/14626511142519
aaime: ok, can you explain me that lgpl thing?
aaime: since he's done tons of commits
jgarnett: lets use bryce as an example
desruisseaux: The license stay LGPL, but the copyright is not assigned to OSGEO for the code wrote by someone who rejected the assignment.
jgarnett: bryce releases work in the public domain; we can make use of that in our project and do anything with it - including making it available under the LGPL.
aaime: jgarnett, that case is clear
aaime: but I'm not sure about David's one
groldan: btw, anyone you know on the most active java developers list: http://www.ohloh.net/languages/5
jgarnett: for david zwiers the work he did while at refractions is covered by the refractions signing the OSGeo document
jgarnett: it looks like he has done 6 commits since then.
groldan: go wolf go!
aaime: groldan, no, nobody
aaime: jgarnett, ah, good
jgarnett: yawn; I am pretty tired of this osgeo grind; suppose it had to be done regardless - and the problems were ours beforehand.
jgarnett: so turnning off the svn tap at the end of the month is good
groldan: yup
aaime: sure
jgarnett: after that we can sit down and update the headers / aka providence review part 2
jgarnett: okay thanks for the meeting everyone - and happy hacking.
desruisseaux: Thanks for driving the meeting Jody.
jgarnett: heh; tanks for getting us out of the driveway.
groldan: and share some kudos (smile)
jgarnett: (doh; I am full of type mumbles today)
jgarnett: I will post the logs.

IRC Logs March 3

Summary:
0) what is up
1) magic wfs xml dependency
2) jira use
3) Some considerations on the process proposal

jgarnett: 0) what is up
jgarnett: jody - porting fixes to trunk, doing too much, etc...
jsorel: johann sorel : cleaning up map2d widget, uml can be found : http://docs.codehaus.org/display/GEOTOOLS/Map2D+structure
***aaime looking around for 1.6.2 bug fixes, starting to consider extended styling for markers to get on par with mapserver, etc
aaime: (btw, looking here: http://docs.codehaus.org/display/GEOTOOLS/Proposals cannot find the process proposal?)
aaime: any direct link to it?
jgarnett: aaime I had a good conversation with a uDig user about extenting markers; we have an interface / designed worked out if you want.
jsorel: http://docs.codehaus.org/display/GEOTOOLS/Process+proposal
aaime: I'd be interested in looking at if for sure
jgarnett: I will join Eclesia in marking it down as "RnD"; I am hoping to be paid for the work since it would be for MIL2525B symbols.
aaime: jgarnett, I cannot pay you for that
jgarnett: You do know that we allready extend the formal style interfaces; and you can follow suite if you want to do more; ie add extra fields to the style implementation in GeoTools to control additional parameters.
aaime: If money is involved I'll just go on by myself, this is not something endorsed by TOPP
jgarnett: no I was hoping to get paid; but if you do the work first that is fine ... I have lots to do.
jgarnett: I just want the work done.
aaime: If you have a design to point me at nice, otherwise I'll try to cook up one by myself
aaime: but yeah, the idea was just to extend on the well known markers and make the name something that can be used to look into a pluggable symbol system
jgarnett: yeah I have a design; let me cut and paste for emails.
aaime: cool
jgarnett: yeah that is the design
jgarnett: we sorted out the interface however.
jgarnett: so you have somewhere to start.
aaime: Ok, we'll talk about it in another meeting
jgarnett: heh; you run the meeting and I will cut and paste the content.
aaime: Ok
aaime: Anything else for the what's up part?
jgarnett: well gabriel is mostly what is up
jgarnett: by I understand he is between a workshop and his hotel.
jgarnett è ora conosciuto come gabrie1
aaime: Eh yeah, he's at the OpenStreetMap mapping party in Girona
gabrie1: I am between my workshop and hotel; I have been working on making DataStore Java 5 happy; and am bogging down with DataStoreFactory.Param
gabrie1 è ora conosciuto come jgarnett
aaime: sigh...
aaime: Ok, let's move to next topic
aaime: 1) magic wfs xml dependency
jgarnett: so yeah; Eclesia's Process proposal also used Param; so we just need to make it a first class object.
jgarnett: um that is me
aaime: this is for jgarnette and jdeolive
jgarnett: but reall jdeolive
aaime: that's not here
jgarnett: basically what the heck; it took me for ever to build on friday.
jgarnett: do we know the solution?
jgarnett: okay everyone is away ...
jgarnett: moving on ...
aaime: I'm here
jgarnett: true
aaime: the solution is to either
aaime: - make sure those jars are deployed (are they not?)
jgarnett: they are
aaime: - put them in gt2, since that's their place anyways
aaime: jgarnett, so why weren't you able to build?
sfarber ha abbandonato la stanza (quit: Read error: 110 (Connection timed out)).
jgarnett: but they are not fetched by mvn; you need to remove them from your local repo first.
jgarnett: even -U does not do it
aaime: Ah, because someone keeps on updating them
aaime: but does not change the version number
jgarnett: without changing version number
jgarnett: (yeah)
aaime: sigh
jgarnett: so if they are real; treat them as real.
aaime: gabrieeeel???
jgarnett: no idea?
aaime: No, the real solution is to move them into gt2
aaime: the so so solution is to remind people updating them
aaime: to redeploy them upping the version number
aaime: that's why I was calling Gabriel
jgarnett: understood.
aaime: he's the one hacking on them nowadays (afaik)
jgarnett: okay so I feel like we need a breakout IRC with gabriel ;-P
jgarnett: next?
aaime: sure
aaime: with gabriel and jdeolive,yeah
jgarnett: 2) jira use
jgarnett: basically Jira use concerning "Fixed for"
jgarnett: is not being done correctly.
jgarnett: so a single bug is showing up in the release notes of most releases.
aaime: I don't understand why all those issues where tagged for a million releases
jgarnett: this was really bad for the 2.4.1 release.
jgarnett: I think it is just a user error.
aaime: may be... (not convinced)
aaime: in geoserver we usually tag an issue for both the stable and the current trunk
aaime: but not more than that
aaime: tagging for two subsequent releases on the same branch makes no sense to me
jgarnett: I agree
jgarnett: I think we may be done ... can we do a search and catch these
jgarnett: and fix them in builk
simboss: (hy guys, sorry mission impossible III got my attention )
simboss: (hy guys, sorry mission impossible III got my attention )
aaime: can you repeat that? I did not get it the first and second time
simboss: (hi guys, sorry mission impossible III got my attention )
simboss:
aaime: Aaahh, thank you, now I got it
aaime: simboss, did you have feedback on the process proposal?
aaime: http://docs.codehaus.org/display/GEOTOOLS/Process+proposal
aaime: it looks saner than the last time I looked at it
jgarnett: yep; I reviewed.
aaime: thought using generics in all those maps
aaime: would make it clearer
simboss: it's changed since last time I look at it
simboss: do we have
jgarnett: some stuff like the "Parameter" need to be done anyways; and we need to write it up using the "Proposal" template so we can record vote.
simboss: status for the process?
jgarnett: better
jgarnett: we have Eclesia here
simboss: like in WPS?
jgarnett: not sure exactly what you mean simboss?
simboss: I meant to say a way to ask a long running process
simboss: for its status?
jgarnett: a ProcessListener has some of that
simboss: you spawwn a process
jgarnett: sorry "ProgressListener"
aaime: ProgressListener maybe? too bad it's not included in the proposal
jgarnett: it is.
simboss: but then you want to be able to ask the status
jgarnett: public Object process(ProgressListener monitor);
aaime: the interface definition is not
aaime: (the listener and its event object)
simboss: I would like to se the progress listener interface define
aaime: ah, it's because it's in gt2 since 2.0
jgarnett: right; I think it is actually just a callback - not sure it has much of events.
simboss: defined
simboss: is there a way to explicitly stop a running process?
aaime: Hum, parallel proposal? yeah, the Prodgress
aaime: sigh sorry
jgarnett: note it is mostly concerned with reporting progress; and cancelling. It does have some support for exceptions
aaime: http://docs.codehaus.org/display/GEOTDOC/ProgressListener
aaime: ah no, it's in the docs...
aaime: can't remember when we talked about this api...
jgarnett: yeah docs!
jgarnett: I talked about it recently as I was adding it to JTS
jgarnett: (in simplified form)
jgarnett: in anycase the "Process Proposal" looks to be close; needs to be written up as a formal page for vote?
simboss: I would not mind having a way to uniquely identify a process
sfarber [n=sfarber@88-149-177-23.static.ngi.it] è entrato nella stanza.
sfarber: Did I miss the meeting?
aaime: more or less
jgarnett: the organized part of it anyways
jgarnett ha scelto come argomento: 0) what is up 1) magic wfs xml dependency 2) jira use 3) free for all
aaime: jgarnett, yeah, an ID would be nice
aaime: to allow server like apps to have a way for clients to refer back to a long running process
sfarber: sorry!
simboss: exact aaime
simboss: I would like to have a fully fledged status object
simboss: that can be requested
simboss: providing an ID
simboss: for a running process
aaime: wondering if this can be achieved using a sub-interface specific for GeoServer
simboss: I do not want to listen for a process
aaime: since what simboss is referring to
simboss: I want to ask the status when I want it
simboss: of course
aaime: is a composite process (which may be made of a single element eventually)
simboss: I am just depicting a use case
simboss: (yeah, could be )
aaime: what I mean simboss
simboss: (aggregation actually, to be picky )
aaime: is that you want an ID for the chain
aaime: but probably not for the single element in it
simboss: mmmhh
simboss: the way I see it
simboss: there is not really a difference
aaime: unless you use it to name an input or an output of the element
simboss: a process
simboss: can itself be a chain or graph or processes
simboss: but still
simboss: each single piece
simboss: must have an id
simboss: so that I can track the status
aaime: I think the issue is deciding on a minimal API vs one that can be everything to everyone
aaime: what I mean is, we need the ID for server side processes all right
simboss: of course
aaime: what about people runnig batches, what are their needs
simboss: I do that a lot
simboss: and what I did
aaime: are we sure that we won't end up with a fat interface?
simboss: was being able to do batches in paralles as needed
aaime: (I'm just making questions, not trying to imply a solution)
simboss: (np problem, brainstorming is godd)
simboss: all I would like to see
simboss: for a process
jgarnett: simboss we are after something simple here
jgarnett: ie
simboss: would be an ID
simboss: and a status
simboss: nothing more
jgarnett: the ability for Java programmers to hack to gether something
jgarnett: managing with an ID and all that
jgarnett: should probably be wrapped around this
aaime: yeah, I was thinking along the same lines
jgarnett: we have tried and failed several times now
aaime: using the listener
jsorel: If i can say something : I see a process like the lowest level. this interface couls be extended in the futur for web services or others...
aaime: you can make up a status object in the wrapper
jgarnett: just because we tend to get complicated; in several directions at once.
simboss: I see your point aaime
aaime: simboss, wrapping those Process objects into a GeoServerProcess would be possible
simboss: I am happy with just having my suggestions captured
aaime: and leave the Process interface bare bones
simboss: I agree that we can create the status using a progress listener
aaime: the id was well can be managed by the wrapper only
aaime: yet
aaime: I have one thing in mind that might require having it in the Process interface
sfarber ha abbandonato la stanza.
aaime: jgarnett, picture the situation where you have a chain of processes
simboss:
aaime: the output of the "whole" is not only the output of the leaves in the processing chain
aaime: but also something in the "middle"
aaime: how do you identify it?
aaime: identifying the output goes thru identifiying the process that generated it, no?
aaime: Of course we could do double wrapping
simboss: well aaime
aaime: to attach id concept to both the single elements and the chain
simboss: I can tell you how people do this with WPS
aaime: but it does not look that good
simboss: chaining WPSs
simboss: there is really no way to do what you want
simboss: what you want is orhestration
simboss: not a process
jgarnett: sorry guys was not paying attention
simboss: if you wrap a chain as a process
simboss: usually that means
jgarnett: but once again; if we get complicated we don't get anything.
simboss: that you do not care about the itnermediate results
simboss: (sure jgarnett, just fleshing out some concepts )
jgarnett: how I would handle it is to feed a progress listener into each step of the chain; but that is me..
jgarnett: okay sure.
aaime: jgarnett, how does that give you identity?
aaime: Ah, another thing
simboss: I am probably to biased towards services
aaime: I understand that returning Object allows you to return anything
jgarnett: we have Objects for identity
aaime: but to make the Processes
jgarnett: (ie at this level)
aaime: chainable
aaime: having a Map of outputs would be probably better
jgarnett: nothing stops you from doing a Map of outputs
aaime: (that's what I did in my process model in by thesis)
jgarnett: espeically with type narrowing.
aaime: jgarnett, you don't understand
aaime: if you want to make and editor
aaime: the concept of multiple recognizable output is better to be found in the api itself
aaime: something you can rely onto
jgarnett: okay; perhaps I should not take part in this conversation if I cannot pay full attention
jgarnett: yeah okay; I do get that part
aaime: otherwise one process outputs a single FeatureCollection
jgarnett: hense the cut of IOp in uDig
aaime: another an array of whatnot
aaime: another a List
jgarnett: makes sure to produce both the metadata stream; ie so you can wire it
aaime: and so on
aaime: amess
jgarnett: and the data stream
aaime: why not mimic the input part?
jsorel: public Class resultClass(Map parameters) throws IllegalArgumentException; <--- gives you the output type
aaime: make a sort of Parameter map in output
simboss: guys have you looked at WPS?
jgarnett: indeed; but then we are into BPEL goodness
simboss: (stupid question )
aaime: jsorel, how do you make an editor that allows you to build a chain of spatial analiss
aaime: based solely on that API
aaime: if you have a Map with description like the one you have in input
aaime: you have all you need to build an editor
aaime: it does not look like a massive complication in the API to me?
jsorel: you can't know the output before the process happen. process can do everything and nothing
TheSteve0 [n=scitronp@66.151.148.225] è entrato nella stanza.
aaime: yes you can
jsorel: you can"t predict what will be the output
aaime: you cannot know the actual output
aaime: but you can know in advance
aaime: you'll get a FeatureCollection and 3 integerrs
aaime: you know the structure in advance
aaime: if you do a dem analisys you can get out
aaime: ridge lines and min/max points
aaime: you know in advance you'll get a feature collectin of points
aaime: and one of lines
jsorel: imagine a process that splits a featurecollection depending on different parameters.
simboss: http://rafb.net/p/mN7Ir111.html
jgarnett: I got to head out guys; I will catch up on the logs...
simboss: this is what 52 north does for wps
jsorel: it can result in 1 or N outputs
aaime: then given the parameters you know what the output are
simboss: check it out quikly guys
simboss: it is the interface for an algorithm to become a WPS process
simboss: Map run(Map layers, Map parameters);
aaime: looks a bit saner, thought I dont' see the need to have separate layers and parameter maps
simboss: neither do I
aaime: a parameter could be something that you input statically in one process, and something you get from another process
simboss:
aaime: in another case
simboss: it was just to show map for inputs and outputs
aaime: jsorel, in the case of a process that does what you proposed above
aaime: you either have the machinery to make the process say how the output will look like given a certain set of inputs
aaime: or you cannot model, describe it
aaime: I think you cannot make a WPS at all out of an API that returns an Object
aaime ha scelto come argomento: 0) what is up 1) magic wfs xml dependency 2) jira use 3) Some considerations on the process proposal
aaime: the api could be modified to be
simboss: (you need something that is web accessible)
aaime: public Map<Output> resultClass(Map<Parameter> input)
aaime: where Output looks a lot like Parameter, without sample and required
aaime: does this make sense?
aaime: (well, Map<Output> resultMap(Map<Parameter> input))
ticheler [n=ticheler@host240-197-dynamic.49-82-r.retail.telecomitalia.it] è entrato nella stanza.
jsorel: yes, but i think in some cases it's really going to be hard to predict
simboss: I am quite happy with that
aaime: Hum, I did a modeller with some 50 operators and did not have any of those cases
aaime: but in fact, those 50 operators were really even simpler
aaime: the output configuration was static, no need to know the inputs
aaime: they were the most common ones found in a gis system
aaime: (both raster and vector)
aaime: this would be more flexible
simboss: (go aaime go, go!)
simboss: absolutely
aaime: anyways I think we could have a deal breaker
simboss: we are not trying to make you waste time jsorel
aaime: if the process is really so dynamic na dhard?
aaime: sorry
aaime: if the process is really that dynamic
aaime: it may well return null to state "I don't know"
simboss: (this discussion is pretty interesting)
aaime: it won't be possible to use it in a modeller
cedricmc [n=chatzill@ble59-6-82-240-110-86.fbx.proxad.net] è entrato nella stanza.
aaime: but it would give you full flexibility
aaime: what do you think?
jsorel: the null could be a solution, this way i agree
aaime: Cool
aaime: Out of curiousity, how do you plan to handle such a very generic process in Puzzle?
aaime: you don't know anything about it, so you don't know what to make of the result?
jsorel: dont worry for that each process will have a special "widgettool"
aaime: A process API is really about extensibility and pluggability, but if you don't have handles
jgarnett: aaime: http://docs.codehaus.org/display/GEOTOOLS/Custom+Symbols+for+MIL2525B+and+EmergencyResponse
aaime: ah; i see, so you'll put the knowledge about the results in the UI
jgarnett: I will email you and Thuns privately since he may be available for testing
jsorel: yes
aaime: jgarnett, you're running too much. I'm thinking about symbols privately
aaime: It may be that I'll have something next year
aaime: or next month
aaime: depending on a lot of other priorities
aaime: jsorel, how is that any different than having the process tell you about the results?
aaime: the UI will have to know anyways, some way or the other
simboss: jgarnett:
simboss: I actually did refactor some of the streaming renderer to handle such symbols
simboss: as well as APP6
simboss: from svg definitions
jsorel: aaime: i wont do UI for all process...
jsorel: only for the simple ones
simboss: jgarnett: what are you doing exaclty?
jgarnett: answering questions on the user list actually
jgarnett: we get one of these questions a month
jgarnett: a fellow callued Theuns thought he may of been able to pay to get the work done
jgarnett: and then andrea asked about it again today.
aaime: jsorel, so you would be ok to update the proposal in order to have Maps as the output, and output descriptions by extending the concept proposed ProcessFactory.resultClass(...) method?
jgarnett: so I wrote up what was needed.
simboss: I might force the nato guys
simboss: to release part of the work
jsorel: I'm updating the page
simboss: let's say ask
jgarnett: okay "ask"
simboss: so that we can work on it and improve it
jgarnett: this Theuns guy had the MIL2525B set done up as a font; but he was not going to be able to release it to us as an unsupported module.
jgarnett: I last saw it as SVG myself...
jgarnett: andrea; what were you needing this work for?
jgarnett: (or just to catch up to mapserver?)
aaime: I have no needs, just interest
aaime: yes, I have seen people turning down geoserver in favour of Mapserver
aaime: just because we don't support extensible symbol sets
jgarnett: for me this is all about recovering some work that was "lost" in OWS-3
aaime: like diagonal line fills for example
jgarnett: I am sick of answering the email every month
aaime: but anyways, as I said, there is no business plan behind this
aaime: I just find it fun
jgarnett: no worries; I have some more content (ie the SLD examples) that I can add to that page.
aaime: which means it has to fight for my scarce free time
simboss: let's try to make it business then
jgarnett: but you understand da plan.
aaime: simboss, sure, find me anyone willing to pay for that
simboss: I might
simboss:
aaime: I'm interested, let me know when you find someone then
jgarnett: Thuens might as well; the reason I was talking to him.
jsorel: done, update the wiki page
ticheler ha abbandonato la stanza (quit: Read error: 104 (Connection reset by peer)).
jgarnett: but I want it done more than I want additional work.
aaime: jsorel, looks good to me
jsorel: jody simboss ?
aaime: small one: public boolean isValid(Map parameters); -> public boolean isValid(Map<Parameter, Object> parameters);
jgarnett: thinking
jgarnett: interesting
jgarnett: avoids the use of a Key String
jgarnett: hard ...
aaime: eh?
jsorel: (Map<String, Object> you mean
jgarnett: I usually go for Map<String,Serializable>
jgarnett: so you can save the bugger.
jgarnett: but you end up having to know about your data; and look it up by id or something ....
aaime: ah, String would be as good, yes
jgarnett: Parameter.key exists does it not?
jgarnett: aaime; I was thinking about your "output" format request... let me be wild here:
desruisseaux ha abbandonato la stanza (quit: "ChatZilla 0.9.81 [Firefox 2.0.0.12/2008021313]").
jgarnett: Map<String,Object> expectedOutput( Map<String,Object> params );
jgarnett: would be an exception if the params are not valid
jgarnett: would be a lookup of String-->metadata otherwise
jgarnett: ie
***jsorel updated the page
jgarnett: String > FeatureType
jgarnett: String > Class
jgarnett: (just throwing out 2 cents...)
aaime: jgarnett, I lost you
aaime: this is not making sense to me
jsorel: jgarnett: the expectedOutput doesnt return a map
jsorel: it's an outputparameter arry
jgarnett: jsorel array / map is the same kind of thing
jgarnett: a data structure to hold the results
jgarnett: in one you use a number to lookup
jgarnett: in the other a key
CIA-23: vitalus 1.1.x * r29527 udig/udig/plugins/net.refractions.udig.catalog/src/net/refractions/udig/catalog/ServiceParameterPersister.java: restoring of the catalog is fixed
jgarnett: makes no difference to me...
jgarnett: sorry Eclesia; just looked at "resultClass" now
ticheler [n=ticheler@host240-197-dynamic.49-82-r.retail.telecomitalia.it] è entrato nella stanza.
jgarnett: (always catching up)
jgarnett: I fear you will need two "type" fields
jgarnett: I am thinking when the result is FeatureCollection
jgarnett: you would also like to know the FeatureType of the contents.
jgarnett: (for OutputParameter)
aaime: true
jgarnett: I would call one "type"
jgarnett: and the other "metadata"
jgarnett: but perhaps that is stupid?
aaime: no, in fact that would be needed as well
aaime: some process might be working only if the feature type has the main geometry of type "point"
jgarnett: usualy waste of time feedback: String -> InternationalString when used for display
jgarnett: (also match the Param interface from DataStoreFactorySPI - since gabriel needs it anyways)
aaime: with the current api you'd know you wired them properly only when running them
jsorel: sigh we could provide a sample object, this way we dont have a second type
jgarnett: your guidence on this one is better than mine aaime; I have only played with working BPEL systems
jgarnett: and at the coding level they were often horrible
jgarnett: make sample optional
aaime: well, mine was made in VB6, how good looking do you think it was?
jgarnett: depends
jgarnett: did you comment it?
jgarnett: or was it a mess of magic maps?
aaime: nope, everything statically typed
jgarnett: (which was my complain with the systen I saw)
aaime: it was quite constrained
jgarnett: interesting
jgarnett: aside:
aaime: specific to GIS
jgarnett: back in the datastore days
aaime: could not do anything else
jgarnett: Param had an alternative idea
jgarnett: useing a Java bean
jgarnett: what do you guys think about using that? rather than a Map
jgarnett: statically typed; JavaBean reflection provides everything else you need for wiring.
jsorel: reflection...
aaime: hum, there's that shadow class you can couple with a JavaBean to actually provide description
aaime: but Param is quite a bit easier to use
jgarnett: you ask for your getParameter() bean
jgarnett: fill in the blanks
aaime: that part of the javabean api (descriptions, constraints)
jgarnett: and process
aaime: is not well known
jgarnett: really?
jgarnett: I always used it when making AWT apps
jgarnett: it came out before reflection.
aaime: never used it and I made tons of swing apps
jgarnett: swing had models
jgarnett: beans were not needed as much
***jsorel never used it
jgarnett: okay so let me put this in other terms
jgarnett: could we use a strongly typed object for the parameter
aaime: I'd say, let's stay away from it... it's almost dead, thought in fact part of the java runtime
jgarnett: and the result
jgarnett: (ignore the bean part; just the object part)
jgarnett: here is my reasoning ...
aaime: jgarnett, with reflection only how do you get a "title" "description" and whatnot?
jgarnett: it would be strongly typed; harder to screw up
jgarnett: code examples would be easier to understand
afabiani [n=chatzill@host-84-220-176-135.cust-adsl.tiscali.it] è entrato nella stanza.
jgarnett: and it is still available for dynamic goodness via reflection
jgarnett: BeanInfo (it is true)
jgarnett: PropertyDescriptor
aaime: right, BeanInfos are basically dead, that was my point
jgarnett: and so on ...
jgarnett: okay so we thought about it ...
aaime: it would make the process api harder to use
jgarnett: I just am horrified to see my simple Param hack stay allive so long; suppose it is doing that because it is simple
aaime: indeed
jgarnett: okay I will let it live
aaime: java made it too hard to attach extra stuff to properties
aaime: hmmm... annotations maybe?
jgarnett: speaking of ...
aaime: that would make javabeans more palatable
jgarnett: yeah you beat me to it
aaime: jsorel, what do you think?
cedricmc ha abbandonato la stanza (quit: "ChatZilla 0.9.81 [Firefox 2.0.0.12/2008020121]").
CIA-23: desruisseaux * r29528 geotools/gt/modules/unsupported/coverageio/src/ (7 files in 2 dirs): Deeper investigation of TreeNode layout and debugging.
aaime: have the parameters be a single java bean
aaime: with annotations on the getters to provide title, description, required and whatnot?
jsorel: i seen a bean constraints once... and i stopped after seeing it
jgarnett: aside: there is one downcheck; internationalization - if you change Parameter description to an InternationalString I have no answer for it it annotation land
jgarnett: we are thinking object not bean
aaime: jsorel, ever played with hiberante?
jgarnett: let me try your example ...
jsorel: update the page and add another solution... i'm getting lost in your talks
aaime: sorry
***jsorel wan't an exemple to understand
aaime: an example of a class annotated to make it hibernate ready: http://pastebin.com/m51bf7c58
aaime: it's just a javabean
aaime: with some annotations to specify the extra behaviour
jgarnett: class ClipProcess implements Process<Clip> {
jgarnett: class Clip

Unknown macro: {jgarnett}

jgarnett: FeatureCollection process( Clip clip, ProgressListener );
jgarnett: }
jgarnett: you would put a @description on "content" and "bounds" above.
aaime: hem, Jody, the output would be another bean
jgarnett: yeah yeah;
jgarnett: do it that way for the wiki.
jgarnett: right now I just want to see how horrified Eclesia is at the idea.
***jsorel is voting -50 for now, and that won't change will i dont understant the stuff
jgarnett: honestly I would find this way easier to understand as a java programmer; but it would be harder to hook up to a ui
aaime: 50x horrified it seems
jgarnett: I am going to grab food
aaime: jgarnett, since he's planning to make up a custom UI for each process, not any bit harder
jgarnett: Eclesia I am happy with the proposal as shown; I would recommend InternationalString and a single Parameter class w/ metadata field.
jgarnett: the pure Java solution seems a bit much
aaime: jsorel, I think having beans woudl make the code look nicer to use a play with
aaime: but the original proposal is miles better than what we have now (nothing)
jgarnett: yeah I noticed that about him; dynamic user interface is the way to go hense the getIcon sutff
aaime: jgarnett, there is no way you can make a decent you dinamically
aaime: each process needs a custom crafted UI if you want it to be usable
jgarnett: but you can make an indecent ui; see geoserver
jgarnett: your point is taken
aaime: processes are a lot harder than just a few connections params
jgarnett: um; some of the BPEL stuff is not bad; but you are correct there is usually a custom ui to configure the important nodes.
aaime: but I agree current GeoServer datastore UI is horrible
aaime: no, make that "the current GeoServer UI is horrible" and let's call it a day
jgarnett: I am going to go grab food; can someone post the logs...
aaime: jsorel, can you pinpoint what makes you feel so bad about the javabean + annotation proposal?
aaime: I just want to see if it's just some lack of explainations
aaime: or something more deep
jsorel: I can't cote +1 for something i never used before
jsorel: that's why i want a clean exemple
jsorel: vote*
jgarnett: understood
jgarnett: (aside: andrea does getHorizontalCRS do what we need for the 3D work? Is it really just a matter of hooking it up .... everywhere?)
aaime: I could make an example, but in fact I never made an annotatin processor so I'm uncertain about the implementation
aaime: jgarnett, more or less.. that's where I'm stuck now at least
jgarnett: andrea I think there are examples for generating bean info already
aaime: if anythying will pop up after that, I don't now
aaime: googling for "beaninfo annotations" only provides list of people asking for the annotations
aaime: no one providing them
jgarnett: http://eppleton.com/blog/?p=102
jgarnett: has something
jgarnett: cannot believe it is not part of Java 5
aaime: this makes you up to speed with what Sun thinks of the BeanInfo future
aaime:
jgarnett: well I can see some examples of @Property
jgarnett: so I am a bit confused
aaime: jgarnett, not intersted in random examples. Is there a maintained library anywhere or not? That's the question
aaime: otherwise we'll end up killing this proposal like the others, just by stretchig too much in another direction we did not try before
jgarnett: I agree
jgarnett: @annotations are good
jgarnett: no need for bean info
jgarnett: that is why nobody cares
jgarnett: (darn you guys and your facinating conversations....)
CIA-23: desruisseaux * r29529 geotools/gt/modules/unsupported/coverageio/src/main/java/org/geotools/image/io/mosaic/TreeNode.java: Removed accidental debugging code.
aaime: lol
aaime: well, I'll think about this and see if I can make up anything
aaime: but
aaime: I don't want jsorel to loose steam
jgarnett: I agree
aaime: jsorel, are you sick of waiting on this proposal?
***jsorel already lost some
jgarnett: lets say one code example; and Eclesia can say if it is a good idea or not.
jgarnett: or do we skip it and go with what is there now?
aaime: jgarnett, I have no time to make one now
jgarnett: I will complete the one above then
jgarnett: (sigh!)
jsorel: one thing you must also think, there are already plenty of "process like" classes in udig
jsorel: so if it too different...
jgarnett: that is fine Eclesia; it is more important to be clear
aaime: jsorel, since you're eager to get you hands dirty
aaime: have you tried the current api in a real example?
jsorel: dont worry for me, i have time for this process thing
aaime: I usually find that it provides good insight on the weaknesses of a proposal
jsorel: with the current proposal i know i can use it
aaime: I'm pushing a little because I had an experience with Hibernate
aaime: and using beans and annotations was a pleasure
jsorel: make an exemple(not know if you dont have time, but in the week)
aaime: ok, I'll try
aaime: if I don't manage to, I'll vote +1 for the proposal as is
aaime: next meeting we vote?
jsorel: i dont have anything against annotations or bean, that's just i dont know them
jgarnett: hi
jgarnett: updated page
jgarnett: - single Parameter class
jgarnett: - metadata field
jgarnett: - International String
jgarnett: also "getResultInfo" to match getParametersInfo()
jsorel: getInputInfo() and getOutputInfo() ? just a suggestion
jsorel: no big deal anyway, leave it
jgarnett: yeah go for it
jgarnett: added a comment w/ the code example
jgarnett: a bit weak; did not do the factory part.
jgarnett: but hopefully shows what is needed?