> Sounds like you are making great progress Mathieu, good stuff. Some comments > inline.
And, as discussed in Barcelona, I still keep in mind as a long-term goal to be able to have an OSGi-based GeoServer. This would make it easier to flexibly combine various technologies (e.g. Spring Security), would allow to dynamically load fixes on a running server, to have various versions of a given implementation coexist in the same runtime (e.g. stable / beta), etc. >> Question: would we consider impacting the code in order to reduce (or >> completely remove) that kind of packages declared in many modules? > > I think long term it would be ok to try to enforce the policy that we make > packages unique to modules/bundles. But in any attempt to do so we will have > to worry about maintaining backwards compatibility... and any packages that > we want to move we will have to first go through the normal deprecation > cycle. So a possible way forward would be: > 1. identify all the packages/modules now that are in violation > 2. figure out how to move/reorganize all the package structures, and do > all the necessary deprecations on the current 8.x branch > 3. once 9.x realizes that will be the first osgi compatible branch In many cases, maintaining backward compatibility with non-OSGi runtimes (that is based on a linear classpath) will not be that difficult. So we could follow the approach you suggest but still have an OSGi-compatible branch earlier. In many cases, we can simply keep the old classes where they are, deriving from the new ones, and OSGi would only expose the new ones. But a classic linear classpath would still find the old ones. In the case of gt-epsg-hsql there is also the issue of the visibility of some classes/methods/fields from gt-referencing. I don't know how critical it is to keep that kind of visibility restrictions. More generally, there are two nice things with OSGi, which IMHO justify the effort. First is the dynamic features (as I described above when dreaming of an OSGi GeoServer), second is how it underlines the dependency structure of your component/module-based application or framework. After the initial pain of ensuring that an existing framework would fit, it enforces by construction that you have well defined dependencies and APIs between the modules. It makes some structural problems appear much earlier (e.g. cyclical dependency between modules, etc.) when it is easier to deal with them. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
