I’m looking for clarification on the current logic behind command line execution. Looking at the console log, I see the following snippet:
In particular, I’m concerned with the following lines:
Delete folder: bin Delete folder: Libs
… after which the project is opened (triggering a recompile). Looking back a ways, I believe this approach may have been an attempt to resolve everyone’s favorite bug:
… where I make a suggestion to delete those directories, then reopen your project, allowing the studio to rebuild the workspace. However, I never intended this to be a permanent solution to that problem so long ago, it was simply a quick fix to get people up and running.
There is a major problem with integrating this into console mode execution by default, and I believe it may be the source of several issues that have been brought up:
The problem I see most often is when multiple executions are triggered simultaneously and/or relatively close together. Consider the following scenario:
1.) An execution is triggered, during which the bin and Libs folders are deleted, and the studio then tries to open the project. While the project is opening, and the source code is being recompiled, there is a period of time where these directories (and the binaries they contain) are not available.
2.) Another execution is triggered while this recompilation is going on. Because those directories are in the process of being rebuilt, one of the following has a good chance of happening:
- An error is thrown during the second job stating that the directories cannot be deleted (either because they don’t exist, or they do exist but are locked by the first job).
- The timing is such that job 2 is able to delete the directories, but this causes job 1 to throw errors, usually related to missing classes.
This issue can be easily recreated by simply triggering two CLI executions simultaneously.
Again, I’m just looking for some insight on why console mode execution does this. In my humble opinion, deleting these folders then recompiling is not a very good solution, especially when multiple exections are triggered as I’ve shown. This is particularly troublesome with Jenkins integration, where multiple nightly jobs are often triggered together.