Re: [hibernate-dev] 5.3.0.Beta1 delay

[Sanne Grinovero]

As far as I know they just require some useful information: license,
developers, description and a url.

Isn't it easier to just add these?

In case of the relocations we have in Hibernate Search, I just declare
a description and then declare the parent pom so that most other
things are inherited.


On 18 January 2018 at 04:39, Steve Ebersole  wrote:
> God bless JBoss Nexus...
>
> JBoss Nexus is doing some over-zealous validations of a relocation POM.
> Even so far as I have found, Maven/Sonatype only expect a very minimal POM
> for relocation artifacts, yet JBoss Nexus' validations are checking that
> all normal POM values are defined.  I'll have to figure this one out.  In
> the meantime, anyone know the proper place to ask about this?  JBoss Jira?
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] staging.hibernate.org CI failure

[Steve Ebersole]

I am trying to finish up the announce and website changes for 5.3.0.Beta1.

staging.in.relation.to changes built fine.

However I am getting incomprehensible (to me) failures on the CI server
trying to build the staging website.  Help?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] staging.hibernate.org CI failure

[Guillaume Smet]

Hi Steve,

I have to go very soon so I can't test myself right now but that might be
because you're missing this file in the 5.3 directory:
https://github.com/hibernate/hibernate.org/blob/d22b1461ee5ae7aac56cff90e4869b57599bb321/_data/projects/orm/releases/5.2/series.yml

You need one to describe the series.

-- 
Guillaume

On Thu, Jan 18, 2018 at 7:22 PM, Steve Ebersole  wrote:

> I am trying to finish up the announce and website changes for 5.3.0.Beta1.
>
> staging.in.relation.to changes built fine.
>
> However I am getting incomprehensible (to me) failures on the CI server
> trying to build the staging website.  Help?
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] staging.hibernate.org CI failure

[Guillaume Smet]

See the thread "ORM release process" I started in late September.

HTH.

On Thu, Jan 18, 2018 at 7:40 PM, Steve Ebersole  wrote:

> Yes, I had seen that.
>
> We definitely need a bunch of notes in the release process about all these
> new steps
>
> On Thu, Jan 18, 2018 at 12:38 PM Guillaume Smet 
> wrote:
>
>> Hi Steve,
>>
>> I have to go very soon so I can't test myself right now but that might be
>> because you're missing this file in the 5.3 directory:
>> https://github.com/hibernate/hibernate.org/blob/
>> d22b1461ee5ae7aac56cff90e4869b57599bb321/_data/projects/orm/
>> releases/5.2/series.yml
>>
>> You need one to describe the series.
>>
>> --
>> Guillaume
>>
>> On Thu, Jan 18, 2018 at 7:22 PM, Steve Ebersole 
>> wrote:
>>
>>> I am trying to finish up the announce and website changes for
>>> 5.3.0.Beta1.
>>>
>>> staging.in.relation.to changes built fine.
>>>
>>> However I am getting incomprehensible (to me) failures on the CI server
>>> trying to build the staging website.  Help?
>>>
>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] staging.hibernate.org CI failure

[Steve Ebersole]

Yes, I had seen that.

We definitely need a bunch of notes in the release process about all these
new steps

On Thu, Jan 18, 2018 at 12:38 PM Guillaume Smet 
wrote:

> Hi Steve,
>
> I have to go very soon so I can't test myself right now but that might be
> because you're missing this file in the 5.3 directory:
>
> https://github.com/hibernate/hibernate.org/blob/d22b1461ee5ae7aac56cff90e4869b57599bb321/_data/projects/orm/releases/5.2/series.yml
>
> You need one to describe the series.
>
> --
> Guillaume
>
> On Thu, Jan 18, 2018 at 7:22 PM, Steve Ebersole 
> wrote:
>
>> I am trying to finish up the announce and website changes for 5.3.0.Beta1.
>>
>> staging.in.relation.to changes built fine.
>>
>> However I am getting incomprehensible (to me) failures on the CI server
>> trying to build the staging website.  Help?
>>
> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] staging.hibernate.org CI failure

[Steve Ebersole]

That did help, thanks!

One additional step is to add `hibernate.org/orm/releases/5.3/index.adoc`
too

I am capturing all of this on our release steps wiki

On Thu, Jan 18, 2018 at 12:43 PM Guillaume Smet 
wrote:

> See the thread "ORM release process" I started in late September.
>
> HTH.
>
> On Thu, Jan 18, 2018 at 7:40 PM, Steve Ebersole 
> wrote:
>
>> Yes, I had seen that.
>>
>> We definitely need a bunch of notes in the release process about all
>> these new steps
>>
>> On Thu, Jan 18, 2018 at 12:38 PM Guillaume Smet 
>> wrote:
>>
>>> Hi Steve,
>>>
>>> I have to go very soon so I can't test myself right now but that might
>>> be because you're missing this file in the 5.3 directory:
>>>
>>> https://github.com/hibernate/hibernate.org/blob/d22b1461ee5ae7aac56cff90e4869b57599bb321/_data/projects/orm/releases/5.2/series.yml
>>>
>>> You need one to describe the series.
>>>
>>> --
>>> Guillaume
>>>
>>> On Thu, Jan 18, 2018 at 7:22 PM, Steve Ebersole 
>>> wrote:
>>>
 I am trying to finish up the announce and website changes for
 5.3.0.Beta1.

 staging.in.relation.to changes built fine.

 However I am getting incomprehensible (to me) failures on the CI server
 trying to build the staging website.  Help?

>>> ___
 hibernate-dev mailing list
 hibernate-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/hibernate-dev

>>>
>>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-12172 - Bintray v. OSSRH

[Steve Ebersole]

Bintray said they would increase the storage limit to 30G for Hibernate.
However that limit is per organization, which is the top-level thing (
https://bintray.com/hibernate).  I think we'd eat that up in no time,
especially if other projects plan on moving to Bintray at any time.

One way around that would be to have each project be its own Bintray
organization.


On Fri, Jan 12, 2018 at 7:33 AM Gunnar Morling  wrote:

> 2018-01-12 12:59 GMT+01:00 Sanne Grinovero :
>
> > Personally I'm neutral. I surely wouldn't want to manage our own
> > Artifactory, but since JFrog will do that I'm not concerned about the
> > platform management being horrible.
> >
> > Artifactory looks better, OSSRH has the benefit of possibly having
> > better integration with Maven.
> >
> > There are some benefits on staying to JBoss's nexus though; not
> > expressing a strong opinion but let's clarify these.
> >
> > # Stats
> > We need download statistics, which I understand they all offer, but an
> > absolute number is not as useful as being able to compare the numbers
> > in one dashboard across various others of our projects.
> > Also not looking forward to have to login to multiple systems to gather
> it
> > all.
> >
> > # Quality control of artifacts
> > I'm understanding that JBoss Nexus does several strict validations on
> > our poms; sure they have been in the way as it's not nice to see such
> > failures *during* a release but there's an upside to them as well.
> > AFAIK OSSRH also has similar rules, but the JBoss team one has
> > different ones, plus a deal with Sonatype to deem our stuff good
> > "pre-approved" so we don't have to satisfy the Sonatype rules too.
> >
> > # Signing
> > Also I'm understanding that to release on OSSRH we need to sign all
> > artifacts; not a bad idea but it's quite more papework and key
> > management. Such paperwork is handled for us by the JBoss Nexus team.
> > We'd need to install GPG on our release servers, get a organization
> > RSA key signed, and people stubbornly releasing manually will have to
> > create a key each, and have it approved by Sonatype.
> >
>
> Debezium already is released to OSSRH from our CI server. May be worth
> chatting to Jiri (added him to CC) about the details of setup. Note there's
> no need for key approval by Sonatype (at least last time I did it), you
> only need to publish them to some key server which you can do all by
> yourself.
>
>
> >
> > Not against migrating if this is what you all want - just making sure
> > we're keeping these into account.
> >
> > Thanks,
> > Sanne
> >
> >
> > On 12 January 2018 at 02:47, Brett Meyer  wrote:
> > > Sorry for the late and probably irrelevant response...
> > >
> > > We're using an in-house Artifactory instance at a gig and it's been
> > > trash.  I can't speak to the UI or management end, nor Bintray, but
> > > Artifactory's platform doesn't seem as polished (can't believe I just
> > > said that) or stable (can't believe I said that either) as Nexus (what
> > > is happening).
> > >
> > > I use OSSRH for some minor projects and have generally had decent luck
> > > -- including a few interactions with the support team that went well.
> > > OSSRH != JBoss Nexus, although I definitely understand the wounds...
> > >
> > >
> > > On 12/19/17 8:34 AM, Steve Ebersole wrote:
> > >> HHH-12172 is about moving away from the JBoss Nexus repo for
> publishing
> > our
> > >> artifacts.  There is an open question about which service to use
> > instead -
> > >> Sonatype's OSSRH (Nexus) or JFrog's Bintray (Artifactory).
> > >>
> > >> Personally I think Artifactory is far superior of a UI/platform.  We
> all
> > >> know Nexus from the JBoss deployment of it, and we have all generally
> > had
> > >> nothing good to say about it.
> > >>
> > >> But I am wondering if anyone has practical experience with either, or
> > knows
> > >> persons/projects tyay do and could share their experiences.  E.g.,
> even
> > >> though I prefer Bintray in almost every regard, I am very nervous that
> > it
> > >> seems next to impossible to get help/support with it.  The same may be
> > true
> > >> with OSSRH - I don't know, hence why I am asking ;)
> > >> ___
> > >> hibernate-dev mailing list
> > >> hibernate-dev@lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > >
> > > ___
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@list

[hibernate-dev] Does Hibernate ORM bytecode enhance application entity classes by default?

[Scott Marlow]

Hi,

Did we change Hibernate to automatically enhance/rewrite application 
entity classes by default?  I remember hearing a few times that we would 
but don't remember if that happened.

This is related to WildFly jira WFLY-8858 [1], which I'm not yet sure of 
how to completely fix (involves deal with multiple deployment ordering 
problems with application level datasources, CDI beanmanagers, parallel 
application deployment and application entity class enhancement).

One WildFly issue is that the application datasources aren't available 
until late in WildFly deployment but the JPA container needs to register 
the JPA classloader level transformers very early, so Hibernate can 
rewrite application classes.  This is further complicated by our WildFly 
CDI implementation needing to read application class definitions.

I wonder if it could make sense for 
org.hibernate.jpa.boot.spi.EntityManagerFactoryBuilder to have a 
separate way to register the ClassTransformer transformer early and 
trigger the PU bootstrap on the first call to registered 
ClassTransformer's.  If that doesn't happen, then we defer bootstrap 
until EntityManagerFactoryBuilder.build() is called.

Scott

[1] https://issues.jboss.org/browse/WFLY-8858
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] replace Pax Exam with Docker

[Brett Meyer]

Thanks Chris!  Steve, not sure if you officially voted -- any concerns?  
Andrea?  Anyone else?

Again, this would all be disabled by default, behind a Maven profile...


On 1/16/18 3:15 PM, Chris Cranford wrote:
> On 01/12/2018 12:54 PM, Sanne Grinovero wrote:
>> On 12 January 2018 at 17:32, Brett Meyer  wrote:
>>> If I don't have time to contribute to Pax Exam, I certainly don't have
>>> time to start a new project haha...
>>>
>>> And realistically, that "something new" would likely involve containers
>>> anyway.
>>>
>>> At this point, mostly a question of 1) status quo, 2) Docker (or any
>>> other container-based solution), or 3) try screwing around with Pax Exam
>>> in "server-only" mode (but I don't have high hopes there).
>> Sure. Docker is now available on the CI slaves too, so that's not a problem.
>>
>> The only annoyance is that the whole ORM team - and anyone
>> contributing - would need to have Docker as well, but that doesn't
>> seem too bad to me... and was likely bound to happen for other tools
>> :)
>>
>> Steve, Chris and Andrea? Ok with that? Maybe you have Docker running already?
> I am fine with it; I have Docker installed already.
>


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] replace Pax Exam with Docker

[Steve Ebersole]

I'm ok with it.  But we use Gradle, so it'll be hard to use a Maven profile
;)

On Thu, Jan 18, 2018, 4:14 PM Brett Meyer  wrote:

> Thanks Chris!  Steve, not sure if you officially voted -- any concerns?
> Andrea?  Anyone else?
>
> Again, this would all be disabled by default, behind a Maven profile...
>
>
> On 1/16/18 3:15 PM, Chris Cranford wrote:
> > On 01/12/2018 12:54 PM, Sanne Grinovero wrote:
> >> On 12 January 2018 at 17:32, Brett Meyer  wrote:
> >>> If I don't have time to contribute to Pax Exam, I certainly don't have
> >>> time to start a new project haha...
> >>>
> >>> And realistically, that "something new" would likely involve containers
> >>> anyway.
> >>>
> >>> At this point, mostly a question of 1) status quo, 2) Docker (or any
> >>> other container-based solution), or 3) try screwing around with Pax
> Exam
> >>> in "server-only" mode (but I don't have high hopes there).
> >> Sure. Docker is now available on the CI slaves too, so that's not a
> problem.
> >>
> >> The only annoyance is that the whole ORM team - and anyone
> >> contributing - would need to have Docker as well, but that doesn't
> >> seem too bad to me... and was likely bound to happen for other tools
> >> :)
> >>
> >> Steve, Chris and Andrea? Ok with that? Maybe you have Docker running
> already?
> > I am fine with it; I have Docker installed already.
> >
>
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] replace Pax Exam with Docker

[Brett Meyer]

One of them there build tool profile or switch thingies.  Sorry, been in 
Maven land for too long these days...


On 1/18/18 5:21 PM, Steve Ebersole wrote:
>
> I'm ok with it.  But we use Gradle, so it'll be hard to use a Maven 
> profile ;)
>
>
> On Thu, Jan 18, 2018, 4:14 PM Brett Meyer  > wrote:
>
> Thanks Chris!  Steve, not sure if you officially voted -- any
> concerns?
> Andrea?  Anyone else?
>
> Again, this would all be disabled by default, behind a Maven
> profile...
>
>
> On 1/16/18 3:15 PM, Chris Cranford wrote:
> > On 01/12/2018 12:54 PM, Sanne Grinovero wrote:
> >> On 12 January 2018 at 17:32, Brett Meyer  > wrote:
> >>> If I don't have time to contribute to Pax Exam, I certainly
> don't have
> >>> time to start a new project haha...
> >>>
> >>> And realistically, that "something new" would likely involve
> containers
> >>> anyway.
> >>>
> >>> At this point, mostly a question of 1) status quo, 2) Docker
> (or any
> >>> other container-based solution), or 3) try screwing around
> with Pax Exam
> >>> in "server-only" mode (but I don't have high hopes there).
> >> Sure. Docker is now available on the CI slaves too, so that's
> not a problem.
> >>
> >> The only annoyance is that the whole ORM team - and anyone
> >> contributing - would need to have Docker as well, but that doesn't
> >> seem too bad to me... and was likely bound to happen for other
> tools
> >> :)
> >>
> >> Steve, Chris and Andrea? Ok with that? Maybe you have Docker
> running already?
> > I am fine with it; I have Docker installed already.
> >
>
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org 
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Does Hibernate ORM bytecode enhance application entity classes by default?

[Luis Barreiro]

Hi Scott,

I can only comment on the initial question. No, hibernate does not 
automatically enhance entities. Entities are either enhanced at build 
time or after WildFly has pushed the right ClassTransformer (based on 
"hibernate.enhance.*" properties in persistence.xml).

I'm not aware of any plans to change the current behavior.

Regards,

Luis Barreiro

Middleware Performance Team



On 01/18/2018 09:39 PM, Scott Marlow wrote:
> Hi,
>
> Did we change Hibernate to automatically enhance/rewrite application
> entity classes by default?  I remember hearing a few times that we would
> but don't remember if that happened.
>
> This is related to WildFly jira WFLY-8858 [1], which I'm not yet sure of
> how to completely fix (involves deal with multiple deployment ordering
> problems with application level datasources, CDI beanmanagers, parallel
> application deployment and application entity class enhancement).
>
> One WildFly issue is that the application datasources aren't available
> until late in WildFly deployment but the JPA container needs to register
> the JPA classloader level transformers very early, so Hibernate can
> rewrite application classes.  This is further complicated by our WildFly
> CDI implementation needing to read application class definitions.
>
> I wonder if it could make sense for
> org.hibernate.jpa.boot.spi.EntityManagerFactoryBuilder to have a
> separate way to register the ClassTransformer transformer early and
> trigger the PU bootstrap on the first call to registered
> ClassTransformer's.  If that doesn't happen, then we defer bootstrap
> until EntityManagerFactoryBuilder.build() is called.
>
> Scott
>
> [1] https://issues.jboss.org/browse/WFLY-8858
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev