I hope this won't come off as flame bait, because it's not. I'm new to
Jazz/RTC over the last couple of weeks and in general am very impressed,
with the sole exception being the Jazz Build Engine implementation. I'm
posting this critique of the JBE in the hope that I'm misunderstanding it,
or that these issues have already been hashed out and there's a new version
in the works, or something. So:

1. Why doesn't JBE "listen" for build jobs rather than polling for new
requests every so many seconds? Polling is generally an antipattern.

2. Why is it so deliberately command-line? Don't get me wrong, I like
command-line programs, but once you have such a program it should be
pretty easy to provide ways to wrap it up as a service (Windows) or daemon
(Linux). True, by the same token users could do the same but that means
each user site reinventing the wheel with a lack of standardization. Not
to mention that individual hacks tend to make upgrades more painful. And
if not wrapped as a service, a manually-started build engine will be down
so frequently as to make scheduled builds unreliable.

3. Why, of all the RTC components, is the JBE implemented with native
code? After all, Java is as capable of forking random sub-processes as the
next language. Although officially RTC supports only Windows and Linux,
I've had little trouble getting both server and client running on Solaris
and Mac, which is simply Java fulfilling its promise. Only the JBE is
restricted to supported platforms by the presence of compiled code. Why,
after all the resources IBM has poured into Java over the years, provide a
brilliantly-designed 100% pure Java platform only to hobble it with one
small piece of native code?

Upon closer inspection it looks like JBE is a standalone Eclipse-based
tool. So maybe the solution would be to provide it as a plugin as well?
This would allow it to be run on any system which supports Eclipse.

4. Of course the JBE - in general - must run as a separate process in
order to allow jobs to be farmed out to a standalone build server. But why
not, as a special case, allow builds to be run locally without all the
overhead entailed in starting up a build engine? In other words, why can't
the JVM in which the RTC client is running be capable of forking off the
build job locally instead of shipping it off to JBE? Possibly this would
"just work" if JBE was available as a plugin?

If this has all been talked out before, my apologies and please point me
to those discussions. I did take a quick look at the 2.0 roadmap and
didn't see anything about build engine work.

Thanks,
DSB

Donald Weinand wrote:
Hopefully these help answer your questions:

Yes, they help a lot, thank you. One of the key things I didn't understand
is that JBE is intended as an entry level builder and that more advanced
systems can be plugged in. This puts the whole issue in a better
perspective. Sorry for missing that.

A few follow-on comments are inline.

1) JBE is a client app, requiring no open ports for simplicity. It's
meant to be an entry level build engine, on par with cruisecontrol (but
really even simpler). Even if JBE listened for a job, this does not
eliminate the polling. What process would then contact JBE with the work?
You would still need code then running somewhere (maybe the Jazz server)
on a timer to check for new requests and send them to the JBE. Having
the JBE be client-only just simplifies this. There is also an
enhancement(54073) request related to remote controlling the JBE.

I think I understand now - you don't want the server to have to keep track
of what build engines are out there and on what ports they're listening?
Presumably there would be some authentication issues with the "push" model
too. So the server just puts build requests in a queue and the JBE pulls
them off the next time it checks in? This makes much more sense, but can
you guard against multiple build engines "poaching" build requests from
each other?

2) There is a wiki topic that explains how to run it as a service. We
explored the idea of including that functionality ourselves but then
decided not to because there were so many providers of that functionality
already. This wiki topic describes using one of the many that are
available. https://jazz.net/wiki/bin/view/Main/JbeAsAWindowsService

Ok, but note that while the wiki is quite helpful, the "official"
documentation (e.g.
http://publib.boulder.ibm.com/infocenter/rtc/v1r0m1/index.jsp and
https://jazz.net/learn/LearnItem.jsp?href=content/docs/build-setup/index.html)
is silent on the ability to run it as a service. Not everyone will know
that they have the option, so it would be helpful to add something like
what's at the top of the wiki page "There is no direct support for running
JBE as a windows service. However, there are several service wrappers for
java available...".

3) JBE has no native code. The jbe.exe launcher is exactly the
eclipse.exe launcher renamed as is the convention for RCP apps. The
launcher is not required, but a convenience for linux/windows. You should
be able to run it on any platform that has a Java 5.0 VM. See the wiki
topic: https://jazz.net/wiki/bin/view/Main/JbeOtherPlatforms

Thanks for the pointer, this solves the most pressing concern. My personal
feeling is that the launcher is more trouble than it's worth; given that
the command line, even when using the launcher, is so long that it would
generally be wrapped up in a script, why not just document the full
command line required to run it directly and strip the native code out?
But as long as direct Java access is available my requirements are
satisfied.

4) JBE is intended to support a team's continuous build running on
dedicated build machine. Running a build locally isn't usually going to
work in most teams because of the elaborate setup that most real world
build scripts have and the need for it to be up 24/7. I also highly
doubt you really want a long running, resource intensive build process
running in the console of your RTC session that slows down performance
and is blown away if you restart your RTC client. I know as a day to day
developer working in RTC I definitely don't want our continuous build
running within my IDE. The build toolkit however is included as a plugin
in the RTC client so if you have an ant script you want to test that
includes any of our tasks they can be run within the Eclipse ant runner
framework.

Granted, in production use you would almost always want to push the build
to a dedicated server (as I noted in my original message). But for
_developing_ builds the shortcut path could be handy. In my experience
when developing a new build model the first N builds generate little load
because they fail quickly, and in any case the load they generate isn't a
problem because fixing the build is the current work item, not a
background task. The short path could also be useful for demos and
tutorials. But I'm just thinking out loud now - once I figure out how I
might file an RFE.

-David