[hibernate-dev] [OGM] Sprint organization

[Gunnar Morling]

> 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.

To give some background, there is a dialect in core itself, HashmapDialect,
which is used when running the TCK in core. It makes sure changes or new
features can be tested in core alone as far as possible. It would be good
to keep the usability of this as nice as it is today.




2015-02-25 12:12 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:

> 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
>>
>
>