Re: SIS-350

[Sisinda Dinusha <si...@gmail.com>]

Hello Martin,

> "error: type argument Length is not within bounds of type-variable Q
> where Q is a type-variable:
> Q extends Quantity<Q> declared in interface Quantity"
This was a compiler error when compiling sis-utility test files.
I was able to find the reason and it was conflict of classes provided
by javax.measure:unit-api and javax.measure:jsr-275 (which was included
by gradle as a dependency for org.opengis:geoapi). So I repackaged
javax.measure classes and references from jsr-275 and geoapi modules
into different namespace (using JarJar tool). This solved that problem and 680
tests passed. Others are 14 runtime errors, 15 failed tests and 17
ignored tests.

-- 
Sisinda

Re: SIS-350

[Martin Desruisseaux <ma...@geomatys.com>]

Hello Sisinda

Le 08/07/2017 à 12:11, Sisinda Dinusha a écrit :

> Garbage collector dependent tests failed almost always.
>
Such tests are highly sensitive to assumption on the running environment
anyway. I presume that those assumptions are wrong on the Android case.
I suggest that you delete those tests (we will rely on those tests being
executed in the Java standard environment). There is not many such tests
I think.


> I placed SQLite configurations in a seperate class
> (SQLiteConfiguration). Since we only target for SQLite, removed codes
> regarding getting database metadata from JDBC and made them to use
> SQLiteConfiguration class. I did this because, as of my knowledge,
> there is no way to get metadata programmatically without using JDBC.
>
Understood.


> Can we install the metadata tables (Create.sql) when installing EPSG
> dataset, and to the same database? Since we cannot create schemas in
> SQLite (correct me if wrong), do we have to create another database
> for metadata?
>
I think we can keep a single database for all. The original tables
published by EPSG all have a "epsg_" prefix in their name, which
simulate schema. Apache SIS replace the "epsg_" prefix by "epsg." schema
name on the fly during installation, but we can disable this replacement
(more on it below). All metadata tables also have some prefix like "CI_"
or "MD_", and the OGC/ISO specifications are designed in such a way that
those prefixes do not clash.

For making sure that the "epsg_" prefix in table names is preserved, we
just just need to make sure that ScriptRunner.isSchemaSupported is set
to false.

    Martin

Re: SIS-350

[Sisinda Dinusha <si...@gmail.com>]

Hello Martin,

> I suspect that some Gradle dependencies have been mixed. Maybe it
> imports GeoAPI 3.0.0 instead of GeoAPI 3.0.1
You are right this was the case for most of the issues.
Garbage collector dependent tests failed almost always. Besides that
there are 11
failed tests now.

I placed SQLite configurations in a seperate class (SQLiteConfiguration).
Since we only target for SQLite, removed codes regarding getting database
metadata from JDBC and made them to use SQLiteConfiguration
class. I did this because, as of my knowledge, there is no way to get
metadata programmatically without using JDBC.

Can we install the metadata tables (Create.sql) when installing EPSG
dataset, and to the same database? Since we cannot create schemas in
SQLite (correct me if wrong), do we have to create another database
for metadata?

-- 
Sisinda

Re: SIS-350

[Martin Desruisseaux <ma...@geomatys.com>]

Hello Sisinda

Le 01/07/2017 à 14:48, Sisinda Dinusha a écrit :

> I was able to find the reason and it was conflict of classes provided
> by javax.measure:unit-api and javax.measure:jsr-275 (which was
> included by gradle as a dependency for org.opengis:geoapi). So I
> repackaged javax.measure classes and references from jsr-275 and
> geoapi modules into different namespace (using JarJar tool).

It should not be necessary to repackage. JSR-275 was used by GeoAPI
3.0.0, but is now replaced by JSR-363. The old JSR-275 should be
considered as retired (more than deprecated). GeoAPI 3.0.1 is being
released especially for replacing JSR-275 by JSR-363.

I suspect that some Gradle dependencies have been mixed. Maybe it
imports GeoAPI 3.0.0 instead of GeoAPI 3.0.1 (actually 3.0.1-RC1 until
OGC deploys the final 3.0.1 release on Maven Central). We need to ensure
that JSR-275 does not appear anywhere, directly or indirectly.

    Martin