[hibernate-dev] improved Eclipse project support

Steve Ebersole steve at hibernate.org
Fri May 3 08:16:11 EDT 2013


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 <steve at hibernate.org
> <mailto:steve at 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.ebersole at gmail.com
>>     <mailto:steven.ebersole at 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 at gmail.com
>>             <mailto:steven.ebersole at gmail.com>
>>             <mailto:steven.ebersole at gmail.com
>>             <mailto:steven.ebersole at 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 at hibernate.org
>>             <mailto:gunnar at hibernate.org>
>>                     <mailto:gunnar at hibernate.org
>>             <mailto:gunnar at hibernate.org>>
>>                     <mailto:gunnar at hibernate.org
>>             <mailto:gunnar at hibernate.org>
>>             <mailto:gunnar at hibernate.org
>>             <mailto:gunnar at hibernate.org>>>>
>>
>>
>>                         2013/4/15 Steve Ebersole
>>             <steven.ebersole at gmail.com <mailto:steven.ebersole at gmail.com>
>>                     <mailto:steven.ebersole at gmail.com
>>             <mailto:steven.ebersole at gmail.com>>
>>                         <mailto:steven.ebersole at gmail.
>>             <mailto:steven.ebersole at gmail.>__com
>>
>>                     <mailto:steven.ebersole at gmail.com
>>             <mailto:steven.ebersole at 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 at redhat.com <mailto:brmeyer at redhat.com>
>>                     <mailto:brmeyer at redhat.com
>>             <mailto:brmeyer at redhat.com>>
>>                                 <mailto:brmeyer at redhat.com
>>             <mailto:brmeyer at redhat.com>
>>
>>                     <mailto:brmeyer at redhat.com
>>             <mailto:brmeyer at 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 at lists.jboss.org
>>             <mailto:hibernate-dev at lists.jboss.org>
>>                     <mailto:hibernate-dev at lists.jboss.org
>>             <mailto:hibernate-dev at lists.jboss.org>>
>>                                     <mailto:hibernate-dev at lists.
>>             <mailto:hibernate-dev at lists.>__jboss.org <http://jboss.org>
>>                     <mailto:hibernate-dev at lists.jboss.org
>>             <mailto:hibernate-dev at 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 at lists.jboss.org
>>             <mailto:hibernate-dev at lists.jboss.org>
>>                     <mailto:hibernate-dev at lists.jboss.org
>>             <mailto:hibernate-dev at lists.jboss.org>>
>>                                 <mailto:hibernate-dev at lists.
>>             <mailto:hibernate-dev at lists.>__jboss.org <http://jboss.org>
>>                     <mailto:hibernate-dev at lists.jboss.org
>>             <mailto:hibernate-dev at 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>__>
>>
>>
>>
>>
>>
>
>


More information about the hibernate-dev mailing list