[wildfly-dev] smaller footprints

Mon Mar 10 16:19:43 EDT 2014

I was just talking about the naming pattern and picked a few examples. I 
was not suggesting that these are all the modules we would have.

Stuart

Jason Greene wrote:
> 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
>