[hibernate-dev] improved Eclipse project support

Gunnar Morling gunnar at hibernate.org
Wed Apr 17 08:58:49 EDT 2013


2013/4/17 Steve Ebersole <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.
>

I'll give it a try.


> On 04/16/2013 09:44 AM, Gunnar Morling wrote:
>
> 2013/4/16 Steve Ebersole <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>>
>>>
>>>
>>>     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>>>
>>>
>>>
>>>             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>>>
>>>
>>>
>>>                 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>>>
>>>
>>>
>>>                         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>>
>>>         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>>
>>>         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