-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello Pantelis,
Pantelis Koukousoulas schrieb: > On Wed, Dec 31, 2008 at 4:28 PM, Harald Krammer <[email protected]> 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 / [email protected] :) > > 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----- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
