Hi all, Last week at foss4g a number of us sat down in an informal GeoTools BOF:
* Adrian, Martin, and Vincent from GeoMatys * Andrea and myself from GeoServer / OpenGeo * Andrea and Sylvia from JGrass * Jesse from uDig * Jan Jezek from Summer of Code * And a number of other existing and future users Discussions ranged from a number of topics, so I will try to break the summary up into chunks. *Warning* this is a long email... so grab yourself a coffee first ;). Current Status of the Library ----------------------------- Much discussion revolved around the current state of the library, and much of the cleanup that needs to be done. Now much of this has been discussed over the last few months in various threads so I wont go over the issues in detail. But the general consensus is that Geotools, while a very powerful library, has become a quite messy one which is becoming increasingly difficult to manage. Bottom line: There is a lot of cleanup to be done. Cleanup that is hard to do since the library is so big and gets pulled in many different directions. Collaboration ------------- First a bit of background on the situation. As many of us know the folks at GeoMatys have started a project code named "GeoTidy". GeoTidy is essentially a fork of the geotools referencing and metadata modules. The reason for the new project is to give Martin an ability to do a lot of clean up in those modules which he has been wanting to do for quite some time, without being hampered by the rest of what is going on in Geotools. Furthermore is the need for Geomatys to work against Java 6. At the moment Martin has stated that he will no longer be actively maintaining referencing in Geotools 2 past the following: * minor bug fixes which are easy to apply * changes which keep referencing aligned with Geoapi End background. Discussion revolved mainly around coming up with a process to move forward which would account for all the following: * Prevent a Geotools fork and keep us working together * Give Martin the freedom to maintain Geotools referencing as he sees fit * Continue to allow projects which depend on geotools such as udig and geoserver to benefit from Martin's work We discussed tools (such as Mercurial and distributed version control) which could be of help in implementing such a process. While this is by no means set in stone, here is a process we came up with that we thought would accomplish all of our goals: * Martin continues to maintain GeoTidy as a separate project, what the final name of the project will be remains to be seen. And how that project will relate to "Geotools 3" (see next section) is up to the community. * A second mercurial repository for GeoTidy is set up and operated by Geotools. This second repository will pull changes from the geomatys repository. Any changes which are "incompatible" to GeoTools will not be pulled down. Such changes include Java 6 specific language features, and any 3rd party dependencies which are problematic for other modules in geotools (for example jaxb). Martin has agreed to do his best to separate commits so that the above changes are easily reverted. Note that Mercurial and distributed version control makes this easier than with conventional svn or cvs. * Geotools depends on referencing through maven, and referencing is built separately from the rest of the geotools library. GeoTools 3 ---------- We talked a bit about what might make sense for Geotools 3. Now this undoubtedly deserves its own thread but i will just summarize what we hit on. We thought that turning Geotools 3 into an "umbrella" for multiple projects might be a good way to proceed. For instance, geotidy or referencing would be its own separate project and maintained solely by Martin. Projects in the umbrella are built and versioned/released separately with dependencies managed of course through maven. The key point to make is allowing different parts of the library to move at different speeds by making them actually different libraries. Actually on a personal note this is a direction i have been wanting to see GeoTools move in for quite some time. Moving Forward with Geotools 2 ------------------------------ Since referencing in Geotools 2 will not longer be fully maintained it leaves us with the question of what to do for the remainder of GeoTools 2.x. We discussed a number of potential options: * Jump straight to the process described above and make referencing a separate project which the rest of geotools depends on through maven * Attempt to patch referencing in geotools with changes from geotidy for the remainder of geotools 2.x. * Do nothing with referencing and leave it unmaintained for the remainder of geotools 2.x. Finally we agreed that we could not, in one session and with only part of the community present, resolve all the issues before us. We would like to get a better handle on the work that needs doing (Jody's "technical debt"). We need to figure out a structure through which to isolate the parts of the library which need to move at different speeds or in different directions. Finally, we need explore various work flows and the impacts of distributed versioning systems to those work flows. This email is the beginning of bring our discussion out into the full geotools community so we can resolve some of these issues. -Justin -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
