8 a.m.
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
9:08 a.m.
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.Fin...
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
9:22 a.m.
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.Fin...
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(a)redhat.com
<mailto:bburke@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
9:40 a.m.
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.Fin...
>
> 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(a)redhat.com
> <mailto:bburke@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:01 a.m.
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.Fin...
>>
>> 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(a)redhat.com
>> <mailto:bburke@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
7:43 p.m.
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(a)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.Fin...
>>>
>>> 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(a)redhat.com
>>> <mailto:bburke@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Misty Stanley-Jones, RHCE
Manager, Content Services (Middleware)
Direct: + 61 7 3514 8105 / Mobile: +61 429 595 932 (TZ: GMT+10)
IRC: misty (Freenode / RH)
8:10 p.m.
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(a)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(a)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.Fin...
>>>>
>>>> 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(a)redhat.com
>>>> <mailto:bburke@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(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
Misty Stanley-Jones, RHCE
Manager, Content Services (Middleware)
Direct: + 61 7 3514 8105 / Mobile: +61 429 595 932 (TZ: GMT+10)
IRC: misty (Freenode / RH)
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
4:56 a.m.
The thing needs distribution tooling to setup different configurations.
As for support, we'll support combinations that are actual products.
Carlo
On 02/24/2014 03:10 AM, 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(a)redhat.com
<mailto:misty@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(a)redhat.com <mailto:brian.stansberry@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, Tomaz( 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.Fin...
>>>>
>>>> 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(a)redhat.com <mailto:bburke@redhat.com>
>>>> <mailto:bburke@redhat.com
<mailto:bburke@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(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
<mailto:wildfly-dev@lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>>
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
<mailto:wildfly-dev@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(a)lists.jboss.org <mailto:wildfly-dev@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
8 a.m.
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(a)redhat.com
<mailto:misty@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(a)redhat.com <mailto:brian.stansberry@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.Fin...
>>>>
>>>> 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(a)redhat.com
<mailto:bburke@redhat.com>
>>>> <mailto:bburke@redhat.com
<mailto:bburke@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(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
<mailto:wildfly-dev@lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>>
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
<mailto:wildfly-dev@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(a)lists.jboss.org <mailto:wildfly-dev@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:16 a.m.
I think we need to get a clearer sense of what "support" means.
First, it's WF so we those of us at Red Hat don't "support" it in the
way we support EAP.
In community there are going to be certain combinations that are heavily
tested, and if you have issues with those, almost certainly you'll get
more help with getting questions answered and bugs fixed.
Beyond that, we should work to ensure our dependency metadata is
correct, so whatever tooling people rely on for rolling their own is
using correct data. Any bugs in that metadata we should of course fix.
Beyond that, if people use unusual combinations and find unusual
problems they should expect a lower probability of getting help.
On 2/24/14, 8:00 AM, 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(a)redhat.com
> <mailto:misty@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(a)redhat.com <mailto:brian.stansberry@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.Fin...
> >>>>
> >>>> 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(a)redhat.com
> <mailto:bburke@redhat.com>
> >>>> <mailto:bburke@redhat.com
<mailto:bburke@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(a)lists.jboss.org
> <mailto:wildfly-dev@lists.jboss.org>
> <mailto:wildfly-dev@lists.jboss.org
> <mailto:wildfly-dev@lists.jboss.org>>
> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> wildfly-dev mailing list
> >>>> wildfly-dev(a)lists.jboss.org
<mailto:wildfly-dev@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(a)lists.jboss.org <mailto:wildfly-dev@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
10:09 a.m.
For TorqueBox users we absolutely need a much slimmer server. When we
were based on AS 7.2, we took the approach of building AS 7.2 from
source and removing all the bits unnecessary for Ruby apps to cut our
distribution size down to a bit less than 40MB from about 160MB.
As we port to WildFly, we're taking this idea much further and will
write TorqueBox itself against a new API that will let us seamlessly run
TorqueBox inside WildFly or outside of WildFly, bringing components in
ourselves directly.
Basically, we want to give those users that just want to run simple Ruby
web apps a way to do that via a small RubyGem that embeds Undertow
directly. This same app will then be able to run inside WildFly and
utilize Undertow (and other components) of the app server instead of the
embedded versions we bring when they run outside of WildFly.
We'll keep our eye on the efforts of WildFly core distribution and the
separated modules, but for now we need something embeddable with a very
small memory and disk footprint for the majority of our users.
Ben
On 02/24/2014 09:00 AM, 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(a)redhat.com
> <mailto:misty@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(a)redhat.com <mailto:brian.stansberry@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.Fin...
> >>>>
> >>>> 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(a)redhat.com
> <mailto:bburke@redhat.com>
> >>>> <mailto:bburke@redhat.com
<mailto:bburke@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(a)lists.jboss.org
> <mailto:wildfly-dev@lists.jboss.org>
> <mailto:wildfly-dev@lists.jboss.org
> <mailto:wildfly-dev@lists.jboss.org>>
> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> wildfly-dev mailing list
> >>>> wildfly-dev(a)lists.jboss.org
<mailto:wildfly-dev@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(a)lists.jboss.org <mailto:wildfly-dev@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
12:37 a.m.
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(a)redhat.com
> <mailto:misty@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@redhat.com<mailto:brian.stansberry@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.Fin...
> >>>>
> >>>> 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(a)redhat.com
> <mailto:bburke@redhat.com>
> >>>>
<mailto:bburke@redhat.com<mailto:bburke@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(a)lists.jboss.org
> <mailto:wildfly-dev@lists.jboss.org>
> <mailto:wildfly-dev@lists.jboss.org
> <mailto:wildfly-dev@lists.jboss.org>>
> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> wildfly-dev mailing list
> >>>>
wildfly-dev@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
Sent using Postbox:
http://www.getpostbox.com
8:35 a.m.
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.
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!
* 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(a)redhat.com
>> <mailto:misty@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@redhat.com<mailto:brian.stansberry@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.Fin...
>>
>> >>>>
>> >>>> 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(a)redhat.com
>> <mailto:bburke@redhat.com>
>> >>>>
<mailto:bburke@redhat.com<mailto:bburke@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(a)lists.jboss.org
>> <mailto:wildfly-dev@lists.jboss.org>
>> <mailto:wildfly-dev@lists.jboss.org
>> <mailto:wildfly-dev@lists.jboss.org>>
>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> wildfly-dev mailing list
>> >>>>
>> wildfly-dev@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:39 a.m.
You might want to look at the work described in
https://issues.jboss.org/browse/MODULES-146 which essentially would let
you keep your modules directory completely remote on a server, with
local caching, if you wanted to.
On 03/04/2014 08:35 AM, 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.
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!
* 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(a)redhat.com
>>> <mailto:misty@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@redhat.com<mailto:brian.stansberry@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.Fin...
>>>
>>> >>>>
>>> >>>> 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(a)redhat.com
>>> <mailto:bburke@redhat.com>
>>> >>>>
<mailto:bburke@redhat.com<mailto:bburke@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(a)lists.jboss.org
>>> <mailto:wildfly-dev@lists.jboss.org>
>>> <mailto:wildfly-dev@lists.jboss.org
>>> <mailto:wildfly-dev@lists.jboss.org>>
>>> >>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> wildfly-dev mailing list
>>> >>>>
>>> wildfly-dev@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>
--
- DML
11:05 a.m.
On 3/4/2014 11:39 AM, David M. Lloyd wrote:
You might want to look at the work described in
https://issues.jboss.org/browse/MODULES-146 which essentially would let
you keep your modules directory completely remote on a server, with
local caching, if you wanted to.
For distributing jars, I like the artifact approach better as you don't
have to maintain two types of repos. You can use a maven repo for both
building apps and running Wildfly. I can't remember exactly, but the
full size of all module.xml files in a Wildfly distro was 200-800k after
you strip out all the comments.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11:56 a.m.
On 03/04/2014 11:05 AM, Bill Burke wrote:
On 3/4/2014 11:39 AM, David M. Lloyd wrote:
> You might want to look at the work described in
> https://issues.jboss.org/browse/MODULES-146 which essentially would let
> you keep your modules directory completely remote on a server, with
> local caching, if you wanted to.
>
For distributing jars, I like the artifact approach better as you don't
have to maintain two types of repos. You can use a maven repo for both
building apps and running Wildfly. I can't remember exactly, but the
full size of all module.xml files in a Wildfly distro was 200-800k after
you strip out all the comments.
It is possible that you misunderstood me. It's not necessarily
one-or-the-other; you could have the remote repository hold the module
descriptors which are downloaded on demand. That will save you even
more space and you don't even have to strip out comments.
Other thoughts however will come on another branch.
--
- DML
12:22 p.m.
On 03/04/2014 08:35 AM, 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.
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.
I'm not sure how tightly you're gripping to this metaphor, but it can
not be exactly this because the maven dependencies do not semantically
have the right dependency information to function 100% correctly at run
time, which is the point of JBoss Modules and its dependency
infrastructure in the first place.
* 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!
Deploy, maybe in certain cases, but I don't think that using Maven repos
is going to be preferred in the data center case or even the cloud case.
In both cases, in any non-trivially sized environment, the systems are
generally going to be either built up by packages long before deployment
time, simply replicated in whole off an image, or built up by high-level
tooling in such a way that it doesn't really pay to "buy in" to the
Maven repository format, which would be more useful perhaps during
development. In many cases, the public Internet isn't even accessible
and a local image is necessary. I think the usefulness of Maven is
heavily, heavily overstated here.
* 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 would be a step backwards, especially if we ever want to support
third-party add-ins in a uniform manner.
* 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.
I guess you're looking at it from the perspective of "every Java
application is a monolithic thing" instead of "I have an installation
which has N applications in it", which is more what my world view is.
And I have in the past, and continue to believe that build and run time
are very distinct. At build time, you have a giant, single universe of
artifacts which include versioned dependency information which is used
for build repeatability purposes. At run time, you have one or more
"environments" of selected artifacts which include versionless
dependency information, that are tested together and certified, which
can be (theoretically anyway) updated, installed, and removed
individually without rebuild (only a one-time, centralized retest in the
updates case). This is actually much closer to both the Jigsaw/MR ethos
as well as the way that UNIX-ish /lib works today, and I think is more
in line with what we want to have in the 5+ year time frame (if we
cannot manage it sooner than that).
--
- DML
2:16 p.m.
On 3/4/2014 1:22 PM, David M. Lloyd wrote:
On 03/04/2014 08:35 AM, 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.
>
> 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.
I'm not sure how tightly you're gripping to this metaphor, but it can
not be exactly this because the maven dependencies do not semantically
have the right dependency information to function 100% correctly at run
time, which is the point of JBoss Modules and its dependency
infrastructure in the first place.
I'm talking about the maven repo directory structure, not the poms!
Being able to resolve an artifact given a base URL, artifact name, and
version is pretty damn powerful. Trivial, but powerful.
JBoss Modules + Maven Repo = "something better"
> * 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!
Deploy, maybe in certain cases, but I don't think that using Maven repos
is going to be preferred in the data center case or even the cloud case.
In both cases, in any non-trivially sized environment, the systems are
generally going to be either built up by packages long before deployment
time, simply replicated in whole off an image, or built up by high-level
tooling in such a way that it doesn't really pay to "buy in" to the
Maven repository format, which would be more useful perhaps during
development. In many cases, the public Internet isn't even accessible
and a local image is necessary. I think the usefulness of Maven is
heavily, heavily overstated here.
I wasn't talking about using a *remote* maven repo to share disk space.
I was talking about a local repo. You would install Wildfly jar
dependencies into the OS image's local maven directory. Then, different
OS VMs could share the same disk space.
> * 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 would be a step backwards, especially if we ever want to support
third-party add-ins in a uniform manner.
> * 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.
I guess you're looking at it from the perspective of "every Java
application is a monolithic thing" instead of "I have an installation
which has N applications in it", which is more what my world view is.
I wasn't advocating one approach over another. I'd like to be able to
do both. While we already have a platform that can have "N applications
in it", we don't have a great way to bundle a "monolithic thing". The
ironic thing is that the users I've talked to who want the ability to
create a "monolithic thing" are talking about applications that are at
least 100+ meg smaller than the current Wildfly distro. :)
If Wildfly and other non-Wildfly apps used a local maven repo (or remote
one I guess), you'd have a common cross-environment way of sharing
dependencies on the same machine. I'm talking more of using JBoss
Modules as a way to create an "exeutable" for non-Wildfly applications.
And I have in the past, and continue to believe that build and run
time
are very distinct.
And I don't think they need to be completely distinct and separate.
Maven repo for building. JBoss modules to bridge between the
"versionless runtime" and the repo, to provide a logical unversioned
view/grouping of dependencies.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3:16 p.m.
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(a)redhat.com
>>> <mailto:misty@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@redhat.com<mailto:brian.stansberry@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.Fin...
>>>
>>>
>>> >>>>
>>> >>>> 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(a)redhat.com
>>> <mailto:bburke@redhat.com>
>>> >>>>
<mailto:bburke@redhat.com<mailto:bburke@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(a)lists.jboss.org
>>> <mailto:wildfly-dev@lists.jboss.org>
>>> <mailto:wildfly-dev@lists.jboss.org
>>> <mailto:wildfly-dev@lists.jboss.org>>
>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> wildfly-dev mailing list
>>> >>>>
>>> wildfly-dev@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>
--
Sent using Postbox:
http://www.getpostbox.com
10:55 p.m.
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(a)redhat.com
>>>> <mailto:misty@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@redhat.com<mailto:brian.stansberry@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.Fin...
>>>>
>>>>
>>>>
>>>> >>>>
>>>> >>>> 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(a)redhat.com
>>>> <mailto:bburke@redhat.com>
>>>> >>>>
<mailto:bburke@redhat.com<mailto:bburke@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(a)lists.jboss.org
>>>> <mailto:wildfly-dev@lists.jboss.org>
>>>> <mailto:wildfly-dev@lists.jboss.org
>>>> <mailto:wildfly-dev@lists.jboss.org>>
>>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> wildfly-dev mailing list
>>>> >>>>
>>>> wildfly-dev@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>
>
3:27 a.m.
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(a)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(a)redhat.com
>>>>> <mailto:misty@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@redhat.com<mailto:brian.stansberry@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.Fin...
>>>>>
>>>>>
>>>>>
>>>>> >>>>
>>>>> >>>> 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(a)redhat.com
>>>>> <mailto:bburke@redhat.com>
>>>>> >>>>
<mailto:bburke@redhat.com<mailto:bburke@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(a)lists.jboss.org
>>>>> <mailto:wildfly-dev@lists.jboss.org>
>>>>> <mailto:wildfly-dev@lists.jboss.org
>>>>> <mailto:wildfly-dev@lists.jboss.org>>
>>>>> >>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> _______________________________________________
>>>>> >>>> wildfly-dev mailing list
>>>>> >>>>
>>>>>
wildfly-dev@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>>
>>
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
2:04 p.m.
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(a)gmail.com <mailto:stuart.w.douglas@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(a)redhat.com <mailto:misty@redhat.com>
>>>>> <mailto:misty@redhat.com
<mailto:misty@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(a)redhat.com
<mailto:brian.stansberry@redhat.com><mailto:brian.stansberry@redhat.com
<mailto:brian.stansberry@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.Fin...
>>>>>
>>>>>
>>>>>
>>>>> >>>>
>>>>> >>>> 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(a)redhat.com <mailto:bburke@redhat.com>
>>>>> <mailto:bburke@redhat.com
<mailto:bburke@redhat.com>>
>>>>> >>>> <mailto:bburke@redhat.com
<mailto:bburke@redhat.com><mailto:bburke@redhat.com
<mailto:bburke@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(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
>>>>> <mailto:wildfly-dev@lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>>
>>>>> <mailto:wildfly-dev@lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
>>>>> <mailto:wildfly-dev@lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>>>
>>>>> >>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
_______________________________________________
>>>>> >>>> wildfly-dev mailing list
>>>>> >>>>
>>>>> wildfly-dev(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org><mailto:wildfly-dev@lists.jboss.org
<mailto:wildfly-dev@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(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org><mailto:wildfly-dev@lists.jboss.org
<mailto:wildfly-dev@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(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org><mailto:wildfly-dev@lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>>
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>>
>>
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
6:20 a.m.
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(a)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(a)redhat.com
>>>>> <mailto:misty@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@redhat.com<mailto:brian.stansberry@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.Fin...
>>>>>
>>>>>
>>>>>
>>>>>>>>>
>>>>>>>>> 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(a)redhat.com
>>>>> <mailto:bburke@redhat.com>
>>>>>>>>>
<mailto:bburke@redhat.com<mailto:bburke@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(a)lists.jboss.org
>>>>> <mailto:wildfly-dev@lists.jboss.org>
>>>>> <mailto:wildfly-dev@lists.jboss.org
>>>>> <mailto:wildfly-dev@lists.jboss.org>>
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> wildfly-dev mailing list
>>>>>>>>>
>>>>>
wildfly-dev@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>>
>>
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)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
3:19 p.m.
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(a)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(a)redhat.com
>>>>>> <mailto:misty@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@redhat.com<mailto:brian.stansberry@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.Fin...
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>> 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(a)redhat.com
>>>>>> <mailto:bburke@redhat.com>
>>>>>>>>>>
<mailto:bburke@redhat.com<mailto:bburke@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(a)lists.jboss.org
>>>>>> <mailto:wildfly-dev@lists.jboss.org>
>>>>>> <mailto:wildfly-dev@lists.jboss.org
>>>>>> <mailto:wildfly-dev@lists.jboss.org>>
>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> wildfly-dev mailing list
>>>>>>>>>>
>>>>>>
wildfly-dev@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)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
10:28 a.m.
Since the logging subsystem is in the core distro, I'm wondering if the
default DUP's to add logging dependencies and search for logging
configuration files in deployments should be disabled. There are
attributes to disable these now which are should remain enabled in
WildFly, but it seems the opposite might be preferable in a core-distro.
I've not really thought about how to do that or looked over Stuarts
branch with great detail, but just kind of throwing it out there to get
opinions on it.
On 03/03/2014 10:37 PM, 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(a)redhat.com
>> <mailto:misty@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@redhat.com<mailto:brian.stansberry@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.Fin...
>> >>>>
>> >>>> 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(a)redhat.com
>> <mailto:bburke@redhat.com>
>> >>>>
<mailto:bburke@redhat.com<mailto:bburke@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(a)lists.jboss.org
>> <mailto:wildfly-dev@lists.jboss.org>
>> <mailto:wildfly-dev@lists.jboss.org
>> <mailto:wildfly-dev@lists.jboss.org>>
>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> wildfly-dev mailing list
>> >>>>
wildfly-dev@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
--
James R. Perkins
Red Hat JBoss Middleware
10:46 a.m.
As long as we don't break deployments which use the container
dependencies, anything is fine.
On 03/04/2014 10:28 AM, James R. Perkins wrote:
Since the logging subsystem is in the core distro, I'm wondering
if the
default DUP's to add logging dependencies and search for logging
configuration files in deployments should be disabled. There are
attributes to disable these now which are should remain enabled in
WildFly, but it seems the opposite might be preferable in a core-distro.
I've not really thought about how to do that or looked over Stuarts
branch with great detail, but just kind of throwing it out there to get
opinions on it.
On 03/03/2014 10:37 PM, 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(a)redhat.com
>>> <mailto:misty@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@redhat.com<mailto:brian.stansberry@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.Fin...
>>> >>>>
>>> >>>> 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(a)redhat.com
>>> <mailto:bburke@redhat.com>
>>> >>>>
<mailto:bburke@redhat.com<mailto:bburke@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(a)lists.jboss.org
>>> <mailto:wildfly-dev@lists.jboss.org>
>>> <mailto:wildfly-dev@lists.jboss.org
>>> <mailto:wildfly-dev@lists.jboss.org>>
>>> >>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> wildfly-dev mailing list
>>> >>>>
wildfly-dev@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
--
- DML
11:27 a.m.
It's an interesting question how a particular child server build will be
able to override a standard config snippet from a depended upon server
build. I know Stuart was thinking about that a bit. It's been at least
28 hours so I'm sure he has it sorted. ;)
On 3/4/14, 10:46 AM, David M. Lloyd wrote:
As long as we don't break deployments which use the container
dependencies, anything is fine.
On 03/04/2014 10:28 AM, James R. Perkins wrote:
> Since the logging subsystem is in the core distro, I'm wondering if the
> default DUP's to add logging dependencies and search for logging
> configuration files in deployments should be disabled. There are
> attributes to disable these now which are should remain enabled in
> WildFly, but it seems the opposite might be preferable in a core-distro.
> I've not really thought about how to do that or looked over Stuarts
> branch with great detail, but just kind of throwing it out there to get
> opinions on it.
>
> On 03/03/2014 10:37 PM, 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(a)redhat.com
>>>> <mailto:misty@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@redhat.com<mailto:brian.stansberry@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.Fin...
>>>> >>>>
>>>> >>>> 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(a)redhat.com
>>>> <mailto:bburke@redhat.com>
>>>> >>>>
<mailto:bburke@redhat.com<mailto:bburke@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(a)lists.jboss.org
>>>> <mailto:wildfly-dev@lists.jboss.org>
>>>> <mailto:wildfly-dev@lists.jboss.org
>>>> <mailto:wildfly-dev@lists.jboss.org>>
>>>> >>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>
_______________________________________________
>>>> >>>> wildfly-dev mailing list
>>>> >>>>
wildfly-dev@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@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@lists.jboss.org<mailto:wildfly-dev@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
3909
days inactive
3926
days old
26 comments
10 participants
participants (10)
-
Ben Browning -
Bill Burke -
Brian Stansberry -
Carlo de Wolf -
David M. Lloyd -
James R. Perkins -
Jason Greene -
Misty Stanley-Jones -
Stuart Douglas -
Tomaž Cerar