Re: [hibernate-dev] [OGM] Sprint organization
On 25 February 2015 at 10:53, Davide D'Alto <daltodavide(a)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(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
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev