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