- Main-Class is fine afaik. It was requested previously by users and
added accordingly. I'm not going to change it unless you can show me
concrete reason to.
Seeing now that Version indeed defines a main() method, didn't expect
that. No
reason to change it indeed.
- Specification-* - I had considered that. TBH its not important
afaik. And Hibernate defines a specification as well (its API) that is a
super set of JPA. And its not like I just added this. Those have been
generated into the manifest at least as far back as the move to Gradle.
I've yet to hear a compliant besides yours today
Not important for sure, and I can get behind your reasoning about
Hibernate's public API being the "specification" here. All good then, not
sure who'd be consuming those headers anyways.
On Thu, Dec 28, 2017 at 11:58 AM Gunnar Morling <gunnar(a)hibernate.org>
wrote:
> Automatic-Module-Name looks good.
>
> While unrelated, those look odd:
>
> * Main-Class: I don't think ORM - as a library - should declare this
> * Specification-Title, Specification-Version: should these rather relate
> to JPA title and version (as opposed to the Implementation-* ones)?
>
>
> 2017-12-28 16:06 GMT+01:00 Steve Ebersole <steve(a)hibernate.org>:
>
>> 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 <steve(a)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 <brett(a)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
<steve(a)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 <
>> gunnar(a)hibernate.org>
>> >> >> wrote:
>> >> >>
>> >> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole
<steve(a)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 <
>> steve(a)hibernate.org>
>> >> >>>> wrote:
>> >> >>>>
>> >> >>>>> Thanks for investigating this Gunnar.
>> >> >>>>>
>> >> >>>>> Some thoughts inline...
>> >> >>>>>
>> >> >>>>> On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling
<
>> >> gunnar(a)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 automatic naming algorithm
stumples upon the
>> numbers
>> >> >>>>>> (2.1)
>> >> >>>>>> within the module name it derives; I'm
therefore using my
>> ModiTect
>> >> >>>>>> tooling (
>> >> >>>>>>
https://github.com/moditect/moditect/) to
convert the JPA API
>> JAR
>> >> >>>>>> into an
>> >> >>>>>> explicit module on the fly
>> >> >>>>>>
>> >> >>>>> We actually no longer use that artifact as a
dependency. Since
>> JPA
>> >> >>>>> 2.2, the EG publishes a "blessed" API jar
which is what we use
>> as a
>> >> >>>>> dependency.
>> >> >>>>>
>> >> >>> Ah, yes, very nice. That one already defines an explicit
module
>> name
>> >> >>> ("java.persistence") via the
Automatic-Module-Name manifest entry.
>> >> >>>
>> >> >>>>>> * When using ByteBuddy as the byte code
provider, a reads
>> >> relationship
>> >> >>>>>> must
>> >> >>>>>> be added from the user's module towards
hibernate.core
>> ("requires
>> >> >>>>>> hibernate.core"). This is due to the usage
of
>> >> >>>>>> org.hibernate.proxy.ProxyConfiguration within
the generated
>> proxy
>> >> >>>>>> classes.
>> >> >>>>>> Ideally no dependence to the JPA provider
should be needed when
>> >> solely
>> >> >>>>>> working with the JPA API (as this demo does),
but I'm not sure
>> >> whether
>> >> >>>>>> this
>> >> >>>>>> can be avoided when using proxies (or could we
construct
>> proxies
>> >> in a
>> >> >>>>>> way
>> >> >>>>>> not requiring this dependence?).
>> >> >>>>>>
>> >> >>>>> I'm not sure what a decent solution would be
here. Ultimately
>> the
>> >> >>>>> runtime needs to be able to communicate with the
generated
>> proxies
>> >> - how
>> >> >>>>> else would you suggest this happen?
>> >> >>>>>
>> >> >>> Not sure either. Maybe we could generate a dedicated
interface
>> into
>> >> the
>> >> >>> user's module and then inject a generated
implementation -- living
>> >> within
>> >> >>> the ORM module -- of that interface into the entities.
Worth some
>> >> tinkering
>> >> >>> I reckon.
>> >> >>>
>> >> >>>>> * 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
>> >> >>>>>
>> >> >>> Excellent.
>> >> >>>
>> >> >>>>> * Multiple methods in ReflectHelper call
setAccessible() without
>> >> >>>>>> checking
>> >> >>>>>> whether the method/field/constructor already is
accessible. If
>> we
>> >> >>>>>> changed
>> >> >>>>>> that to only call setAccessible() if actually
needed, people
>> would
>> >> >>>>>> have to
>> >> >>>>>> be a little bit less permissive in their module
descriptor.
>> It'd
>> >> >>>>>> suffice
>> >> >>>>>> for them to declare "exports
com.example.entities to
>> >> hibernate.core"
>> >> >>>>>> instead of "opens com.example.entities to
hibernate.core",
>> unless
>> >> they
>> >> >>>>>> mandate (private) field access for their
entities.
>> >> >>>>>>
>> >> >>>>> Can you open a Jira for that?
>> >> >>>>>
>> >> >>> Done:
https://hibernate.atlassian.net/browse/HHH-12189.
>> >> >>>
>> >> >>>
>> >> >>>>>> The demo is very simple (insert and load of an
entity with a
>> lazy
>> >> >>>>>> association). If there's anything else
you'd like to try out
>> when
>> >> >>>>>> using ORM
>> >> >>>>>> as JPMS modules, let me know or just fork the
demo and try it
>> out
>> >> >>>>>> yourself
>> >> >>>>>>
>> >> >>>>> IIUC for jars targeting both Java 8 and Java 9 we
cannot
>> include a
>> >> >>>>> module-info file. But we need to set the module
names - you
>> >> mentioned
>> >> >>>>> there was a "hinting" process. From what
I could glean from
>> >> searching
>> >> >>>>> (which was oddly not many hits), this is achieved
by adding a
>> >> >>>>> `Automatic-Module-Name` entry in the JAR's
MANIFEST.MF.
>> Correct?
>> >> >>>>>
>> >> >>> Yes, exactly that's the mechanism. Jason Greene is
working on a
>> >> document
>> >> >>> with recommendations around naming patterns, I hope
it'll be
>> >> published soon.
>> >> >>>
>> >> >>>
>> >> >>>>> Also, IIRC we agreed with `org.hibernate.orm` as
the base for
>> all
>> >> ORM
>> >> >>>>> module names, so we'd have:
>> >> >>>>>
>> >> >>>>> - org.hibernate.orm.c3p0
>> >> >>>>> - org.hibernate.orm.core
>> >> >>>>> - ...
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> > _______________________________________________
>> >> > hibernate-dev mailing list
>> >> > hibernate-dev(a)lists.jboss.org
>> >> >
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> >>
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev(a)lists.jboss.org
>> >>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>