Re: [hibernate-dev] ORM Jenkins Builds

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(a)hibernate.org&gt; 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(a)hibernate.org&gt; > wrote: > >> On Sat, Mar 28, 2015 at 11:26 AM, Sanne Grinovero <sanne(a)hibernate.org&gt; >> 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. >> >> > >