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. > I can see usages of catalog stuff in the data module of geoserver > 1.4.x, but cannot see anything in geoserver actually using the data > module. Community modules were (are) using it. > So we're basically not using it? Eclipse tells me stuff like > DefaultGeoserverCatalog is used only by unit tests, and the catalog > interfaces are used a little in the Data class, but seems only stored > there... it's like an unfinished work. Best talk to Justin then.... >>> 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). > > You're telling me uDig does not uses it? So it's not unit tested nor > real world tested??? It is a port of the uDig code; uDig will try and transition to these interfaces when we move to trunk (we are moving this afternoon). But right now we have some real conflicts (URL vs URI, and I am worried about the event model and the practice of wrapping vs superclass as the way to reference the ResolveFactoryManager).
uDig uses an earlier version of the code; not this version. >> 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). > Hem... I see no catalog module in unsupported, in fact it's still > there in main even on trunk... That is because it predates the policy ( the concept of "unsupported" modules is in part to bring situations like this to heel). 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
