db-ddlutils-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Dudziak <tom...@gmail.com>
Subject Re: Todo/issues. to handle before release..
Date Tue, 20 Dec 2005 19:37:48 GMT
On 12/20/05, Martin van den Bemt <mllist@mvdb.net> wrote:

> I have some questions / observations.
> 1) Should a maven2 plugin live in the ddlutils source tree ? I think it can btw, preferrably
in a seperate source tree, to make sure we don't add too much dependencies to the main codebase..

What are the dependencies for compilation ? If only something like
maven.jar, then I think, we will do fine with a src/maven-plugin
subdirectory and separate Ant compile/build targets.
If not, then it might perhaps be more useful to have a separate
subproject for it.

> 2) We still need to setup a wiki space. Probably a request to / from the db pmc will

An issue against the Infra JIRA might also work ?

> 3) The integration tests. There are a couple of db's that can simply run always/as much
as possible (like Derby, Axion and Hsqldb). The databases that need more than just a jar dependency,
we probably should move to another src or just run as we do the current database tests.

I don't intend to include any database jars with DdlUtils. Right now I
target Derby simply because it is easy to work with in embedded mode,
and so I can create the roundtrip tests in a simple manner. My goal
however is to extend them to every database, though I'll start with
the embedded ones (hsqldb, axion, mckoi) and then the simple ones
(postgresql, mysql).
Right now the setup is specified via a jdbc.properties file for the
database, and that is that. I'll add some guards to the tests so that
we can easily specify for which databases a given test should be
executed and for which not. I think that should suffice ?

> 4) Will check if there are any javadoc errors and fix them as much as possible.

There is a checkstyle target that already does that. I always check
the docs before re-publishing the website. But it would be good if you
could perhaps proof-read them ?

> 5) Before a release we probably should try to get the betwixt team to make a release,
to make adoption a bit easier (people like it if everything is in a released state).

It is unlikely that Robert will create a 1.0 release anytime soon. For
one, he's planning to add some new features (though I don't know of
any timeframe), and there are a couple of Java 5 annotations that I've
started that might be added before 1.0.
So I think, I should ask Robert for an official 0.8 release and then
we should stick to that for the time being.

> 6) Add some faq entries (reminder for myself : how to use executeBatch in a transaction
and how to override the current schema, alhtough latter is better suited on a wiki than in
official docs)

Entries from the Wiki can always be promoted to the docs anyway, so
perhaps we should start the FAQ in the Wiki, not the docs.

> 7) I will have a look at the test coverage to see where there is a big hole..

In case you don't know, we have a Clover license for Apache. But I
haven't really used it so far, so the question is: can it combine the
results of multiple test runs (one for each database) ?

> 8) Other document improvements (disclaimer : I am not really comfortable yet with forrest,
so kick me if I do something bad..)

Think we mainly need the description (with samples) for the schema files.

> 9) Are there any specific databases you are currently targetting (besides Derby) for
the roundtrip tests ? (hope you can do Oracle, since I don't have 8 or 9 running here)

As I said above, I target at having tests for every database that I
can run tests against, which should cover at least one version of
every database that DdlUtils supports. This should be finished before
releasing the 1.0 (in fact I think this is the only thing really

> 10) Any other things you are working on, that I can get in the way with ?

I have a couple of things on my todo list, though mostly for after 1.0:

* Support for SQLite, Ingres, Caché, H2
* Test against the new small Oracle database
* Support for ASCII vs. Unicode (esp. Oracle), also related to JDBC4
* Spring support (usage of JdbcTemplate for accessing the database)
* Ant task mapping overrides, e.g. that you can change the mapping
native type <-> JDBC type

and some smaller enhancements.


View raw message