You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.com> on 2017/04/09 16:55:18 UTC

Should we provide a standalone JSR-363 implementation?

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

Re: Should we provide a standalone JSR-363 implementation?

Posted by Martin Desruisseaux <ma...@geomatys.com>.

Thanks Chris. I created a JSR-37-363 "branch".

    https://svn.apache.org/repos/asf/sis/branches/JSR-363/

I put it in the "branches" directory for now. It may be more appropriate
to put it in a "profiles" directory instead, but I'm not sure it is
worth to create such directory only for JSR-363.

This initial commit does not yet contain the copy of SIS classes; it
uses a temporary dependency to sis-utility in the meantime. The
interesting part is the execution of JSR-363 TCK tests.

    Martin


Le 09/04/2017 � 18:57, Chris Mattmann a �crit :
> Sounds good to me, +1 Martin. Makes sense.
>
> Cheers,
> Chris

Re: Should we provide a standalone JSR-363 implementation?

Posted by Chris Mattmann <ma...@apache.org>.

Sounds good to me, +1 Martin. Makes sense.

Cheers,
Chris




On 4/9/17, 9:55 AM, "Martin Desruisseaux" <ma...@geomatys.com> 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