I'll take a look. Thanks Gunnar!
On Fri 03 May 2013 06:13:53 AM CDT, Gunnar Morling wrote: > Hi Steve, > > I've pushed some commits for using the Animal Sniffer plug-in to > discover the usage of Java 7 APIs to my fork [1]. This uses the Ant > task and fails the build when using methods not existent in Java 6 > such as emptyIterator(). > > I'm still in the process of testing this but thought it would be good > to get some early feedback since this is my first change to the ORM > build scripts. If you think the change is ok I'll create a PR for > this. I'm currently only checking the main classes, if you think test > classes should be checked as well that's easy to add. > > --Gunnar > > [1] https://github.com/gunnarmorling/hibernate-orm/compare/HHH-8219 > > > > 2013/4/17 Steve Ebersole <st...@hibernate.org > <mailto: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. > > > > On 04/16/2013 09:44 AM, Gunnar Morling wrote: >> 2013/4/16 Steve Ebersole <steven.ebers...@gmail.com >> <mailto: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> >> <mailto: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>> >> <mailto: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.ebers...@gmail.com >> <mailto:steven.ebers...@gmail.com>> >> <mailto:steven.ebersole@gmail. >> <mailto:steven.ebersole@gmail.>__com >> >> <mailto:steven.ebers...@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>> >> <mailto: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>> >> <mailto:hibernate-dev@lists. >> <mailto:hibernate-dev@lists.>__jboss.org <http://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>> >> <mailto:hibernate-dev@lists. >> <mailto:hibernate-dev@lists.>__jboss.org <http://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
