Why not install those plug-ins in your application? Then your plug-in can
be in charge of monitoring and manging those plug-ins. The
EclipseStarter.startup you called in your plug-in that is the main function
of your app. You can easily find that Equinox prevents the framework
running again if
Meng, Thanks again. The reason why I did not install my plug-in in my
application is: my application is not an RCP-based application, most of them
might be headless application or web UI application. I developed this
plug-in because I was building an IDE to support the development and monitor
Oleg Besedin wrote:
Did you say why you cannot install your plugins in a lower start level?
IMHO, reliance on a start levels should be avoided:
- start levels don't scale if you are putting together an application
that combines features created by separate development teams (i.e.,
Feature
As to the question of DS, let's not forget that it is just an
instrument. From what I understand, its goal is to help developers
work around OSGi complexities. If it does not help, it needs to be
fixed.
I am all for fixing DS if it is flawed. But your argument against using
startlevel can
Danail Nachev
Senior Software Engineer/Development Tools
ProSyst Labs EOOD
-
stay in touch with your product.
-
Richard S. Hall wrote:
Danail Nachev wrote:
I'm not sure what is the application being
Danail Nachev wrote:
Richard S. Hall wrote:
Danail Nachev wrote:
I'm not sure what is the application being discussed here, but here is a
use case:
An RCP application is being built, which is headless and when launched
does some processing and then exits (Update manager refreshes the
Danail Nachev
Senior Software Engineer/Development Tools
ProSyst Labs EOOD
-
stay in touch with your product.
-
BJ Hargrave wrote:
As to the question of DS, let's not forget that it is just an
Richard S. Hall wrote:
I don't think that what I said makes any assumptions about knowing the
exact dependencies. I think my point agrees with what you are saying,
which is that you have to wait for all plugins to start up (including
waiting for their dependencies on each other to be
Danail Nachev wrote:
Richard S. Hall wrote:
I don't think that what I said makes any assumptions about knowing the
exact dependencies. I think my point agrees with what you are saying,
which is that you have to wait for all plugins to start up (including
waiting for their dependencies on
Danail Nachev
Senior Software Engineer/Development Tools
ProSyst Labs EOOD
-
stay in touch with your product.
-
Richard S. Hall wrote:
Danail Nachev wrote:
Richard S. Hall wrote:
I don't think
I feel that changing DS to perform service registration synchronous
with
bundle activation will likely result in deadlocks when there are
complex
service dependency graphs.
This won't be any different from what is done now manually. The
potential for deadlocks are there regardless of
Danail Nachev wrote:
Danail Nachev
Senior Software Engineer/Development Tools
ProSyst Labs EOOD
-
stay in touch with your product.
-
Richard S. Hall wrote:
Danail Nachev wrote:
Richard S.
BJ Hargrave wrote:
I feel that changing DS to perform service registration synchronous
with
bundle activation will likely result in deadlocks when there are
complex
service dependency graphs.
This won't be any different from what is done now manually. The
potential for
I totally agree. This is what I actually wanted in the very beginning of
this thread.
OK, but I certainly did not understand that at the beginning :-)
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
office: +1 386 848 1781
Jeff, Thomas,
Projects are required to keep meta data up to date using the MyFoundation
Portal (http://portal.eclipse.org/). The following problems were found
with this project's meta-data:
* Project home page does not have an About This Project or Information
about project item at the top of
15 matches
Mail list logo
