+100 to an Eclipse plugin.
Having a featureful/more graphical plugin descriptor editor in Eclipse would
be great (our XSDs are very well documented and editing the plugin descriptor
XML in Eclipse is actually quite a pleasant experience, but with Eclipse
plugin we can go even futher - like automatically add facets to the component
classes, etc).
+100 to a graphical integration with the standalone container - how cool would
that be to have to leave your IDE and test your plugin interactively. But I
must say that while the standalone container is quite powerful, I find its CLI
quite terse and hard to remember (also having command history would help
there ;) ) - if we were to integrate it to an IDE, the standalone pc's CLI
should be given some love.
Just my 2c.
On Tuesday, August 28, 2012 08:10:19 Simeon Pinder wrote:
The act of writing an RHQ plugin is how one integrates a management
product
into the RHQ management space. While the process is fairly well
documented(https://docs.jboss.org/author/display/RHQ/Plugin+Community),
there is still quite a lot of initial investment for a user new to RHQ
development and even more when integrating management products not based in
java.
I think we can significantly improve the plugin development and maintenance
process by putting some more effort in the following areas: Development:
- Add more graphical tooling around plugin development to
a)lower the barrier to entry for new management products
b)shorten the feedback loop during plugin development
Testing:
- Document some best practices and a reference implementation for testing
plugins Deployment/Runtime versions:
- Document some best practices for Deployment/Runtime versioning of
plugins
While the enhancements around Testing and Runtime versions of plugins can be
considered more advanced topics about how to be more consistent and robust
among all available plugins and versions, the enhancements around graphical
tooling for plugin development seem fundamental to increasing plugin
developer productivity and more pressing.
Specifically around graphical plugin development tooling, the following seem
like good enhancement areas to start in: - graphical plugin descriptor
creation. This can be a standalone or integrated part of a Swing|Eclipse
plugin|Forge application. - graphical maven plugin generator. The current
command line version works to create an initial setup but a graphical
wizard would be vastly more helpful. - graphical integration with both
standalone plugin container AND lightweight configuration editor for faster
plugin development/testing. Such a graphical tool would likely have an
RHQ/JON installation as a dependency to ease dependency/setup/requirements.
- Additionally you'd want to support the ability of the developer to insert
sample/mock values to simulate how the plugin code will respond. - a few
short videos/wink demos showing how to develop i)java plugin ii)java
plugins utilizing scripting iii)non-java plugin
* For all of the above we should be mindful of two recent enhancements,
listed below, which enable greater integration of non-java management
plugins. Assuming a java and/or jboss AS stack for development may no
longer be a valid assumption for all plugin developers.
http://pilhuhn.blogspot.de/2012/07/jar-less-plugins-for-rhq.html
http://pilhuhn.blogspot.de/2012/07/introducing-no-op-plugin-for-rhq.html
What do others people think about this? Any other enhancements areas that
we should add to this list? I think such a fundamental part of the RHQ
management framework should be easier to use and the productivity gains
will be substantial.
-Simeon
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel