since the commit 8e2fa9ff.

(005fc622). The position of a TokenMgrError
was not there anymore.

(https://github.com/gmantele/taplib/commit/7a70c6038cef460ab169682bed391bb5ae1de1e9)

It was not possible to use a GROUP BY with a qualified column name.
So finally, now, a GROUP BY is a ClauseADQL<ADQLColumn> instead of
a ClauseADQL<ColumnReference>. Indeed, according to the ADQL's BNF,
GROUP BY items are only columns as they would appear in the SELECT
clause (i.e. qualified or not, delimited or not). On the other
hand an ORDER BY accepts ONLY column index or non-qualified column
name/alias.

The class ColumnReference is kept for backward compatibility (or in
case the next version of the ADQL grammar make items of GROUP BY and
ORDER BY of the same type: index or qualified column). Besides, this
class is still inherited for the ORDER BY clause items
(see adql.query.ADQLOrder).

a qualified column name should be allowed, but still no column index should be.

TAP capabilities resource content.

TAP capabilities resource content.

This error has been raised on the issue #32 by Zarquan.

- empty file
- not a valid VOTable document

In such cases, the following error message is returned:
  "The input file is not a valid VOTable document!"
A cause with more detais (especially the line and column numbers)
may be appended.

Cases handled with no error:

  - If the VOTable document has no rows, an empty table
    is uploaded. No error has to be returned.

  - If a row has a different number of columns than the number
    of declared FIELDs, additional values are ignored and missing
    values are replaced by NULL. This is actually nicely handled by
    STIL.

Two comments:

- JDBCConnection.getDBMSName(String url) is now deprecated ; it may disappear
  in a next version of the ADQLLibrary.
- In case the DBMS name can not be retrieved (generally because of an
  incomplete JDBC driver implementation), NULL will be returned.

Few useless casts have also been removed.

It is also now recommended to make DBConnection.executeQuery(ADQLQuery)
return NULL if the query has been aborted (indeed, the DBConnection is
the only one that can reliably know that fact). JDBCConnection has been
adapted consequently.

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().