Agreed, it'd be the right time if we wanted to change this.
I vote for 1 in case we do it.
In ORM it's enough for many use cases to just add that core module,
hence I like the more concise "hibernate-orm" id (similar to
"hibernate-validator"). It's a bit different for OGM and HSEARCH where
one ne
after thinking a bit on +1 for Steve proposal
On 31 January 2017 at 08:09, Gunnar Morling wrote:
> Agreed, it'd be the right time if we wanted to change this.
>
> I vote for 1 in case we do it.
>
> In ORM it's enough for many use cases to just add that core module,
> hence I like the more concis
Hi,
Some thoughts:
== Group Id ==
Should be something like "org.hibernate.common" as per our discussions
from last week.
== Repo organization ==
I would prefer to have the AsciiDoc style, shared testing utilities
and other utilities in separate repos, not a shared one. To me, a repo
represents
Hi,
If there is just one test case that doesn't work for a specific Dialect
because the Dialect does not support such feature,
you can just skip it for that Dialect either directly or through a
DialectChecks.
One example: when a test uses sequences, you need to use a DialectCheck
because otherwis
On Tue, Jan 31, 2017 at 11:34 AM, Gunnar Morling
wrote:
> == Repo organization ==
>
> I would prefer to have the AsciiDoc style, shared testing utilities
> and other utilities in separate repos, not a shared one. To me, a repo
> represents a coherent unit of "things" with its own lifecycle. Updat
On 31-1-2017 11:49, Vlad Mihalcea wrote:
> Hi,
>
> If there is just one test case that doesn't work for a specific Dialect
> because the Dialect does not support such feature,
> you can just skip it for that Dialect either directly or through a
> DialectChecks.
>
> One example: when a test uses seq
The rename was applied now.
"master" is now referring to the branch which was previously called "5.7".
The maintenance branch for 5.6.x is now named "5.6".
I will not delete the branch "5.7" branch, for convenience of the open
pull requests and any work in progress you might have. Let's make sur
rebased my old PR and it stops working, the "publishing is not yet able to
resolve a dependency on a project with multiple different publications"
exception is back :(
I'm investigating to understand what change reintroduced this issue.
On 31 January 2017 at 09:57, andrea boriero wrote:
> after
