2017-12-28 19:10 GMT+01:00 Steve Ebersole <st...@hibernate.org>: > > - 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 <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
