JBIDE-16025 do not attempt to change the state of as>7 or deploy-only server's deployment scanners during publish

[robstryker]

The block of code inside RSEPublishMethod attempts to stop and restart the deployment scanners on the remote server. The current implementation is only fit for AS < 7. There does not currently exist an implementation (in our code) for AS>=7.

This block of code is entered, and attempts to ssh into the remote machine, and execute a twiddle command, to turn off (and restart) the scanners. It also delays for 3 seconds hoping that the change goes through.

This code is questionable already for AS < 7, but for AS >= 7, it is only a wasted 3-second delay with no purpose at all. Deploy-only servers also suffer from this delay, and deploy-only servers have no such scanners to even be turned off.

Since larger-scale refactors are not currently possible at this time, the best solution is to simply exit the block of code early if the target server is not < AS7.

[fbricon]

If servers without JBossExtendedProperties.FILE_STRUCTURE_SERVER_CONFIG_DEPLOY mean there's no deployment scanners, then we should exit early from these methods.
Will it be always the case though? if yes then proceed and apply the PR, else we should prolly discuss it

[robstryker]

It does not mean that there's no deployment scanners.

First, JBossExtendedProperties.FILE_STRUCTURE_SERVER_CONFIG_DEPLOY means it is an AS < 7 installation and it DOES have deployment scanners that we already know how to turn on and off. There is a "not equals" operator in the patch, so it means all others (deploy-only, as7, etc) should return early.

AS >= 7 does have deployment scanners, however we currently have no code to turn them on and off via an easily accessible API. So in effect, if you have a started AS7, and you initiate a publish, it is attempting as3-6 style deployment scanner commands, and simply wasting time.

Since we cannot provide an implementation for as7 to do this immediately, and since we don't really WANT to (as7 does not need their deployment scanners turned on and off all the time, as their scanners are waiting for .doDeploy marker files to be touched), the only effect this has is to not even try something that we know will fail.

[fbricon]

ok. Please proceed.