Forum Discussion
This change definitely is not welcomed by Open Source community, I believe.
I do not see an issue for the plugin developers to submitting plugin to Smartbear, in fact, users might love it if some piece of software written by them goes to a well named software.
But, before that, plugin needs to verified for themselves wether the plugin, written by them, is working as per the expectations or not. As per the changes mentioned, it appears that it may not possible to test for the plugin author until it goes thru productizing it and new release is done.
Another, probablity could be Smartbear has right to productize the idea or not depending on the value that it brings to table. However, the original author might need it for his/her project to test or automate.
Do we continue to have SoapUI OS releases? just curious after looking at #2.
I believe, what could be more welcomed by Open Source community would be :
- If there is no certain feature, that is fine.
- Continue with existing features.
- If certain feature is going to be deprecated, have it in release notes. That would set the user expectations right or will not be a surprise.
- Just specific to this case, provide a utility that can sign the user plugins as desired by new plugin manager / loader if the new stuff is manadatory.
- New ideas can come from any one who might be technical/non-technical, Open Source/Pro users. Depending on the value that it fetches, the idea may productized or may not be at times. If some thing can be extendable, that would be good for both Pro and OS softwares.
- I do understand that plugins play an important role. Thank you for Smartbear team for productizing this feature to the API tools which makes easy to develop new plugins. Again if some plugin is more critical to certain users may bring zero value to certain users. What I wanted to say here is when users have flexibility they continue to use software (irrespective of paid or unpaid software) rather than looking for alternatives.
Thanks for sharing your opinion! I cannot change anything in this situation :(
However, I've passed this information to the SoapUI Product Owner so that he would be aware about this.
- hschott9 years agoOccasional Contributor
Hi,
for all of you running into the same problem i recommend to have a look at https://github.com/hschott/soapui-pluginloader-jailbreak . This little peace of code will help you to bypass the ProductBodyguard, while testing your plugin.
Regards,
Holger
- hschott9 years agoOccasional Contributor
Hi Tanya,
i would very apreciate and welcome to read a post by MFagerlind, OLensmar or LBrandon about this topic and the roadmap of SoapUI OS.
Regards,
Holger
- MFagerlind9 years agoStaff
Hi Holger,
Sorry for our late response. There will be an official announcement from the Product owner on our strategy for plugins, which I hope will come later for day.
As you know, we have a process for reviewing plugins. In Ready! API, what we do with the plugins after they have been approved is to add them to our repository. In SoapUI OS, where we don't have a repository or a GUI for installing plugins, what we do is to allow only signed plugins to work.
We've always reviewed community code contributions to the SoapUI project (Pull requests) and want to do something similar for plugins. One of the reasons is that we don't want people to accidentally load Ready! API plugins, which may fail in subtle ways.
In other words we will sign your plugin and other plugins like it. It's a great contribution, and we're grateful that you want to make it available to all SoapUI users.
I'll contact you privately to get the JAR file signed.
Regards,
Manne
- hschott9 years agoOccasional Contributor
Hi Manne,
well, i understand the intention to sign plug-ins. But the solution is not very well crafted.
At first there must be a way for developers to test their code. I see three ways to solve this:
1. without signing
2. by signing with a self-signed certificate like Android development does it (opt-in by the user thru UI dialog)
3. by signing with a developer certificate signed by Smartbear like Apple development does it
At second there should be a documented and working process how to get a plug-in reviewed and signed for production.
Both points require a medum to large infrastructure and management effort backed by tools and staff.
Are you aware of this?
Regards,
Holger
Related Content
Recent Discussions
- 2 days agoruchisingh