db-ddlutils-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin van den Bemt <mll...@mvdb.net>
Subject Re: Todo/issues. to handle before release..
Date Tue, 20 Dec 2005 20:37:47 GMT

Thomas Dudziak wrote:
> 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.

Hmm the maven2 plugin will need to be build using maven2 anyway.. So a seperate source strucuture
seems safer in this respect. We'll have to look if we can integrate the generated site for
the plugin in the generated forrest site in some kind of way.. 

>>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 ?

I though the wiki could be created by the pmc chair (at least as far as it is a subwiki of
I'll do the request on infra.

>>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
> 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 ?

Probably the jdbc.properties needs some change to be usable on eg my system (the embedded
ones don't have that problem though). But different test profiles can at least solve my problem
with at least external databases. Some tests with different jdbc drivers to see if we hit
any problems should also be managed by that test profile (eg the MS jdbc driver for sqlserver
2005 could behave differently as the jtds driver).

>>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 ?

Will do.. Didn't know there was a checkstyle target (was kind of expecting that forrest was
doing that for me). Any pointers if we can integrate that with forrest in some way ? I like
(automatic) reports :)

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

Just was talking about a release, which 0.8 for me is in the Betwixt scenario :) At least
we should not depend on a manual trunk build when we release.

>>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) ?

It has a testcoverage database, that it maintains, so it should be able to generate docs for
different scenarios.
Normally I just zap the coverage database though. I'll see if I can find a license in svn
(probably in committers somewhere ? )

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

Samples indeed :)

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

Have Oracle Express running in my vm btw..

> * 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.

I'll try to do some plugging (marketing) for ddlutils by wrting an article for a dutch magazine
and trying to get eg jackrabbit and activemq to use ddlutils instead of the horrible ddl files
they have in svn.. :)

Btw are we targetting jdk 1.4 or should it still run on 1.3 ?
I am happy with 1.4, since I stopped using 1.3 in real life about 6 months ago, but afaik
still a lot of application servers in the wild depend on 1.3.


View raw message