[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