I like the idea of a separate module for shared tests, It makes sense for
our usecase.
I've never been a big fun of the OGM black magic.
Are there any reasons not to do it except that it will add a new module?
I'm not really concerned about having modules in the project if their
purpose is clear.
On Wed, Feb 25, 2015 at 10:30 AM, Hardy Ferentschik <hardy(a)hibernate.org>
wrote:
> > Wouldn't it make sense to have these backendtck tests
defined in a
> > dedicated
> > module? When you mentioned it, I was literally searching for the tests
you
> > were
> > referring to.
> >
>
> Sorry, I guess I should have given you the package name.
>
> I kind of like the fact that one can execute the tests in core right
away,
> i.e. without any copying, or custom runner etc. Would there be any strong
> advantage to having them in a separate module? If not I'd prefer to keep
> the number of modules low.
More transparency. If the module existed I could already just by name infer
what it is about. This might also be helpful for potential dialect
contributors
who look for high level tests.
It is also in the spirit of one module one artifact. Unless I actually
check the
POM and find the second execution of the jar plugin, I don't know that two
artifacts
are generated.
A dedicated module means less surprises and less understanding needed to
see how
things get together.
Also, having a dedicated module allows for adding an additional README
which for
example described the purpose of these tests, how they are executed and
that they
are used by each dialect.
--Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev