Re: [ovirt-devel] Thoughts on modularization

From: "Mark Proctor" <mdproctor(a)gmail.com&gt; To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; Cc: "Vojtech Szocs" <vszocs(a)redhat.com&gt;, devel(a)ovirt.org Sent: Wednesday, November 5, 2014 5:06:24 PM Subject: Re: [ovirt-devel] Thoughts on modularization Not sure if my previous email made it to the wider level(a)ovirt.org list. I just subscribed :) So I’ll repeat the info. Here is a migration path, with detailed explanation on GWTP mappings: https://docs.google.com/presentation/d/1KImrCvvqaUTgULP-CksUfGwLchJv4uB-d... <https://docs.google.com/presentation/d/1KImrCvvqaUTgULP-CksUfGwLchJv4uB-d... Here presentation I gave yesterday, showing all the work we’ve done in BRMS and BPMS and doing. http://blog.athico.com/2014/11/red-hat-jboss-brms-and-bpms-workbench.html <http://blog.athico.com/2014/11/red-hat-jboss-brms-and-bpms-workbench.html... It also shows a little around our Screens and Perspective plugins, or two units of extensions. Both of which have polyglot bindings (GWTExported, will migrate to @JsType later). Implicitly Maven is our unit of modularity, with maven dependency tree to declare this - however this is not recognised in any internal registry. CDI just scans and picks up any @Screen, @Perspective etc. But could be added, to give physical representation of that unit of modality, with life cycle callbacks - we just haven’t had a need for this yet.

Our plan over 2015 is to use JsType to create a contract for all the things a module needs. We will then compile modules separately against this, with iframe separation, so each Module is loaded as a separate GWT app. This does mean GWT core repetition, a pita, but that atleast gets us started and may be solvable by a custom GWT linker.

Longer term we’d like to work with GWT team. They now use the Closure compiler, this support symbol tables, and I expect how their incremental compiler works for their super dev mode. We want to achieve two things 1) stop recompilation of maven modules, when aggregated into sub projects. 2) declare apis that cannot be pruned 3) export a symbol table to allow later compilation of runtime extensions against those, without requiring a repetition of the GWT core (i.e. problem with our first attempt).

We will still continue with our polyglot bindings approach, such as with the AngularJS stuff we have done. But I do not see this as the ideal programming model - it hides much of what Errai brings, around event bus, and general java refactoring capabilities. However it is still useful for our customers, who want to write extensions, but do not want to touch or learn GWT.

Mark > On 5 Nov 2014, at 15:32, Alon Bar-Lev <alonbl(a)redhat.com&gt; wrote: > > > > ----- Original Message ----- >> From: "Vojtech Szocs" <vszocs(a)redhat.com&gt; >> To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; >> Cc: devel(a)ovirt.org, "Mark Proctor" <mdproctor(a)gmail.com&gt; >> Sent: Wednesday, November 5, 2014 5:24:14 PM >> Subject: Re: [ovirt-devel] Thoughts on modularization >> >> >> >> ----- Original Message ----- >>> From: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; >>> To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; >>> Cc: devel(a)ovirt.org, "Mark Proctor" <mdproctor(a)gmail.com&gt; >>> Sent: Wednesday, November 5, 2014 4:12:06 PM >>> Subject: Re: [ovirt-devel] Thoughts on modularization >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Vojtech Szocs" <vszocs(a)redhat.com&gt; >>>> To: devel(a)ovirt.org >>>> Cc: "Mark Proctor" <mdproctor(a)gmail.com&gt; >>>> Sent: Wednesday, November 5, 2014 5:04:24 PM >>>> Subject: [ovirt-devel] Thoughts on modularization >>>> >>>> Hi guys, >>>> >>>> I've discussed this recently with Yair and Mark, I just wanted to share >>>> some more thoughts on this topic -- in particular, how modularization >>>> problem can be approached (regardless of implementation details). >>>> >>>> I see two approaches here. The typical one is to define APIs for modules >>>> to consume. For example, oVirt Engine extension API has API for auth >>>> stuff; oVirt UI plugin API has API for showing tabs and dialogs, etc. >>>> The advantage is strict consistency, disadvantage is burden of having >>>> to maintain the whole API. With this approach, you tell modules: "This >>>> is the API to work with system, defining how you can plug into it." >>>> >>>> Now turn 180 degrees. The other approach, which is really interesting, >>>> is to let modules themselves export API. This naturally leads to module >>>> hierarchies. Ultimately, this leads to micro-kernel-style development, >>>> where all logic resides in modules. Now you might ask: "What if we want >>>> to employ some consistent work flow across multiple modules? For >>>> example, >>>> have some pluggable *auth* infra?" -- this can be done via some "higher" >>>> level module, that exports API and "lower" level modules consume that >>>> API. >>>> >>>> If you have any ideas, please share! >>> >>> Both solutions can be applied using existing extension api, an extension >>> can >>> locate other extension and interact with it the same way the core >>> interacts >>> with extensions. >> >> But how does core interact with extensions? I assume via well-defined >> API, i.e. in accordance with first approach mentioned above. > > presentation: > http://www.ovirt.org/File:Ovirt_3.5_-_aaa.pdf > <http://www.ovirt.org/File:Ovirt_3.5_-_aaa.pdf> > > package org.ovirt.engine.api.extensions; > > /** > * Interface of an extension. > */ > public interface Extension { > > /** > * Invoke operation. > * @param input input parameters. > * @param output output parameters. > * > * <p> > * Interaction is done via the parameters. > * Exceptions are not allowed. > * </p> > * <p> > * Basic mappings available at {@link Base}. > * </p> > * > * @see Base > */ > void invoke(ExtMap input, ExtMap output); > > } > >> With second approach mentioned above, core would not interact with >> extensions at all (or in a very limited way), instead - extensions >> would interact with each other. In other words, extension would not >> need to implement core-specific API (there would be none), instead >> it would inject its dependencies (other modules/extensions) and >> consume their APIs. This is the difference I wanted to point out :) > > The extension interface is primitive to enable exactly that, provided java > people will open their minds :) > > Regards, > Alon