JBoss Tools: making it easier to build against a complex target platform

So you want to be a JBoss Tools developer? Awesome. Welcome to the family. SVN sources are here, JIRA's over here and there's cold beer in the fridge*.

But you say it's a pain in the tuchus to download over 25 zips or add a whole bunch of update sites and hope you get everything you need? Yeah, no argument there. If only there was an easier way to resolve all the dependencies you need to get building, much less to even RUN this stuff.

To make this process simpler, I've created a p2 repo (update site) from our target platform file, which has been recently updated to include Helios SR1 dependencies. You can track subsequent work in progress here: JIRA JBIDE-6982. You can also report any issues there too.

---

So, now, just add this single site** into your vanilla Eclipse 3.6.1 Classic (or a Helios SR1 bundle), uncheck the box for 'Group Items by Category' and you can install everything listed. For great justice.

---

Some handy links:

• Latest Target Platform Repo
• Archived Target Platform Repo
• Target Platform Definition File
• JBoss Tools SVN Sources
• JBoss Tools JIRA

---

Some handy HOWTOs:

• HOWTO build JBoss Tools (all or individual components) using Tycho
• HOWTO run JBoss Tools' tests (all or individual components) using Tycho
• HOWTO attach Eclipse's debugger to JUnit or SWTBot tests running w/ Tycho
• HOWTO convert from a .target into a repo
• HOWTO update a .target to include newer versions based on contents of a local repo
• HOWTO install from p2 repo(s) into Eclipse using p2.director script

---

* - Due to beer2peer limitations, YMMV.

** - I'm aware that the update site throws a 403 if you open it in a browser. I can't be arsed to generate an index.html just yet, nor are there categorized features. Because really, you don't need either - this site is only meant to be used by p2.

EclipseCon '09: B.Y.O.B.S.T.E.D

Karl reminded me tonight about a little bonus feature at this year's EclipseCon I hadn't previously heard about:

Bring Your Own Bag, Score Two Extra Drinks.

We are offering a Bring Your Own (Conference) Bag option this year. To save resources and have some fun, please bring a bag from your collection. There will be prizes for unique bags (oldest, from furthest away, etc.), and everyone who brings a bag will receive two extra drink tickets! [1]

This year at #EclipseCon, it's BYOB - bag, that is. Extra drink tix if you bring ur own bag from past shows. Best recycled ones get a prize. [2]

Is there anything better than free (as in beer)? BYOB and find out!

Beer-to-Peer Networking, Part 1

The following is an experiment in B2P networking, and an attempt to implement a cross-province UUBP transfer. (Aside: I had considered a cross-country experiment too, eg., Toronto to Porland, but I'm not sure how to implement such an idea, especially given the ever-tighter security policies at the US-Canada border. Any suggestions?)

I'd also like to say upfront that this experiment should not be construed as an irresponsible attempt to encourage others to mix beer (or any form of alcohol, really) w/ software development. Drinking and coding can lead to serious problems. Please, B2P responsibly.

While I realize I'm deviating from the spec, I've decided to implement using a more MDD-based approach, in that the message I plan to send via UUBP will not be an actual beer, but rather a model of a beer, which can then be extrapolated and ingested (and later digested!) at the receiving end.

Raw materials can be acquired from your nearest Beer Store and your office's mail room.

Required Materials

Next, the message is encapsulated for security using the "gift envelope" technique, which I presume won't cause licensing headaches or adoption problems as this technique is already widely used in the public domain.

Assembling the Inner Packet

Completed Inner Packet

Now, a second layer of encapsulation is required to ensure the packet can be properly delivered to its intended audience. While there is no real protection of malicious packet sniffing, this at least ensures that the casual observer won't want to intercept the packet. The procedure is very similar to the above, and so will be lest as an exercise for the reader.

With the completed packet, it was time to attempt delivery. The UUBP spec says nothing about transport methods, so I'll first try a web-based approach:

First Delivery Attempt

Unfortunately, even with a 20" monitor, the packet is too large to be sent via the web:

Delivery Attempt Failure

After this initial setback, it was decided to try a more conventional delivery mechanism. This Canada Post node will be employed to transfer the completed packet to its destination.

Second Delivery Attempt: Success!

The UUBP packet is now in transit via the B2P network. With any luck, its recipient will receive it in a couple of days and take some shots, er, photos to complete Part 2.

UPDATE: See Part 2.