[hibernate-dev] [OGM] Sprint organization

[Gunnar Morling]

2015-02-25 11:30 GMT+01:00 Hardy Ferentschik <hardy at 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-structured).
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
>