[hibernate-dev] ORM Jenkins Builds

[Steve Ebersole]

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.
>>
>>
>
>