Hi Java-Experts,

just a quick question: In building JBoss I encounter a lot of jars that
do (partially) overlap. I didn't find anything about how to deal with
this in the Java or Debian policy. (Hope I am not just missing something!)


To give two representative examples:

client and server application jar:
- one jar contains base classes + server classes
- another jar contains base classes + client classes

connector jars:
- a host of different jars that all contain a few connector base classes
and then connector specific (e.g. JDBC-specific) classes.


The rationale is obvious: If you are doing a slim client application you
don't want to install many unnecessary server classes. But you'll
probably need some common infrastructure classes.


I could simply do a client and a server package now. Or one package for
each connector. This however does not fit well into the Debian
"jar-sharing" concept as we would like to avoid having to maintain
different versions of the same (base) classes across different packages.
I think Debian usually assumes that jars are "atomic" installation units
that do not overlap.


What do you recommend in this situation?

Florian


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

On Fri, Jun 20, 2008 at 12:40:55PM -0300, Florian Grandel wrote:
> Hi Java-Experts,
>
> just a quick question: In building JBoss I encounter a lot of jars that
> do (partially) overlap. I didn't find anything about how to deal with
> this in the Java or Debian policy. (Hope I am not just missing
> something!)
>
> To give two representative examples:
>
> client and server application jar:
> - one jar contains base classes + server classes
> - another jar contains base classes + client classes
>
> connector jars:
> - a host of different jars that all contain a few connector base classes
> and then connector specific (e.g. JDBC-specific) classes.
>
> The rationale is obvious: If you are doing a slim client application you
> don't want to install many unnecessary server classes. But you'll
> probably need some common infrastructure classes.
>
> I could simply do a client and a server package now. Or one package for
> each connector. This however does not fit well into the Debian
> "jar-sharing" concept as we would like to avoid having to maintain
> different versions of the same (base) classes across different packages.
> I think Debian usually assumes that jars are "atomic" installation units
> that do not overlap.
>
> What do you recommend in this situation?

I would do it as upstream does it. This doesnt confuse users as that is
what they know from upstream. We had enough problems when our jars were
too mich different from upstream in the past.


Cheers,
Michael


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

Hi Michael,

Michael Koch schrieb:

I would do it as upstream does it. This doesnt confuse users as that is
what they know from upstream. We had enough problems when our jars were
too mich different from upstream in the past.


Thank you very much for your opinion. That's what I was thinking as well
and how I started doing it now.


Bye,

Florian


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

Am Montag 30 Juni 2008 schrieb Florian Grandel:
> Thank you very much for your opinion. That's what I was thinking as
> well and how I started doing it now.

Hi Florian, hi Michael,

sounds sound to me - but:
Intersection also implies waste of space. In cases where the overlapping
base classes extend 1 MB (after installation) and take more than the
half of all, it might be better to create a base-package and state
dependencies of server and client packages against this base package.

In some cases, the overhead of the client package is that low, that you
could make the server package (w/o base classes) dependent on the
client package (incl. base classes).

What do you think?
Regards
Ralf

P.S.: Pointers to Howtos on Java Packaging are welcome.


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

On Mon, Jun 30, 2008 at 07:04:00PM +0200, RalfGesellensetter wrote:
> Am Montag 30 Juni 2008 schrieb Florian Grandel:
> > Thank you very much for your opinion. That's what I was thinking as
> > well and how I started doing it now.
>
> Hi Florian, hi Michael,
>
> sounds sound to me - but:
> Intersection also implies waste of space. In cases where the overlapping
> base classes extend 1 MB (after installation) and take more than the
> half of all, it might be better to create a base-package and state
> dependencies of server and client packages against this base package.
>
> In some cases, the overhead of the client package is that low, that you
> could make the server package (w/o base classes) dependent on the
> client package (incl. base classes).
>
> What do you think?

Creating different JAR contents than upstream only leads to user
irritation. Disk space is relativly cheap today so that should not be an
issue.


Cheers,
Michael


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

Hi Ralf,


Creating different JAR contents than upstream only leads to user
irritation. Disk space is relativly cheap today so that should not be an
issue.


I also think that disk space is not the main issue. When I asked my
question I was more thinking about maintainability (jars with the same
classes may get out of sync). But as long as the overlapping jars are
built from the same source package, maintainability is not an issue
neither as all jars will always be built from the same source.


Rgds,

Florian


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