[hibernate-dev] [OGM] Sprint organization

[Sanne Grinovero]

On 25 February 2015 at 10:53, Davide D'Alto <daltodavide at gmail.com> wrote:
> 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.

I'm not a fan of the current state either, but there are many possible
improvements which don't need a separate module nor need to keep
copying classes around.

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

I like that a change in core is validated by tests in core, at least
so far as it doesn't concern specific integrations. That's a common
best practice for any codebase, and the least surprising layout of the
source code. I think "core" is fine, it's the integrating modules
which are evil.

We can talk about moving core tests to a different module, but I don't
see how that's going to improve things. After all, it's still a
different artifact.

For example, surefire now has some new options which it didn't have 3
years ago, and some of these now allow to "adjust" how the JUnit test
runners discover the tests. I'll play with that, although it only
skips the copy step: it won't improve on debugging needs.
For debugging, it would work fine OOB a long time back, but then you
guys added some conflicting resources across modules which break the
original idea ;-) I'll see if I can revert that without collaterals.

Sanne

>
>
> On Wed, Feb 25, 2015 at 10:30 AM, Hardy Ferentschik <hardy at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev