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 <st...@hibernate.org > <mailto:st...@hibernate.org>> 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 > <st...@hibernate.org <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 > <http://osgi.ee>;filter:="(&(osgi.ee > <http://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 <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 > <br...@hibernate.org <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 > <st...@hibernate.org <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 > <gun...@hibernate.org <mailto:gun...@hibernate.org>> > >> wrote: > >> > >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole > <st...@hibernate.org <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 > <st...@hibernate.org <mailto: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 <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 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 > <mailto:hibernate-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > <mailto: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
