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
                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 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 and WINDUP-563 .  This is what I would like to work on next. Now working on 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  (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