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 21:27:37 GMT


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

It is probably possible, but it is more work to do that so maven users can use the plugin
easily than to write the plugin itself...

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

At least for myself, I don't like commenting out stuff so I make it automatic when I really
hit the issue (for the embedded ones I didn't have any problems yet)

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

Cool..

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

Hope we can reuse the oracle9 driver.. If that is not working, I rather see a test setup of
oracle 9, to see if the problem is there too, so we don't break the integration for oracle9
(this is kind of a problem when not having all other environments to comapre it with).

One last issue comes to mind : It's going to be hard to cut a release with just you having
a binding vote and even when my vote would be legally binding (by being on the PMC), we are
still 1 binding vote short...
Don't actually know if my vote is binding, just because I am a Jakart PMC member / Gump PMC
member ?
I'll hassle Cliff on legal with this :)

Mvgr,
Martin

Mime
View raw message