[windup-dev] Server migration, the big picture

[Ondrej Zizka]

On 28.4.2015 19:34, Ondrej Zizka wrote:
> Hi all,
>
> as I promised, hereby I am proposing how the migration should look 
> like in the bigger picture.
> I don't say we need all the described parts, but I have a good reason 
> to believe we do.
> Details are described in respective Jira issues. The root Jira issue 
> is MIGR-229.
>
> See the attached whiteboard photo for an overview. Slightly chaotic, 
> as drawn on the fly, and it's not complete anyway. Let's make a better 
> one on F2F.
>
> General:
> ======
>
> 1) Server rules in it's own ruleset. Probably also in separated git 
> repo (as it is now).
>
> 2) The ruleset will reuse certain operations from other rulesets:
>       XPath query to XML documents,
>       .properties parsing,
>       possibly decompilation and analysis of classes - e.g. Tomcat 
> valves, maybe Spring beans, JMX mBeans (esp. for EAP 4), 
> implementations of various interfaces used for EAP 5, etc.
>
> 3) The ruleset will provide certain new
>        conditions, like CLI parsing,
>        and operations, like
>            CLI operations export, in a form of WINDUP-565 
> <https://issues.jboss.org/browse/WINDUP-565>
>                 CLI commands in the report, with comments, highlights 
> of the source it was derived form, links to EAP/WildFly docs, etc.;
>                 CLI commands script;
>                 CLI commands execution against some running server
>            Adding a module to EAP 6 target
>            Installing a fresh target server  (if handy)
>        We can look at Eduardo's WINDUP-550 
> <https://issues.jboss.org/browse/WINDUP-550> to see what we can reuse 
> for these.
>
> 4) The server ruleset will probably have a bit stronger source/target 
> technology split, in terms of respective rules being more organized 
> into individual addons. Not sure about this, depends on the mechanism 
> we use to enable/disable them.
>
> 5) To prevent running the app rules against server files, resp. to 
> support running app and server rules together, we need to update the 
> queries of some app rules to only focus on appropriate files. 
> WINDUP-564 <https://issues.jboss.org/browse/WINDUP-564> and WINDUP-563 
> <https://issues.jboss.org/browse/WINDUP-563> .  This is what I would 
> like to work on next. Now working on WINDUP-566 
> <https://issues.jboss.org/browse/WINDUP-566> .
>
>
>
> Parts:
> ====
> Target technologies:
>   So far, we consider EAP 6 as target server. The long-term goal of 
> EAP 6 is to cover configuration with CLI. Not sure about current 
> state, but it needed some additional actions - direct file 
> manipulation (e.g. modules).
>   Maybe some other target technologies? Depends on what is Windup used 
> for. SOA? Drools? Containers for these might require additional 
> configuration.
>
> Source technologies:
>   The platforms we target long-term. It will be mostly XML and 
> .properties. But could also be more tricky parts, like, digging data 
> from EAP 5's ProfileService, mod_cluster config?, etc.
>
> Platform identification and files comparison: WINDUP-562 
> <https://issues.jboss.org/browse/WINDUP-562> (Done)
>   As discussed during last status meeting, it will be useful to
>       recognize the server version - the user may not know the exact 
> version, which we need to know the default configuration (in case of 
> CLI script migration which just skips the defaults.)
>       recognize which files were changed compared to the distribution 
> of that version - i.e. which configuration files changed (and we don't 
> handle them) and which .jars are changed.
>
> -------------
> Those are rough boundaries. Anything to add or remove? And priorities?
>
>
> Ondra
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20150429/b811cb83/attachment-0001.html