Hi,
I'm writing this mail to sum up the module cleanup
wiki page.

The mail is long, if you want to discuss a specific
module's fate, can you please reply changing the subject
to include the module name so that the thread generating
out of this mail gets a little organised?
Something like:

"Modules cleanup: modules removed (build/javadoc)"
if you want to discuss the fate of the javadoc maven
plugin.

On a more practical issue, for modules where there
is consensus for removal, I would like to just go an
kill them, only on trunk, next weekend.

Modules going to be removed
---------------------------------------------------
It seems there was consensus enough to remove the
following modules (that is, some suggestions to
remove these modules, no -1):

build/dummy/jaxb
build/maven/archetype
build/maven/build-configs (already gone)
build/maven/javamaker
build/maven/unopkg
build/scm/cleanup
demo/introduction
modules/extension/openoffice
modules/plugin/epsg-access
modules/unsupported/epsg-oracle
modules/unsupported/example
modules/unsupported/geomedia
modules/unsupported/gml
modules/unsupported/hsql
modules/unsupported/mif
modules/unsupported/notifying-collections
modules/unsupported/tiger
modules/unsupported/vpf

If you don't want any of the above modules
to be removed please speak up now.

Modules that need more work, checks
----------------------------------------

The following need more checks in order
to be removed (switch to Mojo equivalent
plugins):
build/maven/jjtree-javacc
build/maven/rmic

The shapefile-renderer is in my crosshair
for removal, but it cannot be removed until
I can pour in enough work to make the
streaming-renderer + shapefile datastore
be as fast as the customized renderer.

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.

Jury still out
----------------------------------------

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?

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?

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.
Jody, the work you're doing is outside this module,
and thus it can be safely removed?

The gpx related modules are confusing me,
and no one replied to this thread about them:
modules/unsupported/gpx
modules/unsupported/gpx2
modules/unsupported/xml-gpx
I believe Landon (the Sunburned Surveyor) has worked
on one of them, but I cannot tell which one?
Landon, can you clarify so that we can decide
what to remove, if anything?


This should be it. Let me know if I got anything
wrong.

Cheers
Andrea

------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to