Windup API for Eclipse Plugin Suggesitons
by Ian Tewksbury
All,
Pete asked me to send out some of the ideas I have had about what the Eclipse plugin would like to see from the Windup core project as far as API goes.
ProgressMonitor
I would suggest basing this off the Eclipse IProgressMonitor API. I do not think it would make sense to actually use the Eclipse API because then Windup would be dependent on Eclipse. But if Windup had a similar interface I could use it to convert form a Windup ProgressMonitor to an Eclipse IProgressMonitor and report status back to the user. For Windup's long running actions this is very important.
WinupdEngine
I think it is important a single instance of the Windup Engine is reusable and can be run multiple times on the same project or on different projects. But if for whatever reason it is only one time use only that needs to be well documented in the API. Currently with legacy windup I only create one copy of the Engine
WindupEngine#setSettings(WindupEnvironment env) - set the windup options
WindupEngine#process(File parentProject, ProgressMonitor monitor) - runs windup on a parent folder and generates all the metadata
WindupEngine#generateReport(File parentProject, ProgressMonitor monitor) - generates a windup report based on all the metadata that is created by the #process(File parentFolder). This could either error out if the parentFolder has not yet been processed or could automatically process it
WindupEngine#getRuleMatches(File file) - Should return a list of RuleMatch objects, one for every rule match on a given file that can then be used to access any needed information about that rule match determined from all of the generated metadata
RuleMatch
This should be the class that is used to give API users all the information that was determined about a given resource. I would suggest most of this information if not all of it be lazily loaded and not pre populated. I do not know what your plan is for the storage of the windup model you will build on a given project. I hope there is some plan to not just keep it all in memory all the time and there will be some sort of file backend. An application like Eclipse is already a memory hog, to have to store the possibly infinite size of the windup model for all the projects in the workspace in memory all the time could get way out of proportion quickly. My suggestion would be this model would get saved to disk and then classes like the RuleMatch could query the model which would in turn query the disk for information. At the very least if the model is not saved to disk, then at least text and description from rules should only be loaded from disk when requested. So when loading a custom rule you have to load the matcher from disk as you process, but no need to load the description or other information until someone actually requests it, and even then that information should not be kept in memory by windup when requested, it should be returned and forgotten. I could go on an on on this subject, and it maybe a topic for another email or discussion at some point, but wanted to lay down some of my suggestions as it relates to this API.
I would also assume that the report generator for Winup would be using this same API to generate the report. I see the Windup Report generator and the Eclipse plugin as siblings, both using the same API to display the same information in different ways.
RuleMatch#getTitle() - a short description title of the match
RuleMatch#getLongDescription() - a more verbose description of the match. this could possible contain some level of markup/simple html for basic formatting
RuleMatch#getAdditionalReadingLinks() - returns list of links to externally extensible information relevant to the match
RuleMatch#getLocation() - returns a location object that will contain the line number and character start and end locations on that line of the match. If the match if for the entire file there should be some way of describing that as well.
RuleMatch#getCategory() - I am guessing rules will be provided in sets, JEE, WebSphere, Wildfly, or something that groups rules together in logical sets, this would be nice for reporting
RuleMatch#getSeverity() - I would suggest a three level system, info, warning, error.
RuleMatch#getFix() - Should return a block of text that can replace the matched block of text as a quick fix for the match. If you want to get really fancy these fixes should be able to match on parts of the match and inject them into the quick fix block. EX: if replacing one method call with another and there are parameters being passed the fix should be able to have some way of referencing those parameters so it can use them in its fix. This would all have to be done on the Windup side and likely all programmaticly by giving the rule writers access to the source they matched on so they can parse it for use in their fix code
----------------------
That is all I can think of for now. I hope this helps describe the kind of things Eclipse will be looking for in terms of API.
Blue Skies,
~Ian
10 years, 6 months
New branch - Modularize-03
by Ondrej Zizka
Hi,
1) merging didn't work for me (too many conflicts at once), so I
rebased, but instead of force push, I created a new branch, which is
current master + Modularize_new.
Is that git process ok for all?
2) Can we merge this into master now?
Regards,
Ondra
10 years, 6 months
Windup Meeting minutes 2014-06-11
by Lincoln Baxter, III
===============
#windup Meeting
===============
Meeting started by lincolnthree at 13:56:14 UTC.
Meeting summary
---------------
* Agenda (lincolnthree, 13:56:31)
* Groovy Rules (lincolnthree, 13:59:24)
* no technical barriers have become apparent (lincolnthree, 13:59:59)
* Eclipse Plugin (lincolnthree, 14:09:19)
* Exposing Furnace Runtime to Windup Eclipse addon is probably the way
to go. Will keep thinking and revisit if necessary (lincolnthree,
14:22:41)
* POMs and Logging (lincolnthree, 14:22:45)
* Lincoln is debugging through some POM/structure build issues while
working through the logging fixes (lincolnthree, 14:29:56)
* Sample project source code (lincolnthree, 14:31:53)
* AGREED: ozizka will move the sample apps to new github repo
(ozizka, 14:40:36)
* Next steps for everyone (lincolnthree, 14:42:41)
* I plan on finishing the logging refactor and pom cleanup
(lincolnthree, 14:43:04)
* I plan to finish up the dynamic groovy loading (a unit test for the
loader and some improvements to the graph sorter unit test at a
minium) (jsightler, 14:44:01)
* Then I plan to move on to blacklist work (jsightler, 14:44:13)
* Creating the basic windup rules in current framework (ozizka,
14:45:04)
* Check the legacy api for the plugin and create generic one if the
current is not generic enough. (ozizka, 14:46:11)
Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup....
Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup....
Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup....
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
10 years, 6 months
org.springframework.context.ApplicationContext
by Ian Tewksbury
Windup Team,
I am trying to get the Windup Eclipse plugin to work with Windup 2.0 using Forge. The latest issue I am running into is that Eclipse can not find org.springframework.context.ApplicationContext. For that matter I can not find it either. I searched my workspace that has windup, windup-eclipse-plugin, and jboss-forge, and none of the included plugins or library jars seem to have this class. By which magic does Windup normally load this class? I need to figure out how Windup loads the class so I can load it via the plugin as well.
java.lang.NoClassDefFoundError: org/springframework/context/ApplicationContext
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2493)
at java.lang.Class.getConstructor0(Class.java:2803)
at java.lang.Class.getConstructor(Class.java:1718)
at org.jboss.forge.furnace.proxy.Proxies.isInstantiable(Proxies.java:414)
at org.jboss.forge.furnace.proxy.ProxyTypeInspector.getCompatibleClassHierarchy(ProxyTypeInspector.java:40)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.enhanceResult(ClassLoaderAdapterCallback.java:240)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.access$300(ClassLoaderAdapterCallback.java:34)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback$2.call(ClassLoaderAdapterCallback.java:117)
at org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:34)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.invoke(ClassLoaderAdapterCallback.java:89)
at org.jboss.windup.WindupFactory_$$_javassist_c87c990c-13e3-487b-a158-b4143a8407b5.createWindupEngine(WindupFactory_$$_javassist_c87c990c-13e3-487b-a158-b4143a8407b5.java)
at org.jboss.tools.windup.core.WindupService.getWindupEngine(WindupService.java:391)
at org.jboss.tools.windup.core.WindupService.getWindupReportEngine(WindupService.java:412)
at org.jboss.tools.windup.core.WindupService.generateReport(WindupService.java:250)
at org.jboss.tools.windup.core.WindupService.generateReport(WindupService.java:186)
at org.jboss.tools.windup.ui.internal.commands.GenerateWindupReportHandler$1.run(GenerateWindupReportHandler.java:78)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: java.lang.ClassNotFoundException: org.springframework.context.ApplicationContext cannot be found by org.jboss.tools.windup.runtime_3.1.0.qualifier
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:423)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:336)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:328)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 18 more
Blue Skies,
~Ian
10 years, 6 months
Articles for Windup
by Robb Greathouse
Hi,
We want to prepare articles to go out to industry websites and on-line mags to coincide with the September/October release of Windup.
Here are some titles we have kicked around:
"Migrating to JBoss Just Got Much Easier"
"Prospects for Automating Migrations"
"Windup: What's New"
"Importance of Classification in Estimating Costs of Migration"
"How To Write a Plugin For Windup" or "How To Add Your Favorite Tool To Windup"
"Writing Your Own Migration Rules"
If anyone has other ideas or thoughts they can contribute to these, we would love to hear from you.
Robb Greathouse
Chief Evangelist
Middleware Business Unit
JBoss, a Division of Red Hat
cellphone 505-507-4906
10 years, 6 months
