Running a test for any of the datastore (except HashMap) is a pain.
Hardy's approach does not solve the one test problem as it runs all of the TCK,
which can be done with mvn install.
The workarounds are:
- copy the tests
- use your IDE to set the different module classpath but that also means
2015-02-25 16:47 GMT+01:00 Hardy Ferentschik :
> > > 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
On Wed, Feb 25, 2015 at 12:46:13PM +0100, Gunnar Morling wrote:
> To give some background, there is a dialect in core itself, HashmapDialect,
> which is used when running the TCK in core.
Something I did not know. I was about to ask how you can run these tests in
core anyways. I was wondering whet
> > 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.
Hmm, not sure.
> > Also, havi
> 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 its
2015-02-25 11:30 GMT+01:00 Hardy Ferentschik :
> > > 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
On 25 February 2015 at 10:53, Davide D'Alto 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
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.
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.
> > 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
Hey,
2015-02-24 16:49 GMT+01:00 Hardy Ferentschik :
> > * There are two types of tests in core: a) unit tests for stuff in core
> > itself and b) the "backendtck" which are high-level (i.e.
> Session/EM-level)
> > tests and which are executed for all backends.
>
> Wouldn't it make sense to have t
> * There are two types of tests in core: a) unit tests for stuff in core
> itself and b) the "backendtck" which are high-level (i.e. Session/EM-level)
> tests and which are executed for all backends.
Wouldn't it make sense to have these backendtck tests defined in a dedicated
module? When you me
> Before that though, I need to finish the Validator blog? What is the
status on in.relation.to? Can one create blog entries again?
in.relation.to it stills not working and I'm not sure how to solve the
issue.
The content in the db seems correct and I think the problem is related to
some operatio
On Mon 2015-02-23 9:15, Gunnar Morling wrote:
> Hi,
>
> Thanks for grooming the backlog and preparing these releases!
>
> I'm curious how the weekly release scheme is going to work out. In the last
> two sprints we created none (although I thought we wanted to release HS?)
> and one (HV, as plan
Hi,
On Mon, Feb 23, 2015 at 09:15:26AM +0100, Gunnar Morling wrote:
> I'm curious how the weekly release scheme is going to work out. In the last
> two sprints we created none (although I thought we wanted to release HS?)
> and one (HV, as planned) release. Planning for four releases now may be
>
Nice, thanks. I have updated the contribute page with that content.
http://hibernate.org/ogm/contribute/
On Mon 2015-02-23 9:40, Gunnar Morling wrote:
> Hey,
>
> Some pointers for those who haven't worked on the OGM code base in a while:
>
> * Contribution guide: http://hibernate.org/ogm/contri
Hey,
Some pointers for those who haven't worked on the OGM code base in a while:
* Contribution guide: http://hibernate.org/ogm/contribute/
* Build instructions: in the readme.md in the root dir;
* You need to install CouchDB separately and configure the COUCHDB_HOSTNAME
env variable if you want
Hi,
Thanks for grooming the backlog and preparing these releases!
I'm curious how the weekly release scheme is going to work out. In the last
two sprints we created none (although I thought we wanted to release HS?)
and one (HV, as planned) release. Planning for four releases now may be
over-stre
I have walked through all of the issues and sorted what I think should
be done.
## Plan of action
Within these 3 weeks, we will do:
* 4.1.2 (bug fixes) -> code freeze Friday 27th
* 4.2 Alpha1 -> code freeze Friday 27th
* 4.2 Alpha2 or Beta we will see -> code freeze Friday 6th
* 4.2 Beta or CR w
18 matches
Mail list logo
