> I am aware that GeoTools blog announced the end of GeoAPI development in
> 01/2011 [0]. However, my question relates on having different GeoAPI
> versions as project dependency.
>
>
Interesting! If so you would need to not depend on the gt-opengis module (if
you are in maven you could do this
by marking it as "provided").
And then you would be left with incompatibilities ...
> As GeoTools was highly involved in
> GeoAPI development I hope that s/o can give help anyway.
>
>
Perhaps :-)
> I use an own framework which has implemented its own feature model with
> regard to GeoAPI 2.0.0. I have to make coordinate transformation stuff
> in another project (using the framework) and want to use GeoTools
> (version 2.7.3) for that.
>
>
Okay I think I get you; so GeoAPI version 2.0 should ship in a couple of parts
- but for the coordinate stuff a few of the methods will be different or
otherwise renamed.
Because the GeoAPI project is the work of many years the standards being
targeted have changed over time.
> The problem I run into now is the following. Each time I run the
> transformation, GeoTools complaints about an incorrect interface:
>
>
>
> ,------------------
>
> java.lang.AbstractMethodError:
> org.geotools.metadata.iso.citation.CitationImpl.getIdentifierTypes()Ljava/util/Collection;
>
> `------------------
Yep that would be one of the changes.
> Obviously, it depends from which GeoAPI version the classes are loaded
> from first. A different dependency ordering results into a similar error
> thrown from the other framework I use.
>
>
Could you port your referencing code to the gt-opengis module definition of
Citation? There should not be many method changes (I hope).
> I would like to discuss some possible solutions here (if this is the
> right place) how to handle such a situation. Currently I see the
> following possibilities:
>
> a) Checkout GeoAPI 2.0.0, modify package structure and recompile the
> own framework with modified GeoAPI (this implies to create a new
> artifact and providing it in our own repository)
>
>
This may be the same as using gt-opengis interfaces (which were taken from an
early cut of geoapi - you can check the logs to find out which one)
> b) Downgrade GeoTools to(I believe) version 2.2.0 which is quite old
>
>
Indeed, not recommended.
> c) Update own framework's feature model to comply to GeoAPI version
> GeoTools depends on (which implies to stick with a freezed library)
>
>
Yep; that would be the gt-opengis module (we copied and pasted the geoapi
interfaces into geotools at that point).
> d) Completley remove the GeoAPI dependency of the own framework to get
> rid of GeoAPI which is (in my eyes) not backward compatible.
>
>
It is not; but I cannot be too harsh since geotools is not always backward
compatible either.
(We do have a handy upgrade guide if that helps).
> Although not a nice solution, I tempt to go for version a) but I am
> curious to hear other meanings (maybe I am completely wrong here!?). For
> now, I see d) as my current long time favorite, but this means a lot of
> work for now.
>
See the response above; I hope it is not too much work :(
>
> Best
>
>
> Henning
Jody
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
