On 12/20/05, Martin van den Bemt <[EMAIL PROTECTED]> wrote: > > > Thomas Dudziak wrote: > > On 12/20/05, Martin van den Bemt <[EMAIL PROTECTED]> 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.. :) Cool! > 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. Tom
