Re: [jboss-dev] Include Web Beans RI in next JBoss 5 release
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+...
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