Martin Desruisseaux ha scritto: > Jody has posted rencently a number of wish for GeoTools 3. Do we have > any idea when such project could be started? More specifically, is > the following doable? > > * Start with a totally empty repository. Mercurial proposed because > it is bundled with NetBeans (I don't known for Eclipse), > intentionnaly designed with very svn-like commands (so learning curve > is easier), and merging is going to be important for my proposed > plan. However you don't need to quit SVN for a while - more on it > below.
For the record, there are two very very young mercurial eclipse plugins. Don't know if they are any good, probably not since the version number is stuck around 0.2.something... > * Copy code from GeoTools 2 to GeoTools 3 on a module-by-module > basis, in dependency order and only when we feel this module is clear > enough. Since metadata is first on the list, this means start the > work only after we selected what should be the factory system. > > * Don't bother if it take years to move most modules to GeoTools 3. > We have GeoTools 2 working; developpers could work on GeoTools 2 and > merge to GeoTools 3 only the clear code - no module commited in a > rush because of time constraint in GeoTools 3. In other words, > GeoTools 2 become the "unsupported" or "sandbox" area of GeoTools 3. > This doesn't means that GeoTools 2 quality would be compromized. The > intend is rather to be more conservative in the GeoTools 3 code base. > > > * Since it will take a long time before we get metadata, referencing > and geometry (the basic modules needed before we start porting main, > renderer and the like), it will not impose any additional work to the > community except for the maintainer of above modules. In other > words, most developpers outside Geomatys don't need (but are welcome > if they wish) to bother about GeoTools 3, Mercurial and the like > before there is at least a basic geometry module (may or may not be > backed by JTS) running, which will probably not happen before > mid-2009. If I look at it from a resource unconstrained perspective, the plan looks nice. gt3 becomes the place where we remove all deprecations, all mistakes done in the past, and carry on only the code that we know is good. However, if I take into account the reality of current projects, my enthusiasm for it quickly goes away. The way GeoServer (and probably uDig too) goes on is sponsor driven, but no one ever pays for big cleanups, meaning that I'm having difficulties imagining anyone putting in the resources necessary to rewrite most of the datastores and vector handling facilities in general so that uDig and GeoServer can be ported over this brand new world. Given what I see on the horizon, I believe most innovation on the vector front (complex features for example) will keep on being developed in the 2.x.x repository, as well as all the work on ND Coverages done by GeoSolutions, since that one is totally driven by someone sponsoring ND features on GeoServer. That would eventually lead to a fork in the coverage module. Rendering is probably going to be similar. If we want to deal with ND coverages (think wind maps) as well as a few other needs, we'll need a more general renderer, go-1 could be a candidate (provided it's possible to plug StreamingRenderer as a single layer renderer into it), but if that development moves to gt3 repo, we'll eventually have another fork or, in less strong terms, duplication. My concern is that this will eventually lead to a long time fork of the code base, with Geomatys working on the GeoTools 3 codebase, and RR and TOPP working on the 2.x.y one, sharing just the name of the project and diverging into two different directions. Am I seeing dark clouds at the horizon that are not really there? Jody, what is your point of view given the planned future of uDig? Cheers Andrea ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
