From: "Bill Burke" <bburke(a)redhat.com&gt; To: "JBoss AS7 Development" <jboss-as7-dev(a)lists.jboss.org&gt; Sent: Monday, February 25, 2013 4:18:07 PM Subject: [jboss-as7-dev] cant get rid of jetty maven plugin - so lets mavenize JBoss Modules JBoss AS and jboss-as-maven-plugin just doesn't meet my needs, so I've started the process of fixing it. I have some initial code, but I need to know that my suggestions and pull-requests will be accepted before I proceed with the rest of the changes I would need to make. What missing or very hard to do: * Jetty maven plugin is great because there is no pre-installation needed. It builds your war, automatically downloads jetty and runs it in embedded mode, then runs your tests (if you have maven pom configured right). I'd like to replace this with JBoss AS....But...it is just not feasible. jboss-as-maven-plugin does download the AS7 ZIP artifact if jboss isn't running already, but...it unzips the zip into every maven projects target/ directory. FOR EVERY PROJECT. So, if you have more than one test, you are unzipping 100M+ PER PROJECT. This is just unworkable. * I need the above for my O'Reilly Restful Java book examples. Currently I use Jetty and I can't replace with jboss-as-maven-plugin. I refuse to require download/install of jboss and will just stick to jetty if I must. * If you are developing on a subsystem integration on AS codebase, as you build your submodule, you need to either rebuild the distribution, or copy the library to the built JBoss distribution. Its just a pain. I'd like to remove this step and streamline integration module development. * I'd like to have automated AS integration tests in the Resteasy build. This sucks because of the previous problems. Not only is an unzip of AS required per maven project, but I need to override resteasy speific AS modules with the current resteasy build. * You can't distribute a profile of a complete jboss install without distributing *EVERY* jar it depends on. What I'm doing to fix it: * I've got a pull request for JBoss Modules that allows you to specific a maven repository artifact instead of a path for a resource-root: i.e. <resources> <resource-root group="org.jboss.resteasy" artifact="resteasy-jaxrs" version="3.0-beta-4"/> <resource-root group="org.jboss.resteasy" artifact="resteasy-client" version="3.0-beta-4"/> </resources> Looks in the local maven repository for the artifact, if not there, barfs unless you've pointed a system property to a remote maven repository. Then it will download the artifact with a nice updated download-progress message displayed on the console window. Here's my pull request: https://github.com/jbossas/jboss-modules/pull/28 * 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. * Besides the modified distro, I'd like a new maven artifact that is just a zip of the JBoss AS directory structure and the corresponding configuration files. No jars. * I want to rev jboss-as-maven-plugin to take advantage of these new features and distros. Specifically: - Allow a src/jboss directory so that users can provide their own config files that are overlayed on top of the config-only AS distro. - Make config-only AS distro something you can reference as an artifact dependency - provide in-pom support for defining new and override modules. I hope you can see that not only does this make development easier, but it also opens the door define JBoss AS profiles that can easily be exchanged and distributed. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I'm definitely not opposed to changing the way zip is downloaded and/or extracted. It was originally done like this to get something working as I wasn't sure how much it was going to be used to be honest. Probably not really a good excuse, but it's the reason :-)

I am just getting to release a new version that does have a start and shutdown goal so they can be used in integration testing. I do wonder though in the cases where these goals were requested why not use Arquillian and the reason I got was basically that they added custom modules before they run the integration test. This likely could be achieved with either ARQ or the maven plugin by defining the JBOSS_HOME. The maven config could get rather messy, but it would work for sure.

As far as the JBoss Modules part, that's up to David and don't quote me, but I think he rejected something like that before. Again though that's all up to him.

> * 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.

On 2/25/2013 8:32 PM, Bill Burke wrote: > 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. > This is a win on the OS distribution side as well as you manage JARs similarly to shared-libraries and share these jar binaries between multiple jboss instances that may or may not have uniform jars. You also interact with them similarly to shared libraries in that you'd have a jboss-modules equivalent to LD_LIBRARY_PATH in which you can set a hierarchy of local and remote repositories....Works seemlessy cross-platform too. Build, runtime, and OS all using the same directory structure to manage jars.

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.

On 2/26/2013 1:17 PM, Brian Stansberry wrote: > On 2/25/13 7:32 PM, 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. >> > > Yep. If the maven repo is "owned" by the AS installation, it seems > pretty straightforward. If the repo is not owned (e.g. it's the user's > standard local maven repo) then it's a problem. That's why the default would point to the distribution. > For example, see the > David Jorm's comments on > https://community.jboss.org/wiki/SingleInstallationPatching about > disabling jars. > David Jorm's security concern seems pretty bogus to me. An old jar could be accidentally or inadvertently be used in running code? We're talking about modules here. What do OS's do? OS's definitely support multiple versions of a library on the same platform. > There's no law though that says we have to support patching no matter > how a user configures their installation. > >> >> 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/ >> > > Is this a core part of what you're going for, or just a further path it > might take? Its a path it might take or could take. Its like, hey I want to build a IDP, or roll a specific bundle of JBoss AS plus the latest/greatest Resteasy, or whatever...I don't have to distribute a 170M download anymore.... > This concerns me more than the rest. We don't have > "standalone", "web-profile", "soa-profile" etc. If these are > user-defined structures, then patching them becomes a royal pain. We have this problem already, considering AS7 hasn't had a release in 1 year projects like Resteasy are forced to distribute a modules zip file that overrides the current installation. The > patch tool has no clue how the patch relates to the user's installation. > If they are structures defined by us, we'd need one for every > permutation we offer, and that will be a very large set. > Patch tool updates module.xml files (via an unzip) and > Also, it doesn't map well to domain mode, where a domain configuration > covers multiple profiles. > Ok, well, I guess its time for me to move on to something else...It was worth a try, unfortunate you all don't see the benefits...

From: "Stuart Douglas" <stuart.w.douglas(a)gmail.com&gt; To: "Bill Burke" <bburke(a)redhat.com&gt; Cc: jboss-as7-dev(a)lists.jboss.org Sent: Tuesday, February 26, 2013 3:52:18 PM Subject: Re: [jboss-as7-dev] cant get rid of jetty maven plugin - so lets mavenize JBoss Modules 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. Stuart > > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I probably should mention my motivations... The future generation of RPMs will install the JAR files in a maven layout, so we just need to point the modules.xml to that location. No more symlinks!

Also, the ZIP will be the same as the RPM, just with a different location for the maven repo in modules.xml ----- Original Message ----- > From: "Fernando Nasser" <fnasser(a)redhat.com&gt; > To: "Stuart Douglas" <stuart.w.douglas(a)gmail.com&gt; > Cc: jboss-as7-dev(a)lists.jboss.org > Sent: Tuesday, February 26, 2013 4:11:51 PM > Subject: Re: [jboss-as7-dev] cant get rid of jetty maven plugin - so lets mavenize JBoss Modules > > Can I add just a bit more of fuel to this fire? > > Can we have a maven: URI so we can just give GAV (separated by ':") > and > have the maven repo location(s) in a modules.xml configuration file. > > JBoss Modules would read that for the maven: URIs and search the > maven repos > in order using the standard maven repo layout. > > > > > ----- Original Message ----- >> From: "Stuart Douglas" <stuart.w.douglas(a)gmail.com&gt; >> To: "Bill Burke" <bburke(a)redhat.com&gt; >> Cc: jboss-as7-dev(a)lists.jboss.org >> Sent: Tuesday, February 26, 2013 3:52:18 PM >> Subject: Re: [jboss-as7-dev] cant get rid of jetty maven plugin - >> so lets mavenize JBoss Modules >> >> >> >> 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. >> >> Stuart >> >>> >>> >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

From: "Jesse Sightler" <jsightle(a)redhat.com&gt; To: jboss-as7-dev(a)lists.jboss.org Sent: Tuesday, February 26, 2013 4:29:56 PM Subject: Re: [jboss-as7-dev] cant get rid of jetty maven plugin - so lets mavenize JBoss Modules On 02/26/2013 04:23 PM, David M. Lloyd wrote: > On 02/26/2013 03:19 PM, Fernando Nasser wrote: >> I probably should mention my motivations... >> >> The future generation of RPMs will install the JAR files in a >> maven layout, so we just need to point the modules.xml to that >> location. >> No more symlinks! > It will be just in time to be obsolete again. TBH I don't think > this is > a smart move at all; Maven isn't the end state for Java build, and > it > makes zero sense for Java distribution other than development/test > time. Well, this is true of essentially everything. For example, I love JBoss Modules, but I doubt it is the "end state" for Java module systems. :-) OTOH, the Maven repository layout (not necessarily the build system itself) has held up extremely well over the past several years. I don't really see any being good enough to convince people to dump the entire Maven repolayout anytime during the next few years. I don't really know of any alternative Java build systems that are even seriously trying to replace this aspect. I agree that depending on Maven the build tool makes little sense. > >> Also, the ZIP will be the same as the RPM, just with a different >> location for the maven repo in modules.xml >> >> >> >> ----- Original Message ----- >>> From: "Fernando Nasser" <fnasser(a)redhat.com&gt; >>> To: "Stuart Douglas" <stuart.w.douglas(a)gmail.com&gt; >>> Cc: jboss-as7-dev(a)lists.jboss.org >>> Sent: Tuesday, February 26, 2013 4:11:51 PM >>> Subject: Re: [jboss-as7-dev] cant get rid of jetty maven plugin - >>> so lets mavenize JBoss Modules >>> >>> Can I add just a bit more of fuel to this fire? >>> >>> Can we have a maven: URI so we can just give GAV (separated by >>> ':") >>> and >>> have the maven repo location(s) in a modules.xml configuration >>> file. >>> >>> JBoss Modules would read that for the maven: URIs and search the >>> maven repos >>> in order using the standard maven repo layout. >>> >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Stuart Douglas" <stuart.w.douglas(a)gmail.com&gt; >>>> To: "Bill Burke" <bburke(a)redhat.com&gt; >>>> Cc: jboss-as7-dev(a)lists.jboss.org >>>> Sent: Tuesday, February 26, 2013 3:52:18 PM >>>> Subject: Re: [jboss-as7-dev] cant get rid of jetty maven plugin >>>> - >>>> so lets mavenize JBoss Modules >>>> >>>> >>>> >>>> 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. >>>> >>>> Stuart >>>> >>>>> >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On 02/26/2013 03:19 PM, Fernando Nasser wrote: > I probably should mention my motivations... > > The future generation of RPMs will install the JAR files in a maven layout, so we just need to point the modules.xml to that location. > No more symlinks! It will be just in time to be obsolete again. TBH I don't think this is a smart move at all; Maven isn't the end state for Java build, and it makes zero sense for Java distribution other than development/test time.

On 2/26/2013 4:23 PM, David M. Lloyd wrote: > On 02/26/2013 03:19 PM, Fernando Nasser wrote: >> I probably should mention my motivations... >> >> The future generation of RPMs will install the JAR files in a maven layout, so we just need to point the modules.xml to that location. >> No more symlinks! > > It will be just in time to be obsolete again. TBH I don't think this is > a smart move at all; Maven isn't the end state for Java build, and it > makes zero sense for Java distribution other than development/test time. > Can you please share with us exactly how using a maven repo makes no sense?

I keep waiting to hear your legendary insight, but instead I'm just getting a bunch of unsubstantiated claims and some nonsense that maven repos aren't going to exist in the future...Myself and others have given some pretty compelling use cases. It would be nice to hear a counter-argument so we can have a real discussion over this instead of just excepting your word as gospel.

<module> <resources> <resource-root group="org.jboss.resteasy" artifact="resteasy-jaxrs" version="3.0"/> </resources> </module>

> 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.

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...

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.

...and I bet most of that 300k is copyright notices.