[hibernate-dev] ORM Jenkins Builds

[Steve Ebersole]

The reason I ask is that it might be better to point the
non-hibernate-java8 modules to use the Java 6 javac when this JDK6_HOME is
set.  So...

1) Running Gradle with Java 8, JDK6_HOME set -> we'd compile all the
non-hibernate-java8 modules setting
JavaCompile#options#forkOptions#executable to the Java 6 javac.  Tests
would still run using Java 8 (although we could adjust that too if we want).

2) Running Gradle with Java 8, JDK6_HOME not set -> everything is compiled
and tests run with Java 8

3) Running Gradle with Java 6 or 7 -> (irrelevant whether JDK6_HOME is
set); hibernate-java8 is not even included in the project

On Mon, Mar 30, 2015 at 6:53 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Does Eclipse have the ability, like IntelliJ does, to define a different
> JDK for each module in a multi-module project?
>
> On Sat, Mar 28, 2015 at 2:10 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Gradle really is quite elegant in most cases:
>>
>> if ( project.name != 'hibernate-java8' && rootProject.hasProperty(
>> "JDK6_HOME" ) ) {
>> final File java6Home = new File( rootProject.property( "JDK6_HOME" ) as
>> String );
>> final org.gradle.internal.jvm.Jvm java6Jdk =
>> org.gradle.internal.jvm.Jvm.forHome( java6Home ) as
>> org.gradle.internal.jvm.Jvm;
>> if ( !java6Jdk.javaVersion.java6 ) {
>> throw new GradleException( "JDK6_HOME (if set) must point to a Java 1.6
>> home, found ${java6Jdk.javaVersion}" );
>> }
>> final Test mainTestTask = subProject.tasks.test as Test;
>> task testWithJdk6(type:Test) {
>> inputs = mainTestTask.inputs
>> outputs = mainTestTask.outputs
>>
>> if ( java6Jdk.toolsJar ) {
>> bootstrapClasspath java6Jdk.toolsJar
>> }
>>
>> classpath = java6Jdk.runtimeJar + mainTestTask.classpath
>> executable = java6Jdk.javaExecutable
>>
>> // should we recompile the tests using JDK6?  If so, set a different
>> classes dir
>> // here and clone new JavaCompile task for tests.  But just running with
>> the Java 6
>> // JRE should be enough
>> testClassesDir = mainTestTask.testClassesDir
>> testSrcDirs = mainTestTask.testSrcDirs
>>
>> enableAssertions = mainTestTask.enableAssertions
>> environment = mainTestTask.environment
>> systemProperties = mainTestTask.systemProperties
>> scanForTestClasses = mainTestTask.scanForTestClasses
>> includes = mainTestTask.includes
>> excludes = mainTestTask.excludes
>> jvmArgs = mainTestTask.jvmArgs
>> maxHeapSize = mainTestTask.maxHeapSize
>> minHeapSize = mainTestTask.minHeapSize
>> }
>> }
>>
>> On Sat, Mar 28, 2015 at 11:46 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> On Sat, Mar 28, 2015 at 11:26 AM, Sanne Grinovero <sanne at hibernate.org>
>>> wrote:
>>>>
>>>> Consider also that since we now have N slaves, there is no guarantee
>>>> that a second job will run on the same build slave.
>>>> So if the JDK8 build produces artifacts but only deployes them in the
>>>> local repository, the second node might not find the same as it has an
>>>> independent repository cache.
>>>>
>>>
>>> This is one of the major differences between Gradle and Maven.  Gradle
>>> has no idea about a "local repository" in terms of publishing.  These jobs,
>>> if they publish, always publish to Nexus.
>>>
>>> We added the ability to read artifacts from "Maven local" mainly to deal
>>> with cases where we have local Maven-built projects that we want to have
>>> ORM pick up a local snapshot of.  HCANN was the main thing here.  But the
>>> "Gradle way" is to have the "other" local project (e.g., HCANN) publish its
>>> SNAPSHOT to Nexus and for the ORM build to pick it up from there.
>>>
>>> More repeatable builds that way.  You pointed out one such scenario.  Of
>>> course locally, Gradle (with some help usually) also lets you aggregate
>>> these disparate projects together into one cohesive build.
>>>
>>> And given that IIRC I converted HCANN to use Gradle for building as
>>> well, maybe its time to pull that ability.
>>>
>>>
>>> One way would be to actually upload the snapshots to the jboss Nexus,
>>>> but it could be easier / more efficient to have a single job which
>>>> does the compilation & packaging only with JDK8 but then runs the
>>>> tests with JDK6 ?
>>>> The JDK paths are well defined, so that should be scriptable with a
>>>> couple of sequential invocations to Gradle?
>>>
>>>
>>> That is another option for sure.  And actually it does not even have to
>>> be separate invocations.  We could script the creation of a new Test task
>>> based on the configured JDK6 path and just have both run in the same Gradle
>>> build.
>>>
>>>
>>
>>
>