RFR: Additional tests for overlapping packages.

[Alan Bateman]

On 05/10/2015 10:11, Alexandre (Shura) Iline wrote:
> :
>
>>      2. testOverlapUpgradePath assumes that the upgrade module path 
>> can be used as an alternative to the application module path. There 
>> are several discussion points around the upgrade module path but I 
>> don't expect it can be used to do anything other than upgrade modules 
>> that are on the system module path (or linked into the runtime 
>> image). So maybe this one should be dropped for now.
>>
>
> If something is possible, it is bound to happen. Unless it is 
> impossible to place a user code on the upgrade module path, somebody 
> will.  For this, the test makes sense, even if it is assuming behavior 
> beyond what is promised by the spec.
>
> Further on, if the behavior is currently undefined, then the more 
> sense there is to keep the test, IMO. When the behavior changes, it is 
> better to have the failing rather then to forget adding it later.
>
> The only cases where it is better not to have this test are:
>  - the test is invalid. For example there is no way to place any 
> arbitrary code on the upgrade module path.
>  - the behavior is undefined so the error of package name overlap may 
> or may not be reported.
>
> Are you referring to any of these?
>
I completely agree that someone will likely do this by mistake. I'm just 
saying that there are several discussion points in the area of 
upgradeable modules, one of which is the expected behavior when someone 
puts a random module on the upgrade module path that isn't upgrading a 
system module. Is it an error? Should it be ignored? Should it just 
prepend to the system module path as it does now? I think it needs 
conclusion on these issues before we it's possible to use it in tests 
that do anything beyond testing the upgrade module mechanism.

-Alan