- 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. - 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
On Thu, Dec 28, 2017 at 11:58 AM Gunnar Morling <gun...@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 <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
