Martin Desruisseaux wrote: > Jody Garnett a écrit : >> - Arguments - yet another command processor for static main( String >> args[] ) > At the time I wrote this one, I was not aware of existing tools like > the ones below: > > http://jakarta.apache.org/commons/cli/ > https://args4j.dev.java.net/ No worries Martin, and picking up an extra dependency is a high price to pay for something similar to this. Reminded of a blog rant on dependencies considered harmful ;-) > I don't know which one is best - I did no investigation yet. If the > Geotools PMC selects a command processor to be choosen as the > "standard" one for Geotools, I can use it in replacement of "Arguments". Lets leave it well enough alone, we are a library for spatial stuff, lets keep our dependences down to a minimum and let application writers make up there own mind. >> - ClassChanger - so strange I do not really know what to make of it, >> kind of like a "binding" but for compariable > This class lives in the org.geotools.resources package. It is used > internally in some corner of the API (I don't remember which ones), > and users should not really be aware of this one (it is supposed to be > hiden from javadoc). I am just curious because the same or similar code exists in parameter parsing for data stores, and then again for the handling of literals in Expression evaluation. Indeed I was thinking of setting up a FactorySPI extension point to let people teach geotools how to handle new data types (by way of letting a Java 5 application I work with use geotools to handle some enum types).... And the new FeatureType builder also has some fun stuff that is very close, not to mention good old AttributeType.parse( Object )....
In short I think we are duplicating up some code around the issue of type mangling and perhaps breaking out something similar to hibernate UserType would be a very good move. > Back somewhere around 2002, we were looking about what to do about > classes that should have been package-privated, but can't because used > in more than one package. We agreed in some IRC about selecting > "org.geotools.resources" as a package with a special status in > Geotools. Everything in "org.geotools.resources" (and sub-packages) > should be considered as if they were package-private classes, and > actually would have really been package-private if those classes were > used by a single package. Cool, something to write down for the user docs ;-) Heck I never new that one ... > Compared to Sun java implementation, "org.geotools.resources" is > equivalent to "sun.*" packages: Cheers, Jody ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
