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
<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? 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
<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
<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
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

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

• http://geotools.codehaus.org/2.5-M2

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 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
<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

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
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
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
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
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
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
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
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 )
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
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...