Jason Greene wrote:
Any suggestions on what could do the above process? Will gradle or some ant task help us here?
Currently I don't see any best practice for any build system which does exactly this. Which is a bit baffling.
All definitions I've read on "continuous integration" really refer to integrating new code into the mainline, which assumes you have all sources in the tree. Left out of scope is the integration of prebuilt binaries, something we're leaning heavily towards nowadays.
Over the weekend and so far today I've been looking at Gradle and Ivy's dependency resolvers to see at which granularity we can define rules:
- For all org.jboss.ejb3.*, pull in the latest SNAPSHOT
- For all org.jboss.*, pull in the latest RELEASE
- For everything else, use the defined static dependencies
...etc. And be able to run a variety of build configurations on the same integration project to see how external runtime upgrades affect the mainline testsuite.
Using the ShrinkWrap project now as a prototype for seeing how this might fit together in practice. What I really need to do is figure out how to enable *real* CI, accounting for dependencies, in EJB3. I imagine the requirements would be very similar for AS7.
Some related discussion from #jboss-dev:
(02:10:08 PM) ALR: sebersole: Ping, wanna pick your brain on Gradle w.r.t. real CI.
(02:10:36 PM) ALR: Been reading Gradle docs and examples most of the morning.
(02:10:47 PM) sebersole: k
(02:11:00 PM) ALR: sebersole: Here's the use case:
(02:11:01 PM) sebersole: thats about where i stopped though
(02:11:05 PM) ALR: Ah, OK.
(02:11:13 PM) ALR: What I want to do is get a build which can:
(02:11:26 PM) ALR: 1) Build against static matrix of dependencies (we have this in Maven)
(02:11:55 PM) sebersole: no idea what "static matrix of deps" os
(02:11:57 PM) sebersole: i
(02:11:59 PM) sebersole: grrr
(02:12:00 PM) sebersole: is
(02:12:04 PM) ALR: 2) Send a switch or have an alternate build which can grab the latest *versioned* SNAPSHOT of a set of dependencies, without leaking in unversioned stuff transitively.
(02:12:28 PM) ALR: "static matrix of deps" == longwinded way of saying "dependencies" section of POM.
(02:12:36 PM) ALR: groupId:artifactId:version
(02:13:06 PM) sebersole: well the general concept is the kind of thing gradle excels at
(02:13:09 PM) lightguard_jp [~lightguar@166-70-166-98.ip.xmission.com] entered the room.
(02:13:17 PM) sebersole: haha just in time
(02:13:22 PM) lightguard_jp: lol
(02:13:23 PM) ALR: I summoned.
(02:13:26 PM) sebersole: ah
(02:13:27 PM) lightguard_jp: ALR told me to come in
(02:13:40 PM) ALR: Basically I hear about pluggable resolving in Gradle w/ Ivy backend
(02:13:49 PM) ALR: What I'd like is some example of how this works in practice.
(02:14:00 PM) ALR: So I can refine my use cases and see that everything fits.
(02:14:02 PM) sebersole: afaik pluggable means different sources
(02:14:07 PM) sebersole: maven repos
(02:14:11 PM) sebersole: ivy repos
(02:14:13 PM) sebersole: file systems
(02:14:15 PM) sebersole: etc
(02:14:15 PM) ALR: Well, it also means different resolution strategies.
(02:14:24 PM) ALR: Maven is "nearest first", fail.
(02:14:34 PM) ALR: "newest first" is nicer, though not always what you want.
(02:14:39 PM) ALR: Static == declared
(02:14:42 PM) lightguard_jp: You can create and use your own ivy resolver
(02:14:55 PM) ALR: lightguard_jp: Can I apply the resolver per-dependency?
(02:15:03 PM) ALR: Or is it applied per-project / build?
(02:15:22 PM) ALR: For instance in EJB3 builds I might always want the latest versioned snapshot.
(02:15:36 PM) sebersole: its applied per repo afaik
(02:15:37 PM) ALR: But bring in latest real releases of like Tx, JPA, etc
(02:15:37 PM) lightguard_jp: Per project, but you can explicitely declare deps and transitive deps
(02:15:53 PM) ALR: wolfc: ^
(02:16:05 PM) sebersole: lightguard_jp: but you can mix different types of repos in a project
(02:16:30 PM) sebersole: wouldnt each get its own resolver?
(02:16:52 PM) lightguard_jp: Um, I've never done that before, but it should work.
(02:17:00 PM) lightguard_jp: ALR: Here's the overview: http://www.gradle.org/latest/docs/userguide/dependency_management.html
(02:17:08 PM) ALR: lightguard_jp: Hehe, that's the one I've been reading.
(02:17:22 PM) ALR: It shows promise but doesn't quite hit all nails.
(02:17:50 PM) ALR: Basically I think it's a lot of what wolfc has done before using plain ol' Ant/Ivy
(02:17:56 PM) sebersole: i mean worst of all cases you could write a buildscript or init-script that alters the deps
(02:17:57 PM) lightguard_jp: What parts aren't there for you?
(02:18:30 PM) ALR: Applying resolution strategies per-dependency
(02:18:41 PM) ALR: Overriding the strategy as a build switch/property
(02:21:09 PM) lightguard_jp: You may be able to something like that using the ResolverContainer and adding a resolver: http://www.gradle.org/latest/docs/javadoc/org/gradle/api/artifacts/ResolverContainer.html
(02:24:56 PM) lightguard_jp: When you start talking resolvers though, you're in the realm of Ivy
(02:25:11 PM) ALR: Yep, that's fine.
(02:25:26 PM) ALR: I'm shocked this isn't a more standard requirement, to be honest.
(02:25:27 PM) ***lightguard_jp wishes Hans or Adam were here
(02:25:56 PM) ALR: Especially if you want to meet academic needs such as these http://martinfowler.com/articles/continuousIntegration.html
(02:26:19 PM) ALR: Not that Fowler's got the only way, but it's well-documented and fits my cases.
(02:26:44 PM) lightguard_jp: I know Hans said he did some work with snapshots a little while ago in gradle head, but I don't remember what. I'd have to dig through my logs
(02:26:55 PM) ALR: The idea of CI also gets hidden when you take sebersole's approach in hibernate
(02:27:08 PM) ALR: Which is a more simplified tree on a shared release cycle
(02:27:18 PM) ALR: It means less deps and less admin/management.
S,
ALR