Query.find(ArchiveModel.class)Windup User Guide
-
+
- Available Rule Utilities
- Review the Windup Quickstarts
- Known Issues
- Glossary of Terms Used in Windup @@ -482,6 +483,8 @@
- Appendix
Windup User Guide
How can you help?
Try Windup on your application. Be sure to report any issues you encounter.
+Try Windup on your application. Be sure to report any issues you encounter.
Write an Windup rule to automate the migration process.
@@ -1319,7 +1322,7 @@Rule Provider Execution Report
Individual File Analysis Reports
-
You can directly access the the file analysis report pages described above by browsing for them by name in the OUTPUT_REPORT_DIRECTORY/reports/ directory. Because the same common file names can exist in multiple archives, for example "manifest.mf" or "web.xml", Windup adds a unique numeric suffix to each report file name.
You can directly access the the file analysis report pages described above by browsing for them by name in the OUTPUT_REPORT_DIRECTORY/reports/ directory. Because the same common file names can exist in multiple archives, for example "manifest.mf" or "web.xml", Windup adds a unique numeric suffix to each report file name.
Metadata
Available utilities
For a list of what key services and constructs can be used in the rule, -see Available Rules Utilities.
+see Available Rules Utilities.Create the XML Rule
<ruleset>: This element defines this as a Windup rule.
<phase>: This element specifies when the ruleset should execute. See Rule Phases in the Rule Execution Lifecyle for more information.
+<phase>: This element specifies when the ruleset should execute. See Rule Execution Lifecyle for more information about rule phases.
<rules>: element contains the individual rules.
@@ -2898,7 +2901,7 @@Rule Provider Execution Report
Individual File Analysis Reports
-
You can directly access the the file analysis report pages described above by browsing for them by name in the OUTPUT_REPORT_DIRECTORY/reports/ directory. Because the same common file names can exist in multiple archives, for example "manifest.mf" or "web.xml", Windup adds a unique numeric suffix to each report file name.
You can directly access the the file analysis report pages described above by browsing for them by name in the OUTPUT_REPORT_DIRECTORY/reports/ directory. Because the same common file names can exist in multiple archives, for example "manifest.mf" or "web.xml", Windup adds a unique numeric suffix to each report file name.
Classloading Problems
Additional Resources
+
+Available Rule Utilities
+
+
+Programmatically Access the Graph
+
+
+Note: Needs update. This is out of date!
+
+
+(Lower Level API, to cover cases not provided by high level API)
+
+
+This topic describes how to to programmatically access or update graph data when you create a Java-based rule addon.
+
+
+Query the graph
+
+
+There are several ways - including Query API, Gremlin support, or +GraphService methods.
+
+
+Query the Graph Within the .when() method
+
+
+Building a rule contains the method when(), which is used to create a +condition. Vertices that fulfill the condition, are passed to the +perform() method.
+
+
+For the queries in the when() method, class Query is used. There are +several methods which you can use to specify the condition. For example: +* find() specifies the Model type of the vertex * as() method +specifies the name of the final list, that is passed to the perform() +method * from(String name) starts the query not on the all vertices, +but only on the vertices already stored in the the given name (used to +begin query on the result of the other one) * withProperty() specify +the property value of the given vertex
+
+
+The following are examples of simple queries.
+
+
+Return a list of archives
+
+
+
+
+
+
+
+
+Query.find(ApplicationReportModel.class).as(VAR_APPLICATION_REPORTS)
+
+Iteration
+
+
+
+
+ConfigurationBuilder.begin().addRule()
+ .when(
+ GraphSearchConditionBuilderGremlin.create("javaFiles", new ArrayList())
+ .V().framedType( JavaFileModel.class ).has("analyze")
+ )
+ .perform(
+ // For all java files...
+ Iteration.over("javaFiles").var("javaFile").perform(
+
+Nested Iteration
+
+
+
+
+code,java
+// For all java files...
+Iteration.over("javaFiles").var("javaFile").perform(
+ // A nested rule.
+ RuleSubset.evaluate(
+ ConfigurationBuilder.begin().addRule()
+ .when(...)
+ .perform(
+ Iteration.over("regexes").var(RegexModel.class, "regex").perform(
+ new AbstractIterationOperator<RegexModel>( RegexModel.class, "regex" ) {
+ public void perform( GraphRewrite event, EvaluationContext context, RegexModel regex ) {
+ //...
+ }
+ }
+ )
+ .endIteration()
+ )// perform()
+ )
+)
+
+Modify Graph Data
+
+
+For more custom operations dealing with Graph data that are not covered by the Query mechanism, use the GraphService.
+
+
+
+GraphService<FooModel> fooService = new GraphService<FooModel>(graph,FooModel.class);
+
+List<FooModel> = fooService.findAll();
+FooModel = fooService.create();
+
+// etc ...
+
+GraphService<> can also be used to query the graph for models of the specified type:
+
+
+
+
+FooModel foo = new GraphService<>(graphContext, FooModel.class).getUnique();
+
+
+
+FooModel foo = new GraphService<>(graphContext, FooModel.class).getUniqueByProperty("size", 1);Review the Windup Quickstarts
The Windup quickstarts provide working examples of how to create custom Java-based rule addons and XML rules. You can use them as a starting point for creating your own custom rules. The quickstarts are available on GitHub here: https://github.com/windup/windup-quickstarts
@@ -3408,12 +3537,206 @@OCPsoft Rewrite
+
+Dependencies (Forge add-ons)
+
+
+DRAFT Based on +this +discussion.
+
+
+Maven Add-on Structure
+
+
+The following is the typical structure of Maven add-on modules.
+
+
+
+myaddon-parent ++--- myaddon - jar, classifier: forge-addon ++--- myaddon-api - jar ++--- myaddon-impl - jar ++--- myaddon-tests - jar+
+
+The add-on POM file can declare dependencies on other forge-addons.
+To prevent exporting the add-on to dependent modules, use <optional>true</optional>.
+
+
+
+<dependency>
+ <groupId>org.jboss.forge.furnace.container</groupId>
+ <artifactId>cdi</artifactId>
+ <classifier>forge-addon</classifier>
+ <optional>true</optional>
+</dependency>
+
+The add-on POM files may also declare a dependency on typical Maven artifacts.
+To prevent exporting the add-on to dependent modules, use <optional>true</optional>.
+
+
+
+<dependency>
+ <groupId>com.thinkaurelius.titan</groupId>
+ <artifactId>titan-lucene</artifactId>
+ <version>${version.titangraph.lucene}</version>
+</dependency>
+
+One more question regarding dependencies. Is it advisable to depend on the`forge-addon` +artifact from add-on’s subparts?
+
+
+Add-ons should reference the <classifier>forge-addon</classifier>
+artifact from other add-ons.
+
+Add-on sub-parts
+
+
+Add-on sub-parts declare dependency preferably on forge add-on APIs, not
+on the add-ons themselves, wherever possible (wherever an add-on has an
+explicit API). These dependencies must be marked as provided scope.
+
+
+
+<dependency>
+ <groupId>org.jboss.forge.furnace.container</groupId>
+ <artifactId>cdi-api</artifactId>
+ <classifier>forge-addon</classifier>
+ <scope>provided</scope>
+</dependency>
+
+They may instead depend on the primary add-on dependency, e.g.
+forge-addon. The latter makes the POM files simpler, but can be confusing,
+because the add-on dependency still needs to be declared in the depending
+add-on’s POM.
+
+
+
+<dependency>
+ <groupId>org.jboss.forge.furnace.container</groupId>
+ <artifactId>cdi-api</artifactId>
+</dependency>
+
+Declaring a forge-addon depencendy anywhere else than the
+forge-addon pom doesn’t actually cause Furnace to establish an add-on
+dependency. I.e. classes from the dep won’t be available unless you
+declare it in the `forge-addon’s pom.
+
+Add-on’s sub-parts may also declare dependencies on other normal maven +dependencies, and these are treated as normal.
+
+
+
+
+|
+ Note
+ |
+
+
+
+Add-on depends on API , scope |
+
+
+Test dependencies
+
+
+For test dependencies on add-ons: Any addon/sub-part requiring an addon
+for testing purposes should use <scope>test</scope>.
+
+
+
+<dependency>
+ <groupId>org.jboss.windup.graph</groupId>
+ <artifactId>windup-graph</artifactId>
+ <version>${project.version}</version>
+ <classifier>forge-addon</classifier>
+ <scope>test</scope>
+</dependency>
+
+Dependencies between sub-parts within the same add-on
+
+
+Subpart may declare dependency on other subpart. E.g. impl typically
+depends on api. In that case, the scope should be set appropriately
+for the given situation - typically provided or compile scope.
+
+
+
+<dependency>
+ <groupId>org.jboss.windup.graph</groupId>
+ <artifactId>windup-graph-api</artifactId>
+ <scope>compile</scope>
+</dependency>
+
Windup Models
+
+
+Windup models are the classes extending WindupVertexFrame. +They are used to model the data in the graph database to Java objects.
+
+
+This is an overview of the most important models. +The complete and up-to-date list of models is in Javadoc.
+
+
+
+
+Meta Models
+
+
+-
+
-
+
User input
+
+ -
+
Rules and Rule Providers metadata
+
+
+
+Core Models
+
+
+FileModel ArchiveModel
+
+
+Reporting Models
+ +
+
+Custom Models (coming from Addons)
+
+
+See respective ruleset’s documentation.
+