Re: [hibernate-dev] Java 9: progress on compatibility
On 11 June 2016 at 18:47, Sanne Grinovero wrote: > On 11 June 2016 at 18:25, Steve Ebersole wrote: >> The ORM failure seems to be a Gradle/JDK9 issue. Any idea about that? > > Not sure, that's a new one :) > It could be related to https://issues.gradle.org/browse/GRADLE-3287 ? > > Might be worth trying to upgrade to Gradle 2.12 .. I'm not at a > terminal at the moment, I could try later. I've upgraded to Gradle 2.13, the pull request is here: - https://github.com/hibernate/hibernate-orm/pull/1417# It solved that specific issue, but it's not enough. I'm still trying to hack a workaround for the next step, but in the meantime that PR could be considered independently. I could use some pointers with Gradle and the custom plugins we use; essentially we need to pass some additional JVM flags, including to javac, like here: - https://github.com/hibernate/hibernate-orm/commit/5e6a8ea754e3c4c59925fe7f824092490efc008b But the failure happens during: Execution failed for task ':hibernate-core:xjc' and I'm not sure how to override the JVM flags for that plugin execution. Thanks, Sanne > >> >> On Fri, Jun 10, 2016, 4:39 PM Sanne Grinovero wrote: >>> >>> Hi all, >>> please try to have a look at this page when you have a moment: >>> - http://ci.hibernate.org/view/JDK9/ >>> >>> Hibernate Search is working, and it shouldn't be too hard to get the >>> others "green" as well. >>> >>> I've disabled some integration tests to get there, notably: >>> - OSGi tests: Karaf is not ready for it. >>> - Documentation build: Asciidoc will probably need an update. >>> - WildFly integration tests: the WildFly team is aware, will need a >>> minor upgrade. >>> >>> I don't believe these issues are relevant, so I'm satisfied that all >>> other tests working fine mean that the project will pretty much work >>> out of the box for end users - at worst their container won't work, >>> but that's not our responsibility to test for. >>> >>> Could you all contribute a bit to get all projects show "green" on this >>> page? >>> >>> Some "workarounds" you might want to apply: >>> - the Logger interfaces won't compile because of a known issue, this >>> can be worked around for now by having the compilation phase also >>> explicitly depend on this artifact: >>> >>> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L878-L883 >>> - you'll have a ClassNotFoundException on JAXB usage unless you set >>> this JVM flag: >>> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L1429 >>> (This one is not a bug but will be required to be set by end users as >>> well - or we provide our own XML parser, that might be more user >>> friendly). >>> >>> As far as I know, other issues with the build tools have been solved >>> already - including Gradle. >>> >>> Thanks, >>> Sanne >>> ___ >>> 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
Re: [hibernate-dev] Java 9: progress on compatibility
Some more progress by simply setting this environment variable: GRADLE_OPTS="-XaddExports:java.security.sasl/com.sun.security.sasl.digest=ALL-UNNAMED -XaddExports:java.security.sasl/com.sun.security.sasl=ALL-UNNAMED -XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED -XaddExports:jdk.unsupported/sun.reflect=ALL-UNNAMED -addmods java.xml.bind" But it's getting tricky: Caused by: compile error: javassist.NotFoundException: java.lang.String at javassist.compiler.Javac.compileBody(Javac.java:229) at javassist.CtBehavior.setBody(CtBehavior.java:438) ... 76 more This seems to be caused by the following plugin, which I'm not familiar with: - org.hibernate.build.gradle.inject.InjectionAction.execute(InjectionAction.java:62) Is this something which we could disable/skip/remove for now, or update to not require Javassist? Thanks, sanne On 12 June 2016 at 20:56, Sanne Grinovero wrote: > On 11 June 2016 at 18:47, Sanne Grinovero wrote: >> On 11 June 2016 at 18:25, Steve Ebersole wrote: >>> The ORM failure seems to be a Gradle/JDK9 issue. Any idea about that? >> >> Not sure, that's a new one :) >> It could be related to https://issues.gradle.org/browse/GRADLE-3287 ? >> >> Might be worth trying to upgrade to Gradle 2.12 .. I'm not at a >> terminal at the moment, I could try later. > > I've upgraded to Gradle 2.13, the pull request is here: > - https://github.com/hibernate/hibernate-orm/pull/1417# > > It solved that specific issue, but it's not enough. I'm still trying > to hack a workaround for the next step, but in the meantime that PR > could be considered independently. > > I could use some pointers with Gradle and the custom plugins we use; > essentially we need to pass some additional JVM flags, including to > javac, like here: > - > https://github.com/hibernate/hibernate-orm/commit/5e6a8ea754e3c4c59925fe7f824092490efc008b > > But the failure happens during: > Execution failed for task ':hibernate-core:xjc' > > and I'm not sure how to override the JVM flags for that plugin execution. > > Thanks, > Sanne > > >> >>> >>> On Fri, Jun 10, 2016, 4:39 PM Sanne Grinovero wrote: Hi all, please try to have a look at this page when you have a moment: - http://ci.hibernate.org/view/JDK9/ Hibernate Search is working, and it shouldn't be too hard to get the others "green" as well. I've disabled some integration tests to get there, notably: - OSGi tests: Karaf is not ready for it. - Documentation build: Asciidoc will probably need an update. - WildFly integration tests: the WildFly team is aware, will need a minor upgrade. I don't believe these issues are relevant, so I'm satisfied that all other tests working fine mean that the project will pretty much work out of the box for end users - at worst their container won't work, but that's not our responsibility to test for. Could you all contribute a bit to get all projects show "green" on this page? Some "workarounds" you might want to apply: - the Logger interfaces won't compile because of a known issue, this can be worked around for now by having the compilation phase also explicitly depend on this artifact: https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L878-L883 - you'll have a ClassNotFoundException on JAXB usage unless you set this JVM flag: https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L1429 (This one is not a bug but will be required to be set by end users as well - or we provide our own XML parser, that might be more user friendly). As far as I know, other issues with the build tools have been solved already - including Gradle. Thanks, Sanne ___ 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
Re: [hibernate-dev] Revert API change in org.hibernate.Query
On 7 June 2016 at 13:41, Steve Ebersole wrote: > If you send a PR I will include it. Thanks Steve, I finally got to it: - https://hibernate.atlassian.net/browse/HHH-10839 - https://github.com/hibernate/hibernate-orm/pull/1418 > > On Sun, Jun 5, 2016 at 11:00 AM Sanne Grinovero wrote: >> >> I just noticed that the org.hibernate.Query interface was deprecated >> in 5.2, with the suggestion to use org.hibernate.query.Query now. >> That's ok, but it seems the "deprecation process" also forced some API >> changes already on the deprecated interface which seem might have been >> unintentional. >> >> The builder methods on org.hibernate.Query used to allow returning >> "this" to chain methods, >> although this seems no longer possible as the API now declares the >> return type should be the new one, org.hibernate.query.Query. >> >> Could we fix this by relaxing the return to the older deprecated method? >> >> in practice: >> >> org.hibernate.query.Query setFirstResult(int startPosition); >> >> should be: >> >> org.hibernate.Query setFirstResult(int startPosition); >> >> Thanks, >> Sanne >> ___ >> 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
Re: [hibernate-dev] Eclipse Che - quickstart for Hibernate contributions?
Hi Sanne, sorry for missing this mail - fell into my "read when on long flights"-folder. Those projects are setup by volunteers using Che and then shared. I've cc'ed you in a thread/mail to them on this subject - I'm also meeting with them this week so might get a more direct answer there. /max > Hi Max, > > I just noticed that several popular open source projects, including > our "sister projects" WildFly and Vert.X have some kind of public > workspace to help people getting started to contribute: > > http://www.eclipse.org/che/getting-started/ > > Would you know what it would take to include some of our projects > there? > > Thanks, > Sanne /max http://about.me/maxandersen ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Java 9: progress on compatibility
Hey, I hit the same issue with the injection plug-in in HV. It was used for obtaining the version of HV at runtime. I worked around it by obtaining that from the package instead [1]: return SomeHvClass.class.getPackage().getImplementationVersion(); If that's all what the injection plug-in is used for in ORM as well (and you don't depend on that version info e.g. during testing in the IDE, where there is no JAR manifest yet which is the source of the version with that approach), you could do the same there. --Gunnar [1] https://github.com/hibernate/hibernate-validator/commit/8a0eb0bfbc7610ea6fc9962eef024a98c3f9468c#diff-963bab11ed76f80c4a804903ed66e03fR34 2016-06-12 22:18 GMT+02:00 Sanne Grinovero : > Some more progress by simply setting this environment variable: > > GRADLE_OPTS="-XaddExports:java.security.sasl/com.sun.security.sasl.digest=ALL-UNNAMED > -XaddExports:java.security.sasl/com.sun.security.sasl=ALL-UNNAMED > -XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED > -XaddExports:jdk.unsupported/sun.reflect=ALL-UNNAMED -addmods > java.xml.bind" > > But it's getting tricky: > > Caused by: compile error: javassist.NotFoundException: java.lang.String >at javassist.compiler.Javac.compileBody(Javac.java:229) >at javassist.CtBehavior.setBody(CtBehavior.java:438) >... 76 more > > This seems to be caused by the following plugin, which I'm not familiar > with: > - > org.hibernate.build.gradle.inject.InjectionAction.execute(InjectionAction.java:62) > Is this something which we could disable/skip/remove for now, or > update to not require Javassist? > > Thanks, > sanne > > On 12 June 2016 at 20:56, Sanne Grinovero wrote: > > On 11 June 2016 at 18:47, Sanne Grinovero wrote: > >> On 11 June 2016 at 18:25, Steve Ebersole wrote: > >>> The ORM failure seems to be a Gradle/JDK9 issue. Any idea about that? > >> > >> Not sure, that's a new one :) > >> It could be related to https://issues.gradle.org/browse/GRADLE-3287 ? > >> > >> Might be worth trying to upgrade to Gradle 2.12 .. I'm not at a > >> terminal at the moment, I could try later. > > > > I've upgraded to Gradle 2.13, the pull request is here: > > - https://github.com/hibernate/hibernate-orm/pull/1417# > > > > It solved that specific issue, but it's not enough. I'm still trying > > to hack a workaround for the next step, but in the meantime that PR > > could be considered independently. > > > > I could use some pointers with Gradle and the custom plugins we use; > > essentially we need to pass some additional JVM flags, including to > > javac, like here: > > - > https://github.com/hibernate/hibernate-orm/commit/5e6a8ea754e3c4c59925fe7f824092490efc008b > > > > But the failure happens during: > > Execution failed for task ':hibernate-core:xjc' > > > > and I'm not sure how to override the JVM flags for that plugin execution. > > > > Thanks, > > Sanne > > > > > >> > >>> > >>> On Fri, Jun 10, 2016, 4:39 PM Sanne Grinovero > wrote: > > Hi all, > please try to have a look at this page when you have a moment: > - http://ci.hibernate.org/view/JDK9/ > > Hibernate Search is working, and it shouldn't be too hard to get the > others "green" as well. > > I've disabled some integration tests to get there, notably: > - OSGi tests: Karaf is not ready for it. > - Documentation build: Asciidoc will probably need an update. > - WildFly integration tests: the WildFly team is aware, will need a > minor upgrade. > > I don't believe these issues are relevant, so I'm satisfied that all > other tests working fine mean that the project will pretty much work > out of the box for end users - at worst their container won't work, > but that's not our responsibility to test for. > > Could you all contribute a bit to get all projects show "green" on > this > page? > > Some "workarounds" you might want to apply: > - the Logger interfaces won't compile because of a known issue, this > can be worked around for now by having the compilation phase also > explicitly depend on this artifact: > > > https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L878-L883 > - you'll have a ClassNotFoundException on JAXB usage unless you set > this JVM flag: > > https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L1429 > (This one is not a bug but will be required to be set by end users as > well - or we provide our own XML parser, that might be more user > friendly). > > As far as I know, other issues with the build tools have been solved > already - including Gradle. > > Thanks, > Sanne > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ > hibernate-dev mai
