<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Cool. <br><br><span style="background-color: rgba(255, 255, 255, 0);">Brad Davis<br>Red Hat Consulting<br>Email: <a href="mailto:bdavis@redhat.com" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="8">bdavis@redhat.com</a> | c:<a href="tel:980.226.7865" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="9">980.226.7865</a> |<a href="http://www.redhat.com/" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="10">http://www.redhat.com</a> </span><br style="font-family: UICTFontTextStyleBody; -webkit-text-size-adjust: auto;"></div><div><br>On May 9, 2014, at 1:41 PM, Jess Sightler <<a href="mailto:jsightle@redhat.com">jsightle@redhat.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span>I'm sorry for not responding sooner... somehow I missed this email earlier.</span><br><span></span><br><span>Basically I have added a new Type Manager (GraphTypeManager) that </span><br><span>augments the TypeField/TypeValue functionality to support the resolution </span><br><span>of multiple types. It also uses a addon scanner to avoid the need to </span><br><span>hardcode a list of classes for TypedGraphModuleBuilder.</span><br><span></span><br><span>So far this appears to work will for the windup usecase.</span><br><span></span><br><span>On 05/05/2014 01:15 PM, Brad Davis wrote:</span><br><blockquote type="cite"><span>Gotcha. In the current design, it uses TypedGraphModuleBuilder, which is aware of the type via the TypeField annotation, and therefore sets it to one "type" of object. In the current design, I took a similar approach to what you are saying, but accomplished that by the concept of "facets."</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>com.tinkerpop.frames.modules.typedgraph.TypeField;</span><br></blockquote><blockquote type="cite"><span>com.tinkerpop.frames.modules.typedgraph.TypeValue;</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I think if you were trying to accomplish what you are describing, you would need to implement type resolvers (I imagine), and rip out all of the @TypeValue annotations. But haven't done this before in Frames, so it would take some investigation. We should definitely make it easy for those integrating with the Windup API to resolve the appropriate type. Just keep that in mind. But, if there is some sort of DAO that lets you fetch all elements of a given type & casts appropriately, that might be all that is required.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Brad Davis</span><br></blockquote><blockquote type="cite"><span>Red Hat Consulting</span><br></blockquote><blockquote type="cite"><span>Email: <a href="mailto:bdavis@redhat.com">bdavis@redhat.com</a> | c: 980.226.7865 | <a href="http://www.redhat.com">http://www.redhat.com</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>----- Original Message -----</span><br></blockquote><blockquote type="cite"><span>From: "Jess Sightler" <<a href="mailto:jsightle@redhat.com">jsightle@redhat.com</a>></span><br></blockquote><blockquote type="cite"><span>To: <a href="mailto:windup-dev@lists.jboss.org">windup-dev@lists.jboss.org</a></span><br></blockquote><blockquote type="cite"><span>Sent: Monday, May 5, 2014 11:30:06 AM</span><br></blockquote><blockquote type="cite"><span>Subject: Re: [windup-dev] Let's replace the GraphVisitor interface concept with something generic</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I think you are not reading this correctly. That's ok, though, as I</span><br></blockquote><blockquote type="cite"><span>probably didn't describe it correctly. :) I am talking about supporting</span><br></blockquote><blockquote type="cite"><span>types, but supporting them using a model more similar to OWL/RDF than to</span><br></blockquote><blockquote type="cite"><span>classical OO-devleopment. In this model, you do not know all of the</span><br></blockquote><blockquote type="cite"><span>typing information up front, and instead infer type information as you go.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>So, for example, a Vertex may evolve over time to support additional</span><br></blockquote><blockquote type="cite"><span>types as more information is learned. For example, the first rule may</span><br></blockquote><blockquote type="cite"><span>provide a "File", but it later may become "File and ZipFile", and then</span><br></blockquote><blockquote type="cite"><span>ultimately "File and ZipFile and EarFile".</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>During each step of this evolution it retains all of it's</span><br></blockquote><blockquote type="cite"><span>characteristics of the previous step. You can think of it as subclassing</span><br></blockquote><blockquote type="cite"><span>if you want, but eventually the Java model of subclassing will mislead</span><br></blockquote><blockquote type="cite"><span>you about what this means, as it is not necessary for new types to be</span><br></blockquote><blockquote type="cite"><span>subclasses of existing types.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Frames encompasses this concept, and this is the big reason that it uses</span><br></blockquote><blockquote type="cite"><span>Interfaces instead of classes, AFAICT.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>This document may be helpful as well:</span><br></blockquote><blockquote type="cite"><span><a href="http://www.w3.org/TR/sw-oosd-primer/#comparison">http://www.w3.org/TR/sw-oosd-primer/#comparison</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>On 05/05/2014 11:00 AM, Brad Davis wrote:</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>I don't know that I agree. I think it makes sense if we had a black box, but if you are giving Windup API to other people to mash up, I think it might be hard to read a map of many different types of content with many different properties without structure. That is what having real entities provide you. There are only so many types of entities that are present that matter today.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I think by making it untyped, if I am reading this correctly, and just making it meta objects, it will lead to more complexities for those trying to integrate Windup into projects downstream.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Brad Davis</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Red Hat Consulting</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Email: <a href="mailto:bdavis@redhat.com">bdavis@redhat.com</a> | c: 980.226.7865 | <a href="http://www.redhat.com">http://www.redhat.com</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>----- Original Message -----</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>From: "Lincoln Baxter, III" <<a href="mailto:lincolnbaxter@gmail.com">lincolnbaxter@gmail.com</a>></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>To: "Windup-dev List" <<a href="mailto:windup-dev@lists.jboss.org">windup-dev@lists.jboss.org</a>></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Sent: Monday, May 5, 2014 10:34:28 AM</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Subject: Re: [windup-dev] Let's replace the GraphVisitor interface concept with something generic</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Yeah, I actually have to agree with Jess here. I think that the "add more and more information as you go" concept is probably the simplest, and also makes sense from the point-of-view of "improving" what we know the more rules are run.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>On Sun, May 4, 2014 at 7:30 PM, Jess Sightler < <a href="mailto:jsightle@redhat.com">jsightle@redhat.com</a> > wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>On May 2, 2014 5:31 PM, Ondrej Zizka < <a href="mailto:ozizka@redhat.com">ozizka@redhat.com</a> > wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>On 2.5.2014 21:17, Lincoln Baxter wrote:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Hey Ondra,</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I'm moving this discussion to <a href="mailto:windup-dev@lists.jboss.org">windup-dev@lists.jboss.org</a> - please use windup-dev for all non-confidential development discussion.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>In general I support your idea to replace the GraphVisitor interface - I don't think any of us is suggesting that we continue with that approach. But I am concerned that it is more complicated than necessary, and I do have a few concerns about what you've mocked up below:</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>#1) Your concept of replacing nodes is interesting, but what is stopping a rule from replacing a node, then subsequently overwriting or being overwritten by another replacement? I see potential for multiple rules to interfere with each other's types in this way.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>That's the purpose. The rules would interfere. Or rather, infer.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>They would have to be written in a way that they would not do that. You can write an EJB which kills JVM. You can write HQL query which will delete all your entities. You can call wait() in the DSL. Let's assume that user will not write silly rules. Let's give them some freedom and see the rules flourish.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I prefer to think of this in terms of RDF-style classes that operate on the open world assumption: <a href="http://en.m.wikipedia.org/wiki/Open_world_assumption">http://en.m.wikipedia.org/wiki/Open_world_assumption</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>In this model, you don't replace types, you add additional type information, and inferred properties as you discover more things about a particular entity. If you'd like, I can try to put together a little mini presentation on rdf and owl, as I believe we may be re-solving some problems that those groups have already solved pretty well. :-)</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>From my research on Friday, I believe that this OWA type model may actually be supported pretty well by Tinkerpop frames.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>We can discuss further next week, as I am sure the above is insufficient. :-)</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Further - the replacement would simply happen for certain cases. E.g. Maven POM file will never be anything else, so a XmlFileNode can be changed to MavenPomFileNode. In other cases, rules would create new nodes and connect them. Also - these possible collisions can be easily detected - if some migrator asks for a XmlFileNode, and then asks to change it to some subtype while it already is another subtype, -> warning or error.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>#2) I'm also not sure that the graph would allow you to dynamically replace nodes of one type with nodes of another. Can you verify that?</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I didn't find anything related in <a href="https://github.com/thinkaurelius/titan/wiki/Titan-Limitations">https://github.com/thinkaurelius/titan/wiki/Titan-Limitations</a> (those type limitations seem to apply on other things). I'll try practically.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>#3) You asked: "Forge UI could be mapped to XML elements. I.e. <aaa foo="bar"/> could invoke command "aaa" with given params.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I believe Forge already has this way of input, right?"</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I'm not completely following your example here, but in theory you could map XML elements and their attributes to forge commands and their options in this way; nonetheless, I don't think that this is a good use of the Forge command model. You're better off just mapping to Java objects of some type.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Ok, I thought forge UI could be the way to do the mapping, since it has the type conversion already done, but we can duplicate that outside Forge, too.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>#4) This seems more complicated than the example Visitor you linked. Now instead of one Java file containing the rule, and two java interfaces to encapsulate the data storage in the graph, you have two very convoluted XML files. I actually think that the JAXB bit is fairly nice, but the code required to do that in your example would work in the current approach anyway because it would still need to be implemented somewhere.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Yes and no.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>1) The Visitor is custom Java code and of course, with access to all Java libraries in the world, you can make it matter of few lines. But we are heading towards rules which allow non-trivial operations while being limited to just several concepts. In this proposal, free-form Java code would be replaced with those few mentioned: Service calls, Graph queries, JAXB, EL, iteration, rules dependency,</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>IMO, if we don't create something such, we will end up with rules which will be just a thin wrapper around services.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>2) This XML example doesn't map to the visitor 1:1, it's better. The approach is different. In that java code, there are two tasks mixed into one: Discover Maven POM files, and load the dependencies.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>What if the pom files will be added by a custom migrator? E.g. when they have different doctype. Then this visitor would miss them and not scan their dependencies.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>In this approach, the second rule would pick up the MavenPomFileNode no matter where it comes from.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I could have written the example 1:1 but wanted to show this task separation advantage.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>This is similar to what I am prototyping in the config addon, but in XML not in Java. If you want to continue with this idea of reducing the operations to operate more closely with the graph, I support that, but let's please try to find a way to mock it up using the config DSL instead.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Okay, let's see what we have.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>As far as implementing this goes - the syntax you've described below would probably work by mapping to our Java DSL using Reflection, but that's to be done once the java config API is established.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Java first. Then XML (or whatever).</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Hmm. About 4 months ago, it was exactly opposite: XML rules, no Java.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>It was also one of the main reasons to abandon WindRide the XML rules were implemented.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>The argument was that rules authors will not create Java projects and study some framework (e.g. Forge) to be able to write a trivial rule like "if com.foo.Bar is found, report a warning with a comment and a link to docs XY".</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>When did this change, and what's the guarantee that it won't change again?</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Ondra</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>~Lincoln</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>________________________________</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>From: "Ondrej Zizka" < <a href="mailto:ozizka@redhat.com">ozizka@redhat.com</a> ></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>To: <a href="mailto:jboss-migration@redhat.com">jboss-migration@redhat.com</a></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Sent: Thursday, May 1, 2014 12:05:23 AM</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Subject: Re: Let's replace the GraphVisitor interface concept with something generic</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I've put it to this doc so we can edit/comment there.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><a href="https://docs.google.com/document/d/1UOihPv_zryFilCb7T0k8992wPUt3YNP4goh9rxTC7ng/edit#">https://docs.google.com/document/d/1UOihPv_zryFilCb7T0k8992wPUt3YNP4goh9rxTC7ng/edit#</a></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Ondra</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>On 1.5.2014 04:35, Ondrej Zizka wrote:</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Hi,</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>as we discussed before, I'd like to replace the GraphVisitor interface with something generic.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Seriously, having hard-coded interface with methods specific for e.g. MessageDrivenBean, EjbEntity, SpringConfiguration, etc. is IMO not the way to go. It is hard to extend. A rule system created around this would be cumbersome.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>public void visitEjbEntity(EjbEntityFacet entry);</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>public void visitEjbService(EjbSessionBeanFacet entry);</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>public void visitMessageDrivenBean(MessageDrivenBeanFacet entry);</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>public void visitEjbEntity(SpringBeanFacet entry);</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>...</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Instead, we should focus on the graph, and have just very few node types in the core - FileNode, and the rest would be subtypes defined in addons. Addons would, through rules:</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>* replace a node with a subclass, e.g.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>FileNode => XmlFileNode => MavenPomNode,</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>FileNode => JavaFileNode => AnnotationNode</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>* add properties, e.g.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>XmlFileNode's "doctype",</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>ClassNode's "blacklisted"</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>* connect nodes to them, e.g.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>MavenPom ---contains---> MavenDependencyNode</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>JavaFile --- imports --> [ ClassNode, ClassNode, ... ]</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>This approach would:</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>* Leverage of Forge modularity (e.g. Maven addon depending on XmlFile addon)</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>* Improve extendability (no need to squeeze everything into the GraphVisitor interface's methods or extend it)</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>* Lead to much more straightforward rules implementation - all rules would reduce to:</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>* matching graph information (Gremlin?)</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>* using DAO's / Services (for mining data from the files/..., and for writing them during active migration)</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>1) Bundled - XPath, AST query, properties, Maven remote fetch, ...</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>2) User's: .class packed within the addon or a Groovy class</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>* writing back to the graph</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>* rendering pieces of HTML for the report.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Who's in? I need some scenarios where this wouldn't work. But from what I can tell, this would be more generic, but still simpler, than current "God-object" suffering GraphVisitor.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>As an example, take e.g. MavenRemoteFetchVisitor. <a href="https://github.com/windup/windup/blob/master/engine/rules/impl/src/main/java/org/jboss/windup/engine/visitor/inspector/MavenRemoteFetchVisitor.java">https://github.com/windup/windup/blob/master/engine/rules/impl/src/main/java/org/jboss/windup/engine/visitor/inspector/MavenRemoteFetchVisitor.java</a></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>All that is doable using few simple building blocks, directed by few lines of a rule like this:</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>------------------------------------------------------------------</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><var name="pomNS" val=" <a href="http://maven.apache.org/POM/4.0.0">http://maven.apache.org/POM/4.0.0</a> "></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Rule 1) which would process all POM files and load the info into the graph.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><rule id="maven.pomFiles" desc=" Analyze Maven POM files "</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>phase="StaticConfigAnalysis"></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><graph match="XmlFileNode[doctype=' <a href="http://maven.apache.org/POM/4.0.0'">http://maven.apache.org/POM/4.0.0'</a> ]" toVar="xmls"></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><for var="pom" in="xmls"></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><graph:replaceSingle ref="pom" with="MavenPomFileNode"></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><properties></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><!-- <jaxb> would invoce a call to a Service.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><properties> hander would take returned object's bean props.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>toClass would load the class from CL or compile from .groovy coming with the migrator (addon).</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>--></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><jaxb toClass="PomJaxb.groovy" fromFile="${pom.path}"></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><ns name="pom" uri="${pomNS}"/></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></jaxb></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></properties></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></graph></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></for></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></rule></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>@XmlRoot</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>class PomJaxb {</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>@XmlXPath("/pom:project/pom:modelVersion") String modelVersion;</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>@XmlXPath("/pom:project/pom:name") String name;</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>@XmlXPath("/pom:project/pom:description" String description;</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>@XmlXPath("/pom:project/pom:url" String url;</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>}</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Rule 2) which would load the dependencies and describe them into Nodes and Edges.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><rule id="maven.pomDependencies" desc=" Analyze Maven POM file dependencies "</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>phase="StaticConfigAnalysis"></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><after rule="maven.pomFiles"></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><graph match="MavenPomFileNode" toVar="pomVertexes"></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><for var="pomV" in="pomVertexes"></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><xpath toVar="deps" fromFile="${pomV.path}" match="/pom:project/pom:dependencies/pom:dependency"/></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><for var="depElement" in="deps"></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><jaxb toVar="dep" toClass="MavenDepencencyJaxb.groovy" fromElement="depElement" ns="pom ${pomNS}"/></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><graph:query toVar="isBlacklisted"</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>q=" /* I don't know Gremlin so far, imagine an equiv of this XPath: */</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>MavenDependencyNode[</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>g=${dep.groupId} and a=${dep.artifactId} and v=${dep.version}</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>]@blacklisted</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>" /></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><continue if="isBlacklisted /* var, or Groovy (or EL) expression */" /></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><!-- This would be useful for blacklists and filters in general, which appear often in real life rules. --></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><graph:insertIfNotExists type="MavenDependencyNode" toVar="depVertex></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><properties from="dep"/></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></graph></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><graph:edge type="dependsOn" from="pomV" to="depVertex"/></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><!-- Maybe Gremlin could replace this? --></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></for></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></for></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></rule></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>@XmlRoot</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>class MavenDepencencyJaxb {</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>// GraphKeyProperty identifies those which are compared for insertIfNotExists.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>@GraphKeyProperty @XmlXPath("./pom:groupId") String groupId;</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>@GraphKeyProperty @XmlXPath("./pom:artifactId") String artifactId;</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>@GraphKeyProperty @XmlXPath("./pom:version") String version;</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>}</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>------------------------------------------------------------------</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>As you can see, It creates independent rules which only communicate indirectly through the graph.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>You can also see how nicely Java classes fit into this, and how Groovy could make this easier.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>SERVICES INVOCATION</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Forge UI could be mapped to XML elements. I.e. <aaa foo="bar"/> could invoke command "aaa" with given params.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I believe Forge already has this way of input, right?</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>GRAPH OPERATION</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>There would be several <graph:...> operations - CRUD plus some special.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>EXECUTION FLOW</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>The flow would be simple, from top to bottom, creating variables along the way, containing objects or iterable collections of objects. Those iterable could be used in <for>.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Does Lincoln's executor fit this? I haven't still looked how it works. This tree would likely be executed classically with a stack and using tree reduction for operation arguments.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>For more complex logic, users would break the task into multiple rules, storing data into the graph intermediately.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I'll check few more visitors to see if this is powerful enough to satisfy all the baneeds.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>.............................</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Also, I'd like to eradicate any mention of an archive from most of the code - archives should be totally transparent for the migrators. There should be just FileNodes, connected with ArchiveNodes, and whoever needs an information that a file came from an archive, may look that up. See <a href="https://docs.google.com/drawings/d/1IMnds3Qu8Wwcf7_mr7NJ9a3YgtcGJ7dejl09EhWl7Vc">https://docs.google.com/drawings/d/1IMnds3Qu8Wwcf7_mr7NJ9a3YgtcGJ7dejl09EhWl7Vc</a> for illustration.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Ondra</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>_______________________________________________</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>windup-dev mailing list</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="mailto:windup-dev@lists.jboss.org">windup-dev@lists.jboss.org</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="https://lists.jboss.org/mailman/listinfo/windup-dev">https://lists.jboss.org/mailman/listinfo/windup-dev</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span>_______________________________________________</span><br></blockquote><blockquote type="cite"><span>windup-dev mailing list</span><br></blockquote><blockquote type="cite"><span><a href="mailto:windup-dev@lists.jboss.org">windup-dev@lists.jboss.org</a></span><br></blockquote><blockquote type="cite"><span><a href="https://lists.jboss.org/mailman/listinfo/windup-dev">https://lists.jboss.org/mailman/listinfo/windup-dev</a></span><br></blockquote><blockquote type="cite"><span>_______________________________________________</span><br></blockquote><blockquote type="cite"><span>windup-dev mailing list</span><br></blockquote><blockquote type="cite"><span><a href="mailto:windup-dev@lists.jboss.org">windup-dev@lists.jboss.org</a></span><br></blockquote><blockquote type="cite"><span><a href="https://lists.jboss.org/mailman/listinfo/windup-dev">https://lists.jboss.org/mailman/listinfo/windup-dev</a></span><br></blockquote><span></span><br><span>_______________________________________________</span><br><span>windup-dev mailing list</span><br><span><a href="mailto:windup-dev@lists.jboss.org">windup-dev@lists.jboss.org</a></span><br><span><a href="https://lists.jboss.org/mailman/listinfo/windup-dev">https://lists.jboss.org/mailman/listinfo/windup-dev</a></span><br></div></blockquote></body></html>