Okay we have been at this for a few hours ... I think I have figured out what I want to see happen.
1. The 2.5.x release story with unsupported/supported modules needs to be clear. a) I figure deploying unsupported modules to maven is okay for right now; it is a good move that allows new contributors to join geotools and contribute (which is the goal here) b) The user list wanted unsupported modules as a separate download as well (I asked them after the last meeting). I don't want to do this: - making unsupported modules available for download would take away a motivation for making a module supported. - The GeoTools PMC should not be asked to take responsibility for code we have not reviewed (indeed by definition it does not meet the project standards). c) We always get stuck on the unsupported modules that lack a module maintainer - these modules are *required* for one of two reasons: - For modules that are required to complete a product story (Oracle Datastore I am looking at you). Frankly we are in a bind in these kind of things; as long as GeoServer keeps shipping with Oracle support Refractions can not make a good play to get a support contact (and make Oracle supported). We have customers interested in paying; but no threat is evident. Should we ask GeoServer to stop shipping Alphas with Oracle support? - For new unsupported work that is required for the library to build or function (xml parser stuff I am looking at you) we need to see if these can be brought in as supported modules. If we must we should make a new category for this kind of work - I need to emphasis that this is important - the modules we are talking about here are set up to address long term goals of the library (goals that may not be reached with in a single contract, or within a single geotools release). I would even consider "accepting" these modules as supported - with a known deficit of say test coverage. 2. Review of dependencies a) We have had several good discussions about dependencies - usually this focus on minimizing duplication (do we need 3 time support libraries?). Minimizing dependencies is a great direction to take and one it looks like everyone is motivated to follow b) Todays discussion about what we expect from a dependency is a good one - We expect open source? no. Or at least a dummy jar so we can build? usually. Or a profile so code written against a proprietary jar does not upset other developers? yes. - in terms of distributing a dependency I want to focus on that only for supported modules b) I *expect* unsupported modules to work with extra dependencies beyond what the rest of the library is using: - Remember the goal here is to capture experiments that otherwise are lost to the public community - experimenting with a new dependency is a great use of the unsupported idea - I need to respect the fact that unsupported modules are often work that needed to get done right now - as such I don't hold them to a high standard of review - I would like to welcome outside contributors to contribute plugins and Adapters allowing GeoTools to work with additional libraries (Jump? Deegree? Sextante? gvsig?). Providing an area to work (and the ability to be versioned along with the GeoTools library) is a good enabler in this respect. c) We need to be confident of dependencies we package up for download and distribution - going through the website is a good start - spots checks are a fine idea - we should focus on the supported modules that are part of the library d) Projects such as uDig and GeoServer that make use of unsupported modules (via maven dependencies) do so at their own risk - GeoTools makes no assurances - hopefull by the time a module is ready for supported status the dependencies have been vetted; we should put this as a requirement for a supported module In the specific case of imageio-ext I want to make sure the unsupported jars are not package up for download by innocent bystanders . For non-innocent bystanders like uDig we will help where needed before nominating the jar to be included in a release (ie supported status). Currently imageio-ext is central to our story of supporting additional raster formats; with Eclipse RCP framework we have the chops to handle the platform dependence issue - I am not interested in being pure Java (I already have an SWT dependency). Jody ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
