Re: [Geotools-gt2-users] Supplied shapefilerenderer patch for 2.4.x? Maybe? Please check ...

[Andrea A. <aa...@op...>]

Enam ha scritto:
> I have actually 1) installed maven 2) checked out source 3) build the project
> 4) tested the shapefilerenderer in my project. It works as expected when I
> apply the patch. Without the patch, only one type of geometry is drawn. 

Hi, I've looked at the patch and I have troubles understanding why it's 
needed. On 2.4.x that code path is used only if the geometry handler 
reading the shapefile returns something that's not a JTS Geometry 
object. Maybe on 2.3.x things are different...

> It
> would be nice if 2.3.6 could be released with this patch. 

We need a volounteer to do so. Most releases of the 2.3.x series have
been created to accompany a correspondent release of GeoServer 1.5.x
Now that GeoServer 1.5.x branch is abandoned we have no more reason
to create one. uDig is not using it either, so development on 2.3.x
has come to a total stop with the GeoServer 1.5.4 release.
Doing a release takes at least half a day we need someone that has a 
reason to do it.

> I am also eagerly
> waiting for 2.4.x to become a stable branch (2.3.x has too much deprecated
> code like org.geotools.filter.Filter). 

2.4.x is as stable as it can get and we'll be releasing 2.4.0 final 
soon. GeoServer 1.6.0 will use it, as well as any future 1.6.x release.
So I guess for some time the branch will be maintained (at least until
GeoServer 1.6.x branch will be not be abandoned as well, so I guess 
between 6 months and one year?). The moment GeoServer stops using 2.4.x
developmen on it will stop since there is no one else using it.

About deprecations, on 2.4.x things are better but unfortunately the
filter switch to opengis filter is not completed because no one
has been willing to work on it.

> Our project previously used 2.1.x. I migrated the whole project to use 2.3.x
> and was a rather painful process. Some of the mess is still there in 2.3.x
> branch such as datastore accepts only org.geotools.filter.Filter instead of
> opengis filter. Just some late night babbling ....

Even on 2.4.x you have to build filters with the filter factory
and what you'll get will be opengis filters at the interface
level, geotoosl filters at the implementation level. Some datastores
will still break if you provide in your own custom implementation of
an opengis filter. If you need one, make sure you implement the opengis
interfaces but at the same time make it a geotoosl filter as well.

These issues will be eventually address on trunk I guess, since
uDig is jumping straight from 2.2.x to trunk and it has issues
with the above problem. GeoServer uses only factory generated filters
so it's not affected.

As you can see we are in a situation where GeoServer and uDig needs
are completely dominating the development. To change that we would
need some of the geotools users to step up and become a maintainer
of some module. That would allow for better mantainance and
a diversity of point of views in the PMC.

Cheers
Andrea