Hallo Ben,
* Ben Burton wrote:
I agree with this. IMO a java jar should be handled the same as a
binary lib ad should get API Version (~SONAME) included in its name.
The problem is that many java libraries don't have a concept of an API
version / soname. All you can guarantee to get is a
Hallo Ben,
* Ben Burton wrote:
I agree with this. IMO a java jar should be handled the same as a
binary lib ad should get API Version (~SONAME) included in its name.
The problem is that many java libraries don't have a concept of an API
version / soname. All you can guarantee to get is a
Ola Lundqvist wrote:
Yes please. Treat this as an objection for the removal of the versioned
names.
Should Java programs or libraries that use a versioned JAR from another
Java library have a versioned package dependency on this libraray? E.g.
if I use the current
In message: [EMAIL PROTECTED]
Stefan Gybas [EMAIL PROTECTED] writes:
Should Java programs or libraries that use a versioned JAR from another
Java library have a versioned package dependency on this libraray? E.g.
if I use the current /usr/share/java/xalan-2.5.0.jar in my package
Hallo T.,
* T. Alexander Popiel wrote:
Java library have a versioned package dependency on this libraray? E.g.
if I use the current /usr/share/java/xalan-2.5.0.jar in my package how
should my dependency look?
I'd tend to go with #5, until the version number is formally moved
into the package
I agree with this. IMO a java jar should be handled the same as a
binary lib ad should get API Version (~SONAME) included in its name.
The problem is that many java libraries don't have a concept of an API
version / soname. All you can guarantee to get is a release version,
which may or may
In message: [EMAIL PROTECTED]
Ben Burton [EMAIL PROTECTED] writes:
I agree with this. IMO a java jar should be handled the same as a
binary lib ad should get API Version (~SONAME) included in its name.
The problem is that many java libraries don't have a concept of an API
version
In message: [EMAIL PROTECTED]
Stefan Gybas [EMAIL PROTECTED] writes:
Should Java programs or libraries that use a versioned JAR from another
Java library have a versioned package dependency on this libraray? E.g.
if I use the current /usr/share/java/xalan-2.5.0.jar in my package
Hallo T.,
* T. Alexander Popiel wrote:
Java library have a versioned package dependency on this libraray? E.g.
if I use the current /usr/share/java/xalan-2.5.0.jar in my package how
should my dependency look?
I'd tend to go with #5, until the version number is formally moved
into the package
I agree with this. IMO a java jar should be handled the same as a
binary lib ad should get API Version (~SONAME) included in its name.
The problem is that many java libraries don't have a concept of an API
version / soname. All you can guarantee to get is a release version,
which may or may
In message: [EMAIL PROTECTED]
Ben Burton [EMAIL PROTECTED] writes:
I agree with this. IMO a java jar should be handled the same as a
binary lib ad should get API Version (~SONAME) included in its name.
The problem is that many java libraries don't have a concept of an API
version
Ben Burton [EMAIL PROTECTED] wrote:
[...]
I certainly don't believe we should remove versioned JARs until we can
come up with a solution that addresses the API problem. The current
solution is like giving a C library an soname that is equal to the
application version. If we remove
Ben Burton [EMAIL PROTECTED] wrote:
[...]
I certainly don't believe we should remove versioned JARs until we can
come up with a solution that addresses the API problem. The current
solution is like giving a C library an soname that is equal to the
application version. If we remove
Hi,
On Sat, 2003-07-19 at 01:50, Ben Burton wrote:
But you are fooling yourself if you claim that simply removing
versioning all together will bring with it stability. The sad fact with
the Java world is that if your package or app uses some Java library,
you have to follow changelogs to see
On Friday 18 July 2003 11:03, Stefan Gybas wrote:
Jan Schulz wrote:
I've also come to the conclusion that adding the version number to JARs
in /usr/share/java/ is a bad idea. Take for example libxercres2-java: If
you've used /usr/share/java/xercesImpl-2.3.0.jar in another package and
then
E.L. Willighagen (Egon) wrote:
Since Xerces tends to give a lot of trouble moving from one version to
another, even within the 2.x series!, a more granular packaging would
be nice... i.e. separate packages for 2.3 and 2.4, etc...
Probably yes. But I don't have the time to maintain that many
BTW, I've not seen any package that usees the versioned JAR - so
it obviously is not useful.
This is not a valid argument. Just because debian packages don't use a
feature doesn't mean users aren't using the feature with their own
home-grown software.
Ben. :)
--
To UNSUBSCRIBE, email to
Hallo Stefan,
* Stefan Gybas wrote:
Ben Burton wrote:
This is not a valid argument. Just because debian packages don't use a
feature doesn't mean users aren't using the feature with their own
home-grown software.
But I think the process should go in the other direction: Instead of
specifing
Hallo Stefan,
* Stefan Gybas wrote:
(e.g. to use a well-defined class path)
BTW: I just had some problems with that:
SWT is (2.1.1-3) now avavilable with motif and gtk bindings. The
problem is, that gtk is distributet in two jars and motif in one jar
(license issues...). So when someone
But I think the process should go in the other direction: Instead of
specifing something and waiting for people to implement it we should
document what has been implemented and is working well.
This is not necessarily true; take as an example the /usr/lib/jni
proposal. Although pretty much
On Friday 18 July 2003 11:03, Stefan Gybas wrote:
Jan Schulz wrote:
I've also come to the conclusion that adding the version number to JARs
in /usr/share/java/ is a bad idea. Take for example libxercres2-java: If
you've used /usr/share/java/xercesImpl-2.3.0.jar in another package and
then
Hello
Thanks for taking over java-common. I thought you would. :)
On Fri, Jul 18, 2003 at 11:03:22AM +0200, Stefan Gybas wrote:
Jan Schulz wrote:
I just wanted to know what direction. I'm not suggesting to discuss
the things word by word...
I've collected some suggestions for building
Ben Burton wrote:
This is not a valid argument. Just because debian packages don't use a
feature doesn't mean users aren't using the feature with their own
home-grown software.
But I think the process should go in the other direction: Instead of
specifing something and waiting for people to
Hallo Stefan,
* Stefan Gybas wrote:
(e.g. to use a well-defined class path)
BTW: I just had some problems with that:
SWT is (2.1.1-3) now avavilable with motif and gtk bindings. The
problem is, that gtk is distributet in two jars and motif in one jar
(license issues...). So when someone
But I think the process should go in the other direction: Instead of
specifing something and waiting for people to implement it we should
document what has been implemented and is working well.
This is not necessarily true; take as an example the /usr/lib/jni
proposal. Although pretty much
Hallo Stefan,
* Stefan Gybas wrote:
[..]
the debian-java list. Just like it's done on debian-policy.
Ok.
[latest java-policy]
It's the one in java-common 0.21, uploaded today.
Thanks, got it just now. I just thought that I heard once about bigger
changes...
BTW, can you post you suggestion
26 matches
Mail list logo
