[DISCUSS] Time to upgrade or drop Minimal assemblies from 3.0 builds?

[Donald Woods <dw...@apache.org>]

I remember we had some discussion about dropping the minimal assemblies
from the 3.0 builds awhile back, but can't find where a decision was
made, so here goes...


Option 1 - We upgrade the minimal assemblies to support EBA apps by
using the eba-* instead of wab-* plugingroups, so all of our base
assemblies supports the EBA programming environment, while still
producing an assembly which is a subset of the Java EE 6 Web Profile.

The wab-* plugingroups pull in deployers and runtime for:  Servlet 3.0,
JSP 2.2 and EL 1.2, JSF 2.0, JSTL 1.2, WAB (OSGi RFC66), and
remote/offline deploy.  Which creates a zip assembly of ~42MB.

The eba-* plugingroups pull in the wab-* plugins along with deployers
and runtime for:  Aries, JPA2, JTA 1.6, JCA 1.6, system db and TranQL
connectors.   Which creates a zip assembly of ~52MB.


Option 2 - We drop the minimal assemblies and only produce the Java EE 6
full and web profiles.  Both would still support EBA apps, but instead
of being able to download a ~52MB assembly, they would either have to
build a custom assembly or go with a larger web profile assembly that
also pulls in console, monitoring, clustering, EJB, ...


Either option, would require users wanting a "minimal" server to create
their own custom assembly which uses either the wab-* plugins or their
own subset.

For comparison data, currently the framework assembly is ~26MB, the new
javaee6-web assemblies ~65MB, and the full javaee6 assemblies ~75MB (but
both are still lacking full console, hot deploy, monitoring, ... and the
web profile is pulling in all of the EJB support instead of a subset.)


-Donald

Re: [DISCUSS] Time to upgrade or drop Minimal assemblies from 3.0 builds?

[David Jencks <da...@yahoo.com>]

On Jun 10, 2010, at 10:44 AM, Donald Woods wrote:

> 
> 
> On 6/10/10 11:22 AM, Kevan Miller wrote:
>> 
>> On Jun 9, 2010, at 7:48 PM, Donald Woods wrote:
>> 
>>> Now that I have the initial web profile assemblies created and hooked
>>> into our TCK harness, I'd like to circle back around on this.
>>> 
>>> Personally, I like Option #1 - Upgrade and rename minimal assemblies to
>>> EBA based assemblies.  This way, all of the assemblies we build and
>>> release will support the Aries EBA programming model.  Users can choose
>>> to build their own custom assemblies if they choose and leave out the
>>> EBA and WAB support if they do not require it.  Also, it looks like we
>>> will have to add a few more modules into the web profile assemblies to
>>> handle some of the TCK tests, along with missing console, monitoring
>>> agent, clustering, .... which will probably make those assemblies grow
>>> from the current 65MB to more like 80MB.
>> 
>> The last time I checked (over a month ago), I seem to recall that an EBA assembly was pulling in components that I didn't think belonged in an EBA assembly (e.g. ActiveMQ). Was that fixed/changed? 
> 
> No ActiveMQ in the current EBA assembly.
> 
> On that note, I recall the OSGi EEG is looking at adding Message Driven
> Services. So, "EBA" is going to be a moving target overtime... And may
> not always be a "minimal" environment.

I thought eba was a packaging idea, and the nature of the bundles inside would determine what happened next.  So I would expect us to be able to support eba with just a web extender.

>> 
> 
> Well, that could become a problem for our Web profile assembly which
> includes EBA, as the TCK docs mention that if a web profile server
> includes additional/optional Java EE technologies (aka. JMS or web
> services from the Full profile) then the corresponding TCK buckets or
> stand-alone tests must also be run.

We'll have to run the connector tests I think anyway.
> 
> 
>> I can imagine users being interested in WAB, EBA, Java EE Web, and Java EE Full functionality. I'm not sure that a multitude of assemblies is where we want to end up, however. I'm sure we don't want to be building 8 separate assemblies. 
>> 
> 
> True, but you still end up with a download that includes everything,
> including the admin console.  Still think we need a "smaller" download
> option for 3.0 that doesn't include the console....
> 

Personally I don't really care as long as we have something we can ship :-)  I think what is a good idea will come out as we work on it.

thanks
david jencks



> 
>> I've mentioned this before, but I would like to consider packaging multiple configs (or allowing an assembly to easily run a subset of the installed functionality). Something like:
>> 
>> geronimo run -c wab-config.xml
>> geronimo run -c eba-config.xml
>> etc.
>> 
>> --kevan

Re: [DISCUSS] Time to upgrade or drop Minimal assemblies from 3.0 builds?

[Donald Woods <dw...@apache.org>]

On 6/10/10 11:22 AM, Kevan Miller wrote:
> 
> On Jun 9, 2010, at 7:48 PM, Donald Woods wrote:
> 
>> Now that I have the initial web profile assemblies created and hooked
>> into our TCK harness, I'd like to circle back around on this.
>>
>> Personally, I like Option #1 - Upgrade and rename minimal assemblies to
>> EBA based assemblies.  This way, all of the assemblies we build and
>> release will support the Aries EBA programming model.  Users can choose
>> to build their own custom assemblies if they choose and leave out the
>> EBA and WAB support if they do not require it.  Also, it looks like we
>> will have to add a few more modules into the web profile assemblies to
>> handle some of the TCK tests, along with missing console, monitoring
>> agent, clustering, .... which will probably make those assemblies grow
>> from the current 65MB to more like 80MB.
> 
> The last time I checked (over a month ago), I seem to recall that an EBA assembly was pulling in components that I didn't think belonged in an EBA assembly (e.g. ActiveMQ). Was that fixed/changed? 

No ActiveMQ in the current EBA assembly.

On that note, I recall the OSGi EEG is looking at adding Message Driven
Services. So, "EBA" is going to be a moving target overtime... And may
not always be a "minimal" environment.
> 

Well, that could become a problem for our Web profile assembly which
includes EBA, as the TCK docs mention that if a web profile server
includes additional/optional Java EE technologies (aka. JMS or web
services from the Full profile) then the corresponding TCK buckets or
stand-alone tests must also be run.


> I can imagine users being interested in WAB, EBA, Java EE Web, and Java EE Full functionality. I'm not sure that a multitude of assemblies is where we want to end up, however. I'm sure we don't want to be building 8 separate assemblies. 
> 

True, but you still end up with a download that includes everything,
including the admin console.  Still think we need a "smaller" download
option for 3.0 that doesn't include the console....


> I've mentioned this before, but I would like to consider packaging multiple configs (or allowing an assembly to easily run a subset of the installed functionality). Something like:
> 
> geronimo run -c wab-config.xml
> geronimo run -c eba-config.xml
> etc.
> 
> --kevan

Re: [DISCUSS] Time to upgrade or drop Minimal assemblies from 3.0 builds?

[Kevan Miller <ke...@gmail.com>]

On Jun 9, 2010, at 7:48 PM, Donald Woods wrote:

> Now that I have the initial web profile assemblies created and hooked
> into our TCK harness, I'd like to circle back around on this.
> 
> Personally, I like Option #1 - Upgrade and rename minimal assemblies to
> EBA based assemblies.  This way, all of the assemblies we build and
> release will support the Aries EBA programming model.  Users can choose
> to build their own custom assemblies if they choose and leave out the
> EBA and WAB support if they do not require it.  Also, it looks like we
> will have to add a few more modules into the web profile assemblies to
> handle some of the TCK tests, along with missing console, monitoring
> agent, clustering, .... which will probably make those assemblies grow
> from the current 65MB to more like 80MB.

The last time I checked (over a month ago), I seem to recall that an EBA assembly was pulling in components that I didn't think belonged in an EBA assembly (e.g. ActiveMQ). Was that fixed/changed? On that note, I recall the OSGi EEG is looking at adding Message Driven Services. So, "EBA" is going to be a moving target overtime... And may not always be a "minimal" environment.

I can imagine users being interested in WAB, EBA, Java EE Web, and Java EE Full functionality. I'm not sure that a multitude of assemblies is where we want to end up, however. I'm sure we don't want to be building 8 separate assemblies. 

I've mentioned this before, but I would like to consider packaging multiple configs (or allowing an assembly to easily run a subset of the installed functionality). Something like:

geronimo run -c wab-config.xml
geronimo run -c eba-config.xml
etc.

--kevan

Re: [DISCUSS] Time to upgrade or drop Minimal assemblies from 3.0 builds?

[Donald Woods <dw...@apache.org>]

Now that I have the initial web profile assemblies created and hooked
into our TCK harness, I'd like to circle back around on this.

Personally, I like Option #1 - Upgrade and rename minimal assemblies to
EBA based assemblies.  This way, all of the assemblies we build and
release will support the Aries EBA programming model.  Users can choose
to build their own custom assemblies if they choose and leave out the
EBA and WAB support if they do not require it.  Also, it looks like we
will have to add a few more modules into the web profile assemblies to
handle some of the TCK tests, along with missing console, monitoring
agent, clustering, .... which will probably make those assemblies grow
from the current 65MB to more like 80MB.



-Donald


On 6/8/10 3:17 PM, Donald Woods wrote:
> I remember we had some discussion about dropping the minimal assemblies
> from the 3.0 builds awhile back, but can't find where a decision was
> made, so here goes...
> 
> 
> Option 1 - We upgrade the minimal assemblies to support EBA apps by
> using the eba-* instead of wab-* plugingroups, so all of our base
> assemblies supports the EBA programming environment, while still
> producing an assembly which is a subset of the Java EE 6 Web Profile.
> 
> The wab-* plugingroups pull in deployers and runtime for:  Servlet 3.0,
> JSP 2.2 and EL 1.2, JSF 2.0, JSTL 1.2, WAB (OSGi RFC66), and
> remote/offline deploy.  Which creates a zip assembly of ~42MB.
> 
> The eba-* plugingroups pull in the wab-* plugins along with deployers
> and runtime for:  Aries, JPA2, JTA 1.6, JCA 1.6, system db and TranQL
> connectors.   Which creates a zip assembly of ~52MB.
> 
> 
> Option 2 - We drop the minimal assemblies and only produce the Java EE 6
> full and web profiles.  Both would still support EBA apps, but instead
> of being able to download a ~52MB assembly, they would either have to
> build a custom assembly or go with a larger web profile assembly that
> also pulls in console, monitoring, clustering, EJB, ...
> 
> 
> Either option, would require users wanting a "minimal" server to create
> their own custom assembly which uses either the wab-* plugins or their
> own subset.
> 
> For comparison data, currently the framework assembly is ~26MB, the new
> javaee6-web assemblies ~65MB, and the full javaee6 assemblies ~75MB (but
> both are still lacking full console, hot deploy, monitoring, ... and the
> web profile is pulling in all of the EJB support instead of a subset.)
> 
> 
> -Donald
> 
> 
>