Re: [hibernate-dev] [OGM] Sprint organization
2015-02-25 11:30 GMT+01:00 Hardy Ferentschik <hardy(a)hibernate.org>:
> > 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.
Ok, so it seems to be a documentation issue mainly? Note that Emmanuel put
my previous note on the different kinds of tests to the contributor guide (
http://hibernate.org/ogm/contribute/#any-detail-on-how-the-project-is-str...).
I would expect contributors to find their ways from there.
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.
Hm, but test JARs have been an exception to that "rule" in Maven for a long
time. So no-one should really be surprised by using that concept.
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.
Would it help if we add a note to the main readme.md, or maybe
package-info.java in the TCK package? Personally I prefer to have all
build-related info in one readme rather than scattered over several places.
It's not that I'm not against that move per se, I only have doubts whether
there is much benefit to it.
My main concern still is whether that move would complicate running tests
in core itself? Today I can click and run the TCK tests in core in the IDE
without any further preparation. If that'd get more difficult, I'd vote
against that split.
--Hardy