In order to support multiple derived products based on EAP, we need a solution that allows the console to "emulate" plug-ability. By "emulate", I mean that until we have a dynamic rendering engine (AS8/EAP7), we still have to deal with the fact that GWT requires static compilation. The first component of the proposal is that the console have a serial version stream which includes *all* plugins. Every derivative product will need to contribute a plugin which is pulled into the serial version stream via reference. This means that every console release will need to verify compatibility with old and new versions of all products. This should not be too big of a deal because the management policies require that we maintain compatibility anyway. The second component is that every product (and its patch updates if features are added) will bundle a version of the console which includes support for the product. At runtime the server will then simply pick the most recent version available. This will allow for every copy to maintain a clear ownership. So for example, if you install a patch which brings in console version 1.7, that version can be removed and the other available versions can be used. An example is: /consoles/1.1 (Installed by EAP) /consoles/1.2 (Installed by Portal) /consoles/1.3 (Installed by BRMS) /consoles/1.4 (installed by a Portal patch) So in this case the server would start with 1.4. If BRMS was removed, 1.4 would be picked. If the portal patch was then rolled back, 1.2 would be picked. Alternatively we could always just leave all versions, and always pick the most recent console version, however rollbacks would be an issue. We would need some way for the user to manually revert if there was a bug (perhaps just having them delete the bad version). -Jason _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

In order to support multiple derived products based on EAP, we need a solution that allows the console to "emulate" plug-ability. By "emulate", I mean that until we have a dynamic rendering engine (AS8/EAP7), we still have to deal with the fact that GWT requires static compilation. The first component of the proposal is that the console have a serial version stream which includes *all* plugins. Every derivative product will need to contribute a plugin which is pulled into the serial version stream via reference. This means that every console release will need to verify compatibility with old and new versions of all products. This should not be too big of a deal because the management policies require that we maintain compatibility anyway. The second component is that every product (and its patch updates if features are added) will bundle a version of the console which includes support for the product. At runtime the server will then simply pick the most recent version available. This will allow for every copy to maintain a clear ownership. So for example, if you install a patch which brings in console version 1.7, that version can be removed and the other available versions can be used. An example is: /consoles/1.1 (Installed by EAP) /consoles/1.2 (Installed by Portal) /consoles/1.3 (Installed by BRMS) /consoles/1.4 (installed by a Portal patch) So in this case the server would start with 1.4. If BRMS was removed, 1.4 would be picked. If the portal patch was then rolled back, 1.2 would be picked. Alternatively we could always just leave all versions, and always pick the most recent console version, however rollbacks would be an issue. We would need some way for the user to manually revert if there was a bug (perhaps just having them delete the bad version). -Jason

Sort of. The problem is you can only have one console for each product. So like this is to support an "add-on" which adds portal capability to EAP. If I install portal i need the console to support it, so it would include 1.2 with it. Then later on if I install BRMS into the same install as well, the console needs to support both Portal and BRMS and EAP (all supportable in the same process).

That's correct. We are going to support both additional product features we call "add-ons", as well as completely separate installations which are truly different. The longer term goal (around EAP7) is that all "layered" products will be add-ons such that users can mix and match the features between them. On Dec 19, 2012, at 1:00 PM, Heiko Braun <hbraun(a)redhat.com&gt; wrote: > > > so you are saying it will be possible to install different addons on a given EAP installation? > i.e. customers can begin with EAP6 then put Portal and BRMS on it? I was thinking these are always products on their own? > > On Dec 19, 2012, at 7:57 PM, Jason Greene <jason.greene(a)redhat.com&gt; wrote: > >> Sort of. The problem is you can only have one console for each product. So like this is to support an "add-on" which adds portal capability to EAP. If I install portal i need the console to support it, so it would include 1.2 with it. Then later on if I install BRMS into the same install as well, the console needs to support both Portal and BRMS and EAP (all supportable in the same process). >

For more details on some thinking on things like this "add-on" notion, see https://community.jboss.org/docs/DOC-47927 On 12/19/12 1:07 PM, Heiko Braun wrote: > ok, in that case what you suggested makes complete sense. > > On Dec 19, 2012, at 8:04 PM, Jason Greene <jason.greene(a)redhat.com&gt; wrote: > >> That's correct. We are going to support both additional product features we call "add-ons", as well as completely separate installations which are truly different. The longer term goal (around EAP7) is that all "layered" products will be add-ons such that users can mix and match the features between them. >> >> On Dec 19, 2012, at 1:00 PM, Heiko Braun <hbraun(a)redhat.com&gt; wrote: >> >>> >>> so you are saying it will be possible to install different addons on a given EAP installation? >>> i.e. customers can begin with EAP6 then put Portal and BRMS on it? I was thinking these are always products on their own? >>> >>> On Dec 19, 2012, at 7:57 PM, Jason Greene <jason.greene(a)redhat.com&gt; wrote: >>> >>>> Sort of. The problem is you can only have one console for each product. So like this is to support an "add-on" which adds portal capability to EAP. If I install portal i need the console to support it, so it would include 1.2 with it. Then later on if I install BRMS into the same install as well, the console needs to support both Portal and BRMS and EAP (all supportable in the same process). > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >

> > Generally speaking ("emulate pluggability"): > Why is everybody so worried about the compile time extensions? It's a perfectly valid use case IMO, that fully leverages all benefits we gain from using GWT in the first place. Can you elaborate why this should be done differently? Because you can't drop in new capabilities without recompiling. If an ISV or user decides to write a subsystem, they have to recompile the console with all of the appropriate plugins to get the functionality, which sucks. So EAP7 we have to be more data-driven and dynamic.

An example is: /consoles/1.1 (Installed by EAP) /consoles/1.2 (Installed by Portal) /consoles/1.3 (Installed by BRMS) /consoles/1.4 (installed by a Portal patch) So in this case the server would start with 1.4. If BRMS was removed, 1.4 would be picked. If the portal patch was then rolled back, 1.2 would be picked.