I am quite concerned with going to the 1.4 branch on trunk. Mostly for
what justin *didnt* mention than what he did.
The source code re-organization, maven build, and adding spring are all
great - they are not major (in the risky sense of the word) changes.
NOTE: I asked justin about the spring changes, and it seems to be there
"for future work" and is basically unused at the moment. So, this
shouldnt be a concern for anyone.
What justin didnt mention is the fact that Geoserver has jumped from the
geotools 2.1.x branch - this is the 'stable branch' which is *very
stable*. Geoserver 1.3.x and udig 1.0.x are based on this. Its very
good.
1.4 hasnt jumped just to 2.2 (which, as far as I know doesnt have a true
stable branch) but straight to 2.3 (which doesnt really exist yet).
2.3 is, I believe, 2.2 with about six R&D efforts merging in. Its not
stable - in any sense of the word - and its unlikely to be stable for
"a while."
In fact, as far as I can tell, over the last 60 days, geotools trunk has
only actual been able to *build* for about 23 of those days.
And, if you try to build geoserver 1.4 right now, you'll find that it
doesnt actually compile because the geotools API has changed (again)
and is incompatible with whats currently in 1.4.x.
This doesnt bode well for me as I want a stable, useable Geoserver.
Geoserver only uses the very high level geotools api (up until very
recently geoserver was compatible with both 2.1.x and 2.2.x). I asked
justin if the 1.4.x branch is compatible with 2.1.x. He said there
were "a lot" of modifications to geoserver to get it working with 2.2.
There are "just a few" modification necessary to get it working with
2.3.
Perhaps justin could give us a summary of what changes were necessary?
Geotools is supposed to be backwards compatible by one version so,
theoretically, there shouldnt be any changes necessary (and up until
recently none were required).
In the ideal world, I'd like to see geoserver compatible with both 2.1.x
geotools and 2.2 geotools. This way people who are doing Geoserver R&D
experimental work can just set the "use geotools 2.2 or 2.3" switch and
the people who want a stable geoserver can set the "use geotools 2.1"
switch. That way we can all work together and everybody are "shinny
happy people".
You can probably convince me to move to geotools 2.2 (assuming there is
an actual stable branch), but I think its suicide to go right on
geotools trunk. Especially considering the number of changes that are
going to be happening Real Soon Now.
Another big concern is that putting 1.3 on a branch just means we're
going to marginalize and forget about it. I want to see a stable
geoserver; a geoserver that people (including myself) can build stable
applications on. I'm sure there's lots of people who want to see that
too. Geoserver uptake is dependent on this.
I'd like to keep 1.3 on trunk until at least the time that there's a
stable (and good) geotools 2.2 branch and 1.4.x is working well with
it. That means one thats as good as the current 1.3. There's no point
in going *backwards*.
People who require geotools 2.3 or geotools trunk should be on a
1.4-like branch. We can merge in when geotools has a good, stable 2.3
branch. Justin says there's only a few lines in 3 classes that are
different for geoserver to go from 2.2 to 2.3, so maintaining sync
between the two branches should be very little work. In fact, it could
be possible to make geoserver compatible with both 2.2 and 2.3 and then
we're really cooking with gas!
dave
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/