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 ;)
That's right :(
Including it in the build script gets our provioning plugin to know how to
resolve things, and all works fine in the phase of creating the server
But next the produced Wildfly server starts in a new JVM, entirely new
context, and expects to find the dependencies "as configured" for Maven,
for the current user. If the current user's configuration doesn't list the
JBoss nexus it will ignore the locally cached artifacts, even if we made
sure to download them during provisioning.
I'm looking for settings we might use today, if I fail I'll revert it.
On 24 Jan 2018 13:17, "Steve Ebersole" <steve(a)hibernate.org> wrote:
I'm confused. You're saying it's not enough to include it in the Gradle
On Wed, Jan 24, 2018, 5:05 AM Sanne Grinovero <sanne(a)hibernate.org> wrote:
> Hi all,
> especially Chris, and anyone else having problems with the integration
> tests using WildFly,
> the problem seems to be caused by not having the JBoss Nexus
> repository enabled in your *Maven* configuration. (Yes, even though we
> use Gradle..)
> For the time being could you create a ~/.m2/settings.xml
> having the content you can copy from:
> - https://raw.githubusercontent.com/hibernate/hibernate-search/
> This is just a temporary solution so that you're not stuck today,
> while I'm looking for a better fix.
> For details, see:
> - http://lists.jboss.org/pipermail/wildfly-dev/2018-January/006335.html
> Thanks, and sorry for the inconvenience!
> hibernate-dev mailing list
We just released Hibernate Search 5.9.0.CR1, with WildFly feature packs and
This is the last step before 5.9 is released. Be sure to check it out so
you can share your thoughts with us before the release!
You can find more information about 5.9.0.CR1 on our blog:
yoann(a)hibernate.org / yrodiere(a)redhat.com
Hibernate NoORM team
I've re-released the hibernate-jpa-2.1-api with a single, minor
change: declare the official Jigsaw module name "java.persistence" in
the Automatic-Module-Name header in the MANIFEST.
This was mostly done on request of the WildFly team, there's no strong
reason to upgrade any project, unless you want to experiment with
Jigsaw of course..
FYI version 1.0.1.Final never existed; my bad, I misinterpreted the
Reminder: for JPA 2.2 we'll be using the API bundle from the spec
group as it's now finally being released in Maven central. So going
forward it will be javax.persistence:javax.persistence-api.
We decided to roll over some minor pending issues to version 5.10 -
which will target Hibernate ORM 5.3 / JPA 2.2. So since we're all
eager to start working with ORM 5.3 we're wrapping up the works on
Version 5.9 now has only a couple of minor, mostly optional polishing
We plan to tag Hibernate Search 5.9.0.CR1 tomorrow evening.. which
means a final is coming soon after.
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 , 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.