Re: [hibernate-dev] improved Eclipse project support

2013/4/16 Steve Ebersole <steven.ebersole(a)gmail.com <mailto:steven.ebersole@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.ebersole(a)gmail.com <mailto:steven.ebersole@gmail.com> <mailto:steven.ebersole@gmail.com <mailto:steven.ebersole@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 <gunnar(a)hibernate.org <mailto:gunnar@hibernate.org> <mailto:gunnar@hibernate.org <mailto:gunnar@hibernate.org>> <mailto:gunnar@hibernate.org <mailto:gunnar@hibernate.org> <mailto:gunnar@hibernate.org <mailto:gunnar@hibernate.org>>>> 2013/4/15 Steve Ebersole <steven.ebersole(a)gmail.com <mailto:steven.ebersole@gmail.com> <mailto:steven.ebersole@gmail.com <mailto:steven.ebersole@gmail.com>> <mailto:steven.ebersole@gmail. <mailto:steven.ebersole@gmail.>__com <mailto:steven.ebersole@gmail.com <mailto:steven.ebersole@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 <brmeyer(a)redhat.com <mailto:brmeyer@redhat.com> <mailto:brmeyer@redhat.com <mailto:brmeyer@redhat.com>> <mailto:brmeyer@redhat.com <mailto:brmeyer@redhat.com> <mailto:brmeyer@redhat.com <mailto:brmeyer@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____... <http://in.relation.to/__Bloggers/__ImprovedEclipseProjectSupportF__orHibe... <http://in.relation.to/__Bloggers/__ImprovedEclipseProjectSupportF__orHibe... <http://in.relation.to/Bloggers/ImprovedEclipseProjectSupportForHibernateO... Brett Meyer Red Hat Software Engineer, Hibernate ___________________________________________________ hibernate-dev mailing list hibernate-dev(a)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(a)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>__>