Please add instructions for building from source using Eclipse 4.2 (Juno) #89

wants to merge 1 commit into


None yet

3 participants


The current instructions, in particular the part about installing the BIRT Charting Engine, refer to Eclipse 3.7. I'm using Eclipse 4.2, and there seem to have been some changes in the naming of things, also I'm not sure about possible compatibility issues.

Open questions:

  • Searching the BIRT 4.2 update site ( for "chart engine" returns no results. Searching for "chart", then for "engine" shows several confusing choices ("BIRT Chart Framework", "BIRT Chart OSGI Runtime SDK Feature", "BIRT Engine OSGI Runtime SDK Feature", and other permutations of buzzwords). Which items should I install (if any)?
  • If BIRT 4.2 is not compatible with building EclipseFP, what combination of installs should I use?
    • Eclipse 3.7 with BIRT Charting Engine 3.7
    • Eclipse 4.2 with BIRT Charting Engine 3.7
    • Any other version(s)?

I'm not an Eclipse wizard, and neither do I have the intention of becoming one. I just want an IDE for functional programming, and EclipseFP works well (in Eclipse 4.2) for that. I have spent more time trying to fix all kinds of weirdness in Eclipse than I'd care to admit, and in the time it would have taken me to fix them all, I could have easily constructed a complete proof of Fermat's Last Theorem (just joking!)
You get my drift (I hope) :-)


These are the steps I had to take to get the build to work on Eclipse 4.2, Arch Linux, OpenJDK 1.7.0_15:

  • Install "Eclipse Web Developer Tools" (can perhaps be massively minimized, but I didn't bother)
  • Add the BIRT 4.2 update site:
  • Install "BIRT Engine OSGi Runtime SDK Feature"
  • Build will now fail with build path error on the project. To fix this:
    • Remove 2 unresolved org.eclipse.swt*.jar entries from the build path
    • Add external JAR: ECLIPSE_HOME/plugins/org.eclipse.swt.<platform>.<version>.jar (actually, you will have to hunt for it using the file browser, replace <platform> and <version> with the relevant values for your installation).

This leaves me with 1 sole remaining build error, for which I will open a new issue.


Development page update with BIRT page and feature name. For the swt jars since the name of the jars depend on the version, I can't commit the changes otherwise it won't compile here. But that's only for a test module and does not impact the deliverables.


There is a better way of dealing with the SWT issue (taken from this): configure project's build path, using "Projects tab / Add", to require org.eclipse.swt project. This way the project's .classpath file contents will remain static and platform-independent, so users don't need to fix the build path after every Git pull.

Now, users only need to:

  • Download the SWT zip for their platform
  • Import the ZIP (as existing project into workspace)
  • Rebuild

IMHO this far outweighs the small inconvenience of having to download and import an extra (technically redundant) package, as this needs to be done only once.

@ackalker ackalker fix build path
Remove platform-dependent jars, add org.eclipse.swt as a required project.
This makes the .classpath file contents static. Users need to download and
import platform-specific org.eclipse.swt ZIP into their workspace just once,
but don't need to .gitignore or fix the .classpath after every Git pull.

So instead of having users change once and for all a classpath file on their machines, now they have to download something else, and thus another step that needs to be documented as been added? I don't see the interest.
Anyway, this point is moot, since the only class requiring SWT is a a visual test that was useful when I was developing, but should not even have been committed. I've removed it, which removes the dependency on SWT.


Ah, that explains. I didn't dig into the purpose of that project, I assumed that it was somehow important (why else let the build fail because of it?)
And yes, I do consider tests important, especially for a language like Java, where the compiler is all that prevents a programmer from shooting him/herself in the foot.
Comparing compilers to guns: Haskell doesn't prevent someone from shooting him/herself in the foot either, but at least it puts the (type-)safety catch on :-D


Which build fails? Not the build on the machine used to build releases, i.e. mine, and that project is not part of the release anyway...


My build failed. As would anyone else's if using a non-windows non-x86 OS. The build instructions clearly state to import all projects from the Git repo (which is also the most convenient and obvious thing to do in Eclipse), so one would naturally expect them all to build without errors.
But please, let's not get into a nit-picking contest, let's try to collaborate on an open project, if you will.

@ackalker ackalker closed this Feb 27, 2013
@ackalker ackalker reopened this Feb 27, 2013

Successfully built and exported feature net.sf.eclipsefp.haskell-feature to ZIP and installed it.
For some reason, it required several restarts (after unexplainable hangs) and a workspace switch to get working, but in the end it did. Thanks.



Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment