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 <st...@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 <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 <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 <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 <gun...@hibernate.org > > > >> >> wrote: > >> >> > >> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole <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 < > 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 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@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
