[jboss-dev] Include Web Beans RI in next JBoss 5 release

[Andrew Lee Rubinger]

Jason T. Greene wrote:
> Once you start talking about resolving transitive dependencies from a 
> maven repository, as you do below, you need to either use the maven 
> code, or reimplement maven's logic.

It wouldn't necessarily be Maven resolving the dependencies.  Actually, 
until there's a pluggable resolution mechanism (ie. Mercury), we're 
nearly dead in the water.

Also, I made some Unit Tests last week proving that our versioning 
scheme (ie. X.Y.Z.qualifier) is incompatible with Maven's 
DefaultArtifactVersion, also unpluggable.  Parsing major, minor, 
incremental, etc components fails.  @see 
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution 
for correct form.

>> Envision AS as nothing more than a base runtime which supports 
>> arbitrary stuff to be deployed into it.  ...
> OK That does sound cool. However when you do a major feature upgrade to 
> something like EJB3, then  dependencies start to clash, and you can end 
> up with either major conflicts (and subsequent install failure), or an 
> entire app server update. Such a feature would be more interesting if we 
> had a number of services that are truly independent.

EJB3 is an interesting example as it aggregates just about everything 
else in JEE.  I don't see the problem with an EJB3 upgrade triggering 
what amounts to an "app server update".  If I upgrade Compiz, Fedora 
might update all of X11 if necessary.

> The real problem here is that our "configuration" files aren't 
> configuration, they are essentially a meta-language that exposes 
> internal implementation details that 99% of our users could care less 
> about.

It's true.  Also the files are too big, and become general dumping 
grounds for any configuration.  If in EJB3 I made separate configs for 
each MC Bean, there'd be a lot less for the user to touch should they 
ever need to, say, change the implementation of an @EJB resolver.

> The other issue is that user deployments and system deployments get 
> intermixed, but this can be resolved by giving users their own 
> deployment directory that is initially empty.

For AS6 I think we should discuss doing just that, and extend the idea 
to allow for configuration overrides.  ie. Anything component can be 
configured as default, but if declared again in the *user* deploy/conf 
dir, this overrides the default behaviour from a definition in the 
*system* dir.

S,
ALR

-- 
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com