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. 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?
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
----- Original Message -----
From: "Stanislav Ochotnicky" sochotnicky@redhat.com To: "Fedora Java Development" java-devel@lists.fedoraproject.org Sent: Thursday, May 10, 2012 5:31:58 PM Subject: [fedora-java] 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:
- 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.
- 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@redhat.com Software Engineer - Base Operating Systems Brno
PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
Quoting Aleksandar Kurtakov (2012-05-10 16:55:14)
Ergo: I would like to propose a standardization on naming and use of java EE APIs.
There are several aspects of this:
- 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.
Agreed there. Minimal dependencies are a major selling point for me as well. Unless of course there is some deficiency in the implementation.
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.
Note to all, that we have a working draft[1] for new guidelines. There are a few improvements (better explanation of %add_maven_depmap macro, few more hints here and there), removal of old guideline cruft (mostly maven2 related) and now I've added an initial EE api packaging guideline.
See [2] for a diff against current guidelines. Feel free to tweak, add, improve. We can review/fix/revert whatever changes come in later before putting it to a vote during our overdue SIG meeting.
One thing I wonder about adding is that each javax.XX providing package should also install additional file which would basically constitute needed classpath to run the implementation (i.e. arguments for build-classpath). For example "glassfish-jsp-api" would need "glassfish-jsp" on the classpath so it would install let's say: %{_javadir}/javax.servlet.jsp.classpath (just an idea) and this would contain: glassfish-jsp
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.
[1] https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate [2] http://goo.gl/GYrOf
On 05/11/2012 11:53 AM, Stanislav Ochotnicky wrote:
Quoting Aleksandar Kurtakov (2012-05-10 16:55:14)
Ergo: I would like to propose a standardization on naming and use of java EE APIs.
There are several aspects of this:
- 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.
Agreed there. Minimal dependencies are a major selling point for me as well. Unless of course there is some deficiency in the implementation.
Not all implementations follow the same functionality. In some cases defaults are provided within the implementation.
Carlo
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.
Note to all, that we have a working draft[1] for new guidelines. There are a few improvements (better explanation of %add_maven_depmap macro, few more hints here and there), removal of old guideline cruft (mostly maven2 related) and now I've added an initial EE api packaging guideline.
See [2] for a diff against current guidelines. Feel free to tweak, add, improve. We can review/fix/revert whatever changes come in later before putting it to a vote during our overdue SIG meeting.
One thing I wonder about adding is that each javax.XX providing package should also install additional file which would basically constitute needed classpath to run the implementation (i.e. arguments for build-classpath). For example "glassfish-jsp-api" would need "glassfish-jsp" on the classpath so it would install let's say: %{_javadir}/javax.servlet.jsp.classpath (just an idea) and this would contain: glassfish-jsp
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.
[1] https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate [2] http://goo.gl/GYrOf
----- Original Message -----
From: "Carlo de Wolf" cdewolf@redhat.com To: java-devel@lists.fedoraproject.org Sent: Friday, May 11, 2012 12:57:57 PM Subject: Re: [fedora-java] Handling of EE apis and other multiple implementations
On 05/11/2012 11:53 AM, Stanislav Ochotnicky wrote:
Quoting Aleksandar Kurtakov (2012-05-10 16:55:14)
Ergo: I would like to propose a standardization on naming and use of java EE APIs.
There are several aspects of this:
- 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.
Agreed there. Minimal dependencies are a major selling point for me as well. Unless of course there is some deficiency in the implementation.
Not all implementations follow the same functionality. In some cases defaults are provided within the implementation.
This is supposed to be used only by package that need only the API as defined by some JSR. All other use cases are hopeless and packages would have to choose what they work with for a number of reasons.
Alex
Carlo
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.
Note to all, that we have a working draft[1] for new guidelines. There are a few improvements (better explanation of %add_maven_depmap macro, few more hints here and there), removal of old guideline cruft (mostly maven2 related) and now I've added an initial EE api packaging guideline.
See [2] for a diff against current guidelines. Feel free to tweak, add, improve. We can review/fix/revert whatever changes come in later before putting it to a vote during our overdue SIG meeting.
One thing I wonder about adding is that each javax.XX providing package should also install additional file which would basically constitute needed classpath to run the implementation (i.e. arguments for build-classpath). For example "glassfish-jsp-api" would need "glassfish-jsp" on the classpath so it would install let's say: %{_javadir}/javax.servlet.jsp.classpath (just an idea) and this would contain: glassfish-jsp
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.
[1] https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate [2] http://goo.gl/GYrOf
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
Quoting Stanislav Ochotnicky (2012-05-11 11:53:40)
One thing I wonder about adding is that each javax.XX providing package should also install additional file which would basically constitute needed classpath to run the implementation (i.e. arguments for build-classpath). For example "glassfish-jsp-api" would need "glassfish-jsp" on the classpath so it would install let's say: %{_javadir}/javax.servlet.jsp.classpath (just an idea) and this would contain: glassfish-jsp
Mikolaj's questions on the discussion page made me think of a better solution (already in the draft):
* %{_javadir}/javax.XXX will be a directory * this dir will contain all jars (symlinks) needed to use this API (api and impl)
This means things should work like this:
$ build-classpath javax.servlet.jsp /usr/share/java/javax.servlet.jsp/glassfish-jsp-api.jar:/usr/share/java/javax.servlet.jsp/glassfish-jsp.jar
This is currently broken due to a bug in build-classpath script that causes it to ignore symlinks to jar files. Possible issue here is that other distributions taking our packages will be hitting weird bugs due to this so we should get this into upstream. I don't see why they used "-xtype f" in find instead of "-type f". Anyone knows?
java-devel@lists.fedoraproject.org