UML tools, productivity, online tests, feature model

dblasby so - topics for today?
bowens anyone know of any free UML modeling tools, like Visio or Enterprise Architect?
Jody - does the build work again?
Jody Omondo
Jesse_Eichar DIA
Jody (so yes)
Jesse_Eichar umbrello?
bowens thx
dblasby topics 1. SVN commit access for brent?
dblasby others?
dblasby 2.1.x and 2.2 diverging?
Jody brent already has commit access
Jody he is a module maintainer on like validation.
bowens I need to see how to retrieve my account informations, it was with my RR info
dblasby oh - I wasnt sure.
Jody Ah, send a message to admin@refractions.net to get things fixed up ...
Jody Did you get a chance to review the FM stuff brent, if so we can put it on the meeting agenda.
jmacgill bowens Argo is semi stable these days
bowens yes
dblasby I'll make an introduction - many people here already know Brent, when he was involved in Geoserver/Geotools little while ago. He's now working for TOPP full time.
Polio grats bowens
jmacgill agenda topic - OnlineTests
dblasby 2.1.x and 2.2 diverging?
dblasby anything else?
jmacgill yes, this important, we need to have a best practice policy here
jmacgill for the moment we have documetnation of branch workers but not for trunk developers
jmacgill what is the current status of 2.1?
Jody I could change that page to say "How to fix bugs" rather then working with a stable branch?
Jody It is released, another release 2.1.1 will go out with GeoServer.
Jody (I would like to get an Oracle fix in but lack time for testing)
jmacgill I would say that as it is released all bug fixes should be applied to the trunk FIST then back ported to 2.1
dblasby james, There's a lot of work to doing patches on 2 branches. I find that I spend 1/2 my "geotools" time doing productive work, and 1/2 doing non-productive work (running tests, fixing buggy test cases, etc...). this actively prevents me from working on geotools (1) the time I do allocate to it gets eatten up in overhead (2) I ACTIVELY do not work on it because I find it frustrating.
jmacgill I would say that approaching 2/3 of my geotools time is non-productive right now
Polio I only patch / work on head
jmacgill I am almost constatnly working on the build system
jmacgill I also only patch / work on head
dblasby I'm only working on 2.1.x - I tired to backport my SLD parser changes to trunk and it took me longer than it took to write the code.
Jody I only work on branches, and patch trunk and 2.1.x.
dblasby by the way – thanks for all the build work you're doing, james. I appreciate it.
Jody yeah - build work helps everyone.
jmacgill true, but it rarely stays up for more than half a day
jmacgill a unit test or a JAI issue comes up every other day
dblasby yes - a lot of the unit tests are "low quality"...
Jody shall we scrub em and start again ?
jmacgill 2.1.x should be in maintance mode, what kind of development work are you doing with it?
Jody It is a QA thing, everyone is works to solve problems not test cases.
Polio Im some cases ... it may not be a bad idea to diaple the tests and make jira tasks to create new test cases
Jody This is all kind of up to module maintainers ...
dblasby are the module maintainers actually actively "maintaining"?
dblasby I'm doing 2.1.x work because thats what geoserver is based on.
dblasby I'm trying to minimize my geotools work since I find it frustrating and I kill trunk when I try to back port patches (they are getting significantly different)
Polio well, I do try and look into the wfs code every so often (in the process of an upgrade) ... guessing this is 'mainitaining'
jmacgill uDIG is focused on 2.1 as well yes?
Jody yes.
jmacgill does either project have a timeline for 2.2 use?
dblasby not yet
dblasby "when its stable?"
Jody given the RnD timeline next year.
Jody However we need some of the content ealier
jmacgill so more stuff will get ported between 2.2 and 2.1
dblasby but who's going to do that porting?
Jody Yes, even if only to have stable versions of UDIG and GeoServer.
jmacgill I don;t thinkt he porting should be happending
dblasby someone on the geoserver-devel list said they were going to do some work and "leave it up to someone else to port it".
Jody It is an issue of policy, the policy could be don't close the bug until it is fixed on the stable versions. Right now we don't even have checks in place to make trunk stable.
Jody so someone on the geoserver-devel list is not going to get their change in.
Jody James - if you want GeoServer/UDIG to consider trunk then lets make trunk stable.
Jody aka no active development on trunk, RnD in branches and merge = milestone release
dblasby thats an idea
jmacgill what about small chagnes, fixes, tweeks?
dblasby I do like that.
Jody downside, RnD work does not get intergration builds. Really you need both a stable branch and a RnD branch.
dblasby if trunk is stable, then stick it there.
Jody Well it is what Cholmes suggested, but the point remains.
Jody What we are doing cannot go on. fixes yes but we need the power to roll them back if they break the build.
Jody tweeks, no - do it in a branch.
dblasby what do you mean, jody? I see a bug and what am I supposed to do?
Jody But seriously there are like 4 large scale RnD efforts - they would not get the benifit of Intergration builds if we mark trunk as stable.
Jody Fixes and Tweeks were listed small changes.
Jody fixe yes, but if you screw it up it needs to be rolled back.
Jody tweeks, have no place in a stable branch.
dblasby whats a tweek then?
dblasby and if I want to make one, how do I do it?
Jody Eiether you are optimizing in which case do it all as an RnD run and merge
Jody or you are fiddling for no reason? in which case it does not belong in a stable branch.
dblasby ...thats a lot of overhead if you're just changing a class or 2
Jody and overhead == stability, also == a dead code base that people fork.
Jody It is a tradeoff, I just need to make clear that having trunk stable may get udig, geoserver in the game but it has a price.
Jody Dave what about having the GeoServer and UDIG trunk move to geotools trunk
Jody aka all the RnD work together? GeoServer and UDIG both have stable releases (or almost do).
dblasby so, if I want to make the labeler better, I have to do a branch and merge for 4 hours worth of actual coding (and testing)
Jody Trying to suggest you take longer and make labels better for a couple of weeks, and then merge in the result.
jmacgill ugh
dblasby I'm finished - it only took a few hours!
Jody dave there will always be overhead, having two branches is more overhead.
Jody (ya cannot change the laws of physics capt'n)
dblasby There's a few more things I want to do - but I'll do them later. (1/2 hour work = branch and merge!!)
Jody (maybe that should be logs of physics)
Jody dblasby the other thing to do is stay at 2.1.x
dblasby why dont we bust main into a bunch of smaller modules and run each one separately? like renderer, styling, data, ...
jmacgill sigh
Jody we had that it really sucked.
dblasby and then how do I do my fixes?
Jody well where is the problem dave.
Jody Is it the tests?
Jody Is it the branching?
jmacgill (James never thought tht is sucked, but bowed to everyone else)
Jody How can we possibly make things better (it only was a problem because nobody else used maven and could not figure out what jars to use)
Jody dblasby would splitting it up help?
Jody we already went from main to main & referencing
Jody and are about to go to main, core and referencing.
dblasby I just thought then we could have different versions of modules then. That way you can have 2.2.M0 2.2.M1 2.2M3 2.2M4 .... for the renderer.
dblasby or what have yo
Jody however a split by "layer" makes the most sense, but still would this really help you?
Jody Ah, so you would like to run the versions separatly?
jmacgill that would be very hard to track
dblasby I thought it might be easier-- but it be more difficult.
Jody (Would be okay with a stronger plugin system james)
Jody Dave where exactly is the pain for you? I am okay right now with the svn branch/merge, but not with the build time.
jmacgill yes, eclipse and netbeans have frameworks that support that level of versioning
jmacgill from my perspective 2.1 should be in bug fix mode only, we need to move to 2.2, 2.3, 2.4 .....
dblasby As I said, my productive time is actually very small. I'd do more geotools work if I could be more productive. And I see 2.1.x and 2.2 diverging.
Jody My life would go better with a more modern plugins system, but that is just me. Largest benifit would be from making the eclipse .project / .classpath files saved out.
dblasby but our applications run on either 2.1.x OR 2.2 not both.
jmacgill Can uDIG and GeoSerer setup their own stable branches so that develompent work for them can go against 2.2?
Jody Productive time also suffered on trunk as you recall, because trunk is active & not stable.
Jody I thought we had - aka 2.1.x.
jmacgill we do for GeoTools, I ment for uDIG and GeoServer. But yes, trunk should be stable
Jody UDIG 1.0.1 is the stable branch, trunk can switch over - but we will wait for a milestone release with a feature we need.
jmacgill but you are adding features that you need to 2.1
dblasby I have no idea if trunk is working. I dont know if anyone's actually using it.
Jody Jesse is here, we can think about this and get back to you.
Jody (Back to you as in another day)
Jody As for working, I know the 2.1.x oracle does not build (if you try running the tests). It is fine against dummy jars. Have you tested GeoServer with oracle?
dblasby no
jmacgill trunk is working, or it should be, I'll do a full test now.
jmacgill (that was not a comment about oracle)
Jody dblasby sounds like there are two things here: geotools development takes too much overhead, and we don't know what is going on with trunk.
dblasby true
Jody Have you looked at http://docs.codehaus.org/display/GEOTOOLS/RnD
Jody The inFlight section describes what is going on, I even made a news announcement with the expected completion dates for those things with deadlines.
Jody http://docs.codehaus.org/display/GEOTOOLS/2005/08/25/GeoTools+2.2+RnD+Update
Jody So the question is when is it worth moving over, and how can geotools make it worth our while?
jmacgill $1000 fine for build brakers?
Jody I need Random Data Access - so UDIG trunk should move over in October or so.
Jody Gabriel needs ComplexDataStore for GeoServer, so hopefully you have a unstable trunk for him to work on by around november?
Jody To my knowledege all of this stuff is happening in the branch & merge manner.
dblasby yes - probably around nov. When the geotools side of FT is settled, we'll probably move geoserver over (if its reasonably stable).
Jody However I am not too sure that the GC people have cottened on.
dblasby Is everyone moving their 2.1 patches over to 2.2?
Jody I have been.
Jody As for the build brakers, the usual technique is they get to monitor the build status until it is someone elses turn.
Jody But backing out the change is preferable approach.
Jody Q: Is there any other RnD work not on the Page?
Jody Or does anyone have a timeline for some of the other stuff ?
jmacgill I'd like to migrate some of the uDIG rendering code to geotools
dblasby and perhaps the udig catalog
jmacgill stuff to do with selection . highlighting etc.
Jody http://docs.codehaus.org/display/GEOTOOLS/CatalogAPI
Jody selection, highlight is all Filter and Style.
jmacgill kicks off a trunk cc build to see what happens
Jody Catalog needs to happen, before the GC people finish up.
Jody They are messing with the same issues looking to repalce GCE.
Jody I drew jdeolive and bowens a picture of all the RnD work, and what needed to finish before the rest.
Jody Perhaps bowens can draw it up pretty?
bowens I will try to translate your writing into a diagram
Jody dblasby we still did not cover the more important point - how the heck can we make working with geotools less of a pain?
Jody I tried working with an oracle guy who, a) loved the codebase b) never ran maven c) or any tests.
dblasby I dont know, jody; perhaps i'm the only one who feels this way...
Jody Scare tatic: remove maven, include Eclipse .project files, make AllTests entries
Jody Not at all, including .project files (or having someone help me set up "eclipse maven" would do a lot). Jesse has some magic system he has never documented that works for him.
dblasby I've always used maven – I dont get eclipse to work with geotool (I havent needed to yet).
jmacgill works with the maven plugin for netbeans and loves it. the eclipse one should be as good if not better
dblasby but I have a no-test-case builder that makes the jar and puts it in the geoserver deployment location.
Jody I usually work in eclipse, and spend 15 min making the tests work before commiting. I know of GeoServer hacks that just make jars with out running tests just because goeserver is what they are working on - not geotools.
dblasby but I mostly test by actually running the code and looking at the results. I dont actually trust the test cases to find anything.
Jody I write a test case to describe the bug
dblasby Unforutnatley, I cannot run 2.2 in geoserver so I'm kinda running blind when I back patch.
Jody and then hack until the test passes.
jmacgill what stops you running geoserver agsinst 2.2?
Jody Thought: tests for main are too big to actually run - especially when dblasby is just working on rendering. Probably why he would like to split out rendering?
Jody The only thing that stops us splitting out rendering is lack of a common API for J2D and Lite.
dblasby thats one thing – it takes me 10+ minutes just to run the tests. most of the time they fail on trunk anyways. My personal testing is 1000* better than the test cases.
Jody We could split them out early - before there is a common API. Move them to ext ....
Jody I would rather cull the tests in main to the point they were run, then have developers duck them.
Jody dblasby to make you productive two ideas: 1) cull tests in main 2) move renderer code to ext
dblasby how about putting the renderer in its own module?
dblasby ext/ sounds like "bad code".
Jody extention
Jody things like graph and validation that are built ontop of the rest of the library
Jody extention not plugin.
dblasby weird - why's the index shapefile in there instead of plugin?
Jody aka not bad, graph is one of the nicest things available geotools hacker. It just is built on top of geotools.
dblasby i thought it meant "experimental"
Jody Well it is supposed to go back and clobber the origional, but jesse has not had time/inclination.
Jody but you are right it should be moved - it is a plugin.
dblasby I'd really like to see main as a small little thing, but ...
dblasby jmacgill agenda topic - OnlineTests or should we continue talking about this?
jmacgill that topic relates to some of these problems so, yes lets move on
Jody No - it kind of used up all the time. I gotta go soon, ...
jmacgill my attempts to keep trunk building were hampered by random failures in the wms and wfs modules
jmacgill the failues tended to be because of remote server changes or outages
jmacgill I have changed the top level project file to EXCLUDE any test wich matches the pattern *OnlineTest.java
jmacgill I have renamed most of the wms tests to match that pattern
Jody This is kind of hard, for client software (like WMS and Postgis) they kind of need to hit a server.
Jody Is there some kind of switch we can throw to actually run the tests?
jmacgill you will need a modified version of the toplevel project.xml file, I could find no easy way to do it from a property
jmacgill that said, if this solution is not workable, I will find a way to do it off a properly
jmacgill property even
Jody I would rather we did what WFSGeoServerTest does - it only runs if there is a localhost geoserver to test against.
Jody And if there is not it just throws out some warnings but does not fail. Only way to get failure is to a) have a service b) not work
Jody Postgis, Oracle etc work the same way (only fail if user has supplied valid connection info)
jmacgill ok, but I do not have the time to set that up for the wms and wfs modules. The mainitainer would rather they were excluded from all builds completly until release time
Jody James my response is not helping - I would prefer things were done "right", but failing that OnlineTest seems to be a good option. You may be able to hook into the maven -o property
Jody okay, and createRelease includes OnlineTest ?
jmacgill no, it does not, the change has to be done by hand. Not good I know, but I needed something, anything, now.
jmacgill the net result by the way is this:
jmacgill [Geotools-devel] [CC-Trunk] geotools build.182 Build Fixed
jmacgill yes the -o switch would be good...
jmacgill thinking....
Jody Thanks james having the build up is the #1 priority
Jody I kind of wanted to talk to bowens about FM, but I am out of time for today. Bowens do you want to set up an IRC meeting with Gabriel?
dblasby fm?
Jody Feature Model = FM
dblasby ah
Jody Unless bowens had a couple of questions before I go?
bowens yes
Jody Shoot
bowens schema in ComplexType and Complex
bowens are they the same schema?
Jody Just getting the picture, and did you read the javadocs?
bowens yes
Jody So the schema for the ComplexType is supposed describes its contents. It is a List<Schema>
Jody ah I get it
Jody so ComplexSchema.schema() could/should be removed.
bowens ok
Jody just like FeatureCollectionSchema.getMemberSchema() - cool good call.
Jody lets try and have everything only once in the diagram - make it a proper data model. And insert helper methods later.
bowens in your example of FlatFeature, you have get(AttributeType type), should it be get(Type type)?
Jody If you download Omondo you can edit that picture - it is checked into svn.
Jody Yep.
bowens ok
Jody So yeah check out the code, edit the picture, it should all be good.
bowens that's all the questions I have. I'm still looking at Gabriel's diagrams
Jody Hard to evaulate until FeatureCollection is in the picture. You saw I updated http://docs.codehaus.org/display/GEOTOOLS/Feature+Model+Discussion with a description of the remaining issues: ID, Super, ...
Jody So if you can answer any of those "Q:" it would be great .
bowens k
Jody Thanks James - back to you
Jody (thanks to james for letting us interrupt his agenda item, thanks to brent for looking into FM stuff)
jmacgill I have to run off too
jmacgill I'm happy that trunk is building, but not happy with the solution overall
jmacgill I'll think about it more and update people
jmacgill I'll also look at ways to reduce the 'cost' of developing against geotools
Jody okay, were you going to take Justin up on his offer of doing builds?
jmacgill yes!
jmacgill I just wanted to tie some things off first
Jody to bad he just left, you could send him an email
jmacgill ok, so, trunk is up. lets see if it can last 24 hours
jmacgill I have to head home now
Jody I will leave my machine on and try to gather up logs later...