This episode began with a discussion of automatically kicking off Jenkins builds based on upstream dependencies changing. I solved this problem by having Gradle <http://gradle.org> generate the ivy.xml which is committed in source repository and then using the Jenkins Ivy plugin work its magic. Having ivy.xml as a part of source control means more frequent trivial merges, but it is necessary to make Jenkins immediately recognize changed dependencies. It would be interesting to here if you could do the same thing with the Jenkins Maven plugin by generating the POM. Like other things in Jenkins, this strategy works well for building off of HEAD/tip, but requires extra tricks to build off of branches.
I heard some reluctance to embrace Ivy because of it allows too much freedom. My organization solved this by defining a small number of configurations in a project wide file that was included in each individual project file. When we later transitioned to Gradle, we encapsulated all this into project wide Gradle plugins. These semantically versioned plugins went further by enforcing policies like fail on conflicts, turning off transitive dependency resolution, requiring the developer to explicitly download updated artifacts, and controlling project wide dependencies on major 3rd party products (e.g., JUnit, Log4J, Tomcat, etc.). All this minimized and standardized both the build.gradle and generated ivy.xml. Another alternative is to use Gradle's multi-project builds - especially now that it supports parallel builds. It is unclear to me how this complements or competes with Jenkins. Our architecture centered around hundreds of OSGi bundles we aggregate into RPMs based on the higher level "feature" being addressed and provisioned by Chef to VMs based on the role of the VM. If I were to do this again, I'd strongly consider unit testing in an OSGi container using something like PaxExam <https://ops4j1.jira.com/wiki/display/PAXEXAM3/Pax+Exam> and using bndtools <http://bndtools.org/> to enforce conformance to semantic versioning during the build's commit phase. Even then, I'm hesitant to recommend OSGi because it seems to grow exponentially harder the more bundles you deploy. On the other hand, I'd highly recommend publishing RPMs and using Artifactory as a YUM repository. One major disconnect here is that is difficult to relate the artifacts in Artifactory with provisioning tools like Chef & Puppet. You can define version constraints on Chef cookbooks, RPMs, and other artifacts in your binary artifact repository. However, in practice, it is difficult to define a stable thread of versions from the VM down to the bundles because there are 3 different module systems being used. Thank you for the blessing your podcast has been to me. I hope that this small contribution helps someone and I'd love to hear of others related experiences. Mark -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To unsubscribe from this group and stop receiving emails from it, send an email to javaposse+unsubscr...@googlegroups.com. To post to this group, send email to javaposse@googlegroups.com. Visit this group at http://groups.google.com/group/javaposse. For more options, visit https://groups.google.com/groups/opt_out.
