I'm copying this email on user and developpers list so peoples can be inf=
ormed of what is going on=20
with GO-1 development (from legacy StyledMapPane and j2d-renderer).
The 'legacy' and 'migrate' modules have been removed from SVN (both 2.3 t=
runk and 2.2 branch).=20
However the code still available on a separated 'legacy' branch, until GO=
-1 development will be=20
finished.
=D0=9E=D0=BB=D0=B5=D0=B3 =D0=95=D1=84=D0=B8=D0=BC=D0=BE=D0=B2 a =C3=A9cri=
t :
> So, I've finally defeated my organizational problems and Maven (it's a =
tough one) :)
>=20
> Ext/go is compiling, I'm ready for further instructions!
Nice! I suggest that you also performs the following checkout:
svn checkout http://svn.geotools.org/geotools/branches/legacy/
and mount the 'legacy/src' and 'migrate/src' sub-directories into Netbean=
s. You can ignore=20
'legacy/src' (it is only needed for compiling). The interresting director=
y is 'migrate/src'.
The general rule is: as soon as a method has been ported from J2D-Rendere=
r to GO-1, we deprecate the=20
corresponding method in J2D-renderer with a "@deprecated Replaced by {@li=
nk ...}" javadoc tag. When=20
we finished to port all methods from a class, only then we deprecate the =
old legacy class. It allow=20
us to generate a javadoc as a kind of "how to migrate from J2D-renderer t=
o GO-1". Most of the time,=20
there is a one-to-one relationship.
The work is monitored there: http://jira.codehaus.org/browse/GEOT-415
Steps to do
-----------------------------------------------
Our first step is to implement the following GeoAPI interface:
http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/spatialschema/=
geometry/geometry/PointArray.html
It is implemented in the org.geotools.geometry.array package. PointArray2=
D is the abstract base=20
class tuned for GO-1 renderer needs. Try to become familiar with this cla=
ss and its=20
geotools-specific extensions, since it is at the hearth of GO-1 renderer.=
Important additional=20
methods (compared to the GeoAPI interfaces) are:
- getBounds2D
- iterator
- toFloatArray
- subarray
For PointArray2D and subclasses, performance matter. Some method make ass=
umption for performance=20
reasons. We should be generous on usage of "assert" statements in such me=
thods.
We need to port all remaining classes from the legacy org.geotools.render=
er.array package. Ignore=20
all classes already marked as @deprecated (either they are already ported=
, or we choosed to not port=20
them).
I suggest that you begin with DefaultArray (probably to be renamed Defaul=
tArray2D, unless someone=20
has a better name to suggest). Try to retrofit 'getFirstPoint' and 'getLa=
stPoint' implementations=20
into the 'get' method, if applicable. Note that the 'count()' method has =
been renamed as 'length()'.=20
Maybe some other methods were renamed too, I don't remember - we need to =
be carefull about method=20
names same some of them override methods in super-class. Javadoc need to =
be translated from French=20
to English - I will take care of this part, unless you can read French :)=
.
We need an extensive test suite, as JUnit tests. We should port the JUnit=
tests from the=20
'legacy/migrate/test' directory (only the tests related to DefaultArray f=
or now). If there is no=20
tests for DefaultArray, it would be nice if you could write somes (it wou=
ld also be a way to dig in=20
DefaultArray working). If some tests already exist, feel free to add more=
tests.
Thanks,
Martin.
|