----- Original Message -----
> From: "Stanislav Ochotnicky" <sochotnicky@xxxxxxxxxx>
> To: "Fedora Java Development" <java-devel@xxxxxxxxxxxxxxxxxxxxxxx>
> Sent: Thursday, May 10, 2012 5:31:58 PM
> Subject: 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
> deps).
>
> 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.
I propose this being to be the implementation of the latest version with smallest number of dependencies - both runtime and build time. This should work pretty well as the packages that can work with whatever implementation are easy to port to new version too.
> 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
> ...
> %files
> %{_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
> and:
> 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?
This proposal pretty much matches the osgi bundle names see http://download.eclipse.org/tools/orbit/downloads/drops/R20120119162704/
javax.activation
javax.annotation
javax.el
javax.inject
javax.jws
javax.mail
javax.management
javax.management.remote
javax.persistence
javax.security.auth.message
javax.servlet
javax.servlet.jsp
javax.servlet.jsp.jstl
javax.transaction
javax.ws.rs
javax.wsdl
javax.xml
javax.xml.bind
javax.xml.rpc
javax.xml.soap
javax.xml.stream
javax.xml.ws
So sticking close to each other would be even better.
>
> 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.
No versions needed for the default. Every package that doesn't stick to the default should pick implementation on its own or ask for help to get ported.
I really like the proposal.
Alex
>
> How does this sound to you all?
>
>
> [1] http://fedoraproject.org/wiki/Packaging:Alternatives
>
>
> --
> Stanislav Ochotnicky <sochotnicky@xxxxxxxxxx>
> Software Engineer - Base Operating Systems Brno
>
> PGP: 7B087241
> Red Hat Inc. http://cz.redhat.com
> --
> java-devel mailing list
> java-devel@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/java-devel
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel
