> modules/unsupported/example This one is still useful - it is used to "svn copy" when creating a new module.
> modules/unsupported/mif * > modules/unsupported/tiger * > modules/unsupported/vpf * > > If you don't want any of the above modules to be removed please speak up now. I have heard of some of these being useful over the years; but yeah cut scope. > The build/maven/javadoc plugin requires > some thought, it has that single taglet > that can be used to report in which module > the class appears in and a tool that can > be used to automate the insertion of the > taglet in the source code. Do we > want to keep it? Dunno. If we keep it > it would be a good idea to start using > it for good in all the codebase. I had not heard of it before; the ability to list what is in which module is a common request on the user list; if we can generate a report for this information it would be good. > The modules/plugin/epsg-wkt is undecided. Do we remove it, or we keep it > around for people that do not want to use an > embedded database that writes down on the file system? This has some functionality; it is not longer mission critical for udig so I did not comment. > The geometry modules in unsupported are in > a sort of a limbo state. Like, there is no one > supporting them, yet we know there is interest > growing to support more than just JTS geometries. > More confusing, Jody stated he would take > modules/unsupported/jts-wrapper but then on the > users ml he suggested a user to not use it > and give modules/unsupported/geometry a try > instead? Both of these geometry modules are unsupported; out of the two I recommend the unsupported/geometry module (since it has better test cases). Until iso geometry is actually intergrated at the datastore level I do not recommend them to any one. I am also grumpy with the referencing module for implementing a few geometry constructs (DirectPosition etc) and not delegating their creation out to a Factory. I agree they are in limbo in terms of funding; I can baysit them if needed; but until there is a real driver for change they are going to stay as they are now. If we want to make a decision to close off this direction I would like to recast referencing module to use JTS directly. If we just want more time I can babysit these as unsupported modules. > modules/unsupported/repository is kind of strange, > Jody said "jg: I would like to kill this as a distraction > to the user community" but I know he's working on > some repository related stuff... so I'm confused. The Repository interface in the data module is fine; and predates any talk of a catalog. Please kill this unsupported/repository module. > Jody, the work you're doing is outside this module, and thus it can be safely > removed? Yes. > This should be it. Let me know if I got anything wrong. Jody ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
