db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <fisc...@seitenbau.net>
Subject Re: svn commit: r278825 - in /db/torque/test: ./ trunk/ trunk/maven-test-plugin/
Date Tue, 06 Sep 2005 08:36:10 GMT





"Henning P. Schmiedehausen" <hps@intermeta.de> schrieb am 06.09.2005
09:45:50:

> tfischer@apache.org writes:
>
> >    db/torque/test/trunk/maven-test-plugin/   (with props)


I Will call it torque-test-maven-plugin, i

>
> -1 on "maven-test-plugin". We are not testing maven. We are testing
Torque.
>
> >+  <goal name="torque:run-test">

ok, namespace will be torque-test

>
> -1 on the name space overlap between your plugin and the
> torque-plugin. This will not only create confusion, knowing a bit
> about the mes^Wstate of maven, I'm pretty sure that sooner or later a
> name space separation will be enforced and then either one or the
> other plugin breaks.
>
> >+    <attainGoal name="torque:test:test"/>

Using the new namespace, this will also be avoided.

>
> -1 on xxx:yyy:zzz. Same as above. Sooner or later, maven will enforce
> the plugin:goal rule and then double ':' will probably break.
>
> >+</project>
> >\ No newline at end of file
>
> Bad.

Will look for those, and the licences also. I did not finish yesterday.

>
> Personally, I'm -0 on the whole plugin idea. For just running the
> runtime test, I will afterwards have to drag around a plugin not used
> for anything else in my maven installation. Not really ideal.

If this is the only thing which bothers you, I will do a
plugin:uninstall-now
at the end of torque-test:build-run. So the plugin will be installed and
deinstalled during the test, no garbage remains.

I tried several things and this was the best I could come up with till now.
The problem with the old runtimetest were the following:
- one had to build the generator and the templates separately if one
changed something there. Really annoying if you run the test 10 times.
- it was testing the ant version of the generator and not the maven-plugin.
- it had problems with the junit task definition.
- it was not a runtimetest, but instead it was testing the whole of torque,
and therefore should not be in the runtime part of the project.

The new test has none of these problems, and the new problem with the
installed plugin can be solved. So in my own personal private opinion, it
is much better than the old test. Full stop.

However, it is also not the ideal solution from my point of view. What I
would have liked best would be a test project which could be run like any
other torque project. The problems were the following:
- The main problem is that I did not find a possibility to read a profile
file during (not before!!!) maven execution and passing the parameters to
the torque maven plugin. Maybe I did not look hard enough, will look again
this evening if one can do tricks with maven:set.
- in the runtimetest, one can switch the idmethod from the profile. This
was done using ant filters while copying the file. To retain this feature,
one has to copy the schema files. If one does not want to retain this
feature, one could use some tables with the idbroker and some normal ones.
Then one could leave out the copying stuff and the project would look more
like a normal Torque project. A strong point for retaining the idmethod
switching feature is that some database adapters (firebird, at least) do
not support the idmethod="native", so the part of the test using idmethod
native would not run at all. Maybe one wants to have two runs in every
test, one with idmethod=native and one with idmethod=idbroker, but no idea
how to do this in an elegant way.

        Thomas



---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org


Mime
View raw message