year; indeed I mentioned that in my status report to OSGeo.
adding OSGi manifest information.
have no say in its direction or development. When there is a proposal
I have a roll to play and will pay attention. Ideally I like the idea
expensive for everyone involved.
PS. I agree with your points about being careful about branding (and
branch was run for years). I actually made the same point on the udig
list last week; also about the OSGi manifest repo/branch.
Post by Andrea Aime
Post by Martin Desruisseaux
This bring the question about when geotidy can be offered for a merge with
GeoTools. Currently the referencing module is done, except for Oracle and HSQL
plugins of EPSG (I'm doing my test on PostgreSQL for now) and the builder
package, maybe to move in an other module.
GeoTidy has been source of many headaches so far, at least for me.
I appreciate the need for cleaning up the code, and I'm _very_
interested in the list of improvements and fixes you've implemented
there (I really mean it).
On the other side, GeoTidy has been created on a separate repository,
and managed by a single person, which makes it look a lot like an
The list of changes
also says in some places GeoTidy is GeoTools 3, but there is no PSC
agreement on it, it's a single handed decision.
Also, to my knowledge no-one outside of Geomatys has right now the
resources or the need to create a GeoTools 3 branch.
I thought the plan was to make GeoTidy a replacement of the referencing
modules that could be used by GeoTools trunk, yet the number of
changes, removed and renamed classes seems to preclude a solution
in which the GeoTidy changes are simply merged into the GeoTools SVN
(that is, the place where the official GeoTools library is stored).
An alternative path that seems promising would be to build GeoTidy
a GeoTools compatible version that GeoTools trunk can depend onto,
just like we depend on many other external libraries.
This would also clarify once and for all that GeoTidy is its
own library, separated from GeoTools, on which GeoTools depend
just like it depends on JAI, Jakarta commons, Batik and many others.
It would also fit very well with your intention to be the benevolent
dictator of GeoTidy, preventing anyone else to directly commit on it.
It also seems, and this is new to me, that GeoTidy contains also
coverage handling classes. Mixed with your intention of being a
benevolent dictator of your modules I find this very disturbing,
as it would prevent Simone from contributing to it (after all
you said at FOSS4G 2008 that you don't want anything to do
with Simone, with various other PSC members present that can confirm
what I've just wrote).
Simone work is what made the difference between unusable raster
support to something that can rival with MapServer on standard imagery.
Also, we have a very strong need for a more serious coverage I/O
support that the "coverage store" proposal seems to match pretty
I appreciate that you're open to work on that, but past experience
show that does not mean we'll get anything usable in the
year to come. After all, Jody's threading issues have been officially
considered and merged into GeoTidy 1.5 years after he proposed
them, no? I don't think we can wait that much, plus I don't
want a situation in which you're the sole judge of what's
good and wrong in a proposal, this is a community, and the
PSC is the only valid judge on proposals.
You've completely bypassed the PSC and the proposals
mechanism for all the GeoTidy code changes, which makes me believe
you're not interested in collaborating with GeoTools by its
rules. In your own library instead you're free to do pretty much
what you want, without asking other people and without compromising,
but that's no more a community effort, that's no more GeoTools.
So, whilst I see a viable future for a GeoTools dependency on
GeoTidy as an external referencing library, I have reservations
that the same could be made work for coverages.
In order to bring GeoTidy back home it is my personal opinion that
- make all the API changes occurred in GeoTidy go through
a standard GeoTools proposal process and merge back on svn
- accept the fact that the proposal mechanism in GeoTools
might overrule your judgement on coverage handling.
In particular, when the coverage store api reaches the
proposal stage, it may well happen that you have the only
-1 on the proposal. In that case after two subsequent votes
the proposed changes would go in even if you're the maintainer
of the module
As I said, this is only my point of view, a PSC vote is needed
to deal with this matter, but first we have to sort out a
list of possible action plans, discuss, and vote on the best one.
Btw, a shared and distributed community is one of the requirements for
OSGEO incubation, DeeGree is having troubles incubating because
there is a single company behind the project. They only lately
A benevolent dictator model is nor open nor collaborative.
See for example GDAL, where Frank W. had to give up the benevolent
dictator model for a PSC made of people coming from different
One last hard question.
You're a PSC memember, yet the whole GeoTidy thing seems
to either suggest you're either not recognizing the PSC anymore
(given you've bypassed the proposal mechanism whilst still
using the org.geotools package names)
or that you already decided that GeoTidy is a separate library.
Which one is it?
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
Geotools-devel mailing list