Here's a thinker for the PMC: The GeoAPI uses Collections interfaces to implement aggregations in the UML from 19107. The way in which it uses them forces implementations to provide the actual data structure to clients because this is the only way to add component pieces (e.g. add points to a polygon, etc.) Providing such access to external objects leads directly to a synchronization issue.
The implementation we inherited from Sys technologies has a beginning of a solution to this problem. But it is basically a List implementation. I need Collection and Set as well, and I'd like them to be decorators instead of a full up implementation. Apache has some dead code (in the commons-dormant "events" project) which does this: ObservableSet|List|Collection. To top it off, these are decorators. I'd really like to use it. The downside is that there are no releases (and hence no maven targets) for dormant code. You can only get it from their subversion server. Lacking any better ideas, I exported it from their subversion server and plunked it into the geometry branch. So, PMC, how should we handle this? I think our options are: 1] Steal the code outright (refactor into GT namespace). 2] Keep a GT module which generates code in the org.apache.... namespace; in the "commons-events" top level maven repository. 3] Fix it up and try to sweet talk Apache into integrating it back into commons-collections. 4] Re-invent the wheel in GT namespace (dump this apache code). This code doesn't really belong in a geospatial library (unless, of course, it's not available as a dependency). Bryce _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
