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
