Re: [hibernate-dev] NoORM - New groupId and relocation artifacts

2017-01-30 Thread Guillaume Smet
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

Re: [hibernate-dev] NoORM - New groupId and relocation artifacts

2017-01-30 Thread Steve Ebersole
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 >

Re: [hibernate-dev] NoORM - New groupId and relocation artifacts

2017-01-30 Thread Guillaume Smet
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

Re: [hibernate-dev] NoORM - New groupId and relocation artifacts

2017-01-30 Thread Steve Ebersole
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

Re: [hibernate-dev] NoORM - New groupId and relocation artifacts

2017-01-30 Thread Guillaume Smet
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

Re: [hibernate-dev] NoORM - New groupId and relocation artifacts

2017-01-30 Thread Sanne Grinovero
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

Re: [hibernate-dev] NoORM - New groupId and relocation artifacts

2017-01-30 Thread Guillaume Smet
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

Re: [hibernate-dev] NoORM - New groupId and relocation artifacts

2017-01-30 Thread Yoann Rodiere
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

Re: [hibernate-dev] NoORM - New groupId and relocation artifacts

2017-01-30 Thread Sanne Grinovero
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

[hibernate-dev] NoORM - New groupId and relocation artifacts

2017-01-30 Thread Guillaume Smet
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