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