On Sat, Mar 28, 2015 at 11:26 AM, Sanne Grinovero <sa...@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. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
