Re: Eclipse & RCP deployment
-----BEGIN PGP SIGNED MESSAGE-----
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
Swing/AWT.
>
> 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
http://www.debian.org/doc/maint-guide/ch-modify.en.html
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
success.
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
install
- - 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
- --
Harald Krammer
Brucknerstrasse 33
A - 4020 Linz
AUSTRIA
Mobil +43.(0) 664. 130 59 58
Mail: Harald.Krammer (at) hkr.at
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFJXNIL9QlAsubHO9sRCA0pAJ9ACYGepNmuBGZdGubAomh+WcK7cgCgrEEG
czETNIuSYUdpWPi5/8mGyRM=
=va6H
-----END PGP SIGNATURE-----
Reply to: