Skip to end of metadata
Go to start of metadata

Agenda topics:

  1. SE 1.1 and SLD 1.1 chat
  2. Wwhat is up
  3. 2.5.x branch

jgarnett desruisseuax ping? I was wondering if you had any thoughts about epsg-hsql use?
desruisseaux Hello Jody
desruisseaux I don't know why it doesn't find it. I was hopping to produce a dump of registered factories, but I'm unable to remember where is the program doing that.
desruisseaux We had a JIRA task for that with screenshot and usage instructions... I searched for it half-an-hour and didn't found it.
jgarnett I placed it in the geotools user guide
jgarnett I can make a dump of the factories for you.
jgarnett (and can send that on to email)
jgarnett however I think the design of the factory lookup / hints is incorrect.
jgarnett ie global hints are interferring with your ability to look up the epsg-hsql authority; so you never find it in order to wrap it ...
jgarnett here is the tool
jgarnett http://docs.codehaus.org/display/GEOTDOC/1+Referencing+Configuration+and+Tool
Eclesia hi
jgarnett morning
jgarnett we should start the meeting?
jgarnett floor open to agenda topics...
jgarnett martin I am sad about the referencing stuff; I don't feel I have enough information to use up meeting time talking about it.
desruisseaux You have been much better than me for finding back the informations Jody (smile). It was not far finally.
desruisseaux Could you send me a screenshot of the factories tree please? And also a list of all global hints
desruisseaux (there is a tools for dumping global hints as well - trying to remember...)
desruisseaux I think a copy and paste of System.out.println(GeoTools.getGlobalHints()) should be okay.
jgarnett okay I will take that to email (since I don't have enough information to talk about it during the meeting; you did get my earlier emails so you know that global hints are breaking the referencing module)
jgarnett I can make a bug report for that and we can track progress there.
jgarnett emily / Eclesia did you want to grab an agenda topic to talk about SLDParser and/or SE 1.1 ?
jgarnett I was also going to ask gabriel / dwins about the release train
Eclesia I still have no answer for SLD interface in geoapi so I can't really say
jgarnett dwins your code freeze email looked like it was held up in a moderation queue for a while? Hopefully you can clarify this meeting?
jgarnett I am not sure I understand "no answer for SLD interfaces" in geoapi? what do you mean ...
Eclesia For me it's first geoAPI then GeoTools
jgarnett well both have to happen at once; they feed into each other ... I did give you a very solid code review last week
jgarnett (using the geotools implementation to find questions about the geoapi interfaces)

  • dwins doesn't remember sending an email that got held up in a moderation queue
    jgarnett I was supposed to be monitoring the email list while gabriel was away; I let one of your email messages loose over the weekend
    Eclesia (I'm just making the secretary work to build up the interfaces of OGC SLD in geoapi, I also have a look at GT sld class to see what could go wrong)
    jgarnett okay I understand now; I just read your email on the geoapi list. Thus far you have done Symbology Encoding 1.1 I guess? And now you are looking at the SLD 1.1 interfaces?
    Eclesia yes
    Eclesia and they are done
    jgarnett got it; so you have the SLD 1.1 interfaces available for geoapi; and you would like to commit them for review etc. That sounds okay; but I can reply to your email ...
    jgarnett did you want to grab an agenda topic to talk about a) your plans for 2.6.x and b) SLDParser stuff with Emily?
    Eclesia I just want to know if someone at refraction is going to make an SLD1.1 parser, I seen you work on styles and sld
    jgarnett Eclesia we cannot make an SLD 1.1 parser until there is code (and a renderer to make use of it).
    jgarnett We have no paid work in hand that requires SLD 1.1
    jgarnett (indeed for udig we would probably just stick to the SE 1.1 work; SLD is more of interest to #geoserver developers
    Eclesia ok so I dont any agenda item ^^
    jgarnett that said we know the DOM based SLDParser
    jgarnett and we need to know your plans for supporting SE 1.1 and SLD 1.1
    jgarnett (ie this is planning; we don't do work you need for free; and we also don't start work without talking to you first ...)
    Eclesia for SE1.1 GT is going to have a patch in 2.6.x
    jgarnett cool
    Eclesia and for SLD1.1 I still dont know what will be in GT
    aaime GeoServer people has no sponsoring on using SE 1.1 and SLD 1.1 either, actually we don't implement any WMS standard that could use them
    jgarnett well to put anything into geotools we got to keep the big picture in mind
    jgarnett so someone better have plans for a parser
    jgarnett (or we are not taking good care of the library)
    jgarnett I do agree that SLD 1.1 is pretty useless...
    jgarnett (note we have now talked about this so much we should of grabbed an agenda item)
    jgarnett aaime does #geoserver have any plans for SE 1.1 or SLD 1.1 ?
    Eclesia there's no t enormous difference with SLD1.0 now that we have SE1.1
    aaime none
    aaime no one ever requested we support it
    aaime and wms 1.1.1 is based on sld 1.0
    jgarnett what is based on sld 1.1 ?
    jgarnett WMS 1.3 or something?
    aaime maybe wms 1.3, but I actually never seen that citation
    jgarnett Eclesia I am interested in SE 1.1 for uDig.
    jgarnett Based on review I don't think updating the SLDParser would be that bad
    Eclesia streaming can handle Se1.1 ?
    jgarnett so when you get there please talk to us and perhaps we can collaborate.
    aaime of course not
    aaime or can it?
    jgarnett the SLDParser is dom based; the GTXML (ie streaming parser) only has binding for SLD 1.0.
    Eclesia I dont now, perhaps just like me, there is a patch waiting somewhere ^^
    jgarnett I think everyone has their cards on the table; SE 1.1 is new work.
    aaime Eclesia, did you update SLDStyleFactory to handle the extra features se 1.1 has?
    jgarnett and we either need enthusiasm (or a customer) to get it done.
    Eclesia aaime: no
    aaime also, classification functions should be supported directly in the renderer
    aaime so it's quite fair to say streaming renderer does not support se 1.1
    aaime and won't unless somee udig folk updates it in that direction
    aaime or GeoServer gets some sponsoring to work on SLD 1.1/SE 1.1
    jgarnett well I will start slow by making use of the classification functions (which can be represented in SLD 1.0)
    jgarnett still it is good to see this stuff moving; perhaps we can go shopping for a sponsor on this topic.
    jgarnett shall we move on ... with the agenda and meeting?
    jgarnett 1) what is up
  • aaime is fixing geoserver bugs for the 1.7.0-... rc1/beta2 (still haven't decided) release
  • Eclesia JSorel : working on GeoAPI SLD
    jgarnett jgarnett - despairing over epsg-hsql and wondering how geoserver manages to render anything (perhaps someone can help me after the meeting?)
  • aaime is also mail drunk after reading 1100 mails in roughly one day
    aaime jgarnett, GeoServer gave up using Hints because they don't work, we opened a jira issue and got back using System.setProperty
    aaime ugly, but so far the only working solution
    jgarnett thanks for the insight aaime; I am going to go freak out and break a lot of referencing in the process is my guess
    jgarnett (sigh)
    simboss simboss - jpeg2000, jpip and python
    tar1 tara - lurking
    aaime http://jira.codehaus.org/browse/GEOT-1704
    aaime (for jgarnett information)
    aaime jdeolive, we're in the "what's up" phase of the gt2 meeting
    aaime want to join? (smile)
  • dwins having fun with wicket and fixing a gs bug or two
    jgarnett moving on ...
    jgarnett 2) 2.5.x branch
    desruisseaux Andrea, could you remind me the JIRA issue please?
    jgarnett dwins without gabriel here this one is mostly you ...
    aaime desriusseaux, the jira issue it the one I pasted above
    dwins okay
    gdavis_ I wanted to get unsupported gt-wps and gt-process into this branch. dwins, how do I sort that out?
    aaime it contains a small "main" that can be used to reproduce the issue
    dwins as far as I know everything is in place
    desruisseaux Oups! Thanls Andrea
    aaime np (smile)
    dwins gdavis_: good question. i'm not sure of the geotools policy for changing the 'unsupported' status of a module
    dwins jgarnett: care to enlighten us?
    jgarnett gdavis knows this one; it amounts to a page of docs and 40% test coverage.
    aaime jgarnett, that is to get the module to supported land
    jgarnett desruisseaux can point you towards a report of coverage; not sure if it covers unsupported modules however?
    aaime he wants to keep it in 2.5.x as unsuported no?
    jgarnett good question - gdavis what is your intention?
    gdavis_ desruisseaux, how do I get test coverage of my unsupported modules?
    aaime afaik the branching process will just keep it around, unless someone removes it manually
    gdavis_ well are unsupported modules going to be in the 2.5 branch?
    dwins aaime++
    jgarnett well I want us to remove a lot of the unsupported modules; at the very least anything without a review.apt file...
    jgarnett but stronger than that ... anything geoserver is not going to use.
    gdavis_ review.txt file you mean?
    aaime nope, apt
    aaime (almost plain text)
    gdavis_ well we have the wps geoserver module as well, which we'd like to get in 1.7
    jgarnett gdavis_ they changed it in order to generate a "maven site"; no idea what apt stands for - looks similar to a wiki format.
    gdavis_ i havent updated GT in a few days, was that a recent change? All mine still seem to say review.txt
    desruisseaux About coverage: I do not yet have a coverage report for unsupported module. We had difficulty getting clover to run on GT trunk. We tried cobertura instead in a repository containing simplified pom.xml, but it doesn't cover unsupported modules yet.
    gdavis_ so how does an unsupported module get test coverage in order to become supported then?
    aaime so jgarnett, this is your idea, to remove unsupporetd modules from 2.5.x... it's the first time I hear about that
    jgarnett aaime I have talked about this from the definition of the unsupported module idea / we are only hosting stuff to help get new developers. The actual library is defined by what meets our QA and Doc requirements.
    jgarnett Every other time we talk about this you mention unsupported/oracle and assume I am losing my mind.
    jgarnett (ie nobody supports oracle; but we need it; so jody must not be serious about removing unsupported modules from the release train)
    aaime gdavis_, go to your module and type "mvn cobertura:cobertura"
    aaime jgarnett, more or less correct, and how do we get out of that impasse?
    jgarnett I think we start by removing everything geoserver is not using.
    aaime I mean, we're talking about library procedures here
    jgarnett and move the stuff we are using into the library.
    jgarnett (by meeting the doc and testing requirements)
    gdavis_ ok, what does this do?
    aaime jgarnett, but oracle has no maintainer, so it cannot get into the library
    aaime gdavis_, it generates a report, look into target/site
    jgarnett well andrea we may be at a cross roads of either a) asking a sponsor to support a maintainer for oracle (refractions has at least one interested - but it will take dropping oracle from geoserver to show this is a serious requirement)
    jgarnett b) recognizing that once something is in the library the community takes responsibility for keeping it going
    jgarnett (at which point 40% test coverage and a page of docs looks like too small a bar to jump over)
    jgarnett oracle is in limbo right now - no questions about that.
    aaime we're going into a direction where I cannot talk about the issue intellligently. It involves providing resource, and I'm not the one controlling them
    aaime cholmes can say if TOPP is going to maintain Oracle or not, and if it's ok to drop it completely, I cannot
    jgarnett does the idea of removing unsupported modules that are not used by geoserver seem like a good compromise?
    aaime sort of... I mean, what about modules used by udig but not geoserver?
    jgarnett ie it has no effect on your release; and it provides insentive for people to finish their module.
    jgarnett same deal
    jgarnett if udig is keeping something in the build (like say the graph module)
    jgarnett we can make sure it is passing tests on the branch.
    jgarnett but udig is not following you on the 2.5.x branch (we could not get our feature event work done in time and referencing did not meet our requirements)
    jgarnett so the 2.5.x branch is mostly about you (sad)
    CIA-35 gdavis * r31086 /trunk/modules/unsupported/wps/src/test/java/org/geotools/data/wps/ (OnlineWPSFactoryTest.java OnlineWPSManualRequestTest.java): Turning online tests on for covertura
    CIA-35 gdavis * r31087 /trunk/modules/unsupported/wps/src/test/java/org/geotools/data/wps/ (OnlineWPSFactoryTest.java OnlineWPSManualRequestTest.java): Turning online tests back off.
    aaime well ok, I'm not exactly happy about this, but I don't see alternate routes
    jgarnett thinking
    jgarnett andrea what is there not to be happy about? You don't need widgets-swing-pending do you?
    jgarnett (this is just a question - I am not sure if I understand your concern)
    aaime I'm not exactly happy that modules do appear and disappear from the library depending on which project uses the branch
    gdavis_ these reports all show 0% when I know that can't be true....
    jgarnett you are correct; I am not happy that modules that projects depend on are not meeting our very low QA bar; I figure that is irresponsible ...
    jgarnett but the same token I don't want to advertise modules that we know are in flux (ie the definition of an unsupported module)
    jgarnett unsupported is only there to bootstrap quick development; the library slurps up the good ideas (and hopefully grows our developer community in the process)
    aaime it still seems me we should advertise this on the users community before pulling the plug
    jgarnett Perhaps we should return to the details of making a release this week ... I am sorry the handling of unsupported was a surprise Andrea.
    aaime it's quite rushed for a branch that we should do this week
    jgarnett okay I can do that; ask them what they think.
    aaime like for example Camp2Camp is using MIF, we just pissed them off enough with the licensing questions that they stopped mailing us
    aaime (questions -> requirements)
    jgarnett andrea I would settle for deploying to maven but not making it part of the download. See the language on this page for my intension with unsupported modules: http://docs.codehaus.org/display/GEOTDOC/16+Unsupported
    aaime I would like to make a separate zip instead
    jgarnett aaime++ that would work.
    gdavis_ so, can process and wps still reach supported status for this release?
    aaime so that peopole can still use them, but would understand they should get they act togheter and support themselves
    aaime gdavis_, dunno, I tried cobertura on various modules and the coverage I get is not 0
    aaime you can also try out with the cobertura eclipse plugin, you might have better luck
    gdavis_ INFO test
    gdavis_ INFO Tests are skipped.
    gdavis_ it says this
    aaime gdavis_, can we talk about this later?
    gdavis_ I guess so
    aaime it's problem solving, not something we should do during a meeting
    aaime especially since it's supposed to end in 7 minutes
    aaime jgarnett, anything else that is holding up the 2.5.x branch?
    gdavis_ alright
    aaime (I was actually quite surprised by the rush of last minute api change proposals and actions, feature collection, feature id...this kind of stuff should be hanlded at the beginning on a development cycle, not at the end)
    simboss aaime: I have something to say about the 2.5.x branch
    jgarnett aaime I was surprised as well; a lot of this work was started and nto completed
    jgarnett aaime I also did not do the deprecation cycle this release.
    aaime feature collection and feature id are weren't started at all
    jgarnett you know when we go through 2.4.x and remove deprecated methods.
    jgarnett feature collection was started as part of the feature model change over; but it lost momentum.
    jgarnett In trying to use this in a training environment I figured I could not stand to let it out the door with so many half finished ideas; I hope you don't mind.
    aaime I've only seen proposal drafts for Justin, no coding was started
    aaime I did not notice any significant change before your work of last week
    aaime I do mind when these things are done last minute, since we're touching some fundamental class
    aaime that would be better modified when a new trunk starts being worked on
    jgarnett I kind of thought justin would get to it before release.
    aaime how could you think that, we did not even vote the proposal??
    jgarnett And I was hoping to do the featureid work with you but did not figure it out in time before you left on vacation.
    aaime that one fell on me like a surprise as well, it's another major change that should not occur right before branching
    jgarnett I could think that because we focused on the change over to simple feature during September; and we did the bare minimum to make the change. Other things that we knew were wrong (like featurecollection being a feature) were not attempted at that time.
    jgarnett I have been talking to gabriel about the FeatureId handling as part of the feature event work for months; but perhaps because it was feature events it was not visible as a concern?
    aaime jgarnett, I'm not questioning the goodness of the changes
    aaime I'm questioning the timing
    jgarnett But I agree too much was done last minuet; and too much was done by me at the last minuet.
    jgarnett I don't know if I should of been more strict months ago or what.
    jgarnett however I do like the result.
    CIA-35 gdavis * r31088 /trunk/modules/unsupported/wps/src/main/java/org/geotools/data/ (4 files in 4 dirs): Adding package infos for these packages.
    aaime ok...
    aaime so, let's recap a bit
    aaime how are we setup for the 2.5.x branching?
    aaime what still needs to be done?
    jgarnett we await a decision from dwins / gabriel
    jgarnett then we tag
    jgarnett we have to rollback referencing
    jgarnett and I want to review the user guide and bundle it up for download.
    jgarnett (we also need to tag a geoapi milestone but we can limit that to a maven deploy)
    aaime ha great, we tested geoserver for months with the current referencing and now we roll back... this 1.7.x relelase will be a damned one I guess...
    jgarnett well we can ask martin
    jgarnett but he did not get to the work right now?
    jgarnett I think all that happens aaime is we remove my classes (that are still not hooked up)
    aaime ah, not hooked up you say... so we haven't been using them at all
    simboss guys I have two minor fixes for imagemosaic, I have made tests run for both geoserver and geotools successfully; question is can I commit?
    jgarnett correct
    aaime simboss, sure you can
    jgarnett the work I did for so long has not been hooked up yet because I cannot pass one test case about looking up an existing identifier.
    jgarnett so rolling back (or deleting these classes) should not be too stressful.
    aaime I guess it will just be deleting the classes, since desriusseaux has been making changes/fixes to referencing on trunk afaik
    jgarnett agreed
    jgarnett I think martin said he could help on that side; he feels bad about not getting time to work on referencing.
    jgarnett and leaving me hanging.
    CIA-35 simboss * r31089 /trunk/modules/plugin/ (4 files in 2 dirs):
    CIA-35 - releaseing resource for ImageMoisacReader
    CIA-35 - using some good old suppressWarnings tag
    aaime ok, and we need to change the release scripts to create a separate zip for the unsupported modules... something I never managed to figure out how to do
  • Eclesia can wait 2 more weeks if it helps
    jgarnett Eclesia I don't think it will help; only thing we should do that we are not is removing deprecated methods.
    aaime jgarnett, that is going to be a big one, and not possible at all in various cases
    aaime think filters
    aaime you simply cannot remove the deprecated filters
    jgarnett I know
    aaime there is still code using them
    jgarnett (it is one of the things listed on technical debt on the 2.5.x page)
    jgarnett but I suspect there is some work we could do; but it was not as important as making our Java 5 transition and getting our Feature / FeatureCollection story straight.
    aaime ok, who does what and when?
    jgarnett dwins / gabriel was going to make the branch today
    jgarnett I was going to review the user guide pages
    jgarnett I think martin was going to rollback the referencing module?
    jgarnett I was going to help gabriel by running deploy from here.
    aaime I haven't seen groldan around today
    dwins and I don't have write access to the repository
    jgarnett dwins was mostly organizing; gabriel just had the ability to do the work.
    jgarnett I was hoping for code freeze / branch / unfreeze and then starting up the release process from the branch; releasing when CITE tests pass?
    aaime yep
    aaime thought if the FeatureId change is still in the air, we cannot release gt2 2.5-rc
    jgarnett can we wrap up the meeting; and leave the IRC log open for collaboration on the 2.5.x release ...
  • aaime is at the end of his working day almost right now
    jgarnett if gdavis and simboss are happy we could branch 2.5.x fairly quickly. And worry about making the release from the branch tomorrow ...
    simboss I just committed
    simboss so yeah
    simboss I just tested
    aaime so we give up with FeatureId related changes?
    simboss that the fix
    simboss for the coverage bandselect problem
    simboss worked
    aaime (that's an API and GeoAPI change)
    simboss and it worked indeed
    dwins simboss: thanks a lot
    aaime simboss, thanks
    jgarnett FeatureID changes were done on the weekend Andrea; they went well.
    jgarnett or actually late last week.
    aaime Uh?
    jgarnett I talked with gabriel after you left; and Justin.
    aaime I did not even notice
    aaime any page documenting how things are working vs pending ids?
    jgarnett the FeatureEvent page
    jgarnett but now you have the option of getting the FeatureIds from the features
    jgarnett rather than only from events.
    simboss dwins, aaime: If I were you I would double check anyway (smile)
    aaime what about featureStore.add(..)?
    jgarnett dwins made the change on the geoserver side.
    jgarnett now returns a List<FeatureId>
    jgarnett so you can build up your list ...
    aaime and they do change after commit occurs?
    jgarnett yes.
    aaime I see
    *--| tar1 has left #geotools
    aaime any way to know the feature id is "transient"?
    aaime (pending, whatever)
    jgarnett but that is only as good as the datastore implementation as per usual.
    jgarnett no there is not
    aaime I see
    aaime could have been useful
    jgarnett you could add that to the FeatureIdImpl if you want; I would like to see some experimentation on that side.
    jgarnett note versioned postgis was the only thing
    jgarnett to want to set the feature id more than once.
    jgarnett I wanted to ask you why that was ...
    aaime I don't know
    aaime I coded that datastore more than one year ago
    aaime I simply do not remember why
    jgarnett I suspect it is so you can include "feature id" and "version" as part of the Identifier?
    jgarnett but dwins only found tests that failed in #geoserver so I could not verify.
    aaime it probably has something to do with the intricacies of having a feature id mapping between an inner and an external view
    aaime jgarnett, externally the id stays the same
    dwins it looks like you generate a temporary id immediately after getting the feature from the writer
    aaime version is not part of the feature id the users sees, but internally yes, it's part of the id
    dwins and then I guess you do something with it to generate a final id for versioning
    aaime I see.. don't know, I would need to check the code
    jgarnett okay so perhaps a change of api class can do it .. generate the "fid"; use it to construct the FeatureId; and then you can still set it once when you have your final value...
    jgarnett (I just had a check to freak out if a FeatureId was being changed multiple times; and we had to turn it off for your module)
    aaime so now it's not part of the build?
    jgarnett yes
    aaime you should have sent me a mail saying so?
    jgarnett I did?
    aaime I did not see it
    jgarnett reading
    aaime (mind, 1100 mails dropped in my mail client yesterday)
    jgarnett (gasp I may of been evil like dwins and just had a conversation on IRC and not sense an email... the horror)
    aaime I've only seen this, but could not make any sense of it: http://jira.codehaus.org/browse/GEOT-1934
    CIA-35 simboss * r31090 /trunk/modules/unsupported/coveragetools/src/main/java/org/geotools/utils/imagepyramid/PyramidLayerBuilder.java: -minor fix as directed by Thomas Lutz
    aaime also the jira says it's fixed, if so, the module should be brought back into the build
    jgarnett that is true; it was done after the change.
    jgarnett it never left the build; it was always passing its geotools test cases.
    jgarnett you are correct andrea; I sent email and closed bugs on the geoapi list.
    jgarnett I will correct that now.
    aaime k
    aaime dwins, jgarnett, I have to go in a few minutes and I still have some pending commits
    aaime can you send me a mail telling me if I should a) branch b) run the cite tests?
    dwins sure
  • No labels