[wildfly-dev] smaller footprints

Tue Mar 4 23:55:58 EST 2014

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