[wildfly-dev] smaller footprints

Stuart Douglas stuart.w.douglas at gmail.com
Wed Mar 5 15:04:28 EST 2014


That sounds fine to me. In the absence of any other suggestions I will 
go with this for now.

Stuart

Tomaž Cerar wrote:
> What about bit shorter for dist, removing "-build-" part
>
> wildfly-core-build (cut down server core build)
> wildfly-core-dist (core + all jars)
> wildfly-web-build (cut down wildfly server with just the Undertow subsystem)
> wildfly-web-dist (as above, but with jars)
> wildfly-build (cut down full server)
> wildfly-dist (as above)
>
>
>
>
> On Wed, Mar 5, 2014 at 5:55 AM, Stuart Douglas
> <stuart.w.douglas at gmail.com <mailto: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>
>      >>>>> <mailto: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><mailto: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>>
>      >>>>> >>>> <mailto: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>>
>      >>>>> <mailto: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><mailto: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><mailto: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><tel:%2B%2061%207%203514%208105> /
>     Mobile:
>      >>>>> +61 429 595 932
>     <tel:%2B61%20429%20595%20932><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><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
>      >>>>>
>      >>>>
>      >>>
>      >>
>      >
>     _______________________________________________
>     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
>
>


More information about the wildfly-dev mailing list