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