You are viewing a plain text version of this content. The canonical link for it is here.
Posted to torque-dev@db.apache.org by "Henning P. Schmiedehausen" <hp...@intermeta.de> on 2005/09/06 09:45:50 UTC
Re: svn commit: r278825 - in /db/torque/test: ./ trunk/ trunk/maven-test-plugin/
tfischer@apache.org writes:
> db/torque/test/trunk/maven-test-plugin/ (with props)
-1 on "maven-test-plugin". We are not testing maven. We are testing Torque.
>+ <goal name="torque:run-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"/>
-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.
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.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: svn commit: r278825 - in /db/torque/test: ./ trunk/ trunk/maven-test-plugin/
Posted by Thomas Fischer <fi...@seitenbau.net>.
"Henning P. Schmiedehausen" <hp...@intermeta.de> schrieb am 06.09.2005
10:59:52:
>
> It's ok. If you see real benefits and it does not put a burden on a
> maven installation, go ahead. As I said, I'm not really a fan of the
> solution (-0) but I don't object it.
>
> Getting some docs on how to use this would be good, though.
>
As I said, I was not finished with it. Today evening, a miracle will occur
and documenation will appear in svn. I was too tired for miracles yesterday
evening :-).
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: svn commit: r278825 - in /db/torque/test: ./ trunk/ trunk/maven-test-plugin/
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Thomas Fischer <fi...@seitenbau.net> writes:
>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.
It's ok. If you see real benefits and it does not put a burden on a
maven installation, go ahead. As I said, I'm not really a fan of the
solution (-0) but I don't object it.
Getting some docs on how to use this would be good, though.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: svn commit: r278825 - in /db/torque/test: ./ trunk/ trunk/maven-test-plugin/
Posted by Thomas Fischer <fi...@seitenbau.net>.
"Henning P. Schmiedehausen" <hp...@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