[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Eclipse & RCP deployment

Hash: SHA256

Hello Pantelis,

Pantelis Koukousoulas schrieb:
> On Wed, Dec 31, 2008 at 4:28 PM, Harald Krammer <Harald.Krammer@hkr.at> wrote:
>> Hello,
>> I would like to deploy a customized Eclipse development environment on
>> Debian Etch/Lenny.
> Excellent!
> We have already started an effort to get eclipse into shape for debian
> and there is
> a preliminary "monolithic" package. See:
> http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/2008-December/018863.html
> for the details.
> Nathan summers (aka Rockwalrus) seems to also be reviving his efforts
> so you can see
> the ubuntu eclipse-team stuff and
> https://bugs.launchpad.net/eclipse-ubuntu

Thank you for the information and I will try to follow your steps.

>> The method should also work for Eclipse RCP-Apps,
>> SWT-Apps and pure Java applications withMy opinion is that the Java integration has few pitfalls 
> This sounds like nathan's modular approach: may be you could help with that ?
> The idea is to have eclipse-swt, eclipse-rcp, eclipse-platform,
> eclipse-jdt etc packages
> and metapackages for the configurations offered by eclipse.org.

I looked into the modular approach and that was the reason to take
the "monolithic way".
I will get the possibility to mix different versions without
dependencies (if possible). e.g. Eclipse version 3.3 and 3.4 must work
in parallel or different RCP-apps as well.
A mix of all version together is hardly possible and we lose the
flexibility. An additional goal is to use the IDEs (Eclipse/Netbeans) so
much as possible.

>> I saw following issues:
>> *) adding a menu icon
>> Entry into /usr/share/menu & /usr/share/applications
> A particularly good solution would be a org.debian.platform feature (like the
> way fedora does it) with all the debian-specific branding stuff in there.
> Then, we could probably just symlink to the icons there, or put the icons
> in /usr/share and symlink from the feature, depending on what is more
> convenient.
> A problem is that no binary files should be inside debian/ (so that it is easy
> to keep this folder in various SCMs for example). The above solves this,
> but for now we have uuencoded png icons and an svg one too.
> (the svg I think is still in the bugtracker)
>> *) the right place in the file system
>> In the past I installed eclipse in my home directory, in /opt or in
>> /usr/local.
>> As a deb-package I will take following structure:
>>  - Application into  /usr/share/<myeclipseappfolder>
>>  - Starter in /usr/bin/<myeclipsename>
>>  - Docs (changelog, readme,copyright,..) into
>> /usr/share/doc/<myeclipseappfolder>
> We would like to have (in an ideal world)
> /usr/lib/jni                           - for the native swt stuff
> /usr/lib/eclipse                   - due to arch-dependent jars with
> native libs inside etc
> /usr/share/eclipse             -
> Perhaps
> /usr/local/lib/eclipse
> /usr/local/share/eclipse
> Would also be useful, but this will need some discussion

I think /usr/local isn't a good idea. Look at
It is only an option for generic installer.

> Things a non-root user installs through the update manager go to
> ~/.eclipse at least for now
> (A few more interesting tricks seem possible with p2 touchpoints but
> this is very low priority).

The update itself is a very complex thing and I don't have an idea to
deal with it.
A OSGi application has it own administration concept and to combine it
with the Debian package management isn't easy - I hope I am wrong.
An update of a running application will not supported in the beginning (
don't look into the OSGi spec :)
I am convinced that a solution for this problem is very important to get
Possible scenarios are:
- - Bug fixes / security updates via apt-get for OSGi applications
 ( single point of administration)
- - adding of new feature of a running OSGi applications with apt-get
- - Update of OSGi applications in multi user environments
 e.g. The administrator is responsible to deploy the updates.

>>  - Icons into /usr/share/pixmaps/<<myeclipsename>.png,
>> /usr/share/pixmaps/<<myeclipsename>.xpm
>>  - Possible an entry into /usr/share/man/man1/<myeclipseappfolder>
> For policy compliance, it seems we need at least one manpage per executable.
> There is already a bug for that and has some comments.
>> Ok?
>> *) Java Environment
>> The application should work independent from the system properties. So
>> the JRE (e.g. OpenJDK) could be an part of the application or better I
>> add an dependency to e.g. OpenJDK and the starter in /usr/bin/<..> use
>> OpenJDK directly if JAVA_HOME is unset. Ok?
> I think there is standard debian java policy for that, we probably want to
> only care about / depend on openjdk for now and configure eclipse to
> use that.
>> As maintainer I will only guarantee that my application run with my
>> selected VM. Later I will add an /etc-entry to select the VM for
>> advanced user (e.g. system default VM, openjdk and so on).
>> *) Eclipse(OSGi) specific storage in e.g. ~/.eclipse/<myappname>
>> Is it enough to add an menu entry to clean the user specific data in
>> ~/.eclipse/<myappname>?
>> The idea behind is to reset the application to default settings without
>> knowing of e.g. ~/.eclipse/<myappname>.
>> What is your strategy?
> I think debian policy is to leave the "dotfiles" alone when you just
> apt-get remove something
> and only delete them when you say explicitly --purge.
> By doing a --purge and a reinstall you can easily "reset to a vanilla state".
> Would this be enough for your case?

I think it should never happen that an administrator can remove the user
content via apt. The user must control it own content and my focus is
only the usability. If a user start to play with all settings of an IDE
like Eclipse (also installing of plug-ins) then a "reset" is necessary.

>> What is your method to bring Eclipse-RCP-, SWT- and Swing-Application to
>> Debian?  Any feedback are welcome!
> Our method is basically to experiment with various approaches (e.g.,
> we are already
> evaluating like 3 different build-systems), document and discuss whatever we can
> and talk to upstream people in #eclipse-linux / linux-distros@eclipse.org :)
> It would be great if you could join our efforts :-)  The more we are,
> the higher our
> chances to succeed :-)

You are totally right and I will do it.


Nice greetings

- --

Harald Krammer
Brucknerstrasse 33
A - 4020  Linz

Mobil +43.(0) 664. 130 59 58
Mail: Harald.Krammer (at) hkr.at

Version: GnuPG v1.4.6 (GNU/Linux)


Reply to: