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
