Re: [equinox-dev] OSGiServiceSupplier

[Alex Blewitt]

>>> 
>>>public  Function createFunction(BiFunction f) {
>>>return (v) -> {
>>>ServiceReference reference = 
>>> this.context.getServiceReference(this.serviceType);
>>>    if( reference != null ) {
>>>S service = this.context.getService(reference);
>>>try {
>>>return f.apply(v,service);
>>>} finally {
>>>this.context.ungetService(reference);
>>>}
>>> 
>>>}
>>>return (R)null;
>>>};
>>>}
>>> 
>>>public static void main(String[] args) {
>>>OSGiServiceWrapper options = 
>>> OSGiServiceWrapper.create(OSGiServiceWrapper.class, DebugOptions.class);
>>>Function f = options.createFunction( (o,s) -> {
>>>return s.getBooleanOption(o, true);
>>>} );
>>>f.apply("Test");
>>>}
>>> }
>> 
>> Tom
>> 
>>> On 25.09.15 23:42, Alex Blewitt wrote:
>>> BTW I updated the examples in my blog post to use AutoClosable and have
>>> a finalize method. So Tom’s comments below reflected the version before
>>> I made those changes.
>>> 
>>>> On 25 Sep 2015, at 22:20, Alex Blewitt >>> <mailto:alex.blew...@gmail.com>> wrote:
>>>> 
>>>> Thanks for the feedback. I didn’t claim that they followed best OSGi
>>>> practice but you make valid points about the ServiceTracker not being
>>>> closed. A finalize method will help with that, though will defer the
>>>> cleanup to a different part.
>>>> 
>>>> The problem, of course, is that the java.util.function.Supplier has no
>>>> way of codifying a ‘close’ type resource (though perhaps this might be
>>>> modified if the tracker variant implements AutoClosable?).
>>>> 
>>>> However, there’s a lot of cruft in Eclipse generally that are doing
>>>> this kind of pattern anyway. For example, the ContextsActivator
>>>> 
>>>> https://github.com/eclipse/eclipse.platform.runtime/blob/master/bundles/org.eclipse.e4.core.contexts/src/org/eclipse/e4/core/internal/contexts/osgi/ContextsActivator.java
>>>> 
>>>> sets up a debug tracker and starts/stops it in the Activator (which
>>>> I’m trying to remove). Yet the code only gets used in DebugHelper:
>>>> 
>>>> https://github.com/eclipse/eclipse.platform.runtime/blob/master/bundles/org.eclipse.e4.core.contexts/src/org/eclipse/e4/core/internal/contexts/DebugHelper.java
>>>> 
>>>> and even then it only calls it in a static block, once.
>>>> 
>>>> So what’s happened here is:
>>>> 
>>>> * Someone read up on ‘best practices’
>>>> * They set up a tracker
>>>> * They initialised it in the start and stop in the activator, as best
>>>> practice suggests
>>>> * They used it in an irrelevant way because that was the easiest way
>>>> to get the service
>>>> 
>>>> I argue that in this specific case, it’s better to perform a one-off
>>>> lookup of the service instead of keeping a tracker for evermore:
>>>> 
>>>> https://git.eclipse.org/r/#/c/56739/1/bundles/org.eclipse.e4.core.contexts/src/org/eclipse/e4/core/internal/contexts/DebugHelper.java
>>>> 
>>>> (Subsequent patch removes the class completely because it’s never used …)
>>>> 
>>>> I argue that acquiring a service with a Supplier moves the
>>>> implementation from how to pick up the service into the implementation
>>>> instead of the class. In this case, the single-shot approach can be used.
>>>> 
>>>> On the other hand, something like FrameworkLog is probably something
>>>> to keep around for a while instead of looking up each time.
>>>> 
>>>> https://git.eclipse.org/r/#/c/56582/2/bundles/org.eclipse.e4.core.di/src/org/eclipse/e4/core/internal/di/osgi/LogHelper.java
>>>> 
>>>> These are in static references already (mainly to avoid the problems
>>>> with looking up services the whole time). These methods are repeated
>>>> time and time again throughout the Eclipse codebase. Yes, you can
>>>> argue it’s not best practice, and yes you can argue that DS is
>>>> probably better in most cases. But I can only delete code so quickly :)
>>>> 
>&g

Re: [equinox-dev] OSGiServiceSupplier

[Alex Blewitt]

BTW I updated the examples in my blog post to use AutoClosable and have a 
finalize method. So Tom’s comments below reflected the version before I made 
those changes.

> On 25 Sep 2015, at 22:20, Alex Blewitt  wrote:
> 
> Thanks for the feedback. I didn’t claim that they followed best OSGi practice 
> but you make valid points about the ServiceTracker not being closed. A 
> finalize method will help with that, though will defer the cleanup to a 
> different part.
> 
> The problem, of course, is that the java.util.function.Supplier has no way of 
> codifying a ‘close’ type resource (though perhaps this might be modified if 
> the tracker variant implements AutoClosable?).
> 
> However, there’s a lot of cruft in Eclipse generally that are doing this kind 
> of pattern anyway. For example, the ContextsActivator
> 
> https://github.com/eclipse/eclipse.platform.runtime/blob/master/bundles/org.eclipse.e4.core.contexts/src/org/eclipse/e4/core/internal/contexts/osgi/ContextsActivator.java
>  
> <https://github.com/eclipse/eclipse.platform.runtime/blob/master/bundles/org.eclipse.e4.core.contexts/src/org/eclipse/e4/core/internal/contexts/osgi/ContextsActivator.java>
> 
> sets up a debug tracker and starts/stops it in the Activator (which I’m 
> trying to remove). Yet the code only gets used in DebugHelper:
> 
> https://github.com/eclipse/eclipse.platform.runtime/blob/master/bundles/org.eclipse.e4.core.contexts/src/org/eclipse/e4/core/internal/contexts/DebugHelper.java
>  
> <https://github.com/eclipse/eclipse.platform.runtime/blob/master/bundles/org.eclipse.e4.core.contexts/src/org/eclipse/e4/core/internal/contexts/DebugHelper.java>
> 
> and even then it only calls it in a static block, once.
> 
> So what’s happened here is:
> 
> * Someone read up on ‘best practices’
> * They set up a tracker
> * They initialised it in the start and stop in the activator, as best 
> practice suggests
> * They used it in an irrelevant way because that was the easiest way to get 
> the service
> 
> I argue that in this specific case, it’s better to perform a one-off lookup 
> of the service instead of keeping a tracker for evermore:
> 
> https://git.eclipse.org/r/#/c/56739/1/bundles/org.eclipse.e4.core.contexts/src/org/eclipse/e4/core/internal/contexts/DebugHelper.java
>  
> <https://git.eclipse.org/r/#/c/56739/1/bundles/org.eclipse.e4.core.contexts/src/org/eclipse/e4/core/internal/contexts/DebugHelper.java>
> 
> (Subsequent patch removes the class completely because it’s never used …)
> 
> I argue that acquiring a service with a Supplier moves the implementation 
> from how to pick up the service into the implementation instead of the class. 
> In this case, the single-shot approach can be used.
> 
> On the other hand, something like FrameworkLog is probably something to keep 
> around for a while instead of looking up each time.
> 
> https://git.eclipse.org/r/#/c/56582/2/bundles/org.eclipse.e4.core.di/src/org/eclipse/e4/core/internal/di/osgi/LogHelper.java
>  
> <https://git.eclipse.org/r/#/c/56582/2/bundles/org.eclipse.e4.core.di/src/org/eclipse/e4/core/internal/di/osgi/LogHelper.java>
> 
> These are in static references already (mainly to avoid the problems with 
> looking up services the whole time). These methods are repeated time and time 
> again throughout the Eclipse codebase. Yes, you can argue it’s not best 
> practice, and yes you can argue that DS is probably better in most cases. But 
> I can only delete code so quickly :)
> 
> On the plus side, I am making progress in such situations - for example, I 
> decoupled static references from contenttype and moved from bundle-activator 
> lookups to references passed in from declarative services as well.
> 
> https://git.eclipse.org/r/#/c/54290/ <https://git.eclipse.org/r/#/c/54290/> 
> https://git.eclipse.org/r/#/c/54257/ <https://git.eclipse.org/r/#/c/54257/>
> 
> I agree that the get/unget combo will cause oscillations; but the options are 
> between going from zero to one and to zero again, or going from zero to one 
> and leaking that way. 
> 
> In summary;
> 
> * Yes, they could be improved
> * No, they don’t exhibit best OSGi practices
> * This code is being used in Eclipse platform whether or not there is a 
> standard implementation for the above or not
> * They are intended to replace patterns where existing services are kept for 
> the lifetime of the bundle anyway
> * For one-shot services (such as debugoptions usecases) a servicetracker is 
> probably overkill anyway
> * For ongoing or frequent uses, the servicetracker option will probably be 
> the best. Such references are (commonly) stored in static variables at the 
> moment, which will be coupled with the lifeti

Re: [equinox-dev] OSGiServiceSupplier

[Alex Blewitt]

k by having a finalize() method that closes the tracker, but usually 
> finalize() methods are not recommended best-practice.
> 
> The OSGiSupplier is better but it has the unfortunate side-effect of 
> ungetting the service object before even returning it to the client code for 
> its first usage.  In general this is not using good practices in OSGi because 
> the service registration may be using a ServiceFactory that needs to track 
> the state of the using bundles.  Such usage on a ServiceFactory registration 
> will cause the service usecount for the bundle to osilate between one and 
> zero within the get() method.  Each time the usecount goes to zero the 
> service object is thrown away by the framework, then on next usage the 
> service object will have to be recreated by the factory.  This could result 
> in a performance issue if the creating of the service object is expensive.
> 
> The classes may have their uses in specific cases and not cause issues if 
> used in a specific way.  For example, if you know for a fact that the service 
> you are getting is not stateful and does not use a ServiceFactory.  Or if you 
> make sure to use the OSGiTracker in an object that has a one-to-one 
> relationship with the active lifecycle of the bundle.  I am not sure they 
> belong down in Equinox though because I do not believe they promote 
> best-practices when dealing with the OSGi service registry.
> 
> I also wonder if the latest DS specification helps deal with some of the 
> short-comings you mention in your blog.
> 
> Finally I do thank you for proposing a solution to a problem and bringing it 
> here for discussion, I just don't feel comfortable with the current solution 
> :-)
> 
> Tom
> 
> 
> 
> 
> 
> From:Alex Blewitt 
> To:Equinox development mailing list 
> Date:09/25/2015 01:33 PM
> Subject:[equinox-dev] OSGiServiceSupplier
> Sent by:equinox-dev-boun...@eclipse.org
> 
> 
> 
> I posted on http://alblue.bandlem.com/2015/10/osgi-services-in-java-8.html 
> <http://alblue.bandlem.com/2015/10/osgi-services-in-java-8.html>earlier today 
> about using Java 8’s Supplier to acquire a service on-demand without having 
> to do expensive client-side coding, and that would fail fast in the absence 
> of any OSGi classes and return null in such situations.
> 
> I’d like to contribute this to Eclipse so that it can be used in places where 
> Declarative Services aren’t the right solution (specifically; for integrating 
> in where places have static Log or DebugOptions classes).
> 
> Which would be the right project/bundle to contribute this into? Clearly it 
> could go into something like Platform or Core.runtime, but I wondered if it 
> might be sensible to have this in equinox.util or equivalent.
> 
> Alex___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/equinox-dev 
> <https://dev.eclipse.org/mailman/listinfo/equinox-dev>
> 
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] OSGiServiceSupplier

[Alex Blewitt]

I posted on http://alblue.bandlem.com/2015/10/osgi-services-in-java-8.html 
 earlier today 
about using Java 8’s Supplier to acquire a service on-demand without having to 
do expensive client-side coding, and that would fail fast in the absence of any 
OSGi classes and return null in such situations.

I’d like to contribute this to Eclipse so that it can be used in places where 
Declarative Services aren’t the right solution (specifically; for integrating 
in where places have static Log or DebugOptions classes).

Which would be the right project/bundle to contribute this into? Clearly it 
could go into something like Platform or Core.runtime, but I wondered if it 
might be sensible to have this in equinox.util or equivalent.

Alex___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] dependency on org.osgi.annotation?

[Alex Blewitt]

There are Eclipse-specific classes in o.e.osgi such as NLS and Debug which 
makes it hard to do what you suggest, especially since these are provided in a 
supplements bundle which cannot co exist in an eclipse runtime. 

Alex

Sent from my iPhat 6

> On 8 May 2015, at 09:21, BJ Hargrave  wrote:
> 
> > From: Stephan Herrmann  
> 
> > On 05/07/2015 05:21 PM, BJ Hargrave wrote:
> > >  > User has an arbitrary plugin project which obviously depends 
> > > ono.e.osgi.
> > >
> > > Well I would say that no one should depend upon org.eclipse.osgi. 
> > It is an implementation of the OSGi core spec. If you are writing
> > > bundles, then you are dependent on the OSGi API and should put 
> > osgi.core and possibly osgi.annotation on your compile path. These
> > > jars are available from OSGi Alliance website, Maven Central, 
> > JCenter, ... and include their source.
> > 
> > Are you saying no-one should use type org.osgi.framework.Bundle, 
> > forexample??? 
> 
> Of course not. I am saying you need to compile against API jars (e.g. 
> osgi.core, osgi.annotation) and not against implementation jar (e.g. 
> org.eclipse.osgi). I do this all the time (with bnd/bndtools and not PDE) and 
> don't have the issues you raise here. 
> 
> > You read "depends" and think of a dependency declared by OSGi means,
> > but that's not what I was saying. I'm speaking of the situation of
> > all plug-in developers using Eclipse PDE + JDT (independent of whether
> > you like PDE or not). 
> 
> Well PDE is the source of the problem since it uses the manifest as both a 
> build input and a build output. 
> 
> > 
> > 
> > > Perhaps JDT is a bit too sensitive for what it not a real 
> > compilation but instead just providing hover information.
> > 
> > You're interpretation of "compile" is narrower, than what I'm talking about.
> > 
> > Let me explain:
> > Eclipse has a single component, which is responsible for many tasks,
> > from creating detailed information for various views and hovers,
> > over providing the precise semantic information for refactoring,
> > up-to producing executable class files. We traditionally call this
> > component the "compiler".
> > The compiler *must* report any failed attempt to resolve a type. 
> 
> Well the failed attempt to resolve a type is only an issue if the purpose is 
> to create a class file. But if it is to provide hover information, then the 
> missing types are not fatal. It is just reduced information available to the 
> hover information. 
> 
> > You seem to be saying, Eclipse shouldn't use the compiler in this way,
> > but that discussion is moot.
> > 
> > >  > BTW, when I classified ProviderType as API, I certainly wasn't implying
> > >  > "runtime" API. These things are compile time API, just like @NonNull
> > >  > (which, too, has retention CLASS).
> > >
> > > It is necessary to compile the source. But what you are describing
> > is not really compiling the source but using the source to
> > > provide some hover information. So missing things should not blow 
> > the whole thing up since it is not a real compilation.
> > 
> > You're missing the analogy to @NonNull.
> > There is one more perspective between *building* o.e.osgi and *runtime*:
> > Client compilation. 
> 
> Well my point is the clients should not compile against an implementation: 
> org.eclipse.osgi. They should compile against the API. 
> 
> > But as mentioned: this is a different discussion than how to reconcile
> > the incomplete artifact o.e.osgi with JDT. 
> 
> I guess we disagree that org.eclipse.osgi is "incomplete". As an 
> implementation, it is fully complete. It should not be used as a compile time 
> dependency. 
> 
> > 
> > 
> > I was hoping that this list could be the place for discussing,
> > how to improve the experience when developing Equinox bundles
> > within the Eclipse IDE with PDE and JDT. 
> 
> Well I suggest that (1) JDT not have a fatal error here since the goal is not 
> to generate a class file and (2) PDE should (a) not use manifest as a build 
> input (but I realize that will not happen since PDE is what it is and why I 
> don't use it) and (b) support a way to specify compile dependencies different 
> than runtime dependencies so you can compile against OSGi API and not OSGi 
> implementation. 
> 
> --
> BJ Hargrave
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the OSGi Alliance
> hargr...@us.ibm.com   
> 
> office: +1 386 848 1781
> mobile: +1 386 848 3788
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Bundles remaining in life cyle "Starting".

[Alex Blewitt]

I think they’re placed into that state if they are lazily started, i.e. they 
have a BundleActivationPolicy of ‘lazy’. 

http://www.osgi.org/Design/LazyStart
http://wiki.osgi.org/wiki/Bundle-ActivationPolicy

I think it goes from ‘starting’ to ‘started’ when classes have been loaded from 
the bundle.

Alex

On 7 May 2015, at 22:31, Lars Vogel  wrote:

> Hi,
> 
> I frequently see lots of bundles remaining in the life cyle status 
> "Starting". Is this expected? I would assume that "Starting" is a temporary 
> status and that once a bundle has finished starting, it becomes "Active".
> 
> Best regards, Lars
> 
> -- 
> 
> Eclipse Platform and e4 project co-lead
> vogella GmbH CEO
> 
> Haindaalwisch 17a, 22395 Hamburg
> Amtsgericht Hamburg: HRB 127058
> Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
> USt-IdNr.: DE284122352
> Fax (032) 221739404, Email: lars.vo...@vogella.com, Web: 
> http://www.vogella.com
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Equinox DS Performance Problem

[Alex Blewitt]

It would be better to create a bug report at bugs.eclipse.org and attach the 
files and description there. 

Alex

Sent from my iPhat 6

> On 25 Nov 2014, at 21:26, Colin Williams  wrote:
> 
> Hi everyone,
> 
> This is a follow-up to my forum post [1], because I have more information now 
> and firmly believe this is a problem with Equinox, and not my code. I have a 
> simplified test case that duplicates the problem [2], and have verified that 
> Felix does not exhibit the same behavior.
> 
> When firing up a new instance of a Declarative Services component, either a 
> regular component or a newInstance of a ComponentFactory, Equinox checks for 
> dependency cycles ([3] and [4], for regular components and component factory 
> instances, respectively). Unfortunately, it does this by walking the entire 
> list of components and factory instances to check for dependencies, and then 
> walking the entire dependency graph to check for cycles (see [5] and [6]). 
> After checking for cycles, it then walks the entire list again [7] to check 
> for components that may need to be disabled based on the new dependency 
> graph. 
> 
> Now, I'm not sure why the dependency cycle checking is necessary when 
> activating a new factory instance, since presumably it would have been 
> checked when the component was resolved or at least the first time an 
> instance of that factory was created. Even if it is necessary every time, 
> though, wouldn't it only be necessary to check the portion of the dependency 
> graph that is reachable from the new instance, rather than the entire 
> dependency graph of all enabled components? And then furthermore, wouldn't it 
> only be necessary to check the same list of potentially affected components 
> for ones that need to be disabled, rather than all of them? 
> 
> As a result of this, Equinox exhibits O(n^2) runtime in activating new 
> components or creating new instances of factory components, based on the 
> number of components in the runtime and the complexity of the dependency 
> graph. In my test case [2], a fairly simple dependency graph (B->C->D), which 
> is then referenced by 3000 factory instances (A->B), takes minutes to start 
> because of this (see [9]). Adding this bundle to a Felix container results in 
> Felix starting the bundle and all 3000 factories instantly. 
> 
> I will say that I'm not particularly familiar with the Equinox internals, but 
> I have added timing information into a local copy of the DS project, and can 
> verify that findDependencyCycles and resolveEligible both take an excessive 
> amount of time, proportionate to the number of total components in the 
> system. I'm also not very familiar with the Felix internals, but I can't see 
> that Felix does any dependency cycle checking when creating a new factory 
> instance ([8]). 
> 
> I hope this was detailed enough to explain the problem I'm experiencing. Can 
> anyone verify that this is an issue, or explain why it needs to be done? Or 
> offer workaround suggestions to allow us to still use DS ComponentFactories 
> with more than a few hundred services/factories?
> 
> Thanks,
> --Colin
> 
> [1] - https://www.eclipse.org/forums/index.php/t/868856/
> [2] - Attached
> [3] - 
> http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/bundles/org.eclipse.equinox.ds/src/org/eclipse/equinox/internal/ds/Resolver.java#n476
> [4] - 
> http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/bundles/org.eclipse.equinox.ds/src/org/eclipse/equinox/internal/ds/Resolver.java#n1042
> [5] - 
> http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/bundles/org.eclipse.equinox.ds/src/org/eclipse/equinox/internal/ds/Resolver.java#n1073
> [6] - 
> http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/bundles/org.eclipse.equinox.ds/src/org/eclipse/equinox/internal/ds/Resolver.java#n1140
> [7] - 
> http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/bundles/org.eclipse.equinox.ds/src/org/eclipse/equinox/internal/ds/Resolver.java#n511
> [8] - 
> https://github.com/apache/felix/blob/trunk/scr/src/main/java/org/apache/felix/scr/impl/manager/ComponentFactoryImpl.java#L120
> [9] - http://pastebin.com/CNrHFE8C
> [10] - http://pastebin.com/mb3AbP2S
> 
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Equinox console not working

[Alex Blewitt]

The built-in console was removed, as per the release notes.

Built-in Equinox OSGi console removed


On 9 Oct 2014, at 12:30, Artem Zhirkov  wrote:

> Hello,
> 
> I've just downloaded the recent release version of equinox and tried to 
> follow the quick start guide, but even launching OSGI console didn't work for 
> me.
> I tried to launch it like that:
> 
> $ java -jar org.eclipse.osgi_3.10.1.v20140909-1633.jar -console
> 
> and it didn't return anything, it seems like it launched but not returned a 
> console.
> 
> I'm running ubuntu 14.04 x64 and have OpenJDK Runtime Environment (IcedTea 
> 2.5.2) (7u65-2.5.2-3~14.04) installed.
> 
> Any suggestions?
> 
> Best regards
> 
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Composite repository entry that does not bring in categories

[Alex Blewitt]

No, this is not possible with P2. You can however mirror the repository then 
strip out the categories from the file though. 

Alex

Sent from my iPhone 5

> On 7 Aug 2014, at 20:25, "Konstantin Komissarchik" 
>  wrote:
> 
> Sending this question to the dev mailing list since I didn’t get any response 
> on the forum and other channels. Would appreciate a response, even if it’s of 
> the “we can’t do that right now” nature.
>  
> We need to add an entry to a p2 composite repository that does not merge the 
> feature categorization from the referenced repository. Basically, we need to 
> content of the repo to be accessible for dependency resolution, but not 
> present to the user of the composite for selection.
> 
> Is that possible?
>  
> Thanks,
>  
> - Konstantin
>  
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] 32bit vs 64bit launcher

[Alex Blewitt]

You might find that a wow64 launch of Eclipse 32 should work, but to do so 
needs to know its in 32 bit mode. I believe that the auto detection will still 
think it's in 64 bit mode even with 32 bit wow and so the 32 bit launcher looks 
for the 64 bit library and then fails to load or not find it. 

You may find running with -Dosgi.arch=x86 will allow you to launch as 32bit 
depending on which part of the process is doing the incorrect detection. 

Alex

Sent from my iPhone 5

> On 16 Jul 2014, at 18:18, Thomas Watson  wrote:
> 
> I don't think the source is going to shed light on your issue but you can 
> find it here [1]
> 
> The issue is that the 64-bit eclipe.exe is not able to load the 32-bit 
> version of the library eclipse_1310.so and vise versa.
> 
> Tom
> 
> [1] 
> http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/features/org.eclipse.equinox.executable.feature/library
> 
> 
> Ji Hoon Baik ---07/16/2014 11:32:19 AM---Gents, Any help will be 
> much appreciated on this matter.
> 
> From: Ji Hoon Baik 
> To:   equinox-dev@eclipse.org
> Date: 07/16/2014 11:32 AM
> Subject:  [equinox-dev] 32bit vs 64bit launcher
> Sent by:  equinox-dev-boun...@eclipse.org
> 
> 
> 
> Gents,
>  
> 
> Any help will be much appreciated on this matter.
> 
>  
> 
> Our firm is in the process of migrating from 32-bit to 64-bit machines, and 
> my team is refitting our RCP app to run on 64-bit machine.
> 
> Initially our RCP app was failing to launch on 64-bit Win7, and we soon found 
> out that using the x86_64 version of the equinox launcher solved the problem.
> 
>  
> 
> However, we wanted to understand why we weren’t able to run our app while 
> still using the x32 equinox launcher.
> 
> We thought WOW64 should technically emulate 32-bit env and allow this library 
> to run without problems.
> 
> To find an answer, we also looked for source code for eclipse_1310.so jar 
> (3.6’s shared dll), but to no avail.
> 
>  
> 
> Would you be able to shed some light on this matter kindly?
> 
> 1.   What does this eclipse_1310.so do (and can we get the source code 
> for it?)
> 
> 2.   What in it makes it necessary to keep 32-bit and 64-bit versions?
> 
>  
> 
> Jason Baik  I  IT - CFT Sales
> 
>  
> 
> From: Baik, Jason : Investment Bank (NYK) 
> Sent: Wednesday, July 16, 2014 11:20 AM
> Subject: Theories for why SWS is not running with 32-bit launcher
> 
>  
> 
> Reading further, I think it can be two things:
> 
>  
> 
> 1. eclipse_1017.dll contains code that must run in kernel mode
> 
>  
> 
> “Since WOW64 runs in user mode, all 32-bit application code must also run in 
> user mode. This explains why 32-bit kernel mode device drivers and 
> applications that rely on them, will not work under Windows 64-bit.”
> 
>  
> 
> http://www.techsupportalert.com/content/how-windows7-vista64-support-32bit-applications.htm
> 
>  
> 
>  
> 
> 2. Say eclipse_1017.dll runs entirely in user mode and can run on Win7 via 
> WOW64. However, if the 32-bit and 64-bit eclipse_1017.dll’s have different 
> search paths for JVMs, SWS might be failing to start due to the inability to 
> find a JVM.
> 
>  
> 
> “No -vm specified
> 
> When no -vm is specified, the launcher looks for a virtual machine first in a 
> jre directory in the root of eclipse and then on the search path. If java is 
> found in either location, then the launcher looks for a jvm shared library 
> (jvm.dll on Windows, libjvm.so on *nix platforms) relative to that java 
> executable.
> 
>  
> 
> If a jvm shared library is found the launcher loads it and uses the JNI 
> invocation API to start the vm.
> 
> If no jvm shared library is found, the launcher executes the java launcher to 
> start the vm in a new process”
> 
>  
> 
> http://help.eclipse.org/kepler/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/launcher.html
> 
>  
> 
>  
> 
> If #2 is true, this probably proves why there’s no sign of JVM launching when 
> our SWS fails on Win7.
> 
> it might be worth experimenting:
> 
>  
> 
> 1.   Check Windows system logs to see if eclipse_1017.dll throws any 
> errors 
> 
> 2.   Provide an eclipse.ini file that specifies the 32 bit JVM location 
> explicitly and try launching.___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> 
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] State of Gerrit jobs

[Alex Blewitt]

On 17 Mar 2014, at 21:32, Gunnar Wagenknecht  wrote:

> On 2014-03-16 17:06:33 +, Mickael Istria said:
>> I don't think it's that much a matter of resource, it's more that you're the 
>> first one to report this issue. Did you open a bug for it?
> 
> So there were only two earlier builds:
> - one in February
> - one in December
> 
> Both were failing as well. I think that by itself is pretty good evidence 
> that the team does not use Gerrit. Why should it be thrown in the face of 
> poor contributors then? That's like being more holier than the pope.
> 
> BTM, the issue has something to do with the complicated platform build. 
> People knowing that will also understand that's a time sink. I bet it never 
> worked or only worked by accident when the Gerrit trigger was set up. Anyway, 
> the build issue - as I've been told - is not new. Thus I didn't report it as 
> a new bug.

One of those was mine, and I was concerned that it hadn’t been applied, which 
is why I asked if it was successful. 

https://git.eclipse.org/r/#/c/19484/

It turns out that the change was manually cherry picked into the Equinox 
codebase, even though the build in Gerrit was marked as failed and the bug is 
still showing as open in my bundles review:

https://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=35033c8021dde91c3dab707604ceb3df689a7d10

https://git.eclipse.org/r/#/q/is:open+owner:%22Alex+Blewitt+%253Calex.blewitt%2540gmail.com%253E%22,n,z

So yes, it’s clear that the Equinox project doesn’t use Gerrit.

Alex
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Simpler JavaFX class loading

[Alex Blewitt]

Can you not just install a fragment to the system bundle that exports the 
javafx packages?

Sent from my iPhone 5

> On 25 Feb 2014, at 16:15, Doug Schaefer  wrote:
> 
> Hey gang,
> 
> I’m aware of the work Tom S has done with class loading hooks to get JavaFX 
> classes to load. I’m just wondering if there are easier approaches we could 
> be following, something we can put in the JavaSE-1.8.profile file or 
> somewhere else so that we can make this a more data driven approach. It’s a 
> pain to have to set the osgi.framework.extensions property for every product 
> we want to build with JavaFX support. I’m aware that not every 1.8 VM will 
> have JavaFX in it, but for those that do, I’d love to see this support 
> enabled automagicly. Any thoughts?
> 
> Thanks,
> Doug.
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] How to use web services in an Equinox OSGi container.

[Alex Blewitt]

On 21 Apr 2013, at 10:44, Prasad Jeewantha wrote:

> I need to develop an application with back-end and front-end clearly 
> separated through web services. The BE and FE of the application should run 
> on two separate JVMs in two Equinox containers. The BE-FE communication 
> happens through webservices. Is there any recommended way to do this? I came 
> across Apache-CXF which provides a framework for webservices. Please tell me 
> if/how Equinox be integrated with Apache-CFX. Any help is appreciated.
> Thanks,
> PJ.
> 
> PS: please see my SO question on this. 
> http://stackoverflow.com/q/16129590/1411653

Yes, it is possible to do this in any OSGi runtime (whether Felix or Equinox). 
However, this is not an Equinox specific issue. Please see the examples at the 
Apache-CXF pages for distributed OSGi: 
http://cxf.apache.org/distributed-osgi.html

Alex

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] bundles wiring and redeployment issues - hotswap

[Alex Blewitt]

You can't. You have a binding on the MyBean class in the code of both B and C 
so you are pinned to exactly that version. 

Alex 

Sent from my iPhone 4S

On 30 Jan 2013, at 16:47, "matteo rulli"  wrote:

> I'm facing the following issue under OSGi environment: let's say I have a 
> bundle A exporting com.mybiz.example package. This package, in its 1.0.0 
> version, contains a bean class MyBean so that
>  
> public class MyBean {
>  int var;
>  public MyBean() { }
>  public int getVar() { return var; }
>  public void setVar(int v) { var = v; }
> }
>  
> Bundle B exports an interface MyService which uses MyBean:
>  
> public interface MyService {
>  public MyBean getMyBean();
> }
>  
> Note: in our architecture, MyBean must be a class and not an interface.
>  
> Bundle C uses MyService as a declarative service in this way:
>  
> private AtomicReference _serv = new 
> AtomicReference();
> public void addMyService(MyService serv) {
>  //this method is the one called by declarative services when Bundle B is 
> started
>  _serv.set(serv);
> }
>  
> public void run() {
>  ...
> 
>  MyBean x = _serv.getMyBean();
>  //use x ...
> }
>  
> Now the problem arises if I need to do a hot fix on MyBean class.
> Let's say I need to add a field and some methods.
> Then, I've got a running OSGi environment where bundles A,B,C are deployed.
>  
> My requirement is that I cannot stop any bundle.
>  
> So, under these hypotheses, I deploy a new version of my bundle A, say 
> A_1.1.0.jar. Now I'm not able to make bundle C to use the new version of 
> MyBean class contained in A_1.1.0.jar.
>  
> How can I do it?
>  
> Thank you very much!
>  
> Best regards,
> matteo
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] TrustEngine and other security services

[Alex Blewitt]

If you need an example that is publicly available, the Apache Directory Studio 
plugin is signed with an Apache certificate that shows up as untrusted when I 
attempt to install it:

http://directory.apache.org/studio/update/1.x/

On Eclipse 4.2, the pop-up window asking to trust easily gets hidden and can't 
be called back again, which means that the installation of that (and anything 
else in the same provisioning operation) fails. 

Alex

On 3 Jan 2013, at 14:55, John Arthorne wrote:

> I really don't remember the details here. I suspect once we got all Eclipse 
> projects signing with a real cert verified by an authority trusted by the 
> JVM, this wasn't a big issue for us. In the end, asking an end user to make a 
> trust decision on a self-signed or unverified cert is silly anyway. There is 
> no way an end user could make an informed trust decision based on that 
> information, and if we did persist the decision, it would essentially be "I 
> know it's not trusted but please stop asking me". It looks like 
> KeyStoreTrustEngine registered by the framework is capable of persisting 
> changes though, if the system is configured properly. If Scott or anyone else 
> is interested in the trust persistence aspect I suggest opening a bug and we 
> go from there. 
> 
> John 
> 
> 
> 
> From:Thomas Watson  
> To:Equinox development mailing list , 
> Date:01/02/2013 10:20 AM 
> Subject:Re: [equinox-dev] TrustEngine and other security services 
> Sent by:equinox-dev-boun...@eclipse.org 
> 
> 
> 
> Thanks John,
> 
> I see that the code you mention does use a TrustEngine to attempt to persist 
> newly trusted certificates.  But I wonder if there are any implementations of 
> the TrustEngine service that are not read-only.  The framework registers a 
> built-in TrustEngine that is backed by the CA certs that are configured with 
> the VM but this TrustEngine is read-only.
> 
> Tom
> 
> 
> 
> John Arthorne ---01/02/2013 08:43:48 AM---p2 uses the 
> TrustEngine to persist newly trusted certificates after  prompting the user. 
> See org.ecl
> 
> From: John Arthorne 
> To: Equinox development mailing list , 
> Date: 01/02/2013 08:43 AM
> Subject: Re: [equinox-dev] TrustEngine and other security services
> Sent by: equinox-dev-boun...@eclipse.org
> 
> 
> 
> p2 uses the TrustEngine to persist newly trusted certificates after prompting 
> the user. See 
> org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker. 
> 
> http://git.eclipse.org/c/equinox/rt.equinox.p2.git/tree/bundles/org.eclipse.equinox.p2.engine/src/org/eclipse/equinox/internal/p2/engine/phases/CertificateChecker.java
>  
> 
> John 
> 
> 
> 
> From:Thomas Watson  
> To:Equinox development mailing list , 
> Date:01/02/2013 09:28 AM 
> Subject:Re: [equinox-dev] TrustEngine and other security services 
> Sent by:equinox-dev-boun...@eclipse.org 
> 
> 
> 
> The TrustEngine is largely used as an implementation detail behind the 
> org.eclipse.osgi.signedcontent package.  OSGi services published with using 
> the org.eclipse.osgi.service.security.TrustEngine interface are used to 
> determine the authenticity of a certificate chain used to sign content (jars, 
> bundles etc.).  I did not remember p2 using the TrustEngine directly, but 
> perhaps it does for authenticating other types of certificates.
> 
> Sorry, other than the javadoc published for the packages there is not a lot 
> of documentation here.
> 
> Tom
> 
> 
> 
> Pascal Rapicault ---12/29/2012 03:51:46 AM---The p2 
> engine makes use of the TrustEngine, however I don't remember the details of 
> how it works. Yo
> 
> From: Pascal Rapicault 
> To: Equinox development mailing list , 
> Date: 12/29/2012 03:51 AM
> Subject: Re: [equinox-dev] TrustEngine and other security services
> Sent by: equinox-dev-boun...@eclipse.org
> 
> 
> 
> The p2 engine makes use of the TrustEngine, however I don't remember the 
> details of how it works.
> You may also want to poke around at other parts of p2 as I just happen to 
> remember about this ref in the engine, but there may be others.
> 
> HTH
> 
> Pascal
> 
> On 2012-12-29, at 5:47 AM, Scott Lewis wrote:
> 
> > Hello,
> > 
> > Is there documentation on Equinox security services like 
> > org.eclipse.osgi.service.security.TrustEngine service...and implementation? 
> >  I looked in the Equinox Security area [1], but didn't find a lot of 
> > service/API docs.   Is/are there examples of using the TrustEngine 
> > service(s)?
> > 
> > Thanks,
> > 
> > Scott
> > 
> > 
> > 
> > ___
> > equinox-dev mailing list
> > equinox-dev@eclipse.org
> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> 
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> 
> ___
> equinox-dev mailing list
> equinox-

Re: [equinox-dev] Equinox Framework and several bundles moving up to Java SE 5 in Kepler

[Alex Blewitt]

With the upgrade to Java 5 for Kepler, are we likely to see the use of generics 
across the platform increase, for example, for getting services and selections?

Alex

On 5 Oct 2012, at 23:39, Thomas Watson wrote:

> The following bundles (and framework) are moving up to Java SE 5 in Kepler M3:
> 
>   org.eclipse.osgi (the framework)
>   org.eclipse.equinox.supplement
>   org.eclipse.equinox.coordinator
>   org.eclipse.equinox.event
>   org.eclipse.equinox.metatype
> 
> The framework and these equinox bundles have long supported J2ME Foundation 
> VMs.  The OSGi R4.3 specification introduced generics to the API but we still 
> continued to support J2ME by using the jsr14 compiler flag to compile the 
> source into a binary that could still run on J2SE 1.4 based VMs (including 
> J2ME).  With Java 7 the compiler (javac not the eclipse compiler) no longer 
> supports class files compiled with the jsr14 option see [1] for more details. 
>  J2SE 1.4 has long been considered end of life and our ability to support 
> J2ME over the years has become more and more difficult.  Instead of 
> continuing to try and use the jsr14 flag we have decided to simply move up to 
> Java SE 5.  If Java 8 ends up including compact profiles [2] then we will of 
> coarse look to supporting the smallest profile possible.
> 
> Tom
> 
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=369145
> [2] http://openjdk.java.net/jeps/161
> 
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] extending the classpath of an embedded Framework

[Alex Blewitt]

On 30 Aug 2012, at 15:58, Raymond Auge  wrote:

> I think I'm going to try this (on the fly fragment creation)

I've done this in the past with great success, and it works on other OSGi 
runtimes as well so you're not depending on any Equinox specific tech to make 
it happen. You also get the full package binding list so you can see what 
bundles depend on which packages, and resolution failures when they are 
missing. 

Alex
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Service component deployment fails into a running Equinox application

[Alex Blewitt]

Do you have an optional import for the package name? 

If you do, and that bundle starts first, then it won't be wired to the package. 
If you start up the bundle containing the package first, then start up the 
provider, it will resolve the list of optional imports. Once started, even if 
an optional package is added later it's not added to the existing running 
bundle's package list. If you do a 'refresh' on the service provider, does the 
problem go away?

Alex

On 8 Feb 2012, at 09:38, Csaba Szucs wrote:

> Hello Guys,
> 
> I have an Equinox OSGi application using Declarative Services with 3 plugins:
> -a service interface plugin
> -a service provider component
> -a service consumer component (cardinality: 0..n, policy: dynamic)
> 
> Framework is launched.
> idState Bundle
> 0 ACTIVE org.eclipse.osgi_3.8.0.v20110908-1857
> 3 ACTIVE osgi.example.service.consumer_1.0.0.qualifier
> 4 ACTIVE org.eclipse.osgi.services_3.3.0.v20110711-1243
> 5 ACTIVE org.eclipse.equinox.util_1.0.300.v20110502
> 6 ACTIVE org.eclipse.equinox.ds_1.3.100.v20110705
> 10ACTIVE osgi.example.service_interface_1.0.0.qualifier
> 11ACTIVE osgi.example.service.implementation_1.0.0.qualifier
> 
> In case the application is launched, the service consumer is triggered.
> 
> But in case the service provider is installed and started only after the 
> application has launched, SCR fails to load service implementation class. See 
> exception stack below!
> 
> What is the problem with this runtime/post-application deployment of the 
> service component?
> 
> Please note:
> With Apache Felix and SCR, there is no problem with the runtime deployment at 
> all.
> 
> Many thanks, Csaba.
> 
> Framework is launched.
> idState Bundle
> 0 ACTIVE org.eclipse.osgi_3.8.0.v20110908-1857
> 3 ACTIVE osgi.example.service.consumer_1.0.0.qualifier
> 4 ACTIVE org.eclipse.osgi.services_3.3.0.v20110711-1243
> 5 ACTIVE org.eclipse.equinox.util_1.0.300.v20110502
> 6 ACTIVE org.eclipse.equinox.ds_1.3.100.v20110705
> 10ACTIVE osgi.example.service_interface_1.0.0.qualifier
> 
> osgi> install 
> file:/home/csaba/eclipse_distros/Indigo/workspace/osgi.example.service.implementation
> Bundle id is 11.
> 
> idState Bundle
> 11INSTALLED osgi.example.service.implementation_1.0.0.qualifier
> 
> osgi> start 11
> 
> Here SCR throws an exception:
> 
> 
> !SESSION 2012-02-06 21:01:12.378 
> ---
> eclipse.buildId=unknown
> java.version=1.6.0_20
> java.vendor=Sun Microsystems Inc.
> BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US
> Command-line arguments: -dev 
> file:/home/csaba/eclipse_distros/Indigo/workspace/.metadata/.plugins/org.eclipse.pde.core/New_configuration
>  (1)/dev.properties -os linux -ws gtk -arch x86 -consoleLog -console 
> -consolelog
> 
> !ENTRY org.eclipse.equinox.ds 4 0 2012-02-06 21:03:11.214
> !MESSAGE Exception occurred while creating new instance of component 
> Component[
> name = osgi.example.service.implementation
> activate = activate
> deactivate = deactivate
> modified = 
> configuration-policy = optional
> factory = null
> autoenable = true
> immediate = false
> implementation = osgi.example.service.implementation.ServiceImpl
> state = Unsatisfied
> properties = 
> serviceFactory = false
> serviceInterface = [osgi.example.service_interface.Service]
> references = null
> located in bundle = osgi.example.service.implementation_1.0.0.qualifier [13]
> ] 
> !STACK 0
> java.lang.ClassNotFoundException: 
> osgi.example.service.implementation.ServiceImpl
> at 
> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:513)
> at 
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:429)
> at 
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:417)
> at 
> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
> at 
> org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:345)
> at 
> org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:229)
> at 
> org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1208)
> at 
> org.eclipse.equinox.internal.ds.model.ServiceComponent.createInstance(ServiceComponent.java:480)
> at 
> org.eclipse.equinox.internal.ds.model.ServiceComponentProp.createInstance(ServiceComponentProp.java:271)
> at 
> org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:332)
> at 
> org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:588)
> at org.eclipse.equinox.internal.ds.ServiceReg.getService(ServiceReg.java:53)
> at 
> org.eclipse.osgi.internal.serviceregistry.ServiceUse$1.run(ServiceUse.java:141)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.eclipse.osgi.internal.serviceregistry.S

Re: [equinox-dev] Difference in system.packages.extra behaviour between 3.6.2 and 3.7

[Alex Blewitt]

See also the OSGi wiki page on http://wiki.osgi.org/wiki/Boot_Delegation

Alex

On Sep 8, 2011, at 13:42, Neil Bartlett wrote:


Hi Ben,

I tend to see this the other way around…. if you are using that
package then you should have an Import-Package statement for it. If
that causes problems for PDE then that's a bug in PDE, not in Equinox.

Regards,
Neil


On Thu, Sep 8, 2011 at 1:14 PM, Ben Cox   
wrote:

Hi All,

We're being affected by a difference between Equinox 3.6.2 and 3.7,  
and

can't quite work out whether it's caused by a bug fix, a bug being
introduced, or a change in the OSGi spec from 4.2 to 4.3.

Our code has been converted to use OSGi and runs purely on IBM  
JVMs, and as
such has dependencies on several IBM-specific packages of the JRE -  
for
example, com.ibm.CORBA.iiop. To ensure these are exported from the  
JRE by

the system bundle, we have added them to the
org.osgi.framework.system.packages.extra property.

We have set osgi.java.profile.bootdelegation=override and
org.osgi.framework.bundle.parent=app.

The problem is that at Equinox 3.6.2, our bundle is able to load a  
class
from com.ibm.CORBA.iiop without adding it to the Import-Package  
statement.
However, at 3.7, this is not possible. Instead, an Import-Package  
statement

is required (which makes it tricky to compile in PDE...)

Many thanks for your help,
Ben




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with  
number

741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire  
PO6 3AU






___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Custom manifest headers

[Alex Blewitt]

Note that the OSGi 4.3 spec introduces the concept of Require-Capability. 
Equinox has a pre implementation of this with the Eclipse-GenericRequire, which 
of course is not understood by Felix. As a result, Felix doesn't know that it's 
missing a requirement (so starts it) whilst Equinox 'obeys' the Eclipse 
specific header.

If your version of both Equinox and Felix supported the Require-Capability and 
this bundle used the Require-Capbility then you'd see the same behaviour in 
both places. 

Alex

On 19 Aug 2011, at 13:28, Kirchev, Lazar wrote:

> Hello,
>  
> I was experimenting with some bundles on Equinox and Felix and I observed a 
> case when one and the same bundle would start on Felix, but not on Equinox. 
> The reason was a custom manifest header, Eclipse-GenericRequire. Since this 
> is Eclipse-specific header, Felix ignores it and starts the bundle, although 
> there is no bundle providing such capability. Equinox detects that no bundle 
> provides the capability and does not start the bundle.
>  
> I was wondering doesn’t this represent an incompatibility between the OSGi 
> implementations?
>  
> Regards,
> Lazar
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Eclipse and Equinox 3.7 is now available

[Alex Blewitt]

There is a maven.eclipse.org instance, which there are experiments in making an 
Eclipse installation available via Maven. However, it is not yet in operation 
nor populated with the Eclipse 3.7 bits.

Alex

On 27 Jun 2011, at 17:22, Jacek Laskowski wrote:

> On Mon, Jun 27, 2011 at 6:15 PM, Pascal Rapicault  wrote:
>> There is currently no plan to make anything avilable in a Maven repo.
>> Which part are you interested in seeing available in a Maven repo?
> 
> Hi,
> 
> Apache Aries needs a 4.3 runtime (Equinox 3.7) for the Aries itests.
> OSGi 4.3 API is already in the repo
> 
> Aries currently download
> http://archive.eclipse.org/equinox/drops/S-3.7M6-201103101119/org.eclipse.osgi_3.7.0.v20110304.jar
> directly.
> 
> Jacek
> 
> -- 
> Jacek Laskowski
> Java EE, functional languages and IBM WebSphere - http://blog.japila.pl
> Warszawa JUG conference = Confitura (formerly Javarsovia) :: 
> http://confitura.pl
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Plans to replace the Console with GoGo for Indigo

[Alex Blewitt]

On 1 Dec 2010, at 22:06, Thomas Watson wrote:

> There have been various discussions about replacing our framework console 
> with something a bit more functional and flexible like apache gogo [1]. At 
> this point in the Indigo release we do not plan to remove our own console for 
> the Indigo release. Instead we will do what ever is required to enable the 
> use of gogo on top of Equinox. We would like to use the incubator to allow 
> this effort to mature and then re-evaluate the complete removal of our 
> built-in framework console in a later release. Lazar Kirchev from SAP has 
> been doing various experiments and investigations in this area. My hope is 
> that Lazar will soon be in a position to contribute this work to the equinox 
> incubator so that others can try it out on top of Indigo.
> 
> Tom
> 
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=317827
> 
One other advantage would be in slimming down Equinox by providing the console 
in a separate bundle from the main OSGi runtime.

Alex___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] How to best simulate standalone Equinox deployment in Eclipse

[Alex Blewitt]

2010/11/19 Robert Krüger :
>
> I'm going through the (so far rather painful) process of trying to deploy my 
> OSGI app developed within Eclipse 3.6 in a standalone Equinox environment for 
> the first time.

The main problem is the runtime in PDE simulates the Eclipse
workbench, which is to have the osgi compatibility suck in everything
from the boot classpath. That isn't the default on Eqiunox though, so
even though PDE knows the difference between an Eclipse plugin run and
an Equinox run, it treats everything like Ecipse.

You want to have:

-Dosgi.compatibility.bootdelegation=true

http://wiki.eclipse.org/Equinox_Boot_Delegation

"A new option has been be added to Equinox to enable a backwards
compatibility option. The option is osgi.compatibility.bootdelegation.
This option is be enabled by default in the Equinox Launcher, but it
defaults to false if the org.eclipse.osgi jar is run directly (set it
to "true" to make it behave like the Equinox Launcher). When this
option is enabled a last resort boot delegation occurs after all other
steps in the OSGi delegation process have been exhausted."

To make it work 'for real' if you need those packages, either:

1) Set that to '*' in the Equinox runtime, or
2) Install fragments to the system bundle which export the packages required

Option 2 is a more compatible way of dealing with it on other OSGi runtimes.

Alex
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Calling Equinox close command by code

[Alex Blewitt]

It might be an idea to find out why your bundles are creating threads  
that are neither deamon nor shut down appropriately by the bundle's  
activator upon shutdown, because if so, the exit wouldn't be necessary.


Sent from my (new) iPhone

On 29 Apr 2010, at 13:26, "David Conde"  wrote:


Yes, this was what I meant.

Finally, the problem was solved by waiting the Bundle(0)'s RESOLVED  
state and then calling to System.exit().


Regards

-Mensaje original-
De: equinox-dev-boun...@eclipse.org [mailto:equinox-dev- 
boun...@eclipse.org] En nombre de Alex Blewitt

Enviado el: jueves, 29 de abril de 2010 13:49
Para: Equinox development mailing list
CC: Equinox development mailing list
Asunto: Re: [equinox-dev] Calling Equinox close command by code

You mean System.exit()?

Sent from my (new) iPhone

On 29 Apr 2010, at 12:16, "David Conde"  wrote:


Hi again,

For me it is not enough to call context.getBundle(0).stop() since
this does something similar to "shutdown" command (shutdown the OSGi
Framework) and I need something similar to "close" command (shutdown
and exit). How could I achieve it?

If I do context.getBundle(0).stop() my application does not stop and
some bundles continue running, as the same way as if I would type
shutdown command in the command line.

Thank you in advance

David

-Mensaje original-
De: equinox-dev-boun...@eclipse.org [mailto:equinox-dev-
boun...@eclipse.org] En nombre de Neil Bartlett
Enviado el: miércoles, 28 de abril de 2010 18:10
Para: Equinox development mailing list
Asunto: Re: [equinox-dev] Calling Equinox close command by code

David,

The way to shutdown the OSGi framework is to obtain the system bundle
(id zero) and call stop():

 context.getBundle(0).stop();

This will work across all frameworks, not just Equinox.

On a meta note to the list... can we get this question and answer  
into

a FAQ somewhere? It seems to get asked every few weeks!

Regards
Neil

On Wed, Apr 28, 2010 at 5:05 PM, David Conde  wrote:

Hi,

Is there any way to call the “close” command by programming?



I need something to call close command from my Visual User
Interface in
order to close the application though a button.



Thank you in advance

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Calling Equinox close command by code

[Alex Blewitt]

You mean System.exit()?

Sent from my (new) iPhone

On 29 Apr 2010, at 12:16, "David Conde"  wrote:


Hi again,

For me it is not enough to call context.getBundle(0).stop() since  
this does something similar to "shutdown" command (shutdown the OSGi  
Framework) and I need something similar to "close" command (shutdown  
and exit). How could I achieve it?


If I do context.getBundle(0).stop() my application does not stop and  
some bundles continue running, as the same way as if I would type  
shutdown command in the command line.


Thank you in advance

David

-Mensaje original-
De: equinox-dev-boun...@eclipse.org [mailto:equinox-dev- 
boun...@eclipse.org] En nombre de Neil Bartlett

Enviado el: miércoles, 28 de abril de 2010 18:10
Para: Equinox development mailing list
Asunto: Re: [equinox-dev] Calling Equinox close command by code

David,

The way to shutdown the OSGi framework is to obtain the system bundle
(id zero) and call stop():

  context.getBundle(0).stop();

This will work across all frameworks, not just Equinox.

On a meta note to the list... can we get this question and answer into
a FAQ somewhere? It seems to get asked every few weeks!

Regards
Neil

On Wed, Apr 28, 2010 at 5:05 PM, David Conde  wrote:

Hi,

Is there any way to call the “close” command by programming?



I need something to call close command from my Visual User  
Interface in

order to close the application though a button.



Thank you in advance

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Regarding PackageAdmin refreshPackages.

[Alex Blewitt]

Were they started with bundle.start() or bundle.start(START_TRANSIENT)?

Sent from my (new) iPhone

On 27 Apr 2010, at 08:02, "Srijith Kochunni"   
wrote:


Thanks for the explanation Tim. I understand the refresh phenomenon  
now.

>>
If the bundle was started before the refresh operation, it will  
automatically be restarted after it has been rewired.


 However this I don't see happening. Not sure why.. The Bundle just  
remains in RESOLVED state. If I manually start it, it starts fine.


Thanks,
Srijith.


>>> "Tim Diekmann"  4/27/2010 11:35 AM >>>
The refresh operation rewires the bundles that need to be rewired  
based on the changes your agent made to the bundle wiring state. In  
order to rewire a bundle it has to be stopped and a new classloader  
is created for the bundle. If the bundle was started before the  
refresh operation, it will automatically be restarted after it has  
been rewired.


BTW, wiring is the term for the import and export package  
relationship between bundles. The framework creates a link (wire)  
between the bundles based on their metadata in manifest.mf.


Does this help explaining the refresh phenomenon?

 Tim.


On Apr 26, 2010, at 22:36, "Srijith Kochunni"   
wrote:



Are you suggesting that when I invoke refreshPackages, I must do it  
in a separate thread.?  Either way why would this call stop an  
active bundle ? Don't quite get that.


Thanks,
Srijith.


>>> "Tim Diekmann"  4/27/2010 10:45 AM >>>
The refreshPackages() is required to perform it's operation in a  
separate thread according to the spec. This makes it use tricky and  
hardly predictable.


 Tim.


On Apr 26, 2010, at 22:09, "Srijith Kochunni"   
wrote:




Hi

  I have an equinox runtime, where I have deployed my  
bundles. I notice that at times, when I do not do a clean start,  
as in start without osgi.clean option, I notice that some of my  
bundles go into Stopped state. This happens when a "Refresh  
packages"  thread spawned by the framework is run. It seems to be  
stopping my application bundles.


   My setup is such that I am using my own custom module  
loader, which loads my bundles from a pre-specified folder and  
after my bundles are installed / updated, I also directly invoke  
PackageAdmin.refreshPackages and it seems to be returning  
correctly and all bundles are in a proper state, but then this  
thread gets spawned and it seems to stop most of my application  
bundles. Not sure what the problem is, so I did a dump of my stack  
Trace in my Activator stop and I could see this


at  
org.eclipse.osgi.framework.internal.core.BundleContextImpl$3.run 
(BundleContextImpl.java:1050)
at java.security.AccessController.doPrivileged(Native  
Method)
at  
org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop 
(BundleContextImpl.java:1046)
at  
org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker 
(BundleHost.java:457)
at  
org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend 
(AbstractBundle.java:531)
at  
org.eclipse.osgi.framework.internal.core.Framework.suspendBundle 
(Framework.java:1104)
at  
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.suspendBundle( 
PackageAdminImpl.java:280)
at  
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta( 
PackageAdminImpl.java:415)
at  
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles( 
PackageAdminImpl.java:223)
at  
org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run 
(PackageAdminImpl.java:162)

at java.lang.Thread.run(Unknown Source)

 Wanted to know when this would happen / how it can be rectified.  
Also wanted to know, whether it is possible to stop the Refresh  
packages thread from being spawned through some configuration,  
because I am anyway invoking it directly in my application and  
therefore don't need the framework to do it. Any help regarding  
this would be much appreciated.


 Thanks,
 Srijith.



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev





___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] jetty-http / jsp / problem with session-scoped beans after bundle update

[Alex Blewitt]

On 3 Mar 2010, at 00:51, Yuriy Malchenko wrote:

> Or maybe I should take the needed classes (session/application scoped)
> to a separate bundle which will not be needed to update frequently?
> But anyway sometimes it might, so it's not a good solution.

It's generally a good idea to separate out interfaces/classes which are going 
to be exposed to the end user and make them available in a separate bundle, 
whilst having your logic/program in a different bundle. Then you can throw away 
the program and reinstantiate it after update, but keep your data 
objects/interfaces the same. 

Note that applies to a number of other cases where the implementation must be 
bounced but whilst maintaining the same interface classes; it's not unique to 
servlets or JSPs, though of course, you notice these in situations like this.

The other approach is to drop all sessions when you reload the code, which 
doesn't sound like a sensible solution.

Alex___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] How to add whole directory in classpath and how to controll osgi console log

[Alex Blewitt]

On Thu, Feb 18, 2010 at 9:30 AM, Swapnil Patil wrote:

> Tom,
> Thank you for the comment.
> I hope next version of OSGi implementations will add support for this
> classpath case.
>

There's no real need to do this. You have to generate the bundle/manifest
from something; that should have full visibility of the JARs that are
contained within the bundle at build time, so it's a trivial build issue to
solve.

If you want to use something which installs all bundles in a directory, then
either Peter's FileInstall (available at felix.apache.org) or the P2
Director is able to bulk-install all JARs in a directory into a running OSGi
runtime. There's no concept of an 'ext dir' per se, given that all bundles
must be installed ahead of time, but the tools mentioned above allow you to
trivially add a new bundle into a runtime by copying into a new area. In the
case of your example, you'd do:

java -Dfelix.fileinstall.dir=c:\jars -jar org.eclipse.osgi_*.jar
osgi> install fileinstall.jar
osgi> start 1

http://felix.apache.org/site/apache-felix-file-install.html

Note that whilst P2 is the Eclipse case, there's next to no documentation on
how to use it, and so the Felix FileInstall is generally preferred for that
reason.

Alex

PS The mailing list is for development of equinox; there's a newsgroup for
user questions like this next time.

http://dev.eclipse.org/newslists/news.eclipse.technology.equinox/
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Configuration Admin Service Problem

[Alex Blewitt]

On Jan 13, 2010, at 18:01, David Conde wrote:

Hi I would like to know how I can activate Configuration Admin  
Bundle for Equinox.


I have tried by launching org.eclipse.osgi.services.jar bundle where  
it is suppoused to be, but I when I tried to get the Configuration  
Admin Service using the next code but I do not get any service at all.


You should really use the newsgroup for this. Note that the CM  
interfaces are defined in the osgi srervices bundle, but the  
implementation (cm) is not.


http://download.eclipse.org/equinox/drops/R-3.5.1-200909170800/index.php

For example, for 3.5.1, the bundle is:

http://download.eclipse.org/equinox/drops/R-3.5.1-200909170800/download.php?dropFile=org.eclipse.equinox.cm_1.0.100.v20090520-1800.jar___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Bridging the plain Java and OSGi classloading worlds

[Alex Blewitt]

My understanding is that the interfaces used (and dependent types  
therin) need to be loadable from oustide the OSGi engine and have the  
service import the same (external) interface. If you were to have one  
interface from outside, and one inside, they would complain.


Another possibility would be to use sone kind of RMI or  
externalisation to get across the boundary, which would have the  
advantage of being usable for distributed access. Distributed OSGi  
might be useful for this.


Alex

Sent from my (new) iPhone

On 19 Aug 2009, at 21:32, "Michael Furtak"  wrote:


Hi Hal,

Thanks for those references. They were helpful. It feels like I’m cl 
ose, but problems remain.


Also, I’m a bit confused as to whether the noted techniques can help 
 my problem. My understanding of the system packages and boot delega 
tion stuff is that it helps OSGi find classes that are not explicitl 
y exported from any of the OSGi bundles (i.e. java.*, javax.* stuff, 
 etc.)


My dilemma is somewhat the opposite. I’m originating from Java, outs 
ide of the OSGi environment, but want to call objects created inside 
 of OSGi. Of course, this leads to a ClassCastException when I get t 
he service object and try to refer to it by its interface as loaded  
in Java land.


I’ve attached my source w/ some class/package names changed to prote 
ct the innocent. Also attached is my config.ini file. Without the or 
g.osgi.framework.system.packages.extra directive, the ClassCastExcep 
tion occurs. With it, I don’t get a callback on my ServiceTrackerCus 
tomizer’s addedService() method.


Do you have any further thoughts?

Thanks in advance,
-Mike





THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS  
ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED,  
CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you  
are not the intended recipient, your use of this message for any  
purpose is strictly prohibited. If you have received this  
communication in error, please delete the message and notify the  
sender so that we may correct our records.




From: equinox-dev-boun...@eclipse.org [mailto:equinox-dev- 
boun...@eclipse.org] On Behalf Of Hal Hildebrand

Sent: Wednesday, August 19, 2009 3:18 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Bridging the plain Java and OSGi  
classloading worlds


You can also check out: 
http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html

note the section "Creating and Configuring the Framework Instance",  
and the use of the property  
"org.osgi.framework.system.packages.extra" which makes this a bit  
easier.  Works the same way with Equinox.


On Aug 19, 2009, at 12:13 PM, Hal Hildebrand wrote:


Sure.  See http://blog.springsource.com/2009/01/19/exposing-the-boot-classpath-in-osgi/ 
 for an in depth discussion by Costin of SS.


On Aug 19, 2009, at 12:08 PM, Michael Furtak wrote:


Hi Hal,

Thanks very much for your reply. I’m heartened that you’re  
confident in this possibility. Is there any documentation for the op 
tion you mention that I can refer to?


Thanks,
-Mike






THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS  
ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED,  
CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you  
are not the intended recipient, your use of this message for any  
purpose is strictly prohibited. If you have received this  
communication in error, please delete the message and notify the  
sender so that we may correct our records.




From: equinox-dev-boun...@eclipse.org [mailto:equinox-dev- 
boun...@eclipse.org] On Behalf Of Hal Hildebrand

Sent: Wednesday, August 19, 2009 3:01 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Bridging the plain Java and OSGi  
classloading worlds


sure, you just have to have a class loader in common.  The way this  
would work is to modify the exports of the System bundle (an option  
when starting the framework in Equinox) to export the classes from  
the base class path you need.  Then there is no class loader issues,  
as they're both using the same.


On Aug 19, 2009, at 11:56 AM, Michael Furtak wrote:



Hi all,

I am using the EclipseStarter.startup(…) method to bring up the Equn 
inox framework from within a plain ol’ Java application. My question 
 is this:


Is it possible to allow the plain ol’ Java environment to get and ca 
ll service objects from the OSGi side? I know their respective class 
loader environments are disjoint, but is there any hope at all of br 
idging them? Has anyone been dumb/crazy enough to want to do this?


Thanks,
-Mike




THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS  
ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED,  
CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you  
are not the intended recipient, your use of this message for any  
purpose is strictly prohibited. If you have received this  
communi

Re: [equinox-dev] Problem when running Equinox with Maven and OSP4J's Pax Construct when behind a proxy

[Alex Blewitt]

This is a PAX issue, rather than Equinox. Indeed, Eclipse doesn't  
actually host the bundles on ibiblio at all ... they're put up by  
volunteers.


You might try a pax-update from the PAX scripts to see if there is any  
updates. It may be that the Equinox version you've specified is no  
longer available.


I recall I used pax-construct to create my project which defaulted to  
a right version of Equinox. Perhaps after update you can create a new  
project with that and then cut'n'paste the Equinox dependency.


Alex

Sent from my (new) iPhone

On 12 Jun 2009, at 16:09, Samad Lotia  wrote:


Hello,
I am trying to use Equinox with Maven and Pax Construct. When I type  
"mvn pax:run", it correctly downloads all the bundles. However,  
Maven gets stuck when attempting to download Equinox:


 -> Equinox 3.4.2 (v20081215-1030) : downloading...

After ten minutes or so, Pax times out, saying that it wasn't able  
to obtain the bundle. I get this message: "Oops, these has been a  
problem! URL [mvn:org.eclipse/osgi/3.4.3.

v20081215-1030] could not be resolved."

I have environment variables set up correctly ($http_proxy,  
$HTTP_PROXY, $HTTPS_PROXY, $FTP_PROXY), and I have provided proxy  
settings in my ~/.m2/settings.xml file.


Here's some information on my computer:
Output from uname: Linux  2.6.18-128.1.6.el5 #1 SMP Wed Apr  
1 09:10:25 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

Java version: Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Maven version: Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100)

How can I fix this?

Thanks,
Samad
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] ServiceReference.compareTo(Object)

[Alex Blewitt]

2009/4/24 岡野　真一 :
> Hi all !
>
> I am using Equinox 3.4.2, and I thik I found a bug.
>
> The Javadoc of "org.osgi.framework.ServiceReference.compareTo(Object)"
> says the following:
>
>    This ServiceReference is less than the specified ServiceReference if
>    it has a lower service ranking and greater if it has a higher
>    service ranking. Otherwise, if this ServiceReference and the
>    specified ServiceReference have the same service ranking, this
>    ServiceReference is less than the specified ServiceReference if it
>    has a higher service id and greater if it has a lower service id.
>
> But,
> org.eclipse.osgi.framework.internal.core.ServiceReferenceImpl.compareTo(Object)
> (version=3.4.3.R34x_v20081215-1030) is implemented the following.
>
>    if (this.getRanking() != other.getRanking())
>        return this.getRanking() > other.getRanking() ? -1 : 1;
>    return this.getId() == other.getId() ? 0 : this.getId() > other.getId() ? 
> 1 : -1;
>
> I think the following is correct.
>
>    if (this.getRanking() != other.getRanking())
>
>        return this.getRanking() > other.getRanking() ? 1 : -1;  //  <--
>
>    return this.getId() == other.getId() ? 0 : this.getId() > other.getId() ? 
> -1 : 1;  // <<-
>
>
> I'm sorry if I have a mistake, or if it had already been discussed.

Looks reasonable. Why not open a bug at bugs.eclipse.org?

Alex
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Update to Jetty and Servlet API in the M4 SDK

[Alex Blewitt]

So the question is ... Why are you bumping o.e.e.h.jetty from 1.1->2.0  
instead of 1.1->1.2?


Sent from my (new) iPhone

On 11 Dec 2008, at 20:59, Simon Kaegi  wrote:


Yes you're right.
The bundle-version on org.eclipse.equinox.http.jetty is bumped to  
"2.0" so to high-light Alex's point/concern...
There is the possibility of breakage if a team used a version  
restricted Require-Bundle with major version semantics like:
Require-Bundle: org.eclipse.equinox.http.jetty; bundle- 
version="[1.1,2.0)
The Export-Package is still using "1.1" so Import-Package users  
should be fine.


As a result of this change it is important for teams that are using  
the server-side bundles to verify as this change could cause  
problems. This is why the original email was sent and is a pre-step  
for an entry in the 3.4 to 3.5 migration guide.
In most cases all should be well since the actual binary API has not  
changed although the bundle metadata has.

-Simon


Alex Blewitt ---12/11/2008 02:50:38 PM---I thought that  
an API compatible change was only meant to increment



From:   
Alex Blewitt 

To: 
Equinox development mailing list 

Cc: 
"eclipse-...@eclipse.org" , "cross-project-issues-...@eclipse.org 
" , "equinox-dev@eclipse.org" >


Date:   
12/11/2008 02:50 PM

Subject:
Re: [equinox-dev] Update to Jetty and Servlet API in the M4 SDK



I thought that an API compatible change was only meant to increment
the minor version number, rather than the major number?

Alex

Sent from my (new) iPhone

On 11 Dec 2008, at 19:02, Simon Kaegi  wrote:

> In M4 the platform team updated the version of Jetty that comes
> packaged with the SDK from 5.1 to 6.1.
> This impacts the following bundles:
>
> 1) org.mortbay.jetty (version 5.1) (removed)
> If your feature directly integrates with the Jetty 5 API you can
> continue to do so but must now add the appropriate bundles from
> Orbit yourself.
>
> 2) org.mortbay.jetty.server and org.mortbay.jetty.util (version 6.1)
> (added)
>
> 3) javax.servlet (upgraded from version 2.4 to 2.5)
> API compatible. Bundle-Version and Export-Package version updated.
> Teams should verify version ranges for Import-Package and Require-
> Bundle.
>
> 4) org.eclipse.equinox.http.jetty (upgraded from version 1.1 to 2.0)
> API compatible. Bundle Version updated but no change to Export-
> Package version. Teams using Require-Bundle with a restricted  
bundle-

> version range should confirm.
>
> --
> None of these changes introduce new Eclipse binary API or prevent
> the use of existing API.
>
> If anyone has a problem please log a bug against RT->Equinox- 
>Server-

> Side
>
> -Simon
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Update to Jetty and Servlet API in the M4 SDK

[Alex Blewitt]

I thought that an API compatible change was only meant to increment  
the minor version number, rather than the major number?


Alex

Sent from my (new) iPhone

On 11 Dec 2008, at 19:02, Simon Kaegi  wrote:

In M4 the platform team updated the version of Jetty that comes  
packaged with the SDK from 5.1 to 6.1.

This impacts the following bundles:

1) org.mortbay.jetty (version 5.1) (removed)
If your feature directly integrates with the Jetty 5 API you can  
continue to do so but must now add the appropriate bundles from  
Orbit yourself.


2) org.mortbay.jetty.server and org.mortbay.jetty.util (version 6.1)  
(added)


3) javax.servlet (upgraded from version 2.4 to 2.5)
API compatible. Bundle-Version and Export-Package version updated.  
Teams should verify version ranges for Import-Package and Require- 
Bundle.


4) org.eclipse.equinox.http.jetty (upgraded from version 1.1 to 2.0)
API compatible. Bundle Version updated but no change to Export- 
Package version. Teams using Require-Bundle with a restricted bundle- 
version range should confirm.


--
None of these changes introduce new Eclipse binary API or prevent  
the use of existing API.


If anyone has a problem please log a bug against RT->Equinox->Server- 
Side


-Simon
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] What bundle class loaded from

[Alex Blewitt]

I've used equinox to persist/load a Jar from a database system without
ever hitting the local file system. It's not just an equinox thing.

Alex

On Wed, Nov 26, 2008 at 2:45 PM, Fredrik Alströmer <[EMAIL PROTECTED]> wrote:
> I'm aware of this, but I figured this was the equinox mailing list, so
> maybe there's an equinox answer? :)
>
> On Wed, Nov 26, 2008 at 14:58, BJ Hargrave <[EMAIL PROTECTED]> wrote:
>> Not in any standard way. A framework is free to store an installed bundle in
>> any way is chooses. It could keep the original JAR file, expand it to the
>> file system, put all the entries in a database, convert it to some VM
>> optimized format, etc.
>> --
>>
>> BJ Hargrave
>> Senior Technical Staff Member, IBM
>> OSGi Fellow and CTO of the OSGi Alliance
>> [EMAIL PROTECTED]
>> office: +1 386 848 1781
>> mobile: +1 386 848 3788
>>
>>
>> From: "Fredrik Alströmer" <[EMAIL PROTECTED]>
>> To:
>> "Equinox development mailing list" 
>> Date: 2008/11/26 08:46
>> Subject: Re: [equinox-dev] What bundle class loaded from
>> Sent by: [EMAIL PROTECTED]
>> 
>>
>>
>> On a similar note, is there a way to access the actual bundle file?
>> Like for running an external javac-process (think tomcat jasper),
>> which needs a classpath.
>>
>> On Mon, Nov 24, 2008 at 18:15, BJ Hargrave <[EMAIL PROTECTED]> wrote:
>>> PackageAdmin.getBundle(Class)
>>> --
>>>
>>> BJ Hargrave
>>> Senior Technical Staff Member, IBM
>>> OSGi Fellow and CTO of the OSGi Alliance
>>> [EMAIL PROTECTED]
>>> office: +1 386 848 1781
>>> mobile: +1 386 848 3788
>>>
>>>
>>> From:
>>> Oleg Zhurakousky <[EMAIL PROTECTED]>
>>> To: Equinox development mailing list 
>>> Date: 2008/11/24 12:04
>>> Subject: [equinox-dev] What bundle class loaded from
>>> Sent by: [EMAIL PROTECTED]
>>> 
>>>
>>>
>>> I know how to do it the "hard way", but was wondering if there is and
>>> elegant way to determine which Bundle loaded a class?
>>> Thanks
>>> Oleg
>>> ___
>>> equinox-dev mailing list
>>> equinox-dev@eclipse.org
>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>
>>>
>>> ___
>>> equinox-dev mailing list
>>> equinox-dev@eclipse.org
>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>
>>>
>> ___
>> equinox-dev mailing list
>> equinox-dev@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>
>>
>> ___
>> equinox-dev mailing list
>> equinox-dev@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>
>>
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Is the P2 installer supposed to work?

[Alex Blewitt]

On Wed, May 21, 2008 at 1:01 PM, Pascal Rapicault
<[EMAIL PROTECTED]> wrote:
> Open a bug with the errors you are getting.

I already did:

> - Please enter a bug for this with your good steps.  Thanks!
> - We have been running the installer on windows and the Mac quite regularly 
> and even via JNLP.  This must be a quirk in the build as the product 
> definition file looks fine.

Yeah, I was going to - I just wanted to check that it wasn't already a
known problem.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=233159
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Is the P2 installer supposed to work?

[Alex Blewitt]

On Wed, May 21, 2008 at 5:20 AM, Jeff McAffer <[EMAIL PROTECTED]> wrote:
> I should have mentioned...
>
> - Please enter a bug for this with your good steps.  Thanks!
> - We have been running the installer on windows and the Mac quite regularly 
> and even via JNLP.  This must be a quirk in the build as the product 
> definition file looks fine.

Yeah, I was going to - I just wanted to check that it wasn't already a
known problem.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=233159

It looks like it's not consulting the p2installer.ini file, but that
doesn't matter since the p2installer.ini file doesn't contain the URL
anyway. And the documentation is still wrong on the Wiki.

Still, using the right URL and the command line args to set the system
property, it finally did work; at least in the sense of getting to
another error. This time, it complains 'No repository found at
http://download.eclipse.org/eclipse/updates/3.4milestones/'
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Is the P2 installer supposed to work?

[Alex Blewitt]

I only ask because I downloaded the installer from:

  
http://download.eclipse.org/eclipse/equinox/drops/S-3.4RC1-200805161333/index.php#Provisioning

and when running it, it doesn't install the SDK as the documentation suggests:

  http://wiki.eclipse.org/Equinox_p2_Installer

* Get the installer for your platform from the equinox download page.
* Unzip the installer anywhere on your local disk
* Run the "p2installer" executable
* In the install wizard, select where you want to install the software

Shows a dialog with "Where do you want to install null?"

I had a look at the p2installer.ini:

-showsplash
org.eclipse.platform
-vmargs
-Xdock:icon=../Resources/Eclipse.icns
-XstartOnFirstThread
-Xms40m
-Xmx256m
-XX:MaxPermSize=256m
-Dorg.eclipse.swt.internal.carbon.smallFonts

No mention of the org.eclipse.equinox.p2.installDescription that the
page suggests it looks for. I try adding it, and get a new message
saying the error is invalid. That's maybe because the URL that that
page points to is invalid:

  http://update.eclipse.org/eclipse/testUpdates/sdk-installer.properties
- 404 not found

* When finished, you can delete the installer

I deleted it. At least that worked ...

Alex
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] [sec] use of Equinox secure storage

[Alex Blewitt]

On Wed, May 14, 2008 at 11:15 PM, Scott Lewis <[EMAIL PROTECTED]> wrote:
> Agreed RE: making life easier WRT authentication/account mgmt/single
> sign-on, etc.  I'm hoping that Matt, Eric, Thomas, etc. will also work with
> us to take further advantage after 3.4 is out.
>
> Scott

Did you ever have any luck with Kerberos? I had an implementation of
kerberized CVS (which has missed most of the 3.x releases by now,
including this one) which acquired kerberos credentials using Sun's
kerberos manager. A colleague at work developed this idea a bit
further.

Would I be able to provide any assistance in the kerberos domain, or
is kerberized ECF services not something you've come across?

Alex
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Installing a bundle from console does not make it available to the workspace?

[Alex Blewitt]

By not available, do you mean that it does not work, or that you can't  
write a PDE bundle that depends on it?


If the latter, it's because PDE caches the target environment, and you  
have to refresh it. You can do that from window > preferences > pde >  
target. Then your bundle should he available.


Alex

Sent from my iPhone

On 7 May 2008, at 00:20, Mark <[EMAIL PROTECTED]> wrote:

Installing a bundle after launching Eclipse using the -console, or  
using the Neils most excellent bundlemonitor (http://neilbartlett.name/downloads/bundlemonitor/ 
) fails to make that bundle available in the WorkSpace / or as an  
available plugin dependency.


It does however show up it the bundle monitor.

(Eclispe 3.3.1.1 on Windows XP)

I would have expected the functionality to be similar to adding a  
JAR, in that once the bundle has been installed, it should be  
available throughout the Eclipse Environment.


I did get it to work by installing the plugin (using the links  
extension mechanism) prior to launching eclipse. Then the bundle is  
available and can be used in the workspace.


Unless anyone has any bright ideas ?

I will submit more information in the morning, if required.

Regards

Mark

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Customize versioning scheme

[Alex Blewitt]

On Apr 7, 2008, at 13:48, Baptiste MATHUS wrote:


Hi all,

We're using Eclipse RCP as the platform for our UI. We're almost  
done with dev and are beginning to look at the packaging/deployment  
phases.


OSGi specifies the org.osgi.framework.Version class to manage  
versioning by default with x.y.z.qualifier scheme. Our scheme is not  
very far from it, but not the same, it's something like  
a.b.c.d.e.qualifier (two numbers more).


So my question is simple: is this possible to inject a custom  
versioning scheme (for example, we could inherit/extend the current  
Version class to manage our case) ?


For bundles, no, the OSGi versioning is fixed. I'm not sure of the  
point of having so many numbers, but if you have a.b which are on the  
whole the same throughout other releases, you might like to call your  
bundle foo-a-b_c.d.e.qualifier instead. You'd lose the connection with  
the version comparisons but since you'd end up with different named  
bundles each time, you could easily do that approach.


The other thing would be to use some kind of bitshift to represent the  
numbers e.g. a.b.(c*1024+d*512+e*128).equalifier.


Alex
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] p2 update

[Alex Blewitt]

On Thu, Mar 27, 2008 at 5:38 PM, Alex Blewitt <[EMAIL PROTECTED]> wrote:
> Right, it wasn't so much of a question as "can it be done" (you've
>  been able to do it with hackery and symlinks in the past) but rather
>  allowing Eclipse apps to have this by default to make them better Mac
>  citizens. Here's what the Apple guide says about the Library location:
>  
> http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html#//apple_ref/doc/uid/20002282-BAJHCHJI

Specifically:

[/Library|~/Library]/Application Support

Contains application-specific data and support files such as
third-party plug-ins, helper applications, templates, and extra
resources that are used by the application but not required for it to
operate. This directory should never contain any kind of user data. By
convention, all of these items should be put in a subdirectory named
after the application. For example, third-party resources for the
application MyApp would go in Application Support/MyApp/. Note that
required resources should go inside the application bundle itself.
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] p2 update

[Alex Blewitt]

Right, it wasn't so much of a question as "can it be done" (you've
been able to do it with hackery and symlinks in the past) but rather
allowing Eclipse apps to have this by default to make them better Mac
citizens. Here's what the Apple guide says about the Library location:

http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html#//apple_ref/doc/uid/20002282-BAJHCHJI

Alex.
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] p2 update

[Alex Blewitt]

On Thu, Mar 27, 2008 at 5:18 PM, Pascal Rapicault
<[EMAIL PROTECTED]> wrote:
> It is technically possible but we don't have a UI to add such locations and
>  will not get to it for 3.4.
>  That, said, since one of the goal p2 is to get people out of the file
>  system, therefore I would highly suggest to d&d the plugins directly on the
>  p2 UI.

Given that Mac apps normally put extensions in these locations, it's
fairly standard places to look. Can they not be coded in by default,
even if the UI isn't there?

I thought that the point of P2 was to have less explicit dependencies
on hard-coded names like 'plugins' and 'features'. If you've got to
have another directory called 'dropins' then it's basically just
exchanged one problem for another.

Alex
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] p2 update

[Alex Blewitt]

Is it possible to define more than one dropins folder? On Mac systems,
/Library/Eclipse/ and ~/Library/Eclipse would be good places to define
additional dropins locations for users. The normal convention would be
to capitalise the directory name, so /Library/Eclipse/Dropins and
~/Library/Eclipse/Dropins would be the normal directories for all
users and the current user respectively.

Alex

On Thu, Mar 27, 2008 at 2:25 PM, Pascal Rapicault
<[EMAIL PROTECTED]> wrote:
>
>  Hello,
>
>  The night brought us a new platform build
>  
> (http://download.eclipse.org/eclipse/downloads/drops/I20080327-0100/index.php)
>   including p2 fixes for the most pressing issues that have reported against
>  previous builds:
>   - p2 is now capable of discovering plugins dropped in the plugins
>  folder, like you have always been able to do. That said, going forward we
>  still recommend people to use the dropins folder
>  
> (http://wiki.eclipse.org/Equinox_p2_Getting_Started#Supported_dropins_formats).
>   - more resilience in what gets installed from the dropins folder
>   - better handling of optional dependencies at install time
>
>  Please try this build for further testing,
>
>  Thank you,
>
>  PaScaL
>
>  ___
>  equinox-dev mailing list
>  equinox-dev@eclipse.org
>  https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Using log4j with LogService

[Alex Blewitt]

On Tue, Mar 18, 2008 at 3:49 AM, Srijith Kochunni <[EMAIL PROTECTED]> wrote:
>
> Thanks for the quick reply. Yes I can use the LogReader Service and then
> direct it to log4j.

Have you looked at PAX logging?

http://wiki.ops4j.org/confluence/display/ops4j/Pax+Logging

That allows you to have an OSGi LogService implementation that picks
up messages and forwards them to the back-end logger of your choice,
including log4j. And because it exports logging packages, clients can
transparently use existing log4j logging code -> PAX logging -> log4j
at the back end.

Alex
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Eclipse and the Mac System Log - Runaway CPU

[Alex Blewitt]

On Wed, Feb 20, 2008 at 8:52 PM, Thomas Watson <[EMAIL PROTECTED]> wrote:
>
> It may actually be coming from the VM shipped with the Mac. The messages
> seem somewhat related to the extension classloader in the VM. Do you know if
> you are using an officially released version of the VM?

I've got an Eclipse 3.3.0 kicking around, and I see some messages
being logged which are clearly from Eclipse:

Feb 20 22:31:04 apple /Users/alex/Desktop/IDEs/Eclipse
3.3/Eclipse.app/Contents/MacOS/eclipse[794]: Unrecognized Java VM
option ignored: -Xdock:icon=..
/Resources/Eclipse.icns
Feb 20 22:31:04 apple /Users/alex/Desktop/IDEs/Eclipse
3.3/Eclipse.app/Contents/MacOS/eclipse[794]: Unrecognized Java VM
option ignored: -XstartOnFirst
Thread
Feb 20 22:31:30 apple [0x0-0x5a05a].org.eclipse.eclipse[794]: !SESSION
Feb 20 22:31:31 apple [0x0-0x5a05a].org.eclipse.eclipse[794]:
2008-02-20 22:31:07.658
---
Feb 20 22:31:31 apple [0x0-0x5a05a].org.eclipse.eclipse[794]:
eclipse.buildId=I20070625-1500
Feb 20 22:31:31 apple [0x0-0x5a05a].org.eclipse.eclipse[794]:
java.version=1.5.0_13
Feb 20 22:31:31 apple [0x0-0x5a05a].org.eclipse.eclipse[794]:
java.vendor=Apple Inc.
Feb 20 22:31:31 apple [0x0-0x5a05a].org.eclipse.eclipse[794]:
BootLoader constants: OS=macosx, ARCH=ppc, WS=carbon, NL=en_US
Feb 20 22:31:31 apple [0x0-0x5a05a].org.eclipse.eclipse[794]:
Framework arguments:  -keyring /Users/alex/.eclipse_keyring
-showlocation
Feb 20 22:31:31 apple [0x0-0x5a05a].org.eclipse.eclipse[794]:
Command-line arguments:  -os macosx -ws carbon -arch ppc -keyring
/Users/alex/.eclipse_ke
yring -consoleLog -showlocation
Feb 20 22:31:31 apple [0x0-0x5a05a].org.eclipse.eclipse[794]: !ENTRY
org.eclipse.update.configurator 2008-02-20 22:31:30.971
Feb 20 22:31:31 apple [0x0-0x5a05a].org.eclipse.eclipse[794]: !MESSAGE
Could not install bundle plugins/osgi.jar   Bundle "org.eclipse.osgi"
version "3
.3.0.v20070530" has already been installed from: System Bundle
Feb 20 22:31:32 apple login[800]: USER_PROCESS: 800 ttys001

It looks like they're being printed out by System.out/err type calls,
but they're not repeating. This is using a vanilla Java 1.5.0 install,
on a PowerPC system.

The LIBRARY calls look like the JVM is doing something special,
though. What's in your Eclipse.ini file? What version of Java? Is it
an intel or powerpc system?

Alex
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] [prov] peer-to-peer downloads (ECF)

[Alex Blewitt]

On Fri, Feb 15, 2008 at 4:08 PM, Jeff McAffer <[EMAIL PROTECTED]> wrote:
> Remy, excuse me if this is really basic and naïve.  I've only used bittorent
>  to download large single wad files...
>
>  Would it be reasonable to use bittorent to download *parts* of things?  For
>  example, if you look at an entire repo as one file then when you want just
>  one of the artifacts ...

It would be better not to consider the repo as only one file, but
rather as an index that point to a set of files instead. These might
even be understandable units like bundles or IUs. As for the
individual downloading, what happens is that the file is only
downloaded as a single entity, but that under the covers it makes
multiple network requests to multiple network hosts to achieve that
download.

>  Seems that bittorent clients can look for peers that have parts of
>  files so if there was an index saying which artifacts are in what parts of
>  the torent file, a client could just look for the parts of interest and lay
>  them out on disk appropriately.

That's an internal optimisation, rather than something a user has
control over; somewhat like the way that TCP streams are chunked into
IP across the net; it happens, but you don't (really) know about it.

In terms of externally 'indexable' items, bittorrent tracks them at
the 'file' level. The file is packeted up into diffferent segments
(think downloading http://a.example.com/file.zip{0-10k} and
http://b.example.com/file.zip{10k-20k} etc.)

I guess the interesting question is: why think of a repo as an
individual file? Even for those that don't support bittorrent, it's
much better to think of it as a collection of files. That's one of the
problems with the SDK zips; there's a lot of duplicated data in
individual files. If they were individually addressable, you would
only have to store them once.

Alex
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Reference remote bundles when writing a new plugin.

[Alex Blewitt]

On Feb 11, 2008 12:57 PM, Mark <[EMAIL PROTECTED]> wrote:
> Thanks Alex.
>
> Perhaps this is also a possible feature for the PDE team.

PDE lists bundles in your workspace/runtime, though; it doesn't
constrain how they get there. The issue is how you get a bundle stored
in a repo into your workspace such that PDE can see it.

Anyway, this is the equinox-dev, not pde list :-) Perhaps submitting
an enhancement request is the best way forward.

As an aside, you can install bundles using the Bundles view:

http://neilbartlett.name/blog/2008/02/04/osgi-bundles-view-plug-in-for-eclipse/

That might do what you want already.

Alex
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Reference remote bundles when writing a new plugin.

[Alex Blewitt]

On Feb 10, 2008 8:01 PM, Mark <[EMAIL PROTECTED]> wrote:
>
> I have created a couple of plugins that use maven2 in order to publish the
> jar files in the repository.
>
> I would like to be able to reference these budles in a similar manner as one
> would reference remote jars.
>
> However so far I have not found a good way to reference remote bundles (file
> path/url) when writing a new plugin using eclipse 3.3+
>
> I can add them to the classpath / however the access restrictions are not
> enforced.

I'm pretty sure you could do something like:

eclipse -console

and then do

install http://path/to/repo/foo-1.2.3.jar

You'd then have the bundle installed (remotely) into your workspace,
and it would be treated as normal (modulo bugs) by PDE.

Alex
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Maven and all that [was: Jetty and commons logging]

[Alex Blewitt]

On Jan 7, 2008 10:33 PM, Jeff McAffer <[EMAIL PROTECTED]> wrote:
>
> Personally I would find it hard to in any way sanction a repo of any kind
> that resulted in people getting JARs with names different than what we
> produced.

You mean like someone downloading log4j-1.2.13.jar, and instead of
calling it the same name:

http://repo1.maven.org/maven2/log4j/log4j/1.2.13/log4j-1.2.13.jar

renaming it to something different:

http://download.eclipse.org/tools/orbit/downloads/drops/S200712072116/bundles/org.apache.log4j_1.2.13.v200706111418.jar

Alex
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Jetty and commons logging

[Alex Blewitt]

On Jan 6, 2008 1:18 AM, Jeff McAffer <[EMAIL PROTECTED]> wrote:
>
> I won't disagree and would certainly welcome anyone who wanted to
> create/maintain such a repo.  It seems that someone has done this at
> maven.org.  The Maven user community should encourage that person to
> continue doing the work.  I don't really see eclipse.org or the projects
> hosting another copy of all their bundles laid out in the standard Maven dir
> structure.  Our mirrors would be upset at the doubling in size and we have
> to maintain the update site structure for the Eclipse user community anyway.
> As I understand Maven, it is at least in theory possible to define different
> kinds of repos so, for example, Eclipse update sites could be directly
> accessed from Maven.  No idea what is involved in that but it feels like the
> right kind of direction.

The problem with the Eclipse downloads is that there's actually no
real way of knowing where to look for something. Quite apart from the
arbitrary tools/platform/technology project splits, each directory is
versioned in an S-3.4M2-200709210919 directory whose name is computed
based on the time that something was run, rather than anything
detectable. In order to provide my 'direct download links' I had to
manually grep for the random-date-string in order to update my links
each time a new drop was released.

Not only that, but eclipse.org doesn't provide any really useful way
of finding out what plugins are hosted, or even where. It also ends up
wasting a *heap* of bandwith; the -win32-win32-, -win32-wpf-,
-linux-gtk-, -linux-motif-, combos are all pretty much 95%+ the same,
with only a few native bits different from each of them. There's no
'one' place to download the individual plugins.

Even the update sites aren't helpful. You can't browse to them, and
even when you do (e.g. via a mirror) it's not clear as to which plugin
is stored in which location.

Lastly, there's no metadata available. One of the things which will
have been observed from the P2 work is that it is necessary to have a
(small) downloadable metadata file that can be downloaded without
needing to download the bits that the metadata refers to. In Maven,
this is the POM, and without it, a maven repo is just an HTTP store.

Whether the P2 work can be leveraged to have a Maven->P2 link (or vice
versa) is something that could be investigated, but the problem is
that if you rely on e.g. additions to the maven repository then they
are either done sporadically or erroneously. In the case of Eclipse,
several (different) people have uploaded variants of some of the core
Eclipse plugins, but then never get updated as newer versions are
available. If this process were baked into the Eclipse release
process, more people might be tempted to build upon OSGi systems than
they are at the moment.

For those that are interested in building OGSi with Maven, then take a
look at Pax Construct:
  http://wiki.ops4j.org/confluence/display/ops4j/Pax+Construct

There's also Pax Runner, which allows bundles to be launched inside
different OSGi engines, such as Equinox and Felix:
  http://wiki.ops4j.org/confluence/display/ops4j/Pax+Runner

Alex
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Jetty and commons logging

[Alex Blewitt]

On Jan 5, 2008 2:38 PM, Jeff McAffer <[EMAIL PROTECTED]> wrote:
>
> Dave, there isn't one.  For the most part Eclipse teams use the PDE tooling
> to build their bundles.

Having a maven repo would be a really, really good thing for the
Eclipse bundles. After all, it's just a set of directories and some
meta-information (which could be automatically generated from the
bundle's data). If there's anything in the pipeline for a V4.0, having
the ability for the bundles to be consumed by maven users would be a
really good thing.

Alex
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] EclipseCon 2008: An introduction to Pax tools for OSGi

[Alex Blewitt]

Sounds great! If only I could be there ... hope it goes well.

Alex

On Dec 19, 2007 12:21 PM, Stuart McCulloch <[EMAIL PROTECTED]> wrote:
> Hi folks,
>
> Alin and I will be running a tutorial on the Pax tools at EclipseCon 2008:
>
>http://www.eclipsecon.org/2008/index.php?page=sub/&id=59
>
> for those that don't know about Pax, it's a collection of bundles and tools
> for OSGi developed by the OPS4J community using wiki-style development:
>
>
> http://wiki.ops4j.org/confluence/display/ops4j/Open+Participation+Software+for+Java
>
> If there are any specific topics you'd like us to cover, let us know and
> we'll try to work them into the tutorial. Btw, I'm also running a vote on
> my blog to find out which tools/bundles people are most interested in:
>
>
> http://mcculls.blogspot.com/2007/12/introduction-to-pax-tools-for-osgi.html
>
> Hope to see you at EclipseCon, even if you don't make it to our tutorial!
>
> --
> Cheers, Stuart McCulloch (Jayway Malaysia)
>
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] [prov] Comments on wiki "Equinox p2 Shared Install Plan"

[Alex Blewitt]

On Dec 18, 2007 2:00 AM, Jeff McAffer <[EMAIL PROTECTED]> wrote:
>
> Hey James, this is alot of good information.  Would you have a chance to
> update the shared install scenarios document to highlight some of the
> points?  My gut feeling from reading your comments is that most of what you
> suggest is do-able wrt the underlying infrastructure but the current context
> is driving Andrew et al to express things in a different way (that may or
> may not line up with your situations).

I did a search for p2 on the wiki.eclipse.org and failed to find
anything, so apologies for not reading the shared install document.

One thing that would be great for Mac is to have two sets of bundles;
a global (i.e. multi-user) directory, and a per-user directory for
storing bundles. The normal place to put these would be e.g.
/Library/Application Support/Eclipse/Bundles (or plugins) and for a
per-user view, ~/Library/Application Support/Eclipse/Bundles. I don't
know if the support exists at the moment to have a hierarchical set of
bundle repositories like this (nor do I know what the correct terms
are; apologies) but the idea would be that a user could install their
latest FooBar plugin into their own one without affecting everyone
else. I guess the same distinction would be the case for Linux/Unix
users; e.g. /usr/share/eclipse/plugins and ~/.eclipse/plugins might be
appropriate.

The only problem would be writing; all of the mutable data should
really be stored in the ~/Library/Application Support/Eclipse area.
There are issues at the moment with the Mac Eclipse.app launcher,
since if it's dragged-and-dropped into (say) /Applications, it has a
nasty tendency to extract eclipse.exe (or local equivalent) into an
area that it's not supposed to write to.

Lastly, if multi-repository bundles are permitted, then perhaps a
default set could be placed in
Eclipse.app/Contents/Resources/Java/Bundles. That would allow a simple
drag-and-drop of the Eclipse.app in its entirety to a location on
disk.

Are the ideas of hierarchical repositories of bundles supported in p2?

Alex
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Declarative Services with RCP Plug-in Extensions

[Alex Blewitt]

On Nov 28, 2007 12:19 AM, Darren Janeczek <[EMAIL PROTECTED]> wrote:

> Hello.
>
> I need some tips in narrowing down the cause of a problem We've been
> having in our RCP/OSGi application.
>
> Our project is using Declarative Services to manage several bundles of
> services, and Eclipse Plug-in Extensions for various RCP components.
> Everything seems to be running ok, but I'm having trouble with one thing:
> getting the OSGi framework and all of the bundles to shut down when the user
> closes the RCP Application window.
>

Do any of your bundles start threads? If so, make sure that they are set
with thread.setDaemon(true), as otherwise they'll be an active thread which
is keeping the VM active. I don't know what the DS services do with any
threads that they create, but I'd think that would be standard behaviour.


> First, a few questions:
> -
>
> I read articles like
> http://www.eclipsezone.com/articles/extensions-vs-services/ and start to
> worry if our use of both DS and RCP plug-ins is somehow fundamentally
> problematic. There is a lot of functional overlap, but do these two
> approaches ever conflict? Is there a standard way to get them to work
> together to close down when the application is done?


I don't think these approaches conflict; after all, any Eclipse-based RCP
has the ability to use OSGi services (and yes, shutdown cleanly when done).
In any case, the registry is just another bundle.


> Eclipse automatically seems to understand that we want the framework to
> shut down when the application closes, but when we take our jars out into
> the real world, the framework doesn't stop. I suppose this is
> understandable, since we tell OSGi to start the applications and to start
> the bundles and services. How do we tell OSGi that they are linked, and must
> be shut down when the Application closes?


You could put a call to OSGi's shutdown() method, but I don't believe that
you need to do that. You could also iterate through all running bundles and
call 'stop' if you wanted to during shutdown, but I don't think either are
necessary.

You might want to check that the -noexit isn't being passed somewhere, which
would of course prevent that from happening :-)

NB for debugging, you can view the console by a networked port (e.g.
-console 1234) although you probably wouldn't want to use that in production
use. But you might be able to use it to find out which bundles are still
active.

Alex.
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Equinox->Bundles component is getting crowded

[Alex Blewitt]

Frankly, the organisation of Eclipse projects in general falls into
the same problem (i.e. is it in tools/, eclipse/, technology/ ...

On 13/09/2007, BJ Hargrave <[EMAIL PROTECTED]> wrote:
> > It is about community and clarity for our consumers.
>
> I don't see how arbitrary groupings help here. The whole point of the
> component model is people pick the components they need which is why it is
> good that people can download bundles individually. Arbitrary groupings
> would be more interesting perhaps if you actually delivered against the
> groupings.
>
> > Why not reify the structure we think we have?
>
> I think part of the issue is that there is no common view of the structure
> "we think we have" to reify it.
>
> >  would the http service be part of "standard services" or "server side"?
>
> You totally avoid this question by avoiding arbitrary groupings like
> standard services and server side.
>
> Perhaps this whole topic deserves a small slot on the Equinox Summit
> agenda?
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the OSGi Alliance
> [EMAIL PROTECTED]
>
> office: +1 386 848 1781
> mobile: +1 386 848 3788
>
>
>
>
> From:
> Jeff McAffer <[EMAIL PROTECTED]>
> To:
> Equinox development mailing list 
> Date:
> 2007-09-13 09:04
> Subject:
> Re: [equinox-dev] Equinox->Bundles component is getting crowded
>
>
>
>
> to me it is neither of these options.  It is about community and clarity
> for our consumers.  Walking up to Equinox you just have a sea of bundles.
> Add in the p2 and security stuff and the sea turns into an ocean.  Say you
> hear that Equinox has implementations of some OSGi service specs.  If you
> go to the download page today you have to grovel through spec impls,
> launchers, random other stuff and cannot tell one from the other.  Since
> there is no particular web/wiki page for people interested in spec
> implementations, it is hard to build a community around that topic. People
> interested in contributing to standard spec impls cannot easily find
> related bugs etc.  There is also no clear lead of that community who is
> plotting the course/planning, coordinating execution, building the
> community, ...  You can replace OSGi service spec with p2, security, ...
>
>
> A number of these issues can be addressed simply by structuring the
> download site or wiki or...  If you address most of them then in effect
> you have just created a component without actually creating a component.
> So what are we afraid of?  Why not reify the structure we think we have?
>
> That begs the question, what is the structure? The challenge is that all
> partitionings will have problems as different people have different views
> on the world.  would the http service be part of "standard services" or
> "server side"?  However the existance of issues need not stop progress or
> movement.  So this discussion is really about defining that structure.  At
> least thats my view...
>
> Jeff
>
>
>
> BJ Hargrave <[EMAIL PROTECTED]>
> Sent by: [EMAIL PROTECTED]
> 09/12/2007 05:13 PM
>
> Please respond to
> Equinox development mailing list 
>
>
> To
> Equinox development mailing list 
> cc
>
> Subject
> Re: [equinox-dev] Equinox->Bundles component is getting crowded
>
>
>
>
>
>
>
>
> What is the point of the proposed change?  Tom's mail suggests we
> subdivide bundles. But in what way? To organize commit rights or bugs in
> bugzilla? Or both? I guess that is what is not clear. Clarity here will
> help us evaluate choices. It seems we can easily have M bugzilla
> components and N commit right sets with M >=N. Right now (for bundles) M
> and N both equal 1. Are we looking to increase M or N or both?
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the OSGi Alliance
> [EMAIL PROTECTED]
>
> office: +1 386 848 1781
> mobile: +1 386 848 3788
>
>
>
>
> From:
> Jeff McAffer <[EMAIL PROTECTED]>
> To:
> Equinox development mailing list 
> Date:
> 2007-09-12 16:03
> Subject:
> Re: [equinox-dev] Equinox->Bundles component is getting crowded
>
>
>
>
> yes but under the new plan you pointed out, the commit rights will be
> managed by groups and groups will have a 1:1 relationship to components
> and components will have associated leads, bugzilla entries, websites, ...
>
> This is alot of infrastructure to put in place for each bundle.
>
> We did "bundles" originally because we could not come up with any
> reasonable partitioning of the space.  To date we have gotten away with it
>
> because a) the number of bundles in there was relatively low and b) many
> have very little activity.  As Tom points out, this is changing.  Our
> solution space seem to be N bundles => 1 group, N groups or M groups where
>
> 1 < M < N.  Unfortunately, it is still not clear that there is a
> reasonable grouping so while (at least to me) M groups feels like a good
> spot, it will be challenging.  Here are some thoughts
> - "framework" = the framework.  This stays unchanged
> - "standa

Re: [equinox-dev] RCP Application doesn't shut down OSGi console

[Alex Blewitt]

It depends how you are launching it. If you've got 'osgi.noExit=true'
then I'd expect to see that behaviour. Are you running with eclipse
-application ? If so, I'd expect that when your application
returns from the run() method, it would shut down the framework. Do
you know you are returning from that call? How are you determining
that your application is shutting down; is it a case of having a
window be closed? If so, is you readAndDispatch() loop taking care of
the fact that it has been closed?

You might want to find (with the console) by using 'getprop
osgi.noExit' to find out what the value is. You could also do a 'ss'
after you think you've closed your application; that would show which
bundles were stopped (INSTALLED), and which were STOPPING. It may be
that one of your stop() calls is blocking or there's some kind of
deadlock, and since the bundles are still awaiting shutdown, the
framework can't stop either.

Alex.

On 30/08/2007, Volodymyr Babiy <[EMAIL PROTECTED]> wrote:
> Hello
>
> We just have one small question to ask.
>
> Current situation:
> We are running independent bundles, which we have
> developed, inside of the Equinox framework. Our problem is
> that when we manually shut down our Application, the OSGi
> console does not automatically shut down. When we run the
> application from our EXE, the OSGi console is not visible,
> but the JARs are still in use after the application is
> manually closed. This problem becomes apparent when we try
> to delete the JAR bundles when we try to uninstall our
> Application. The Application uses the RCP platform, all
> our bundles communicate through Declarative Services, and
> all of our bundles are coded in Java.
>
> Notes:
>
> - When we run our application through Eclipse Plug-in
> Development, the console DOES shut off naturally when we
> close the Application.
>
> Desired outcome:
> We want a safe way to shut down the entire OSGi framework
> right after the user manually closes the Application when
> it runs from the stand-alone EXE form.
>
> So far, the only way we can turn OSGi off is to ensure
> that the console is on, and to issue an 'exit' command
> manually, but this is not desirable. We have tried
> deactivating all bundles (including bundle #0) and the
> console remained on. All literature seems to suggest that
> the system should shut down automatically once the
> Application has been closed, but we haven't been as
> fortunate. We need help in understanding what we are
> missing.
>
> Any help, suggestions, or advice would be greatly
> appreciated by our team.
> We would like to thank you in advance for your attention.
>
>
>
>
> Out teem would greatly apparition your help.
> Thank you,
> Darren Janeczek
> Volodymyr Babiy
> MIRARCO Mining Innovation
> Sudbury, ON
> Canada
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] [prov] directory watcher

[Alex Blewitt]

Interesting. Does it periodically scan for changes, or does it hook in
with the underlying file system notifications to receive changes? I
believe that the Win32 resources API has the ability to pick up
changes; it would be good if that worked for other systems too.

Does it do the reverse, uninstalling a bundle if the corresponding
file is deleted?

Alex.

On 30/08/2007, Jeff McAffer <[EMAIL PROTECTED]> wrote:
>
> I finally did something that has been on my list for quite some time.
>  Inspired by Peter Kriens' FileInstall bundle, I made a DirectoryWatcher
> that, as the name implies, watches a directory and installs, uninstalls,
> configures, ... things that are dropped into/removed from/changed in the
> dir.  The current working support directly calls installBundle() etc but I
> have also been working on one that calls p2 API to effect and install.  The
> design consists of a DirectoryWatcher with which you can register listeners.
>  The listeners then get added, removed and changed events for the files of
> interest in the directory being watched.  It is quite easy to create a new
> listener that does your own thing.
>
> Keeping in mind that this is quite early, take a look at
> org.eclipse.equinox.p2.directorywatcher
> I have added not this to the PSF files yet as there are some compile errors
> in the provisioning listener as I have not completed enhancing the metadata
> generator to work on individual files rather than directories.  More to come
> later...
>
> Jeff
>
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] [prov] Shared install filesystem layout

[Alex Blewitt]

On 13/08/07, Andrew Overholt <[EMAIL PROTECTED]> wrote:
> * Alex Blewitt <[EMAIL PROTECTED]> [2007-08-10 18:47]:
> > There was some talk a while ago of creating a /usr/share/java for such
> > things. Given that the .jars are architecture independent (even if
> > some of their contents aren't) I'd vote for not splitting the bundles
> > arbitrarily.
>
> We have /usr/share/java for architecture-independent jars already.  If
> the contents aren't architecture-independent, I'd argue that the jars
> themselves shouldn't be considered architecture-independent.

I'd argue that the Jars should go there, even if the contents are
architecture dependent. The reason for this is that the Equinox
runtime selects which Jars to use based on the current OS's
architecture. Indeed, the OSGi spec allows for a single bundle/jar to
have multiple native libraries for different OSs. So in that sense,
the bundles themselves are architecture independent, even if you use a
subset of each.

One of the distinctions between this and the standard Unix library is
that there's a one-library-per-file in a single .dll or .so, whereas
in the Java case, the .jar is a container which may contain .dlls or
.sos for multiple platforms in the same package. And given a set of
OSGi bundles, you can run on all platforms anyway, as long as all
fragments are available; the runtime uses the one that's correct for
that platform.

On the other hand, splitting up the OSGi bundles arbitrarily will lead
to more difficult packaging for cross-platform installs, and runs all
manner of problems when you're trying to e.g. generate a
cross-platform build on any one platform. Having all the bundles in
one place makes it easy to cross-build a Mac OS X app from a Linux
box; having the bundles split across many places means that it's going
to be much more difficult (to the extent that it may be impossible,
given that there may be assumptions that the os-specific fragment and
the architecture-neutral bundle are in the same directory), not to
mention the issue of where you'd install the non-current-OS bundles
(where would the Mac specific bundles be installed on a Linux box in
order to enable cross-compilation?).

Alex.
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] [prov] Shared install filesystem layout

[Alex Blewitt]

On 13/08/07, Pascal Rapicault <[EMAIL PROTECTED]> wrote:
> >where such things
>What does such refer to, plugins or preferences?

Any/all of the above. One suspects that a subdivision of the
~/Library/Application Support/Eclipse/ directory could be performed;
for example .../Eclipse/Bundles/.

There's also a ~/Library/Preferences directory specifically for
preferences, but normally there's one file per application, and I'm
not sure that Eclipse's preferences are suitably well structured to
put into ~/Library/Preferences/ directory.

Alex.

> I should also throw into the mix ... on Macs, there's
> /Library/Application Support/Eclipse and ~/Library/Application
> Support/Eclipse as standard places where such things could go and be
> considered to be on the search path for bundles (I think I suggested
> the idea of a BUNDLEPATH somewhere in one of my bug reports). So
> whilst having a logical separation of ideas is good, let's think about
> how they might work for other OSes as well :-)
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] [prov] Shared install filesystem layout

[Alex Blewitt]

> > - how do you generally handle versions?  for example, it is imaginable
> > that people need Eclipse 3.3 and 3.4 installed.  They both have
> > eclipse.exe, eclipse.ini, ...  Are they packaged with unique names?
>
> Well, in Fedora it's easy because we only ship one version :)  But I
> imagine you'd solve this with a prefix or something:
> ex. /usr/lib/eclipse34 or even (but please no) /opt/eclipse34.

On some systems (e.g. Debian) the use of /etc/alternatives is quite
common. The code is put in a per-directory with version, and then
there's a symbolic link for the system-wide 'default' one:

/etc/alternatives/eclipse -> /usr/lib/eclipse_3-3/eclipse

Others can then use different versions by changing their path.

BTW the /usr/share/ stuff is listed at:

http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA

"The /usr/share hierarchy is for all read-only architecture
independent data files. [30]

This hierarchy is intended to be shareable among all architecture
platforms of a given OS; thus, for example, a site with i386, Alpha,
and PPC platforms might maintain a single /usr/share directory that is
centrally-mounted. Note, however, that /usr/share is generally not
intended to be shared by different OSes or by different releases of
the same OS."

There was some talk a while ago of creating a /usr/share/java for such
things. Given that the .jars are architecture independent (even if
some of their contents aren't) I'd vote for not splitting the bundles
arbitrarily.

Alex.
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] [prov] Shared install filesystem layout

[Alex Blewitt]

I should also throw into the mix ... on Macs, there's
/Library/Application Support/Eclipse and ~/Library/Application
Support/Eclipse as standard places where such things could go and be
considered to be on the search path for bundles (I think I suggested
the idea of a BUNDLEPATH somewhere in one of my bug reports). So
whilst having a logical separation of ideas is good, let's think about
how they might work for other OSes as well :-)

Alex.

On 10/08/07, Alex Blewitt <[EMAIL PROTECTED]> wrote:
> I'd personally be against the platform-specific fragments in a
> .../lib/... dir. Quite often, if you want to ship something, then
> having it mountable in one place (e.g. /usr/share/eclipse) is easier
> than having it in several places. In any case, the Jars themselves are
> platform portable; it's just that some are active on one OS and others
> are active on another OS. I don't see that there's any benefit in
> splitting the definition here, just because there's some kinds of
> difference in fragments. Ideally, you'd want to be able to end up with
> a distribution that could work on multiple platforms anyway, with the
> only difference being the launcher.
>
> FWIW the 'lib' is usually separate from the 'share', because the
> 'share' is mounted noexec, whereas the 'lib' is. That's unnecessary on
> an Eclipse install, though, because the fragments are stored as Jars.
> (it might make a difference to where the .dlls or .sos are extracted
> *to* however, but that's a separate issue.)
>
> One of the big things I think Eclipse misses out on is the ability to
> distinguish 'cache' state from 'preference' state in the .metadata
> (i.e. **/*.prefs vs others). It would be really useful to have the
> concepts of 'etc' (for preferences/configuration), 'var' (for cache
> state that's generally useful to keep around but can be thrown away if
> necessary), 'tmp' (for temporary files that can be wiped on every
> restart, or when the user feels like it). If you had those
> distinctions, it would make migrating from one workspace to another
> easy; you'd just copy the 'etc' component part. There's a secondary
> problem as to how you'd determine programmatically which they were
> from the prefrerences state API, and whether you'd have
> 'org.eclipse.foo/etc' or 'etc/org.eclipse.foo' as the storage layout
> (the latter being easier to bulk move/copy).
>
> A couple of other thoughts in the mix; do you want to have a single
> 'bundles' directory, or have multiple locations? And inside the
> 'bundles' directory, do you have a single flat list or structure it
> more like Maven? I think that instead of a very long flat list, having
> eclipse/emf/ eclipse/jdt/... eclipse/rcp/... etc. would be a good
> way of (a) breaking up the list, and (b) communicating some kind of
> reference as to what the plugins do. Coming up with a suitable naming
> convention might be tricky, but you could always dot-separate the
> bundles by name e.g
> bundles/org/eclipse/equinox/org.eclipse.equinox.ds_1.2.3.jar.
>
> BTW a rename from 'plugins' to 'bundles' would be good if there's big
> changes afoot anyway :-)
>
> Alex.
>
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] [prov] Shared install filesystem layout

[Alex Blewitt]

I'd personally be against the platform-specific fragments in a
.../lib/... dir. Quite often, if you want to ship something, then
having it mountable in one place (e.g. /usr/share/eclipse) is easier
than having it in several places. In any case, the Jars themselves are
platform portable; it's just that some are active on one OS and others
are active on another OS. I don't see that there's any benefit in
splitting the definition here, just because there's some kinds of
difference in fragments. Ideally, you'd want to be able to end up with
a distribution that could work on multiple platforms anyway, with the
only difference being the launcher.

FWIW the 'lib' is usually separate from the 'share', because the
'share' is mounted noexec, whereas the 'lib' is. That's unnecessary on
an Eclipse install, though, because the fragments are stored as Jars.
(it might make a difference to where the .dlls or .sos are extracted
*to* however, but that's a separate issue.)

One of the big things I think Eclipse misses out on is the ability to
distinguish 'cache' state from 'preference' state in the .metadata
(i.e. **/*.prefs vs others). It would be really useful to have the
concepts of 'etc' (for preferences/configuration), 'var' (for cache
state that's generally useful to keep around but can be thrown away if
necessary), 'tmp' (for temporary files that can be wiped on every
restart, or when the user feels like it). If you had those
distinctions, it would make migrating from one workspace to another
easy; you'd just copy the 'etc' component part. There's a secondary
problem as to how you'd determine programmatically which they were
from the prefrerences state API, and whether you'd have
'org.eclipse.foo/etc' or 'etc/org.eclipse.foo' as the storage layout
(the latter being easier to bulk move/copy).

A couple of other thoughts in the mix; do you want to have a single
'bundles' directory, or have multiple locations? And inside the
'bundles' directory, do you have a single flat list or structure it
more like Maven? I think that instead of a very long flat list, having
eclipse/emf/ eclipse/jdt/... eclipse/rcp/... etc. would be a good
way of (a) breaking up the list, and (b) communicating some kind of
reference as to what the plugins do. Coming up with a suitable naming
convention might be tricky, but you could always dot-separate the
bundles by name e.g
bundles/org/eclipse/equinox/org.eclipse.equinox.ds_1.2.3.jar.

BTW a rename from 'plugins' to 'bundles' would be good if there's big
changes afoot anyway :-)

Alex.
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] No available bundle exports package 'javax.swing.event'

[Alex Blewitt]

What OS are you using? I know that the Mac stores its JVM classes over
two files (classes.jar, ui.jar) so I wonder if that might be relevant
here.

Have you configured access rules for any of the JREs in the workspace?
And is your project dependent on a specifically installed JRE or an
OSGi execution environment?

Alex.

On 24/07/07, David Leangen <[EMAIL PROTECTED]> wrote:



> Where do you see the error?  In the java code
> file where you import the javax.swing.event
> package or in your bundle MANIFEST.MF file where
> you use Import-Package: javax.swing.event?

In the bundle manifest.

The compilation error means that Eclipse refuses to build my project until I
"fix" it.


> This package should be exported by the system
> bundle (org.eclipse.osgi in equinox) when running
> on a J2SE-1.2 or higher VM.

That's what I thought.

Using 1.5 currently.

Should I be filing a bug for this, then?


Cheers,
David


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: Re[4]: [equinox-dev] Prosyst contributions

[Alex Blewitt]

The only reference to 'initial' is in the title of the chapter. The
document talks about *provisioning*, not initial provisioning. Initial
is merely an adjective used to describe the provisioning itself.

See, for example, 110.4 where it discusses 'The Provisioning Service'.
Also note that all the constants begin with PROVISIONING_ and indeed,
the classes that make it up are in org.osgi.service.provisioning.
There's no 'initial' about it. In fact, the only initials that have
been used with respect to provisioning have been 'I.P.'.

The fact that it's the first Provisioning Service to be consulted
shouldn't be part of the name. It's merely an adjective used to
describe it.

In any case, I was just observing that the OSGi spec used
'provisioning' almost exclusively in terms of the package, class and
constant names in the description, yet it seems that the Equinox names
are being based on the chapter title. Either way, I don't care;
anything is better than 'ip'. Though frankly, I don't see why
'org.eclipse.equinox. provisioning' providing
'org.osgi.service.provisioning' is such a bad idea.

Alex.

On 08/07/07, BJ Hargrave <[EMAIL PROTECTED]> wrote:

Well, read the spec! :-) Then you will understand the "initial" part!
--

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]

office: +1 386 848 1781
mobile: +1 386 848 3788




"Alex Blewitt" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
2007-07-08 10:29
Please respond to
Equinox development mailing list 


To
"Equinox development mailing list" 
cc

Subject
Re: Re[4]: [equinox-dev] Prosyst contributions






Well, why not call it 'o.e.provisioning' then? What's so initial about it?

On 08/07/07, BJ Hargrave <[EMAIL PROTECTED]> wrote:
> o.e.eq.ip should only be an internal (private) package name. The public
> API is defined by OSGi: org.osgi.service.provisioning.
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the OSGi Alliance
> [EMAIL PROTECTED]
>
> office: +1 386 848 1781
> mobile: +1 386 848 3788
>
>
>
>
> "Alex Blewitt" <[EMAIL PROTECTED]>
> Sent by: [EMAIL PROTECTED]
> 2007-07-08 07:21
> Please respond to
> Equinox development mailing list 
>
>
> To
> "Pavlin Dobrev" <[EMAIL PROTECTED]>
> cc
> Equinox development mailing list 
> Subject
> Re: Re[4]: [equinox-dev] Prosyst contributions
>
>
>
>
>
>
> It would be better to have a more descriptive bundle symbollic name,
> that's for sure. The question then becomes whether it makes sense to
> keep the bundle symbolic name and package name in sync. Given that
> most package imports are handled automatically by Eclipse anyway, the
> only reason I can think for having a shorter package name is that it
> takes up a few less chars in the various UTF-8 constant pools in the
> .class files; but if that were really an issue, we'd be calling the
> packages o.e.eq.ip anyway.
>
> The danger with using 'ip' as the package name is that it effectively
> prevents anyone from having a package with the same name for unrelated
> services; for example, an OSGi bundle for generating ICMP IP packets.
>
> I'd vote for a longer name in both cases. Not that my vote counts for
> anything, but as a periodic lurker on the mailing list ...
>
> Alex.
>
> On 08/07/07, Pavlin Dobrev <[EMAIL PROTECTED]> wrote:
> > Hi Alex,
> >
> > My personal opinion also is that IP is a horible name but maybe as BJ
> > propose we can use long bundle symbolic name?
> >
> > -Pavlin
> >
> > AB> I'm glad I'm not alone. I've asked the question to a wider
audience
> to
> > AB> see if they'd get the reference:
> >
> > AB> http://www.eclipsezone.com/eclipse/forums/t98469.html
> >
> > AB> On 07/07/07, Remy Chi Jian Suen <[EMAIL PROTECTED]> wrote:
> > >> You're not alone, Alex. I think ip is a horrible name.
> > >> initprovisioning or initprov or something would've been better.
> > >> There's just no way that someone's going to know that 'ip' is
> 'initial
> > >> provisioning'.
> > >>
> > >> Regards,
> > >> Rem
> > >>
> > >> On 7/7/07, Alex Blewitt <[EMAIL PROTECTED]> wrote:
> > >> > Am I really the only one who thinks '.ip'  is a bad name?
> > >> >
> > >> > Alex.
> > >> >
> > >> > On 07/07/07, Simon Kaegi <[EMAIL PROTECTED]>

Re: Re[4]: [equinox-dev] Prosyst contributions

[Alex Blewitt]

Well, why not call it 'o.e.provisioning' then? What's so initial about it?

On 08/07/07, BJ Hargrave <[EMAIL PROTECTED]> wrote:

o.e.eq.ip should only be an internal (private) package name. The public
API is defined by OSGi: org.osgi.service.provisioning.
--

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]

office: +1 386 848 1781
mobile: +1 386 848 3788




"Alex Blewitt" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
2007-07-08 07:21
Please respond to
Equinox development mailing list 


To
"Pavlin Dobrev" <[EMAIL PROTECTED]>
cc
Equinox development mailing list 
Subject
Re: Re[4]: [equinox-dev] Prosyst contributions






It would be better to have a more descriptive bundle symbollic name,
that's for sure. The question then becomes whether it makes sense to
keep the bundle symbolic name and package name in sync. Given that
most package imports are handled automatically by Eclipse anyway, the
only reason I can think for having a shorter package name is that it
takes up a few less chars in the various UTF-8 constant pools in the
.class files; but if that were really an issue, we'd be calling the
packages o.e.eq.ip anyway.

The danger with using 'ip' as the package name is that it effectively
prevents anyone from having a package with the same name for unrelated
services; for example, an OSGi bundle for generating ICMP IP packets.

I'd vote for a longer name in both cases. Not that my vote counts for
anything, but as a periodic lurker on the mailing list ...

Alex.

On 08/07/07, Pavlin Dobrev <[EMAIL PROTECTED]> wrote:
> Hi Alex,
>
> My personal opinion also is that IP is a horible name but maybe as BJ
> propose we can use long bundle symbolic name?
>
> -Pavlin
>
> AB> I'm glad I'm not alone. I've asked the question to a wider audience
to
> AB> see if they'd get the reference:
>
> AB> http://www.eclipsezone.com/eclipse/forums/t98469.html
>
> AB> On 07/07/07, Remy Chi Jian Suen <[EMAIL PROTECTED]> wrote:
> >> You're not alone, Alex. I think ip is a horrible name.
> >> initprovisioning or initprov or something would've been better.
> >> There's just no way that someone's going to know that 'ip' is
'initial
> >> provisioning'.
> >>
> >> Regards,
> >> Rem
> >>
> >> On 7/7/07, Alex Blewitt <[EMAIL PROTECTED]> wrote:
> >> > Am I really the only one who thinks '.ip'  is a bad name?
> >> >
> >> > Alex.
> >> >
> >> > On 07/07/07, Simon Kaegi <[EMAIL PROTECTED]> wrote:
> >> > > That's great! I've just done a quick sanity check and everything
compiles,
> >> > > starts and is ready to try out.
> >> > >  Thanks.
> >> > >
> >> > > For anyone wanting to take a look, the following new projects
were added to
> >> > > the incubator.
> >> > >
> >> > > 1) org.eclipse.equinox.ds
> >> > > 2) org.eclipse.equinox.io
> >> > > 3) org.eclipse.equinox.ip
> >> > > 4) org.eclipse.equinox.util
> >> > > 5) org.eclipse.equinox.wireadmin
> >> > >
> >> > > I had one cosmetic question for equinox.util. Currently the BSN
is
> >> > > "org.eclipse.equinox.util.putifull" -- is there some reason it's
not just
> >> > > org.eclipse.equinox.util?
> >> > > -Simon
> >> > >
> >> > > [EMAIL PROTECTED] wrote on 07/07/2007 06:41:23 AM:
> >> > >
> >> > > > In CVS under your proposed naming.
> >> > > >
> >> > > > -Pavlin
> >> > > >
> >> > > > >
> >> > > >
> >> > > > OK, I'm not particular about the names right now.  Since we
already
> >> > > > have a DS bundle lets just use org.eclipse.equinox.ds for
> >> > > > declarative services.
> >> > > >
> >> > > > I also like org.eclipse.equinox.ip for initial provisioning but
> >> > > > thought it might be to short :)  but it is snappy.
> >> > > >
> >> > > > Pavlin, if these are ok with you please release with the names
org.
> >> > > > eclipse.equinox.ds and org.eclipse.equinox.ip.  As I said
before it
> >> > > > is no big deal to rename the bundles if needed in the incubator
later.
> >> > > >
> >> > > > Tom
> >> > > >
> >> &g

Re: Re[4]: [equinox-dev] Prosyst contributions

[Alex Blewitt]

It would be better to have a more descriptive bundle symbollic name,
that's for sure. The question then becomes whether it makes sense to
keep the bundle symbolic name and package name in sync. Given that
most package imports are handled automatically by Eclipse anyway, the
only reason I can think for having a shorter package name is that it
takes up a few less chars in the various UTF-8 constant pools in the
.class files; but if that were really an issue, we'd be calling the
packages o.e.eq.ip anyway.

The danger with using 'ip' as the package name is that it effectively
prevents anyone from having a package with the same name for unrelated
services; for example, an OSGi bundle for generating ICMP IP packets.

I'd vote for a longer name in both cases. Not that my vote counts for
anything, but as a periodic lurker on the mailing list ...

Alex.

On 08/07/07, Pavlin Dobrev <[EMAIL PROTECTED]> wrote:

Hi Alex,

My personal opinion also is that IP is a horible name but maybe as BJ
propose we can use long bundle symbolic name?

-Pavlin

AB> I'm glad I'm not alone. I've asked the question to a wider audience to
AB> see if they'd get the reference:

AB> http://www.eclipsezone.com/eclipse/forums/t98469.html

AB> On 07/07/07, Remy Chi Jian Suen <[EMAIL PROTECTED]> wrote:
>> You're not alone, Alex. I think ip is a horrible name.
>> initprovisioning or initprov or something would've been better.
>> There's just no way that someone's going to know that 'ip' is 'initial
>> provisioning'.
>>
>> Regards,
>> Rem
>>
>> On 7/7/07, Alex Blewitt <[EMAIL PROTECTED]> wrote:
>> > Am I really the only one who thinks '.ip'  is a bad name?
>> >
>> > Alex.
>> >
>> > On 07/07/07, Simon Kaegi <[EMAIL PROTECTED]> wrote:
>> > > That's great! I've just done a quick sanity check and everything 
compiles,
>> > > starts and is ready to try out.
>> > >  Thanks.
>> > >
>> > > For anyone wanting to take a look, the following new projects were added 
to
>> > > the incubator.
>> > >
>> > > 1) org.eclipse.equinox.ds
>> > > 2) org.eclipse.equinox.io
>> > > 3) org.eclipse.equinox.ip
>> > > 4) org.eclipse.equinox.util
>> > > 5) org.eclipse.equinox.wireadmin
>> > >
>> > > I had one cosmetic question for equinox.util. Currently the BSN is
>> > > "org.eclipse.equinox.util.putifull" -- is there some reason it's not just
>> > > org.eclipse.equinox.util?
>> > > -Simon
>> > >
>> > > [EMAIL PROTECTED] wrote on 07/07/2007 06:41:23 AM:
>> > >
>> > > > In CVS under your proposed naming.
>> > > >
>> > > > -Pavlin
>> > > >
>> > > > >
>> > > >
>> > > > OK, I'm not particular about the names right now.  Since we already
>> > > > have a DS bundle lets just use org.eclipse.equinox.ds for
>> > > > declarative services.
>> > > >
>> > > > I also like org.eclipse.equinox.ip for initial provisioning but
>> > > > thought it might be to short :)  but it is snappy.
>> > > >
>> > > > Pavlin, if these are ok with you please release with the names org.
>> > > > eclipse.equinox.ds and org.eclipse.equinox.ip.  As I said before it
>> > > > is no big deal to rename the bundles if needed in the incubator later.
>> > > >
>> > > > Tom
>> > > >
>> > > > Chris Aniszczyk/Austin/[EMAIL PROTECTED]
>> > > > Sent by: [EMAIL PROTECTED]
>> > > > 07/05/2007 09:34 PM
>> > > >
>> > > > Please respond to
>> > > > Equinox development mailing list 
>> > > >
>> > > > To
>> > > >
>> > > > Equinox development mailing list 
>> > > >
>> > > > cc
>> > > >
>> > > > Subject
>> > > >
>> > > > Re: [equinox-dev] Prosyst contributions
>> > > >
>> > > > as an outsider, +1 for DS instead of SCR, there's like 5 people that
>> > > > would get the SCR reference :)
>> > > >
>> > > > initialprovisioning is really long
>> > > >
>> > > > Cheers,
>> > > >
>> > > > ---
>> > > > Chris Aniszczyk | IBM Lotus | Eclipse Committer | http://mea-bloga.
>>

Re: Re[2]: [equinox-dev] Prosyst contributions

[Alex Blewitt]

I'm glad I'm not alone. I've asked the question to a wider audience to
see if they'd get the reference:

http://www.eclipsezone.com/eclipse/forums/t98469.html

On 07/07/07, Remy Chi Jian Suen <[EMAIL PROTECTED]> wrote:

You're not alone, Alex. I think ip is a horrible name.
initprovisioning or initprov or something would've been better.
There's just no way that someone's going to know that 'ip' is 'initial
provisioning'.

Regards,
Rem

On 7/7/07, Alex Blewitt <[EMAIL PROTECTED]> wrote:
> Am I really the only one who thinks '.ip'  is a bad name?
>
> Alex.
>
> On 07/07/07, Simon Kaegi <[EMAIL PROTECTED]> wrote:
> > That's great! I've just done a quick sanity check and everything compiles,
> > starts and is ready to try out.
> >  Thanks.
> >
> > For anyone wanting to take a look, the following new projects were added to
> > the incubator.
> >
> > 1) org.eclipse.equinox.ds
> > 2) org.eclipse.equinox.io
> > 3) org.eclipse.equinox.ip
> > 4) org.eclipse.equinox.util
> > 5) org.eclipse.equinox.wireadmin
> >
> > I had one cosmetic question for equinox.util. Currently the BSN is
> > "org.eclipse.equinox.util.putifull" -- is there some reason it's not just
> > org.eclipse.equinox.util?
> > -Simon
> >
> > [EMAIL PROTECTED] wrote on 07/07/2007 06:41:23 AM:
> >
> > > In CVS under your proposed naming.
> > >
> > > -Pavlin
> > >
> > > >
> > >
> > > OK, I'm not particular about the names right now.  Since we already
> > > have a DS bundle lets just use org.eclipse.equinox.ds for
> > > declarative services.
> > >
> > > I also like org.eclipse.equinox.ip for initial provisioning but
> > > thought it might be to short :)  but it is snappy.
> > >
> > > Pavlin, if these are ok with you please release with the names org.
> > > eclipse.equinox.ds and org.eclipse.equinox.ip.  As I said before it
> > > is no big deal to rename the bundles if needed in the incubator later.
> > >
> > > Tom
> > >
> > > Chris Aniszczyk/Austin/[EMAIL PROTECTED]
> > > Sent by: [EMAIL PROTECTED]
> > > 07/05/2007 09:34 PM
> > >
> > > Please respond to
> > > Equinox development mailing list 
> > >
> > > To
> > >
> > > Equinox development mailing list 
> > >
> > > cc
> > >
> > > Subject
> > >
> > > Re: [equinox-dev] Prosyst contributions
> > >
> > > as an outsider, +1 for DS instead of SCR, there's like 5 people that
> > > would get the SCR reference :)
> > >
> > > initialprovisioning is really long
> > >
> > > Cheers,
> > >
> > > ---
> > > Chris Aniszczyk | IBM Lotus | Eclipse Committer | http://mea-bloga.
> > > blogspot.com | +1.860.839.2465
> > >
> > > [image removed] Jeff McAffer ---07/05/2007 09:13:02 PM---I agree
> > > with all/most Tom said. In the end we should look to have just one
> > > DS implementation, Ultimately I suggest that it be
> > >
> > > [image removed]
> > > From:
> > >
> > > [image removed]
> > > Jeff McAffer <[EMAIL PROTECTED]>
> > >
> > > [image removed]
> > > To:
> > >
> > > [image removed]
> > > Equinox development mailing list 
> > >
> > > [image removed]
> > > Date:
> > >
> > > [image removed]
> > > 07/05/2007 09:13 PM
> > >
> > > [image removed]
> > > Subject:
> > >
> > > [image removed]
> > > Re: [equinox-dev] Prosyst contributions
> > >
> > > I agree with all/most Tom said. In the end we should look to have
> > > just one DS implementation, Ultimately I suggest that it be called
> > > o.e.e.ds. Never did like "scr". I'm a little bummed by o.e.e.
> > > initialprovisioning. o.e.e.ip is snappier and I doubt that anyone
> > > would get confused with Intelectual property, or Internet Protocol
> > > or, ... In any event, it is a mild dislike so...
> > >
> > > Lets get the code in the incubator and move forward.
> > >
> > > Jeff
> > >
> > > Thomas Watson <[EMAIL PROTECTED]>
> > > Sent by: [EMAIL PROTECTED]
> > > 07/05/2007 03:51 PM
> > >
> > > Please respond to
> > > Equinox development mailing list 
> > >
> > >

Re: Re[2]: [equinox-dev] Prosyst contributions

[Alex Blewitt]

Am I really the only one who thinks '.ip'  is a bad name?

Alex.

On 07/07/07, Simon Kaegi <[EMAIL PROTECTED]> wrote:

That's great! I've just done a quick sanity check and everything compiles,
starts and is ready to try out.
 Thanks.

For anyone wanting to take a look, the following new projects were added to
the incubator.

1) org.eclipse.equinox.ds
2) org.eclipse.equinox.io
3) org.eclipse.equinox.ip
4) org.eclipse.equinox.util
5) org.eclipse.equinox.wireadmin

I had one cosmetic question for equinox.util. Currently the BSN is
"org.eclipse.equinox.util.putifull" -- is there some reason it's not just
org.eclipse.equinox.util?
-Simon

[EMAIL PROTECTED] wrote on 07/07/2007 06:41:23 AM:

> In CVS under your proposed naming.
>
> -Pavlin
>
> >
>
> OK, I'm not particular about the names right now.  Since we already
> have a DS bundle lets just use org.eclipse.equinox.ds for
> declarative services.
>
> I also like org.eclipse.equinox.ip for initial provisioning but
> thought it might be to short :)  but it is snappy.
>
> Pavlin, if these are ok with you please release with the names org.
> eclipse.equinox.ds and org.eclipse.equinox.ip.  As I said before it
> is no big deal to rename the bundles if needed in the incubator later.
>
> Tom
>
> Chris Aniszczyk/Austin/[EMAIL PROTECTED]
> Sent by: [EMAIL PROTECTED]
> 07/05/2007 09:34 PM
>
> Please respond to
> Equinox development mailing list 
>
> To
>
> Equinox development mailing list 
>
> cc
>
> Subject
>
> Re: [equinox-dev] Prosyst contributions
>
> as an outsider, +1 for DS instead of SCR, there's like 5 people that
> would get the SCR reference :)
>
> initialprovisioning is really long
>
> Cheers,
>
> ---
> Chris Aniszczyk | IBM Lotus | Eclipse Committer | http://mea-bloga.
> blogspot.com | +1.860.839.2465
>
> [image removed] Jeff McAffer ---07/05/2007 09:13:02 PM---I agree
> with all/most Tom said. In the end we should look to have just one
> DS implementation, Ultimately I suggest that it be
>
> [image removed]
> From:
>
> [image removed]
> Jeff McAffer <[EMAIL PROTECTED]>
>
> [image removed]
> To:
>
> [image removed]
> Equinox development mailing list 
>
> [image removed]
> Date:
>
> [image removed]
> 07/05/2007 09:13 PM
>
> [image removed]
> Subject:
>
> [image removed]
> Re: [equinox-dev] Prosyst contributions
>
> I agree with all/most Tom said. In the end we should look to have
> just one DS implementation, Ultimately I suggest that it be called
> o.e.e.ds. Never did like "scr". I'm a little bummed by o.e.e.
> initialprovisioning. o.e.e.ip is snappier and I doubt that anyone
> would get confused with Intelectual property, or Internet Protocol
> or, ... In any event, it is a mild dislike so...
>
> Lets get the code in the incubator and move forward.
>
> Jeff
>
> Thomas Watson <[EMAIL PROTECTED]>
> Sent by: [EMAIL PROTECTED]
> 07/05/2007 03:51 PM
>
> Please respond to
> Equinox development mailing list 
>
> To
>
> Equinox development mailing list 
>
> cc
>
> [image removed]
>
> Subject
>
> Re: [equinox-dev] Prosyst contributions
>
> [image removed]
>
> [image removed]
>
> > Hi Simon,
> >
> > I can commit the sources in the CVS. Here are the open issues
> > that should be resolved prior moving code to the CVS.
> >
> > 1. Naming.
> > Following the discussion the last proposed naming is:
> > 1.1 org.eclipse.equionx.initialprovisioning
> > other suggestion: org.eclipse.equionx.ip
>
> +1 for org.eclipse.equinox.initialprovisioning
>
> I think this name will reduce an confusion with the
> rest of the equinox provisioning work.
>
> > 1.2 org.eclipse.equionx.ds
> > other suggestion: org.eclipse.equionx.scr
>
> +1 for org.eclipse.equinox.scr
>
> > 1.3 org.eclipse.equinox.io
> > 1.4 org.eclipse.equinox.util
> > 1.5 org.eclipse.equinox.wireadmin
> >
> > 2. Replacing. If we use the names org.eclipse.equinox.wireadmin and
> > org.eclipse.equionx.ds they collide with the current one. Can we
replace
> > the code in the CVS at this stage directly or temporary other names
> > will be used?
>
> There is no problem replacing the current implementations in the
> incubator.  To be clear this is under the equinox-incubator directory
> at dev.eclipse.org:/cvsroot/eclipse.  At this point I suggest we
> get the initial code released in the incubator.  It is likely that
> a number of refactorings are going be needed to follow other
> eclipse coding practices (i.e. using "internal" package names etc.).
>
> I'm not fussed on getting all the names correct initially.  We
> can easily rename them if needed in the incubator.
>
> >
> > 3. javax.microedition.io package
> > Now it is in Connector services implementation. This is not a good
> > choice because it is needed only on Java SE VMs. J2ME VMs
> > contains that package. In our equinox distribution it is a fragment of
> > the system bundle that is installed only on Java SE VMs.
> > But initially we can put it inside the connector implementation.
> >
> > -Pavlin
> >
>
> I think we should consider separating this out into another bund

Re: [equinox-dev] Prosyst contributions

[Alex Blewitt]

I'm one of the vehement people against IP. There's too many acronyms
that already use that.

http://en.wikipedia.org/wiki/IP

Given that people are likely to read 'initialprovisioning' and
immediately get what it means (but not vice versa) I'd put in a strong
vote for the longer name.

DS I'd say to keep, because that's what Equinox already uses.

Alex.

On 06/07/07, Thomas Watson <[EMAIL PROTECTED]> wrote:


OK, I'm not particular about the names right now.  Since we already have a
DS bundle lets just use org.eclipse.equinox.ds for declarative services.

I also like org.eclipse.equinox.ip for initial provisioning but thought it
might be to short :)  but it is snappy.

Pavlin, if these are ok with you please release with the names
org.eclipse.equinox.ds and org.eclipse.equinox.ip.  As I said before it is
no big deal to rename the bundles if needed in the incubator later.

 Tom






Chris Aniszczyk/Austin/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]

07/05/2007 09:34 PM


Please respond to
 Equinox development mailing list 


To Equinox development mailing list 

cc

Subject Re: [equinox-dev] Prosyst contributions





as an outsider, +1 for DS instead of SCR, there's like 5 people that would
get the SCR reference :)

 initialprovisioning is really long

 Cheers,

 ---
 Chris Aniszczyk | IBM Lotus | Eclipse Committer |
http://mea-bloga.blogspot.com | +1.860.839.2465

 Jeff McAffer ---07/05/2007 09:13:02 PM---I agree with all/most Tom said. In
the end we should look to have just one DS implementation, Ultimately I
suggest that it be


 From:
 Jeff McAffer <[EMAIL PROTECTED]>

 To:
 Equinox development mailing list 

 Date:
 07/05/2007 09:13 PM

 Subject:
 Re: [equinox-dev] Prosyst contributions
 




 I agree with all/most Tom said. In the end we should look to have just one
DS implementation, Ultimately I suggest that it be called o.e.e.ds. Never
did like "scr". I'm a little bummed by o.e.e.initialprovisioning. o.e.e.ip
is snappier and I doubt that anyone would get confused with Intelectual
property, or Internet Protocol or, ... In any event, it is a mild dislike
so...

 Lets get the code in the incubator and move forward.

 Jeff






Thomas Watson <[EMAIL PROTECTED]>
 Sent by: [EMAIL PROTECTED]

07/05/2007 03:51 PM



Please respond to
 Equinox development mailing list 



To Equinox development mailing list 

cc

Subject Re: [equinox-dev] Prosyst contributions








 > Hi Simon,
 >
 > I can commit the sources in the CVS. Here are the open issues
 > that should be resolved prior moving code to the CVS.
 >
 > 1. Naming.
 > Following the discussion the last proposed naming is:
 > 1.1 org.eclipse.equionx.initialprovisioning
 > other suggestion: org.eclipse.equionx.ip

 +1 for org.eclipse.equinox.initialprovisioning

 I think this name will reduce an confusion with the
 rest of the equinox provisioning work.

 > 1.2 org.eclipse.equionx.ds
 > other suggestion: org.eclipse.equionx.scr

 +1 for org.eclipse.equinox.scr

 > 1.3 org.eclipse.equinox.io
 > 1.4 org.eclipse.equinox.util
 > 1.5 org.eclipse.equinox.wireadmin
 >
 > 2. Replacing. If we use the names org.eclipse.equinox.wireadmin and
 > org.eclipse.equionx.ds they collide with the current one. Can we replace
 > the code in the CVS at this stage directly or temporary other names
 > will be used?

 There is no problem replacing the current implementations in the
 incubator.  To be clear this is under the equinox-incubator directory
 at dev.eclipse.org:/cvsroot/eclipse.  At this point I
suggest we
 get the initial code released in the incubator.  It is likely that
 a number of refactorings are going be needed to follow other
 eclipse coding practices (i.e. using "internal" package names etc.).

 I'm not fussed on getting all the names correct initially.  We
 can easily rename them if needed in the incubator.

 >
 > 3. javax.microedition.io package
 > Now it is in Connector services implementation. This is not a good
 > choice because it is needed only on Java SE VMs. J2ME VMs
 > contains that package. In our equinox distribution it is a fragment of
 > the system bundle that is installed only on Java SE VMs.
 > But initially we can put it inside the connector implementation.
 >
 > -Pavlin
 >

 I think we should consider separating this out into another bundle and
 import the packages from org.eclipse.equinox.io (but we can do this later).
 I'm not sure why it has to be a system bundle fragment.  I think we should
 make it a normal bundle (called javax.microedition.io?).

 Tom ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equin