As promised in my status update earlier in the week .... I am indeed causing trouble.
Andrea asked me to pass on an "out of the pool" email while compile errors are fixed on geoserver trunk.
So far the compile errors seem to be cases where geotools now expects a SimpleFeatureCollection to be provided; we should be able to tone that down a bit but need to hunt down the instances...
Jody
Jody Garnett ha scritto:
As promised in my status update earlier in the week .... I am indeed
causing trouble. Andrea asked me to pass on an "out of the pool"
email while compile errors are fixed on geoserver trunk.So far the compile errors seem to be cases where geotools now expects
a SimpleFeatureCollection to be provided; we should be able to tone
that down a bit but need to hunt down the instances...
Just a heads up to everybody. I made a local git branch to perform the
changes to SimpleFeatureCollection, SimpleFEatureSource and so on and...
the patch is a wopping 580KB already (I'm missing 5 classes that still
do not compile).
The process followed so far was to do a search and replace of:
FeatureSource<SimpleFeatureType, SimpleFeature> -> SimpleFeatureSource
(the same for store and locking)
FeatureCollection<SimpleFeatureType, SimpleFeature> -> SimplleFeatureCollection
FeatureIterator<SimpleFeature> -> SimpleFeatureIterator
and then do a mass "organize imports" to fix all the missing imports.
I did not change the main GEoSErver feature source wrappers, those
are still generic.
Then hand fix what the above process did not fix already.
None of the above changes makes GeoServer more married to simple
features that what it is already (afaik), but since we're talking
about a class and not about generics anymore it makes things a tad
more explicit, e.g., the compiler will not provide warning anymore,
but real compile rrors. E.g., in the code there was a ton of:
FEatureCollection<SimpleFEatureType, SimpleFeature> coll = (FeatureCollection) whatever;
In retrospect I believe this makes it easier to spot the parts of
GeoServer that are actually complex feature ready.
As you can imagine it makes for a lot of changes... and a massive patch
(the mass "organize imports" adds quite a bit of unrelated ones, but
at the same time going through all the files that were changed and
make a manual one was going to be crazy... in some places the
old imports are legitimate since the code was already complex feature
ready).
At the same time, GS trunk is not building now.
Does anyone want to suggest a different approach or review the patch?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
I would say just continue on... as long as no actual functionality changes i don't see the need for an official review.
2c.
-Justin
On 4/30/10 8:50 AM, Andrea Aime wrote:
Jody Garnett ha scritto:
As promised in my status update earlier in the week .... I am indeed
causing trouble. Andrea asked me to pass on an "out of the pool"
email while compile errors are fixed on geoserver trunk.So far the compile errors seem to be cases where geotools now expects
a SimpleFeatureCollection to be provided; we should be able to tone
that down a bit but need to hunt down the instances...Just a heads up to everybody. I made a local git branch to perform the
changes to SimpleFeatureCollection, SimpleFEatureSource and so on and...
the patch is a wopping 580KB already (I'm missing 5 classes that still
do not compile).The process followed so far was to do a search and replace of:
FeatureSource<SimpleFeatureType, SimpleFeature> -> SimpleFeatureSource
(the same for store and locking)
FeatureCollection<SimpleFeatureType, SimpleFeature> ->
SimplleFeatureCollection
FeatureIterator<SimpleFeature> -> SimpleFeatureIteratorand then do a mass "organize imports" to fix all the missing imports.
I did not change the main GEoSErver feature source wrappers, those
are still generic.
Then hand fix what the above process did not fix already.None of the above changes makes GeoServer more married to simple
features that what it is already (afaik), but since we're talking
about a class and not about generics anymore it makes things a tad
more explicit, e.g., the compiler will not provide warning anymore,
but real compile rrors. E.g., in the code there was a ton of:FEatureCollection<SimpleFEatureType, SimpleFeature> coll =
(FeatureCollection) whatever;In retrospect I believe this makes it easier to spot the parts of
GeoServer that are actually complex feature ready.As you can imagine it makes for a lot of changes... and a massive patch
(the mass "organize imports" adds quite a bit of unrelated ones, but
at the same time going through all the files that were changed and
make a manual one was going to be crazy... in some places the
old imports are legitimate since the code was already complex feature
ready).At the same time, GS trunk is not building now.
Does anyone want to suggest a different approach or review the patch?
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.