Dear list,

especially in educational settings, there is an increasing pool of
platform independent Java applications (JARs) that can be integrated in
users' desktops.

While Java JDK is freed nowadays, those JAR files are mostly
closed-source (bluej, javakara, jprologeditor, greenfoot etc.).

Rather than creating wrapping deb-packages with binary content
('dirty'), I'd suggest a straight-forward policy plus some desktop
integration tool for admins:

RFC:
- place all jar files to /usr/share/java or /usr/lib/jar
- register desktop relevant jar files in /etc/debian-desktop-jar.conf
like this:
[BlueJ]
exec="java -jar /usr/lib/jar/bluej22.jar"
menu="BlueJ Java Editor"
icon=/usr/share/icons/misc/bluej.png
...
- add some hook that makes those icons show in desktop menus
- provide some tool that helps registering such JAR apps.

Maybe there is already such approach. In some way it would be handy if
the proposed /etc/debian-desktop-jar.conf could be spreaded easily to
further desktops. This would imply packaging all files mentioned there
(jar files, icons) for further deployment.

Especially for Schools running Debian (Edu) such policy/tool could be
very helpful.

Please comment on this.
Kind regards
Ralf


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Dear list,

especially in educational settings, there is an increasing pool of
platform independent Java applications (JARs) that can be integrated in
users' desktops.

While Java JDK is freed nowadays, those JAR files are mostly
closed-source (bluej, javakara, jprologeditor, greenfoot etc.).

Rather than creating wrapping deb-packages with binary content
('dirty'), I'd suggest a straight-forward policy plus some desktop
integration tool for admins:

RFC:
- place all jar files to /usr/share/java or /usr/lib/jar
- register desktop relevant jar files in /etc/debian-desktop-jar.conf
like this:
[BlueJ]
exec="java -jar /usr/lib/jar/bluej22.jar"
menu="BlueJ Java Editor"
icon=/usr/share/icons/misc/bluej.png
...
- add some hook that makes those icons show in desktop menus
- provide some tool that helps registering such JAR apps.

Maybe there is already such approach. In some way it would be handy if
the proposed /etc/debian-desktop-jar.conf could be spreaded easily to
further desktops. This would imply packaging all files mentioned there
(jar files, icons) for further deployment.

Especially for Schools running Debian (Edu) such policy/tool could be
very helpful.

Please comment on this.
Kind regards
Ralf


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hi,

RalfGesellensetter wrote:
> While Java JDK is freed nowadays, those JAR files are mostly
> closed-source (bluej, javakara, jprologeditor, greenfoot etc.).
>
> Rather than creating wrapping deb-packages with binary content
> ('dirty'), I'd suggest a straight-forward policy plus some desktop
> integration tool for admins:

> RFC:
> - place all jar files to /usr/share/java or /usr/lib/jar

If I understand your mail right, you want to create an application to
manage the JAR files? If this is right, the *.jar files should IMO go
to /usr/local/lib/java (or somewhere else in /usr/local).

> - register desktop relevant jar files in /etc/debian-desktop-jar.conf
> like this:
> [BlueJ]
> exec="java -jar /usr/lib/jar/bluej22.jar"
> menu="BlueJ Java Editor"
> icon=/usr/share/icons/misc/bluej.png
> ...

These could then be dropped in /usr/local/share/applications. This
would also solve the next point (at least for desktops that use the
.desktop files).

> - add some hook that makes those icons show in desktop menus
> - provide some tool that helps registering such JAR apps.

I miss something in this approach: How would the JAR files be
distributed? And how can updates be handled? Having the admin install
them manually on multiple systems is not very comfortable and error
prone.

I think it might be a better idea to make it easy to create Debian
packages out of the JAR files (somewhat similar to dh-make-perl for Perl
packages). This would make it easy to handle distribution and updates
centrally. Also it gets the added benefit of dependency handling by
APT.

Regards,
Ansgar

--
PGP: 1024D/595FAD19 739E 2D09 0969 BEA9 9797 B055 DDB0 2FF7 595F AD19


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sunday 13 July 2008 17:15:01 RalfGesellensetter wrote:
> Dear list,

Hello,

> especially in educational settings, there is an increasing pool of
> platform independent Java applications (JARs) that can be integrated in
> users' desktops.
>
> While Java JDK is freed nowadays, those JAR files are mostly
> closed-source (bluej, javakara, jprologeditor, greenfoot etc.).
>
> Rather than creating wrapping deb-packages with binary content
> ('dirty'), I'd suggest a straight-forward policy plus some desktop
> integration tool for admins:

Hmmm, the debian binary packages are not just a way to blindly move files
(i.e. the payload) to the users desktops, it brings some meaningful set of
well crafted features like relationships between these payloads (depends,
provides, conflict, etc) thus users are able to manage them is a sane way
(install, remove, configure, reconfigure,not to mention various a-la `list'
and `show' queries like dpkg -L, dpkg -S, debsums, and so forth). I'm afraid
that your proposal has an inherent problem and won't survive or is not
suitable for broad spread, but probably you can find a way to use it locally
somehow especially if a robust system accountability and housekeeping is not
of any interest for you.

--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Jul 13, 2008 at 10:31 PM, RalfGesellensetter <rgx@gmx.de> wrote:

> - place all jar files to /usr/share/java or /usr/lib/jar

Locally installed and built stuff should go to /usr/local or /opt
rather than there.

> - register desktop relevant jar files in /etc/debian-desktop-jar.conf

Just altering all the menu files that packages put in /etc/xdg/menus/
to look for .desktop files in /usr/local/share/applications should be
the right way.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Ta, paul

Am Montag 14 Juli 2008 schrieb Paul Wise:
> Just altering all the menu files that packages put in /etc/xdg/menus/

what's the difference between /usr/share/menu/ & /etc/xdg/menus/ ?

cheers
regards
ralf


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Tue, Jul 15, 2008 at 1:17 AM, RalfGesellensetter <rgx@gmx.de> wrote:

> what's the difference between /usr/share/menu/ & /etc/xdg/menus/ ?

The former is for menu files for the Debian-specific menu (that isn't
available in Debian GNOME by default). The latter lists FreeDesktop
menus for different desktop systems. /usr/share/applications/ is the
equivalent of /usr/share/menu/ for the FreeDesktop menus.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org