Forum Discussion

Liberty_Informa's avatar
Liberty_Informa
Regular Contributor
12 years ago

soapUI settings through script

In order to have uniform settings on developer machines we enforce many best practices through groovy script through project load script. This is to ensure that even though developer manually changed preferences, they are again reverted back to standard settings. Few of them are like socket time-out, default request response editor, closing all projects on start-up etc.

We have code something like this in the project load script:

SoapUI.settings.setString( UISettings.CLOSE_PROJECTS , "true" )


We have this piece of code in all soapUI projects. Is there any better way to have this at one place rather than in all project load script?
  • nmrao's avatar
    nmrao
    Icon for Champion Level 2 rankChampion Level 2
    Please see this attachment, is this is what you are looking for?
  • Liberty_Informa's avatar
    Liberty_Informa
    Regular Contributor
    nmrao Yes. Rather than asking all developers to change these preferences manually, we want to enforce them through script.

    Right now we have number of settings that we enforce in the load script of the each soapUI project. Since the piece of code which is doing this job is exactly same, we were wondering is there any better alternative for doing this may be keeping code at one place which will be available for all soapUI projects or any better place other than load script.
  • nmrao's avatar
    nmrao
    Icon for Champion Level 2 rankChampion Level 2
    This is a preference and not specific to project. These are saved in soapui-settings.xml. So, may be all the preferences can be saved by one and share to others. Keep this file in default location so that soapui can read this file on soapui is invoked. Note that it will also have some localpath to the recent projects opened which may to deal separately like remove from file before sharing to others.

    I will let SOAPUI team to add if there is any alternative better way.
  • Liberty_Informa's avatar
    Liberty_Informa
    Regular Contributor
    nmrao the solution you are proposing is risky in a situation not having same version of soapUI across the teams situated across the globe, sometimes even different OS. soapUI guys please comment.
  • Hi,

    Interesting discussion!

    I would say, right now we don't have good support for sharing uniform settings across different machines.

    Also, sharing soapui-settings.xml might be too cumbersome since it keeps references to projects location on user's file system and you might end up with more troubles. So for now, I can't suggest anything better than the way you are doing it.

    After reading this thread, we have started to think about introducing global SoapUI level load script support. So, from SoapUI preference menu you can choose a script that will be run every time you start SoapUI, and this script will override soapui-settings.xml in case, you have conflicting values for the same property. And if you disable this preference it will just apply the settings saved on user's soapui-settings.xml as it is today. This means you still have to share your common load script and all SoapUI users within your organization need to select the script from preference. But this is better in the sense that, you will only have one script and users need to configure it only once. Upgrading and re-sharing can possibly be handled by some version control mechanism.

    Feel free to comment on what do you think about the proposed feature or if you have any other suggestions. Once we are on the same page, I will create a new feature request.

    Regards,
    Shadid
    SmartBear Sweden
  • Liberty_Informa's avatar
    Liberty_Informa
    Regular Contributor
    Nice proposal Shadid !

    In my opinion there could be couple of solutions.

    1. First one would be more simpler and coding-less solution. I think I had given that proposal in some other thread.
    Please refer to this one:

    http://www.soapui.org/forum/viewtopic.php?f=2&t=15841


    This solution would be as simple as exporting master preferences from one machine and then importing same preferences on any developer machine. The file which will be exported should be able to be maintained in the version control tool. SoapUI-settings.xml file is also same but it stores many developer machine specific details. The one which I am proposing should be developer machine neutral, may be a child file of the soapUI-settings file. This type of solution is available almost in all programming IDE in the form of coding best practises.

    This has advantage that it is really simple solution for soapUI users (for you guys more toil may be). They need not to be worry about searching API and implementing any solution through code. The disadvantage is that it requires governance that every developer must have imported master preferences file on their machine however that is organisations to enforce this.

    2. Second solution could be exactly what you are proposing. This one requires API knowledge. May be you guys can provide some sample snippets. This solution doesn't require any additional governance. One more advantage I see is for some other purposes many times developer could require global scripting, your new place can be extended for that purpose as well.

    Thank you.
  • Liberty_Informa's avatar
    Liberty_Informa
    Regular Contributor
    Hi Micheal

    I hope you read the complete post.

    I completely agree that you can set global preferences through code. Please tell me the place to write this code in soapUI. How can it be accessed by all soapUI projects?

    Thanks.
  • Liberty_Informa's avatar
    Liberty_Informa
    Regular Contributor
    Hi Micheal

    I hope you read the complete post.

    I completely agree that you can set global preferences through code. Please tell me the place to write this code in soapUI. How can it be accessed by all soapUI projects?

    Thanks.
  • Hi,

    Thanks for your suggestion! We actually also thought about the other suggestion that you posted about exporting and importing machine independent preferences. We kind of preferred the scripting solution since it would give more power in the sense that you can use it as global script. At the same time it will require more work from users as you mentioned.

    I have created a feature request for this (SOAP-430), but we have not made a final decision on which approach to choose when solving this. We will get back to you when we have more information on this.

    Regards,
    Shadid
    SmartBear Sweden