Andrea Aime wrote: >> Fair enough Andrea; but this is the third implementation (GeoTools >> has throw out two already) - the only way I am going to get this >> documented to your satisfaction is to set uDig and GeoServer up to >> actually use it - and this is what is happening. > Nope... this is not going to happen until we are satisfied it's good. > Geoserver at the moment has no catalog usage whatsoever. Then why did Justin put it in? My understanding is your existing data modules (FeatureTypeInfo etc) have an implementation that implements these GeoTools interfaces. > Putting undocumented and untested stuff in main seems like a blitz to > me, not the proper way to do things in a community of peers. Justin moved quickly; and we were unable to review ourselves (it will be expensive for us to integrate this into uDig, but we figured since we could not give him the time of day when he needed it we have to take the pain).
All we can do is fix the policy that allowed this situation to occur: this is the motivation for the "unsupported" module system (ie GeoTools formally asks for documentation upfront before work is rolled into the core library). > Chris did not even knew the catalog stuff was there, and I only > discovered it because coverage reports showed me a big package with > no tests whatsoever. I knew it was there as Justin was asking for code reviews for two months solid; not sure if he sent those to the list or to me personally. >>> Hacking is fun, but maybe someone wants to understand what you're >>> doing too... where are the docs???? Where is the discussion on how >>> and why this thing is better than the DataStoreFactories it tries to >>> replace, but in fact apparently just duplicates (many methods in common >>> between the factories and one of your service objects). >> Andrea why don't we start that discussion - with your question about >> Factories vs Catalog Handles >> >> DataStoreFactories are about connecting to external resources (they >> *only* create a class after all). Both our real applications have >> other needs: >> - Manage Resources (ie instances) - previously the best adivce was to >> storing DataStores as singletons! >> - Be Lazy (describe the content before connection (title, bounds, >> description,etc...), GeoServer tracks this information as part of its >> configuration (simply not good enough for uDig, or even users - we >> all expect this stuff to work "out of the box') > I agree with both as a general need, but I need Chris to allocate time > to study it if no documentation is around at all... I think Justin already booked some documentation time to clean up the mess after his OWS-4 project (I would consider this part of the mess); for myself I plan to help out by getting uDig on trunk where I can use a large existing code base to stress test this (and other) mad changes. Jody ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
