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

[David M. Lloyd]

On 02/27/2013 09:34 AM, Bill Burke wrote:
>
>
> On 2/26/2013 4:21 PM, Stuart Douglas wrote:
>>
>>
>> Brian Stansberry wrote:
>>>> 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.
>>
>> I actually mean't that a complete set of module.xml files would just be
>> unzipped in a separate location in the AS (/modules/versions/eap_6.2.54
>> or whatever). JBoss modules would still need to know which module root
>> to point at. The main difference would be that each patch is a complete
>> set of module.xml files.
>>
>> Stuart
>>
>
> Wouldn't a maven-repo backed set of module files make the -jar option
> more feasible?  The JBoss Modules -jar option with JBoss AS would
> require a 170M file...

I assume when you say "-jar option" you mean "whole repos in a JAR"? 
JBoss Modules can launch a JAR via -jar while still having an external 
module repository (the JAR is run in a module and may include module 
dependencies).

-- 
- DML