I guess I cannot understand why you would want to keep old test cases
that are no longer applicable to the new architecture of your
system...makes more sense to change the test cases to me.
However, if you really want to make sure everything starts before your
GUI, you can put all of your service bundles in a lower start level than
your GUI bundle; thus, by the time the GUI bundle starts, then all your
services will be available.
-> richard
jaredmac wrote:
Felix Meschberger-2 wrote:
Clients always get a deterministic answer: The services registered at
the time of the call. The non-determinism comes from the fact, that the
services are registered asynchronously, which is by design and good.
Thanks for the explanation. You mentioned a few times that the
non-determinism is good. I can see how that would be the true in some cases,
and not so much in others.
As it is, I have unit tests in which I do not want to introduce regressions,
and these tests are checking that the program has a certain appearance --
specifically, it is examining the state of the user interface's menu items.
I have turned these menu items into bundles, such that each bundle can
contribute to the UI.
So even if I change my client to respond to bind() and unbind() methods, and
dynamically register/unregister these menu items, then the UI will work
correctly (with menu items coming and going, I suppose), but the unit tests
still fail. I want to avoid that.
As I describe my situation, I get the impression that I should be using
extensions rather than services... but I have not yet tried using extensions
with Felix (that would require Equinox?). So far, I was enjoying the
simplicity of Felix + SCR, because it has gotten me 95% of the way there.
But I will look into these alternate approaches and report back. Thanks for
the help.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
