Re: [wildfly-dev] smaller footprints

Great work Stuart! I'm really happy somebody is taking initiative on this because I really think it will help a lot with Wildfly adoption. Is it ready to use? I'm willing to try it out RIGHT NOW.

I've expressed some of these thoughts months ago when I introduced the JBoss Modules artifact features, but here was my vision: * maven repos would become to Wildfly as /lib /usr/local/lib directory structures are to unix. * The JBoss Module artifact feature would become the preferred way to deploy Wildfly/JBoss. This would make it really easy to support multiple versions as well as different distro's of JBoss/Wildfly on the same machine and save huge amounts of disk space. If we could get a JVM that could share JAR instances between processes to save on RAM, the win would be even bigger! Think of the cloud implications!

* JBoss Module definitions could eventually be defined in one large XML file. We would have maven/ant plugins to help build this large XML file. * This single JBoss Module XML file could be bundled within a JBoss/Wildfly "executable jar". * This "executable jar" could be overlayed with external JBoss Module XML files or directory structures. * Finally, you could create this "executable jar" for any Java project. On 3/4/2014 1:37 AM, Stuart Douglas wrote: > I have made a start on this split, and I think the solution I am working > on will meet all the use cases, including users that want to cut down an > existing server, and users that want to re-use the jars in their maven > repo using Bill's changes to JBoss Modules. It still needs a bit more > work and a lot of cleanup, however it seems to work: > > https://github.com/stuartwdouglas/wildfly/compare/wildfly-build-plugin > > So basically the core of it is a maven plugin that builds a Wildfly > distribution, either from scratch or use other distributions as a base. > > It also supports building servers that use the new <artifact> > functionality in jboss modules, and cutting down an existing server into > a smaller server with only the specified modules (and their transitive > dependencies). > > The way this will work in practice is that each Wildfly sub project will > produce two different server artifacts, one of which is a server without > any jars using artifact references, and a more traditional version with > jars packaged in the module directory. Downstream projects will consume > the smaller version without all the jars, so when a version changes the > download should be less than 5mb rather than larger than 100mb (the > plugin has the ability to turn a server that uses artifact references > into a server that contains the jars in the modules dir). > > Basically the upshot is that it should be basically possible to build > whatever configuration of server you want once this is part of our build > process, and we should also be publishing lightweight server artifacts > that use the jars in the maven repo as well as our traditional > 'everything and the kitchen sink' build. > > It is anticipated that 3rd party projects build on Wildfly would also > use this plugin (I think at the moment the standard approach has been to > copy and modify our ant scripts). > > This is still very much a work in progress, so nothing is set in stone > yet and any comments are welcome. > > Stuart > > > Bill Burke wrote: >> A lot of users want that ability, would you rather have them roll Netty >> + whatever? >> >> On 2/23/2014 9:10 PM, Stuart Douglas wrote: >>> No, because that means we essentially have to support and test every >>> possible combination that someone might select. >>> >>> Stuart >>> >>> >>> On Mon, Feb 24, 2014 at 7:13 AM, Misty Stanley-Jones&lt;misty(a)redhat.com >>> <mailto:misty@redhat.com>> wrote: >>> >>> I know you guys aren’t there yet, but can we think about wrapping a >>> GUI around this, so that the developer only needs to tick the boxes >>> for what he does/doesn’t want, with dependencies sorted out >>> automatically? Maybe some default profiles that select a group of >>> things, but the ability to go in and add or remove individual >>> subsystems as needed? Maybe this could be part of the installer but >>> could optionally be run post-install as well. >>> >>> On Feb 22, 2014, at 2:01 AM, Brian Stansberry >>> <brian.stansberry@redhat.com<mailto:brian.stansberry@redhat.com>> >>> wrote: >>> >>> > When I said "Web" I meant the thing described on that wiki >>> page Tomaz >>> > linked: >>> > >>> > "Web >>> > >>> > Undertow subsystem, and all related dependencies, including >>> a small >>> > subset of EE and JNDI. This is basically just a Servlet >>> container, and >>> > will provide a platform for people that want to create web >>> based >>> > appliances or applications, and don't need all the additional >>> > functionality that Wildfly provides. We should end up with >>> something as >>> > lightweight as Tomcat or Jetty, but with all our advanced >>> management >>> > functionality." >>> > >>> > On 2/21/14, 9:40 AM, Bill Burke wrote: >>> >> Its also "Web" minus some stuff. For my project I want just >>> Servlet, >>> >> JAX-RS, JPA, and datasources. Its very very hard to >>> figure out >>> how to >>> >> remove a subsystem and all its associated modules. >>> >> >>> >> BTW, I think my maven artifact thing got into JBoss >>> Modules. So it >>> >> would be possible to load jars on demand, or at least use >>> it as >>> a way to >>> >> figure out which modules aren't being used ;). >>> >> >>> >> >>> >> On 2/21/2014 10:22 AM, Brian Stansberry wrote: >>> >>> This will move things in the right direction, but not all the >>> way there >>> >>> yet. Note the set of capabilities Bill mention: web, CDI, >>> JAX-RS, JPA. >>> >>> That sounds like our "Web" variant, plus some stuff. It's the >>> easy "plus >>> >>> some stuff" part that needs sorting at some point. >>> >>> >>> >>> On 2/21/14, 9:08 AM, Tomaž Cerar wrote: >>> >>>> Bill, >>> >>>> >>> >>>> that is exactly idea we have in mind of 9. >>> >>>> We already started with producing WildFly core >>> distribution in >>> that is >>> >>>> WildFly with no subsystems, upon which you can build you own >>> wildfly. >>> >>>> It is only 15mb and contains whole mgmt capabilites (CLI, >>> standalone, >>> >>>> domain,...) you can grab it at: >>> >>>> >>> >>> http://download.jboss.org/wildfly/8.0.0.Final/core/wildfly-core-8.0.0.Fin... >>> >>> >>> >>>> >>> >>>> For 9 we have plans to move things bit further and have >>> decided that we >>> >>>> will also do split codebase for core, ee, web, .. and other >>> distributions. >>> >>>> >>> >>>> Current idea on code split up is here >>> >>>> >>> https://community.jboss.org/wiki/SplittingUpTheWildflyCodeBase >>> >>>> >>> >>>> -- >>> >>>> tomaz >>> >>>> >>> >>>> >>> >>>> >>> >>>> On Fri, Feb 21, 2014 at 3:00 PM, Bill >>> Burke&lt;bburke(a)redhat.com >>> <mailto:bburke@redhat.com> >>> >>>> <mailto:bburke@redhat.com<mailto:bburke@redhat.com>>> >>> wrote: >>> >>>> >>> >>>> On Resteasy list I have a few people "rolling their own >>> app server" >>> >>>> using Netty, Weld, Resteasy and JPA. I asked one of >>> them >>> "I don't >>> >>>> understand why you are rolling your own app server" >>> response: >>> >>>> >>> >>>> "It's actually a lot more lightweight. The minimum >>> I can >>> run the >>> >>>> equivalent on AS7 on is ~ 180 mb in binaries, but >>> throwing this >>> >>>> together is about 32 mb (and compresses further when >>> its >>> packaged). >>> >>>> I'm able to start the JVM on the bare minimum >>> (~100mb on >>> my linux VM) >>> >>>> but AS7 with all I need is about 756mb. When >>> rolling out >>> in the >>> >>>> cloud, where all of my REST APIs are stateless, running >>> with this >>> >>>> configuration helps us get a lot more per node." >>> >>>> >>> >>>> I'm not complaining :), just something to think >>> about. It >>> might be >>> >>>> really valuable to focus a bit in Wildfly 9 to make it >>> easier to create >>> >>>> custom profiles or even different packaging options for >>> the app server >>> >>>> instead of the exploded style we currently have. >>> >>>> -- >>> >>>> Bill Burke >>> >>>> JBoss, a division of Red Hat >>> >>>> http://bill.burkecentral.com >>> >>>> _______________________________________________ >>> >>>> wildfly-dev mailing list >>> >>>> wildfly-dev(a)lists.jboss.org >>> <mailto:wildfly-dev@lists.jboss.org> >>> <mailto:wildfly-dev@lists.jboss.org >>> <mailto:wildfly-dev@lists.jboss.org>> >>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> wildfly-dev mailing list >>> >>>> >>> wildfly-dev@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org> >>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>>> >>> >>> >>> >>> >>> >> >>> > >>> > >>> > -- >>> > Brian Stansberry >>> > Senior Principal Software Engineer >>> > JBoss by Red Hat >>> > _______________________________________________ >>> > wildfly-dev mailing list >>> > wildfly-dev@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org> >>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> Misty Stanley-Jones, RHCE >>> Manager, Content Services (Middleware) >>> Direct: + 61 7 3514 8105<tel:%2B%2061%207%203514%208105> / Mobile: >>> +61 429 595 932<tel:%2B61%20429%20595%20932> (TZ: GMT+10) >>> IRC: misty (Freenode / RH) >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >