Hi,
So, with Gunnar, we did the work to rename the groupId and relocate the
artifacts of Validator.
It would be nice if we could be consistent on the way we do it.
So what we did:
- we created a relocation/ directory/parent artifact containing all the
relocation artifacts
- we only enable the bu
Hi,
So, as discussed at the F2F, I set up an hibernate-commons project.
Currently, it's here https://github.com/gsmet/hibernate-commons, waiting
for everyone to agree on the name, the license, the purpose and so on.
We would like to make quick progress on it as it's blocking for the
migration of
Hi,
Did the same this week-end, and adapted your work to match the bigger
picture of what we discussed on Friday.
Basically the "StructureTraverser" is now called "ValueProcessor", because
it's not responsible for exposing the internals of a structure anymore, but
only to process a structure accor
Everything you said seems to make sense to me, so +1.
We can see later whether we agree on the other common projects we could add
(checkstyle rules, test utils, ...), but I think there won't be many
arguments *against* them as long as there is no transitive dependency to
these projects for end user
# groupId
+1 for the name "hibernate-commons".
I wouldn't want to move the hibernate-commons-annotations project
though. This project is stable, not evolving much yet several branches
will need to be maintained for very long time still.
Moving repositories would make maintenance trickier for no ot
Nothing major, but still this got me wondering:
- why the parent pom "hibernate-validator-relocation" ?
- why the profile switch? do you plan to omit these artifacts for -
say - nightly builds and local testing of other projects depending on
it?
- what's the benefit you're hoping to achieve by b
One benefit we always get by being consistent is that it's easier for a
newcomer to switch from project to project... If it doesn't require more
work, we may as well be consistent.
Anyway, thanks Guillaume, I added this piece of information to the HSearch
ticket: https://hibernate.atlassian.net/br
On Mon, Jan 30, 2017 at 1:01 PM, Sanne Grinovero
wrote:
> Nothing major, but still this got me wondering:
> - why the parent pom "hibernate-validator-relocation" ?
>
To avoid having too many useless directories in the parent directory.
> - why the profile switch? do you plan to omit these ar
On Mon, Jan 30, 2017 at 12:44 PM, Sanne Grinovero
wrote:
> # groupId
> +1 for the name "hibernate-commons".
>
> I wouldn't want to move the hibernate-commons-annotations project
> though. This project is stable, not evolving much yet several branches
> will need to be maintained for very long tim
On 30 January 2017 at 12:49, Guillaume Smet wrote:
> On Mon, Jan 30, 2017 at 1:01 PM, Sanne Grinovero
> wrote:
>>
>> Nothing major, but still this got me wondering:
>> - why the parent pom "hibernate-validator-relocation" ?
>
>
> To avoid having too many useless directories in the parent directo
On Mon, Jan 30, 2017 at 2:01 PM, Sanne Grinovero
wrote:
> Different projects have different needs. Consistency is nice, and
> certainly makes it easier to find oneself comfortably "at home" when
> jumping from one project to another, but it also is inconvenient to do
> things "for consistency" wh
I didn't have time to do it.
I'll postponed the updates to next week: the 9th of February
Thanks,
Davide
On Tue, Jan 17, 2017 at 4:56 PM, Davide D'Alto wrote:
> Hi,
> there are some plugins to upgrade on Jenkins and it seems they have
> some non trivial changes.
>
> I'll do that on Thursday and
On 30 January 2017 at 13:58, Guillaume Smet
wrote:
> Note that the current version of hibernate-commons-annotations is
> org.hibernate.common (without the s at the end, not org.hibernate as Yoann
> stated it).
>
You're right. Wouldn't the simplest solution be to use the same groupId
(without a "
On Mon, Jan 30, 2017 at 3:26 PM, Yoann Rodiere wrote:
>
> On 30 January 2017 at 13:58, Guillaume Smet
> wrote:
>
>> Note that the current version of hibernate-commons-annotations is
>> org.hibernate.common (without the s at the end, not org.hibernate as Yoann
>> stated it).
>>
> You're right. Wo
Well let's investigate what this consistency means across projects first.
As Sanne mentions, if it makes it building ORM more difficult then I'd be
-1 it too. But I promise to take a peek when I get back from PTO in a few
days. Or maybe Andrea can in the next few days as he already has worked on
Disclaimer : I have not yet looked at the Asciidoc style. Again I promise
to look at it when I come back from PTO. That said I want to make certain
that the developed style matches the new ORM documentation style. The
design team at Red Hat spent a lot of time helping us develop that.
Specifica
Hi Steve,
Thus the NoORM prefix in the subject :).
I just wanted us to be consistent across the NoORM projects.
--
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Umm, we could also be consistent across all of the projects since they are
all Hibernate projects.
On Mon, Jan 30, 2017 at 10:34 AM Guillaume Smet
wrote:
> Hi Steve,
>
> Thus the NoORM prefix in the subject :).
>
> I just wanted us to be consistent across the NoORM projects.
>
> --
> Guillaume
>
Relatedly, I have been thinking whether we want to rename the ORM artifacts
as well since this is the best time if we wanted to do that.
So we know we will change the groupId to `org.hibernate.orm`.
I was thinking we might want to also either:
1. rename `hibernate-core` as `hibernate-orm`
After a hiatus of 6 months, I have gone back to my PR for
improving/replacing the Firebird dialect. I am running into a number of
test failures which I am working through to see if they are relevant or not.
One of the test failures I am looking at is
org.hibernate.jpa.test.criteria.basic.Concat
Hello,
We just released Hibernate Search 5.6.0.Final, the first stable release
featuring experimental support for Elasticsearch (2.x).
We also started the candidate release phase for Hibernate Search 5.7 by
releasing version 5.7.0.CR1, with support for ORM 5.2.7 and newer (but not
older, see the
Great! Fantastic work everyone!
On 30 January 2017 at 18:07, Yoann Rodiere wrote:
> Hello,
>
> We just released Hibernate Search 5.6.0.Final, the first stable release
> featuring experimental support for Elasticsearch (2.x).
>
> We also started the candidate release phase for Hibernate Search 5.7
I worked on the ORM relocation script probably a year ago, I'll have to go
back and refresh my memory. Tomorrow I'll give a look at it.
On 30 Jan 2017 16:44, "Steve Ebersole" wrote:
> Relatedly, I have been thinking whether we want to rename the ORM artifacts
> as well since this is the best tim
Not have a strong opinion on the renaming.
On 30 Jan 2017 19:05, "andrea boriero" wrote:
I worked on the ORM relocation script probably a year ago, I'll have to go
back and refresh my memory. Tomorrow I'll give a look at it.
On 30 Jan 2017 16:44, "Steve Ebersole" wrote:
> Relatedly, I have be
On Mon, Jan 30, 2017 at 5:37 PM, Steve Ebersole wrote:
> Umm, we could also be consistent across all of the projects since they are
> all Hibernate projects.
>
Sure. But as the build system is different, there might be different
requirements/prerequisites.
So, for the NoORM projects, I'd like u
On Mon, Jan 30, 2017 at 5:36 PM, Steve Ebersole wrote:
> Disclaimer : I have not yet looked at the Asciidoc style. Again I promise
> to look at it when I come back from PTO. That said I want to make certain
> that the developed style matches the new ORM documentation style. The
> design team
Sounds good to me. +1
Am 30.01.2017 um 17:31 schrieb Steve Ebersole:
> Relatedly, I have been thinking whether we want to rename the ORM artifacts
> as well since this is the best time if we wanted to do that.
>
> So we know we will change the groupId to `org.hibernate.orm`.
>
> I was thinking we
27 matches
Mail list logo
