Forum Discussion

Yoav_Seroussi's avatar
Yoav_Seroussi
Occasional Contributor
14 years ago

Complex project creates many unnecessary tmp files

Hi,

I'm running SoapUI Pro 3.5.1 (build: daily-2010-04-18-[1], but it also happens for the distro build).
The OS is Windows Vista Business SP. 2 64bit.
I think the JRE is the on installed from the exe (JRE 6u18).

The problem we have (not only on my computer) is that the soapUI Pro creates hundreds of tmp xml files in the composite project.

Here's a screenshot to illustrate the problem:


Regards,
Mike

19 Replies

  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    SmartBear Alumni (Retired)
    Hello,

    thank you! I've just opened issue SOAPUI-3308 for dealing with this.

    Regards,
    Vladimir
    SmartBear Software
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    SmartBear Alumni (Retired)
    awesome work indeed!

    I've attempted a fix to this - will be in the upcoming nightly build - please give it a try and let us know if it makes any difference.

    Thanks!

    /Ole
    SmartBear Software
  • nicorette's avatar
    nicorette
    Occasional Contributor
    Hello,
    sorry that i reply so late.

    Is this fix taken to the newest version of soapUI 4.5 (release or nightly build)?
  • nicorette's avatar
    nicorette
    Occasional Contributor
    SmartBear Support wrote:
    Hello,

    yes, it should be fixed in 4.5. Please try.

    robert
    /Smartbear


    I tested it with the soapUI-release 4.5.0 and the problem still exists. >:(
  • Finan's avatar
    Finan
    Frequent Contributor
    Just a heads up, I also see this warning when saving non-composite projects.
  • linkon1's avatar
    linkon1
    Occasional Visitor
    Any news on this one?
    It still exists in latest nightly-build:

    soapUI Pro 4.5.1.1-SNAPSHOT
    Build [internal], Build Date 2012/11/20 00:57

    As many other SoapUI Pro users we're using SVN, and "normalize line breaks" seems to be the simple solution for us to keep our files (approx 50-70 SoapUI projects) in a consistent format. Right now we're facing constant differences due to "end-of-line" changes.

    By using "normalize line breaks" - we would have all consistent format of all files - and only the files that really are modified would be committed to SVN.
    By having a lot of files "changed" by end-of-line differences - our tester's and developer's will have constant problems when they are working on same project (different files/testsuites/testcases) - due to the many conflicts at check-in time.

    But - the generation of the tmp files makes this feature hard to use - as you will not be able to save / reload the project (without removing all tmp files after save...) locally when developing your tests in SoapUI!
  • nicorette's avatar
    nicorette
    Occasional Contributor
    linkon1 wrote:
    Any news on this one?
    It still exists in latest nightly-build:

    soapUI Pro 4.5.1.1-SNAPSHOT
    Build [internal], Build Date 2012/11/20 00:57

    As many other SoapUI Pro users we're using SVN, and "normalize line breaks" seems to be the simple solution for us to keep our files (approx 50-70 SoapUI projects) in a consistent format. Right now we're facing constant differences due to "end-of-line" changes.

    By using "normalize line breaks" - we would have all consistent format of all files - and only the files that really are modified would be committed to SVN.
    By having a lot of files "changed" by end-of-line differences - our tester's and developer's will have constant problems when they are working on same project (different files/testsuites/testcases) - due to the many conflicts at check-in time.

    But - the generation of the tmp files makes this feature hard to use - as you will not be able to save / reload the project (without removing all tmp files after save...) locally when developing your tests in SoapUI!


    Hello linkon1,
    you described the same situation as in our company.
    We are also annoyed that this bug still exists and it seems that SoapUI-Support not cares about it anymore. As workaround we use a shell-script which normalizes every XML file recusivley before check in.