On 25 February 2015 at 10:53, Davide D'Alto <daltodav...@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 <ha...@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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
