I blame Maven (of course :-P ).
Originally the intend of the javaee project was to centralize all APIs,
so people can use one simple artifact which represents JavaEE 5.
This makes it easy for both end-users and an EAP configuration. Problems
have arising with this approach in the JBossWS and Hibernate area. For
JBossWS we're one step ahead, for Hibernate it would introduce an
'outside' dependency. The same problem I have with EJB 3.1, so now we
also have jboss-ejb3-api 3.1.0-SNAPSHOT.
It all boils down to software configuration management within AS itself.
For this purpose Maven is clearly inadequate. Where I to put this in
Debian package I would have a lot of different packages providing
servlet-api-2.5 and let aptitude sort it out. This would also allow me
upgrade to another API without affecting other installed components. So
if I where to install javax.servlet-2.5, it would result in a conflict
with jboss-javaee-5.0 thus it would provide me with an alternative to
un-install jboss-javaee-5.0 and install all individual APIs (thus
providing me a fine grained upgrade path). (Note that yum is too limited
for these scenarios.)
So what I really need is proper software configuration management.
For the product we want jboss-javaee-5.0 to be authoritative, so exclude
all others.
Carlo
Dimitris Andreadis wrote:
There is a bit of overlapping in our API libraries.
E.g. for jsp-api.jar we have 2 jars with similar content, one from
JBossWeb and one coming
from Sun:
[INFO] +- jboss.web:jsp-api:jar:2.1.1.GA:compile
[INFO] +- javax.servlet.jsp:jsp-api:jar:2.1:compile
For the servlet-api.jar we have 3 jars with similar content. One comes
from our javaee apis
project, one from jboss web and one from Sun.
org.jboss.javaee:jboss-javaee.jar also bundles
jboss-servlet-api.jar:
[INFO] +- org.jboss.javaee:jboss-servlet-api:jar:2.5.0.GA:compile
[INFO] +- jboss.web:servlet-api:jar:2.1.1.GA:compile
[INFO] +- javax.servlet:servlet-api:jar:2.5:compile
The sun one is referenced by:
[INFO] +-
org.jboss.seam.integration:jboss-seam-int-jbossas:jar:5.0.0.CR7:compile
[INFO] | \- (javax.servlet:servlet-api:jar:2.5:compile - version
managed from 2.4
...
[INFO] +- httpunit:httpunit:jar:1.6:test
[INFO] | +- (javax.servlet:servlet-api:jar:2.5:test - version managed
from 2.3
...
[INFO] +- org.jboss.jaxr:juddi-saaj:jar:1.2.1.GA:compile
[INFO] | \- (javax.servlet:servlet-api:jar:2.5:compile - version
managed from 2.4
...
[INFO] +- org.jboss.jaxr:juddi-service:jboss-sar:1.2.1.GA:compile
[INFO] | \- (javax.servlet:servlet-api:jar:2.5:compile - version
managed from 2.4;
Our org.jboss.javaee one by EJB3.
What ends up in AS5 is the jsp-api/server-api that comes from
JBossWeb. Also the
jboss-javaee.jar that duplicates the server api classes.
---
So the question is how we want to proceed? I think we should end up
with a single copy of
the apis. We could either agree to:
a) Use the sun provided artifacts. If there are no license problems
that would be the
easiest solution. Many thirdparty project would be referencing those
artifacts, too.
b) Centralize the apis in our javaee project. The problem here is that
projects like JBossWS, JBossWeb, Hibernate, would have to agree to use
only those artifacts, rather than
duplicating them, or removing them and importing them into their
projects.
c) Continue the current mixed solution with projects controling the
related APIs, in which
case we should at least remove any duplicates, e.g. the jboss-javaee
servlet APIs.
Thoughts?
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development