[Incubator] New Application: GeoToolkit

[Adrian Custer]

     [Forwarded on behalf of Martin, who is not subscribed to the list]


Hello Jody

I would like to bring my point of view on some of the point raised:

Jody Garnett a écrit :
> We had ask Martin to step down last month which was very dissappointing.

Actually my decision to step down from the PMC has been taken before that, the
same day than when we decided to fork. It was not announced immediately 
because we wanted to have the geotoolkit web site ready before to make the 
anouncement.

> A couple specific things that got me:
> - strategic decisions that should be made as a community were being
> made behind closed doors

The mercurial repository was public since the begining, and the main lines of
the most important changes were documented:

     http://www.geotoolkit.org/build/tools/geotk-migrate/changes.html

The above link has been given on the mailing list in various "report on 
geotidy progress" emails. The PMC did not commented those changes as far as I 
know.


> - A specific technological direction - the use  of JaxB an xml parsing
> technology - we were unable to accept as it could not be used with
> Java 5 (representing our current installation base)

JAXB can be used with Java 5 - you just need to add the JAXB jar file provided
by Sun or other vendor. This is exactly the same situation than the Eclipse
technology used in other GeoTools modules, which require an eclipse JAR file 
for parsing XML.

Note that in Java 6, JAXB is integrated straight in the JDK so there is no
longer external dependency, at the opposite of Eclipse-based XML parsing.

What was considered unacceptable was the addition of a dependency to an other
JAR file (JAXB) for Java 5 users, which I can understand. For this reason we
provided a mechanism allowing to "erase" JAXB annotations at compile-time for
those who don't want them. This mechanism worked with Maven (the official
GeoTools build tool) and NetBeans (the IDE we use at Geomatys), but was broken
on Eclipse (the IDE used by Geoserver developers). Consequently we rolledback
JAXB and moved our work to an other repository. At this time (one year ago) it
was for us a branch, not yet a fork.


> - in ability to accept patches; we had a $60k referencing patch that
> sat in the code base for 3 years; which we now see integrated on this
> fork

There are patches that I accepted much faster than this particular one. 
Generally speaking I have been happy with Rueben Shulz's work for instance.

I did not accepted that particular patch because I was not happy with that 
code. When as a module maintainer I asked for changes (on the mailing list), 
someone from Refractions replied me that the contract with the client was over 
and if I wanted my change requests to be applied, I need to pay Refractions - 
or I should have done my requests sooner.

I have spent 10 years writting referencing. Then Refractions stepped in this
module which was mostly unknown to them. No use case was given for justifying
their objective, despite our questions on the mailing list. The result of that
work was in large part duplication of existing code.

That work has not been integrated "as is" in Geotoolkit. The code duplication
has been simply deleted, and the most noticeable new classes (ObjectCache and
related) have been rewritten from scratch (compare with the "Cache" class on
Geotoolkit) for technical reasons.

I rewrote all this work in 2 or 3 weeks. Knowning that Refractions has been 
paid $60k for that just add to my amertume.


	Regards,

		Martin