Re: [hibernate-dev] Realising the JavaDoc jars as well

2017-12-29 Thread andrea boriero 
+1 for filtering out internal packages.

not a strong opinion on grouping

On 24 December 2017 at 14:23, Steve Ebersole  wrote:

> Sure, but the question remains :P  It just adds another one:
>
>
>1. Should internal packages be generated into the javadocs (individual
>and/or aggregated)?
>2. Should the individual javadocs (only intended for publishing to
>Central) group the packages into api/spi(/internal) the way we do for
> the
>aggregated javadocs?
>
> Personally I think filtering out internal packages is a great idea.
>
> Regarding grouping packages, I think its not worth the effort for the
> individual ones - just have an overview for these that just notes this
> distinction.
>
> On Sat, Dec 23, 2017 at 6:53 AM Sanne Grinovero 
> wrote:
>
> > On 22 December 2017 at 18:16, Steve Ebersole 
> wrote:
> > > I wanted to get everyone's opinion about the api/spi/internal package
> > > grouping we do in the aggregated Javadoc in regards to the per-module
> > > javadocs.  Adding this logic adds significant overhead to the process
> of
> > > building the Javadoc, to the point where I am considering not
> performing
> > > that grouping there.
> > >
> > > Thoughts?
> >
> > For Hibernate Search we recently decided to not produce javadocs at
> > all for "internal"; everything else is just documented as a single
> > group.
> >
> > That cuts on the "need to know" complexity of end users. Advanced
> > users who could have benefitted from knowing more about the internals
> > will likely have sources.
> >
> > >
> > > On Tue, Dec 12, 2017 at 11:37 AM Vlad Mihalcea <
> mihalcea.v...@gmail.com>
> > > wrote:
> > >>
> > >> I tested it locally, and when publishing the jars to Maven local, the
> > >> JavaDoc is now included.
> > >>
> > >> Don't know if there's anything to be done about it.
> > >>
> > >> Vlad
> > >>
> > >> On Mon, Dec 11, 2017 at 9:32 PM, Sanne Grinovero  >
> > >> wrote:
> > >>
> > >> > +1 to merge it (if it works - which I didn't check)
> > >> >
> > >> > Some history can easily be found:
> > >> >  -
> > >> >
> > http://lists.jboss.org/pipermail/hibernate-dev/2017-January/015758.html
> > >> >
> > >> > Thanks,
> > >> > Sanne
> > >> >
> > >> >
> > >> > On 11 December 2017 at 15:24, Vlad Mihalcea <
> mihalcea.v...@gmail.com>
> > >> > wrote:
> > >> > > Hi,
> > >> > >
> > >> > > I've noticed this Pull Request which is valid and worth
> integrating:
> > >> > >
> > >> > > https://github.com/hibernate/hibernate-orm/pull/2078
> > >> > >
> > >> > > Before I merge it, I wanted to make sure whether this change was
> > >> > accidental
> > >> > > or intentional.
> > >> > >
> > >> > > Was there any reason not to ship the JavaDoc jars along with the
> > >> > > release
> > >> > > artifacts and the sources jars as well?
> > >> > >
> > >> > > Thanks,
> > >> > > Vlad
> > >> > > ___
> > >> > > 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

Re: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules

2017-12-29 Thread Steve Ebersole 
Maybe this is similar to the problems we've had with the WildFly
hibernate-orm-moudles stuff - versions of karaf/aries/etc not yet
supporting EE8 techs (JPA 2.2, CDI 2.0, etc)?


On Thu, Dec 28, 2017 at 11:56 AM Steve Ebersole  wrote:

> Brett, after making these changes the osgi tests now fail[1] with a RMI
> connection error which I cannot decipher.  Could you see if you can
> understand the problem?
>
> Thanks
>
> [1]
> http://ci.hibernate.org/job/hibernate-orm-master-h2-main/942/testReport/junit/org.hibernate.osgi.test/
>
>
>
> On Thu, Dec 28, 2017 at 9:06 AM Steve Ebersole 
> wrote:
>
>> After tweaking this, here is what I have...
>>
>> Manifest-Version: 1.0
>> Created-By: 1.8.0_121 (Oracle Corporation)
>> Main-Class: org.hibernate.Version
>>
>> Specification-Title: hibernate-core
>> Specification-Version: 5.3
>> Specification-Vendor: Hibernate.org
>>
>> Implementation-Title: hibernate-core
>> Implementation-Version: 5.3.0.SNAPSHOT
>> Implementation-Vendor-Id: org.hibernate
>> Implementation-Vendor: Hibernate.org
>> Implementation-Url: http://hibernate.org
>>
>> Automatic-Module-Name: org.hibernate.orm.core
>>
>> Bundle-ManifestVersion: 2
>> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
>> Tool: Bnd-3.4.0.201707252008
>>
>> Bundle-SymbolicName: org.hibernate.orm.core
>> Bundle-Version: 5.3.0.SNAPSHOT
>> Bundle-Name: hibernate-core
>> Bundle-Description: A module of the Hibernate O/RM project
>> Bundle-Vendor: Hibernate.org
>> Bundle-DocURL: http://www.hibernate.org/orm/5.3
>> Bnd-LastModified: 1513615321000
>>
>> Import-Package: ...
>> Export-Package: ...
>>
>>
>> Which looks great to me...
>>
>> On Wed, Dec 27, 2017 at 3:39 PM Steve Ebersole 
>> wrote:
>>
>>> I had intended this for 5.3 which hasn't even gone Beta yet (we wont
>>> have an Alpha).
>>>
>>> On Wed, Dec 27, 2017 at 3:38 PM Brett Meyer  wrote:
>>>
 +1 from me on making them consistent.  In practice, Bundle-SymbolicName
 isn't used for much, other than a guaranteed unique identifier.  One of
 the Karaf guys pointed out that Bundle-SymbolicName is used to link a
 fragment bundle to its host bundle, but we've been able to avoid
 fragments like the plague on purpose.

 In practice, most users should be pulling in and interacting with our
 bundles purely through Maven artifacts or our features.xml, so a change
 would largely be unnoticed.

 We still might consider holding off doing that until at least a minor
 version change, since there is a potential issue for any tooling that
 might be relying on that (logging/auditing, etc.)...


 On 12/23/17 11:38 PM, Steve Ebersole wrote:
 > Another thing I was noticing was an annoying minor difference between
 the
 > OSGi bundle name and the Java 9 module name:
 >
 > Automatic-Module-Name: org.hibernate.orm.core
 > Bundle-SymbolicName: org.hibernate.core
 >
 > Does it make sense to adjust the OSGi bundle name to follow the module
 > naming?
 >
 > On Sat, Dec 23, 2017 at 8:47 AM Steve Ebersole 
 wrote:
 >
 >> I already did a PR for the `Automatic-Module-Name` yesterday and
 added you
 >> as a reviewer.  when you get a chance...
 >>
 >>
 >>
 >> On Sat, Dec 23, 2017 at 8:36 AM Gunnar Morling >>> >
 >> wrote:
 >>
 >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole :
 >>>
  I created a Jira to track this:
  https://hibernate.atlassian.net/browse/HHH-12188
 
  On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole <
 st...@hibernate.org>
  wrote:
 
 > Thanks for investigating this Gunnar.
 >
 > Some thoughts inline...
 >
 > On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling <
 gun...@hibernate.org>
 > wrote:
 >
 >
 >> * JDK 9 comes with an incomplete JTA module (java.transaction),
 so a
 >> complete one must be provided via --upgrade-module-path (I'm
 using the
 >> 2.0.0.Alpha1 version Tomaz Cerar has created for that purpose)
 >>
 > Do you know if there is a plan to fix this in Java 9?  Seems
 bizarre
 > that Java 9 expects all kinds of strict modularity from libraries
 and
 > applications when the JDK itself can't follow that..
 >
 >>> The "java.transaction" module of the JDK is marked with
 >>> @Deprecated(forRemoval=true) as of Java 9, but I don't know when the
 >>> removal will happen. There's JEP 320 for this (
 >>> http://openjdk.java.net/jeps/320), which also describes why the
 module
 >>> exists in its current form. It's not scheduled for Java 10
 currently, and
 >>> given the latter is in rampdown already, I wouldn't expect this
 removal to
 >>> happen before Java 11.
 >>>
 >>>
 >> * hibernate-jpa-2.1-api-1.0.0.Final.jar can't be used as an
 automatic
 >> module, as the a

Re: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules

2017-12-29 Thread Brett Meyer 
Hey Steve, just to clarify, did this start failing directly after the 
manifest change?  Or are you saying it could be from other 
dependency-related updates?


On 12/29/17 10:58 AM, Steve Ebersole wrote:
> Maybe this is similar to the problems we've had with the WildFly 
> hibernate-orm-moudles stuff - versions of karaf/aries/etc not yet 
> supporting EE8 techs (JPA 2.2, CDI 2.0, etc)?
>
>
> On Thu, Dec 28, 2017 at 11:56 AM Steve Ebersole  > wrote:
>
> Brett, after making these changes the osgi tests now fail[1] with
> a RMI connection error which I cannot decipher.  Could you see if
> you can understand the problem?
>
> Thanks
>
> [1]
> 
> http://ci.hibernate.org/job/hibernate-orm-master-h2-main/942/testReport/junit/org.hibernate.osgi.test/
>
>
>
> On Thu, Dec 28, 2017 at 9:06 AM Steve Ebersole
> mailto:st...@hibernate.org>> wrote:
>
> After tweaking this, here is what I have...
>
> Manifest-Version: 1.0
> Created-By: 1.8.0_121 (Oracle Corporation)
> Main-Class: org.hibernate.Version
>
> Specification-Title: hibernate-core
> Specification-Version: 5.3
> Specification-Vendor: Hibernate.org
>
> Implementation-Title: hibernate-core
> Implementation-Version: 5.3.0.SNAPSHOT
> Implementation-Vendor-Id: org.hibernate
> Implementation-Vendor: Hibernate.org
> Implementation-Url: http://hibernate.org
>
> Automatic-Module-Name: org.hibernate.orm.core
>
> Bundle-ManifestVersion: 2
> Require-Capability: osgi.ee
> ;filter:="(&(osgi.ee
> =JavaSE)(version=1.8))"
> Tool: Bnd-3.4.0.201707252008
>
> Bundle-SymbolicName: org.hibernate.orm.core
> Bundle-Version: 5.3.0.SNAPSHOT
> Bundle-Name: hibernate-core
> Bundle-Description: A module of the Hibernate O/RM project
> Bundle-Vendor: Hibernate.org
> Bundle-DocURL: http://www.hibernate.org/orm/5.3
> Bnd-LastModified: 1513615321000
>
> Import-Package: ...
> Export-Package: ...
>
>
> Which looks great to me...
>
> On Wed, Dec 27, 2017 at 3:39 PM Steve Ebersole
> mailto:st...@hibernate.org>> wrote:
>
> I had intended this for 5.3 which hasn't even gone Beta
> yet (we wont have an Alpha).
>
> On Wed, Dec 27, 2017 at 3:38 PM Brett Meyer
> mailto:br...@hibernate.org>> wrote:
>
> +1 from me on making them consistent.  In practice,
> Bundle-SymbolicName
> isn't used for much, other than a guaranteed unique
> identifier.  One of
> the Karaf guys pointed out that Bundle-SymbolicName is
> used to link a
> fragment bundle to its host bundle, but we've been
> able to avoid
> fragments like the plague on purpose.
>
> In practice, most users should be pulling in and
> interacting with our
> bundles purely through Maven artifacts or our
> features.xml, so a change
> would largely be unnoticed.
>
> We still might consider holding off doing that until
> at least a minor
> version change, since there is a potential issue for
> any tooling that
> might be relying on that (logging/auditing, etc.)...
>
>
> On 12/23/17 11:38 PM, Steve Ebersole wrote:
> > Another thing I was noticing was an annoying minor
> difference between the
> > OSGi bundle name and the Java 9 module name:
> >
> > Automatic-Module-Name: org.hibernate.orm.core
> > Bundle-SymbolicName: org.hibernate.core
> >
> > Does it make sense to adjust the OSGi bundle name to
> follow the module
> > naming?
> >
> > On Sat, Dec 23, 2017 at 8:47 AM Steve Ebersole
> mailto:st...@hibernate.org>> wrote:
> >
> >> I already did a PR for the `Automatic-Module-Name`
> yesterday and added you
> >> as a reviewer.  when you get a chance...
> >>
> >>
> >>
> >> On Sat, Dec 23, 2017 at 8:36 AM Gunnar Morling
> mailto:gun...@hibernate.org>>
> >> wrote:
> >>
> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole
> mailto:st...@hibernate.org>>:
> >>>
>  I created a Jira to track this:
>  https://hibernate.atlassian.net/browse/HHH-12188
> 
>  On Fri, Dec 22, 2017 at 5:33 AM Steve

Re: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules

2017-12-29 Thread Steve Ebersole 
Actually I found the problem.  Its actually not related to the manifest
change.  The problem was a mismatch in the bundle group/module names for
JPA since we switched to the (now published) standard JPA API jar.  Fixing
that fixed the failures.  Sorry for the noise.


On Fri, Dec 29, 2017 at 10:35 AM Brett Meyer  wrote:

> Hey Steve, just to clarify, did this start failing directly after the
> manifest change?  Or are you saying it could be from other
> dependency-related updates?
>
> On 12/29/17 10:58 AM, Steve Ebersole wrote:
>
> Maybe this is similar to the problems we've had with the WildFly
> hibernate-orm-moudles stuff - versions of karaf/aries/etc not yet
> supporting EE8 techs (JPA 2.2, CDI 2.0, etc)?
>
>
> On Thu, Dec 28, 2017 at 11:56 AM Steve Ebersole 
> wrote:
>
>> Brett, after making these changes the osgi tests now fail[1] with a RMI
>> connection error which I cannot decipher.  Could you see if you can
>> understand the problem?
>>
>> Thanks
>>
>> [1]
>> http://ci.hibernate.org/job/hibernate-orm-master-h2-main/942/testReport/junit/org.hibernate.osgi.test/
>>
>>
>>
>> On Thu, Dec 28, 2017 at 9:06 AM Steve Ebersole 
>> wrote:
>>
>>> After tweaking this, here is what I have...
>>>
>>> Manifest-Version: 1.0
>>> Created-By: 1.8.0_121 (Oracle Corporation)
>>> Main-Class: org.hibernate.Version
>>>
>>> Specification-Title: hibernate-core
>>> Specification-Version: 5.3
>>> Specification-Vendor: Hibernate.org
>>>
>>> Implementation-Title: hibernate-core
>>> Implementation-Version: 5.3.0.SNAPSHOT
>>> Implementation-Vendor-Id: org.hibernate
>>> Implementation-Vendor: Hibernate.org
>>> Implementation-Url: http://hibernate.org
>>>
>>> Automatic-Module-Name: org.hibernate.orm.core
>>>
>>> Bundle-ManifestVersion: 2
>>> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
>>> Tool: Bnd-3.4.0.201707252008
>>>
>>> Bundle-SymbolicName: org.hibernate.orm.core
>>> Bundle-Version: 5.3.0.SNAPSHOT
>>> Bundle-Name: hibernate-core
>>> Bundle-Description: A module of the Hibernate O/RM project
>>> Bundle-Vendor: Hibernate.org
>>> Bundle-DocURL: http://www.hibernate.org/orm/5.3
>>> Bnd-LastModified: 1513615321000
>>>
>>> Import-Package: ...
>>> Export-Package: ...
>>>
>>>
>>> Which looks great to me...
>>>
>>> On Wed, Dec 27, 2017 at 3:39 PM Steve Ebersole 
>>> wrote:
>>>
 I had intended this for 5.3 which hasn't even gone Beta yet (we wont
 have an Alpha).

 On Wed, Dec 27, 2017 at 3:38 PM Brett Meyer 
 wrote:

> +1 from me on making them consistent.  In practice, Bundle-SymbolicName
> isn't used for much, other than a guaranteed unique identifier.  One of
> the Karaf guys pointed out that Bundle-SymbolicName is used to link a
> fragment bundle to its host bundle, but we've been able to avoid
> fragments like the plague on purpose.
>
> In practice, most users should be pulling in and interacting with our
> bundles purely through Maven artifacts or our features.xml, so a change
> would largely be unnoticed.
>
> We still might consider holding off doing that until at least a minor
> version change, since there is a potential issue for any tooling that
> might be relying on that (logging/auditing, etc.)...
>
>
> On 12/23/17 11:38 PM, Steve Ebersole wrote:
> > Another thing I was noticing was an annoying minor difference
> between the
> > OSGi bundle name and the Java 9 module name:
> >
> > Automatic-Module-Name: org.hibernate.orm.core
> > Bundle-SymbolicName: org.hibernate.core
> >
> > Does it make sense to adjust the OSGi bundle name to follow the
> module
> > naming?
> >
> > On Sat, Dec 23, 2017 at 8:47 AM Steve Ebersole 
> wrote:
> >
> >> I already did a PR for the `Automatic-Module-Name` yesterday and
> added you
> >> as a reviewer.  when you get a chance...
> >>
> >>
> >>
> >> On Sat, Dec 23, 2017 at 8:36 AM Gunnar Morling <
> gun...@hibernate.org>
> >> wrote:
> >>
> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole :
> >>>
>  I created a Jira to track this:
>  https://hibernate.atlassian.net/browse/HHH-12188
> 
>  On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole <
> st...@hibernate.org>
>  wrote:
> 
> > Thanks for investigating this Gunnar.
> >
> > Some thoughts inline...
> >
> > On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling <
> gun...@hibernate.org>
> > wrote:
> >
> >
> >> * JDK 9 comes with an incomplete JTA module (java.transaction),
> so a
> >> complete one must be provided via --upgrade-module-path (I'm
> using the
> >> 2.0.0.Alpha1 version Tomaz Cerar has created for that purpose)
> >>
> > Do you know if there is a plan to fix this in Java 9?  Seems
> bizarre
> > that Java 9 expects all kinds of strict modularity from
> librarie

Re: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules

2017-12-29 Thread Brett Meyer 
Sorry folks, responding to this thread out of order...

Steve, at first glance, this looks fine!


On 12/28/17 10:06 AM, Steve Ebersole wrote:
> After tweaking this, here is what I have...
>
> Manifest-Version: 1.0
> Created-By: 1.8.0_121 (Oracle Corporation)
> Main-Class: org.hibernate.Version
>
> Specification-Title: hibernate-core
> Specification-Version: 5.3
> Specification-Vendor: Hibernate.org
>
> Implementation-Title: hibernate-core
> Implementation-Version: 5.3.0.SNAPSHOT
> Implementation-Vendor-Id: org.hibernate
> Implementation-Vendor: Hibernate.org
> Implementation-Url: http://hibernate.org
>
> Automatic-Module-Name: org.hibernate.orm.core
>
> Bundle-ManifestVersion: 2
> Require-Capability: osgi.ee ;filter:="(&(osgi.ee 
> =JavaSE)(version=1.8))"
> Tool: Bnd-3.4.0.201707252008
>
> Bundle-SymbolicName: org.hibernate.orm.core
> Bundle-Version: 5.3.0.SNAPSHOT
> Bundle-Name: hibernate-core
> Bundle-Description: A module of the Hibernate O/RM project
> Bundle-Vendor: Hibernate.org
> Bundle-DocURL: http://www.hibernate.org/orm/5.3
> Bnd-LastModified: 1513615321000
>
> Import-Package: ...
> Export-Package: ...
>
>
> Which looks great to me...
>
> On Wed, Dec 27, 2017 at 3:39 PM Steve Ebersole  > wrote:
>
> I had intended this for 5.3 which hasn't even gone Beta yet (we
> wont have an Alpha).
>
> On Wed, Dec 27, 2017 at 3:38 PM Brett Meyer  > wrote:
>
> +1 from me on making them consistent.  In practice,
> Bundle-SymbolicName
> isn't used for much, other than a guaranteed unique
> identifier.  One of
> the Karaf guys pointed out that Bundle-SymbolicName is used to
> link a
> fragment bundle to its host bundle, but we've been able to avoid
> fragments like the plague on purpose.
>
> In practice, most users should be pulling in and interacting
> with our
> bundles purely through Maven artifacts or our features.xml, so
> a change
> would largely be unnoticed.
>
> We still might consider holding off doing that until at least
> a minor
> version change, since there is a potential issue for any
> tooling that
> might be relying on that (logging/auditing, etc.)...
>
>
> On 12/23/17 11:38 PM, Steve Ebersole wrote:
> > Another thing I was noticing was an annoying minor
> difference between the
> > OSGi bundle name and the Java 9 module name:
> >
> > Automatic-Module-Name: org.hibernate.orm.core
> > Bundle-SymbolicName: org.hibernate.core
> >
> > Does it make sense to adjust the OSGi bundle name to follow
> the module
> > naming?
> >
> > On Sat, Dec 23, 2017 at 8:47 AM Steve Ebersole
> mailto:st...@hibernate.org>> wrote:
> >
> >> I already did a PR for the `Automatic-Module-Name`
> yesterday and added you
> >> as a reviewer.  when you get a chance...
> >>
> >>
> >>
> >> On Sat, Dec 23, 2017 at 8:36 AM Gunnar Morling
> mailto:gun...@hibernate.org>>
> >> wrote:
> >>
> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole
> mailto:st...@hibernate.org>>:
> >>>
>  I created a Jira to track this:
>  https://hibernate.atlassian.net/browse/HHH-12188
> 
>  On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole
> mailto:st...@hibernate.org>>
>  wrote:
> 
> > Thanks for investigating this Gunnar.
> >
> > Some thoughts inline...
> >
> > On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling
> mailto:gun...@hibernate.org>>
> > wrote:
> >
> >
> >> * JDK 9 comes with an incomplete JTA module
> (java.transaction), so a
> >> complete one must be provided via --upgrade-module-path
> (I'm using the
> >> 2.0.0.Alpha1 version Tomaz Cerar has created for that
> purpose)
> >>
> > Do you know if there is a plan to fix this in Java 9? 
> Seems bizarre
> > that Java 9 expects all kinds of strict modularity from
> libraries and
> > applications when the JDK itself can't follow that..
> >
> >>> The "java.transaction" module of the JDK is marked with
> >>> @Deprecated(forRemoval=true) as of Java 9, but I don't
> know when the
> >>> removal will happen. There's JEP 320 for this (
> >>> http://openjdk.java.net/jeps/320), which also describes
> why the module
> >>> exists in its current form. It's not scheduled for Java 10
> currently, and
> >>> given the latter is in rampdown already, I wouldn't expect
> this rem

Re: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules

2017-12-29 Thread Steve Ebersole 
On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole  wrote:

>
> * When using ByteBuddy as the byte code provider, I still needed to have
>> Javassist around, as it's used in ClassFileArchiveEntryHandler. I
>> understand that eventually this should be using Jandex, but I'm wondering
>> whether we could (temporarily) change it to use ASM instead of Javassist
>> (at least when using ByteBuddy as byte code provider, which is based on
>> ASM), so people don't need to have Javassist *and* ByteBuddy when using
>> the
>> latter as byte code provider? This seems desirable esp. once we move to
>> ByteBuddy by default.
>>
>
> Yes, Sanne brought this up in Paris and it is something I will look at
> prior to a 5.3.0.Final
>

Actually this is different than what Sanne brought up.  I actually cannot
reproduce what Sanne is reporting.  If I had to guess he was not specifying
the bytecode provider to use "globally".  This is a special kind of setting
(we used to have a few) that can only be specified per-VM : either as a
root `hibernate.properties` or as a System property.  It has to do with how
Hibernate builds its mapping model, specifically
`org.hibernate.mapping.Component`.  Given the redesign of the bootstrap
process we may actually be able to remove that "VM wide" requirement.  I'll
look into that for 5.3.  BTW Sanne, I created a repo[1] showing that this
does indeed work when specified "properly".

Gunnar, what you are seeing is very different and I'm not sure of a way to
solve that yet.  That is all part of auto-discovery of resources (entities,
embeddables, converters, etc) during bootstrap.  We need to inspect the
file without loading the Class to look at its annotations.  We need
*something* to do that, whether that is Jandex, Javassist, etc.  Byte Buddy
may or may not have a similar facility.  The problem here is that the
Javassist dependency is needed for a very different purpose.  And without a
viable alternative solution, its going to have to stay that way.

[1] https://github.com/sebersole/orm-bytebuddy-no-javassist
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev