[jboss-as7-dev] cant get rid of jetty maven plugin - so lets mavenize JBoss Modules

[Brian Stansberry]

On 2/26/13 2:52 PM, Stuart Douglas wrote:
>
>
> Bill Burke wrote:
>>
>> On 2/25/2013 8:07 PM, Brian Stansberry wrote:
>>>> * I'd like to change the JBoss AS distribution to use this new
>>>> jboss-modules maven artifact feature.  This requires modifying
>>>> module.xml creation as well as creating and distributing a local maven
>>>> repository with the jars needed.
>>>>
>>> This is a pretty big change for our distribution model, particularly for
>>> doing things like shipping patches. Sounds interesting as an alternative
>>> form of distribution though. It might work fine as the only form of
>>> distribution, although I think we'd need to pretty thoroughly vet it
>>> before making that move.
>>>
>>
>> I agree its an idea that needs to be vetted.  But here's what a distro
>> would look like:
>>
>> bin/
>> standalone/
>> modules/
>> jboss-maven-repository/
>>
>> The interesting thing is that you can have a distro without the
>> repository.  Patching would change to adding a new jar to the maven
>> repository instead of the modules directory.
>>
>>
>> Furthermore, since the modules/ directory wouldn't have any jars you
>> move it under the profile's directory:
>>
>> bin/
>> standalone/
>>              modules/
>> web-profile/
>>              modules/
>> soa-profile/
>>              modules/
>> data-profile/
>>              modules/
>>
>> I said this in a previous email, but it doesn't make much sense to me
>> why build-time, run-time, and the OS all have their own special way of
>> distributing and managing java binaries.
>>
>
> I think that this is something that is definitely worth investigating.
> It is something that has been talked about before, but nothing that went
> past the hand wavey stage.
>
> I think it does open up some interesting possibilities for patching as
> well. If you zip up all the module.xml files in the AS they come to
> 300k, which means that for a 'patch' you could basically just distribute
> a whole new set of modules, and just have the patch tool download any
> jars that are missing into the local repository. This should mean that
> there is no need to use overlays or any sort of layering mechanism.
>

That can work if we rework how the patch staging/application process 
works. If a patch is a layer, the new module.xml files can be copied to 
disk (staged) but are effectively invisible to jboss-modules until the 
process is restarted. If we completely replace the files, we'll have to 
do the filesystem replacement work after the system is down.

Either way this question is unrelated to the binaries; i.e. whether 
patches add a layer or just completely replace the module.xml files, the 
binaries can be handled via a repo.


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat