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

[Jason T. Greene]

Andrew Lee Rubinger wrote:
> Comments inline.
> 
> Jason T. Greene wrote:
>> Carlo de Wolf wrote:
>>> That's the reason why we're working on the EJB3 plugin. It works in a 
>>> similar manner to the WB RI update. Use ant to patch AS.
>>>
>>> In future this is going to be handled by the patching functionality 
>>> of the Profile Service. It'll be backed up by a Maven repository 
>>> where it'll download the version of a bundle/package specified by the 
>>> administrator.
>>
>> Ugh, I really hope we reconsider integrating maven's buggy codebase 
>> into AS. 
> 
> No patch installer has to depend upon Maven itself - Carlo was referring 
> to our 3rdparty repo used to house binaries brought into AS.

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.
> 
>  > Further this kind of thing really only seems useful
>> for applying simple support patches, not so much for feature upgrades.
> 
> I disagree with you pretty infrequently; this is one of those times.
> 
> Feature / module upgrades allow each project a release cycle independent 
> of AS.
> 
> Envision AS as nothing more than a base runtime which supports arbitrary 
> stuff to be deployed into it.  Some upgrade/install mechanism should be 
> able to say:
> 
> "Install EJB3"
> 
> ...and then the installer kicks in to:
> 
> * Resolve all dependencies (+transitive)
> * Ensure compatibility
> * Download all dependencies (from Maven2 repo)
> * Install all dependencies (libraries and configs)
> * Download and install EJB3
> 
> Same for update.

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.

> 
>> It's perfectly fine for a component library to do their own AS upgrade, 
> 
> Kinda, but not really.  Because if the upgrade isn't 
> backwards-compatible with all of the projects which depend upon it, or 
> if the library demands upgrades to its own dependencies, things get ugly 
> quick.
> 
> So for a component library to upgrade itself, all of its dependencies 
> must be able to do the same.  Hence the recursive process I outlined 
> above, and Carlo's explained a bit before (I don't have written record 
> of where).

Right, it's a hack.

> 
>> however that doesn't escape the need for frequent AS releases. 
> 
> Agree.
> 
>> Also, updating a minor AS rev is simpler for users to manage, and all 
>> of the components are actually tested together.
> 
> Also agree.
> 
> Of course, the second that users start adding/changing their configs, 
> they have to merge their stuff with the new updates coming in, and 
> that's not always intuitive.  So a user will *think* they have 5.0.1, 
> but in actuality have a config that more resembles 5.0.0...
> 

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.

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.

-- 
Jason T. Greene
JBoss, a division of Red Hat