> Thinking about it more though, don't we have that problem anyway since we
> still want to publish relocation artifacts?
Do we need to create relocation artifacts for new modules only added after
the group id change? There won't be wrong references to these out in the
wild, so people should be fi
To clarify my last reply...
Today all of the artifacts under org.hibernate are published to JBoss Nexus
and then rsync'ed to Central. When I move to publishing the artifacts for
ORM to Central "directly" (via OSSRH), those artifacts need to be excluded
from the rsync. But today, because all (mos
It's more a convenience of defining the rsync that currently happens
between JBoss and Central.
On Wed, Oct 5, 2016, 5:48 PM Sanne Grinovero wrote:
> Are we required to change groupId for that?
> Asking mainly to get OGM there as well, as it's already using the proposed
> scheme.
>
> On Wed, 5 O
Are we required to change groupId for that?
Asking mainly to get OGM there as well, as it's already using the proposed
scheme.
On Wed, 5 Oct 2016, 23:44 Steve Ebersole, wrote:
> The grouping is certainly "nice". But given the possibility of
> difficulties renaming the groupId could have for use
The grouping is certainly "nice". But given the possibility of
difficulties renaming the groupId could have for users I'd not make this
change just because it is nice. No, this is part of a larger change I want
to do which is laid out in the JIRA Gunnar mentioned. Specifically I want
to move awa
yes, with relocation artefacts things could be made less annoying.
Just wanted to be sure we at least considered it and I hope you can get
Gradle to play nice ;)
/max
> Hi Max,
>
> the intent is to publish "relocation artifacts" like this one which we
> created when the Hibernate Search main art
I've promoted my "ORM 5.2 upgrade preview" pull request as upstream
branch "5.7",
just after having it rebased on the freshly baked tag: 5.6.0.Beta3
This implies we have now two active streams of development for
Hibernate Search (!);
we still have just one mission: finish 5.6 and its Elasticsearch
In SQM's domain metamodel we decided to follow JPA's guidelines in terms
of javax.persistence.metamodel.Metamodel. That is to say... a Type in SQM
describes a Java type not its database mapping, just as it is in JPA.
As a concrete example of the difference and its implication, consider a
Boolean
> On the other end, maybe grouping them together will make it clearer to
> end users which artifacts need to use the same version?
Right, that'd be my hope as well. It'll just more clearly emphasize which
artifacts "belong together" because they are part of the same project.
More fine-grained gro
Hi Max,
the intent is to publish "relocation artifacts" like this one which we
created when the Hibernate Search main artifact was renamed from
"org.hibernate:hibernate-search" to
"org.hibernate:hibernate-search-orm"
https://raw.githubusercontent.com/hibernate/hibernate-search/master/legacy/pom.x
10 matches
Mail list logo
