[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re[2]: [equinox-dev] Roadmap?
|
Isnt this what the PicoContainer is doing?
Kind regards,
Peter Kriens
SX> That's correct. The UI component framework is not UI
SX> specific. Generally speaking, it provides a loosely-coupled way
SX> to instantiate and destroy objects.
SX> Concretely, here was our driving use-case:
SX> - API Clients are allowed to implement views and editors (or "parts").
SX> - We wanted to add API such that clients could host parts.
SX> - Parts have a number of local APIs available to them,
SX> provided by their containing context. We called these local API
SX> "services", but they are more like Eclipse adapters than OSGi
SX> services.
SX> - These service APIs change over time.
SX> - Clients that host parts can offer an extended set of
SX> services to the parts they host.
SX> - All parts need to work in all contexts. For example:
SX> - If a part updates itself to use the latest APIs, it
SX> should continue to work when hosted in a context that still
SX> implements the old API.
SX> - If a host is updated to implement the latest APIs, it
SX> should continue to be able to host parts that expect the old
SX> version.
SX> - If a part uses an extended set of features, it should
SX> still work in a context that does not know about the extended
SX> features.
SX> - We wanted to be able to act on an open-ended set of
SX> services. For example, it should be possible to write a wrapper
SX> part that overrides a closed set of services and delegates
SX> everything else to another part.
SX> Put simply, we wanted to make all parts interchangeable, but
SX> still leave avenues open for API evolution. These are issues that
SX> apply to any object that gets created from an extension point, and
SX> our implementation was similarly generic. Although the IoC
SX> framework works with any POJO, I will continue using the word
SX> "part" since I find the UI metaphor easiest to visualize.
SX> We wanted our implementation to have the following properties:
SX> - It must be simpler (require less code + XML) to implement a
SX> component-based part than a traditional part.
SX> - There must not be a significant memory or CPU cost to using IoC.
SX> - It must be self-documenting in the following sense: given a
SX> set of plugins, a developer should be able to generate the list of
SX> services that they could use in the implementation of their part.
SX> - Services can depend on other services. Since all are
SX> created through the framework, there is no real distinction
SX> between the implementation of a "part" and a "service".
SX> Although the framework was originally intended for views and
SX> editors, it is very well suited for any extension point that calls
SX> createExecutableExtension and I have used it for many non-UI
SX> extension points. I do not believe it would work as a replacement
SX> for OSGi's DS, as DS is mainly concerned with dynamic connections
SX> between singletons, whereas the UI IoC stuff is concerned with
SX> creating static connections to objects that can be instantiated
SX> anywhere.
SX> Here's how our implementation works:
SX> - Our implementation does NOT require dependencies to be
SX> declared anywhere (no need for a prereqs extension point).
SX> - You only need to say "when someone asks for service X,
SX> create it using factory Y". When it comes time to create an X, the
SX> factory will ask for any services it needs, which get created
SX> dynamically.
SX> - One standard factory, "ReflectionFactory" creates objects
SX> using constructor injection. It would also be possible to write a
SX> setter-injection factory or factories that are specific to a
SX> particular service.
SX> - Although the factories are framework-aware, the objects
SX> they create can truly be POJOs with no framework awareness.
SX> I hope that explains what it can and can't do. If you want to
SX> play with it, you'll find the main IoC container in
SX> org.eclipse.ui.internal.components.framework.Container.
SX> My two cents:
SX> I would not suggest trying to use the same IoC framework for
SX> OSGi services and for createExecutableExtension. The former are
SX> dynamic, so it makes sense to formally declare dependencies
SX> between services in order to defer creation of a service until all
SX> of its dependancies exist. In the case of
SX> createExecutableExtension, everything the object needs will be
SX> available immediately if the code is correctly written. This means
SX> that an IoC framework for createExecutableExtension wouldn't need
SX> all the tiresome metadata for describing service dependencies.
SX> Services can just ask for their dependencies the first time they
SX> need them.
SX> If this were to be seriously considered for inclusion in
SX> core, I would want to trim a lot of fat first.
SX> Example usage:
SX> class Cat {
SX> String catName;
SX>
SX> Cat(String name) {
SX> catName = name;
SX> };
SX> }
SX>
SX> class Dog {
SX> Cat theCat;
SX>
SX> Dog(Cat toChase) {
SX> theCat = toChase;
SX> }
SX>
SX> public chaseCat() {
SX> System.out.println("Chasing " + theCat.getName());
SX> }
SX> }
SX>
SX> ...
SX>
SX> public static void main(String[] args) {
SX> // Create a context that knows how to create Dogs. Any time it needs a Cat,
SX> // it will refer to poor Fluffy.
SX> FactoryMap context = new FactoryMap()
SX> .add(Dog.class, new ReflectionFactory(Dog.class))
SX> .addInstance(Cat.class, new Cat("Fluffy"));
SX>
SX> // Create a container for a particular Dog
SX> Container container = new Container(context);
SX>
SX> try {
SX> // Create a Dog
SX> Dog myDog = (Dog)container.getService(Dog.class);
SX>
SX> // Chase Fluffy around
SX> myDog.chaseCat();
SX>
SX> } catch (ComponentException e) {
SX> // We weren't able to create the Dog
SX> System.out.println(e.toString());
SX> } finally {
SX> // Clean up the container when no longer needed
SX> container.dispose();
SX> }
SX> }
SX> Pascal Rapicault/Ottawa/IBM
SX> 11/22/2005 10:04 PM
SX> To
SX> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
SX> Stefan Xenos/Ottawa/IBM@IBMCAcc
SX> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
SX> equinox-dev-bounces@eclipse.orgSubject
SX> RE: [equinox-dev] Roadmap?Link
SX> If I remember correctly, the design of the support for
SX> nesting UI component was based of an IoC container and it had
SX> nothing UI specific.
SX> It would be good to see if we could actually reuse some of
SX> the work that had been done there.
SX> Stephan, am I completly smoking? Would you be able to provide
SX> us with some usefull pointers so people can explore?
SX> Thanks,
SX> PaScaL
SX> Jeff McAffer/Ottawa/IBM@IBMCA
SX> Sent by: equinox-dev-bounces@xxxxxxxxxxx
SX> 11/22/2005 09:52 PM
SX> Please respond to
SX> Equinox development mailing list
SX> To
SX> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>cc
SX> Subject
SX> RE: [equinox-dev] Roadmap?
SX> First an answer to your last questions. Yes, anything that
SX> makes writing components easier is very much of interest here.
SX> Rather than creating new programming idioms and mechanisms it
SX> would be interesting, as you have been doing, to investigate all
SX> possible avenues. If in the end there is truly something new
SX> here, it may make sense to supply a library/bundle.
SX> I will offer an alternative that *may* make sense. It is
SX> something that we have been playing with. In the Eclipse
SX> extension registry it is possible to create executable extensions
SX> via a factory (see
SX> IConfigurationElement.createExecutableExtension() and
SX> IExecutableExtensionFactory). So your IoC framework could publish
SX> an extension point "prereqs" (for lack of a better name). People
SX> who have prereqs (services in your example) to register can then
SX> supply extensions that identify either the actual class to
SX> instantiate (if the simple no-arg constructor is enough) or an
SX> IExecutableExtensionFactory (with args) if more complicated
SX> construction is needed.
SX> In the IoC mechanism (com.example.ioc)
SX> <extension-point id="prereqs"/>
SX> In the provider JAR (org.example.provider).
SX> <extension id="prereq1" point="com.example.ioc.prereqs">
SX> <prereq
SX> class="org.example.Factory:coolObject"
SX> ...
SX> This extension says run the org.example.Factory and tell it
SX> to create the thing called "coolObject". The factory can be as
SX> simple or as complicated as you like. You can make some generic
SX> factories and share them or make one per thingie you want to
SX> create. You can also pass in an arbitrary number of args
SX> statically declared on in the extension (see the Javadoc for
SX> details).
SX> You then have two choices for when the contributed
SX> prerequisites are actually instantiated and supplied to consumers;
SX> lazily or aggressively. If you go for the lazy approach then your
SX> POJO could access the prereq on demand using something like
SX> Object IoC.getPrereq(String prereqName, Object objectToInject)
SX> where the prereqName is the id of the extension to
SX> instantiate (org.example.provider.prereq1 in the above example).
SX> (not really a POJO if it is referencing IoC but you seemed fine
SX> with this in your example...) This ends up being implemented as a
SX> call to IConfigurationElement.createExecutableExtension(). The
SX> prereq object is only instantiated as needed. When you stop using
SX> it, just drop the pointer. I believe previously you stated that
SX> lifecycle was not important so the disappearance of the provider
SX> should not be an issue.
SX> If you want to create the instances aggressively then the
SX> IoC mechanism should have the sort of registerDependency method
SX> you outlined. It should also implement an IRegistryChangeListener
SX> that listens for new extensions being added to the "prereqs"
SX> extension point. When it sees one that someone has registered an
SX> interest in, it calls createExecutableExtension and uses the
SX> supplied setter. If it later sees the extension going away, it
SX> can unset the value. See IExtensionTracker for some utilities to
SX> help manage this.
SX> Some notes:
SX> - You are probably thinking that this is crazy, the
SX> extension registry is buried deep in Eclipse. Wrong! As of
SX> today's integration build it is actually broken out in its own
SX> bundle (org.eclipse.equinox.registry) and the intention it that it
SX> run on any OSGi R4 implementation (we've not tested that part yet).
SX> - So you are still thinking, "but its based on OSGi". Yes
SX> and No. It is pluggable. You can customize the implementation of
SX> the registry to suite different sources of declarations (e.g.,
SX> something other than plugin.xml), different namespace management
SX> policies and different mechanisms for implementing
SX> createExecutableExtension. We supply an OSGi registry strategy
SX> but you can supply one of your own. The usecases that are driving
SX> this new structure are quite similar to your hosted and client
SX> scenarios.
SX> - The ability to supply dynamic context objects to
SX> createExecutableExtension is currently not implemented. We
SX> discussed this late in 3.1 but opted out. This topic has been
SX> raised again and we are certainly open to adding it.
SX> - I've thought about this exact problem for about as long as
SX> it took me to write this response so I could be completely out to
SX> lunch here...
SX> Jeff
SX> "John Wells" <jwells@xxxxxxx>
SX> Sent by: equinox-dev-bounces@xxxxxxxxxxx
SX> 11/22/2005 04:00 PM
SX> Please respond to
SX> Equinox development mailing list
SX> To
SX> "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>cc
SX> Subject
SX> RE: [equinox-dev] Roadmap?
SX> Yes, the code using the LogService would have to explicitly
SX> check (with a synchronized block) whether or not the logger
SX> exists. The code would be something like:
SX>
SX> LogService localLogger;
SX> synchronized (this) {
SX> localLogger = logService;
SX> }
SX>
SX> If (localLogger != null) {
SX> localLogger(This is fun!!!);
SX> }
SX>
SX>
SX> This will work whether or not we are in the OSGi environment.
SX>
SX> Also very interesting trick to getting the bundle.
SX> Thanks. I wish there was a more framework independent way to
SX> do this.
SX>
SX> My more general question remains though: is this a
SX> requirement that more people than me have faced? Would a Dynamic
SX> IoC utility be of interest to the OSGi community? At this point
SX> Im writing this thing anyway, I just want to know if people here
SX> would be interested in me contributing the code? Since this is a
SX> utility (of course it would be a Bundle as well) Im not exactly
SX> sure where the proper place would be to put such a thing, or if
SX> people are even interested in such a facility.
SX>
SX> John Wells (Aziz)
SX> jwells@xxxxxxx
SX> From: equinox-dev-bounces@xxxxxxxxxxx
SX> [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Jeremy
SX> Volkman
SX> Sent: Tuesday, November 22, 2005 2:57 PM
SX> To: Equinox development mailing list
SX> Subject: Re: [equinox-dev] Roadmap?
SX>
SX> John,
SX> When writing a component to be environment-agnostic, how do
SX> you handle the case when LogService may not be available at the
SX> time of your POJO's instantiation (only in the OSGi environment,
SX> of course)? Will the programmer have to explicitly check the
SX> value of the logger member before attempting to use it? If so,
SX> doesn't this go against your wishes that the programmer not care
SX> what environment he/she is writing for?
SX> Also, on getting a caller's BundleContext: it is possible,
SX> but it get ugly. I had to do something similar to get per-bundle
SX> logging working with the Apache Commons Logging API. Commons
SX> Logging provides the static LogFactory class to get Log instances,
SX> and I wanted Log instances to know which Bundle had created them
SX> (so I could print out the name of the Bundle logging a message).
SX> One way would be to include a separate copy of my modified
SX> LogFactory class with each bundle, and provide the Bundle's
SX> personal LogFactory instance with a reference to the Bundle at
SX> start up, but this seemed like a maintenance nightmare, and it
SX> negated OSGi's nifty code sharing feature.
SX> So i went with the following approach:
SX> 1. Subclass SecurityManager and gain access to the getClassContext() method
SX> 2. Pick the Class of the caller off the stack
SX> 3. Use OSGi's PackageAdmin and its getBundle(
SX> java.lang.Class) method to get the Bundle containing a particular
SX> class
SX> Since the BundleContext instance is supposed to be private
SX> to its associated Bundle, OSGi provides no way of getting a
SX> BundleContext for a given Bundle (the DS spec mentions this).
SX> With Equinox, this can be done through reflection, as Equniox's
SX> AbstractBundle class defines a method "getContext":
SX>
SX> Bundle bundle = ...
SX> Method contextMethod =
SX> bundle.getClass().getDeclaredMethod("getContext", (Class[]) null);
SX> contextMethod.setAccessible(true);
SX> BundleContext context = (BundleContext)
SX> contextMethod.invoke(bundle, (Object[]) null);
SX> Of course there are numerous possible issues with this
SX> method (can't create new SecurityManagers, can't change Method
SX> accessibility, etc.), but perhaps it will be food for thought.
SX> Jeremy Volkman
SX> On 11/22/05, John Wells < jwells@xxxxxxx> wrote: Thanks for your response Olivier.
SX>
SX> In an earlier response I talked about the requirement I would
SX> like to see satisfied that would make the IoC pattern work in both
SX> a dynamic and a static environment. Basically, I want to write
SX> code that dynamically tells the IoC system that it wants to depend
SX> on some other type and I want this to work both in a "client"
SX> environment where the classes are linked together via the system
SX> class-loader as well in the dynamic environment afforded by OSGi.
SX> To me what is interesting is to be able to write code that runs
SX> in both a "hosted" and "client" environment without modification.
SX>
SX> What I do not want is for the programmers writing the code to
SX> know the difference between the two environments. Furthermore, I
SX> think that this could be a common programming pattern when writing
SX> modular code. I want the service writers to have simple
SX> instructions for how to write their services, and then I want the
SX> framework to do the "correct" thing based on whether or not we are
SX> running in the OSGi framework or on a client that has not started
SX> the OSGi kernel. Yes, I want my cake and I want to eat it too ;-)
SX>
SX> Let's take something as simple as a log service. I want to
SX> have a pojo that says something like:
SX>
SX> private LogServer logger;
SX>
SX>
SX>
SX> // inside some method of my pojo
SX> IoC.createDependency("com.acme.LogService", "setLogger", this);
SX>
SX>
SX>
SX> public synchronized void setLogger(com.acme.LogService logger) {
SX> this.logger = logger;
SX> }
SX>
SX> When in the OSGi world, the LogService might be satisified by
SX> lots of different implementations. However, in the client world
SX> there may be only the one that is satisfied on the client
SX> classpath.. One problem we run up against right away is that
SX> com.acme.LogService is very likely an interface, and hence cannot
SX> be instantiated directly on the client. In order to solve this
SX> problem I was thinking that it would be necessary to define a
SX> generic sort of factory interface like this:
SX>
SX> public interface GenericFactory<T> {
SX> public <T> create(
);
SX> public <T> find(
) throws NotFoundException;
SX> }
SX>
SX> (excuse any typo's, I am typing as I write, not pasting from an IDE ;-)
SX>
SX> Now instead our IoC object might look like this:
SX>
SX> private LogFactory logFactory = new LogFactory(); //
SX> Implements the GenericFactory interface
SX> private LogServer logger;
SX>
SX>
SX>
SX> // note this time I must provide the factory to use for this service
SX> // just in case this is running in a "client" environment
SX> IoC.createDependency("com.acme.LogService", "setLogger", this, logFactory);
SX>
SX>
SX>
SX> public synchronized void setLogger(com.acme.LogService logger) {
SX> this.logger = logger;
SX> }
SX>
SX> The signature for createDependency would be something like:
SX>
SX> public Object createDependency(String serviceName, String
SX> setterName, GenericFactory staticFactory,
);
SX>
SX> where the extra arguments are used in the find/create methods of the factory.
SX>
SX> What my IoC controller could do then would be that *if* I was
SX> running in OSGi (and could find the bundle context of this caller)
SX> then use the ServiceTracker to hook up the LogService with the
SX> implementation. But *if* I was running in a "client" environment
SX> I would use the factory (first trying to find, then create the
SX> service).
SX>
SX> Everything above is doable (with a big question mark on how
SX> to get the code's BundleContext) using home-made code. I was
SX> wondering if anyone else has these sorts of requirements or if
SX> there is any "standard" way to accomplish what I am trying to
SX> achieve? And does this clarify what requirements I have?
SX>
SX> John Wells (Aziz)
SX> jwells@xxxxxxx
SX> From:equinox-dev-bounces@xxxxxxxxxxx [mailto:
SX> equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Olivier Gruber
SX> Sent: Tuesday, November 22, 2005 12:26 PM
SX> To: Equinox development mailing list
SX> Subject: RE: [equinox-dev] Roadmap?
SX>
SX> John,
SX> Declarative services are mostly about lifecycle and injection.
SX> It is the combination of both that is powerful, especially
SX> regarding the linkage with the bundle lifecycle underneath.
SX> That is, a service is created only when its dependencies are available...
SX> and this means that the creations of class loaders are also delayed.
SX> Without lifecycle, injection becomes service tracking with
SX> the use of setter/getter methods,
SX> especially if you are not using a constructor-based injection.
SX> What I am curious about is that inversion of control becomes
SX> really interesting when used with a lifecycle.
SX> The goal is that a service code does not have to deal with
SX> the dynamic nature of its environment.
SX> When it is activated, it has all the references it needs
SX> because they have been injected.
SX> Before loosing a reference, it will be deactivated.
SX> But you are stating that you have no lifecycle, does this
SX> mean that you have injection but your code is also fully
SX> responsible for dynamically appearing/disappearing
SX> references? Who controls that lifecyle? That is, who creates
SX> your POJO and why.
SX> Just trying to understand.
SX> Best regards,
SX> Olivier Gruber, Ph.D.
SX> Persistent & Distributed Object Platforms and Frameworks
SX> IBM TJ Watson Research Center
SX> "John Wells" < jwells@xxxxxxx>
SX> Sent by: equinox-dev-bounces@xxxxxxxxxxx
SX> 11/22/2005 05:25 PM
SX> Please respond to Equinox development mailing list
SX>
SX> To: "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
SX> cc:
SX> Subject: RE: [equinox-dev] Roadmap?
SX> Yeah I had thought of that too. I guess I wanted it to be sort of
SX> "standardized" rather than having to write a layer. But that's ok.
SX> So... then I also need to know if/when the "ServiceTracker" will be
SX> implemented in Equinox. Or perhaps it already is, since I can remember
SX> ServiceTracker from r3?
SX> John Wells (Aziz)
SX> jwells@xxxxxxx
SX> -----Original Message-----
SX> From: equinox-dev-bounces@xxxxxxxxxxx
SX> [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Jeremy Volkman
SX> Sent: Tuesday, November 22, 2005 11:21 AM
SX> To: Equinox development mailing list
SX> Subject: Re: [equinox-dev] Roadmap?
SX> It seems as though you may be able to realize your DDS needs right now
SX> by using the already-available ServiceTracker. When
SX> registerDependency() is called, create a new ServiceTracker with the
SX> given service information and start it. Override the addingService()
SX> and removedService() methods (or provide a ServiceTrackerCustomizer)
SX> and make these methods call your POJO's setter/unsetter (remember that
SX> this is a dynamic environment, so you'll probably want an unsetter).
SX> The only issue is that you'll need to provide ServiceTracker with a
SX> BundleContext for it to get a ServiceReference.
SX> Jeremy Volkman
SX> On 11/22/05, John Wells <jwells@xxxxxxx> wrote:
>> Yes, I do like the delayed activation part of DS. Here are some
SX> issues
>> I have with DS (since you asked - didn't you? ;-)
>>
>> I would like to be able to have a POJO that uses a service which gets
>> injected. While I think that with DS I can declare a class that the
SX> DS
>> would instantiate, what I want is something more dynamic. I want to
SX> be
>> able to have my own class (that I instantiated myself in whatever way)
>> declare that it wants a service (e.g. "com.acme.Foo") injected into
SX> it.
>> This class would *not* be under the lifecycle control of DS, but would
>> still be getting the dependent service injected into it appropriately
SX> as
>> the class is available in the OSGi framework.
>>
>> In my mind I have been calling such a facility "Dynamic DS" or DDS for
>> short. It would be a service or a class with static methods that had
>> methods like the following:
>>
>> /**
>> * This method would call the setter on the object when the
SX> appropriate
>> * service becomes "available", but objectToInject is *not* under the
>> * specific control of the DS framework
>> * Note: There are likely other "registerDependency" verbs that
SX> specify
>> * all the options available in the DS configuration file and OSGi
>> * service filters
>> * @param serviceName The name of the service I would like to depend
SX> on
>> * @param setterName The name of the setter - a public void method
SX> that
>> * takes the type as the argument
>> * @param objectToInject The object (not under the control of DS) to
>> * "inject"
>> */
>> public static void registerDependency(String serviceName, String
>> setterName, Object objectToInject) throws WhateverException;
>>
>> /**
>> * This method removes the dependency, for when the object is done
>> needing
>> * the service.
>> */
>> public static void unregisterDependency(String serviceName, Object
>> objectToInject) throws WhateverException;
>>
>> Obviously, the above is pseudo-code and I wouldn't mind having the
>> "registerDependency" return some form of object that can be used to
>> unregister the dependency later. I also wouldn't mind having the
>> registerDependency take some form of other object (e.g. BundleContext)
>> that it might need in order to make it work in OSGi. (However, one of
>> the design goals I have is to make any OSGi specific imports not
>> visible, so I would almost prefer some sort of wrapper or even
>> name-based mechanism).
>>
>> The basic idea is that independent object can register for injection
>> dynamically, and would not have to muck about in the OSGi API in order
>> to do service tracking or the like.
>>
>> Or perhaps there is already a way to do this with the current DS? I
>> looked at the spec and the API, but it is possible I missed something?
>> Thanks for helping me understand this a bit more.
>>
>> And of course, I still need the DS like yesterday ;-).
>>
>> Anyway, have a nice day.
>>
>> John Wells (Aziz)
>> jwells@xxxxxxx
>> -----Original Message-----
>> From: equinox-dev-bounces@xxxxxxxxxxx
>> [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of BJ Hargrave
>> Sent: Tuesday, November 22, 2005 10:34 AM
>> To: Equinox development mailing list
>> Subject: Re: [equinox-dev] Roadmap?
>>
>> IBM is in the process of preparing a contribution of a Declarative
>> Services implementation (among other selected services). Stay tuned...
>>
>> I would have to say Declarative Service is the best to use. But in the
>> interest of full disclosure, I was the designer of Declarative
SX> Services
>> :-) I am also not very familiar with GBeans. But DS does fully
SX> integrate
>>
>> with the OSGi service model and has certain desirable performance
>> characteristics such as delayed activation.
>>
>> BJ Hargrave
>> Senior Technical Staff Member, IBM
>> OSGi Fellow and CTO of the OSGi Alliance
>> hargrave@xxxxxxxxxx
>> Office: +1 407 849 9117 Mobile: +1 386 848 3788
>>
>>
>>
>> "John Wells" <jwells@xxxxxxx>
>> Sent by: equinox-dev-bounces@xxxxxxxxxxx
>> 2005-11-22 10:00 AM
>> Please respond to
>> Equinox development mailing list
>>
>>
>> To
>> <equinox-dev@xxxxxxxxxxx>
>> cc
>>
>> Subject
>> [equinox-dev] Roadmap?
>>
>>
>>
>>
>>
>>
>> Is there a roadmap for Equinox, especially where it concerns the
>> compendium services of r4? In particular, I am interested in using
SX> the
>> Declarative Services Specification?
>>
>> I have been looking around to see if I could find information about it
>> (dss), but haven?t found anything other than a handful of mail in the
>> archive. In particular, I need to have a good idea when (if) dss is
>> going
>> to be implemented. I?ve even considered just implementing that part
SX> of
>> the specification myself in order to get it quicker.
>>
>> Also:
>>
>> Both DSS and GBeans are IoC frameworks. Does anyone have any opinions
>> on
>> which are easier to use? Better? Any pros/cons?
>>
>> John Wells (Aziz)
>> jwells@xxxxxxx
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>
>>
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>
SX> _______________________________________________
SX> equinox-dev mailing list
SX> equinox-dev@xxxxxxxxxxx
SX> https://dev.eclipse.org/mailman/listinfo/equinox-dev
SX> _______________________________________________
SX> equinox-dev mailing list
SX> equinox-dev@xxxxxxxxxxx
SX> https://dev.eclipse.org/mailman/listinfo/equinox-dev
SX> _______________________________________________
SX> equinox-dev mailing list
SX> equinox-dev@xxxxxxxxxxx
SX> https://dev.eclipse.org/mailman/listinfo/equinox-dev
SX> _______________________________________________
SX> equinox-dev mailing list
SX> equinox-dev@xxxxxxxxxxx
SX> https://dev.eclipse.org/mailman/listinfo/equinox-dev
SX> _______________________________________________
SX> equinox-dev mailing list
SX> equinox-dev@xxxxxxxxxxx
SX> https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
Peter Kriens Tel +33870447986
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
