[wildfly-dev] smaller footprints

Jason Greene jason.greene at redhat.com
Mon Mar 10 07:20:54 EDT 2014 

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 <stuart.w.douglas at gmail.com> 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<misty at redhat.com
>>>>>> <mailto:misty at 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 at redhat.com<mailto:brian.stansberry at 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.Final.zip
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 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<bburke at redhat.com
>>>>>> <mailto:bburke at redhat.com>
>>>>>>>>>> <mailto:bburke at redhat.com<mailto:bburke at 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 at lists.jboss.org
>>>>>> <mailto:wildfly-dev at lists.jboss.org>
>>>>>> <mailto:wildfly-dev at lists.jboss.org
>>>>>> <mailto:wildfly-dev at lists.jboss.org>>
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> wildfly-dev mailing list
>>>>>>>>>> 
>>>>>> wildfly-dev at lists.jboss.org<mailto:wildfly-dev at 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 at lists.jboss.org<mailto:wildfly-dev at 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 at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at 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

More information about the wildfly-dev mailing list