An Eclipse DemoCamp is a congregation of Eclipse enthusiasts to meet up and demo what they are doing with Eclipse. The demos can be of research projects, Eclipse open source projects, applications based on Eclipse, commercial products using Eclipse or whatever you think might be of interest to the attendees. The only stipulation is that it must be Eclipse related.

Earlier you’d go get a coffee every time you clicked the eclipse update manager. With the eclipse servers taking a beating and download speeds really going slow you better grab lunch.

But wait there’s another nifty “hack”: Don’t talk to the eclipse servers.

To make the p2 update manager faster (assuming you aren’t downloading from the eclipse mirror sites):

• Edit your hosts file (/etc/hosts or c:\windows\system32\drivers\etc\hosts)
• Add a fake alias for the download server:

  127.0.0.10 download.eclipse.org
  

Open the update manager again, enjoy the amazing speeds, remember to remove the line if you indeed want to talk to the eclipse servers.

Download the jruby source zip, extract it and open the build.xml file, search for “rspec” (there’s two occurences) and you’ll find that it’s passed in as an argument to the gem installer, add in another line with “cucumber”:

<target name="install-gems">
  <property name="jruby.home" value="${basedir}"/>
  <java classname="org.jruby.Main" fork="true" maxmemory="${jruby.launch.memory}" failonerror="true">
    <classpath refid="build.classpath"/>
    <classpath path="${jruby.classes.dir}"/>
    <sysproperty key="jruby.home" value="${jruby.home}"/>
    <arg value="--command"/>
    <arg value="maybe_install_gems"/>
    <arg value="rspec"/>
    <arg value="rake"/>
    <arg value="cucumber"/> <!-- add cucumber -->
    <arg value="--env-shebang"/>
  </java>
</target>

Then run ant:

$ ant jar-complete

To verify that everything is fine:

$ java -jar lib/jruby-complete.jar -S gem list

*** LOCAL GEMS ***

builder (2.1.2)
cucumber (0.2.3)
diff-lcs (1.1.2)
polyglot (0.2.5)
rake (0.8.4)
rspec (1.2.2)
sources (0.0.1)
term-ansicolor (1.0.3)
treetop (1.2.5)

Great we’ve now managed to package jruby-in-a-jar with some additional gems. Now to run cucumber on jruby in eclipse.

The process be praised!

However there are times when you’re making major changes and the ‘commit’ phase in the cycle could break everybody else’s work, but you still need to check in! Here’s how mercurial (or even git) can help:

Checkout the initial sources from CVS(or svn) using eclipse.
$ cvs -d :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse co -P "pde/ui"

Navigate to the directory containing the workspace and initialize the mercurial repository:
$ cd ~eclipse
$ hg init
# see below for .hgignore
$ vi .hgignore


Commit what you just checked out of cvs:
$ hg addremove
$ hg commit -m "initial import from cvs"


Here’s a .hgignore that worked for me:

CVS
.*/bin
.DS_Store
.cvsignore
.metadata


Clone the initial import

We will not work in this checked out copy, instead we will clone it. The checked out copy will always track upstream CVS and will contain CVS metadata:
$ hg clone ~eclipse ../eclipse-working-copy

Now we switch workspace to ../eclipse-working-copy (both in eclipse and the command line) and keep checking in as and when needed:
$ cd ../eclipse-working-copy
$ echo "Hello World" >>| org.eclipse.pde/README.txt
$ hg addremove
$ hg commit -m 'minor changes towards adding foo-bar support'

We’ve now checked in a few changes into our working copy, time to push them into the CVS copy:
$ hg push

This pushed the changes in the upstream repository, but the working copy in upstream does not contain the local changes:
$ cd ~eclipse
$ hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg log
changeset: 1:373d70bd13d6
tag: tip
user: ketanpadegaonkar@storm.corporte.thoughtworks.com
date: Sat Jan 24 10:53:27 2009 +0530
summary: minor changes towards adding foo-bar support

changeset: 0:ef6bc5b6d1db
user: ketanpadegaonkar@storm.corporte.thoughtworks.com
date: Sat Jan 24 10:24:20 2009 +0530
summary: initial import from cvs

Create a patch and send to bugzilla:
$ hg diff -r 0 > patch

Pulling from CVS into your eclipse-working copy is also similar, you do:
$ cd ~eclipse
$ cvs up
$ hg addremove
$ hg commit -m 'synced from cvs'
# goto the working copy, pull changes and apply them to the working copy
$ cd ../eclipse-working-copy
$ hg pull
$ hg update


I’d expect a ‘login’ link to be clearly visible on the eclipsecon website.

Here’s what I did:
1. Click on the “Propose a BoF” link
2. Look around for a login link that I can click, nothing
3. There is a ‘register’ link click on that, takes you to the same page
4. Nothing, open gmail and find a link to the submission system

I’ve filed a bug about this. The eclipsecon website could also use some love to improve usability.

 _________________________________________
/ How much net work could a network work, \
\ if a network could net work?            /
 -----------------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

SVN 1.5 has been around for a while now, and provides a range of new features that help improve the overall experience and makes SVN suck less.

I’ve opened this bug to request that projects that want to migrate to svn 1.5 at eclipse.org have the option to do so. The existing SVN is running on a SVN 1.4.0. Please drop in your comments on this bug.

Dependency injection over Service Locator.

Each one has their own baggage of merits and de-merits.

DI also adds to better design, so that classes do not start doing Platform.getExtensionRegistry().getConfigurationElementsFor(EXTENSION_POINT_ID).createExecutableExtension(myProperty) in the middle of nowhere, and there’s no way that I can start testing them unless the tests put something in the registry. Service Locator makes provisions for the some of the extensibility that eclipse needs. Injecting objects that locate services into objects that need these services seems to be a right thing to do:

Here’s an example of what we do: makes for easy testing because it is now possible to mock the interface out for testing the object.

public class FooBarFacade {
  public FooBarFacade(IConfigurationElement driver) {
    options = (IFooBarOptionsOptions) driver.createExecutableExtension(OPTIONS_EXTENSION_POINT);
    optionsComposite = (IFooBarOptionsComposite) driver.createExecutableExtension(OPTIONS_UI);
    optionsInitializer = (IFooBarInitializer) driver.createExecutableExtension(INITIALIZER);
  }
}

Interfaces with getter/setter methods

The other point that always strikes me in the API are some really huge interfaces with get/set methods. Clearly the interface/implementation is doing more than that, using abstract classes is probably a good thing to do in such cases (more so, if there’s going to be just one implementation of the interface anyway)

Why do we need getters and setters anyway ? Do they not break encapsulation ? There’s two schools of opinions I’ve come across here. One that likes to follow the javabeans specfications. The other that says hates getters and setters for the reason that objects then tell you who their friends are (Disclosure: I belong to such a group). Objects should expose behavior and not their friends that may help you out.

Law of Demeter

The Law of Demeter says “talk to your immediate friends”. getA().getB().getC().doSomething is probably a bad thing to do.

Don’t confuse your dog. Asking a dog to walk its legs is easier(and less confusing) than asking the dog for it’s legs and then making them walk.

Singletons and the law of demeter

I’m always having to do something like:

PlatformUI.getWorkbench().getActiveWorkbenchWindow().getWorkbench().doSomething();
IJavaProject p = JavaCore.create(ResourcesPlugin.getWorkspace().getRoot().getProject("foobar"));

So much so that I’ve now got templates for all such APIs. Why not just:

Workbench.getActiveWorkbench().doSomething();
IJavaProject p = JavaCore.createProject("foobar");

In Conclusion: How much API is “good enough” API ?

Returning the legs of a dog is an easier thing to do, and let clients manage the walking, but heck, I can’t imagine anything I’d want to do with a dog’s legs other than to walk, so I might was well want to ask the dog to walk itself.

This is certainly not a solved problem. I prefer to follow a simple rule. Provide just about enough API to make 80% of the users happy. Provide just about enough extensibility to make the other 20% happy, just in case someone wants to make the dog walk backwards!

Update site: http://swtbot.sourceforge.net/latest/update-site/

SWTBot 1.2.0 is the 3rd of the 1.x releases of SWTBot was released last night, and there have already been about 200 downloads by the time of writing this blog post.

SWTBot has always believed in release early release often mantra, and pushes out nightly builds out of CruiseControl. From the download stats I’m looking at, there are more downloads of the nightly build than the ‘stable’ available on the sourceforge mirrors.

The highlight of the release is support for view menus and view toolbar.

Thanks to the contributors and adoptors, for patches, criticism, and suggestions for improvement. The release has fixed about 42 issues.

Read more on the detailed release notes and the changelog.