Sounds good to me, +1 Martin. Makes sense. Cheers, Chris
On 4/9/17, 9:55 AM, "Martin Desruisseaux" <[email protected]> wrote: Hello all As a side effect of Apache SIS 0.8 development, we provided a JSR-363 (Unit of Measurement API) implementation in the sis-utility module. That module is about 900 kb large, and I suspect that some peoples may be interested in the JSR-363 implementation alone without all the remaining stuff in sis-utility module and without GeoAPI dependency. I'm thinking about providing that in a separated Maven artifact, which could be named sis-uom. That artifact would have the following properties: * Would be separated from the main Apache SIS project, with its own version number. * Would contain a copy of the minimal amount of Apache SIS classes needed to implement JSR-363. * Some geospatial-specific stuff like EPSG codes would be omitted. * The main Apache SIS project would NOT depends on that sis-uom module, because the version in the main SIS project would have some extra more like EPSG codes. I'm tempted to keep the same package name (org.apache.sis.measure) for the classes in the sis-uom module, with a promise to keep sis-utility 100% binary compatible with sis-utility module. In other words, sis-uom would not be an independent module, but a profile of sis-utility. This is the same idea than "compact1", "compact2", etc. profiles of the standard JDK. If a project got both the sis-utility module and the sis-uom profile on the classpath (e.g. through transitive dependencies), then the sis-uom profile would be simply excluded since sis-utility module would contain all the sis-uom public API and more. The intend is to simplify interoperability between Apache SIS and non-geospatial project that would use sis-uom (if any) since we would still have only one unit framework. Any though? Martin
