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 20:57:04 GMT
On 12/20/05, Martin van den Bemt <mllist@mvdb.net> wrote:
> 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..

Really ? We cannot bootstrap a Maven2 plugin without Maven2 ? That's strange ...
If that's true, then we should definitely have a sub project for that.

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

That's the general idea: adapt the corresponding jdbc.properties file
for your system and then run the tests.
For the databases that may be accessed with different databases, we
should define the variants in the jdbc.properties file so that the
user can simply comment/uncomment the corresponding section, adapt the
settings and then run the tests.

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

Not sure if that is useful on the website ? After all, it simply says
everything is ok, or points out the problems, so it is basically a
useful tool for us developers. Same for PMD which I plan to integrate
once the 1.0 is out.

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

Sounds good. I'll ask Robert once we're nearing a release.

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

Might be, you could have a look into the corresponding SVN.

> > * Test against the new small Oracle database
> Have Oracle Express running in my vm btw..

Cool, you could run the tests against it once they are finished.

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

The target is still 1.3/JDBC 2 (with special care for BOOLEAN/DATALINK
which are only available in JDBC3), and I think that is ok because
there haven't been too much differences API-wise between 1.3 and 1.4
AFAIK. On my test installations I have the latest 1.3 installed, so I
can actually test against it.


View raw message