[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