Bug#801026: osgi-compendium: depends on obsolete libservlet2.5-java library

[Markus Koschany]

Am 05.10.2015 um 22:35 schrieb Neil Bartlett:
[...]

> There is no contradiction… where did I claim that it only supports 2.5?

You wrote:

> We cannot simply update to 3.1 since that could break any consumers using 2.5 
> — also the package would not comply with the published specification.

I read the last part of this sentence as that the "package" was
src:osgi-compendium from Debian but it seems I have misunderstood you. I
would like to know more about your specific use case and in which
context you use Debian's osgi-compendium package in order to better
understand your concerns.


> The specification supports users who depend on servlet 2.5 or above. That 
> means the specification JAR compiles against the lowest version that it 
> supports, i.e. 2.5.

This is correct. Like I said servlet 2.5 is the minimum requirement for
OSGi 5. However Debian's osgi-compendium package would also comply with
the specification if it was compiled against a later version, e.g 3.1.

[...]
> The source code for OSGi Compendium contains the type 
> org.osgi.service.http.HttpService, which depends on types from the 
> javax.servlet package. If the osgi-compendium package in Debian builds from 
> Java sources then it certainly needs javax.servlet to be present on the 
> compiler’s classpath, and therefore the dependency cannot be removed. On the 
> other hand if it repackages pre-built JARs from elsewhere then I would agree 
> that javax.servlet does not need to be present as a dependency.

I have checked the source package again and this was a mistake on my
side. The servlet dependency is needed. If I remove the build-dependency
on libservlet2.5-java it compiles successfully but only because another
implicit build-dependency depends on libservlet2.5-java too.


>> Can you provide an example what package in Debian would be negatively
>> affected if we started to build-depend/depend on libservlet3.1-java?
> 
> No I am not able to answer this.

I need more information how this upgrade to libservlet3.1-java affects
your setup and under which circumstances it would break your
"consumers", otherwise I can't help you. Also libservlet2.5-java won't
probably go away in Stretch, so you can still install this package if
you like.

Markus



signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#801026: osgi-compendium: depends on obsolete libservlet2.5-java library

[Neil Bartlett]

> On 5 Oct 2015, at 21:03, Markus Koschany  wrote:
> 
> Am 05.10.2015 um 21:26 schrieb Neil Bartlett:
>> This isn’t really possible. The osgi-compendium package is not just a 
>> program or library; it represents a specification published by a standards 
>> body, the OSGi Alliance. The specification supports the java servlet API 2.5 
>> and above. We cannot simply update to 3.1 since that could break any 
>> consumers using 2.5 — also the package would not comply with the published 
>> specification.
>> 
>> Neil Bartlett
> 
> Hello,
> 
> you contradict yourself by claiming that The OSGi Compendium 5
> specification supports the Java servlet API 2.5 and above and in the
> next sentence you claim it only supports 2.5.

There is no contradiction… where did I claim that it only supports 2.5?

The specification supports users who depend on servlet 2.5 or above. That means 
the specification JAR compiles against the lowest version that it supports, 
i.e. 2.5.

> 
> I think your first part is correct. I quote from page 795 of the
> specification:
> 
> "This Web Application Specification provides support for web
> applications written to the Servlet 2.5
> specification, or later"
> 
> So I see this more like a minimum requirement. I have also never
> understood why we build-depend on libservlet2.5-java at all given the
> fact that it is not needed at build-time. I would rather tend to
> completely remove the build-dependency and the corresponding dependency
> on libservlet2.5-java but not before I have checked that all
> reverse-dependencies do not rely on this behaviour.

The source code for OSGi Compendium contains the type 
org.osgi.service.http.HttpService, which depends on types from the 
javax.servlet package. If the osgi-compendium package in Debian builds from 
Java sources then it certainly needs javax.servlet to be present on the 
compiler’s classpath, and therefore the dependency cannot be removed. On the 
other hand if it repackages pre-built JARs from elsewhere then I would agree 
that javax.servlet does not need to be present as a dependency.


> 
> Can you provide an example what package in Debian would be negatively
> affected if we started to build-depend/depend on libservlet3.1-java?

No I am not able to answer this.

> 
> Regards,
> 
> Markus
> 


Neil

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#801026: osgi-compendium: depends on obsolete libservlet2.5-java library

[Markus Koschany]

Am 05.10.2015 um 21:26 schrieb Neil Bartlett:
> This isn’t really possible. The osgi-compendium package is not just a program 
> or library; it represents a specification published by a standards body, the 
> OSGi Alliance. The specification supports the java servlet API 2.5 and above. 
> We cannot simply update to 3.1 since that could break any consumers using 2.5 
> — also the package would not comply with the published specification.
> 
> Neil Bartlett

Hello,

you contradict yourself by claiming that The OSGi Compendium 5
specification supports the Java servlet API 2.5 and above and in the
next sentence you claim it only supports 2.5.

I think your first part is correct. I quote from page 795 of the
specification:

"This Web Application Specification provides support for web
applications written to the Servlet 2.5
specification, or later"

So I see this more like a minimum requirement. I have also never
understood why we build-depend on libservlet2.5-java at all given the
fact that it is not needed at build-time. I would rather tend to
completely remove the build-dependency and the corresponding dependency
on libservlet2.5-java but not before I have checked that all
reverse-dependencies do not rely on this behaviour.

Can you provide an example what package in Debian would be negatively
affected if we started to build-depend/depend on libservlet3.1-java?

Regards,

Markus



signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#801026: osgi-compendium: depends on obsolete libservlet2.5-java library

[Neil Bartlett]

This isn’t really possible. The osgi-compendium package is not just a program 
or library; it represents a specification published by a standards body, the 
OSGi Alliance. The specification supports the java servlet API 2.5 and above. 
We cannot simply update to 3.1 since that could break any consumers using 2.5 — 
also the package would not comply with the published specification.

Neil Bartlett
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#801026: osgi-compendium: depends on obsolete libservlet2.5-java library

[Markus Koschany]

Package: osgi-compendium
Severity: normal
User: pkg-java-maintainers@lists.alioth.debian.org
Usertags: oldlibs libservlet2.5-java

Hi,

osgi-compendium depends or build-depends on libservlet2.5-java, which is 
obsolete and
was replaced by libservlet3.1-java. osgi-compendium should be ported to the new
libservlet3.1-java version, so that we can remove the old, unmaintained one.

In most cases the switch should be straightforward and can be accomplished by
simply changing the dependencies in debian/control.

If you have any questions don't hesitate to ask and contact us on

debian-j...@list.debian.org

Regards,

Markus

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.