Re: [wildfly-dev] smaller footprints

In the original plan/writeup we had a separate clustering layer and EE layer. I guess the biggest limiting factor for those is cleaning up our dependencies. On Mar 5, 2014, at 4:55 AM, Stuart Douglas&lt;stuart.w.douglas(a)gmail.com&gt; wrote: > So now onto one of the hard problems, naming things... > > As a result of splitting up the server we are going to end up with a lot > more artifacts. Basically each repo will produce at least two servers, a > cut down server that uses the maven repo and a full server that is > similar to what we have at the moment, and we are going to need some > kind of consistent name for them. > > I am thinking maybe something like: > > wildfly-core-build (cut down server core build) > wildfly-core-build-dist (core + all jars) > wildfly-web-build (cut down wildfly server with just the Undertow subsystem) > wildfly-web-build-dist (as above, but with jars) > wildfly-build (cut down full server) > wildfly-build-dist (as above) > > Does anyone have any better ideas about what to call this stuff? > > One side effect of the above would be that the build directory will no > longer contain the full Wildfly server (just a version with no jars > present), and the full server would be in the dist directory instead. > > Stuart > > Stuart Douglas wrote: >> >> Bill Burke wrote: >>> 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. >> Sort of. You can build from my wildfly-build-plugin branch and it should >> work, but at the moment it is creating a build that includes all the >> jars. If you want to create a build that uses<artifact> you will need >> to modify the copy-module-artifacts attribute in ./build/server-build.xml . >> >> Eventually we will produce both versions, I should get to this some time >> today. >> >> Also this is very new, and may not work, but if you want to try it out >> feel free. Hopefully I will have something a lot more polished by the >> end of the week. >> >>> 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! >> I think we would need some kind of tool to make sure that a repo is >> fully downloaded if people wanted to use this in production. Even though >> download on demand is cool, you would not want a production server >> hanging as it attempts to download a jar. Not sure what sort of form >> this tool would take. >> >> Stuart >> >>> * 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 >>>>>> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat