12:34 p.m.
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
