Sorry for my late reply :). See my comments below. Am 20.01.2012 08:53, schrieb Jody Garnett: >> 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). Well, this would mean to port the whole framework to go with gt-opengis module (see option c) >> 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) Actually, with this option I meant to use both the gt-opengis module to satisfy gt and having the modified version for our own (bit outdated) framework .. >> 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). I do not have any problems with libs which are not backward compatible all the time (I beliebe this is not even possible over years). The thing is, that each GeoAPI lib comes along with big changes. Over time you only can hope that your dependencies uses the same GeoAPI version then. This is actually the point why I mentioned option d, anyway ;). >> 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 :( Fortunately, it was less than I thought :) although I put it into a transitional state (commented interfaces, added mockups, etc.). I think the next step would be to provide appropriate modules for different GeoAPI versions ... Best Henning -- Henning Bredel 52°North Initiative for Geospatial Open Source Software GmbH Martin-Luther-King-Weg 24 48155 Münster Fon: +49-(0)-251–396371-34 Fax: +49-(0)-251–396371-11 email: [email protected] 52North-site: http://www.52north.org General Managers: Dr. Albert Remke, Dr. Andreas Wytzisk Local Court Muenster HRB 10849
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
