Forum Discussion
Nice post - thanks for getting involved, your expert guidance on this topic is very welcome :-)
Hope you had a good holiday,
Thanks,
Rupert
A related question,
If a plugin is developed for the OpenSource version, can it easily be used for the licensed version? We generally used the open source version for the developers desk, and a licensed copy for acceptance testing.
- titou109 years agoOccasional Contributor
Thanks Manne and Rupert for your comments
I'm a little bit confused here
- Currently my intention is to provide a plugin for the FOSS version of SoapUI (if it work for the non free version ,fine). JMSToolBox is GPL v3 licensed
- I definitively need to read in detail the documentation on how to develop a plugin
- Manne, you are talking about v5.3 but the current available FOSS version of SoapUI is v5.2.1. Can I use the " Ready! API Plugin framework" with SoapUI FOSS v5.2.1?
- Should I understand from your comments that each time I'll build the plugin in developpement and deploy it to a local SoapUI for testing I'll need to ask you to "sign it"? or is there a dev tool to do that? or bypass the process?
Also I will need to find the time to dig into all of that as the work could be split into various areas :
- define the way (protocol) the plugin will communicate with JTB (HTTP? REST? other?)
- develop a SoapUI plugin (I guess some property/config pages, "jms" protocol implementation, calls to JTB etc.)
- modify/extend JTB to provide/expose services/features (at least: connect, post, get, disconnect, maybe browse, discover..) called by the plugin. My initial intention is to embed as less as possible of JTB code into the plugin.
I will try to find the time to setup a plugin dev environment to have an idea on what to expect in terms of development effort and impact on JTB code. I guess I could add another eclipse plugin in JTB dedicated to expose JTB services/features to other tools like SoapUI
Denis aka titou10
- MFagerlind9 years agoStaff
Yes, sorry I meant 5.2.1, not 5.3.
Unfortunately, if you're running with the official build of SoapUI OS, you need to sign it. However, it's quite easy to jailbreak it (it is open source, after all), so you shouldn't have to do the signing process during development. Here's a solution by another plugin developer: https://github.com/hschott/soapui-pluginloader-jailbreak. Another solution is to just test with an earlier version of SoapUI. I believe the signing requirement was introduced in 5.2.1. As I said, we're currently discussing what the long-term solution will be, so this problem is likely to go away pretty soon.
Resources for plugin development can be found on this page: http://community.smartbear.com/t5/SmartBear-Developer-Network/ct-p/SmartBear_Developer_Network.
You may also want to check the forum for plugin development, where you can also post your own questions, of course: http://community.smartbear.com/t5/Ready-API-and-SoapUI-PlugIn/bd-p/Ready_SoapUI_Plugins
I don't understand the part about communication with JTS. Doesn't it have a a Java library that you can call into to communicate with it? You shouldn't have to embed any JTS code into the plugin, because the plugin framework supports bundling libraries inside the plugin JAR.
If you have any more questions, don't hesitate to ask!
Regards,
Manne
- MFagerlind9 years agoStaff
As a matter of fact, the Ready! API Plugin framework is now also part of SoapUI OS (I believe it was added in 5.3).
However, the plugins written using this framework (which is much easier and safer to use than the old extension mechanism) have to be signed by us. This is an interim solution to make sure that people don't try to load plugins into SoapUI OSthat would only work in Ready! API. The latter has a lot of functionality and platform services that are missing in the OS version, e.g. an event bus that allows plugins to get notifications from other parts of the application. We also want to review plugins contributed by the community, just like we review Pull requests on GitHub.
Long term I don't expect plugins to have to be signed by us, but until we find a better model, we're happy to help you with signing your plugin.
Regards,
Manne
- titou108 years agoOccasional Contributor
I've finaly developped a basic plugin to communicate with JMSToolBox (in draft state..)
I've implemented a new protocl ("jtb") that allows to communicate with JMSToolBox via its exposed REST interface
Bascially this allows to deal with messages (post, get, etc.) and destinations defined in JMSToolBox
As an example, the endpoint "jtb://localhost:9997/rest/message/sessionMQ/queue1" to post the message to the corresponding session/destination
The goals is to become an alternative to HermesJMS but I don't know what kind of exchanges between SoapUI and the Q Manager via JMSToolBox I should implement
Currently, the services are a kind of "post and forget", ie call the REST service to post/get/etc, a message to a queue and that's it.
The HermesJMS integration offer more options (post, post then get etc.), however the JMSToolBox exposed services have more diversity to deal with Q Managers and Destination (Topics/Queues)
I would like to know what are the real use-cases to use a JMS Client from SoapUI in order to add them to the plugin and if there are people relly interested in such a plugin
- rupert_anderson9 years agoValued Contributor
Hi,
Its been a while since I tried, as I no longer have the pro (commercial) version of SoapUI, but as I remember the SoapUI pro/NG plugins have special annotations to enable them to work with the plugin manager (a SoapUI pro/NG only feature). So there would be some hopefully minor code changes.
More recently I think SmartBear have changed SoapUI Open Source (v5.2.1+ I think) to require that all open source plugins also be digitally signed by their certificate - please see this thread for more details:
Cheers,
Rupert
- rupert_anderson9 years agoValued Contributor
Hi Manne,
That sounds cool, I like the idea that the plugins may one day not need to be signed, at least for the open source version :-)
I didn't realise there was a 5.3 version of open source SoapUI, or is this a next release? If so, do you know when it might be available? Sounds very sensible to unify the plugin frameworks anyway.
Thanks,
Rup
- MFagerlind9 years agoStaff
Yes, it will work fine.
EDIT: This was in reply to the question if plugins written for the OS version will work in Ready! API.
- MFagerlind9 years agoStaff
Sorry, I slipped: I meant 5.2.1. Mostly working with Ready! API at the moment. :-)
Related Content
- 9 years agovon_bailey
- 4 years agoLarsenrw22
- 8 years agoAndyO
- 6 years agokaivi
Recent Discussions
- 7 days agoemoya