From Fedora Project Wiki

Etherpad FAD

Its a go. See Etherpad FAD for more info.

Packaging Etherpad

There's a not really guidelines compliant version alive here:

Etherpad bundles a good chunk of libraries. Some of them are already packaging in Fedora, some aren't.

Moving towards a package of Upstream

Recommended you start with these notes on how I'm getting Etherpad 1.1 to work without bundled libraries.

Based on SDZ spec (see "not really guidelines compliant version") and tons of packages by JStanley and Spot (see chart below)

--Colin Z 00:03, 18 October 2010 (UTC)

Libraries bundled in Etherpad

in infrastructure/lib

file name fedora package status
c3p0- review Heavily patched to work on Java 1.6 and the project seems dead. Request to move Etherpad to Apache Commons DBCP submitted upstream.
mchange-commons-0.2 review Required for c3p0 building
rhino-js-1.7r1.jar review contains proprietary extensions which are patched around. R1 is needed for yuicompressor to work, we have R2 in Fedora. R1 with appjet patches package.
yuicompressor-2.4-appjet.jar review breaks build, significant api breakage for yuicompressor both in R2 and R3; can be disabled, or we need compat-rhino-17r1. Alternatively, we could ship CSS-only version; performance penalty for JavaScript. needs packaging. Yuicompressor w/ patches working in above appjetrhino package.

Scala Version Issue Compat Packages

Etherpad requires an old version of Scala (upstream ticket)

Jon Stanley's Scala2.7 compat packages:

Packaged: yes

Accepted: no

Notes from Victor Vasilyev


I've successfully compiled and launched the project on the Fedora 13, and can confirm that is working well. But, I've also noticed that the Google wave has a bit more facilities  :-(

After a brief researching of the project I've opinion that you'll have a lot of the tasks that should be completed before release of the project for the Fedora Linux distribution will happen. I see at least the following tasks:

  • Decomposing of the project, and selecting of all "internal" and "external" components.
  • Replacing the all third-party components with the requirements for each component to have a list of all external dependencies.
  • Providing of the RPM packages for required third-party components that are not in Fedora yet (if any).
  • Dividing of all external dependencies into build-time and run-time dependencies.
  • Sorting of all "internal" components by their languages, and avoiding unneeded languages to simplify the project.


I think, you should also decide to use a build system that is "usual" for Java (e.g. Ant, Maven, etc.) instead of Bash-scripts.

...And, finally, will be better to see a components diagram for the project (e.g. UML components diagram) that might explain a role of each component, and their dependencies.

Note from Matěj Cepl

--Mcepl 07:55, 16 December 2010 (UTC)