[jboss-jira] [JBoss JIRA] Commented: (JBRULES-1945) Migrating version 4 graphical ruleflows to version 5 in Eclipse plugin and the Guvnor

[ https://jira.jboss.org/jira/browse/JBRULES-1945?page=com.atlassian.jira.p... ] Shahad Ahmed commented on JBRULES-1945: --------------------------------------- I've created a patch (attachment ruleflow_migratory.zip) that adds more support for migrating drools version 4 ruleflows to drools version 5, including full support in the Guvnor and Eclipse plugin as well! The patch also fixes a number of bugs in the existing ruleflow support. The existing support for version 4 ruleflows allows .rfm (i.e. non-graphical) ruleflow files to be compiled if the drools.ruleflow.port property is set. The following patch extends support for ruleflow migration into the Guvnor and Eclipse Plugin to allow graphical ruleflows (.rf files) to be migrated and viewed. I've detailed the headline enhancement/fixes immediately below, and there's a full list of all the file changes, with more details of the modifications further below. I hope this will allows existing version 4 users a more seamless upgrade path to drools 5 from their existing drools 4 packages that use ruleflows. Headline Fixes/Modifications ----------------------------------- The patch adds the following enhancements and bug fixes: 1. Improves the current XSL transformation of version 4 .rfm ruleflow files to also migrate import and global definition in split, join nodes etc into the header tag of the version 5 ruleflow. Also migrates the ruleflow version attribute. 2. Fixes bug in the existing ruleflow migration in the compiler where existing version 5 ruleflows will not be added to a compilation package if the drools.ruleflow.port property is set to allow migration. 3. Allows drools version 4 .rf (graphical) ruleflow files to be opened and viewed as graphical ruleflows in the drools version 5 Eclipse plugin! The graphical ruleflow is migrated from version 4 to 5 (bendpoint and all), with a dialog telling the user that the transformation has occurred but not saved, so the user can back out. 4. Enhanced Guvnor to migrate existing drools v4 .rfm (non graphical) ruleflow assets to drools 5 ruleflow assets and allow them to be opened in the Guvnor! The migration only occurs if the drools.ruleflow.port property is set (as a VM argument , in the case of the Guvnor). 5. Fixes bug were drools 4 ruleflow assets in an existing repository cannot be opened in the Guvnor when a repository is "Auto" migrated from v4 to 5. Nor can you perform any operations on these assets like archive, save etc as a NullPointerException is thrown on the server. They are effectively stuck in their repository packages - this bug has been fixed in the patch Detailed Description of New/Modified Files and Changes ----------------------------------------------------------------------- There are 10 files in the patch with 7 modifications of existing files and 3 new files. The patch is attached as a zip that unzips with a directory structure equivalent to the trunk, but only contains the 10 files. The modified/new files are listed below together with a summary of the changes. Where possible, I have added a comment with the text " Migrate v4 ruleflows to v5" near any changes in existing files. COMPILER 1. drools-compiler\src\main\java\org\drools\xml\processes\RuleFlowMigrator.java NEW utility class that contains all the methods required to transform drools 4 .rf and .rfm ruleflow xml format to drools 5 .rf format. This class copies and extends the original methods in ProcessBuilder that migrated version 4 .rfm files to version 5 during a rules compilation. I decided to create this separate utility class, as the Eclipse plugin and the Guvnor will also access the methods here. This class also has a simple main class that allows it to transform version 4 .rf files in case anyone want to use it stand alone via the command line. BUG FIX: Note this class also fixes a bug I found in the original ruleflow migration code in portToCurrentVersion in ProcessBuilder. The original code read the input Reader parameter to create a string version of its xml contents using the convertReaderToString method. If the xml was found to be already a version 5 ruleflow then the original Reader object was returned as the result with the intention that the ruleflow and hence the original Reader were not modified - however the act of reading the Reader means that it content will have been exhausted and any subsequent use of this allegedly "unmodified" reader will return no content. This bug manifests if you set the drools.ruleflow.port property true to allow the compiler to migrate v4 ruleflows, and you try and compile a package containing a version 5 ruleflow - the version 5 ruleflow is essentially treated as an empty file as the contents of its Reader have already been read. 2. drools-compiler\src\main\java\org\drools\compiler\ProcessBuilder.java MODIFIED portToCurrentVersion method to allow the use of both version 4.rfm and .rf ruleflows files as part of a package. As before, migration only occurs if the system property drools.ruleflow.port is true. The class has also been re-factored to use the migration methods/classes from RuleFlowMigrator, and duplicate code in this class has been removed. 3. drools-compiler\src\main\resources\org\drools\xml\processes\RuleFlowGraphicalFrom4To5.xsl NEW file containing an XSL definition that migrates drools 4 .rf (graphical ruleflow) xml files to version 5. The migration preserves all node positions and bendpoints, imports, globals etc. 4. drools-compiler\src\main\resources\org\drools\xml\processes\RuleFlowFrom4To5.xsl MODIFIED to also migrate import and global definitions that might be declared inside split, join and other nodes. Also migrates the ruleflow version attribute as well now. Recall this XSL only migrates .rfm (non-graphical) rulefule xml. GUVNOR 5. drools-guvnor\src\main\java\org\drools\guvnor\server\repository\BRMSRepositoryConfiguration.java MODIFIED the create method to perform a full migration of all version 4 Ruleflow assets in the repository using the methods in Migrate Repository. Migration only occurs if drools.ruleflow.port system property is true. 6. drools-guvnor\src\main\java\org\drools\guvnor\server\repository\MigrateRepository.java NEW utility class that migrates all the version 4 .rfm (and .rf) ruleflow assets in a Guvnor repository to version 5 .rf ruleflow. Previously if you imported, or already had existing version 4 ruleflow assets into the Guvnor, you would not be able to open them. Also, any attempted operations on the assets (e.g. archive, save etc) resulted in a NullPointerException on the server. When a ruleflow asset is migrated, it is checked-in as a new version of the existing asset, with a description that it has been auto-migrated from drools 4 to 5 by the admin user. Note that although the .rfm (non graphical) ruleflows are migrated to version 5, the version 5 ruleflow will have no coordinates for nodes on the flow (i.e. no layout info, as v4 .rfm files did not have any), so when you open the flow, all the nodes are on top of each other - but at least you can open it now. I did consider using the vertical ruleflow layout code in the eclipse plugin to add layout details, but that would involve adding some eclipse libraries to the Guvnor, so I left that as a fairly straightforward enhancement for the future by using the code in the VerticalAutoLayoutAction class in the Guvnor - users can always export the migrated .rf and import it into Eclipse, apply the auto-layout and import it back into the Guvnor as well. 7. drools-guvnor\src\main\java\org\drools\guvnor\server\files\FileManagerUtils.java MODIFIED importRulesRepository and importPackageToRepository to migrate the ruleflows in any imported repository or package 8. drools-guvnor\src\main\java\org\drools\guvnor\server\contenthandler\RuleFlowHandler.java BUG FIX by adding some null value checks in storeAssetContent. Before this fix, any attempt to move, save etc on a drools 4 ruleflow asset in a migrated repository caused a NullPointerException on the server. This Fix along with the fix in RuleFlowContentModelBuilder.java below fixes this issue. Note that there are also small changes in storeAssetContent and retreiveAssetContent that leave the old drools 4 .rfm asset in the repository if it cannot be migrated for any reason - this way at least the existing package can still be built (assuming the drools.ruleflow.port property is set true). 9. drools-guvnor\src\main\java\org\drools\guvnor\server\builder\RuleFlowContentModelBuilder.java BUG FIX in createNodesAndConnection method by adding guards to check for null values before setting the X and Y coordinates of a node. I figured this was an omission, as setting the node sizes has null-check guards. This fix allows the Guvnor to open migrated .rfm to .rf ruleflow assets that will not have node size or coordinate data in their xml definition. ECLIPSE-PLUGIN 10. drools-eclipse\org.drools.eclipse\src\main\java\org\drools\eclipse\flow\ruleflow\editor\RuleFlowModelEditor.java MODIFIED createModel method to allow the opening of version 4 .rf (Graphical) ruleflow files. The version 4 ruleflow is converted to a version 5 ruleflow model using the RuleFlowMigrator class. This allows the version 4 .rf ruleflow to be viewed and modified graphically using the drools 5 eclipse plug-in. Note that the underlying version 4 file is not modified by the migration. Instead a warning dialog is displayed to tell the user they're opening a drools 4 .rf and that any changes they make to the ruleflow will be saved in drools 5 format (i.e. backwards compatibility with drools 4 will be lost if they save). I suppose there may be a better solution than this, but I wanted to avoid changing any user files without first warning the user. Shahad -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira