This class is using static attributes of type DecimalFormat.
Unfortunately this type of objects can NOT be accessed by multiple
threads simultaneously: it is not thread-safe. Parsing errors,
mostly during TAP uploads, have been experienced for this reason.

To solve quickly this issue, the main static public functions of
ISO8601Format have been synchronized.

apply a quick space replacement (by %20) for few URIs of the configuration file
and remove duplicated entry (encoding) from the Gradle build script.

A special test has also been added in getFile(...) in order to deliver
a clear error message for users using a former version with URIs in their
configuration file (only for file_root_path and metadata_file).

Two embedded DBMS are used: H2 and a little SQLite. JDBC drivers are provided
in the `lib` directory. The databases are created and deleted automatically
by the JUnit tests (see `test/tap/db_testtools/DBTools for more details`).

The ANT and Gradle build scripts have been updated to reflect all these test
modifications.

Two classes have been modified after compilation:
    - ADQLParser - a simple cast for one of the automatically generated
                   constructor.
    - ParseException - the token position has been stored for better
                       syntax error messages.
A note has been added at the top comment for both files to highlight
the modified parts and how to restore them after re-generation.

This issue has been raised with an H2 database.

This import can not be resolved in a standalone version of adql. It
also creates a circular dependency: ADQL then depends on TAP, which
depends on starjava, but starjava depends on ADQL.

ResultSetTableIterator (i.e. functions returning unknown numeric values
were not set with the right datatype but char* instead).

the automatic datatype detection was missing for CENTROID functions.
--
Additionally, some JUnit test files of the `adql` package has been moved to
the correct location.

Date and Time are converted into a string with the following resp.
formats: 'yyyy-MM-dd' and 'HH:mm:ss'.

The "normal" JOIN:
    A JOIN B ON A.id = B.id JOIN C ON B.id = C.id
is correctly interpreted as:
    ( (A JOIN B ON A.id = B.id) JOIN C ON B.id = C.id )
But with a NATURAL JOIN, the tree is mirrored:
    A NATURAL JOIN B NATURAL JOIN C
gives:
	( A NATURAL JOIN (B NATURAL JOIN C) )
instead of:
    ( (A NATURAL JOIN B) NATURAL JOIN C )
This is not a problem when the SQL translation is identical to the ADQL
expression, but for some DBMS a conversion into a INNER JOIN ON is necessary
and in this case we got the following SQL:
    A JOIN B JOIN C ON A.id = B.id ON B.id = C.id
Which seems to work, but is syntactically strange.

This commit should fix the generated tree. A "normal" JOIN and a NATURAL JOIN
should now have the same form. A JUnit test has been added into TestADQLParser
to check that: testJoinTree().

job as been interrupted not by a TimeOut (cf executionDuration) but by an
IOException.

47d36bfb
In the UWS and TAP configuration files the executionDuration has to be
provided into milliseconds. But the UWS parameter MUST be in seconds.
So now, UWS is still keeping this duration in seconds (in its
ExecutionDurationController) but TAP keeps it in milliseconds (in order
to avoid unexpected silent modification of the API) and converts it into
seconds for its controller (i.e. TAPExecutionDurationController), for the
default home page and for the Capabilities page.

68666ccb
It happens that the JDBC driver returned an Integer instead of a Short for a
Postgres SMALLINT column. This is not a problem for all formats because of
implicit cast, except for FITS which requires an exact correct type. This
commit ensure that columns declared as SMALLINT in the metadata are always
casted as Short.

c5cba4ba. The cast into a Short object is
absolutely required for the FITS format.

If a BOOLEAN database column is encountered, its datatype will be considered
as SMALLINT (because TAP 1.0 does not support BOOLEAN) and its values will
be converted into 0 for FALSE and 1 for TRUE. This last part was missing
in the TAP library before this commit.

This is very helpful if TAP_SCHEMA (or some of its tables and their columns)
has a different name in the database.
The mapping can be specified to JDBCConnection or directly in the configuration
file.

This is particularly annoying for numeric functions like sqrt(...)
(example query: SELECT TOP 1 sqrt(2) as s2 FROM whatever_table).
This bug has been raised by M. Taylor.

Execution duration should be expressed in seconds in this TAP endpoint,
but the TAP Library was returning its internal value which is expressed in
milliseconds.

Schema were still ordered by schema_name instead of schema_index when this
latter exists.

Commit following 6fc7f8fd.

TAPTable.copy(...) and TAPColumn.copy(...) use directly the attribute dbName
instead using getDBName() ; indeed getDBName() <> dbName.
Because of this bug, queries with aliased tables did not work anymore.

These two columns let recommend an order, respectively, for tables in their
schema, and columns in their table.
In addition of these new columns, "arraysize" has been also added.
All these new columns are already supported when creating a TAP_SCHEMA from
an XML file.

sub-query. Without this information, it was impossible to resolve columns makingreference to sub-queries of the clause FROM. See the JUnit test case for a
concrete example.
(error raised by Hendrik Heinl - ARI/GAVO)

column in TAP_SCHEMA. Such names are normalized (without any prefix and without
double quotes) when getADQLName() is called, but are returned just trimmed
by getRawName(). This latter is just used by TAPMetadata when writing the XML
description of all TAP tables.

in DBType.DBDatatype (for UNKNOWN and UNKNOWN_NUMERIC). This reset is performed
after each JUnit setting a special custom value (otherwise it prevents other
JUnit to run correctly)

clause SELECT.