From lbaxter at redhat.com  Fri May  2 15:17:45 2014
From: lbaxter at redhat.com (Lincoln Baxter)
Date: Fri, 2 May 2014 15:17:45 -0400 (EDT)
Subject: [windup-dev] Let's replace the GraphVisitor interface concept
	with something	generic
In-Reply-To: <5361C803.5040409@redhat.com>
References: <5361B2DE.60101@redhat.com> <5361C803.5040409@redhat.com>
Message-ID: <455050578.12453669.1399058265626.JavaMail.zimbra@redhat.com>

Hey Ondra, 

I'm moving this discussion to windup-dev at lists.jboss.org - please use windup-dev for all non-confidential development discussion. 

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: 

#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. 

#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? 

#3) You asked: " Forge UI could be mapped to XML elements. I.e. <aaa foo="bar"/> could invoke command "aaa" with given params. 
I believe Forge already has this way of input, right?" 

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. 

#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. 

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. 

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. 

Java first. Then XML (or whatever). 

~Lincoln 

----- Original Message -----

From: "Ondrej Zizka" <ozizka at redhat.com> 
To: jboss-migration at redhat.com 
Sent: Thursday, May 1, 2014 12:05:23 AM 
Subject: Re: Let's replace the GraphVisitor interface concept with something generic 

I've put it to this doc so we can edit/comment there. 

https://docs.google.com/document/d/1UOihPv_zryFilCb7T0k8992wPUt3YNP4goh9rxTC7ng/edit# 

Ondra 



On 1.5.2014 04:35, Ondrej Zizka wrote: 


Hi, 

as we discussed before, I'd like to replace the GraphVisitor interface with something generic. 
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. 

public void visitEjbEntity(EjbEntityFacet entry); 
public void visitEjbService(EjbSessionBeanFacet entry); 
public void visitMessageDrivenBean(MessageDrivenBeanFacet entry); 
public void visitEjbEntity(SpringBeanFacet entry); 
... 



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: 
* replace a node with a subclass, e.g. 
FileNode => XmlFileNode => MavenPomNode, 
FileNode => JavaFileNode => AnnotationNode 

* add properties, e.g. 
XmlFileNode's "doctype", 
ClassNode's "blacklisted" 
* connect nodes to them, e.g. 
MavenPom ---contains---> MavenDependencyNode 
JavaFile --- imports --> [ ClassNode, ClassNode, ... ] 

This approach would: 
* Leverage of Forge modularity (e.g. Maven addon depending on XmlFile addon) 
* Improve extendability (no need to squeeze everything into the GraphVisitor interface's methods or extend it) 
* Lead to much more straightforward rules implementation - all rules would reduce to: 
* matching graph information (Gremlin?) 
* using DAO's / Services (for mining data from the files/..., and for writing them during active migration) 
1) Bundled - XPath, AST query, properties, Maven remote fetch, ... 
2) User's: .class packed within the addon or a Groovy class 
* writing back to the graph 
* rendering pieces of HTML for the report. 

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. 

As an example, take e.g. MavenRemoteFetchVisitor. https://github.com/windup/windup/blob/master/engine/rules/impl/src/main/java/org/jboss/windup/engine/visitor/inspector/MavenRemoteFetchVisitor.java 

All that is doable using few simple building blocks, directed by few lines of a rule like this: 

------------------------------------------------------------------ 

<var name="pomNS" val= "http://maven.apache.org/POM/4.0.0" > 

Rule 1) which would process all POM files and load the info into the graph. 

<rule id="maven.pomFiles" desc=" Analyze Maven POM files " 
phase="StaticConfigAnalysis"> 
<graph match="XmlFileNode[doctype=' http://maven.apache.org/POM/4.0.0 ']" toVar="xmls"> 
<for var="pom" in="xmls"> 
<graph:replaceSingle ref="pom" with="MavenPomFileNode"> 
<properties> 
<!-- <jaxb> would invoce a call to a Service. 
<properties> hander would take returned object's bean props. 
toClass would load the class from CL or compile from .groovy coming with the migrator (addon). 
--> 
<jaxb toClass="PomJaxb.groovy" fromFile="${pom.path}"> 
<ns name="pom" uri="${pomNS}"/> 
</jaxb> 
</properties> 
</graph> 
</for> 
</rule> 

@XmlRoot 
class PomJaxb { 
@XmlXPath( "/pom:project/pom:modelVersion" ) String modelVersion ; 
@XmlXPath( "/pom:project/pom:name" ) String name ; 
@XmlXPath( "/pom:project/pom:description" String description ; 
@XmlXPath( "/pom:project/pom:url" String url; 
} 


Rule 2) which would load the dependencies and describe them into Nodes and Edges. 

<rule id="maven.pomDependencies" desc=" Analyze Maven POM file dependencies " 
phase="StaticConfigAnalysis"> 
<after rule="maven.pomFiles"> 

<graph match="MavenPomFileNode" toVar="pomVertexes"> 
<for var="pomV" in="pomVertexes"> 

<xpath toVar="deps" fromFile="${pomV.path}" match="/pom:project/pom:dependencies/pom:dependency"/> 
<for var="depElement" in="deps"> 
<jaxb toVar="dep" toClass="MavenDepencencyJaxb.groovy" fromElement="depElement" ns="pom ${pomNS}"/> 
<graph:query toVar="isBlacklisted" 
q=" /* I don't know Gremlin so far, imagine an equiv of this XPath: */ 
MavenDependencyNode[ 
g=${dep.groupId} and a=${dep.artifactId} and v=${dep.version} 
]@blacklisted 
" /> 
<continue if="isBlacklisted /* var, or Groovy (or EL) expression */" /> 
<!-- This would be useful for blacklists and filters in general, which appear often in real life rules. --> 

<graph:insertIfNotExists type="MavenDependencyNode" toVar="depVertex> 
<properties from="dep"/> 
</graph> 
<graph:edge type="dependsOn" from="pomV" to="depVertex"/> 
<!-- Maybe Gremlin could replace this? --> 
</for> 
</for> 
</rule> 

@XmlRoot 
class MavenDepencencyJaxb { 
// GraphKeyProperty identifies those which are compared for insertIfNotExists. 
@GraphKeyProperty @XmlXPath("./pom:groupId") String groupId; 
@GraphKeyProperty @XmlXPath("./pom:artifactId") String artifactId; 
@GraphKeyProperty @XmlXPath("./pom:version") String version; 
} 
------------------------------------------------------------------ 

As you can see, It creates independent rules which only communicate indirectly through the graph. 
You can also see how nicely Java classes fit into this, and how Groovy could make this easier. 

SERVICES INVOCATION 
Forge UI could be mapped to XML elements. I.e. <aaa foo="bar"/> could invoke command "aaa" with given params. 
I believe Forge already has this way of input, right? 

GRAPH OPERATION 
There would be several <graph:...> operations - CRUD plus some special. 

EXECUTION FLOW 
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>. 

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. 

For more complex logic, users would break the task into multiple rules, storing data into the graph intermediately. 

I'll check few more visitors to see if this is powerful enough to satisfy all the baneeds. 


............................. 

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 https://docs.google.com/drawings/d/1IMnds3Qu8Wwcf7_mr7NJ9a3YgtcGJ7dejl09EhWl7Vc for illustration. 

Ondra 








-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140502/e9554984/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 12554 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/windup-dev/attachments/20140502/e9554984/attachment-0001.jpe 

From ozizka at redhat.com  Fri May  2 16:20:46 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Fri, 02 May 2014 22:20:46 +0200
Subject: [windup-dev] Let's replace the GraphVisitor interface concept
 with something generic
In-Reply-To: <455050578.12453669.1399058265626.JavaMail.zimbra@redhat.com>
References: <5361B2DE.60101@redhat.com> <5361C803.5040409@redhat.com>
	<455050578.12453669.1399058265626.JavaMail.zimbra@redhat.com>
Message-ID: <5363FE1E.1030704@redhat.com>


On 2.5.2014 21:17, Lincoln Baxter wrote:
> Hey Ondra,
>
> I'm moving this discussion to windup-dev at lists.jboss.org 
> <mailto:windup-dev at lists.jboss.org> - please use windup-dev for all 
> non-confidential development discussion.
>
> 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:
>
> *#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.
That's the purpose. The rules would interfere. Or rather, infer.
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.

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.

> *#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?
I didn't find anything related in 
https://github.com/thinkaurelius/titan/wiki/Titan-Limitations (those 
type limitations seem to apply on other things). I'll try practically.
>
> *#3)* You asked: "Forge UI could be mapped to XML elements. I.e.  <aaa 
> foo="bar"/> could invoke command "aaa" with given params.
> I believe Forge already has this way of input, right?"
>
> 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.
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.
>
> *#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.
Yes and no.

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,
IMO, if we don't create something such, we will end up with rules which 
will be just a thin wrapper around services.

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.
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.
In this approach, the second rule would pick up the MavenPomFileNode no 
matter where it comes from.
I could have written the example 1:1 but wanted to show this task 
separation advantage.


>
> 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.
Okay, let's see what we have.
>
> 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.
>
> Java first. Then XML (or whatever).
Hmm. About 4 months ago, it was exactly opposite: XML rules, no Java.
It was also one of the main reasons to abandon WindRide the XML rules 
were implemented.
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".
When did this change, and what's the guarantee that it won't change again?

Ondra

>
> ~Lincoln
>
> ------------------------------------------------------------------------
> *From: *"Ondrej Zizka" <ozizka at redhat.com>
> *To: *jboss-migration at redhat.com
> *Sent: *Thursday, May 1, 2014 12:05:23 AM
> *Subject: *Re: Let's replace the GraphVisitor interface concept with 
> something        generic
>
> I've put it to this doc so we can edit/comment there.
>
> https://docs.google.com/document/d/1UOihPv_zryFilCb7T0k8992wPUt3YNP4goh9rxTC7ng/edit#
>
> Ondra
>
>
>
> On 1.5.2014 04:35, Ondrej Zizka wrote:
>
>     Hi,
>
>     as we discussed before, I'd like to replace the GraphVisitor
>     interface with something generic.
>     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.
>
>         public void visitEjbEntity(EjbEntityFacet entry);
>         public void visitEjbService(EjbSessionBeanFacet entry);
>         public void visitMessageDrivenBean(MessageDrivenBeanFacet entry);
>         public void visitEjbEntity(SpringBeanFacet entry);
>         ...
>
>     <http://www.google.hu/imgres?imgurl=http%3A%2F%2Fimages.firstcovers.com%2Fcovers%2Fuserquotes%2Fn%2Fno_matter_how_far-133551.jpg&imgrefurl=http%3A%2F%2Fwww.firstcovers.com%2Fuserquotes%2F133551%2Fno%2Bmatter%2Bhow%2Bfar.html&h=315&w=850&tbnid=KPt-4-d8G4ur7M%3A&zoom=1&docid=70YydZev__q0ZM&ei=35phU6_WJ8LcOevqgPgP&tbm=isch&client=ubuntu&ved=0CF0QMygIMAg&iact=rc&uact=3&dur=651&page=1&start=0&ndsp=31>
>
>     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:
>          *  replace a node with a subclass, e.g.
>                   FileNode => XmlFileNode => MavenPomNode,
>                   FileNode => JavaFileNode => AnnotationNode
>
>          *  add properties, e.g.
>                   XmlFileNode's "doctype",
>                   ClassNode's "blacklisted"
>          *  connect nodes to them, e.g.
>                   MavenPom ---contains---> MavenDependencyNode
>                   JavaFile --- imports --> [ ClassNode, ClassNode, ... ]
>
>     This approach would:
>         * Leverage of Forge modularity (e.g. Maven addon depending on
>     XmlFile addon)
>         * Improve extendability (no need to squeeze everything into
>     the GraphVisitor interface's methods or extend it)
>         * Lead to much more straightforward rules implementation - all
>     rules would reduce to:
>              * matching graph information (Gremlin?)
>              * using DAO's / Services (for mining data from the
>     files/..., and for writing them during active migration)
>                      1) Bundled - XPath, AST query, properties, Maven
>     remote fetch, ...
>                      2) User's:  .class packed within the addon or a
>     Groovy class
>              * writing back to the graph
>              * rendering pieces of HTML for the report.
>
>     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.
>
>     As an example, take e.g. MavenRemoteFetchVisitor.
>     https://github.com/windup/windup/blob/master/engine/rules/impl/src/main/java/org/jboss/windup/engine/visitor/inspector/MavenRemoteFetchVisitor.java
>
>     All that is doable using few simple building blocks, directed by
>     few lines of a rule like this:
>
>     ------------------------------------------------------------------
>
>     <var name="pomNS" val="http://maven.apache.org/POM/4.0.0">
>
>     Rule 1) which would process all POM files and load the info into
>     the graph.
>
>     <rule id="maven.pomFiles" desc="   Analyze Maven POM files  "
>               phase="StaticConfigAnalysis">
>         <graph
>     match="XmlFileNode[doctype='http://maven.apache.org/POM/4.0.0']"
>     toVar="xmls">
>         <for var="pom" in="xmls">
>               <graph:replaceSingle ref="pom" with="MavenPomFileNode">
>                    <properties>
>                         <!-- <jaxb> would invoce a call to a Service.
>                                <properties> hander would take returned
>     object's bean props.
>                                toClass would load the class from CL or
>     compile from .groovy coming with the migrator (addon).
>                          -->
>                         <jaxb toClass="PomJaxb.groovy"
>     fromFile="${pom.path}">
>                                <ns name="pom" uri="${pomNS}"/>
>                         </jaxb>
>                     </properties>
>               </graph>
>           </for>
>     </rule>
>
>     @XmlRoot
>     class PomJaxb {
>            @XmlXPath("/pom:project/pom:modelVersion") String
>     modelVersion;
>            @XmlXPath("/pom:project/pom:name") String name;
>            @XmlXPath("/pom:project/pom:description"String description;
>            @XmlXPath("/pom:project/pom:url"                          
>     String url;
>     }
>
>
>     Rule 2) which would load the dependencies and describe them into
>     Nodes and Edges.
>
>     <rule id="maven.pomDependencies" desc="   Analyze Maven POM file
>     dependencies  "
>               phase="StaticConfigAnalysis">
>          <after rule="maven.pomFiles">
>
>          <graph match="MavenPomFileNode" toVar="pomVertexes">
>          <for var="pomV" in="pomVertexes">
>
>               <xpath toVar="deps" fromFile="${pomV.path}"
>     match="/pom:project/pom:dependencies/pom:dependency"/>
>               <for var="depElement" in="deps">
>                   <jaxb toVar="dep"
>     toClass="MavenDepencencyJaxb.groovy" fromElement="depElement"
>     ns="pom ${pomNS}"/>
>                   <graph:query toVar="isBlacklisted"
>                        q=" /*  I don't know Gremlin so far, imagine an
>     equiv of this XPath: */
>                            MavenDependencyNode[
>                                  g=${dep.groupId} and
>     a=${dep.artifactId} and v=${dep.version}
>                            ]@blacklisted
>                   " />
>                   <continue if="isBlacklisted /* var, or Groovy (or
>     EL) expression */" />
>                   <!-- This would be useful for blacklists and filters
>     in general, which appear often in real life rules. -->
>
>                   <graph:insertIfNotExists type="MavenDependencyNode"
>     toVar="depVertex>
>                        <properties from="dep"/>
>                   </graph>
>                   <graph:edge type="dependsOn" from="pomV"
>     to="depVertex"/>
>                                 <!-- Maybe Gremlin could replace this? -->
>               </for>
>         </for>
>     </rule>
>
>     @XmlRoot
>     class MavenDepencencyJaxb {
>           // GraphKeyProperty identifies those which are compared for
>     insertIfNotExists.
>           @GraphKeyProperty  @XmlXPath("./pom:groupId")   String groupId;
>           @GraphKeyProperty  @XmlXPath("./pom:artifactId") String
>     artifactId;
>           @GraphKeyProperty  @XmlXPath("./pom:version")   String version;
>     }
>     ------------------------------------------------------------------
>
>     As you can see, It creates independent rules which only
>     communicate indirectly through the graph.
>     You can also see how nicely Java classes fit into this, and how
>     Groovy could make this easier.
>
>     SERVICES INVOCATION
>     Forge UI could be mapped to XML elements. I.e.  <aaa foo="bar"/>
>     could invoke command "aaa" with given params.
>     I believe Forge already has this way of input, right?
>
>     GRAPH OPERATION
>     There would be several <graph:...> operations - CRUD plus some
>     special.
>
>     EXECUTION FLOW
>     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>.
>
>     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.
>
>     For more complex logic, users would break the task into multiple
>     rules, storing data into the graph intermediately.
>
>     I'll check few more visitors to see if this is powerful enough to
>     satisfy all the baneeds.
>
>
>     .............................
>
>     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
>     https://docs.google.com/drawings/d/1IMnds3Qu8Wwcf7_mr7NJ9a3YgtcGJ7dejl09EhWl7Vc
>     for illustration.
>
>     Ondra
>
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140502/6ca821ad/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 12554 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/windup-dev/attachments/20140502/6ca821ad/attachment-0001.jpe 

From lbaxter at redhat.com  Fri May  2 17:18:30 2014
From: lbaxter at redhat.com (Lincoln Baxter)
Date: Fri, 2 May 2014 17:18:30 -0400 (EDT)
Subject: [windup-dev] Let's replace the GraphVisitor interface concept
 with something generic
In-Reply-To: <5363FE1E.1030704@redhat.com>
References: <5361B2DE.60101@redhat.com> <5361C803.5040409@redhat.com>
	<455050578.12453669.1399058265626.JavaMail.zimbra@redhat.com>
	<5363FE1E.1030704@redhat.com>
Message-ID: <135875554.12520295.1399065510383.JavaMail.zimbra@redhat.com>

To address your points: 

#1) " Let's assume that user will not write silly rules. Let's give them some freedom and see the rules flourish." 

We can't assume that users won't do silly things. Users always do silly things and always find ways to break things. The Java-based rules DSL that I've proposed both encourages the user to be a "good citizen" and allows them the freedom to do whatever they like. As I said before, I'd like it if you could think about how to implement your approach using this as a starting point. I agree with you that the data can be represented in the graph in any way imaginable. I'm a little worried that you're still looking at the GraphVisitor stuff that's there now and thinking that's the direction we are headed in - The GraphVisitor is all going to be replaced with the config java DSL (or something java if that doesn't work out.) 

#3) I thought forge UI could be the way to do the mapping, since it has the type conversion already done 

If you're looking for dynamic/automatic type conversion, just use the Forge conversion addon - https://github.com/forge/core/tree/master/convert#features - no need to bring in the UI for that, as far as I know. 

#4) About 4 months ago, it was exactly opposite: XML rules, no Java. When did this change, and what's the guarantee that it won't change again? 

This hasn't changed. We won't not require users to write Java and compile projects to write rules, I'm saying that we should design the Java APIs first or at *least* in parallel to designing any XML or non-native rule format. If you take a look at the config addon - it should look very similar to the XML you've written below: https://github.com/windup/windup/tree/master/engine/config/api/src/main/java/org/jboss/windup/addon/config 

Is it possible that the Java DSL approach won't work out? Yes, but I think, at this moment, it provides us a great deal of flexibility, and at the same time does not impede your goal of representing the graph data with lower-level, more abstract constructs. Think of it as an implementation of what you have proposed in this thread - the java that makes your XML work. 

~Lincoln 


----- Original Message -----

From: "Ondrej Zizka" <ozizka at redhat.com> 
To: "Lincoln Baxter" <lbaxter at redhat.com> 
Cc: windup-dev at lists.jboss.org 
Sent: Friday, May 2, 2014 4:20:46 PM 
Subject: Re: Let's replace the GraphVisitor interface concept with something generic 


On 2.5.2014 21:17, Lincoln Baxter wrote: 



Hey Ondra, 

I'm moving this discussion to windup-dev at lists.jboss.org - please use windup-dev for all non-confidential development discussion. 

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: 

#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. 


That's the purpose. The rules would interfere. Or rather, infer. 
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. 

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. 


<blockquote>

#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? 

</blockquote>
I didn't find anything related in https://github.com/thinkaurelius/titan/wiki/Titan-Limitations (those type limitations seem to apply on other things). I'll try practically. 

<blockquote>


#3) You asked: " Forge UI could be mapped to XML elements. I.e. <aaa foo="bar"/> could invoke command "aaa" with given params. 
I believe Forge already has this way of input, right?" 

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. 

</blockquote>
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. 

<blockquote>


#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. 

</blockquote>
Yes and no. 

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, 
IMO, if we don't create something such, we will end up with rules which will be just a thin wrapper around services. 

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. 
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. 
In this approach, the second rule would pick up the MavenPomFileNode no matter where it comes from. 
I could have written the example 1:1 but wanted to show this task separation advantage. 



<blockquote>


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. 

</blockquote>
Okay, let's see what we have. 

<blockquote>


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. 

Java first. Then XML (or whatever). 

</blockquote>
Hmm. About 4 months ago, it was exactly opposite: XML rules, no Java. 
It was also one of the main reasons to abandon WindRide the XML rules were implemented. 
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". 
When did this change, and what's the guarantee that it won't change again? 

Ondra 


<blockquote>


~Lincoln 

----- Original Message -----

From: "Ondrej Zizka" <ozizka at redhat.com> 
To: jboss-migration at redhat.com 
Sent: Thursday, May 1, 2014 12:05:23 AM 
Subject: Re: Let's replace the GraphVisitor interface concept with something generic 

I've put it to this doc so we can edit/comment there. 

https://docs.google.com/document/d/1UOihPv_zryFilCb7T0k8992wPUt3YNP4goh9rxTC7ng/edit# 

Ondra 



On 1.5.2014 04:35, Ondrej Zizka wrote: 

<blockquote>
Hi, 

as we discussed before, I'd like to replace the GraphVisitor interface with something generic. 
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. 

public void visitEjbEntity(EjbEntityFacet entry); 
public void visitEjbService(EjbSessionBeanFacet entry); 
public void visitMessageDrivenBean(MessageDrivenBeanFacet entry); 
public void visitEjbEntity(SpringBeanFacet entry); 
... 



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: 
* replace a node with a subclass, e.g. 
FileNode => XmlFileNode => MavenPomNode, 
FileNode => JavaFileNode => AnnotationNode 

* add properties, e.g. 
XmlFileNode's "doctype", 
ClassNode's "blacklisted" 
* connect nodes to them, e.g. 
MavenPom ---contains---> MavenDependencyNode 
JavaFile --- imports --> [ ClassNode, ClassNode, ... ] 

This approach would: 
* Leverage of Forge modularity (e.g. Maven addon depending on XmlFile addon) 
* Improve extendability (no need to squeeze everything into the GraphVisitor interface's methods or extend it) 
* Lead to much more straightforward rules implementation - all rules would reduce to: 
* matching graph information (Gremlin?) 
* using DAO's / Services (for mining data from the files/..., and for writing them during active migration) 
1) Bundled - XPath, AST query, properties, Maven remote fetch, ... 
2) User's: .class packed within the addon or a Groovy class 
* writing back to the graph 
* rendering pieces of HTML for the report. 

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. 

As an example, take e.g. MavenRemoteFetchVisitor. https://github.com/windup/windup/blob/master/engine/rules/impl/src/main/java/org/jboss/windup/engine/visitor/inspector/MavenRemoteFetchVisitor.java 

All that is doable using few simple building blocks, directed by few lines of a rule like this: 

------------------------------------------------------------------ 

<var name="pomNS" val= "http://maven.apache.org/POM/4.0.0" > 

Rule 1) which would process all POM files and load the info into the graph. 

<rule id="maven.pomFiles" desc=" Analyze Maven POM files " 
phase="StaticConfigAnalysis"> 
<graph match="XmlFileNode[doctype=' http://maven.apache.org/POM/4.0.0 ']" toVar="xmls"> 
<for var="pom" in="xmls"> 
<graph:replaceSingle ref="pom" with="MavenPomFileNode"> 
<properties> 
<!-- <jaxb> would invoce a call to a Service. 
<properties> hander would take returned object's bean props. 
toClass would load the class from CL or compile from .groovy coming with the migrator (addon). 
--> 
<jaxb toClass="PomJaxb.groovy" fromFile="${pom.path}"> 
<ns name="pom" uri="${pomNS}"/> 
</jaxb> 
</properties> 
</graph> 
</for> 
</rule> 

@XmlRoot 
class PomJaxb { 
@XmlXPath( "/pom:project/pom:modelVersion" ) String modelVersion ; 
@XmlXPath( "/pom:project/pom:name" ) String name ; 
@XmlXPath( "/pom:project/pom:description" String description ; 
@XmlXPath( "/pom:project/pom:url" String url; 
} 


Rule 2) which would load the dependencies and describe them into Nodes and Edges. 

<rule id="maven.pomDependencies" desc=" Analyze Maven POM file dependencies " 
phase="StaticConfigAnalysis"> 
<after rule="maven.pomFiles"> 

<graph match="MavenPomFileNode" toVar="pomVertexes"> 
<for var="pomV" in="pomVertexes"> 

<xpath toVar="deps" fromFile="${pomV.path}" match="/pom:project/pom:dependencies/pom:dependency"/> 
<for var="depElement" in="deps"> 
<jaxb toVar="dep" toClass="MavenDepencencyJaxb.groovy" fromElement="depElement" ns="pom ${pomNS}"/> 
<graph:query toVar="isBlacklisted" 
q=" /* I don't know Gremlin so far, imagine an equiv of this XPath: */ 
MavenDependencyNode[ 
g=${dep.groupId} and a=${dep.artifactId} and v=${dep.version} 
]@blacklisted 
" /> 
<continue if="isBlacklisted /* var, or Groovy (or EL) expression */" /> 
<!-- This would be useful for blacklists and filters in general, which appear often in real life rules. --> 

<graph:insertIfNotExists type="MavenDependencyNode" toVar="depVertex> 
<properties from="dep"/> 
</graph> 
<graph:edge type="dependsOn" from="pomV" to="depVertex"/> 
<!-- Maybe Gremlin could replace this? --> 
</for> 
</for> 
</rule> 

@XmlRoot 
class MavenDepencencyJaxb { 
// GraphKeyProperty identifies those which are compared for insertIfNotExists. 
@GraphKeyProperty @XmlXPath("./pom:groupId") String groupId; 
@GraphKeyProperty @XmlXPath("./pom:artifactId") String artifactId; 
@GraphKeyProperty @XmlXPath("./pom:version") String version; 
} 
------------------------------------------------------------------ 

As you can see, It creates independent rules which only communicate indirectly through the graph. 
You can also see how nicely Java classes fit into this, and how Groovy could make this easier. 

SERVICES INVOCATION 
Forge UI could be mapped to XML elements. I.e. <aaa foo="bar"/> could invoke command "aaa" with given params. 
I believe Forge already has this way of input, right? 

GRAPH OPERATION 
There would be several <graph:...> operations - CRUD plus some special. 

EXECUTION FLOW 
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>. 

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. 

For more complex logic, users would break the task into multiple rules, storing data into the graph intermediately. 

I'll check few more visitors to see if this is powerful enough to satisfy all the baneeds. 


............................. 

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 https://docs.google.com/drawings/d/1IMnds3Qu8Wwcf7_mr7NJ9a3YgtcGJ7dejl09EhWl7Vc for illustration. 

Ondra 





</blockquote>



</blockquote>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140502/8c37fff0/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 12554 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/windup-dev/attachments/20140502/8c37fff0/attachment-0001.jpe 

From ozizka at redhat.com  Fri May  2 19:26:34 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Sat, 03 May 2014 01:26:34 +0200
Subject: [windup-dev] Rules API
Message-ID: <536429AA.20605@redhat.com>

Hi,

WRT rules API, as proposed at
https://github.com/windup/windup/blob/master/engine/config/api/src/main/java/org/jboss/windup/addon/config/example/MavenExampleConfigurationProvider.java#L22

It's nice, with some comments.

I know it was typed in a hurry, but anyway:

1) The  (when, perform) structure would be basic for all rules?

2) This seems like it will build object tree, which will then be 
processed, right? No space for custom code?

3) Isn't that a fluent API overuse? How about something like:

new ConfigBuilder( ... ){{
     addRule( new MavenPomRule( this, ... ){
              boolean when(  ) { return Selection.exists(XMLFile.class, 
"xmls").with("doctype", DOCTYPE_POM); }
              void perform( MavenPomInfo mpi ){ ... }
         }
     );
}}.run();

It's verbose now but with Java 8 lambdas, it would be less.

While it's a bit more verbose, it would have obvious benefits of better 
debuggability, and would better leverage Java's features like 
inheritance (imagine AbstractXmlFileRule and it's subclasses for 
whatever one would want to do with a XML file, having few of its 
properties passed as parameters.

Btw this code above is inspired by Wicket and GWT.

4) .withDoctype("http://maven.apache.org/POM/4.0.0") ?
doctype is a property...  Better .with(PropNames.DOCTYPE, 
"http://maven.apache.org/POM/4.0.0") ?

5) Could the variable be filled outside .when () ? But perhaps just a 
matter of taste.

More later when we have some more examples.

Nice!
Ondra

From jsightle at redhat.com  Sun May  4 19:30:53 2014
From: jsightle at redhat.com (Jess Sightler)
Date: Sun, 4 May 2014 19:30:53 -0400 (EDT)
Subject: [windup-dev] Let's replace the GraphVisitor interface concept
 with something generic
Message-ID: <1394105113.162433.1399246253927.JavaMail.zimbra@zmail09.collab.prod.int.phx2.redhat.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140504/0d59a753/attachment-0001.html 

From lincolnbaxter at gmail.com  Mon May  5 10:23:44 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Mon, 5 May 2014 10:23:44 -0400
Subject: [windup-dev] Rules API
In-Reply-To: <536429AA.20605@redhat.com>
References: <536429AA.20605@redhat.com>
Message-ID: <CAEp_U4EaZmsguzvPu5LDJHs8vgK7e3jGqeDBSNzBpsgTL9Srjg@mail.gmail.com>

1) The  (when, perform) structure would be basic for all rules?

Yes, there are actually a few more structures:

.addRule()
.when() // if
.perform() // then
.otherwise() // else

2) This seems like it will build object tree, which will then be
processed, right? No space for custom code?

You can already do exactly what you just suggested :) Custom code is no
problem, it just accepts an object like any normal Java code - it's just
Java.

3) Isn't that a fluent API overuse? How about something like:

I don't know what you are referring to here as overuse, but yes, I am
exaggerating the use of the fluent API to make a point. The rules could be
completely un-fluent and still use these same APIs. I'm not sure I see the
point/difference of the sample you've shown.

4) .withDoctype("http://maven.apache.org/POM/4.0.0") ?
doctype is a property...  Better .with(PropNames.DOCTYPE,
"http://maven.apache.org/POM/4.0.0") ?

I agree, some kind of more general structure here would probably be better.

5) Could the variable be filled outside .when () ? But perhaps just a
matter of taste.

Absolutely you could - and yes, it's all a matter of taste :)


On Fri, May 2, 2014 at 7:26 PM, Ondrej Zizka <ozizka at redhat.com> wrote:

> Hi,
>
> WRT rules API, as proposed at
>
> https://github.com/windup/windup/blob/master/engine/config/api/src/main/java/org/jboss/windup/addon/config/example/MavenExampleConfigurationProvider.java#L22
>
> It's nice, with some comments.
>
> I know it was typed in a hurry, but anyway:
>
> 1) The  (when, perform) structure would be basic for all rules?
>
> 2) This seems like it will build object tree, which will then be
> processed, right? No space for custom code?
>
> 3) Isn't that a fluent API overuse? How about something like:
>
> new ConfigBuilder( ... ){{
>      addRule( new MavenPomRule( this, ... ){
>               boolean when(  ) { return Selection.exists(XMLFile.class,
> "xmls").with("doctype", DOCTYPE_POM); }
>               void perform( MavenPomInfo mpi ){ ... }
>          }
>      );
> }}.run();
>
> It's verbose now but with Java 8 lambdas, it would be less.
>
> While it's a bit more verbose, it would have obvious benefits of better
> debuggability, and would better leverage Java's features like
> inheritance (imagine AbstractXmlFileRule and it's subclasses for
> whatever one would want to do with a XML file, having few of its
> properties passed as parameters.
>
> Btw this code above is inspired by Wicket and GWT.
>
> 4) .withDoctype("http://maven.apache.org/POM/4.0.0") ?
> doctype is a property...  Better .with(PropNames.DOCTYPE,
> "http://maven.apache.org/POM/4.0.0") ?
>
> 5) Could the variable be filled outside .when () ? But perhaps just a
> matter of taste.
>
> More later when we have some more examples.
>
> Nice!
> Ondra
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140505/6cb1284f/attachment.html 

From lincolnbaxter at gmail.com  Mon May  5 10:33:00 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Mon, 5 May 2014 10:33:00 -0400
Subject: [windup-dev] Rules API
In-Reply-To: <CAEp_U4EaZmsguzvPu5LDJHs8vgK7e3jGqeDBSNzBpsgTL9Srjg@mail.gmail.com>
References: <536429AA.20605@redhat.com>
	<CAEp_U4EaZmsguzvPu5LDJHs8vgK7e3jGqeDBSNzBpsgTL9Srjg@mail.gmail.com>
Message-ID: <CAEp_U4H+JK9PqbPzdBeo9kc6Jsnj1hUJ+AL51AZPE4c4x18sQA@mail.gmail.com>

.addRule()
.when() // if
.perform() // then
.otherwise() // else
.where("paramName1").configuredBy(...).where("paramName2") // configure
parameters


On Mon, May 5, 2014 at 10:23 AM, Lincoln Baxter, III <
lincolnbaxter at gmail.com> wrote:

> 1) The  (when, perform) structure would be basic for all rules?
>
> Yes, there are actually a few more structures:
>
> .addRule()
> .when() // if
> .perform() // then
> .otherwise() // else
>
>
> 2) This seems like it will build object tree, which will then be
> processed, right? No space for custom code?
>
> You can already do exactly what you just suggested :) Custom code is no
> problem, it just accepts an object like any normal Java code - it's just
> Java.
>
>
> 3) Isn't that a fluent API overuse? How about something like:
>
> I don't know what you are referring to here as overuse, but yes, I am
> exaggerating the use of the fluent API to make a point. The rules could be
> completely un-fluent and still use these same APIs. I'm not sure I see the
> point/difference of the sample you've shown.
>
> 4) .withDoctype("http://maven.apache.org/POM/4.0.0") ?
> doctype is a property...  Better .with(PropNames.DOCTYPE,
> "http://maven.apache.org/POM/4.0.0") ?
>
> I agree, some kind of more general structure here would probably be better.
>
>
> 5) Could the variable be filled outside .when () ? But perhaps just a
> matter of taste.
>
> Absolutely you could - and yes, it's all a matter of taste :)
>
>
> On Fri, May 2, 2014 at 7:26 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
>
>> Hi,
>>
>> WRT rules API, as proposed at
>>
>> https://github.com/windup/windup/blob/master/engine/config/api/src/main/java/org/jboss/windup/addon/config/example/MavenExampleConfigurationProvider.java#L22
>>
>> It's nice, with some comments.
>>
>> I know it was typed in a hurry, but anyway:
>>
>> 1) The  (when, perform) structure would be basic for all rules?
>>
>> 2) This seems like it will build object tree, which will then be
>> processed, right? No space for custom code?
>>
>> 3) Isn't that a fluent API overuse? How about something like:
>>
>> new ConfigBuilder( ... ){{
>>      addRule( new MavenPomRule( this, ... ){
>>               boolean when(  ) { return Selection.exists(XMLFile.class,
>> "xmls").with("doctype", DOCTYPE_POM); }
>>               void perform( MavenPomInfo mpi ){ ... }
>>          }
>>      );
>> }}.run();
>>
>> It's verbose now but with Java 8 lambdas, it would be less.
>>
>> While it's a bit more verbose, it would have obvious benefits of better
>> debuggability, and would better leverage Java's features like
>> inheritance (imagine AbstractXmlFileRule and it's subclasses for
>> whatever one would want to do with a XML file, having few of its
>> properties passed as parameters.
>>
>> Btw this code above is inspired by Wicket and GWT.
>>
>> 4) .withDoctype("http://maven.apache.org/POM/4.0.0") ?
>> doctype is a property...  Better .with(PropNames.DOCTYPE,
>> "http://maven.apache.org/POM/4.0.0") ?
>>
>> 5) Could the variable be filled outside .when () ? But perhaps just a
>> matter of taste.
>>
>> More later when we have some more examples.
>>
>> Nice!
>> Ondra
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140505/14df3825/attachment.html 

From lincolnbaxter at gmail.com  Mon May  5 10:34:28 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Mon, 5 May 2014 10:34:28 -0400
Subject: [windup-dev] Let's replace the GraphVisitor interface concept
 with something generic
In-Reply-To: <1394105113.162433.1399246253927.JavaMail.zimbra@zmail09.collab.prod.int.phx2.redhat.com>
References: <1394105113.162433.1399246253927.JavaMail.zimbra@zmail09.collab.prod.int.phx2.redhat.com>
Message-ID: <CAEp_U4HyzwzAj2C6Nbf2SQP3NW_TP0xTeOOnDzX8SX5J3dO7LA@mail.gmail.com>

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.


On Sun, May 4, 2014 at 7:30 PM, Jess Sightler <jsightle at redhat.com> wrote:

>
> On May 2, 2014 5:31 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
> >
> >
> > On 2.5.2014 21:17, Lincoln Baxter wrote:
> >>
> >> Hey Ondra,
> >>
> >> I'm moving this discussion to windup-dev at lists.jboss.org - please use
> windup-dev for all non-confidential development discussion.
> >>
> >> 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:
> >>
> >> #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.
> >
> > That's the purpose. The rules would interfere. Or rather, infer.
> > 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.
>
> I prefer to think of this in terms of RDF-style classes that operate on
> the open world assumption:
> http://en.m.wikipedia.org/wiki/Open_world_assumption
>
> 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. :-)
>
> From my research on Friday, I believe that this OWA type model may
> actually be supported pretty well by Tinkerpop frames.
>
> We can discuss further next week, as I am sure the above is insufficient.
> :-)
>
> >
> > 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.
> >
> >> #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?
> >
> > I didn't find anything related in
> https://github.com/thinkaurelius/titan/wiki/Titan-Limitations (those type
> limitations seem to apply on other things). I'll try practically.
> >>
> >>
> >> #3) You asked: "Forge UI could be mapped to XML elements. I.e.  <aaa
> foo="bar"/> could invoke command "aaa" with given params.
> >> I believe Forge already has this way of input, right?"
> >>
> >> 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.
> >
> > 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.
> >>
> >>
> >> #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.
> >
> > Yes and no.
> >
> > 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,
> > IMO, if we don't create something such, we will end up with rules which
> will be just a thin wrapper around services.
> >
> > 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.
> > 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.
> > In this approach, the second rule would pick up the MavenPomFileNode no
> matter where it comes from.
> > I could have written the example 1:1 but wanted to show this task
> separation advantage.
> >
> >
> >>
> >> 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.
> >
> > Okay, let's see what we have.
> >>
> >>
> >> 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.
> >>
> >> Java first. Then XML (or whatever).
> >
> > Hmm. About 4 months ago, it was exactly opposite: XML rules, no Java.
> > It was also one of the main reasons to abandon WindRide the XML rules
> were implemented.
> > 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".
> > When did this change, and what's the guarantee that it won't change
> again?
> >
> > Ondra
> >
> >>
> >> ~Lincoln
> >>
> >> ________________________________
> >> From: "Ondrej Zizka" <ozizka at redhat.com>
> >> To: jboss-migration at redhat.com
> >> Sent: Thursday, May 1, 2014 12:05:23 AM
> >> Subject: Re: Let's replace the GraphVisitor interface concept with
> something        generic
> >>
> >> I've put it to this doc so we can edit/comment there.
> >>
> >>
> https://docs.google.com/document/d/1UOihPv_zryFilCb7T0k8992wPUt3YNP4goh9rxTC7ng/edit#
> >>
> >> Ondra
> >>
> >>
> >>
> >> On 1.5.2014 04:35, Ondrej Zizka wrote:
> >>>
> >>> Hi,
> >>>
> >>> as we discussed before, I'd like to replace the GraphVisitor interface
> with something generic.
> >>> 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.
> >>>
> >>>     public void visitEjbEntity(EjbEntityFacet entry);
> >>>     public void visitEjbService(EjbSessionBeanFacet entry);
> >>>     public void visitMessageDrivenBean(MessageDrivenBeanFacet entry);
> >>>     public void visitEjbEntity(SpringBeanFacet entry);
> >>>     ...
> >>>
> >>>
> >>>
> >>> 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:
> >>>      *  replace a node with a subclass, e.g.
> >>>               FileNode => XmlFileNode => MavenPomNode,
> >>>               FileNode => JavaFileNode => AnnotationNode
> >>>
> >>>      *  add properties, e.g.
> >>>               XmlFileNode's "doctype",
> >>>               ClassNode's "blacklisted"
> >>>      *  connect nodes to them, e.g.
> >>>               MavenPom ---contains---> MavenDependencyNode
> >>>               JavaFile --- imports --> [ ClassNode, ClassNode, ... ]
> >>>
> >>> This approach would:
> >>>     * Leverage of Forge modularity (e.g. Maven addon depending on
> XmlFile addon)
> >>>     * Improve extendability (no need to squeeze everything into the
> GraphVisitor interface's methods or extend it)
> >>>     * Lead to much more straightforward rules implementation - all
> rules would reduce to:
> >>>          * matching graph information (Gremlin?)
> >>>          * using DAO's / Services (for mining data from the files/...,
> and for writing them during active migration)
> >>>                  1) Bundled - XPath, AST query, properties, Maven
> remote fetch, ...
> >>>                  2) User's:  .class packed within the addon or a
> Groovy class
> >>>          * writing back to the graph
> >>>          * rendering pieces of HTML for the report.
> >>>
> >>> 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.
> >>>
> >>> As an example, take e.g. MavenRemoteFetchVisitor.
> https://github.com/windup/windup/blob/master/engine/rules/impl/src/main/java/org/jboss/windup/engine/visitor/inspector/MavenRemoteFetchVisitor.java
> >>>
> >>> All that is doable using few simple building blocks, directed by few
> lines of a rule like this:
> >>>
> >>> ------------------------------------------------------------------
> >>>
> >>> <var name="pomNS" val="http://maven.apache.org/POM/4.0.0">
> >>>
> >>> Rule 1) which would process all POM files and load the info into the
> graph.
> >>>
> >>> <rule id="maven.pomFiles" desc="   Analyze Maven POM files  "
> >>>           phase="StaticConfigAnalysis">
> >>>     <graph match="XmlFileNode[doctype='
> http://maven.apache.org/POM/4.0.0']" toVar="xmls">
> >>>     <for var="pom" in="xmls">
> >>>           <graph:replaceSingle ref="pom" with="MavenPomFileNode">
> >>>                <properties>
> >>>                     <!-- <jaxb> would invoce a call to a Service.
> >>>                            <properties> hander would take returned
> object's bean props.
> >>>                            toClass would load the class from CL or
> compile from .groovy coming with the migrator (addon).
> >>>                      -->
> >>>                     <jaxb toClass="PomJaxb.groovy"
> fromFile="${pom.path}">
> >>>                            <ns name="pom" uri="${pomNS}"/>
> >>>                     </jaxb>
> >>>                 </properties>
> >>>           </graph>
> >>>       </for>
> >>> </rule>
> >>>
> >>> @XmlRoot
> >>> class PomJaxb {
> >>>        @XmlXPath("/pom:project/pom:modelVersion")        String
> modelVersion;
> >>>        @XmlXPath("/pom:project/pom:name")                     String
> name;
> >>>        @XmlXPath("/pom:project/pom:description"              String
> description;
> >>>        @XmlXPath("/pom:project/pom:url"
> String url;
> >>> }
> >>>
> >>>
> >>> Rule 2) which would load the dependencies and describe them into Nodes
> and Edges.
> >>>
> >>> <rule id="maven.pomDependencies" desc="   Analyze Maven POM file
> dependencies  "
> >>>           phase="StaticConfigAnalysis">
> >>>      <after rule="maven.pomFiles">
> >>>
> >>>      <graph match="MavenPomFileNode" toVar="pomVertexes">
> >>>      <for var="pomV" in="pomVertexes">
> >>>
> >>>           <xpath toVar="deps" fromFile="${pomV.path}"
> match="/pom:project/pom:dependencies/pom:dependency"/>
> >>>           <for var="depElement" in="deps">
> >>>               <jaxb toVar="dep" toClass="MavenDepencencyJaxb.groovy"
> fromElement="depElement" ns="pom ${pomNS}"/>
> >>>               <graph:query toVar="isBlacklisted"
> >>>                    q=" /*  I don't know Gremlin so far, imagine an
> equiv of this XPath: */
> >>>                        MavenDependencyNode[
> >>>                              g=${dep.groupId} and a=${dep.artifactId}
> and v=${dep.version}
> >>>                        ]@blacklisted
> >>>               " />
> >>>               <continue if="isBlacklisted /* var, or Groovy (or EL)
> expression */" />
> >>>               <!-- This would be useful for blacklists and filters in
> general, which appear often in real life rules. -->
> >>>
> >>>               <graph:insertIfNotExists type="MavenDependencyNode"
> toVar="depVertex>
> >>>                    <properties from="dep"/>
> >>>               </graph>
> >>>               <graph:edge type="dependsOn" from="pomV" to="depVertex"/>
> >>>                             <!-- Maybe Gremlin could replace this? -->
> >>>           </for>
> >>>     </for>
> >>> </rule>
> >>>
> >>> @XmlRoot
> >>> class MavenDepencencyJaxb {
> >>>       // GraphKeyProperty identifies those which are compared for
> insertIfNotExists.
> >>>       @GraphKeyProperty  @XmlXPath("./pom:groupId")   String groupId;
> >>>       @GraphKeyProperty  @XmlXPath("./pom:artifactId")   String
> artifactId;
> >>>       @GraphKeyProperty  @XmlXPath("./pom:version")   String version;
> >>> }
> >>> ------------------------------------------------------------------
> >>>
> >>> As you can see, It creates independent rules which only communicate
> indirectly through the graph.
> >>> You can also see how nicely Java classes fit into this, and how Groovy
> could make this easier.
> >>>
> >>> SERVICES INVOCATION
> >>> Forge UI could be mapped to XML elements. I.e.  <aaa foo="bar"/> could
> invoke command "aaa" with given params.
> >>> I believe Forge already has this way of input, right?
> >>>
> >>> GRAPH OPERATION
> >>> There would be several <graph:...> operations - CRUD plus some special.
> >>>
> >>> EXECUTION FLOW
> >>> 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>.
> >>>
> >>> 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.
> >>>
> >>> For more complex logic, users would break the task into multiple
> rules, storing data into the graph intermediately.
> >>>
> >>> I'll check few more visitors to see if this is powerful enough to
> satisfy all the baneeds.
> >>>
> >>>
> >>> .............................
> >>>
> >>> 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
> https://docs.google.com/drawings/d/1IMnds3Qu8Wwcf7_mr7NJ9a3YgtcGJ7dejl09EhWl7Vc
> for illustration.
> >>>
> >>> Ondra
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140505/834182a5/attachment-0001.html 

From bdavis at redhat.com  Mon May  5 10:52:35 2014
From: bdavis at redhat.com (Brad Davis)
Date: Mon, 5 May 2014 10:52:35 -0400 (EDT)
Subject: [windup-dev] Rules API
In-Reply-To: <536429AA.20605@redhat.com>
References: <536429AA.20605@redhat.com>
Message-ID: <544009503.608869.1399301555471.JavaMail.zimbra@redhat.com>

This overlaps a lot with the Pipelines already part of Tinkerpop.  (https://github.com/tinkerpop/pipes) You may be able to implement these as pipes.

Also, be careful not to get so stuck on doing everything in rules that you miss the fact that some things aren't going to be rule driven, or don't make sense in rules.  Otherwise the rules will become overly complex and may not add much value.

I think the casting of XML files, or filtering of XML files by their namespace and doctype are fine for rules, but things like: 
* Parsing an EJB and connecting XML files to Java files: probably not suited well for Rules because it is a 1 time thing and spec specific.  
* Highlighting lines in Java or XML by Regex or XPath: probably well suited for Rules because it is user driven what needs to be highlighted, and may expand over time.

Brad Davis
Red Hat Consulting
Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com 


----- Original Message -----
From: "Ondrej Zizka" <ozizka at redhat.com>
To: windup-dev at lists.jboss.org, "Lincoln Baxter" <lbaxter at redhat.com>
Sent: Friday, May 2, 2014 7:26:34 PM
Subject: [windup-dev] Rules API

Hi,

WRT rules API, as proposed at
https://github.com/windup/windup/blob/master/engine/config/api/src/main/java/org/jboss/windup/addon/config/example/MavenExampleConfigurationProvider.java#L22

It's nice, with some comments.

I know it was typed in a hurry, but anyway:

1) The  (when, perform) structure would be basic for all rules?

2) This seems like it will build object tree, which will then be 
processed, right? No space for custom code?

3) Isn't that a fluent API overuse? How about something like:

new ConfigBuilder( ... ){{
     addRule( new MavenPomRule( this, ... ){
              boolean when(  ) { return Selection.exists(XMLFile.class, 
"xmls").with("doctype", DOCTYPE_POM); }
              void perform( MavenPomInfo mpi ){ ... }
         }
     );
}}.run();

It's verbose now but with Java 8 lambdas, it would be less.

While it's a bit more verbose, it would have obvious benefits of better 
debuggability, and would better leverage Java's features like 
inheritance (imagine AbstractXmlFileRule and it's subclasses for 
whatever one would want to do with a XML file, having few of its 
properties passed as parameters.

Btw this code above is inspired by Wicket and GWT.

4) .withDoctype("http://maven.apache.org/POM/4.0.0") ?
doctype is a property...  Better .with(PropNames.DOCTYPE, 
"http://maven.apache.org/POM/4.0.0") ?

5) Could the variable be filled outside .when () ? But perhaps just a 
matter of taste.

More later when we have some more examples.

Nice!
Ondra
_______________________________________________
windup-dev mailing list
windup-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev

From bdavis at redhat.com  Mon May  5 11:00:15 2014
From: bdavis at redhat.com (Brad Davis)
Date: Mon, 5 May 2014 11:00:15 -0400 (EDT)
Subject: [windup-dev] Let's replace the GraphVisitor interface concept
 with something generic
In-Reply-To: <CAEp_U4HyzwzAj2C6Nbf2SQP3NW_TP0xTeOOnDzX8SX5J3dO7LA@mail.gmail.com>
References: <1394105113.162433.1399246253927.JavaMail.zimbra@zmail09.collab.prod.int.phx2.redhat.com>
	<CAEp_U4HyzwzAj2C6Nbf2SQP3NW_TP0xTeOOnDzX8SX5J3dO7LA@mail.gmail.com>
Message-ID: <181119329.615524.1399302015745.JavaMail.zimbra@redhat.com>

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. 

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.

Brad Davis
Red Hat Consulting
Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com 


----- Original Message -----
From: "Lincoln Baxter, III" <lincolnbaxter at gmail.com>
To: "Windup-dev List" <windup-dev at lists.jboss.org>
Sent: Monday, May 5, 2014 10:34:28 AM
Subject: Re: [windup-dev] Let's replace the GraphVisitor interface concept with something generic

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. 


On Sun, May 4, 2014 at 7:30 PM, Jess Sightler < jsightle at redhat.com > wrote: 






On May 2, 2014 5:31 PM, Ondrej Zizka < ozizka at redhat.com > wrote: 
> 
> 
> On 2.5.2014 21:17, Lincoln Baxter wrote: 
>> 
>> Hey Ondra, 
>> 
>> I'm moving this discussion to windup-dev at lists.jboss.org - please use windup-dev for all non-confidential development discussion. 
>> 
>> 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: 
>> 
>> #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. 
> 
> That's the purpose. The rules would interfere. Or rather, infer. 
> 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. 



I prefer to think of this in terms of RDF-style classes that operate on the open world assumption: http://en.m.wikipedia.org/wiki/Open_world_assumption 

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. :-) 

>From my research on Friday, I believe that this OWA type model may actually be supported pretty well by Tinkerpop frames. 

We can discuss further next week, as I am sure the above is insufficient. :-) 




> 
> 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. 
> 
>> #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? 
> 
> I didn't find anything related in https://github.com/thinkaurelius/titan/wiki/Titan-Limitations (those type limitations seem to apply on other things). I'll try practically. 
>> 
>> 
>> #3) You asked: "Forge UI could be mapped to XML elements. I.e. <aaa foo="bar"/> could invoke command "aaa" with given params. 
>> I believe Forge already has this way of input, right?" 
>> 
>> 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. 
> 
> 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. 
>> 
>> 
>> #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. 
> 
> Yes and no. 
> 
> 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, 
> IMO, if we don't create something such, we will end up with rules which will be just a thin wrapper around services. 
> 
> 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. 
> 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. 
> In this approach, the second rule would pick up the MavenPomFileNode no matter where it comes from. 
> I could have written the example 1:1 but wanted to show this task separation advantage. 
> 
> 
>> 
>> 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. 
> 
> Okay, let's see what we have. 
>> 
>> 
>> 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. 
>> 
>> Java first. Then XML (or whatever). 
> 
> Hmm. About 4 months ago, it was exactly opposite: XML rules, no Java. 
> It was also one of the main reasons to abandon WindRide the XML rules were implemented. 
> 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". 
> When did this change, and what's the guarantee that it won't change again? 
> 
> Ondra 
> 
>> 
>> ~Lincoln 
>> 
>> ________________________________ 
>> From: "Ondrej Zizka" < ozizka at redhat.com > 
>> To: jboss-migration at redhat.com 
>> Sent: Thursday, May 1, 2014 12:05:23 AM 
>> Subject: Re: Let's replace the GraphVisitor interface concept with something generic 
>> 
>> I've put it to this doc so we can edit/comment there. 
>> 
>> https://docs.google.com/document/d/1UOihPv_zryFilCb7T0k8992wPUt3YNP4goh9rxTC7ng/edit# 
>> 
>> Ondra 
>> 
>> 
>> 
>> On 1.5.2014 04:35, Ondrej Zizka wrote: 
>>> 
>>> Hi, 
>>> 
>>> as we discussed before, I'd like to replace the GraphVisitor interface with something generic. 
>>> 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. 
>>> 
>>> public void visitEjbEntity(EjbEntityFacet entry); 
>>> public void visitEjbService(EjbSessionBeanFacet entry); 
>>> public void visitMessageDrivenBean(MessageDrivenBeanFacet entry); 
>>> public void visitEjbEntity(SpringBeanFacet entry); 
>>> ... 
>>> 
>>> 
>>> 
>>> 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: 
>>> * replace a node with a subclass, e.g. 
>>> FileNode => XmlFileNode => MavenPomNode, 
>>> FileNode => JavaFileNode => AnnotationNode 
>>> 
>>> * add properties, e.g. 
>>> XmlFileNode's "doctype", 
>>> ClassNode's "blacklisted" 
>>> * connect nodes to them, e.g. 
>>> MavenPom ---contains---> MavenDependencyNode 
>>> JavaFile --- imports --> [ ClassNode, ClassNode, ... ] 
>>> 
>>> This approach would: 
>>> * Leverage of Forge modularity (e.g. Maven addon depending on XmlFile addon) 
>>> * Improve extendability (no need to squeeze everything into the GraphVisitor interface's methods or extend it) 
>>> * Lead to much more straightforward rules implementation - all rules would reduce to: 
>>> * matching graph information (Gremlin?) 
>>> * using DAO's / Services (for mining data from the files/..., and for writing them during active migration) 
>>> 1) Bundled - XPath, AST query, properties, Maven remote fetch, ... 
>>> 2) User's: .class packed within the addon or a Groovy class 
>>> * writing back to the graph 
>>> * rendering pieces of HTML for the report. 
>>> 
>>> 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. 
>>> 
>>> As an example, take e.g. MavenRemoteFetchVisitor. https://github.com/windup/windup/blob/master/engine/rules/impl/src/main/java/org/jboss/windup/engine/visitor/inspector/MavenRemoteFetchVisitor.java 
>>> 
>>> All that is doable using few simple building blocks, directed by few lines of a rule like this: 
>>> 
>>> ------------------------------------------------------------------ 
>>> 
>>> <var name="pomNS" val=" http://maven.apache.org/POM/4.0.0 "> 
>>> 
>>> Rule 1) which would process all POM files and load the info into the graph. 
>>> 
>>> <rule id="maven.pomFiles" desc=" Analyze Maven POM files " 
>>> phase="StaticConfigAnalysis"> 
>>> <graph match="XmlFileNode[doctype=' http://maven.apache.org/POM/4.0.0' ]" toVar="xmls"> 
>>> <for var="pom" in="xmls"> 
>>> <graph:replaceSingle ref="pom" with="MavenPomFileNode"> 
>>> <properties> 
>>> <!-- <jaxb> would invoce a call to a Service. 
>>> <properties> hander would take returned object's bean props. 
>>> toClass would load the class from CL or compile from .groovy coming with the migrator (addon). 
>>> --> 
>>> <jaxb toClass="PomJaxb.groovy" fromFile="${pom.path}"> 
>>> <ns name="pom" uri="${pomNS}"/> 
>>> </jaxb> 
>>> </properties> 
>>> </graph> 
>>> </for> 
>>> </rule> 
>>> 
>>> @XmlRoot 
>>> class PomJaxb { 
>>> @XmlXPath("/pom:project/pom:modelVersion") String modelVersion; 
>>> @XmlXPath("/pom:project/pom:name") String name; 
>>> @XmlXPath("/pom:project/pom:description" String description; 
>>> @XmlXPath("/pom:project/pom:url" String url; 
>>> } 
>>> 
>>> 
>>> Rule 2) which would load the dependencies and describe them into Nodes and Edges. 
>>> 
>>> <rule id="maven.pomDependencies" desc=" Analyze Maven POM file dependencies " 
>>> phase="StaticConfigAnalysis"> 
>>> <after rule="maven.pomFiles"> 
>>> 
>>> <graph match="MavenPomFileNode" toVar="pomVertexes"> 
>>> <for var="pomV" in="pomVertexes"> 
>>> 
>>> <xpath toVar="deps" fromFile="${pomV.path}" match="/pom:project/pom:dependencies/pom:dependency"/> 
>>> <for var="depElement" in="deps"> 
>>> <jaxb toVar="dep" toClass="MavenDepencencyJaxb.groovy" fromElement="depElement" ns="pom ${pomNS}"/> 
>>> <graph:query toVar="isBlacklisted" 
>>> q=" /* I don't know Gremlin so far, imagine an equiv of this XPath: */ 
>>> MavenDependencyNode[ 
>>> g=${dep.groupId} and a=${dep.artifactId} and v=${dep.version} 
>>> ]@blacklisted 
>>> " /> 
>>> <continue if="isBlacklisted /* var, or Groovy (or EL) expression */" /> 
>>> <!-- This would be useful for blacklists and filters in general, which appear often in real life rules. --> 
>>> 
>>> <graph:insertIfNotExists type="MavenDependencyNode" toVar="depVertex> 
>>> <properties from="dep"/> 
>>> </graph> 
>>> <graph:edge type="dependsOn" from="pomV" to="depVertex"/> 
>>> <!-- Maybe Gremlin could replace this? --> 
>>> </for> 
>>> </for> 
>>> </rule> 
>>> 
>>> @XmlRoot 
>>> class MavenDepencencyJaxb { 
>>> // GraphKeyProperty identifies those which are compared for insertIfNotExists. 
>>> @GraphKeyProperty @XmlXPath("./pom:groupId") String groupId; 
>>> @GraphKeyProperty @XmlXPath("./pom:artifactId") String artifactId; 
>>> @GraphKeyProperty @XmlXPath("./pom:version") String version; 
>>> } 
>>> ------------------------------------------------------------------ 
>>> 
>>> As you can see, It creates independent rules which only communicate indirectly through the graph. 
>>> You can also see how nicely Java classes fit into this, and how Groovy could make this easier. 
>>> 
>>> SERVICES INVOCATION 
>>> Forge UI could be mapped to XML elements. I.e. <aaa foo="bar"/> could invoke command "aaa" with given params. 
>>> I believe Forge already has this way of input, right? 
>>> 
>>> GRAPH OPERATION 
>>> There would be several <graph:...> operations - CRUD plus some special. 
>>> 
>>> EXECUTION FLOW 
>>> 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>. 
>>> 
>>> 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. 
>>> 
>>> For more complex logic, users would break the task into multiple rules, storing data into the graph intermediately. 
>>> 
>>> I'll check few more visitors to see if this is powerful enough to satisfy all the baneeds. 
>>> 
>>> 
>>> ............................. 
>>> 
>>> 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 https://docs.google.com/drawings/d/1IMnds3Qu8Wwcf7_mr7NJ9a3YgtcGJ7dejl09EhWl7Vc for illustration. 
>>> 
>>> Ondra 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
> 



_______________________________________________ 
windup-dev mailing list 
windup-dev at lists.jboss.org 
https://lists.jboss.org/mailman/listinfo/windup-dev 



-- 
Lincoln Baxter, III 
http://ocpsoft.org 
"Simpler is better." 

_______________________________________________
windup-dev mailing list
windup-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev

From jsightle at redhat.com  Mon May  5 11:05:32 2014
From: jsightle at redhat.com (Jess Sightler)
Date: Mon, 05 May 2014 11:05:32 -0400
Subject: [windup-dev] Rules API
In-Reply-To: <CAEp_U4H+JK9PqbPzdBeo9kc6Jsnj1hUJ+AL51AZPE4c4x18sQA@mail.gmail.com>
References: <536429AA.20605@redhat.com>	<CAEp_U4EaZmsguzvPu5LDJHs8vgK7e3jGqeDBSNzBpsgTL9Srjg@mail.gmail.com>
	<CAEp_U4H+JK9PqbPzdBeo9kc6Jsnj1hUJ+AL51AZPE4c4x18sQA@mail.gmail.com>
Message-ID: <5367A8BC.8040104@redhat.com>

Could you explain the "where" clause in more detail here? I have seen 
this a few times in your examples, but I'm not entirely clear on what it 
is doing. :)


On 05/05/2014 10:33 AM, Lincoln Baxter, III wrote:
> .addRule()
> .when() // if
> .perform() // then
> .otherwise() // else
> .where("paramName1").configuredBy(...).where("paramName2") // 
> configure parameters
>
>
> On Mon, May 5, 2014 at 10:23 AM, Lincoln Baxter, III 
> <lincolnbaxter at gmail.com <mailto:lincolnbaxter at gmail.com>> wrote:
>
>     1) The  (when, perform) structure would be basic for all rules?
>
>     Yes, there are actually a few more structures:
>
>     .addRule()
>     .when() // if
>     .perform() // then
>     .otherwise() // else
>
>
>     2) This seems like it will build object tree, which will then be
>     processed, right? No space for custom code?
>
>     You can already do exactly what you just suggested :) Custom code
>     is no problem, it just accepts an object like any normal Java code
>     - it's just Java.
>
>
>     3) Isn't that a fluent API overuse? How about something like:
>
>     I don't know what you are referring to here as overuse, but yes, I
>     am exaggerating the use of the fluent API to make a point. The
>     rules could be completely un-fluent and still use these same APIs.
>     I'm not sure I see the point/difference of the sample you've shown.
>
>     4) .withDoctype("http://maven.apache.org/POM/4.0.0") ?
>     doctype is a property...  Better .with(PropNames.DOCTYPE,
>     "http://maven.apache.org/POM/4.0.0") ?
>
>     I agree, some kind of more general structure here would probably
>     be better.
>
>
>     5) Could the variable be filled outside .when () ? But perhaps just a
>     matter of taste.
>
>     Absolutely you could - and yes, it's all a matter of taste :)
>
>
>     On Fri, May 2, 2014 at 7:26 PM, Ondrej Zizka <ozizka at redhat.com
>     <mailto:ozizka at redhat.com>> wrote:
>
>         Hi,
>
>         WRT rules API, as proposed at
>         https://github.com/windup/windup/blob/master/engine/config/api/src/main/java/org/jboss/windup/addon/config/example/MavenExampleConfigurationProvider.java#L22
>
>         It's nice, with some comments.
>
>         I know it was typed in a hurry, but anyway:
>
>         1) The  (when, perform) structure would be basic for all rules?
>
>         2) This seems like it will build object tree, which will then be
>         processed, right? No space for custom code?
>
>         3) Isn't that a fluent API overuse? How about something like:
>
>         new ConfigBuilder( ... ){{
>              addRule( new MavenPomRule( this, ... ){
>                       boolean when(  ) { return
>         Selection.exists(XMLFile.class,
>         "xmls").with("doctype", DOCTYPE_POM); }
>                       void perform( MavenPomInfo mpi ){ ... }
>                  }
>              );
>         }}.run();
>
>         It's verbose now but with Java 8 lambdas, it would be less.
>
>         While it's a bit more verbose, it would have obvious benefits
>         of better
>         debuggability, and would better leverage Java's features like
>         inheritance (imagine AbstractXmlFileRule and it's subclasses for
>         whatever one would want to do with a XML file, having few of its
>         properties passed as parameters.
>
>         Btw this code above is inspired by Wicket and GWT.
>
>         4) .withDoctype("http://maven.apache.org/POM/4.0.0") ?
>         doctype is a property...  Better .with(PropNames.DOCTYPE,
>         "http://maven.apache.org/POM/4.0.0") ?
>
>         5) Could the variable be filled outside .when () ? But perhaps
>         just a
>         matter of taste.
>
>         More later when we have some more examples.
>
>         Nice!
>         Ondra
>         _______________________________________________
>         windup-dev mailing list
>         windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
>
>     -- 
>     Lincoln Baxter, III
>     http://ocpsoft.org
>     "Simpler is better."
>
>
>
>
> -- 
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev

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

From lincolnbaxter at gmail.com  Mon May  5 11:27:18 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Mon, 5 May 2014 11:27:18 -0400
Subject: [windup-dev] Rules API
In-Reply-To: <5367A8BC.8040104@redhat.com>
References: <536429AA.20605@redhat.com>
	<CAEp_U4EaZmsguzvPu5LDJHs8vgK7e3jGqeDBSNzBpsgTL9Srjg@mail.gmail.com>
	<CAEp_U4H+JK9PqbPzdBeo9kc6Jsnj1hUJ+AL51AZPE4c4x18sQA@mail.gmail.com>
	<5367A8BC.8040104@redhat.com>
Message-ID: <CAEp_U4Gf3TmT4iw6RxTaYUZLCH-rm1SWD=84vz6gF5yzxxLVZw@mail.gmail.com>

Sure, take this example:

                    .addRule()
>                     .when(Selection.exists(XMLFile.class, "xmls")
>                                 .with(Element.DOCTYPE, "
> http://maven.apache.org/POM/4.0.0")
>                     )
>                     .perform(Iteration.over(XMLFile.class, "xmls", "pom"
> ).as(MavenPomFile.class)
>                                 .perform(
>
> Graph.replace(Selection.current(XMLFile.class))
>
> .with(Selection.current(MavenPomFile.class))
>                                 )
>                     )


Now consider what would happen if we were to parameterize the DOCTYPE
statement:


                    .addRule()
>                     .when(Selection.exists(XMLFile.class, "xmls")
>                                 .with(Element.DOCTYPE, "http://
> {domain}/POM/4.0.0")
>                     )


What if we want to match some domains and not others? Well, we'll need to
configure the parameter:

>                     .addRule()
>                     .when(Selection.exists(XMLFile.class, "xmls")
>                                 .with(Element.DOCTYPE, "http://
> {domain}/POM/4.0.0")
>                     )
>                     .where("domain").matches("(maven.apache.org|
> jboss.org/maven|example\\.(com|org|net))").convertedBy(new
> URLDomainConverter()).bindsTo(new GraphBinding("xml>domain"))


This would both ensure that the parameter matches only what was contained
in the regular expression, but also adds a converter which stores the value
in the graph (somehow) as a URLDomain (which just for example's sake is a
@VertexFrame annotated interface.) Keep in mind that this is just a
hypothetical example.

The full battery of parameter configuration options are:

> .where(String param)
> .matches(String regex)
> .constrainedBy(Constraint constraint)
> .convertedBy(Converter converter)
> .validatedBy(Validator validator)
> .bindsTo(Binding binding)
> .configuredBy(ParameterConfigurator configurator) // can do any of the
> above


~Lincoln




On Mon, May 5, 2014 at 11:05 AM, Jess Sightler <jsightle at redhat.com> wrote:

>  Could you explain the "where" clause in more detail here? I have seen
> this a few times in your examples, but I'm not entirely clear on what it is
> doing. :)
>
>
>
> On 05/05/2014 10:33 AM, Lincoln Baxter, III wrote:
>
>  .addRule()
> .when() // if
>  .perform() // then
> .otherwise() // else
> .where("paramName1").configuredBy(...).where("paramName2") // configure
> parameters
>
>
> On Mon, May 5, 2014 at 10:23 AM, Lincoln Baxter, III <
> lincolnbaxter at gmail.com> wrote:
>
>>  1) The  (when, perform) structure would be basic for all rules?
>>
>>  Yes, there are actually a few more structures:
>>
>>  .addRule()
>> .when() // if
>> .perform() // then
>> .otherwise() // else
>>
>>
>> 2) This seems like it will build object tree, which will then be
>> processed, right? No space for custom code?
>>
>>  You can already do exactly what you just suggested :) Custom code is no
>> problem, it just accepts an object like any normal Java code - it's just
>> Java.
>>
>>
>> 3) Isn't that a fluent API overuse? How about something like:
>>
>>  I don't know what you are referring to here as overuse, but yes, I am
>> exaggerating the use of the fluent API to make a point. The rules could be
>> completely un-fluent and still use these same APIs. I'm not sure I see the
>> point/difference of the sample you've shown.
>>
>>  4) .withDoctype("http://maven.apache.org/POM/4.0.0") ?
>> doctype is a property...  Better .with(PropNames.DOCTYPE,
>> "http://maven.apache.org/POM/4.0.0") ?
>>
>>  I agree, some kind of more general structure here would probably be
>> better.
>>
>>
>> 5) Could the variable be filled outside .when () ? But perhaps just a
>> matter of taste.
>>
>>  Absolutely you could - and yes, it's all a matter of taste :)
>>
>>
>>  On Fri, May 2, 2014 at 7:26 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> WRT rules API, as proposed at
>>>
>>> https://github.com/windup/windup/blob/master/engine/config/api/src/main/java/org/jboss/windup/addon/config/example/MavenExampleConfigurationProvider.java#L22
>>>
>>> It's nice, with some comments.
>>>
>>> I know it was typed in a hurry, but anyway:
>>>
>>> 1) The  (when, perform) structure would be basic for all rules?
>>>
>>> 2) This seems like it will build object tree, which will then be
>>> processed, right? No space for custom code?
>>>
>>> 3) Isn't that a fluent API overuse? How about something like:
>>>
>>> new ConfigBuilder( ... ){{
>>>      addRule( new MavenPomRule( this, ... ){
>>>               boolean when(  ) { return Selection.exists(XMLFile.class,
>>> "xmls").with("doctype", DOCTYPE_POM); }
>>>               void perform( MavenPomInfo mpi ){ ... }
>>>          }
>>>      );
>>> }}.run();
>>>
>>> It's verbose now but with Java 8 lambdas, it would be less.
>>>
>>> While it's a bit more verbose, it would have obvious benefits of better
>>> debuggability, and would better leverage Java's features like
>>> inheritance (imagine AbstractXmlFileRule and it's subclasses for
>>> whatever one would want to do with a XML file, having few of its
>>> properties passed as parameters.
>>>
>>> Btw this code above is inspired by Wicket and GWT.
>>>
>>> 4) .withDoctype("http://maven.apache.org/POM/4.0.0") ?
>>> doctype is a property...  Better .with(PropNames.DOCTYPE,
>>> "http://maven.apache.org/POM/4.0.0") ?
>>>
>>> 5) Could the variable be filled outside .when () ? But perhaps just a
>>> matter of taste.
>>>
>>> More later when we have some more examples.
>>>
>>> Nice!
>>> Ondra
>>> _______________________________________________
>>> windup-dev mailing list
>>> windup-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>>
>>
>>
>>
>>   --
>> Lincoln Baxter, III
>> http://ocpsoft.org
>> "Simpler is better."
>>
>
>
>
>  --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
>
> _______________________________________________
> windup-dev mailing listwindup-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140505/c5008525/attachment-0001.html 

From lincolnbaxter at gmail.com  Mon May  5 11:28:26 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Mon, 5 May 2014 11:28:26 -0400
Subject: [windup-dev] Rules API
In-Reply-To: <CAEp_U4Gf3TmT4iw6RxTaYUZLCH-rm1SWD=84vz6gF5yzxxLVZw@mail.gmail.com>
References: <536429AA.20605@redhat.com>
	<CAEp_U4EaZmsguzvPu5LDJHs8vgK7e3jGqeDBSNzBpsgTL9Srjg@mail.gmail.com>
	<CAEp_U4H+JK9PqbPzdBeo9kc6Jsnj1hUJ+AL51AZPE4c4x18sQA@mail.gmail.com>
	<5367A8BC.8040104@redhat.com>
	<CAEp_U4Gf3TmT4iw6RxTaYUZLCH-rm1SWD=84vz6gF5yzxxLVZw@mail.gmail.com>
Message-ID: <CAEp_U4EFr4cT=DBB5oN-BPmEMJYsc7LbWrXj+ZOVvf70jetrEg@mail.gmail.com>

Sorry, in my above example I said the converter is responsible for storing
the value, which is not the case. The GraphBinding would be responsible for
that.


On Mon, May 5, 2014 at 11:27 AM, Lincoln Baxter, III <
lincolnbaxter at gmail.com> wrote:

> Sure, take this example:
>
>                     .addRule()
>>                     .when(Selection.exists(XMLFile.class, "xmls")
>>                                 .with(Element.DOCTYPE, "
>> http://maven.apache.org/POM/4.0.0")
>>                     )
>>                     .perform(Iteration.over(XMLFile.class, "xmls", "pom"
>> ).as(MavenPomFile.class)
>>                                 .perform(
>>
>> Graph.replace(Selection.current(XMLFile.class))
>>
>> .with(Selection.current(MavenPomFile.class))
>>                                 )
>>                     )
>
>
> Now consider what would happen if we were to parameterize the DOCTYPE
> statement:
>
>
>                     .addRule()
>>                     .when(Selection.exists(XMLFile.class, "xmls")
>>                                 .with(Element.DOCTYPE, "http://
>> {domain}/POM/4.0.0")
>>                     )
>
>
> What if we want to match some domains and not others? Well, we'll need to
> configure the parameter:
>
>>                     .addRule()
>>                     .when(Selection.exists(XMLFile.class, "xmls")
>>                                 .with(Element.DOCTYPE, "http://
>> {domain}/POM/4.0.0")
>>                     )
>>                     .where("domain").matches("(maven.apache.org|
>> jboss.org/maven|example\\.(com|org|net)<http://jboss.org/maven%7Cexample%5C%5C.(com%7Corg%7Cnet)>)").convertedBy(new
>> URLDomainConverter()).bindsTo(new GraphBinding("xml>domain"))
>
>
> This would both ensure that the parameter matches only what was contained
> in the regular expression, but also adds a converter which stores the value
> in the graph (somehow) as a URLDomain (which just for example's sake is a
> @VertexFrame annotated interface.) Keep in mind that this is just a
> hypothetical example.
>
> The full battery of parameter configuration options are:
>
>> .where(String param)
>> .matches(String regex)
>> .constrainedBy(Constraint constraint)
>> .convertedBy(Converter converter)
>> .validatedBy(Validator validator)
>> .bindsTo(Binding binding)
>> .configuredBy(ParameterConfigurator configurator) // can do any of the
>> above
>
>
> ~Lincoln
>
>
>
>
> On Mon, May 5, 2014 at 11:05 AM, Jess Sightler <jsightle at redhat.com>wrote:
>
>>  Could you explain the "where" clause in more detail here? I have seen
>> this a few times in your examples, but I'm not entirely clear on what it is
>> doing. :)
>>
>>
>>
>> On 05/05/2014 10:33 AM, Lincoln Baxter, III wrote:
>>
>>  .addRule()
>> .when() // if
>>  .perform() // then
>> .otherwise() // else
>> .where("paramName1").configuredBy(...).where("paramName2") // configure
>> parameters
>>
>>
>> On Mon, May 5, 2014 at 10:23 AM, Lincoln Baxter, III <
>> lincolnbaxter at gmail.com> wrote:
>>
>>>  1) The  (when, perform) structure would be basic for all rules?
>>>
>>>  Yes, there are actually a few more structures:
>>>
>>>  .addRule()
>>> .when() // if
>>> .perform() // then
>>> .otherwise() // else
>>>
>>>
>>> 2) This seems like it will build object tree, which will then be
>>> processed, right? No space for custom code?
>>>
>>>  You can already do exactly what you just suggested :) Custom code is no
>>> problem, it just accepts an object like any normal Java code - it's just
>>> Java.
>>>
>>>
>>> 3) Isn't that a fluent API overuse? How about something like:
>>>
>>>  I don't know what you are referring to here as overuse, but yes, I am
>>> exaggerating the use of the fluent API to make a point. The rules could be
>>> completely un-fluent and still use these same APIs. I'm not sure I see the
>>> point/difference of the sample you've shown.
>>>
>>>  4) .withDoctype("http://maven.apache.org/POM/4.0.0") ?
>>> doctype is a property...  Better .with(PropNames.DOCTYPE,
>>> "http://maven.apache.org/POM/4.0.0") ?
>>>
>>>  I agree, some kind of more general structure here would probably be
>>> better.
>>>
>>>
>>> 5) Could the variable be filled outside .when () ? But perhaps just a
>>> matter of taste.
>>>
>>>  Absolutely you could - and yes, it's all a matter of taste :)
>>>
>>>
>>>  On Fri, May 2, 2014 at 7:26 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> WRT rules API, as proposed at
>>>>
>>>> https://github.com/windup/windup/blob/master/engine/config/api/src/main/java/org/jboss/windup/addon/config/example/MavenExampleConfigurationProvider.java#L22
>>>>
>>>> It's nice, with some comments.
>>>>
>>>> I know it was typed in a hurry, but anyway:
>>>>
>>>> 1) The  (when, perform) structure would be basic for all rules?
>>>>
>>>> 2) This seems like it will build object tree, which will then be
>>>> processed, right? No space for custom code?
>>>>
>>>> 3) Isn't that a fluent API overuse? How about something like:
>>>>
>>>> new ConfigBuilder( ... ){{
>>>>      addRule( new MavenPomRule( this, ... ){
>>>>               boolean when(  ) { return Selection.exists(XMLFile.class,
>>>> "xmls").with("doctype", DOCTYPE_POM); }
>>>>               void perform( MavenPomInfo mpi ){ ... }
>>>>          }
>>>>      );
>>>> }}.run();
>>>>
>>>> It's verbose now but with Java 8 lambdas, it would be less.
>>>>
>>>> While it's a bit more verbose, it would have obvious benefits of better
>>>> debuggability, and would better leverage Java's features like
>>>> inheritance (imagine AbstractXmlFileRule and it's subclasses for
>>>> whatever one would want to do with a XML file, having few of its
>>>> properties passed as parameters.
>>>>
>>>> Btw this code above is inspired by Wicket and GWT.
>>>>
>>>> 4) .withDoctype("http://maven.apache.org/POM/4.0.0") ?
>>>> doctype is a property...  Better .with(PropNames.DOCTYPE,
>>>> "http://maven.apache.org/POM/4.0.0") ?
>>>>
>>>> 5) Could the variable be filled outside .when () ? But perhaps just a
>>>> matter of taste.
>>>>
>>>> More later when we have some more examples.
>>>>
>>>> Nice!
>>>> Ondra
>>>> _______________________________________________
>>>> windup-dev mailing list
>>>> windup-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>>>
>>>
>>>
>>>
>>>   --
>>> Lincoln Baxter, III
>>> http://ocpsoft.org
>>> "Simpler is better."
>>>
>>
>>
>>
>>  --
>> Lincoln Baxter, III
>> http://ocpsoft.org
>> "Simpler is better."
>>
>>
>> _______________________________________________
>> windup-dev mailing listwindup-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/windup-dev
>>
>>
>>
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140505/0434854b/attachment-0001.html 

From robb.greathouse at redhat.com  Mon May  5 11:51:48 2014
From: robb.greathouse at redhat.com (Robb Greathouse)
Date: Mon, 5 May 2014 11:51:48 -0400 (EDT)
Subject: [windup-dev] Testing
Message-ID: <2035446983.727660.1399305108118.JavaMail.zimbra@redhat.com>




Robb Greathouse 
Chief Evangelist 
Middleware Business Unit 
JBoss, a Division of Red Hat 
cellphone 505-507-4906 

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

From robb.greathouse at redhat.com  Mon May  5 12:03:20 2014
From: robb.greathouse at redhat.com (Robb Greathouse)
Date: Mon, 5 May 2014 12:03:20 -0400 (EDT)
Subject: [windup-dev] Looking for Rules Contributors
In-Reply-To: <2112651330.735617.1399305779405.JavaMail.zimbra@redhat.com>
Message-ID: <1713000854.735732.1399305800580.JavaMail.zimbra@redhat.com>

Hi, 

We are looking for people who can contribute Rules or contribute use cases for rules that are needed. Anyone interested in learning to develop rules should reply to this list. 


Robb Greathouse 
Chief Evangelist 
Middleware Business Unit 
JBoss, a Division of Red Hat 
cellphone 505-507-4906 

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

From jsightle at redhat.com  Mon May  5 11:30:06 2014
From: jsightle at redhat.com (Jess Sightler)
Date: Mon, 05 May 2014 11:30:06 -0400
Subject: [windup-dev] Let's replace the GraphVisitor interface concept
 with something generic
In-Reply-To: <181119329.615524.1399302015745.JavaMail.zimbra@redhat.com>
References: <1394105113.162433.1399246253927.JavaMail.zimbra@zmail09.collab.prod.int.phx2.redhat.com>	<CAEp_U4HyzwzAj2C6Nbf2SQP3NW_TP0xTeOOnDzX8SX5J3dO7LA@mail.gmail.com>
	<181119329.615524.1399302015745.JavaMail.zimbra@redhat.com>
Message-ID: <5367AE7E.1000505@redhat.com>

I think you are not reading this correctly. That's ok, though, as I 
probably didn't describe it correctly. :) I am talking about supporting 
types, but supporting them using a model more similar to OWL/RDF than to 
classical OO-devleopment. In this model, you do not know all of the 
typing information up front, and instead infer type information as you go.

So, for example, a Vertex may evolve over time to support additional 
types as more information is learned. For example, the first rule may 
provide a "File", but it later may become "File and ZipFile", and then 
ultimately "File and ZipFile and EarFile".

During each step of this evolution it retains all of it's 
characteristics of the previous step. You can think of it as subclassing 
if you want, but eventually the Java model of subclassing will mislead 
you about what this means, as it is not necessary for new types to be 
subclasses of existing types.

Frames encompasses this concept, and this is the big reason that it uses 
Interfaces instead of classes, AFAICT.

This document may be helpful as well:
http://www.w3.org/TR/sw-oosd-primer/#comparison


On 05/05/2014 11:00 AM, Brad Davis wrote:
> 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.
>
> 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.
>
> Brad Davis
> Red Hat Consulting
> Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
>
>
> ----- Original Message -----
> From: "Lincoln Baxter, III" <lincolnbaxter at gmail.com>
> To: "Windup-dev List" <windup-dev at lists.jboss.org>
> Sent: Monday, May 5, 2014 10:34:28 AM
> Subject: Re: [windup-dev] Let's replace the GraphVisitor interface concept with something generic
>
> 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.
>
>
> On Sun, May 4, 2014 at 7:30 PM, Jess Sightler < jsightle at redhat.com > wrote:
>
>
>
>
>
>
> On May 2, 2014 5:31 PM, Ondrej Zizka < ozizka at redhat.com > wrote:
>>
>> On 2.5.2014 21:17, Lincoln Baxter wrote:
>>> Hey Ondra,
>>>
>>> I'm moving this discussion to windup-dev at lists.jboss.org - please use windup-dev for all non-confidential development discussion.
>>>
>>> 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:
>>>
>>> #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.
>> That's the purpose. The rules would interfere. Or rather, infer.
>> 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.
>
>
> I prefer to think of this in terms of RDF-style classes that operate on the open world assumption: http://en.m.wikipedia.org/wiki/Open_world_assumption
>
> 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. :-)
>
> >From my research on Friday, I believe that this OWA type model may actually be supported pretty well by Tinkerpop frames.
>
> We can discuss further next week, as I am sure the above is insufficient. :-)
>
>
>
>
>> 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.
>>
>>> #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?
>> I didn't find anything related in https://github.com/thinkaurelius/titan/wiki/Titan-Limitations (those type limitations seem to apply on other things). I'll try practically.
>>>
>>> #3) You asked: "Forge UI could be mapped to XML elements. I.e. <aaa foo="bar"/> could invoke command "aaa" with given params.
>>> I believe Forge already has this way of input, right?"
>>>
>>> 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.
>> 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.
>>>
>>> #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.
>> Yes and no.
>>
>> 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,
>> IMO, if we don't create something such, we will end up with rules which will be just a thin wrapper around services.
>>
>> 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.
>> 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.
>> In this approach, the second rule would pick up the MavenPomFileNode no matter where it comes from.
>> I could have written the example 1:1 but wanted to show this task separation advantage.
>>
>>
>>> 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.
>> Okay, let's see what we have.
>>>
>>> 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.
>>>
>>> Java first. Then XML (or whatever).
>> Hmm. About 4 months ago, it was exactly opposite: XML rules, no Java.
>> It was also one of the main reasons to abandon WindRide the XML rules were implemented.
>> 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".
>> When did this change, and what's the guarantee that it won't change again?
>>
>> Ondra
>>
>>> ~Lincoln
>>>
>>> ________________________________
>>> From: "Ondrej Zizka" < ozizka at redhat.com >
>>> To: jboss-migration at redhat.com
>>> Sent: Thursday, May 1, 2014 12:05:23 AM
>>> Subject: Re: Let's replace the GraphVisitor interface concept with something generic
>>>
>>> I've put it to this doc so we can edit/comment there.
>>>
>>> https://docs.google.com/document/d/1UOihPv_zryFilCb7T0k8992wPUt3YNP4goh9rxTC7ng/edit#
>>>
>>> Ondra
>>>
>>>
>>>
>>> On 1.5.2014 04:35, Ondrej Zizka wrote:
>>>> Hi,
>>>>
>>>> as we discussed before, I'd like to replace the GraphVisitor interface with something generic.
>>>> 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.
>>>>
>>>> public void visitEjbEntity(EjbEntityFacet entry);
>>>> public void visitEjbService(EjbSessionBeanFacet entry);
>>>> public void visitMessageDrivenBean(MessageDrivenBeanFacet entry);
>>>> public void visitEjbEntity(SpringBeanFacet entry);
>>>> ...
>>>>
>>>>
>>>>
>>>> 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:
>>>> * replace a node with a subclass, e.g.
>>>> FileNode => XmlFileNode => MavenPomNode,
>>>> FileNode => JavaFileNode => AnnotationNode
>>>>
>>>> * add properties, e.g.
>>>> XmlFileNode's "doctype",
>>>> ClassNode's "blacklisted"
>>>> * connect nodes to them, e.g.
>>>> MavenPom ---contains---> MavenDependencyNode
>>>> JavaFile --- imports --> [ ClassNode, ClassNode, ... ]
>>>>
>>>> This approach would:
>>>> * Leverage of Forge modularity (e.g. Maven addon depending on XmlFile addon)
>>>> * Improve extendability (no need to squeeze everything into the GraphVisitor interface's methods or extend it)
>>>> * Lead to much more straightforward rules implementation - all rules would reduce to:
>>>> * matching graph information (Gremlin?)
>>>> * using DAO's / Services (for mining data from the files/..., and for writing them during active migration)
>>>> 1) Bundled - XPath, AST query, properties, Maven remote fetch, ...
>>>> 2) User's: .class packed within the addon or a Groovy class
>>>> * writing back to the graph
>>>> * rendering pieces of HTML for the report.
>>>>
>>>> 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.
>>>>
>>>> As an example, take e.g. MavenRemoteFetchVisitor. https://github.com/windup/windup/blob/master/engine/rules/impl/src/main/java/org/jboss/windup/engine/visitor/inspector/MavenRemoteFetchVisitor.java
>>>>
>>>> All that is doable using few simple building blocks, directed by few lines of a rule like this:
>>>>
>>>> ------------------------------------------------------------------
>>>>
>>>> <var name="pomNS" val=" http://maven.apache.org/POM/4.0.0 ">
>>>>
>>>> Rule 1) which would process all POM files and load the info into the graph.
>>>>
>>>> <rule id="maven.pomFiles" desc=" Analyze Maven POM files "
>>>> phase="StaticConfigAnalysis">
>>>> <graph match="XmlFileNode[doctype=' http://maven.apache.org/POM/4.0.0' ]" toVar="xmls">
>>>> <for var="pom" in="xmls">
>>>> <graph:replaceSingle ref="pom" with="MavenPomFileNode">
>>>> <properties>
>>>> <!-- <jaxb> would invoce a call to a Service.
>>>> <properties> hander would take returned object's bean props.
>>>> toClass would load the class from CL or compile from .groovy coming with the migrator (addon).
>>>> -->
>>>> <jaxb toClass="PomJaxb.groovy" fromFile="${pom.path}">
>>>> <ns name="pom" uri="${pomNS}"/>
>>>> </jaxb>
>>>> </properties>
>>>> </graph>
>>>> </for>
>>>> </rule>
>>>>
>>>> @XmlRoot
>>>> class PomJaxb {
>>>> @XmlXPath("/pom:project/pom:modelVersion") String modelVersion;
>>>> @XmlXPath("/pom:project/pom:name") String name;
>>>> @XmlXPath("/pom:project/pom:description" String description;
>>>> @XmlXPath("/pom:project/pom:url" String url;
>>>> }
>>>>
>>>>
>>>> Rule 2) which would load the dependencies and describe them into Nodes and Edges.
>>>>
>>>> <rule id="maven.pomDependencies" desc=" Analyze Maven POM file dependencies "
>>>> phase="StaticConfigAnalysis">
>>>> <after rule="maven.pomFiles">
>>>>
>>>> <graph match="MavenPomFileNode" toVar="pomVertexes">
>>>> <for var="pomV" in="pomVertexes">
>>>>
>>>> <xpath toVar="deps" fromFile="${pomV.path}" match="/pom:project/pom:dependencies/pom:dependency"/>
>>>> <for var="depElement" in="deps">
>>>> <jaxb toVar="dep" toClass="MavenDepencencyJaxb.groovy" fromElement="depElement" ns="pom ${pomNS}"/>
>>>> <graph:query toVar="isBlacklisted"
>>>> q=" /* I don't know Gremlin so far, imagine an equiv of this XPath: */
>>>> MavenDependencyNode[
>>>> g=${dep.groupId} and a=${dep.artifactId} and v=${dep.version}
>>>> ]@blacklisted
>>>> " />
>>>> <continue if="isBlacklisted /* var, or Groovy (or EL) expression */" />
>>>> <!-- This would be useful for blacklists and filters in general, which appear often in real life rules. -->
>>>>
>>>> <graph:insertIfNotExists type="MavenDependencyNode" toVar="depVertex>
>>>> <properties from="dep"/>
>>>> </graph>
>>>> <graph:edge type="dependsOn" from="pomV" to="depVertex"/>
>>>> <!-- Maybe Gremlin could replace this? -->
>>>> </for>
>>>> </for>
>>>> </rule>
>>>>
>>>> @XmlRoot
>>>> class MavenDepencencyJaxb {
>>>> // GraphKeyProperty identifies those which are compared for insertIfNotExists.
>>>> @GraphKeyProperty @XmlXPath("./pom:groupId") String groupId;
>>>> @GraphKeyProperty @XmlXPath("./pom:artifactId") String artifactId;
>>>> @GraphKeyProperty @XmlXPath("./pom:version") String version;
>>>> }
>>>> ------------------------------------------------------------------
>>>>
>>>> As you can see, It creates independent rules which only communicate indirectly through the graph.
>>>> You can also see how nicely Java classes fit into this, and how Groovy could make this easier.
>>>>
>>>> SERVICES INVOCATION
>>>> Forge UI could be mapped to XML elements. I.e. <aaa foo="bar"/> could invoke command "aaa" with given params.
>>>> I believe Forge already has this way of input, right?
>>>>
>>>> GRAPH OPERATION
>>>> There would be several <graph:...> operations - CRUD plus some special.
>>>>
>>>> EXECUTION FLOW
>>>> 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>.
>>>>
>>>> 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.
>>>>
>>>> For more complex logic, users would break the task into multiple rules, storing data into the graph intermediately.
>>>>
>>>> I'll check few more visitors to see if this is powerful enough to satisfy all the baneeds.
>>>>
>>>>
>>>> .............................
>>>>
>>>> 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 https://docs.google.com/drawings/d/1IMnds3Qu8Wwcf7_mr7NJ9a3YgtcGJ7dejl09EhWl7Vc for illustration.
>>>>
>>>> Ondra
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>


From lincolnbaxter at gmail.com  Mon May  5 12:19:37 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Mon, 5 May 2014 12:19:37 -0400
Subject: [windup-dev] Testing
In-Reply-To: <2035446983.727660.1399305108118.JavaMail.zimbra@redhat.com>
References: <2035446983.727660.1399305108118.JavaMail.zimbra@redhat.com>
Message-ID: <CAEp_U4EgSQAwL15s4cFxS5JHVZdUtkhc+DvFQ0MnQFNnAsmndA@mail.gmail.com>

received


On Mon, May 5, 2014 at 11:51 AM, Robb Greathouse <robb.greathouse at redhat.com
> wrote:

>
>
>
> Robb Greathouse
> Chief Evangelist
> Middleware Business Unit
> JBoss, a Division of Red Hat
> cellphone 505-507-4906
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140505/63c4ea94/attachment.html 

From bdavis at redhat.com  Mon May  5 13:15:01 2014
From: bdavis at redhat.com (Brad Davis)
Date: Mon, 5 May 2014 13:15:01 -0400 (EDT)
Subject: [windup-dev] Let's replace the GraphVisitor interface concept
 with something generic
In-Reply-To: <5367AE7E.1000505@redhat.com>
References: <1394105113.162433.1399246253927.JavaMail.zimbra@zmail09.collab.prod.int.phx2.redhat.com>
	<CAEp_U4HyzwzAj2C6Nbf2SQP3NW_TP0xTeOOnDzX8SX5J3dO7LA@mail.gmail.com>
	<181119329.615524.1399302015745.JavaMail.zimbra@redhat.com>
	<5367AE7E.1000505@redhat.com>
Message-ID: <1485356002.683076.1399310101224.JavaMail.zimbra@redhat.com>

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."

com.tinkerpop.frames.modules.typedgraph.TypeField;
com.tinkerpop.frames.modules.typedgraph.TypeValue;

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.

Brad Davis
Red Hat Consulting
Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com 


----- Original Message -----
From: "Jess Sightler" <jsightle at redhat.com>
To: windup-dev at lists.jboss.org
Sent: Monday, May 5, 2014 11:30:06 AM
Subject: Re: [windup-dev] Let's replace the GraphVisitor interface concept with something generic

I think you are not reading this correctly. That's ok, though, as I 
probably didn't describe it correctly. :) I am talking about supporting 
types, but supporting them using a model more similar to OWL/RDF than to 
classical OO-devleopment. In this model, you do not know all of the 
typing information up front, and instead infer type information as you go.

So, for example, a Vertex may evolve over time to support additional 
types as more information is learned. For example, the first rule may 
provide a "File", but it later may become "File and ZipFile", and then 
ultimately "File and ZipFile and EarFile".

During each step of this evolution it retains all of it's 
characteristics of the previous step. You can think of it as subclassing 
if you want, but eventually the Java model of subclassing will mislead 
you about what this means, as it is not necessary for new types to be 
subclasses of existing types.

Frames encompasses this concept, and this is the big reason that it uses 
Interfaces instead of classes, AFAICT.

This document may be helpful as well:
http://www.w3.org/TR/sw-oosd-primer/#comparison


On 05/05/2014 11:00 AM, Brad Davis wrote:
> 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.
>
> 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.
>
> Brad Davis
> Red Hat Consulting
> Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
>
>
> ----- Original Message -----
> From: "Lincoln Baxter, III" <lincolnbaxter at gmail.com>
> To: "Windup-dev List" <windup-dev at lists.jboss.org>
> Sent: Monday, May 5, 2014 10:34:28 AM
> Subject: Re: [windup-dev] Let's replace the GraphVisitor interface concept with something generic
>
> 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.
>
>
> On Sun, May 4, 2014 at 7:30 PM, Jess Sightler < jsightle at redhat.com > wrote:
>
>
>
>
>
>
> On May 2, 2014 5:31 PM, Ondrej Zizka < ozizka at redhat.com > wrote:
>>
>> On 2.5.2014 21:17, Lincoln Baxter wrote:
>>> Hey Ondra,
>>>
>>> I'm moving this discussion to windup-dev at lists.jboss.org - please use windup-dev for all non-confidential development discussion.
>>>
>>> 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:
>>>
>>> #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.
>> That's the purpose. The rules would interfere. Or rather, infer.
>> 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.
>
>
> I prefer to think of this in terms of RDF-style classes that operate on the open world assumption: http://en.m.wikipedia.org/wiki/Open_world_assumption
>
> 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. :-)
>
> >From my research on Friday, I believe that this OWA type model may actually be supported pretty well by Tinkerpop frames.
>
> We can discuss further next week, as I am sure the above is insufficient. :-)
>
>
>
>
>> 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.
>>
>>> #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?
>> I didn't find anything related in https://github.com/thinkaurelius/titan/wiki/Titan-Limitations (those type limitations seem to apply on other things). I'll try practically.
>>>
>>> #3) You asked: "Forge UI could be mapped to XML elements. I.e. <aaa foo="bar"/> could invoke command "aaa" with given params.
>>> I believe Forge already has this way of input, right?"
>>>
>>> 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.
>> 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.
>>>
>>> #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.
>> Yes and no.
>>
>> 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,
>> IMO, if we don't create something such, we will end up with rules which will be just a thin wrapper around services.
>>
>> 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.
>> 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.
>> In this approach, the second rule would pick up the MavenPomFileNode no matter where it comes from.
>> I could have written the example 1:1 but wanted to show this task separation advantage.
>>
>>
>>> 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.
>> Okay, let's see what we have.
>>>
>>> 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.
>>>
>>> Java first. Then XML (or whatever).
>> Hmm. About 4 months ago, it was exactly opposite: XML rules, no Java.
>> It was also one of the main reasons to abandon WindRide the XML rules were implemented.
>> 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".
>> When did this change, and what's the guarantee that it won't change again?
>>
>> Ondra
>>
>>> ~Lincoln
>>>
>>> ________________________________
>>> From: "Ondrej Zizka" < ozizka at redhat.com >
>>> To: jboss-migration at redhat.com
>>> Sent: Thursday, May 1, 2014 12:05:23 AM
>>> Subject: Re: Let's replace the GraphVisitor interface concept with something generic
>>>
>>> I've put it to this doc so we can edit/comment there.
>>>
>>> https://docs.google.com/document/d/1UOihPv_zryFilCb7T0k8992wPUt3YNP4goh9rxTC7ng/edit#
>>>
>>> Ondra
>>>
>>>
>>>
>>> On 1.5.2014 04:35, Ondrej Zizka wrote:
>>>> Hi,
>>>>
>>>> as we discussed before, I'd like to replace the GraphVisitor interface with something generic.
>>>> 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.
>>>>
>>>> public void visitEjbEntity(EjbEntityFacet entry);
>>>> public void visitEjbService(EjbSessionBeanFacet entry);
>>>> public void visitMessageDrivenBean(MessageDrivenBeanFacet entry);
>>>> public void visitEjbEntity(SpringBeanFacet entry);
>>>> ...
>>>>
>>>>
>>>>
>>>> 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:
>>>> * replace a node with a subclass, e.g.
>>>> FileNode => XmlFileNode => MavenPomNode,
>>>> FileNode => JavaFileNode => AnnotationNode
>>>>
>>>> * add properties, e.g.
>>>> XmlFileNode's "doctype",
>>>> ClassNode's "blacklisted"
>>>> * connect nodes to them, e.g.
>>>> MavenPom ---contains---> MavenDependencyNode
>>>> JavaFile --- imports --> [ ClassNode, ClassNode, ... ]
>>>>
>>>> This approach would:
>>>> * Leverage of Forge modularity (e.g. Maven addon depending on XmlFile addon)
>>>> * Improve extendability (no need to squeeze everything into the GraphVisitor interface's methods or extend it)
>>>> * Lead to much more straightforward rules implementation - all rules would reduce to:
>>>> * matching graph information (Gremlin?)
>>>> * using DAO's / Services (for mining data from the files/..., and for writing them during active migration)
>>>> 1) Bundled - XPath, AST query, properties, Maven remote fetch, ...
>>>> 2) User's: .class packed within the addon or a Groovy class
>>>> * writing back to the graph
>>>> * rendering pieces of HTML for the report.
>>>>
>>>> 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.
>>>>
>>>> As an example, take e.g. MavenRemoteFetchVisitor. https://github.com/windup/windup/blob/master/engine/rules/impl/src/main/java/org/jboss/windup/engine/visitor/inspector/MavenRemoteFetchVisitor.java
>>>>
>>>> All that is doable using few simple building blocks, directed by few lines of a rule like this:
>>>>
>>>> ------------------------------------------------------------------
>>>>
>>>> <var name="pomNS" val=" http://maven.apache.org/POM/4.0.0 ">
>>>>
>>>> Rule 1) which would process all POM files and load the info into the graph.
>>>>
>>>> <rule id="maven.pomFiles" desc=" Analyze Maven POM files "
>>>> phase="StaticConfigAnalysis">
>>>> <graph match="XmlFileNode[doctype=' http://maven.apache.org/POM/4.0.0' ]" toVar="xmls">
>>>> <for var="pom" in="xmls">
>>>> <graph:replaceSingle ref="pom" with="MavenPomFileNode">
>>>> <properties>
>>>> <!-- <jaxb> would invoce a call to a Service.
>>>> <properties> hander would take returned object's bean props.
>>>> toClass would load the class from CL or compile from .groovy coming with the migrator (addon).
>>>> -->
>>>> <jaxb toClass="PomJaxb.groovy" fromFile="${pom.path}">
>>>> <ns name="pom" uri="${pomNS}"/>
>>>> </jaxb>
>>>> </properties>
>>>> </graph>
>>>> </for>
>>>> </rule>
>>>>
>>>> @XmlRoot
>>>> class PomJaxb {
>>>> @XmlXPath("/pom:project/pom:modelVersion") String modelVersion;
>>>> @XmlXPath("/pom:project/pom:name") String name;
>>>> @XmlXPath("/pom:project/pom:description" String description;
>>>> @XmlXPath("/pom:project/pom:url" String url;
>>>> }
>>>>
>>>>
>>>> Rule 2) which would load the dependencies and describe them into Nodes and Edges.
>>>>
>>>> <rule id="maven.pomDependencies" desc=" Analyze Maven POM file dependencies "
>>>> phase="StaticConfigAnalysis">
>>>> <after rule="maven.pomFiles">
>>>>
>>>> <graph match="MavenPomFileNode" toVar="pomVertexes">
>>>> <for var="pomV" in="pomVertexes">
>>>>
>>>> <xpath toVar="deps" fromFile="${pomV.path}" match="/pom:project/pom:dependencies/pom:dependency"/>
>>>> <for var="depElement" in="deps">
>>>> <jaxb toVar="dep" toClass="MavenDepencencyJaxb.groovy" fromElement="depElement" ns="pom ${pomNS}"/>
>>>> <graph:query toVar="isBlacklisted"
>>>> q=" /* I don't know Gremlin so far, imagine an equiv of this XPath: */
>>>> MavenDependencyNode[
>>>> g=${dep.groupId} and a=${dep.artifactId} and v=${dep.version}
>>>> ]@blacklisted
>>>> " />
>>>> <continue if="isBlacklisted /* var, or Groovy (or EL) expression */" />
>>>> <!-- This would be useful for blacklists and filters in general, which appear often in real life rules. -->
>>>>
>>>> <graph:insertIfNotExists type="MavenDependencyNode" toVar="depVertex>
>>>> <properties from="dep"/>
>>>> </graph>
>>>> <graph:edge type="dependsOn" from="pomV" to="depVertex"/>
>>>> <!-- Maybe Gremlin could replace this? -->
>>>> </for>
>>>> </for>
>>>> </rule>
>>>>
>>>> @XmlRoot
>>>> class MavenDepencencyJaxb {
>>>> // GraphKeyProperty identifies those which are compared for insertIfNotExists.
>>>> @GraphKeyProperty @XmlXPath("./pom:groupId") String groupId;
>>>> @GraphKeyProperty @XmlXPath("./pom:artifactId") String artifactId;
>>>> @GraphKeyProperty @XmlXPath("./pom:version") String version;
>>>> }
>>>> ------------------------------------------------------------------
>>>>
>>>> As you can see, It creates independent rules which only communicate indirectly through the graph.
>>>> You can also see how nicely Java classes fit into this, and how Groovy could make this easier.
>>>>
>>>> SERVICES INVOCATION
>>>> Forge UI could be mapped to XML elements. I.e. <aaa foo="bar"/> could invoke command "aaa" with given params.
>>>> I believe Forge already has this way of input, right?
>>>>
>>>> GRAPH OPERATION
>>>> There would be several <graph:...> operations - CRUD plus some special.
>>>>
>>>> EXECUTION FLOW
>>>> 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>.
>>>>
>>>> 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.
>>>>
>>>> For more complex logic, users would break the task into multiple rules, storing data into the graph intermediately.
>>>>
>>>> I'll check few more visitors to see if this is powerful enough to satisfy all the baneeds.
>>>>
>>>>
>>>> .............................
>>>>
>>>> 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 https://docs.google.com/drawings/d/1IMnds3Qu8Wwcf7_mr7NJ9a3YgtcGJ7dejl09EhWl7Vc for illustration.
>>>>
>>>> Ondra
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>

_______________________________________________
windup-dev mailing list
windup-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev

From bgeorges at redhat.com  Wed May  7 22:44:00 2014
From: bgeorges at redhat.com (Bruno Georges)
Date: Thu, 8 May 2014 14:44:00 +1200
Subject: [windup-dev] JBoss 5 to 7
Message-ID: <D5026182-E9FF-4B1C-87DC-6C5CCF5D1B4B@redhat.com>

just fyi if you haven?t seen that already: http://java.dzone.com/articles/jboss-5-7-11-steps


Cheers,
--
Bruno P. Georges
Director, Application Platforms Engineering
JBoss, by Red Hat
Cell:   +65 8218 0964

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

From ozizka at redhat.com  Wed May  7 07:26:40 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Wed, 07 May 2014 13:26:40 +0200
Subject: [windup-dev] WindUp/engine/graph/addon is empty?
Message-ID: <536A1870.107@redhat.com>

Hi,

what is $SUBJ good for? It's a jar artifact, but has no code nor tests.

Shall we remove that?

Ondra

From ozizka at redhat.com  Fri May  9 12:16:51 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Fri, 09 May 2014 18:16:51 +0200
Subject: [windup-dev] Test
Message-ID: <536CFF73.9090108@redhat.com>

from: .*.com removed

From lincolnbaxter at gmail.com  Fri May  9 10:41:31 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Fri, 9 May 2014 10:41:31 -0400
Subject: [windup-dev] WindUp/engine/graph/addon is empty?
In-Reply-To: <536A1870.107@redhat.com>
References: <536A1870.107@redhat.com>
Message-ID: <CAEp_U4HxW3-2SGLGuVWvdSRhCnVUsUxP_VLEFZB--P9wZ47Kgw@mail.gmail.com>

It's necessary as a classified POM artifact for Furnace addon-manager to
pick up. If we were not using the "exploded" project layout, this is where
the code would be.


On Wed, May 7, 2014 at 7:26 AM, Ondrej Zizka <ozizka at redhat.com> wrote:

> Hi,
>
> what is $SUBJ good for? It's a jar artifact, but has no code nor tests.
>
> Shall we remove that?
>
> Ondra
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140509/165c0d85/attachment.html 

From ozizka at redhat.com  Fri May  9 12:15:21 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Fri, 09 May 2014 18:15:21 +0200
Subject: [windup-dev] Headers settings
Message-ID: <536CFF19.1030306@redhat.com>

https://lists.jboss.org/mailman/admin/windup-dev/privacy/spam

Maybe the "from: .*.com" should go away? Google.com gets hit by that.

# Lines that *start* with a '#' are comments.
to: friend.com
message-id: relay.comanche.denmark.eu
from: list.com
from: .*.com
cc: thecore.com
to: thecore.com

From lincolnbaxter at gmail.com  Fri May  9 12:58:19 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Fri, 9 May 2014 12:58:19 -0400
Subject: [windup-dev] Headers settings
In-Reply-To: <536CFF19.1030306@redhat.com>
References: <536CFF19.1030306@redhat.com>
Message-ID: <CAEp_U4H_Ot-_f35OtWEt3y=Efw=z8fZSErnbbDdFdKyyA_Zn5w@mail.gmail.com>

Does that work? Testing.


On Fri, May 9, 2014 at 12:15 PM, Ondrej Zizka <ozizka at redhat.com> wrote:

> https://lists.jboss.org/mailman/admin/windup-dev/privacy/spam
>
> Maybe the "from: .*.com" should go away? Google.com gets hit by that.
>
> # Lines that *start* with a '#' are comments.
> to: friend.com
> message-id: relay.comanche.denmark.eu
> from: list.com
> from: .*.com
> cc: thecore.com
> to: thecore.com
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140509/e0b501f8/attachment.html 

From ozizka at redhat.com  Fri May  9 13:00:58 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Fri, 09 May 2014 19:00:58 +0200
Subject: [windup-dev] Headers settings
In-Reply-To: <CAEp_U4H_Ot-_f35OtWEt3y=Efw=z8fZSErnbbDdFdKyyA_Zn5w@mail.gmail.com>
References: <536CFF19.1030306@redhat.com>
	<CAEp_U4H_Ot-_f35OtWEt3y=Efw=z8fZSErnbbDdFdKyyA_Zn5w@mail.gmail.com>
Message-ID: <536D09CA.9010408@redhat.com>

For me it does.

On 9.5.2014 18:58, Lincoln Baxter, III wrote:
> Does that work? Testing.
>
>
> On Fri, May 9, 2014 at 12:15 PM, Ondrej Zizka <ozizka at redhat.com 
> <mailto:ozizka at redhat.com>> wrote:
>
>     https://lists.jboss.org/mailman/admin/windup-dev/privacy/spam
>
>     Maybe the "from: .*.com" should go away? Google.com gets hit by that.
>
>     # Lines that *start* with a '#' are comments.
>     to: friend.com <http://friend.com>
>     message-id: relay.comanche.denmark.eu
>     <http://relay.comanche.denmark.eu>
>     from: list.com <http://list.com>
>     from: .*.com
>     cc: thecore.com <http://thecore.com>
>     to: thecore.com <http://thecore.com>
>     _______________________________________________
>     windup-dev mailing list
>     windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
>
> -- 
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140509/4c1678da/attachment.html 

From lincolnbaxter at gmail.com  Fri May  9 13:01:32 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Fri, 9 May 2014 13:01:32 -0400
Subject: [windup-dev] Headers settings
In-Reply-To: <536D09CA.9010408@redhat.com>
References: <536CFF19.1030306@redhat.com>
	<CAEp_U4H_Ot-_f35OtWEt3y=Efw=z8fZSErnbbDdFdKyyA_Zn5w@mail.gmail.com>
	<536D09CA.9010408@redhat.com>
Message-ID: <CAEp_U4GP2hYteraQn6fe6LRzM-5pEoq=X_cF1QDYqEwGhYc_wA@mail.gmail.com>

SWEET. Thank you. Good find!


On Fri, May 9, 2014 at 1:00 PM, Ondrej Zizka <ozizka at redhat.com> wrote:

>  For me it does.
>
>
> On 9.5.2014 18:58, Lincoln Baxter, III wrote:
>
> Does that work? Testing.
>
>
> On Fri, May 9, 2014 at 12:15 PM, Ondrej Zizka <ozizka at redhat.com> wrote:
>
>> https://lists.jboss.org/mailman/admin/windup-dev/privacy/spam
>>
>> Maybe the "from: .*.com" should go away? Google.com gets hit by that.
>>
>> # Lines that *start* with a '#' are comments.
>> to: friend.com
>> message-id: relay.comanche.denmark.eu
>> from: list.com
>> from: .*.com
>> cc: thecore.com
>> to: thecore.com
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>
>
>
>
>  --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
>
> _______________________________________________
> windup-dev mailing listwindup-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140509/c60d830b/attachment-0001.html 

From jsightle at redhat.com  Fri May  9 13:03:26 2014
From: jsightle at redhat.com (Jess Sightler)
Date: Fri, 09 May 2014 13:03:26 -0400
Subject: [windup-dev] WindUp/engine/graph/addon is empty?
In-Reply-To: <CAEp_U4HxW3-2SGLGuVWvdSRhCnVUsUxP_VLEFZB--P9wZ47Kgw@mail.gmail.com>
References: <536A1870.107@redhat.com>
	<CAEp_U4HxW3-2SGLGuVWvdSRhCnVUsUxP_VLEFZB--P9wZ47Kgw@mail.gmail.com>
Message-ID: <536D0A5E.9030001@redhat.com>

Is this where UIWizard and forge command will go as well?

On 05/09/2014 10:41 AM, Lincoln Baxter, III wrote:
> It's necessary as a classified POM artifact for Furnace addon-manager 
> to pick up. If we were not using the "exploded" project layout, this 
> is where the code would be.
>
>
> On Wed, May 7, 2014 at 7:26 AM, Ondrej Zizka <ozizka at redhat.com 
> <mailto:ozizka at redhat.com>> wrote:
>
>     Hi,
>
>     what is $SUBJ good for? It's a jar artifact, but has no code nor
>     tests.
>
>     Shall we remove that?
>
>     Ondra
>     _______________________________________________
>     windup-dev mailing list
>     windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
>
> -- 
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140509/5fcefadd/attachment.html 

From jsightle at redhat.com  Fri May  9 13:41:36 2014
From: jsightle at redhat.com (Jess Sightler)
Date: Fri, 09 May 2014 13:41:36 -0400
Subject: [windup-dev] Let's replace the GraphVisitor interface concept
 with something generic
In-Reply-To: <1485356002.683076.1399310101224.JavaMail.zimbra@redhat.com>
References: <1394105113.162433.1399246253927.JavaMail.zimbra@zmail09.collab.prod.int.phx2.redhat.com>	<CAEp_U4HyzwzAj2C6Nbf2SQP3NW_TP0xTeOOnDzX8SX5J3dO7LA@mail.gmail.com>	<181119329.615524.1399302015745.JavaMail.zimbra@redhat.com>	<5367AE7E.1000505@redhat.com>
	<1485356002.683076.1399310101224.JavaMail.zimbra@redhat.com>
Message-ID: <536D1350.9030304@redhat.com>

I'm sorry for not responding sooner... somehow I missed this email earlier.

Basically I have added a new Type Manager (GraphTypeManager) that 
augments the TypeField/TypeValue functionality to support the resolution 
of multiple types. It also uses a addon scanner to avoid the need to 
hardcode a list of classes for TypedGraphModuleBuilder.

So far this appears to work will for the windup usecase.

On 05/05/2014 01:15 PM, Brad Davis wrote:
> 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."
>
> com.tinkerpop.frames.modules.typedgraph.TypeField;
> com.tinkerpop.frames.modules.typedgraph.TypeValue;
>
> 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.
>
> Brad Davis
> Red Hat Consulting
> Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
>
>
> ----- Original Message -----
> From: "Jess Sightler" <jsightle at redhat.com>
> To: windup-dev at lists.jboss.org
> Sent: Monday, May 5, 2014 11:30:06 AM
> Subject: Re: [windup-dev] Let's replace the GraphVisitor interface concept with something generic
>
> I think you are not reading this correctly. That's ok, though, as I
> probably didn't describe it correctly. :) I am talking about supporting
> types, but supporting them using a model more similar to OWL/RDF than to
> classical OO-devleopment. In this model, you do not know all of the
> typing information up front, and instead infer type information as you go.
>
> So, for example, a Vertex may evolve over time to support additional
> types as more information is learned. For example, the first rule may
> provide a "File", but it later may become "File and ZipFile", and then
> ultimately "File and ZipFile and EarFile".
>
> During each step of this evolution it retains all of it's
> characteristics of the previous step. You can think of it as subclassing
> if you want, but eventually the Java model of subclassing will mislead
> you about what this means, as it is not necessary for new types to be
> subclasses of existing types.
>
> Frames encompasses this concept, and this is the big reason that it uses
> Interfaces instead of classes, AFAICT.
>
> This document may be helpful as well:
> http://www.w3.org/TR/sw-oosd-primer/#comparison
>
>
> On 05/05/2014 11:00 AM, Brad Davis wrote:
>> 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.
>>
>> 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.
>>
>> Brad Davis
>> Red Hat Consulting
>> Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
>>
>>
>> ----- Original Message -----
>> From: "Lincoln Baxter, III" <lincolnbaxter at gmail.com>
>> To: "Windup-dev List" <windup-dev at lists.jboss.org>
>> Sent: Monday, May 5, 2014 10:34:28 AM
>> Subject: Re: [windup-dev] Let's replace the GraphVisitor interface concept with something generic
>>
>> 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.
>>
>>
>> On Sun, May 4, 2014 at 7:30 PM, Jess Sightler < jsightle at redhat.com > wrote:
>>
>>
>>
>>
>>
>>
>> On May 2, 2014 5:31 PM, Ondrej Zizka < ozizka at redhat.com > wrote:
>>> On 2.5.2014 21:17, Lincoln Baxter wrote:
>>>> Hey Ondra,
>>>>
>>>> I'm moving this discussion to windup-dev at lists.jboss.org - please use windup-dev for all non-confidential development discussion.
>>>>
>>>> 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:
>>>>
>>>> #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.
>>> That's the purpose. The rules would interfere. Or rather, infer.
>>> 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.
>>
>> I prefer to think of this in terms of RDF-style classes that operate on the open world assumption: http://en.m.wikipedia.org/wiki/Open_world_assumption
>>
>> 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. :-)
>>
>> >From my research on Friday, I believe that this OWA type model may actually be supported pretty well by Tinkerpop frames.
>>
>> We can discuss further next week, as I am sure the above is insufficient. :-)
>>
>>
>>
>>
>>> 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.
>>>
>>>> #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?
>>> I didn't find anything related in https://github.com/thinkaurelius/titan/wiki/Titan-Limitations (those type limitations seem to apply on other things). I'll try practically.
>>>> #3) You asked: "Forge UI could be mapped to XML elements. I.e. <aaa foo="bar"/> could invoke command "aaa" with given params.
>>>> I believe Forge already has this way of input, right?"
>>>>
>>>> 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.
>>> 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.
>>>> #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.
>>> Yes and no.
>>>
>>> 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,
>>> IMO, if we don't create something such, we will end up with rules which will be just a thin wrapper around services.
>>>
>>> 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.
>>> 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.
>>> In this approach, the second rule would pick up the MavenPomFileNode no matter where it comes from.
>>> I could have written the example 1:1 but wanted to show this task separation advantage.
>>>
>>>
>>>> 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.
>>> Okay, let's see what we have.
>>>> 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.
>>>>
>>>> Java first. Then XML (or whatever).
>>> Hmm. About 4 months ago, it was exactly opposite: XML rules, no Java.
>>> It was also one of the main reasons to abandon WindRide the XML rules were implemented.
>>> 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".
>>> When did this change, and what's the guarantee that it won't change again?
>>>
>>> Ondra
>>>
>>>> ~Lincoln
>>>>
>>>> ________________________________
>>>> From: "Ondrej Zizka" < ozizka at redhat.com >
>>>> To: jboss-migration at redhat.com
>>>> Sent: Thursday, May 1, 2014 12:05:23 AM
>>>> Subject: Re: Let's replace the GraphVisitor interface concept with something generic
>>>>
>>>> I've put it to this doc so we can edit/comment there.
>>>>
>>>> https://docs.google.com/document/d/1UOihPv_zryFilCb7T0k8992wPUt3YNP4goh9rxTC7ng/edit#
>>>>
>>>> Ondra
>>>>
>>>>
>>>>
>>>> On 1.5.2014 04:35, Ondrej Zizka wrote:
>>>>> Hi,
>>>>>
>>>>> as we discussed before, I'd like to replace the GraphVisitor interface with something generic.
>>>>> 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.
>>>>>
>>>>> public void visitEjbEntity(EjbEntityFacet entry);
>>>>> public void visitEjbService(EjbSessionBeanFacet entry);
>>>>> public void visitMessageDrivenBean(MessageDrivenBeanFacet entry);
>>>>> public void visitEjbEntity(SpringBeanFacet entry);
>>>>> ...
>>>>>
>>>>>
>>>>>
>>>>> 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:
>>>>> * replace a node with a subclass, e.g.
>>>>> FileNode => XmlFileNode => MavenPomNode,
>>>>> FileNode => JavaFileNode => AnnotationNode
>>>>>
>>>>> * add properties, e.g.
>>>>> XmlFileNode's "doctype",
>>>>> ClassNode's "blacklisted"
>>>>> * connect nodes to them, e.g.
>>>>> MavenPom ---contains---> MavenDependencyNode
>>>>> JavaFile --- imports --> [ ClassNode, ClassNode, ... ]
>>>>>
>>>>> This approach would:
>>>>> * Leverage of Forge modularity (e.g. Maven addon depending on XmlFile addon)
>>>>> * Improve extendability (no need to squeeze everything into the GraphVisitor interface's methods or extend it)
>>>>> * Lead to much more straightforward rules implementation - all rules would reduce to:
>>>>> * matching graph information (Gremlin?)
>>>>> * using DAO's / Services (for mining data from the files/..., and for writing them during active migration)
>>>>> 1) Bundled - XPath, AST query, properties, Maven remote fetch, ...
>>>>> 2) User's: .class packed within the addon or a Groovy class
>>>>> * writing back to the graph
>>>>> * rendering pieces of HTML for the report.
>>>>>
>>>>> 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.
>>>>>
>>>>> As an example, take e.g. MavenRemoteFetchVisitor. https://github.com/windup/windup/blob/master/engine/rules/impl/src/main/java/org/jboss/windup/engine/visitor/inspector/MavenRemoteFetchVisitor.java
>>>>>
>>>>> All that is doable using few simple building blocks, directed by few lines of a rule like this:
>>>>>
>>>>> ------------------------------------------------------------------
>>>>>
>>>>> <var name="pomNS" val=" http://maven.apache.org/POM/4.0.0 ">
>>>>>
>>>>> Rule 1) which would process all POM files and load the info into the graph.
>>>>>
>>>>> <rule id="maven.pomFiles" desc=" Analyze Maven POM files "
>>>>> phase="StaticConfigAnalysis">
>>>>> <graph match="XmlFileNode[doctype=' http://maven.apache.org/POM/4.0.0' ]" toVar="xmls">
>>>>> <for var="pom" in="xmls">
>>>>> <graph:replaceSingle ref="pom" with="MavenPomFileNode">
>>>>> <properties>
>>>>> <!-- <jaxb> would invoce a call to a Service.
>>>>> <properties> hander would take returned object's bean props.
>>>>> toClass would load the class from CL or compile from .groovy coming with the migrator (addon).
>>>>> -->
>>>>> <jaxb toClass="PomJaxb.groovy" fromFile="${pom.path}">
>>>>> <ns name="pom" uri="${pomNS}"/>
>>>>> </jaxb>
>>>>> </properties>
>>>>> </graph>
>>>>> </for>
>>>>> </rule>
>>>>>
>>>>> @XmlRoot
>>>>> class PomJaxb {
>>>>> @XmlXPath("/pom:project/pom:modelVersion") String modelVersion;
>>>>> @XmlXPath("/pom:project/pom:name") String name;
>>>>> @XmlXPath("/pom:project/pom:description" String description;
>>>>> @XmlXPath("/pom:project/pom:url" String url;
>>>>> }
>>>>>
>>>>>
>>>>> Rule 2) which would load the dependencies and describe them into Nodes and Edges.
>>>>>
>>>>> <rule id="maven.pomDependencies" desc=" Analyze Maven POM file dependencies "
>>>>> phase="StaticConfigAnalysis">
>>>>> <after rule="maven.pomFiles">
>>>>>
>>>>> <graph match="MavenPomFileNode" toVar="pomVertexes">
>>>>> <for var="pomV" in="pomVertexes">
>>>>>
>>>>> <xpath toVar="deps" fromFile="${pomV.path}" match="/pom:project/pom:dependencies/pom:dependency"/>
>>>>> <for var="depElement" in="deps">
>>>>> <jaxb toVar="dep" toClass="MavenDepencencyJaxb.groovy" fromElement="depElement" ns="pom ${pomNS}"/>
>>>>> <graph:query toVar="isBlacklisted"
>>>>> q=" /* I don't know Gremlin so far, imagine an equiv of this XPath: */
>>>>> MavenDependencyNode[
>>>>> g=${dep.groupId} and a=${dep.artifactId} and v=${dep.version}
>>>>> ]@blacklisted
>>>>> " />
>>>>> <continue if="isBlacklisted /* var, or Groovy (or EL) expression */" />
>>>>> <!-- This would be useful for blacklists and filters in general, which appear often in real life rules. -->
>>>>>
>>>>> <graph:insertIfNotExists type="MavenDependencyNode" toVar="depVertex>
>>>>> <properties from="dep"/>
>>>>> </graph>
>>>>> <graph:edge type="dependsOn" from="pomV" to="depVertex"/>
>>>>> <!-- Maybe Gremlin could replace this? -->
>>>>> </for>
>>>>> </for>
>>>>> </rule>
>>>>>
>>>>> @XmlRoot
>>>>> class MavenDepencencyJaxb {
>>>>> // GraphKeyProperty identifies those which are compared for insertIfNotExists.
>>>>> @GraphKeyProperty @XmlXPath("./pom:groupId") String groupId;
>>>>> @GraphKeyProperty @XmlXPath("./pom:artifactId") String artifactId;
>>>>> @GraphKeyProperty @XmlXPath("./pom:version") String version;
>>>>> }
>>>>> ------------------------------------------------------------------
>>>>>
>>>>> As you can see, It creates independent rules which only communicate indirectly through the graph.
>>>>> You can also see how nicely Java classes fit into this, and how Groovy could make this easier.
>>>>>
>>>>> SERVICES INVOCATION
>>>>> Forge UI could be mapped to XML elements. I.e. <aaa foo="bar"/> could invoke command "aaa" with given params.
>>>>> I believe Forge already has this way of input, right?
>>>>>
>>>>> GRAPH OPERATION
>>>>> There would be several <graph:...> operations - CRUD plus some special.
>>>>>
>>>>> EXECUTION FLOW
>>>>> 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>.
>>>>>
>>>>> 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.
>>>>>
>>>>> For more complex logic, users would break the task into multiple rules, storing data into the graph intermediately.
>>>>>
>>>>> I'll check few more visitors to see if this is powerful enough to satisfy all the baneeds.
>>>>>
>>>>>
>>>>> .............................
>>>>>
>>>>> 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 https://docs.google.com/drawings/d/1IMnds3Qu8Wwcf7_mr7NJ9a3YgtcGJ7dejl09EhWl7Vc for illustration.
>>>>>
>>>>> Ondra
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>
>>
>>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev


From bdavis at redhat.com  Fri May  9 13:44:30 2014
From: bdavis at redhat.com (Brad Davis)
Date: Fri, 9 May 2014 13:44:30 -0400 (EDT)
Subject: [windup-dev] Let's replace the GraphVisitor interface concept
	with something generic
In-Reply-To: <536D1350.9030304@redhat.com>
References: <1394105113.162433.1399246253927.JavaMail.zimbra@zmail09.collab.prod.int.phx2.redhat.com>
	<CAEp_U4HyzwzAj2C6Nbf2SQP3NW_TP0xTeOOnDzX8SX5J3dO7LA@mail.gmail.com>
	<181119329.615524.1399302015745.JavaMail.zimbra@redhat.com>
	<5367AE7E.1000505@redhat.com>
	<1485356002.683076.1399310101224.JavaMail.zimbra@redhat.com>
	<536D1350.9030304@redhat.com>
Message-ID: <6B977DA7-E795-44F1-86F1-8CFA44340651@redhat.com>

Cool. 

Brad Davis
Red Hat Consulting
Email: bdavis at redhat.com | c:980.226.7865 |http://www.redhat.com 

> On May 9, 2014, at 1:41 PM, Jess Sightler <jsightle at redhat.com> wrote:
> 
> I'm sorry for not responding sooner... somehow I missed this email earlier.
> 
> Basically I have added a new Type Manager (GraphTypeManager) that 
> augments the TypeField/TypeValue functionality to support the resolution 
> of multiple types. It also uses a addon scanner to avoid the need to 
> hardcode a list of classes for TypedGraphModuleBuilder.
> 
> So far this appears to work will for the windup usecase.
> 
>> On 05/05/2014 01:15 PM, Brad Davis wrote:
>> 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."
>> 
>> com.tinkerpop.frames.modules.typedgraph.TypeField;
>> com.tinkerpop.frames.modules.typedgraph.TypeValue;
>> 
>> 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.
>> 
>> Brad Davis
>> Red Hat Consulting
>> Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
>> 
>> 
>> ----- Original Message -----
>> From: "Jess Sightler" <jsightle at redhat.com>
>> To: windup-dev at lists.jboss.org
>> Sent: Monday, May 5, 2014 11:30:06 AM
>> Subject: Re: [windup-dev] Let's replace the GraphVisitor interface concept with something generic
>> 
>> I think you are not reading this correctly. That's ok, though, as I
>> probably didn't describe it correctly. :) I am talking about supporting
>> types, but supporting them using a model more similar to OWL/RDF than to
>> classical OO-devleopment. In this model, you do not know all of the
>> typing information up front, and instead infer type information as you go.
>> 
>> So, for example, a Vertex may evolve over time to support additional
>> types as more information is learned. For example, the first rule may
>> provide a "File", but it later may become "File and ZipFile", and then
>> ultimately "File and ZipFile and EarFile".
>> 
>> During each step of this evolution it retains all of it's
>> characteristics of the previous step. You can think of it as subclassing
>> if you want, but eventually the Java model of subclassing will mislead
>> you about what this means, as it is not necessary for new types to be
>> subclasses of existing types.
>> 
>> Frames encompasses this concept, and this is the big reason that it uses
>> Interfaces instead of classes, AFAICT.
>> 
>> This document may be helpful as well:
>> http://www.w3.org/TR/sw-oosd-primer/#comparison
>> 
>> 
>>> On 05/05/2014 11:00 AM, Brad Davis wrote:
>>> 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.
>>> 
>>> 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.
>>> 
>>> Brad Davis
>>> Red Hat Consulting
>>> Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com
>>> 
>>> 
>>> ----- Original Message -----
>>> From: "Lincoln Baxter, III" <lincolnbaxter at gmail.com>
>>> To: "Windup-dev List" <windup-dev at lists.jboss.org>
>>> Sent: Monday, May 5, 2014 10:34:28 AM
>>> Subject: Re: [windup-dev] Let's replace the GraphVisitor interface concept with something generic
>>> 
>>> 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.
>>> 
>>> 
>>> On Sun, May 4, 2014 at 7:30 PM, Jess Sightler < jsightle at redhat.com > wrote:
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On May 2, 2014 5:31 PM, Ondrej Zizka < ozizka at redhat.com > wrote:
>>>>> On 2.5.2014 21:17, Lincoln Baxter wrote:
>>>>> Hey Ondra,
>>>>> 
>>>>> I'm moving this discussion to windup-dev at lists.jboss.org - please use windup-dev for all non-confidential development discussion.
>>>>> 
>>>>> 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:
>>>>> 
>>>>> #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.
>>>> That's the purpose. The rules would interfere. Or rather, infer.
>>>> 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.
>>> 
>>> I prefer to think of this in terms of RDF-style classes that operate on the open world assumption: http://en.m.wikipedia.org/wiki/Open_world_assumption
>>> 
>>> 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. :-)
>>> 
>>>> From my research on Friday, I believe that this OWA type model may actually be supported pretty well by Tinkerpop frames.
>>> 
>>> We can discuss further next week, as I am sure the above is insufficient. :-)
>>> 
>>> 
>>> 
>>> 
>>>> 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.
>>>> 
>>>>> #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?
>>>> I didn't find anything related in https://github.com/thinkaurelius/titan/wiki/Titan-Limitations (those type limitations seem to apply on other things). I'll try practically.
>>>>> #3) You asked: "Forge UI could be mapped to XML elements. I.e. <aaa foo="bar"/> could invoke command "aaa" with given params.
>>>>> I believe Forge already has this way of input, right?"
>>>>> 
>>>>> 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.
>>>> 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.
>>>>> #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.
>>>> Yes and no.
>>>> 
>>>> 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,
>>>> IMO, if we don't create something such, we will end up with rules which will be just a thin wrapper around services.
>>>> 
>>>> 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.
>>>> 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.
>>>> In this approach, the second rule would pick up the MavenPomFileNode no matter where it comes from.
>>>> I could have written the example 1:1 but wanted to show this task separation advantage.
>>>> 
>>>> 
>>>>> 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.
>>>> Okay, let's see what we have.
>>>>> 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.
>>>>> 
>>>>> Java first. Then XML (or whatever).
>>>> Hmm. About 4 months ago, it was exactly opposite: XML rules, no Java.
>>>> It was also one of the main reasons to abandon WindRide the XML rules were implemented.
>>>> 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".
>>>> When did this change, and what's the guarantee that it won't change again?
>>>> 
>>>> Ondra
>>>> 
>>>>> ~Lincoln
>>>>> 
>>>>> ________________________________
>>>>> From: "Ondrej Zizka" < ozizka at redhat.com >
>>>>> To: jboss-migration at redhat.com
>>>>> Sent: Thursday, May 1, 2014 12:05:23 AM
>>>>> Subject: Re: Let's replace the GraphVisitor interface concept with something generic
>>>>> 
>>>>> I've put it to this doc so we can edit/comment there.
>>>>> 
>>>>> https://docs.google.com/document/d/1UOihPv_zryFilCb7T0k8992wPUt3YNP4goh9rxTC7ng/edit#
>>>>> 
>>>>> Ondra
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 1.5.2014 04:35, Ondrej Zizka wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> as we discussed before, I'd like to replace the GraphVisitor interface with something generic.
>>>>>> 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.
>>>>>> 
>>>>>> public void visitEjbEntity(EjbEntityFacet entry);
>>>>>> public void visitEjbService(EjbSessionBeanFacet entry);
>>>>>> public void visitMessageDrivenBean(MessageDrivenBeanFacet entry);
>>>>>> public void visitEjbEntity(SpringBeanFacet entry);
>>>>>> ...
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 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:
>>>>>> * replace a node with a subclass, e.g.
>>>>>> FileNode => XmlFileNode => MavenPomNode,
>>>>>> FileNode => JavaFileNode => AnnotationNode
>>>>>> 
>>>>>> * add properties, e.g.
>>>>>> XmlFileNode's "doctype",
>>>>>> ClassNode's "blacklisted"
>>>>>> * connect nodes to them, e.g.
>>>>>> MavenPom ---contains---> MavenDependencyNode
>>>>>> JavaFile --- imports --> [ ClassNode, ClassNode, ... ]
>>>>>> 
>>>>>> This approach would:
>>>>>> * Leverage of Forge modularity (e.g. Maven addon depending on XmlFile addon)
>>>>>> * Improve extendability (no need to squeeze everything into the GraphVisitor interface's methods or extend it)
>>>>>> * Lead to much more straightforward rules implementation - all rules would reduce to:
>>>>>> * matching graph information (Gremlin?)
>>>>>> * using DAO's / Services (for mining data from the files/..., and for writing them during active migration)
>>>>>> 1) Bundled - XPath, AST query, properties, Maven remote fetch, ...
>>>>>> 2) User's: .class packed within the addon or a Groovy class
>>>>>> * writing back to the graph
>>>>>> * rendering pieces of HTML for the report.
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>>> As an example, take e.g. MavenRemoteFetchVisitor. https://github.com/windup/windup/blob/master/engine/rules/impl/src/main/java/org/jboss/windup/engine/visitor/inspector/MavenRemoteFetchVisitor.java
>>>>>> 
>>>>>> All that is doable using few simple building blocks, directed by few lines of a rule like this:
>>>>>> 
>>>>>> ------------------------------------------------------------------
>>>>>> 
>>>>>> <var name="pomNS" val=" http://maven.apache.org/POM/4.0.0 ">
>>>>>> 
>>>>>> Rule 1) which would process all POM files and load the info into the graph.
>>>>>> 
>>>>>> <rule id="maven.pomFiles" desc=" Analyze Maven POM files "
>>>>>> phase="StaticConfigAnalysis">
>>>>>> <graph match="XmlFileNode[doctype=' http://maven.apache.org/POM/4.0.0' ]" toVar="xmls">
>>>>>> <for var="pom" in="xmls">
>>>>>> <graph:replaceSingle ref="pom" with="MavenPomFileNode">
>>>>>> <properties>
>>>>>> <!-- <jaxb> would invoce a call to a Service.
>>>>>> <properties> hander would take returned object's bean props.
>>>>>> toClass would load the class from CL or compile from .groovy coming with the migrator (addon).
>>>>>> -->
>>>>>> <jaxb toClass="PomJaxb.groovy" fromFile="${pom.path}">
>>>>>> <ns name="pom" uri="${pomNS}"/>
>>>>>> </jaxb>
>>>>>> </properties>
>>>>>> </graph>
>>>>>> </for>
>>>>>> </rule>
>>>>>> 
>>>>>> @XmlRoot
>>>>>> class PomJaxb {
>>>>>> @XmlXPath("/pom:project/pom:modelVersion") String modelVersion;
>>>>>> @XmlXPath("/pom:project/pom:name") String name;
>>>>>> @XmlXPath("/pom:project/pom:description" String description;
>>>>>> @XmlXPath("/pom:project/pom:url" String url;
>>>>>> }
>>>>>> 
>>>>>> 
>>>>>> Rule 2) which would load the dependencies and describe them into Nodes and Edges.
>>>>>> 
>>>>>> <rule id="maven.pomDependencies" desc=" Analyze Maven POM file dependencies "
>>>>>> phase="StaticConfigAnalysis">
>>>>>> <after rule="maven.pomFiles">
>>>>>> 
>>>>>> <graph match="MavenPomFileNode" toVar="pomVertexes">
>>>>>> <for var="pomV" in="pomVertexes">
>>>>>> 
>>>>>> <xpath toVar="deps" fromFile="${pomV.path}" match="/pom:project/pom:dependencies/pom:dependency"/>
>>>>>> <for var="depElement" in="deps">
>>>>>> <jaxb toVar="dep" toClass="MavenDepencencyJaxb.groovy" fromElement="depElement" ns="pom ${pomNS}"/>
>>>>>> <graph:query toVar="isBlacklisted"
>>>>>> q=" /* I don't know Gremlin so far, imagine an equiv of this XPath: */
>>>>>> MavenDependencyNode[
>>>>>> g=${dep.groupId} and a=${dep.artifactId} and v=${dep.version}
>>>>>> ]@blacklisted
>>>>>> " />
>>>>>> <continue if="isBlacklisted /* var, or Groovy (or EL) expression */" />
>>>>>> <!-- This would be useful for blacklists and filters in general, which appear often in real life rules. -->
>>>>>> 
>>>>>> <graph:insertIfNotExists type="MavenDependencyNode" toVar="depVertex>
>>>>>> <properties from="dep"/>
>>>>>> </graph>
>>>>>> <graph:edge type="dependsOn" from="pomV" to="depVertex"/>
>>>>>> <!-- Maybe Gremlin could replace this? -->
>>>>>> </for>
>>>>>> </for>
>>>>>> </rule>
>>>>>> 
>>>>>> @XmlRoot
>>>>>> class MavenDepencencyJaxb {
>>>>>> // GraphKeyProperty identifies those which are compared for insertIfNotExists.
>>>>>> @GraphKeyProperty @XmlXPath("./pom:groupId") String groupId;
>>>>>> @GraphKeyProperty @XmlXPath("./pom:artifactId") String artifactId;
>>>>>> @GraphKeyProperty @XmlXPath("./pom:version") String version;
>>>>>> }
>>>>>> ------------------------------------------------------------------
>>>>>> 
>>>>>> As you can see, It creates independent rules which only communicate indirectly through the graph.
>>>>>> You can also see how nicely Java classes fit into this, and how Groovy could make this easier.
>>>>>> 
>>>>>> SERVICES INVOCATION
>>>>>> Forge UI could be mapped to XML elements. I.e. <aaa foo="bar"/> could invoke command "aaa" with given params.
>>>>>> I believe Forge already has this way of input, right?
>>>>>> 
>>>>>> GRAPH OPERATION
>>>>>> There would be several <graph:...> operations - CRUD plus some special.
>>>>>> 
>>>>>> EXECUTION FLOW
>>>>>> 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>.
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>>> For more complex logic, users would break the task into multiple rules, storing data into the graph intermediately.
>>>>>> 
>>>>>> I'll check few more visitors to see if this is powerful enough to satisfy all the baneeds.
>>>>>> 
>>>>>> 
>>>>>> .............................
>>>>>> 
>>>>>> 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 https://docs.google.com/drawings/d/1IMnds3Qu8Wwcf7_mr7NJ9a3YgtcGJ7dejl09EhWl7Vc for illustration.
>>>>>> 
>>>>>> Ondra
>>> 
>>> _______________________________________________
>>> windup-dev mailing list
>>> windup-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/windup-dev
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
> 
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140509/e1d0de5e/attachment-0001.html 

From lincolnbaxter at gmail.com  Fri May  9 17:48:32 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Fri, 9 May 2014 17:48:32 -0400
Subject: [windup-dev] WindUp/engine/graph/addon is empty?
In-Reply-To: <536D0A5E.9030001@redhat.com>
References: <536A1870.107@redhat.com>
	<CAEp_U4HxW3-2SGLGuVWvdSRhCnVUsUxP_VLEFZB--P9wZ47Kgw@mail.gmail.com>
	<536D0A5E.9030001@redhat.com>
Message-ID: <CAEp_U4G+nAj+ZLj9=bkhHF82rKP=Z-3xN1+kCpZACR+Lx3APBw@mail.gmail.com>

They could go there, yes. There or the IMPL. there's no real difference
between the two. Most of the time in forge this module just remains empty.


On Fri, May 9, 2014 at 1:03 PM, Jess Sightler <jsightle at redhat.com> wrote:

>  Is this where UIWizard and forge command will go as well?
>
>
> On 05/09/2014 10:41 AM, Lincoln Baxter, III wrote:
>
> It's necessary as a classified POM artifact for Furnace addon-manager to
> pick up. If we were not using the "exploded" project layout, this is where
> the code would be.
>
>
> On Wed, May 7, 2014 at 7:26 AM, Ondrej Zizka <ozizka at redhat.com> wrote:
>
>> Hi,
>>
>> what is $SUBJ good for? It's a jar artifact, but has no code nor tests.
>>
>> Shall we remove that?
>>
>> Ondra
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>
>
>
>
>  --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
>
> _______________________________________________
> windup-dev mailing listwindup-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140509/69049a71/attachment.html 

From ozizka at redhat.com  Sun May 11 20:36:48 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Mon, 12 May 2014 02:36:48 +0200
Subject: [windup-dev] WindUp/engine/graph/addon is empty?
In-Reply-To: <CAEp_U4HxW3-2SGLGuVWvdSRhCnVUsUxP_VLEFZB--P9wZ47Kgw@mail.gmail.com>
References: <536A1870.107@redhat.com>
	<CAEp_U4HxW3-2SGLGuVWvdSRhCnVUsUxP_VLEFZB--P9wZ47Kgw@mail.gmail.com>
Message-ID: <537017A0.2090802@redhat.com>

And is the

WindUp/engine/graph/addon/src/main/java/org/jboss/windup/addon/package-info.java

needed? Or was it just generated by some IDE...



On 9.5.2014 16:41, Lincoln Baxter, III wrote:
> It's necessary as a classified POM artifact for Furnace addon-manager 
> to pick up. If we were not using the "exploded" project layout, this 
> is where the code would be.
>
>
> On Wed, May 7, 2014 at 7:26 AM, Ondrej Zizka <ozizka at redhat.com 
> <mailto:ozizka at redhat.com>> wrote:
>
>     Hi,
>
>     what is $SUBJ good for? It's a jar artifact, but has no code nor
>     tests.
>
>     Shall we remove that?
>
>     Ondra
>     _______________________________________________
>     windup-dev mailing list
>     windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
>
> -- 
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140512/1f05df99/attachment.html 

From ozizka at redhat.com  Sun May 11 21:03:02 2014
From: ozizka at redhat.com (Ondrej Zizka)
Date: Mon, 12 May 2014 03:03:02 +0200
Subject: [windup-dev] Decompilers results, Jad
Message-ID: <53701DC6.6080708@redhat.com>

Hi Brad,

I've tried Procyon, Jad, and CFR.
The results are in WINDUP-50 and subtasks.

I wanted to ask - Jad tells me it doesn't support .class v50 even if I 
run JadRetro before.
Also, this only happens for just 25 classes out of 1200.
Seems like the JadRetro failed to transform or such.
Have you also observed this? Any tip how to improve?

Thanks,
Ondra

From jsightle at redhat.com  Mon May 12 09:18:52 2014
From: jsightle at redhat.com (Jess Sightler)
Date: Mon, 12 May 2014 09:18:52 -0400
Subject: [windup-dev] WindUp/engine/graph/addon is empty?
In-Reply-To: <537017A0.2090802@redhat.com>
References: <536A1870.107@redhat.com>	<CAEp_U4HxW3-2SGLGuVWvdSRhCnVUsUxP_VLEFZB--P9wZ47Kgw@mail.gmail.com>
	<537017A0.2090802@redhat.com>
Message-ID: <5370CA3C.1040500@redhat.com>

If nothing else, it keeps git from auto-purging the (otherwise empty) 
folder. I'm not sure what else it accomplishes as an auto-generated 
(empty) file.

On 05/11/2014 08:36 PM, Ondrej Zizka wrote:
> And is the
>
> WindUp/engine/graph/addon/src/main/java/org/jboss/windup/addon/package-info.java
>
> needed? Or was it just generated by some IDE...
>
>
>
> On 9.5.2014 16:41, Lincoln Baxter, III wrote:
>> It's necessary as a classified POM artifact for Furnace addon-manager 
>> to pick up. If we were not using the "exploded" project layout, this 
>> is where the code would be.
>>
>>
>> On Wed, May 7, 2014 at 7:26 AM, Ondrej Zizka <ozizka at redhat.com 
>> <mailto:ozizka at redhat.com>> wrote:
>>
>>     Hi,
>>
>>     what is $SUBJ good for? It's a jar artifact, but has no code nor
>>     tests.
>>
>>     Shall we remove that?
>>
>>     Ondra
>>     _______________________________________________
>>     windup-dev mailing list
>>     windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/windup-dev
>>
>>
>>
>>
>> -- 
>> Lincoln Baxter, III
>> http://ocpsoft.org
>> "Simpler is better."
>>
>>
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140512/9e648d4e/attachment.html 

From lincolnbaxter at gmail.com  Mon May 12 11:45:07 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Mon, 12 May 2014 11:45:07 -0400
Subject: [windup-dev] WindUp/engine/graph/addon is empty?
In-Reply-To: <5370CA3C.1040500@redhat.com>
References: <536A1870.107@redhat.com>
	<CAEp_U4HxW3-2SGLGuVWvdSRhCnVUsUxP_VLEFZB--P9wZ47Kgw@mail.gmail.com>
	<537017A0.2090802@redhat.com> <5370CA3C.1040500@redhat.com>
Message-ID: <CAEp_U4FtBPKhkW1AcuaiG=VzLeaVqdirawPimZedgaOJEapjsQ@mail.gmail.com>

It keeps various plugins in Maven from complaining about creating empty
archives or processing empty archives during the release process.


On Mon, May 12, 2014 at 9:18 AM, Jess Sightler <jsightle at redhat.com> wrote:

>  If nothing else, it keeps git from auto-purging the (otherwise empty)
> folder. I'm not sure what else it accomplishes as an auto-generated (empty)
> file.
>
>
> On 05/11/2014 08:36 PM, Ondrej Zizka wrote:
>
> And is the
>
>
> WindUp/engine/graph/addon/src/main/java/org/jboss/windup/addon/package-info.java
>
> needed? Or was it just generated by some IDE...
>
>
>
> On 9.5.2014 16:41, Lincoln Baxter, III wrote:
>
> It's necessary as a classified POM artifact for Furnace addon-manager to
> pick up. If we were not using the "exploded" project layout, this is where
> the code would be.
>
>
> On Wed, May 7, 2014 at 7:26 AM, Ondrej Zizka <ozizka at redhat.com> wrote:
>
>> Hi,
>>
>> what is $SUBJ good for? It's a jar artifact, but has no code nor tests.
>>
>> Shall we remove that?
>>
>> Ondra
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>
>
>
>
>  --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
>
> _______________________________________________
> windup-dev mailing listwindup-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
>
> _______________________________________________
> windup-dev mailing listwindup-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140512/fec288c4/attachment-0001.html 

From lincolnbaxter at gmail.com  Mon May 12 11:45:28 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Mon, 12 May 2014 11:45:28 -0400
Subject: [windup-dev] WindUp/engine/graph/addon is empty?
In-Reply-To: <CAEp_U4FtBPKhkW1AcuaiG=VzLeaVqdirawPimZedgaOJEapjsQ@mail.gmail.com>
References: <536A1870.107@redhat.com>
	<CAEp_U4HxW3-2SGLGuVWvdSRhCnVUsUxP_VLEFZB--P9wZ47Kgw@mail.gmail.com>
	<537017A0.2090802@redhat.com> <5370CA3C.1040500@redhat.com>
	<CAEp_U4FtBPKhkW1AcuaiG=VzLeaVqdirawPimZedgaOJEapjsQ@mail.gmail.com>
Message-ID: <CAEp_U4FFz1esddE4dWN8CQ_a+x3AAYLuLpca1d16oVy34t3gyQ@mail.gmail.com>

It's possible there is another workaround, but I don't remember the exact
issues.


On Mon, May 12, 2014 at 11:45 AM, Lincoln Baxter, III <
lincolnbaxter at gmail.com> wrote:

> It keeps various plugins in Maven from complaining about creating empty
> archives or processing empty archives during the release process.
>
>
> On Mon, May 12, 2014 at 9:18 AM, Jess Sightler <jsightle at redhat.com>wrote:
>
>>  If nothing else, it keeps git from auto-purging the (otherwise empty)
>> folder. I'm not sure what else it accomplishes as an auto-generated (empty)
>> file.
>>
>>
>> On 05/11/2014 08:36 PM, Ondrej Zizka wrote:
>>
>> And is the
>>
>>
>> WindUp/engine/graph/addon/src/main/java/org/jboss/windup/addon/package-info.java
>>
>> needed? Or was it just generated by some IDE...
>>
>>
>>
>> On 9.5.2014 16:41, Lincoln Baxter, III wrote:
>>
>> It's necessary as a classified POM artifact for Furnace addon-manager to
>> pick up. If we were not using the "exploded" project layout, this is where
>> the code would be.
>>
>>
>> On Wed, May 7, 2014 at 7:26 AM, Ondrej Zizka <ozizka at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> what is $SUBJ good for? It's a jar artifact, but has no code nor tests.
>>>
>>> Shall we remove that?
>>>
>>> Ondra
>>> _______________________________________________
>>> windup-dev mailing list
>>> windup-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>>
>>
>>
>>
>>  --
>> Lincoln Baxter, III
>> http://ocpsoft.org
>> "Simpler is better."
>>
>>
>> _______________________________________________
>> windup-dev mailing listwindup-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/windup-dev
>>
>>
>>
>>
>> _______________________________________________
>> windup-dev mailing listwindup-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/windup-dev
>>
>>
>>
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
>>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140512/3545c8b6/attachment.html 

From lincolnbaxter at gmail.com  Wed May 28 17:12:22 2014
From: lincolnbaxter at gmail.com (Lincoln Baxter, III)
Date: Wed, 28 May 2014 17:12:22 -0400
Subject: [windup-dev] Example Windup Report
Message-ID: <CAEp_U4GTZUSSVmUkyYQSF5qRFPLQKi6YBmO0VWdku2YeTTT-mw@mail.gmail.com>

Example Windup Report

---------- Forwarded message ----------
From: Brad Davis <bdavis at redhat.com>
Date: Wed, May 28, 2014 at 4:12 PM
Subject: Report
To: Lincoln Baxter <lbaxter at redhat.com>, "Lincoln Baxter, III" <
lincolnbaxter at gmail.com>


Report

Brad Davis
Red Hat Consulting
Email: bdavis at redhat.com | c: 980.226.7865 | http://www.redhat.com





-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140528/b3b289f1/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: windup-2-output.zip
Type: application/zip
Size: 1091932 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/windup-dev/attachments/20140528/b3b289f1/attachment-0001.zip 

From jsightle at redhat.com  Thu May 29 15:59:43 2014
From: jsightle at redhat.com (Jess Sightler)
Date: Thu, 29 May 2014 15:59:43 -0400
Subject: [windup-dev] groovy closures syntax example
Message-ID: <538791AF.6030608@redhat.com>

Attached...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: helloworlddsl.zip
Type: application/zip
Size: 24535 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/windup-dev/attachments/20140529/6915786e/attachment-0001.zip