[wildfly-dev] Analyse the management model

[Brian Stansberry]

If version was an distinguishing property of a resource node then the relationship between versions becomes another edge.

Or version is a node and the relationship between versions are edges.

Either way those relationships aren’t really clear though. Version 1.7 and 2.0 may both be descendants of version 1.6 but 2.0 is not directly related to 1.7. And we don’t store the kind of version relationship data that would allow that to be worked out automatically.

Anyway, this stuff is a bit of a tangent, although a worthy one. On the main point, cool! Good job. Just last week I was messing around looking for cases where we had attributes that were both required and had a default (which is wrong since the ‘required’ makes the default pointless). This would have saved me some time and probably still will as I’m sure I’ll have to redo the search to make sure I got it right.

> On Feb 6, 2017, at 7:33 AM, Harald Pehl <hpehl at redhat.com> wrote:
> 
> Good point. I guess this could easily be done by moving this to
> OpenShift. With dedicated WildFly / Neo4j instances for each major
> WildFly version. This way we could also provide an online Neo4j
> browser (similar to [1] and [2]). Even with a custom documentation and
> mini guides.
> 
> [1] https://stackoverflow.com/questions/37370820/hosting-a-public-read-only-neo4j-instance-in-the-cloud
> [2] http://neo4j.het.io/browser/
> 
> On Mon, Feb 6, 2017 at 2:14 PM, Kabir Khan <kabir.khan at jboss.com> wrote:
>> Very cool. If we could have the neo4j server somewhere central, perhaps we could eventually do the comparisons of model versions from there?
>>> On 6 Feb 2017, at 11:15, Harald Pehl <hpehl at redhat.com> wrote:
>>> 
>>> TL;DR
>>> 
>>> A tool to analyse the WildFly management model tree using a graph database.
>>> 
>>> # Longer version
>>> 
>>> As a heavy consumer of the WildFly management model I've always been
>>> looking for a way to analyse the management model. So I decided to
>>> start a little side project over the weekend. The result is a tool [1]
>>> which reads a (sub)tree of the WildFly management model and stores the
>>> results into a graph database using Neo4j [2]. To get started, you
>>> need a running WildFly and Neo4j instance.
>>> 
>>> The tool writes nodes for each resource, attribute, operation, request
>>> property and capability. In addition it creates relationships between
>>> these nodes. You can use the data to
>>> 
>>> - get alternatives and requires relations between attributes
>>> - get deprecated attributes and request parameters for one or all resources
>>> - find attributes which might miss a capability reference
>>> - find inconsistent attributes
>>> - see differences between resources (using external diff tools)
>>> 
>>> See [3] for more use cases. I hope this is useful for others as well.
>>> Feedback, suggestions and critics are welcome!
>>> 
>>> [1] https://github.com/hal/model-graph
>>> [2] https://neo4j.com/
>>> [3] https://github.com/hal/model-graph#examples
>>> 
>>> --
>>> Harald Pehl
>>> JBoss by Red Hat
>>> http://hpehl.info
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
> 
> 
> 
> -- 
> Harald Pehl
> JBoss by Red Hat
> http://hpehl.info
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat