FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development Java

LinkBack Thread Tools
Old 05-10-2012, 02:31 PM
Stanislav Ochotnicky
Default Handling of EE apis and other multiple implementations

Hi all,

we have been having long-standing issues with multiple implementations
of the same APIs (javax.servlet, javax.servlet.jsp, etc). Namely we
don't handle them at all. They work in Maven through our dependency
mapping, but are not really usable during runtime.

What I mean is for example several packages requiring javax.servlet
implementation, but in reality they have to pick one of several RPMs we
have. This inevitably leads to bloated installations when users
inevitably end up with more than one implementation installed (and their

There has always been a solution for this, which is using alternatives
system[1]. We haven't used it, mostly because relatively complicated
nature. So I went looking into simplifying it with rpm macros. Long
story short...this didn't turn out well mostly due to different
implementations needing different things on classpath.

Ergo: I would like to propose a standardization on naming and use of
java EE APIs.

There are several aspects of this:
1. We need to chose 1 implementation to serve as "THE" implementation
for each API.
2. That package will get to "Provides: EEAPI". Other packages can stop
pretenting to provide any EE api :-) They can of course be used
directly if a package requires something specific.
3. Since packages will be using "Requires: EEAPI" we can switch
implementations easily if the need arises (dead project, new major
version etc.)

Now, I would like to standardize EEAPI naming as well. We have several
versions of this. For example from tomcat.spec:

Provides: jsp = %{jspspec}
Provides: jsp22
... # other package
Provides: el_1_0_api = %{epoch}:%{version}-%{release}
Provides: el_api = %{elspec}
... # other package
Provides: servlet = %{servletspec}
Provides: servlet6
Provides: servlet3

So it looks like we are not consistent and I would like to fix that. My
first idea was to have:

Provides: javax.xml
%{_javadir}/javax.xml.jar # this is symlink

Then I realized JSP is "javax.servlet.jsp", and Servlet API is a
superset so first 2 parts of package name would not be enough there. We
could still have:

Provides: javax.servlet # in servlet impl
Provides: javax.servlet.jsp # in jsp impl

To be clear: I want the names to be simple to deduce without going
through spec files, searching with yum (much) etc. The simpler the
better. I would hope Java devs chime in here. What would be the first
thing that came to your mind here?

As for versioning APIs, I am not sure that would be needed. We usually
try to keep packages up to date with latest APIs and packages not
supporting current API can be moved to an older implementation.

How does this sound to you all?

[1] http://fedoraproject.org/wiki/Packaging:Alternatives

Stanislav Ochotnicky <sochotnicky@redhat.com>
Software Engineer - Base Operating Systems Brno

PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
java-devel mailing list

Thread Tools

All times are GMT. The time now is 05:17 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org