As the subject says. Lately I have not had the motivation to deal with
eclipse and as a result it is currently bit-rotting in unstable.
Furthermore, my daily Debian work has more or less drifted away from
The particular issue (#649912) supposedly have a partial patch,
though unfortunately eclipse FTBFS on amd64 for me because some files
have "moved" and I have no clue as to why. Due to the above, I realized
that perhaps it was time to move on and make room for some new blood.
There are some people listed as uploaders of eclipse; some of them may
still be around and willing to work on eclipse. That being said I
strongly suspect we need new people in addition to the current ones.
If you are interested in maintaining in eclipse be advised that:
* eclipse takes a lot of effort, commitment and time.
- I have heard plenty of people say they would like to help with
eclipse. Though few actually stay around for longer than a week.
- In my experience, your co-maintainers can/will be busy for extended
periods of time or simply need some "away time" from eclipse.
- Most likely you will need a break from eclipse every now and then
- Some times you have to deal with a major upstream release mostly
on your own.
* you want some package experience before accepting this package.
- it is not simple, kind nor forgiving.
- you can compenstate with stubbornness and patience in short term.
- But it will wear you down in long term.
* it is very unlikely packaging the eclipse plugins
- we got reasonably good tool support for those, not for eclipse.
* eclipse has its own build system and an implied self circular
- Every major version eclipse needs to be bootstrapped by a
- upstream unaffected due to incremental development style
- manually bootstrapping is technically possible, but easily
becomes time consuming.
- It is "merely" a nuisance and in the past Fedora did it for us.
- Though it did not work with 3.7, as the bootstrapping did not use
our "common" links (instead it recorded the final target which is
* every major upstream versions have pre-compiled binaries or
- This has improved a lot since I picked up the package in 2009.
- This is a great source of frustration for me when packaging
eclipse 3.6 and 3.7
* eclipse consists of a myriad of "smaller" upstreams
- LinuxTools handles the build tools we use and usually happy to
carry patches that are not accepted "further upstream".
- Not all upstreams agree to the Debian approach.
- Some bundles are the "official binaries from X".
- Some accept our patches as "fall-back" (e.g. "recompile binary
if it is not present").
* you cannot forward patches to eclipse from someone.
- Author of the patch must forward it (or appear on their BTS and
give his/her consent)
* you generally want to be envolved in LinuxTools's eclipse-build
- Some architecture patches got axed in the 3.7 cycle because we were
not around to refresh them. Presumably the cause of #649912.
* the eclipse build system is a resource hog.
- Over 0.5 GB of B-D (beyond build-essential) and over 2.7 GB size
used at the end of the build.
- javadoc process known to eat over 1.7 GB RAM alone during build.
- With less than 2 GB of RAM your build time will easily exceed an
- (parts of the) build is parallel by default and I have no clue how
to disable that.
* the build system has been known to ignore errors and happily continue
- In the old days this could cause pre-compiled binaries to end up in
the final package, but I think we have solved all of those problems
- The error you see is often caused by something that happened
- Unfortunately 2-3 screens worth of exceptions and stack-traces
are "normal" in our current builds. >.>
* following Ubuntu bugs can easily kill your motivation.
- The reporters tend to use the precompiled binaries from eclipse.org
and report crash logs.
- Follow-ups are usually "Just download it from eclipse.org and it
* Eclipse "hard-codes" paths (and "versions") of Jars.
- Even minor version updates to (e.g.) sat4j will cause issues.
- Issues propagate to the user's ~/.eclipse and stays there.
* Eclipse depends on multiple or old versions of the same library.
- Defacto you will end up maintaining those.
- Migrating eclipse to the new version can be difficult depending on
the library and eclipse's assumptions about it.
* Eclipse has a very good control on Copyright and License.
- Almost everything is EPL (with some exceptions).
- They have rigid copyright requirements.
- d/copyright is currently auto-generated.
* Eclipse has a strict release cycle.
- Yearly major releases (I think it is in June or July)
- They can be very difficult.
- eclipse-build has been known to prepare earlier to weed out some
of the bugs.
- If time permits, you want to be around for that.
- 2 minor releases.
- Usually relatively simple to do.
* Eclipse know-how is scares in Debian.
- Only a handful of people has worked with eclipse in Debian for the
past 3 years.
- Even fewer with 6+ (active) months of experience.
However, there are oppertunities here:
* Parts of upstreams have started projects to improve Linux distro
- Unfortunately I have not been able to follow up on this, so
currently we get what Fedora is ordering.
- I can dig out (some of) the relevant bugs on request.
* There is plenty of oppertunities to go further upstream and
- Java and ant are what you need and what you will learn.
* You will most likely be working with people from Fedora/RedHat.
- LinuxTools is filled with those.
- Solutions to lots of problems can usually be found in the Fedora
spec file (or one of their patches).
- Just generalize it and get it into eclipse-build or further
upstream and profit.
* When you have maintained eclipse for a year or so:
- most other packages will be pale and trivial in comparison.
- some people will assume you know everything there is to know
about Java (Packaging).
- someone will tell you to join NM (or become a DM) if you aren't
- Your milage may vary here, but generally your technical skills
will very likely be DM/DD material after a year with eclipse.
* I will be around to answer questions and guide you to the right
people (did I mention LinuxTools's eclipse-build?).
I did not do it myself, but it might be a good idea to coordinate with
team members/co-maintainers to align your expectations. It can be very
demotivational to be (or to feel that you are) the only one working on
the "coming major upstream release".
The "Inner Workings" is a "fairly" new document that describes some of
the things we had to learn the "hard-way" in 2009. Sami Wagiaalla from
Fedora is to praise for starting this.
Both files, the tarball needs to replace the existing tarball in the
upstream part of the package.
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com