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
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 A
> 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 A
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 pac
> 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]>
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 pa
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 /usr/share/java/xalan-2.5.0.jar
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 pac
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 pa
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 /usr/share/java/xalan-2.5.0.jar
On Thu, Jul 24, 2003 at 03:25:59PM +0200, Arnaud Vandyck wrote:
> 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 lib
On Thu, Jul 24, 2003 at 03:25:59PM +0200, Arnaud Vandyck wrote:
> 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 lib
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
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
> 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 mu
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 depen
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
>speci
> 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 mu
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 depen
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
>speci
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 imple
> 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. :)
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 impl
> 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
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 bui
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 packag
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
> the
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 Java package at
http://pkg-java.alioth.debian.org/building.html. I think some of them
(e.g. to use a well-defined class path) should becom
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 bui
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 packa
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
> the
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 Java package at
http://pkg-java.alioth.debian.org/building.html. I think some of them
(e.g. to use a well-defined class path) should beco
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
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
38 matches
Mail list logo
