Re: [hibernate-dev] improved Eclipse project support

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.ebersole(a)gmail.com&gt; > 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>> >> >> >> 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>>> >> >> >> 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>>> >> >> >> 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>>> >> >> >> 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>> >> 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>> >> 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>__> >> >> >> >> >>