2013/4/17 Steve Ebersole <st...@hibernate.org> > I think it would be great if you wanted to try including this in the ORM > build. Worst case you could just use the sniffer ant tasks from Gradle. >
I'll give it a try. > On 04/16/2013 09:44 AM, Gunnar Morling wrote: > > 2013/4/16 Steve Ebersole <steven.ebers...@gmail.com> > >> What is "configured JDK baseline"? Do you have to point to a JDK path? >> If so, no difference than just setting the javac bootstrap option to a >> local path. > > > No, you don't point to another JDK path, you use the JDK you are on, > i.e. Java 7. You just say which JDK version you want to target, e.g. 1.6. > In the HV case, the config is this: > > <plugin> > <groupId>org.codehaus.mojo</groupId> > <artifactId>animal-sniffer-maven-plugin</artifactId> > <version>1.9</version> > <configuration> > <signature> > <groupId>org.codehaus.mojo.signature</groupId> > <artifactId>java16</artifactId> > <version>1.0</version> > </signature> > </configuration> > </plugin> > > The referenced signature artifact contains the API signature for that > JDK version, i.e. all Java 1.6 methods, public fields etc. If your code > uses a method which is not part of that API signature, the plug-in will > fail the build. > > That is, you still use the Java 7 API to compile against, but the > plug-in makes sure you use only those parts of the API which where there > already as of Java 6. So this emulates building against Java 6, but without > the hassle of handling several actual JDKs, setting up the boot classpath > etc. > > > >> >> >> On Tue 16 Apr 2013 08:38:37 AM CDT, Gunnar Morling wrote: >> >>> In HV, we use the Animal Sniffer plug-in [1] for that purpose. >>> >>> This checks the code base against a configured JDK baseline and fails >>> the build, when e.g. using a method which is not part of the targeted >>> JDK release. In other words, you still use your current JDK for >>> building (avoiding any bootstrap path fiddling) but make sure you >>> invoke only those parts of the API which are also available in the >>> targeted Java version. >>> >>> Together with the source/target level correctly set, this allows to >>> safely compile with newer JDK versions and still be sure that the code >>> e.g. runs on 6. >>> >>> We use the Maven plug-in, but via the Ant task, this should also be >>> usable for Gradle builds. If you like me to, I can give this a try for >>> ORM. >>> >>> --Gunnar >>> >>> [1] http://mojo.codehaus.org/animal-sniffer/index.html >>> >>> >>> 2013/4/16 Steve Ebersole <steven.ebers...@gmail.com >>> <mailto:steven.ebers...@gmail.com>> >>> >>> >>> Mainly thats an issue with that fact that so far we have not >>> defined 'bootstrap class path' option to javac to go along with >>> the source/target compatibility settings. The difficulty is that >>> defining bootstrap for javac becomes very system specific (it >>> needs to name a path). Sure we could externalize that into a >>> setting, but then what do you do when someone wants to build >>> Hibernate but has not defined this setting? Do you let the build >>> continue (aka, make the bootstrap setting optional)? >>> >>> Bottom line, just setting source/target compatibility is never >>> enough. >>> >>> >>> On Tue 16 Apr 2013 03:44:29 AM CDT, Gunnar Morling wrote: >>> >>> On a related note: >>> >>> I know Java 7 is required to compile ORM, but is Java 7 also the >>> required runtime Java version now (I vaguely remember a related >>> discussion around the JPA API JAR)? >>> >>> I'm asking, because the Java 7 method >>> Collections#emptyIterator() is >>> used at two places, making this code not runnable on Java 6. If >>> requiring 7 is intentional, feel free to ignore this mail ;) >>> >>> --Gunnar >>> >>> >>> >>> 2013/4/16 Gunnar Morling <gun...@hibernate.org >>> <mailto:gun...@hibernate.org> >>> <mailto:gun...@hibernate.org <mailto:gun...@hibernate.org>>> >>> >>> >>> 2013/4/15 Steve Ebersole <steven.ebers...@gmail.com >>> <mailto:steven.ebers...@gmail.com> >>> <mailto:steven.ebersole@gmail.__com >>> >>> <mailto:steven.ebers...@gmail.com>>> >>> >>> >>> I am not touching this :) >>> >>> I think I have explained this 198,052 times thus far lol >>> >>> >>> I must have missed this then. Or I was not yet part of the >>> team at >>> that time. >>> >>> >>> https://community.jboss.org/____wiki/GradleWhy >>> <https://community.jboss.org/__wiki/GradleWhy> >>> >>> >>> <https://community.jboss.org/__wiki/GradleWhy >>> <https://community.jboss.org/wiki/GradleWhy>> see #4 >>> >>> >>> Thanks for the link. >>> >>> I get the reasoning about Maven's "one artifact" rule and >>> the need >>> for re-usable test code. But now that we use Gradle, >>> wouldn't it >>> be possible to move the things from hibernate-testng back to >>> hibernate-core and built two JARs with the different >>> contents from >>> there? To me, a circular dependency between two modules >>> always >>> seems a bit suspicious, also if it is doable with Gradle, >>> turning >>> off warnings in the IDE etc. >>> >>> Btw. also Maven supports this particular use case of >>> creating a >>> main JAR and a JAR with re-usable test infrastructure [1]. >>> We e.g. >>> make use of this in HV. >>> >>> --Gunnar >>> >>> [1] >>> >>> http://maven.apache.org/__plugins/maven-jar-plugin/test-__jar-mojo.html >>> >>> < >>> http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html> >>> >>> >>> On Mon 15 Apr 2013 04:10:43 PM CDT, Gunnar Morling wrote: >>> >>> Hi Brett, >>> >>> That's good news, thanks for your efforts. Based >>> on step 3 >>> from your blog >>> post it seems as there still is a circular dependency >>> between some of the >>> modules/projects. Just out of interest, could you >>> give >>> some more details >>> why this kind of setup is required? >>> >>> --Gunnar >>> >>> >>> >>> 2013/4/15 Brett Meyer <brme...@redhat.com >>> <mailto:brme...@redhat.com> >>> <mailto:brme...@redhat.com >>> >>> <mailto:brme...@redhat.com>>> >>> >>> >>> There's been several complaints about ORM's use >>> of >>> Gradle not generating >>> Eclipse projects correctly. This was recently >>> cleaned >>> up in HHH-7617 [1]. >>> FYI, there's a quick blog post [2] about how to >>> quickly get >>> up-and-running. Please let me know if there >>> are any >>> further ways we could >>> streamline the IDE setup. >>> >>> [1] >>> https://hibernate.atlassian.____net/browse/HHH-7617 >>> >>> >>> <https://hibernate.atlassian.__net/browse/HHH-7617 >>> <https://hibernate.atlassian.net/browse/HHH-7617>> >>> [2] >>> >>> http://in.relation.to/____Bloggers/____ImprovedEclipseProjectSupportF____orHibernateORMDevelopment >>> < >>> http://in.relation.to/__Bloggers/__ImprovedEclipseProjectSupportF__orHibernateORMDevelopment> >>> >>> >>> >>> >>> < >>> http://in.relation.to/__Bloggers/__ImprovedEclipseProjectSupportF__orHibernateORMDevelopment >>> < >>> http://in.relation.to/Bloggers/ImprovedEclipseProjectSupportForHibernateORMDevelopment >>> >> >>> >>> Brett Meyer >>> Red Hat Software Engineer, Hibernate >>> >>> ___________________________________________________ >>> >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> <mailto:hibernate-dev@lists.jboss.org> >>> <mailto:hibernate-dev@lists.__jboss.org >>> <mailto:hibernate-dev@lists.jboss.org>> >>> https://lists.jboss.org/____mailman/listinfo/hibernate-dev >>> <https://lists.jboss.org/__mailman/listinfo/hibernate-dev> >>> >>> <https://lists.jboss.org/__mailman/listinfo/hibernate-dev >>> <https://lists.jboss.org/mailman/listinfo/hibernate-dev>__> >>> >>> ___________________________________________________ >>> >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> <mailto:hibernate-dev@lists.jboss.org> >>> <mailto:hibernate-dev@lists.__jboss.org >>> <mailto:hibernate-dev@lists.jboss.org>> >>> https://lists.jboss.org/____mailman/listinfo/hibernate-dev >>> <https://lists.jboss.org/__mailman/listinfo/hibernate-dev> >>> >>> <https://lists.jboss.org/__mailman/listinfo/hibernate-dev >>> <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
