<div dir="ltr">What about bit shorter for dist, removing "-build-" part<br><br>wildfly-core-build (cut down server core build)<br>
wildfly-core-dist (core + all jars)<br>
wildfly-web-build (cut down wildfly server with just the Undertow subsystem)<br>
wildfly-web-dist (as above, but with jars)<br>
wildfly-build (cut down full server)<br>
wildfly-dist (as above)<br><br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 5, 2014 at 5:55 AM, Stuart Douglas <span dir="ltr"><<a href="mailto:stuart.w.douglas@gmail.com" target="_blank">stuart.w.douglas@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So now onto one of the hard problems, naming things...<br>
<br>
As a result of splitting up the server we are going to end up with a lot<br>
more artifacts. Basically each repo will produce at least two servers, a<br>
cut down server that uses the maven repo and a full server that is<br>
similar to what we have at the moment, and we are going to need some<br>
kind of consistent name for them.<br>
<br>
I am thinking maybe something like:<br>
<br>
wildfly-core-build (cut down server core build)<br>
wildfly-core-build-dist (core + all jars)<br>
wildfly-web-build (cut down wildfly server with just the Undertow subsystem)<br>
wildfly-web-build-dist (as above, but with jars)<br>
wildfly-build (cut down full server)<br>
wildfly-build-dist (as above)<br>
<br>
Does anyone have any better ideas about what to call this stuff?<br>
<br>
One side effect of the above would be that the build directory will no<br>
longer contain the full Wildfly server (just a version with no jars<br>
present), and the full server would be in the dist directory instead.<br>
<span class="HOEnZb"><font color="#888888"><br>
Stuart<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
Stuart Douglas wrote:<br>
><br>
><br>
> Bill Burke wrote:<br>
>> Great work Stuart! I'm really happy somebody is taking initiative on<br>
>> this because I really think it will help a lot with Wildfly adoption. Is<br>
>> it ready to use? I'm willing to try it out RIGHT NOW.<br>
><br>
> Sort of. You can build from my wildfly-build-plugin branch and it should<br>
> work, but at the moment it is creating a build that includes all the<br>
> jars. If you want to create a build that uses <artifact> you will need<br>
> to modify the copy-module-artifacts attribute in ./build/server-build.xml .<br>
><br>
> Eventually we will produce both versions, I should get to this some time<br>
> today.<br>
><br>
> Also this is very new, and may not work, but if you want to try it out<br>
> feel free. Hopefully I will have something a lot more polished by the<br>
> end of the week.<br>
><br>
>><br>
>> I've expressed some of these thoughts months ago when I introduced the<br>
>> JBoss Modules artifact features, but here was my vision:<br>
>><br>
>> * maven repos would become to Wildfly as /lib /usr/local/lib directory<br>
>> structures are to unix.<br>
>> * The JBoss Module artifact feature would become the preferred way to<br>
>> deploy Wildfly/JBoss. This would make it really easy to support multiple<br>
>> versions as well as different distro's of JBoss/Wildfly on the same<br>
>> machine and save huge amounts of disk space. If we could get a JVM that<br>
>> could share JAR instances between processes to save on RAM, the win<br>
>> would be even bigger! Think of the cloud implications!<br>
><br>
> I think we would need some kind of tool to make sure that a repo is<br>
> fully downloaded if people wanted to use this in production. Even though<br>
> download on demand is cool, you would not want a production server<br>
> hanging as it attempts to download a jar. Not sure what sort of form<br>
> this tool would take.<br>
><br>
> Stuart<br>
><br>
>> * JBoss Module definitions could eventually be defined in one large XML<br>
>> file. We would have maven/ant plugins to help build this large XML file.<br>
>> * This single JBoss Module XML file could be bundled within a<br>
>> JBoss/Wildfly "executable jar".<br>
>> * This "executable jar" could be overlayed with external JBoss Module<br>
>> XML files or directory structures.<br>
>> * Finally, you could create this "executable jar" for any Java project.<br>
>><br>
>><br>
>><br>
>><br>
>> On 3/4/2014 1:37 AM, Stuart Douglas wrote:<br>
>>> I have made a start on this split, and I think the solution I am working<br>
>>> on will meet all the use cases, including users that want to cut down an<br>
>>> existing server, and users that want to re-use the jars in their maven<br>
>>> repo using Bill's changes to JBoss Modules. It still needs a bit more<br>
>>> work and a lot of cleanup, however it seems to work:<br>
>>><br>
>>> <a href="https://github.com/stuartwdouglas/wildfly/compare/wildfly-build-plugin" target="_blank">https://github.com/stuartwdouglas/wildfly/compare/wildfly-build-plugin</a><br>
>>><br>
>>> So basically the core of it is a maven plugin that builds a Wildfly<br>
>>> distribution, either from scratch or use other distributions as a base.<br>
>>><br>
>>> It also supports building servers that use the new <artifact><br>
>>> functionality in jboss modules, and cutting down an existing server into<br>
>>> a smaller server with only the specified modules (and their transitive<br>
>>> dependencies).<br>
>>><br>
>>> The way this will work in practice is that each Wildfly sub project will<br>
>>> produce two different server artifacts, one of which is a server without<br>
>>> any jars using artifact references, and a more traditional version with<br>
>>> jars packaged in the module directory. Downstream projects will consume<br>
>>> the smaller version without all the jars, so when a version changes the<br>
>>> download should be less than 5mb rather than larger than 100mb (the<br>
>>> plugin has the ability to turn a server that uses artifact references<br>
>>> into a server that contains the jars in the modules dir).<br>
>>><br>
>>> Basically the upshot is that it should be basically possible to build<br>
>>> whatever configuration of server you want once this is part of our build<br>
>>> process, and we should also be publishing lightweight server artifacts<br>
>>> that use the jars in the maven repo as well as our traditional<br>
>>> 'everything and the kitchen sink' build.<br>
>>><br>
>>> It is anticipated that 3rd party projects build on Wildfly would also<br>
>>> use this plugin (I think at the moment the standard approach has been to<br>
>>> copy and modify our ant scripts).<br>
>>><br>
>>> This is still very much a work in progress, so nothing is set in stone<br>
>>> yet and any comments are welcome.<br>
>>><br>
>>> Stuart<br>
>>><br>
>>><br>
>>> Bill Burke wrote:<br>
>>>> A lot of users want that ability, would you rather have them roll Netty<br>
>>>> + whatever?<br>
>>>><br>
>>>> On 2/23/2014 9:10 PM, Stuart Douglas wrote:<br>
>>>>> No, because that means we essentially have to support and test every<br>
>>>>> possible combination that someone might select.<br>
>>>>><br>
>>>>> Stuart<br>
>>>>><br>
>>>>><br>
>>>>> On Mon, Feb 24, 2014 at 7:13 AM, Misty Stanley-Jones<<a href="mailto:misty@redhat.com">misty@redhat.com</a><br>
>>>>> <mailto:<a href="mailto:misty@redhat.com">misty@redhat.com</a>>> wrote:<br>
>>>>><br>
>>>>> I know you guys aren’t there yet, but can we think about wrapping a<br>
>>>>> GUI around this, so that the developer only needs to tick the boxes<br>
>>>>> for what he does/doesn’t want, with dependencies sorted out<br>
>>>>> automatically? Maybe some default profiles that select a group of<br>
>>>>> things, but the ability to go in and add or remove individual<br>
>>>>> subsystems as needed? Maybe this could be part of the installer but<br>
>>>>> could optionally be run post-install as well.<br>
>>>>><br>
>>>>> On Feb 22, 2014, at 2:01 AM, Brian Stansberry<br>
>>>>> <<a href="mailto:brian.stansberry@redhat.com">brian.stansberry@redhat.com</a><mailto:<a href="mailto:brian.stansberry@redhat.com">brian.stansberry@redhat.com</a>>><br>
>>>>> wrote:<br>
>>>>><br>
>>>>> > When I said "Web" I meant the thing described on that wiki<br>
>>>>> page Tomaz<br>
>>>>> > linked:<br>
>>>>> ><br>
>>>>> > "Web<br>
>>>>> ><br>
>>>>> > Undertow subsystem, and all related dependencies, including<br>
>>>>> a small<br>
>>>>> > subset of EE and JNDI. This is basically just a Servlet<br>
>>>>> container, and<br>
>>>>> > will provide a platform for people that want to create web<br>
>>>>> based<br>
>>>>> > appliances or applications, and don't need all the additional<br>
>>>>> > functionality that Wildfly provides. We should end up with<br>
>>>>> something as<br>
>>>>> > lightweight as Tomcat or Jetty, but with all our advanced<br>
>>>>> management<br>
>>>>> > functionality."<br>
>>>>> ><br>
>>>>> > On 2/21/14, 9:40 AM, Bill Burke wrote:<br>
>>>>> >> Its also "Web" minus some stuff. For my project I want just<br>
>>>>> Servlet,<br>
>>>>> >> JAX-RS, JPA, and datasources. Its very very hard to<br>
>>>>> figure out<br>
>>>>> how to<br>
>>>>> >> remove a subsystem and all its associated modules.<br>
>>>>> >><br>
>>>>> >> BTW, I think my maven artifact thing got into JBoss<br>
>>>>> Modules. So it<br>
>>>>> >> would be possible to load jars on demand, or at least use<br>
>>>>> it as<br>
>>>>> a way to<br>
>>>>> >> figure out which modules aren't being used ;).<br>
>>>>> >><br>
>>>>> >><br>
>>>>> >> On 2/21/2014 10:22 AM, Brian Stansberry wrote:<br>
>>>>> >>> This will move things in the right direction, but not all the<br>
>>>>> way there<br>
>>>>> >>> yet. Note the set of capabilities Bill mention: web, CDI,<br>
>>>>> JAX-RS, JPA.<br>
>>>>> >>> That sounds like our "Web" variant, plus some stuff. It's the<br>
>>>>> easy "plus<br>
>>>>> >>> some stuff" part that needs sorting at some point.<br>
>>>>> >>><br>
>>>>> >>> On 2/21/14, 9:08 AM, Tomaž Cerar wrote:<br>
>>>>> >>>> Bill,<br>
>>>>> >>>><br>
>>>>> >>>> that is exactly idea we have in mind of 9.<br>
>>>>> >>>> We already started with producing WildFly core<br>
>>>>> distribution in<br>
>>>>> that is<br>
>>>>> >>>> WildFly with no subsystems, upon which you can build you own<br>
>>>>> wildfly.<br>
>>>>> >>>> It is only 15mb and contains whole mgmt capabilites (CLI,<br>
>>>>> standalone,<br>
>>>>> >>>> domain,...) you can grab it at:<br>
>>>>> >>>><br>
>>>>><br>
>>>>> <a href="http://download.jboss.org/wildfly/8.0.0.Final/core/wildfly-core-8.0.0.Final.zip" target="_blank">http://download.jboss.org/wildfly/8.0.0.Final/core/wildfly-core-8.0.0.Final.zip</a><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> >>>><br>
>>>>> >>>> For 9 we have plans to move things bit further and have<br>
>>>>> decided that we<br>
>>>>> >>>> will also do split codebase for core, ee, web, .. and other<br>
>>>>> distributions.<br>
>>>>> >>>><br>
>>>>> >>>> Current idea on code split up is here<br>
>>>>> >>>><br>
>>>>> <a href="https://community.jboss.org/wiki/SplittingUpTheWildflyCodeBase" target="_blank">https://community.jboss.org/wiki/SplittingUpTheWildflyCodeBase</a><br>
>>>>> >>>><br>
>>>>> >>>> --<br>
>>>>> >>>> tomaz<br>
>>>>> >>>><br>
>>>>> >>>><br>
>>>>> >>>><br>
>>>>> >>>> On Fri, Feb 21, 2014 at 3:00 PM, Bill<br>
>>>>> Burke<<a href="mailto:bburke@redhat.com">bburke@redhat.com</a><br>
>>>>> <mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>><br>
>>>>> >>>> <mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a><mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>>>><br>
>>>>> wrote:<br>
>>>>> >>>><br>
>>>>> >>>> On Resteasy list I have a few people "rolling their own<br>
>>>>> app server"<br>
>>>>> >>>> using Netty, Weld, Resteasy and JPA. I asked one of<br>
>>>>> them<br>
>>>>> "I don't<br>
>>>>> >>>> understand why you are rolling your own app server"<br>
>>>>> response:<br>
>>>>> >>>><br>
>>>>> >>>> "It's actually a lot more lightweight. The minimum<br>
>>>>> I can<br>
>>>>> run the<br>
>>>>> >>>> equivalent on AS7 on is ~ 180 mb in binaries, but<br>
>>>>> throwing this<br>
>>>>> >>>> together is about 32 mb (and compresses further when<br>
>>>>> its<br>
>>>>> packaged).<br>
>>>>> >>>> I'm able to start the JVM on the bare minimum<br>
>>>>> (~100mb on<br>
>>>>> my linux VM)<br>
>>>>> >>>> but AS7 with all I need is about 756mb. When<br>
>>>>> rolling out<br>
>>>>> in the<br>
>>>>> >>>> cloud, where all of my REST APIs are stateless, running<br>
>>>>> with this<br>
>>>>> >>>> configuration helps us get a lot more per node."<br>
>>>>> >>>><br>
>>>>> >>>> I'm not complaining :), just something to think<br>
>>>>> about. It<br>
>>>>> might be<br>
>>>>> >>>> really valuable to focus a bit in Wildfly 9 to make it<br>
>>>>> easier to create<br>
>>>>> >>>> custom profiles or even different packaging options for<br>
>>>>> the app server<br>
>>>>> >>>> instead of the exploded style we currently have.<br>
>>>>> >>>> --<br>
>>>>> >>>> Bill Burke<br>
>>>>> >>>> JBoss, a division of Red Hat<br>
>>>>> >>>> <a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
>>>>> >>>> _______________________________________________<br>
>>>>> >>>> wildfly-dev mailing list<br>
>>>>> >>>> <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
>>>>> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>><br>
>>>>> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
>>>>> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>>><br>
>>>>> >>>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
>>>>> >>>><br>
>>>>> >>>><br>
>>>>> >>>><br>
>>>>> >>>><br>
>>>>> >>>> _______________________________________________<br>
>>>>> >>>> wildfly-dev mailing list<br>
>>>>> >>>><br>
>>>>> <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><mailto:<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>><br>
>>>>> >>>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
>>>>> >>>><br>
>>>>> >>><br>
>>>>> >>><br>
>>>>> >><br>
>>>>> ><br>
>>>>> ><br>
>>>>> > --<br>
>>>>> > Brian Stansberry<br>
>>>>> > Senior Principal Software Engineer<br>
>>>>> > JBoss by Red Hat<br>
>>>>> > _______________________________________________<br>
>>>>> > wildfly-dev mailing list<br>
>>>>> > <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><mailto:<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>><br>
>>>>> > <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
>>>>><br>
>>>>> Misty Stanley-Jones, RHCE<br>
>>>>> Manager, Content Services (Middleware)<br>
>>>>> Direct: <a href="tel:%2B%2061%207%203514%208105" value="+61735148105">+ 61 7 3514 8105</a><tel:%2B%2061%207%203514%208105> / Mobile:<br>
>>>>> <a href="tel:%2B61%20429%20595%20932" value="+61429595932">+61 429 595 932</a><tel:%2B61%20429%20595%20932> (TZ: GMT+10)<br>
>>>>> IRC: misty (Freenode / RH)<br>
>>>>><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> wildfly-dev mailing list<br>
>>>>> <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><mailto:<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> wildfly-dev mailing list<br>
>>>>> <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
>>>>><br>
>>>><br>
>>><br>
>><br>
><br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</div></div></blockquote></div><br></div>