Hello, The example given by Joel is not really relevant to the proposal. Here Martin is really suggesting some spring cleaning rather than any rewrite from scratch.
In our case, one of the major benefits of open source is to create a project without business constraints ( "It will be released when it will be ready") and produce a really good source code quality. This is why Linux and others major FOSS projects won important battles against closed source projects. Now we are all trying to meet deadlines, we tend to have a "It will be released when my client needs it to be" but I'm sure that in the middle term projects who don't respect the initial policy will die by the lack of quality of its source code (remember everybody can have a look at it). If we continue thinking GT evolution only with business in mind, and if we don't take care at GT code quality and consistancy of it's architecture it will never be a serious alternative to ArcObjects or MapObjects or whatever proprietary geospatial toolkits. The reality of the market now is to respect interoperability statements by following OGC and ISO standards because customers want it (cf. INSPIRE). An other reallity is to produce the best toolkit ever by adopting a strategy where we can avoid side effects produced by business constraints. Doing business with a 2.X branch and creating a 3.x branch with no concessions is certainly the best way to go. My full time job now is to find customers who can sponsors the 3.0 approach, accepting a longer delay in their projects, but with a stronger and sustainable architecture (with good performances of course). It's perhaps an other business model than the one we have been applying, but I think it will be good for the long run. Vincent Le 30 juin 08 à 16:04, Andrea Aime a écrit : > 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 > ------------------------------------------------------------------------- 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
