12:14 p.m.
On 20 Apr 2010, at 01:37, Steven Boscarine wrote:
As Dan pointed out, if we run that new BOM alone, we're missing:
• javax.faces:jsf-api:jar
• javax.enterprise:cdi-api:jar
• javax.annotation:jsr250-api:jar
• javax.validation:validation-api:jar
These specs will be added into the next release of the BOM.
The issue here is that the dependency name space for this new BOM
doesn't match the ones we used because they're all prefixed with org.jboss.spec.*
and have different version numbers.
Yes. As we discussed though, JBoss can't publish to the javax. namespace, and Sun
won't/don't publish all their specs APIs into Maven (though maybe this is
changing?)
So the design question for the list is do we want to expose to
users:
<dependency>
<groupId>org.jboss.spec.javax.servlet</groupId>
<artifactId>jboss-servlet-api_3.0_spec</artifactId>
<version>1.0.0.Beta2</version>
</dependency>
...or would we prefer:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>3.0</version>
</dependency>
Either is perfectly valid and achieves the same bottom-line result. Both are the same
jar.
It's not the same JAR, but it is the same API (subtly different ;-)
On one hand, I prefer the javax.* because it is more conventional and
in my opinion, more polished looking, especially for people who choose to run weld or Java
EE outside of a JBoss container.
Agreed. However even if we decided to maintain a BOM for this, we couldn't have it
100% using javax. as some specs in EE6 are missing published Maven artifacts. So, the
question becomes whether it is worth doing a split one?
On the other hand, it would be preferable if the JBoss AS team
maintained a BOM for each point release of JBoss AS with the precise point release of each
API shipped with their container.
Yes, this is what they are doing from now on.
I imagine this is relatively important for the AS team as I am guessing a non-trivial
number of errors in the wild occur due to library version mismatches. Perhaps maintaining
a good set of archetypes that match your container precisely will either reduce these or
at least give the developers less of an excuse for these errors?
What options are available?
Shelly, are you willing to allow both the javax.* and the org.jboss.spec.javax.* entries
in the BOM?
Personally, I don't think this is a good idea. It would be better to maintain a
separate BOM for the javax. ones.
If we could maintain the same namespace for dependencies (javax.servlet, for example) for
every container, then a user could use one pom and change the BOM to match his/her precise
container version (Glassfish v3 vs JBoss AS 6.0.0 or JBoss AS 6.0.1). The AS project can
use the org.jboss.spec.* jars as before and just help out keeping the javax.* entries up
to date as new releases are performed.
An example where this would be an issues is javax.enterprise.cdi-api. JBoss AS has no
use for a CDI-API 1.0.0 as they're using 1.0.1, however, to use the BOM and have it
work on Glassfish v3 and JBoss AS 6, JBoss would have to upload weld 1.0.0 as
org.jboss.spec.javax.enterprise.cdi-api (if the javax.* entries weren't in the BOM).
I think this is the plan, but Shelly was working out the details.
Shelly, if you think that it's acceptable to keep both the normal jar name and the
org.jboss.spec jar name in the BOM, I can make the initial edits. IMO, this will really
pay off if the server team updates the versions of the individual jars down the road as
versions change for JBoss AS point releases. Otherwise, the archetype project will have
to duplicate a lot of effort to keep in sync with the server team.