Re: [equinox-dev] Issue with Felix SCR and Dependency manager Annotations jars with Eclipse Equinox R4_19
Hi, you should try to annotate you SCR Components using the OSGi annotations: - org.osgi.service.component.annotations.Component - org.osgi.service.component.annotations.Activate - org.osgi.service.component.annotations.Deactivate and so on. But remember that these annotations are build time annotations, So you need tools like bndtools or the PDE (PDE only support DS until 1.3) that generate the metadata (componenten - xml files) for these annotations. Felic SCR is the implementation for OSGi Declarative Services: It is the implementation for OSGi Declarative Services: https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html https://developer.ibm.com/articles/osgi-demystified-part-5-using-declarative-services/ I hope this helps. Regards, Mark Am 09.12.21 um 11:01 schrieb Kuldeep Singh Budania: Hi All, I am working on an OSGI project where I am upgrading jetty and OSGI versions from R-4.9 to R4_19_maintenance and Jetty version is getting upgraded from 9.4.11 to 9.4.44 I was using org.eclipse.equinox.ds(1.4.400) as a bundle earlier which was using org.apache.felix internally. Since org.eclipse.equinox.ds dependency has been removed from R4_19_maintenance, I have added dependency of org.apache.felix.scr(2.1.24) but the issue is org.apache.felix.scr.annotation services are not getting activated. *(Activate* *method is not being called)* Also, the same is happening with org.apache.felix.scr.dependencymanager.annotations (3.2.0) and the services are not getting started *(Start method is not being called)* Can you please help me in knowing if it is the version of org.apache.felix.scr.annotation that is causing the issue, if yes, which version it supports or what could be the possible issues that might be causing this. I appreciate your quick response and thanks in advance. Thanks, - Kuldeep Singh Budania ___ equinox-dev mailing list equinox-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev -- Mark Hoffmann M.A. Dipl.-Betriebswirt (FH) Geschäftsführer Tel:+49 3641 384 910 0 Mobil: +49 175 701 2201 E-Mail: m.hoffm...@data-in-motion.biz Web: www.datainmotion.de Data In Motion Consulting GmbH Kahlaische Straße 4 07745 Jena Geschäftsführer Mark Hoffmann Jürgen Albert Jena HRB 513025 Steuernummer 162/107/05779 USt-Id DE310002614 ___ equinox-dev mailing list equinox-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Best way to contribute values (eg PGP keys) with OSGi?
Hello,as far as I know P2 supports OSGi Capabilities and Requirements that Tom mentioned.Mark Hoffmann M.A. Dipl.-Betriebswirt (FH) CEO/CTO Phone: +49 3641 384 910 0 Mobile: +49 175 701 2201 E-Mail: m.hoffm...@data-in-motion.biz Web: www.datainmotion.de Data In Motion Consulting GmbH Kahlaische Strasse 4 07745 Jena Germany Geschäftsführer/CEO Mark Hoffmann Jürgen Albert Jena HRB 513025 Steuernummer 162/107/05779 USt-Id DE310002614 Ursprüngliche Nachricht Von: Mickael Istria Datum: 01.12.21 16:43 (GMT+01:00) An: Equinox development mailing list , P2 developer discussions Betreff: [equinox-dev] Best way to contribute values (eg PGP keys) with OSGi? Hi all,In the context of https://bugs.eclipse.org/bugs/show_bug.cgi?id=577248 , we need a way for bundles (that were preliminary approved by user) to be capable of contributing some PGP public keys as being "trusted by default". I'm wondering what would be the best way to contribute such extensibility in p2. p2 doesn't define extension points, but uses OSGi Services; but here we only want to contribute a value (that could be the armoured keys, or a path to a resource in the bundle containing such keys...). As far as I am aware -ie not much-, I see 3 possible approaches:1. Define a service interface and let bundles contribute extensions to this interface, eg via OSGI-INF/component.xml * Requires to create 1 service/API interace * Would consuming the service from a bundle automatically trigger bundle activation? That would be undesired.2. Add support for a custom MANIFEST header, something like `Eclipse-P2-PGP-TrustedKey`. * Seems a bit alien, would require some support in toolsAre there other solutions you think could fit? What should be preferred?Thanks in advance-- Mickael IstriaEclipse IDE developer, for Red Hat Developers ___ equinox-dev mailing list equinox-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] OSGi and javax.jws.WebService with Java 11
Hi Lars,obviously the implementations want to have different Jaxb implementations. com.sun.xml vs the glassfish one. Maybe choosing just the obe from the Jax-Ws stuff is your candidate.This is why we use EMF for that 😉Mark Hoffmann M.A. Dipl.-Betriebswirt (FH) CEO/CTO Phone: +49 3641 384 910 0 Mobile: +49 175 701 2201 E-Mail: m.hoffm...@data-in-motion.biz Web: www.datainmotion.de Data In Motion Consulting GmbH Kahlaische Strasse 4 07745 Jena Germany Geschäftsführer/CEO Mark Hoffmann Jürgen Albert Jena HRB 513025 Steuernummer 162/107/05779 USt-Id DE310002614 Ursprüngliche Nachricht Von: Lars Vogel Datum: 07.05.21 12:44 (GMT+01:00) An: Equinox development mailing list Betreff: Re: [equinox-dev] OSGi and javax.jws.WebService with Java 11 Hi Mark,thanks. The additional fragment was indeed necessary. I added it andnow it complains about the JaxB configuration.Caused by: jakarta.xml.bind.JAXBException: return is not a validproperty on classcom.example.rcpclient.handlers.jaxws.SayHelloResponse atorg.glassfish.jaxb.runtime.v2.runtime.JAXBContextImpl.getElementPropertyAccessor(JAXBContextImpl.java:908)at com.sun.xml.ws.db.glassfish.JAXBRIContextWrapper.getElementPropertyAccessor(JAXBRIContextWrapper.java:91)at com.sun.xml.ws.server.sei.EndpointResponseMessageBuilder$DocLit.(EndpointResponseMessageBuilder.java:228)… 54 moreI didn't know that Java Webservices uses JaxB under the hood. :-OI will try to configure this and update this message thread with the results:For reference, here is an example with the current state:https://github.com/vogellacompany/eclipsercp-javaws-java11Thanks also to Gunnar for the tip and Christoph for the amazing m2E /PDE integration which makes using libraries super easy.Best regards, LarsOn Fri, May 7, 2021 at 8:38 AM Mark Hoffmann wrote:>> Hi Lars,>> this might be possible, but its always worth to take a look into the API Code. In the area if Jaxb ans JaxWs there have been default providers defined in the lookup process.>> This is what the fragments are for. Take a look into jakarta.xml.soap maybe you also need a fragment for this with Import Package com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl>> Mark Hoffmann> M.A. Dipl.-Betriebswirt (FH)> CEO/CTO>> Phone: +49 3641 384 910 0> Mobile: +49 175 701 2201> E-Mail: m.hoffm...@data-in-motion.biz>> Web: www.datainmotion.de>> Data In Motion Consulting GmbH> Kahlaische Strasse 4> 07745 Jena> Germany>> Geschäftsführer/CEO> Mark Hoffmann> Jürgen Albert>> Jena HRB 513025> Steuernummer 162/107/05779> USt-Id DE310002614>>> Ursprüngliche Nachricht > Von: Lars Vogel > Datum: 06.05.21 18:02 (GMT+01:00)> An: Equinox development mailing list > Betreff: Re: [equinox-dev] OSGi and javax.jws.WebService with Java 11>> Thanks, Mark for the answer. That fixed the reported error.>> I now get another error (see below) but I assume this is due to> missing libraries. I have a look and see if I can fix these.>> java.lang.Error: jakarta.xml.soap.SOAPException: Unable to create SAAJ> meta-factory: Provider> com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl not found> Caused by: jakarta.xml.soap.SOAPException: Unable to create SAAJ> meta-factory: Provider> com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl not> found)>> On Thu, May 6, 2021 at 3:54 PM Mark Hoffmann> wrote:> >> > Hi Lars,> >> > this is simular related to Jaxb. I believe you will need a Frgament for the jakarta.xml.ws-api that declares an Import to ProviderImpl> >> > Regards,> >> > Mark Hoffmann> > M.A. Dipl.-Betriebswirt (FH)> > CEO/CTO> >> > Phone: +49 3641 384 910 0> > Mobile: +49 175 701 2201> > E-Mail: m.hoffm...@data-in-motion.biz> >> > Web: www.datainmotion.de> >> > Data In Motion Consulting GmbH> > Kahlaische Strasse 4> > 07745 Jena> > Germany> >> > Geschäftsführer/CEO> > Mark Hoffmann> > Jürgen Albert> >> > Jena HRB 513025> > Steuernummer 162/107/05779> > USt-Id DE310002614> >> >> > Ursprüngliche Nachricht > > Von: Lars Vogel > > Datum: 06.05.21 15:15 (GMT+01:00)> > An: Equinox development mailing list > > Betreff: [equinox-dev] OSGi and javax.jws.WebService with Java 11> >> > Hi,> >> > I'm trying to migrate an RCP client to Java 11. All good so far only> > the webservice which was part of Java 8 refused to start with an> > sun.xml.internal.ws.spi.ProviderImpl exception.> >> > Exception:> > Caused by: javax.xml.ws.WebServiceException: Provider> > com.sun.xml.internal.ws.spi.ProviderI
Re: [equinox-dev] OSGi and javax.jws.WebService with Java 11
Hi Lars,this might be possible, but its always worth to take a look into the
API Code. In the area if Jaxb ans JaxWs there have been default providers
defined in the lookup process. This is what the fragments are for. Take a look
into jakarta.xml.soap maybe you also need a fragment for this with Import
Package com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImplMark
Hoffmann M.A. Dipl.-Betriebswirt (FH) CEO/CTO Phone: +49 3641 384 910 0
Mobile: +49 175 701 2201 E-Mail: m.hoffm...@data-in-motion.biz Web:
www.datainmotion.de Data In Motion Consulting GmbH Kahlaische Strasse 4 07745
Jena Germany Geschäftsführer/CEO Mark Hoffmann Jürgen Albert Jena HRB 513025
Steuernummer 162/107/05779 USt-Id DE310002614
Ursprüngliche Nachricht Von: Lars Vogel
Datum: 06.05.21 18:02 (GMT+01:00) An: Equinox
development mailing list Betreff: Re: [equinox-dev]
OSGi and javax.jws.WebService with Java 11 Thanks, Mark for the answer. That
fixed the reported error.I now get another error (see below) but I assume this
is due tomissing libraries. I have a look and see if I can fix
these.java.lang.Error: jakarta.xml.soap.SOAPException: Unable to create
SAAJmeta-factory:
Providercom.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl not
foundCaused by: jakarta.xml.soap.SOAPException: Unable to create
SAAJmeta-factory:
Providercom.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl
notfound)On Thu, May 6, 2021 at 3:54 PM Mark
Hoffmann wrote:>> Hi Lars,>> this is simular
related to Jaxb. I believe you will need a Frgament for the jakarta.xml.ws-api
that declares an Import to ProviderImpl>> Regards,>> Mark Hoffmann> M.A.
Dipl.-Betriebswirt (FH)> CEO/CTO>> Phone: +49 3641 384 910 0> Mobile: +49 175
701 2201> E-Mail: m.hoffm...@data-in-motion.biz>> Web: www.datainmotion.de>>
Data In Motion Consulting GmbH> Kahlaische Strasse 4> 07745 Jena> Germany>>
Geschäftsführer/CEO> Mark Hoffmann> Jürgen Albert>> Jena HRB 513025>
Steuernummer 162/107/05779> USt-Id DE310002614>>> Ursprüngliche
Nachricht > Von: Lars Vogel > Datum: 06.05.21
15:15 (GMT+01:00)> An: Equinox development mailing list
> Betreff: [equinox-dev] OSGi and javax.jws.WebService
with Java 11>> Hi,>> I'm trying to migrate an RCP client to Java 11. All good
so far only> the webservice which was part of Java 8 refused to start with an>
sun.xml.internal.ws.spi.ProviderImpl exception.>> Exception:> Caused by:
javax.xml.ws.WebServiceException: Provider>
com.sun.xml.internal.ws.spi.ProviderImpl not found> at
javax.xml.ws.spi.FactoryFinder$1.createException(FactoryFinder.java:61)> at
javax.xml.ws.spi.FactoryFinder$1.createException(FactoryFinder.java:58)> at
javax.xml.ws.spi.ServiceLoaderUtil.newInstance(ServiceLoaderUtil.java:103)> at
javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:112)> at
javax.xml.ws.spi.Provider.provider(Provider.java:96)> at
javax.xml.ws.Endpoint.publish(Endpoint.java:254)> at
eupen.rcp.core.handers.StartWebserviceHandler.execute(StartWebserviceHandler.java:15)>
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native>
Method)> at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)>
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)>
at java.base/java.lang.reflect.Method.invoke(Method.java:564)> at
org.eclipse.e4.c>> Example:>> import javax.jws.WebMethod;> import
javax.jws.WebService;>> @WebService> public class WebServiceExample {>
private String message = new String("Hello, ");>> public void Hello() {}>>
@WebMethod> public String sayHello(String name) {> return
message + name + ".";> }> }>> And I start it via:> > import
org.eclipse.e4.core.di.annotations.Execute;>> import javax.xml.ws.Endpoint;>>
public class StartWebserviceHandler {>> @Execute> public void execute() {>
String url = "http://localhost:4434/miniwebservice";;> Endpoint.publish(
url, new WebServiceExample() );> }> }>> ->>> I started to add libraries
from Maven central via the new PDE / M2e> integration but it seems that this
pull and endless list of> dependencies into the classpath.>> Is anyone aware of
a working example using such a Webservice inside> OSGi with Java 11 or
higher?>> Best regards, Lars>> --> Eclipse Platform project co-lead> CEO
vogella GmbH>> Haindaalwisch 17a, 22395 Hamburg> Amtsgericht Hamburg: HRB
127058> Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel> USt-IdNr.:
DE284122352> Fax (040) 5247 6322, Email: lars.vo...@
Re: [equinox-dev] OSGi and javax.jws.WebService with Java 11
Hi Lars, this is simular related to Jaxb. I believe you will need a Frgament
for the jakarta.xml.ws-api that declares an Import to ProviderImplRegards,Mark
Hoffmann M.A. Dipl.-Betriebswirt (FH) CEO/CTO Phone: +49 3641 384 910 0
Mobile: +49 175 701 2201 E-Mail: m.hoffm...@data-in-motion.biz Web:
www.datainmotion.de Data In Motion Consulting GmbH Kahlaische Strasse 4 07745
Jena Germany Geschäftsführer/CEO Mark Hoffmann Jürgen Albert Jena HRB 513025
Steuernummer 162/107/05779 USt-Id DE310002614
Ursprüngliche Nachricht Von: Lars Vogel
Datum: 06.05.21 15:15 (GMT+01:00) An: Equinox
development mailing list Betreff: [equinox-dev] OSGi
and javax.jws.WebService with Java 11 Hi,I'm trying to migrate an RCP client to
Java 11. All good so far onlythe webservice which was part of Java 8 refused to
start with ansun.xml.internal.ws.spi.ProviderImpl exception.Exception:Caused
by: javax.xml.ws.WebServiceException:
Providercom.sun.xml.internal.ws.spi.ProviderImpl not foundat
javax.xml.ws.spi.FactoryFinder$1.createException(FactoryFinder.java:61)at
javax.xml.ws.spi.FactoryFinder$1.createException(FactoryFinder.java:58)at
javax.xml.ws.spi.ServiceLoaderUtil.newInstance(ServiceLoaderUtil.java:103)at
javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:112)at
javax.xml.ws.spi.Provider.provider(Provider.java:96)at
javax.xml.ws.Endpoint.publish(Endpoint.java:254)at
eupen.rcp.core.handers.StartWebserviceHandler.execute(StartWebserviceHandler.java:15)at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(NativeMethod)at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at
java.base/java.lang.reflect.Method.invoke(Method.java:564)at
org.eclipse.e4.cExample:import javax.jws.WebMethod;import
javax.jws.WebService;@WebServicepublic class WebServiceExample { private
String message = new String("Hello, "); public void Hello() {} @WebMethod
public String sayHello(String name) { return message + name + ".";
}}And I start it via:import
org.eclipse.e4.core.di.annotations.Execute;import javax.xml.ws.Endpoint;public
class StartWebserviceHandler {@Executepublic void execute() { String url =
"http://localhost:4434/miniwebservice"; Endpoint.publish( url, new
WebServiceExample() );}}-I started to add libraries from Maven central
via the new PDE / M2eintegration but it seems that this pull and endless list
ofdependencies into the classpath.Is anyone aware of a working example using
such a Webservice insideOSGi with Java 11 or higher?Best regards, Lars--
Eclipse Platform project co-leadCEO vogella GmbHHaindaalwisch 17a, 22395
HamburgAmtsgericht Hamburg: HRB 127058Geschäftsführer: Lars Vogel, Jennifer
Nerlich de VogelUSt-IdNr.: DE284122352Fax (040) 5247 6322, Email:
lars.vo...@vogella.com, Web:
http://www.vogella.com___equinox-dev
mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/equinox-dev___
equinox-dev mailing list
equinox-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Bug 566085 - javax.annotation package-uses problems with Java 8
Hi Neil, somehow I have the feeling, this problem can be solved in a different way. If the osgi.framework.system.packages / extra is provided including a version qualifier for JavaSE-1.8. Mostly, I see, if provided at all, that these definitions are provided without version attribute. If I understand it correctly in https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.resolvingprocess. The resolver preference priorities are resolved exporter before unresolved exporters and then versioned exports before un-versioned. That would mean that the system-bundle with system.packages is always resolved, and would preferred before other bundles. If then also a correct version is provided in the system.packages, it should be the preferred wire before all others. Adding an Import-Package, where an Export-Package exist, could also lead to the situation, where the Import-Package is ignored by the framework: https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-import.export.same.package Or am I missing something here? Regards, Mark Am 26.08.20 um 16:44 schrieb Neil Bartlett: I'm not sure that class loading order is even relevant here. The stack trace linked by Brian was an OSGi resolution error... resolution happens before a Bundle ClassLoader is constructed and therefore before the bundle attempts to load any class name. Neil On Sat, 22 Aug 2020 at 09:50, Mark Hoffmann mailto:mark.hoffm...@web.de>> wrote: Hi, I dont think that this is final solution for that problem. The class finding search order is defined in OSGi: https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.overallsearchorder That mean finding a class to be loaded will be initially done using the boot delegation (Step 2 in this case). If defined correctly the following will happen: Java 1.8 - delegate to parent class loader an load javax.annotation from there (no matter, if you have an bundle provided for that package) Java 11 - cannot find javax.annotation over boot-delegation, go on with Import-Package or Require-Bundle Either provide a org.osgi.framework.bootdelegation=javax.* as property to activate boot-delegation or you can use the existing profiles instead. The Profiles are defined in Equinox: https://github.com/eclipse/rt.equinox.framework/blob/master/bundles/org.eclipse.osgi/JavaSE-1.8.profile You can find the property: org.osgi.framework.bootdelegation there with a definition for javax.* To make Equinox use this profile (I dont know, if this happens by default) via launcher, you should provide the osgi.java.profile=file://JavaSE-1.8.profile If you take the profile, then you have to additionally provide the property: osgi.java.profile.bootdelegation=override, so that Equinox takes the profile boot delegation entries. instead of already defined ones With the correct boot-delegation configuration, always that same class loader will be taken for this constellation, no matter, if in Java 1.8 or 11. The same applies to JAXB problems. https://wiki.eclipse.org/Equinox_Boot_Delegation Regards, Mark Am 21.08.20 um 22:43 schrieb Brian de Alwis: Unfortunately javax.annotation /package-uses/ issues have returned <https://bugs.eclipse.org/bugs/show_bug.cgi?id=566085> :( The effort to replace the no-longer maintained Spotify Docker <https://bugs.eclipse.org/bugs/show_bug.cgi?id=558284>Client <https://bugs.eclipse.org/bugs/show_bug.cgi?id=558284> (bug 558284) <https://bugs.eclipse.org/bugs/show_bug.cgi?id=558284> introduced a new version of the javax.annotation bundle into Orbit <https://git.eclipse.org/r/c/orbit/orbit-recipes/+/161789> based on Jakarta EE’s somewhat recently released javax.annotation bundle with version 1.3.5 <https://search.maven.org/artifact/jakarta.annotation/jakarta.annotation-api/1.3.5/jar>. This bundle doesn’t use the same approach used for the javax.annotation 1.2.0 bundle <https://bugs.eclipse.org/bugs/show_bug.cgi?id=462686#c27> to use import-what-you-export /and/ requiring system.bundle. The issue only occurs on Java 8 and has been seen in the wild <https://github.com/GoogleCloudPlatform/google-cloud-eclipse/issues/3623>. I suspect it has not been more widespread due to increased adoption of Java 11. I’ve pushed up a fix to the javax.annotation 1.3.5 bundle <https://git.eclipse.org/r/c/orbit/orbit-recipes/+/167718>. I think the risk is small, but given that we’re in RC season, it would be good to get some more eyes on this. If you have concerns, please comment on Bug 566085 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=566085>. Brian. _
Re: [equinox-dev] Bug 566085 - javax.annotation package-uses problems with Java 8
Hi, I dont think that this is final solution for that problem. The class finding search order is defined in OSGi: https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.overallsearchorder That mean finding a class to be loaded will be initially done using the boot delegation (Step 2 in this case). If defined correctly the following will happen: Java 1.8 - delegate to parent class loader an load javax.annotation from there (no matter, if you have an bundle provided for that package) Java 11 - cannot find javax.annotation over boot-delegation, go on with Import-Package or Require-Bundle Either provide a org.osgi.framework.bootdelegation=javax.* as property to activate boot-delegation or you can use the existing profiles instead. The Profiles are defined in Equinox: https://github.com/eclipse/rt.equinox.framework/blob/master/bundles/org.eclipse.osgi/JavaSE-1.8.profile You can find the property: org.osgi.framework.bootdelegation there with a definition for javax.* To make Equinox use this profile (I dont know, if this happens by default) via launcher, you should provide the osgi.java.profile=file://JavaSE-1.8.profile If you take the profile, then you have to additionally provide the property: osgi.java.profile.bootdelegation=override, so that Equinox takes the profile boot delegation entries. instead of already defined ones With the correct boot-delegation configuration, always that same class loader will be taken for this constellation, no matter, if in Java 1.8 or 11. The same applies to JAXB problems. https://wiki.eclipse.org/Equinox_Boot_Delegation Regards, Mark Am 21.08.20 um 22:43 schrieb Brian de Alwis: Unfortunately javax.annotation /package-uses/ issues have returned <https://bugs.eclipse.org/bugs/show_bug.cgi?id=566085> :( The effort to replace the no-longer maintained Spotify Docker <https://bugs.eclipse.org/bugs/show_bug.cgi?id=558284>Client <https://bugs.eclipse.org/bugs/show_bug.cgi?id=558284> (bug 558284) <https://bugs.eclipse.org/bugs/show_bug.cgi?id=558284> introduced a new version of the javax.annotation bundle into Orbit <https://git.eclipse.org/r/c/orbit/orbit-recipes/+/161789> based on Jakarta EE’s somewhat recently released javax.annotation bundle with version 1.3.5 <https://search.maven.org/artifact/jakarta.annotation/jakarta.annotation-api/1.3.5/jar>. This bundle doesn’t use the same approach used for the javax.annotation 1.2.0 bundle <https://bugs.eclipse.org/bugs/show_bug.cgi?id=462686#c27> to use import-what-you-export /and/ requiring system.bundle. The issue only occurs on Java 8 and has been seen in the wild <https://github.com/GoogleCloudPlatform/google-cloud-eclipse/issues/3623>. I suspect it has not been more widespread due to increased adoption of Java 11. I’ve pushed up a fix to the javax.annotation 1.3.5 bundle <https://git.eclipse.org/r/c/orbit/orbit-recipes/+/167718>. I think the risk is small, but given that we’re in RC season, it would be good to get some more eyes on this. If you have concerns, please comment on Bug 566085 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=566085>. Brian. ___ equinox-dev mailing list equinox-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev -- Mark Hoffmann E-Mail: mark.hoffm...@web.de ___ equinox-dev mailing list equinox-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] JAXB with Java 11 in OSGi
Hi,
the point is, that with Java11 API and implementation/s are separated.
But the API JAXBContext loads the implementation.
In OSGi this would mean, that the JAXB-API has to know the
implementation. This is not the case. As default, JAXB tries to load
from jaxb.properties in the package of your entities, or a system
property, or in OSGi using HK2 which tracks the Java ServiceLoader
information or the default implementation:
com.sun.xml.bind.v2.ContextFactory using the context class loader. This
will all fail, unless you provide a class-loader that knows the
implementation, best using import package.
Thats why the most approaches using exactly that, by importing the
either com.sun.xml.bind.v2 or for Moxy org.eclipse.persistence.jaxb.
Then you can create you JAXBContext like this:
JAXBContext.newInstance(Bookstore.class.getPackageName(),
Bookstore.class.getClassLoader())
If you dont like that approach, you are best putting your jaxb
implementation and api on the classpath the framework is started with.
Using bndtools this is very easy using the runpath instruction:
-runpath: \
jakarta.activation-api;version='[1.2.2,1.2.3)',\
jakarta.xml.bind-api;version='[2.3.3,2.3.4)',\
org.eclipse.persistence.core;version='[2.7.6,2.7.7)',\
org.eclipse.persistence.moxy;version='[2.7.6,2.7.7)'
...
-runfw:
org.eclipse.osgi;version='[3.13.100.v20180827-1536,3.13.100.v20180827-1536]'
-runee: JavaSE-11
-runvm:
-Djavax.xml.bind.JAXBContextFactory=org.eclipse.persistence.jaxb.JAXBContextFactory
You are then fine with import-package declarations without
implementation details for the entities bundles as well as for the
bundle that creates the JAXBContext:
Import-Package
javax.xml.bind {version=[2.3,3)}
javax.xml.bind.annotation {version=[2.3,3)}
javax.xml.bind.annotation.adapters {version=[2.3,3)}
In that case you can create you JAXBContext like this:
JAXBContext jc = JAXBContext.newInstance(Bookstore.class);
But I dont know how to put additional jars to the framework class path
when using the Equinox Launcher, like the RCP does.
There is a section for implicit dependencies in the target platform
editor, that seems not to save anything. Playing around with the
osgi.frameworkClassPath laucher property didn't succeed. Maybe you have
additionally define the packages via
org.osgi.framework.system.packages.extra.
Regards,
Mark
At some point you will reach
Am 01.08.20 um 14:53 schrieb Lars Vogel:
Thanks, Mark
Mark Hoffmann mailto:mark.hoffm...@web.de>>
schrieb am Fr., 31. Juli 2020, 20:49:
Hi Lars,
I will take a look into it over the weekend.
Regards,
Mark
Ursprüngliche Nachricht
Von: Lars Vogel mailto:lars.vo...@vogella.com>>
Datum: 31.07.20 13:49 (GMT+01:00)
An: Equinox development mailing list mailto:equinox-dev@eclipse.org>>
Betreff: Re: [equinox-dev] JAXB with Java 11 in OSGi
Hi Neil, Dmytro and Mark,
I tried this but I'm still getting the ClassNotFound Exception.
I uploaded a tiny example here:
https://github.com/vogellacompany/eclipsercp-jaxb-java11
In case you want to test, clone the repo, import the example into
Eclipse and activate the jaxbtarget.target definition and start the
application via the com.vogella.jaxb.product.
Press the button called "Trigger JAXB"
Results in ClassNotFoundException
Caused by: java.lang.ClassNotFoundException:
org.eclipse.persistence.jaxb.JAXBContextFactory at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:602)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) at
org.eclipse.osgi.internal.framework.ContextFinder.loadClass(ContextFinder.java:147)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) at
javax.xml.bind.ContextFinder.safeLoadClass(ContextFinder.java:480) at
javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:184) … 29
more
Best regards, Lars
On Tue, Jul 28, 2020 at 3:07 PM Neil Bartlett
mailto:njbartl...@gmail.com>> wrote:
>
> Hi Lars,
>
> Dmytro is correct, the jaxb-api and javax.activation bundles are
required to provide the JAXB API on Java 11. You will also need an
implementation of the API... the org.eclipse.persistence.core and
org.eclipse.persistence.moxy bundles from EclipseLink provide this.
>
> I have had JAXB working with RCP for some time on J11 but
unfortunately cannot share the code because it is commercial.
>
> Neil
>
> On Tue, 28 Jul 2020 at 14:03, Dmytro Pishchukhin
mailto:dmytro.pishchuk...@gmail.com>> wrote:
>>
>> Hi
Re: [equinox-dev] JAXB with Java 11 in OSGi
Or you provide the class loader as parameter, when you create the JaxbContext.
Mark
Ursprüngliche Nachricht Von: Tom Schindl
Datum: 31.07.20 21:28 (GMT+01:00) An:
equinox-dev@eclipse.org Betreff: Re: [equinox-dev] JAXB with Java 11 in OSGi
IIRC you need to set the thread-context-classloader!Try
that:---8<---ClassLoader cl =
Thread.currentThread().getContextClassLoader();try { ClassLoader tmp =
Bookstore.class.getClassLoader()
Thread.currentThread().setContextClassLoader(tmp); context =
JAXBContext.newInstance(Bookstore.class); Marshaller m =
context.createMarshaller(); ...} finally {
Thread.currentThread().setContextClassLoader(cl);}---8<---TomAm 31.07.20 um
13:49 schrieb Lars Vogel:> Hi Neil, Dmytro and Mark,> > I tried this but I'm
still getting the ClassNotFound Exception.> > I uploaded a tiny example here:>
https://github.com/vogellacompany/eclipsercp-jaxb-java11> > In case you want to
test, clone the repo, import the example into> Eclipse and activate the
jaxbtarget.target definition and start the> application via the
com.vogella.jaxb.product.> > Press the button called "Trigger JAXB"> > Results
in ClassNotFoundException> > Caused by: java.lang.ClassNotFoundException:>
org.eclipse.persistence.jaxb.JAXBContextFactory at>
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:602)>
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)>
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) at>
org.eclipse.osgi.internal.framework.ContextFinder.loadClass(ContextFinder.java:147)>
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) at>
javax.xml.bind.ContextFinder.safeLoadClass(ContextFinder.java:480) at>
javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:184) … 29> more> >
Best regards, Lars> > On Tue, Jul 28, 2020 at 3:07 PM Neil Bartlett
wrote:>>>> Hi Lars,>>>> Dmytro is correct, the jaxb-api
and javax.activation bundles are required to provide the JAXB API on Java 11.
You will also need an implementation of the API... the
org.eclipse.persistence.core and org.eclipse.persistence.moxy bundles from
EclipseLink provide this.>>>> I have had JAXB working with RCP for some time on
J11 but unfortunately cannot share the code because it is commercial.>>>>
Neil>>>> On Tue, 28 Jul 2020 at 14:03, Dmytro Pishchukhin
wrote:>>>>>> Hi Lars,>>>>>> Try to use 2 bundles
to resolve JAXB packages:>>> - jaxb-api (javax.xml.bind:jaxb-api:2.3.1)>>> -
javax.activation (com.sun.activation:javax.activation:1.2.0)>>>>>> On Tue, Jul
28, 2020 at 1:56 PM Lars Vogel wrote:>>>>>>>> Friends
of OSGi,>>>>>>>> Is anyone aware of an example / description of how to use JAXB
with>>>> Java 11 in OSGI (Eclipse RCP)? If yes, please share it with
me.>>>>>>>> The examples I found for Java 11 are not inside OSGi and fail for
me.>>>>>>>> Best regards, Lars>>>>>>>>>>>>>>>> -->>>> Eclipse Platform project
co-lead>>>> CEO vogella GmbH>>>>>>>> Haindaalwisch 17a, 22395 Hamburg>>>>
Amtsgericht Hamburg: HRB 127058>>>> Geschäftsführer: Lars Vogel, Jennifer
Nerlich de Vogel>>>> USt-IdNr.: DE284122352>>>> Fax (040) 5247 6322, Email:
lars.vo...@vogella.com, Web: http://www.vogella.com>>>>
___>>>> equinox-dev mailing
list>>>> equinox-dev@eclipse.org>>>> To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/equinox-dev>>>>>>>>>>>> -->>> Best
regards,>>> Dmytro Pishchukhin>>>
___>>> equinox-dev mailing list>>>
equinox-dev@eclipse.org>>> To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/equinox-dev>>>>
___>> equinox-dev mailing list>>
equinox-dev@eclipse.org>> To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/equinox-dev> > > > >
___> equinox-dev mailing list>
equinox-dev@eclipse.org> To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/equinox-dev>
___equinox-dev mailing
listequinox-dev@eclipse.orgTo unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/equinox-dev___
equinox-dev mailing list
equinox-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] JAXB with Java 11 in OSGi
Hi Lars, I will take a look into it over the weekend. Regards, Mark Ursprüngliche Nachricht Von: Lars Vogel Datum: 31.07.20 13:49 (GMT+01:00) An: Equinox development mailing list Betreff: Re: [equinox-dev] JAXB with Java 11 in OSGi Hi Neil, Dmytro and Mark,I tried this but I'm still getting the ClassNotFound Exception.I uploaded a tiny example here:https://github.com/vogellacompany/eclipsercp-jaxb-java11In case you want to test, clone the repo, import the example intoEclipse and activate the jaxbtarget.target definition and start theapplication via the com.vogella.jaxb.product.Press the button called "Trigger JAXB"Results in ClassNotFoundExceptionCaused by: java.lang.ClassNotFoundException:org.eclipse.persistence.jaxb.JAXBContextFactory atjava.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:602)at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) atorg.eclipse.osgi.internal.framework.ContextFinder.loadClass(ContextFinder.java:147)at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) atjavax.xml.bind.ContextFinder.safeLoadClass(ContextFinder.java:480) atjavax.xml.bind.ContextFinder.newInstance(ContextFinder.java:184) … 29moreBest regards, LarsOn Tue, Jul 28, 2020 at 3:07 PM Neil Bartlett wrote:>> Hi Lars,>> Dmytro is correct, the jaxb-api and javax.activation bundles are required to provide the JAXB API on Java 11. You will also need an implementation of the API... the org.eclipse.persistence.core and org.eclipse.persistence.moxy bundles from EclipseLink provide this.>> I have had JAXB working with RCP for some time on J11 but unfortunately cannot share the code because it is commercial.>> Neil>> On Tue, 28 Jul 2020 at 14:03, Dmytro Pishchukhin wrote:>>>> Hi Lars,>>>> Try to use 2 bundles to resolve JAXB packages:>> - jaxb-api (javax.xml.bind:jaxb-api:2.3.1)>> - javax.activation (com.sun.activation:javax.activation:1.2.0)>>>> On Tue, Jul 28, 2020 at 1:56 PM Lars Vogel wrote:>>>>>> Friends of OSGi,>>>>>> Is anyone aware of an example / description of how to use JAXB with>>> Java 11 in OSGI (Eclipse RCP)? If yes, please share it with me.>>>>>> The examples I found for Java 11 are not inside OSGi and fail for me.>>>>>> Best regards, Lars>>>>>>>>>>>> -->>> Eclipse Platform project co-lead>>> CEO vogella GmbH>>>>>> Haindaalwisch 17a, 22395 Hamburg>>> Amtsgericht Hamburg: HRB 127058>>> Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel>>> USt-IdNr.: DE284122352>>> Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web: http://www.vogella.com>>> ___>>> equinox-dev mailing list>>> equinox-dev@eclipse.org>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev>>>>>>>> -->> Best regards,>> Dmytro Pishchukhin>> ___>> equinox-dev mailing list>> equinox-dev@eclipse.org>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev>> ___> equinox-dev mailing list> equinox-dev@eclipse.org> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev-- Eclipse Platform project co-leadCEO vogella GmbHHaindaalwisch 17a, 22395 HamburgAmtsgericht Hamburg: HRB 127058Geschäftsführer: Lars Vogel, Jennifer Nerlich de VogelUSt-IdNr.: DE284122352Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web: http://www.vogella.comOn Tue, Jul 28, 2020 at 9:11 PM Mark Hoffmann wrote:>> Hi Lars,>> For EclipseLink you should also place a jaxb.properties file in the package where the entites are located or otherwise/better use the>> -Djavax.xml.bind.JAXBContextFactory=org.eclipse.persistence.jaxb.JAXBContextFactory>> System Property>> Am 28.07.20 um 15:07 schrieb Neil Bartlett:>> Hi Lars,>> Dmytro is correct, the jaxb-api and javax.activation bundles are required to provide the JAXB API on Java 11. You will also need an implementation of the API... the org.eclipse.persistence.core and org.eclipse.persistence.moxy bundles from EclipseLink provide this.>> I have had JAXB working with RCP for some time on J11 but unfortunately cannot share the code because it is commercial.>> Neil>> On Tue, 28 Jul 2020 at 14:03, Dmytro Pishchukhin wrote:>>>> Hi Lars,>>>> Try to use 2 bundles to resolve JAXB packages:>> -
Re: [equinox-dev] JAXB with Java 11 in OSGi
Hi Lars, For EclipseLink you should also place a jaxb.properties file in the package where the entites are located or otherwise/better use the -Djavax.xml.bind.JAXBContextFactory=org.eclipse.persistence.jaxb.JAXBContextFactory System Property Am 28.07.20 um 15:07 schrieb Neil Bartlett: Hi Lars, Dmytro is correct, the jaxb-api and javax.activation bundles are required to provide the JAXB API on Java 11. You will also need an implementation of the API... the org.eclipse.persistence.core and org.eclipse.persistence.moxy bundles from EclipseLink provide this. I have had JAXB working with RCP for some time on J11 but unfortunately cannot share the code because it is commercial. Neil On Tue, 28 Jul 2020 at 14:03, Dmytro Pishchukhin mailto:dmytro.pishchuk...@gmail.com>> wrote: Hi Lars, Try to use 2 bundles to resolve JAXB packages: - jaxb-api (javax.xml.bind:jaxb-api:2.3.1) - javax.activation (com.sun.activation:javax.activation:1.2.0) On Tue, Jul 28, 2020 at 1:56 PM Lars Vogel mailto:lars.vo...@vogella.com>> wrote: Friends of OSGi, Is anyone aware of an example / description of how to use JAXB with Java 11 in OSGI (Eclipse RCP)? If yes, please share it with me. The examples I found for Java 11 are not inside OSGi and fail for me. Best regards, Lars -- Eclipse Platform project co-lead CEO vogella GmbH Haindaalwisch 17a, 22395 Hamburg Amtsgericht Hamburg: HRB 127058 Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel USt-IdNr.: DE284122352 Fax (040) 5247 6322, Email: lars.vo...@vogella.com <mailto:lars.vo...@vogella.com>, Web: http://www.vogella.com ___ equinox-dev mailing list equinox-dev@eclipse.org <mailto:equinox-dev@eclipse.org> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev -- Best regards, Dmytro Pishchukhin ___ equinox-dev mailing list equinox-dev@eclipse.org <mailto:equinox-dev@eclipse.org> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev -- Mark Hoffmann E-Mail: mark.hoffm...@web.de ___ equinox-dev mailing list equinox-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Accessing files of a feature project during runtime
Hi Simon,
Features or no bundles. they are no part of the OSGi specification and
only related to Eclipse. Features can be seen as an meta-aggregation of
bundle into a functionality description. It is more to ease the humans
mind, when handling with large numbers of bundles and get them
"categorized".
The OSGi there are subsystems, that are doing similar thing and even
more, like isolation of visibility.
With features you can use the root files stuff [1] to copy files nearly
wherever you like. Take notice that the stuff is bundled for deployment
time. P2 uses the instructions to copy files.
But from my point of view, you should include your files into a bundle
or a bundle-fragment. Especially during runtime it is the recommended
way, because bundles are resolved by any OSGi resolver. Eclipse Features
are not resolved during runtime from equinox. You have to use P2 for
that, but even then, features are no real part of your runtime.
I hope it helps.
Regards,
Mark
[1]
https://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Freference%2Fpde_feature_generating_build.htm
Am 20.04.2018 um 11:43 schrieb Simon Scholz:
Hi guys,
is there a way to access files from features?
With bundles it works pretty straight forward:
Bundle bundle = Platform.getBundle("myBundlesSymbolicName");
or
Bundle bundle = FrameworkUtil.getBundle(getClass());
and then using the FileLocator to get resources inside the bundle.
Unfortunately there is nothing like:
Feature feature = Platform.getFeature("myFeatureId"); + a way to get
files from this feature JAR.
Can someone tell me how to do that in the right way?
Thanks in Advance,
Simon Scholz
___
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 start problem
Hi, you have to add: - org.eclipse.equinox.console, - org.apache.felix.gogo.command - org.apache.felix.gogo.shell - org.apache.felix.gogo.runtime to your launch configuration. Maybe you dont need gogo.command. Regards, Mark Am 21.12.2017 um 09:34 schrieb Wang, Julian: Hi, I am studying equinox and want to start the osgi container. With the command suggested by the document http://www.eclipse.org/equinox/documents/quickstart-framework.php I can’t see the prompt osgi> prompt I have tried os windows, linux, org.eclipse.osgi_3.2.0.jar 3.2.0, 3.12.50, 3.8.2. My java version is 1.8.0_151 java -jar org.eclipse.osgi_3.2.0.jar -console What’s the reason? What should I do? Yanqiu Wang IoT Solution Architect, Connected Enterprise China yanqiu.w...@honeywell.com <mailto:yanqiu.w...@honeywell.com> 18701820967, 021-28944230 logo ___ 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] Question to: java.lang.ClassCircularityError: org/eclipse/equinox/internal/app/CommandLineArgs
Hi all, last week I experienced the error above. The problem was that this ClassCircularityError not appears at build time. This error comes from equinox.ds, I think when it tries to resolute all DS dependencies. Now I know how to solve this error. It was a mistake in my service component definition, where I have defined a service consumer from a non DS service as static 1..1. I changed it to dynamic 0..1 and everything is fine now. My question is, is there any functionality to check the DS dependency resolution, programmatic or via ant task? I would trigger such a check at build time, to avoid a misconfiguration of service component definitions. Another posibility is to integrate such a check into the launch configuration of the PDE to avoid the mistakes I made. Regards, Mark -- Geckoware Consulting and Development Inhaber: Mark Hoffmann M.A. Dipl.-Betriebswirt (FH) Kurt-Keicher-Straße 93 07545 Gera Germany Web:http://www.geckoware.de E-Mail: mhoffm...@geckoware.de XING: https://www.xing.com/profile/Mark_Hoffmann6 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Mark Rogalski is out of the office.
I will be out of the office starting 07/02/2010 and will not return until 07/12/2010. I will be returning on July 12th___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Committer vote for Scott Lewis has been approved by the PMC
rt.equinox.incubator Committers, This automatically generated message marks the PMC's approval of the vote for Scott Lewis's full Committer status on the rt.equinox.incubator project. The next step is for the project lead to return to the portal and fill in the CVS package and employer information for Scott Lewis. The PMC's comments were: Looks like a good contribution history and a good showing of plus ones from the team. I approve the vote. If you have any questions, please do not hesitate to contact your project lead, PMC member, or the EMO ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
RE: [equinox-dev] Using LIRc library in Equinox
Hi, just an idea. Maybe jlirc works with JNI? Maybe you have to give the library path to the VM similar to subclipse? Like: -vmargs -Djava.library.path=path_to_lirc_libs Mark "David Conde" schrieb am 14.08.2009 14:23:22: > > The problem can be because OSGI does not recognize the LIRC daemon, > because I have tried to introduce all the classes from LIRC packages > in my bundle and I have the same result. I do not know if I have to > do something special to relate the OSGI framework with the LIRC > daemon in Ubuntu, or include some libraries. I do not know much about > LIRC but I think that is a daemon which takes data from remote > control and then send this information to a socket, so I think my > bundle just should interact with a socket, but there > are an API to use LIRC in Java called JLIRC which I think should be > enough. > > Any idea will help me. > > Thanks > > De:equinox-dev-boun...@eclipse.org [mailto:equinox-dev-bounces@ > eclipse.org] *En nombre de *David Conde > *Enviado el:* viernes, 14 de agosto de 2009 11:50 > *Para:* 'Equinox development mailing list' > *Asunto:* [equinox-dev] Using LIRc library in Equinox > > Hi, > > I am trying to use LIRC libraries in order to use remote controls in > my bundles running on Equinox. > > For this task, I download de JLIRC source and put it all together in > a new bundle called RemoteLIRC, then I exported the next packages: > > -org.lirc > > -org.lirc.socket > > -org.lirc.ui > > -org.lirc.utils > > Then I imported these packages in another bundle called Remote > Manager which use some of the classes defined in these packages. > > I did not get any error in compilation time with Eclipse but when I > tried to launch Remote Manager by console I got a java.lang. > NoClassDefFoundError: Could not initialize class org.lirc.socket. > UnixSocketImpl > > I do not know If I am putting right the LIRC packages or is it a > problem from sockets? > > Any Idea? > > Thank you in advance > ___ equinox-dev mailing > list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/ > > equinox-dev -- Mark Hoffmann e-Mail: mark.hoffm...@web.de __ GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT! Jetzt freischalten unter http://movieflat.web.de ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
RE: [equinox-dev] Getting info for dynamic imports through the console
Is diag just reporting about optionally imported packages? Isn't that the only way it could know which packages are potentially dynamically imported? "Kirchev, Lazar" Sent by: equinox-dev-boun...@eclipse.org 07/08/2009 09:00 AM Please respond to Equinox development mailing list To "Equinox development mailing list" cc Subject RE: [equinox-dev] Getting info for dynamic imports through the console Thanks, Then I will open a bug for the diag, and an enhancement request for providing info for the dynamically imported packages. I will try to provide patches shortly. Lazar From: equinox-dev-boun...@eclipse.org [ mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Thomas Watson Sent: Wednesday, July 08, 2009 4:53 PM To: Equinox development mailing list Subject: RE: [equinox-dev] Getting info for dynamic imports through the console The diag command appears to have a bug then. I do not expect that behavior. There currently is no way to get information about dynamically imported packages from the console. You should open a bug and contributions are welcome ;-) Tom "Kirchev, Lazar" ---07/08/2009 08:38:37 AM---But then why if the bundle imports dynamically packages, which are not provided by any other bundle, the diag command returns t From: "Kirchev, Lazar" To: "Equinox development mailing list" Date: 07/08/2009 08:38 AM Subject: RE: [equinox-dev] Getting info for dynamic imports through the console But then why if the bundle imports dynamically packages, which are not provided by any other bundle, the diag command returns that the dynamically imported packages are missing? This really does not affect the resolving of the bundle and it gets resolved correctly, but still are returned by diag. When a bundle providing these packages is installed and activated, diag stops returning the dynamically imported packages as missing. But my question was more about how I can check through the console what packages a bundle imports dynamically? Lazar From: equinox-dev-boun...@eclipse.org [ mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Thomas Watson Sent: Wednesday, July 08, 2009 4:22 PM To: Equinox development mailing list Subject: Re: [equinox-dev] Getting info for dynamic imports through the console The diag command only shows info on why a bundle could not resolve. Dynamic imports never prevent a bundle from resolving. Dynamic import wires are created (well) dynamically, the bundle command only shows imports for statically imported packages. Tom "Kirchev, Lazar" ---07/08/2009 06:48:41 AM---Hello, From: "Kirchev, Lazar" To: "Equinox development mailing list" Date: 07/08/2009 06:48 AM Subject: [equinox-dev] Getting info for dynamic imports through the console Hello, I have the following question regarding dynamic imports info. The bundle console command does not return the dynamic imports of a bundle, and in the same time the diag command states that there are no unresolved imports for this bundle. So is this the intended behavior of the bundle command? Is it possible to get info through a console command which packages are dynamically imported by the bundle? Kind regards, Lazar Kirchev___ 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] Problem with security in Equinox
Hi,
I run equinox with my own policy, that looks like this:
grant codeBase
"file:/path_to_launcher_bundle/org.eclipse.equinox.launcher_1.0.100.v20080509-1800.jar"
{
permission java.util.PropertyPermission "*", "read, write";
permission java.io.FilePermission "<>", "read, write, delete";
permission java.lang.RuntimePermission "*";
permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
permission org.osgi.framework.ServicePermission "*","register,get";
permission org.osgi.framework.AdminPermission;
permission java.net.NetPermission "specifyStreamHandler";
permission org.osgi.service.application.ApplicationAdminPermission "*",
"lifecycle";
permission org.osgi.framework.PackagePermission "*","export,import";
permission org.osgi.framework.BundlePermission "*","provide,require";
permission javax.security.auth.AuthPermission "modifyPrincipals";
permission javax.security.auth.AuthPermission "createLoginContext.TEST";
permission javax.security.auth.AuthPermission "doAsPrivileged";
permission javax.security.auth.AuthPermission "setLoginConfiguration";
permission javax.security.auth.AuthPermission "doAs";
permission javax.security.auth.AuthPermission "getSubject";
permission java.security.SecurityPermission "getPolicy";
permission java.security.SecurityPermission "setPolicy";
};
grant codeBase "file:/path_to/workspace" {
permission java.io.FilePermission "<>", "read, write, delete";
permission java.util.PropertyPermission "*", "read, write";
permission java.lang.RuntimePermission "*";
permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
permission org.osgi.framework.ServicePermission "*","register,get";
permission org.osgi.framework.AdminPermission;
permission java.net.NetPermission "specifyStreamHandler";
permission org.osgi.service.application.ApplicationAdminPermission "*",
"lifecycle";
permission org.osgi.framework.PackagePermission "*","export,import";
permission org.osgi.framework.BundlePermission "*","provide,require";
permission javax.security.auth.AuthPermission "modifyPrincipals";
permission javax.security.auth.AuthPermission "createLoginContext.TEST";
permission javax.security.auth.AuthPermission "doAsPrivileged";
permission javax.security.auth.AuthPermission "setLoginConfiguration";
permission javax.security.auth.AuthPermission "doAs";
permission javax.security.auth.AuthPermission "getSubject";
};
As VM lauch arguments I gave:
-Djava.security.policy=${workspace_loc}/PluginName/data/test.policy
-Djava.security.manager
-Declipse.security=org.eclipse.osgi.framework.internal.core.FrameworkSecurityManager
What I further needed was the permissions.perm file in the OSGI-INF folder,
that contains the same information like the section for the launcher in the
policy file:
(java.io.FilePermission "<>" "read,write,delete")
(java.util.PropertyPermission "*" "read, write")
(java.lang.RuntimePermission "*")
(java.lang.reflect.ReflectPermission "suppressAccessChecks")
(org.osgi.framework.ServicePermission "*" "register,get")
(org.osgi.framework.AdminPermission)
(java.net.NetPermission "specifyStreamHandler")
(org.osgi.service.application.ApplicationAdminPermission "*" "lifecycle")
(org.osgi.framework.PackagePermission "*" "export,import")
(org.osgi.framework.BundlePermission "*" "provide,require")
(javax.security.auth.AuthPermission "modifyPrincipals")
(javax.security.auth.AuthPermission "createLoginContext.TEST")
(javax.security.auth.AuthPermission "doAsPrivileged")
(javax.security.auth.AuthPermission "setLoginConfiguration")
(javax.security.auth.AuthPermission "doAs")
(javax.security.auth.AuthPermission "getSubject")
(java.security.SecurityPermission "getPolicy")
(java.security.SecurityPermission "setPolicy")
Regards,
Mark
"David Conde" schrieb am 27.04.2009 09:32:16:
>
> I got a solution for my problem, if I modify the common policy file
> in JVM directory, instead of changing in my policy file (into my
> program directory), and there I write:
>
> grant {
> permission java.security.AllPermission;
> };
>
> then If I launch Equinox with security parameters I do not get any
> exception at all.
Re: [equinox-dev] Adding Equinox Declarative Services (DS) to the Eclipse SDK
+1 -- Dipl.-Betriebswirt (FH) Mark Hoffmann Schrödingerstraße 90 07745 Jena e-Mail: mark.hoffm...@software-in-motion.de Pt! Schon vom neuen WEB.DE MultiMessenger gehört? Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Mark Rogalski is out of the office.
I will be out of the office starting 11/19/2008 and will not return until 12/01/2008. I will respond to your message when I return.___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Fw: [equinox-dev] Extension registry evolution
My comment was meant generically. But annotations is an example of something not supported on CDC VMs. - Forwarded by Mark Rogalski/Austin/IBM on 09/26/2008 01:49 PM - "Boris Bokowski" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/26/2008 01:10 PM Please respond to Equinox development mailing list To "Equinox development mailing list" cc Subject Re: [equinox-dev] Extension registry evolution On Fri, Sep 26, 2008 at 11:32 AM, Mark Rogalski <[EMAIL PROTECTED]> wrote: > > Not to throw a fly in the ointment, but some of the designs being discussed > would not work on CDC/Foundation 1.1. Mark, what are you referring to? Being able to use annotations in client code, for use with dependency injection frameworks like Guice, or were you making a more general comment? I agree that the platform itself should continue to target CDC Foundation 1.1, but at the same time, we should make it possible for clients to exploit the functionality available in later VMs. Boris ___ 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] Extension registry evolution
Not to throw a fly in the ointment, but some of the designs being
discussed would not work on CDC/Foundation 1.1. With Eclipse based
solutions being deployed on more and more mobile devices, I think this
should be an important consideration. If we introduce non-Foundation
compatible, we'd probably have to split Eclipse into Desktop and Mobile
versions and apps would no longer be binary compatible between them. Of
course it is always a difficult choice of sticking with compatibility vs.
taking advantage of new innovations.
"Boris Bokowski" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
09/26/2008 10:01 AM
Please respond to
Equinox development mailing list
To
"Equinox development mailing list"
cc
Subject
Re: [equinox-dev] Extension registry evolution
On Wed, Sep 24, 2008 at 3:19 PM, Oleg Besedin <[EMAIL PROTECTED]> wrote:
>
> What would you like to see in the extension registry 2010?
I just looked at
http://wiki.eclipse.org/Equinox_Extension_Registry_Work_Objects. I
like that you plan to use constructor and setter injection, this has a
lot of potential for simplifying things, but I would like to see a
more flexible approach.
Here are my comments:
(1) I don't like that clients cannot provide more than just one single
"context" object. For example, when contributing to the UI, there are
a whole lot of services that views or editors need from their context.
The Workbench provides these services, but with the API you propose
there is no way to have these directly injected into the provided
object, as in (for example):
public class SomeContributedView {
public SomeContributedView(ISelectionService ss, IProgressService ps,
IWorkbenchHelpSystem hs) {
...
}
(2) IRegistryObject is odd - can you not split this into two
interfaces that we would recommend are being used whenever objects
need to be initialized, or disposed? How about:
package org.eclipse.equinox.common;
public interface IDisposable {
public void dispose();
}
public interface IInitializee { // someone please propose a better name
public void init();
}
Note that I already see three interfaces "IDisposable" in my workspace
(one in ECF, one in EMF, and one in Platform UI), and I suspect they
all could extend this common one.
Another possibility, since you are using reflection anyway, is to not
require clients to implement interfaces like this but rather call
their init() and dispose() methods should they exist.
(3) What about existing dependency injection frameworks? How does your
proposal relate to them? Some dependency injection frameworks use Java
annotations to specify defaults (Guice being one example). Wouldn't it
be good if clients could specify which dependency injection mechanism
they would like to be used? I am thinking of something in the
plugin.xml by which they could specify how the dependency injection
should be done.
(4) What about other languages, for example JPython, JRuby,
Javascript, Groovy etc. - all of these can run on the JVM. Actually,
enabling (3) would help with this - if clients can specify a
dependency injection mechanism, that mechanism could be one targeted
at creating objects implemented in those other languages.
Boris
___
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] Installing a bundle from console does not make it available to the workspace?
Alex, Yep I can't write a bundle that depends on it. So I'll try the refresh option. Have a great day all. 2008/5/7 Alex Blewitt <[EMAIL PROTECTED]>: > 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/> > 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 > > ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Installing a bundle from console does not make it available to the workspace?
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] Sprint releases OSGi based Next Gen Mobile Java Platform
RCP developers, I'd like to inform you that Sprint has made publicly available their "Titan" platform based on OSGi and Eclipse eRCP. This platform for Windows Mobile devices brings the power of OSGi and Eclipse to mobile phones in a big way. You can run eRCP applications and may even be inclined to port your existing Eclipse apps to eRCP so you can always have them with you. The reference platform for Titan is a Sprint Mogul device, but I think any WM6 Classic or Professional device should do pretty well. Go to http://developer.sprint.com/site/global/develop/technologies/sprint_titan/p_sprint_titan.jsp to download the runtime and tools and learn more about Titan. There will also be a session on this topic at EclipseCon 2008 (with some give-aways I hear). Mark___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Building against specific EEs
eRCP XML bundles, also known as "microXML" are in the Eclipse embedded
Rich Client Platform project (www.eclipse.org/ercp).
The two bundles provide full DOM Level 2, SAX 2.0 and JAXP 1.0 support in
about 100k. Part of the reason for the small size is that the parser is
non-validating.
You can check out the two projects from CVS or get pre-built bundles from
an eRCP runtime.
Mark
David M Williams/Raleigh/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
02/20/2008 05:19 PM
Please respond to
Equinox development mailing list
To
Equinox development mailing list
cc
Subject
Re: [equinox-dev] Building against specific EEs
> Please direct question or comments to this list.
Ok, I have a few ... I'm not familiar with the background, so I'm not sure
if I need to know or not. :)
> eRCP XML bundles
What are these?
Can the ones in Orbit work? Such as javax.xml_1.3.4
> Note that this will require people to have the XML APIs available in
their
> workspace if they are set up with exact match VMs.
What's exact match mean? You mean lower than 1.4 or Java 5 VMs?
> We will adjust the project set files to load
> Xerces or the bundles from eRCP, accordingly.
According to what? And, are you saying never from the VM?
From:
DJ Houghton <[EMAIL PROTECTED]>
To:
equinox-dev@eclipse.org
Date:
02/20/2008 05:30 PM
Subject:
[equinox-dev] Building against specific EEs
As mentioned in the Equinox call earlier this week, I am investigating the
EE situation with our bundles and how it relates to the build. Kim and I
discussed this today and we will move forward by:
- Kim ensuring that VMs for the appropriate profiles are available in the
build (in the process of aquiring Foundation 1.1)
- downloading the eRCP XML bundles and put them in a spot so PDE/Build
knows to take them into account when compiling
- running a test build with one of our "requires XML" bundles changed to
have the correct order for the EE
If everything is ok, then we will recommend that the order of EEs in the
bundle manifests be changed to reflect the true order.
Note that this will require people to have the XML APIs available in their
workspace if they are set up with exact match VMs. We will adjust the
project set files to load Xerces or the bundles from eRCP, accordingly.
Please direct question or comments to this list.
Thanks.
___
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] [prov] use of Foundation 1.1
MicroXML from eRCP is available. Not sure we want that dependency, but you can consider it. Mark Thomas Watson/Austin/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 02/19/2008 09:01 AM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] [prov] use of Foundation 1.1 The org.eclipse.equinox.registry also has J2SE 1.4 listed before Foundation 1.1. If I remember correctly, this is because we do not have a bundle at pde-build time that provides the XML api to bundles with BREE < J2SE 1.4. I think if you simply reorder the BREEs we will get a build failure for bundles needing XML stuff to compile. We would need an XML bundle to be available at build time also. Tom "Jeff McAffer" ---02/19/2008 07:57:02 AM---There are several projects in p2 currently that list J2SE 1.4 and Foundation 1.1 in the BREE for the bundle. This is good but t From: "Jeff McAffer" <[EMAIL PROTECTED]> To: "'Equinox development mailing list'" Date: 02/19/2008 07:57 AM Subject: [equinox-dev] [prov] use of Foundation 1.1 There are several projects in p2 currently that list J2SE 1.4 and Foundation 1.1 in the BREE for the bundle. This is good but they list them in that order. The net result is that J2SE 1.4 is used to compile the code. What happens in some cases people don’t have 1.4 so PDE uses the next best thing which ends up being 1.5 or 1.6. In the end we get references to things we ought not. In particular, I just had a setup in which there were no XML api in my workspace or target yet everything was compiling ok. Took quite some time to figure out how this could be so. If everyone agrees, I will go through the projects and update them accordingly. 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 <><><><><><><><><>___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] the importance of targetting Foundation JREs
Thanks, Jeff. I'm glad your keeping an eye on this as it is very
important for the eRCP project.
Mark
"Jeff McAffer" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
02/15/2008 03:20 PM
Please respond to
Equinox development mailing list
To
"'Equinox development mailing list'"
cc
Subject
[equinox-dev] the importance of targetting Foundation JREs
In the past couple days there have been at least three cases of code
problems that where either code from J2SE was being used or dependencies
were spec’d incorrectly because stuff was coming for free from the JRE. We
can avoid these simply by installing and configuring a Foundation 1.1 JRE.
See
http://wiki.eclipse.org/index.php/J9#Foundation_1.1
for details on how to do this. I would have thought that the builds would
pick this up but perhaps they do not have foundation JREs either. I’ll
open a bug for that.
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] Reference remote bundles when writing a new plugin.
Thanks once again. Regarding the pde list - seems even the forums are bundles ): Kind Regards Mark On 11/02/2008, Alex Blewitt <[EMAIL PROTECTED]> wrote: > > 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 > ___ 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.
Thanks Alex. Perhaps this is also a possible feature for the PDE team. On 11/02/2008, Alex Blewitt <[EMAIL PROTECTED]> wrote: > > 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 > ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Reference remote bundles when writing a new plugin.
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. Any ideas ? Regards Mark ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] is this a service tracker bug?
orkConsole.docommand( FrameworkConsole.java:291) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console( FrameworkConsole.java:276) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run( FrameworkConsole.java:218) at java.lang.Thread.run(Thread.java:595) On 25/01/2008, BJ Hargrave <[EMAIL PROTECTED]> wrote: > > That seems to be a bug in Equinox. You may wish to file a bug report. > > For giggles, try update 1 without stopping it first. The update operation > will automatically stop and restart the updated bundle. > > Note: in order for import and exporting the package to work here, the > exported package in A' must be backwards compatible with the exported > package in A. This is because the remaining code in A' will be > implementing/using the interface from A. > -- > > 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: > Mark <[EMAIL PROTECTED]> > To: > "Equinox development mailing list" > Date: > 2008-01-25 12:59 > Subject: > Re: [equinox-dev] is this a service tracker bug? > > > > Try adding: > > Import-Package: bundlea.service > > to the Bundle A manifest. > > = > I just tried the suggestion above - but it blows up? > > Framework is launched. > > idState Bundle > 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 > 1ACTIVE bundleA_1.0.0 > 2ACTIVE bundleB_1.0.0 > > osgi> stop 1 > removedService > > osgi> update 1 > > osgi> ss > > Framework is launched. > > idState Bundle > 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 > 1INSTALLED bundleA_1.0.0 > 2ACTIVE bundleB_1.0.0 > > osgi> start 1 > org.osgi.framework.BundleException: Exception in bundlea.Activator.start() > of bundle bundleA. > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator( > BundleContextImpl.java:1018) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.start( > BundleContextImpl.java:974) > at > org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( > BundleHost.java:346) > at > org.eclipse.osgi.framework.internal.core.AbstractBundle.start( > AbstractBundle.java:260) > at > org.eclipse.osgi.framework.internal.core.AbstractBundle.start( > AbstractBundle.java:252) > at > org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start( > FrameworkCommandProvider.java:260) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java > :39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > > org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute > (FrameworkCommandInterpreter.java:150) > at > org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand( > FrameworkConsole.java:291) > at > org.eclipse.osgi.framework.internal.core.FrameworkConsole.console( > FrameworkConsole.java:276) > at > org.eclipse.osgi.framework.internal.core.FrameworkConsole.run( > FrameworkConsole.java:218) > at java.lang.Thread.run(Thread.java:595) > Caused by: java.lang.IllegalStateException: The state indicates the bundle > is resolved > at > > org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage > (AbstractBundle.java:1376) > at > org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( > BundleHost.java:305) > at > org.eclipse.osgi.framework.internal.core.AbstractBundle.start( > AbstractBundle.java:260) > at > org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) > at > > org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass > (EclipseLazyStarter.java:111) > at > org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass( > ClasspathManager.java:417) > at > org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass( > DefaultClassLoader.java:189) > at > org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass( > BundleLoader.java:340) > at > org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass( > SingleSourcePackage.java:37) > at > org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal( > BundleLoader.jav
Re: [equinox-dev] is this a service tracker bug?
I see - It's in an IllegalState until you refresh On 25/01/2008, Mark <[EMAIL PROTECTED]> wrote: > > Try adding: > > Import-Package: bundlea.service > > to the Bundle A manifest. > > = > I just tried the suggestion above - but it blows up? > > Framework is launched. > > idState Bundle > 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 > 1ACTIVE bundleA_1.0.0 > 2ACTIVE bundleB_1.0.0 > > osgi> stop 1 > removedService > > osgi> update 1 > > osgi> ss > > Framework is launched. > > idState Bundle > 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 > 1INSTALLED bundleA_1.0.0 > 2ACTIVE bundleB_1.0.0 > > osgi> start 1 > org.osgi.framework.BundleException: Exception in bundlea.Activator.start() > of bundle bundleA. > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator( > BundleContextImpl.java:1018) > at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start( > BundleContextImpl.java:974) > at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( > BundleHost.java:346) > at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( > AbstractBundle.java:260) > at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( > AbstractBundle.java:252) > at > org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start( > FrameworkCommandProvider.java:260) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke( > NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute > (FrameworkCommandInterpreter.java:150) > at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand > (FrameworkConsole.java:291) > at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console( > FrameworkConsole.java:276) > at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run( > FrameworkConsole.java:218) > at java.lang.Thread.run(Thread.java:595) > Caused by: java.lang.IllegalStateException: The state indicates the bundle > is resolved > at > org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage > (AbstractBundle.java:1376) > at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( > BundleHost.java:305) > at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( > AbstractBundle.java:260) > at org.eclipse.osgi.framework.util.SecureAction.start( > SecureAction.java:400) > at > org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass > (EclipseLazyStarter.java:111) > at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass > (ClasspathManager.java:417) > at > org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass( > DefaultClassLoader.java:189) > at > org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass( > BundleLoader.java:340) > at > org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass( > SingleSourcePackage.java:37) > at > org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal( > BundleLoader.java:396) > at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass( > BundleLoader.java:369) > at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass( > BundleLoader.java:357) > at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass( > DefaultClassLoader.java:83) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at bundlea.Activator.start(Activator.java:12) > at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run( > BundleContextImpl.java:999) > at java.security.AccessController.doPrivileged(Native Method) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator( > BundleContextImpl.java:993) > ... 14 more > Nested Exception: > java.lang.IllegalStateException: The state indicates the bundle is > resolved > at > org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage > (AbstractBundle.java:1376) > at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( > BundleHost.java:305) > at org.eclipse.osgi.framework.internal.core
Re: [equinox-dev] is this a service tracker bug?
Try adding: Import-Package: bundlea.service to the Bundle A manifest. = I just tried the suggestion above - but it blows up? Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1ACTIVE bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi> stop 1 removedService osgi> update 1 osgi> ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1INSTALLED bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi> start 1 org.osgi.framework.BundleException: Exception in bundlea.Activator.start() of bundle bundleA. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator( BundleContextImpl.java:1018) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start( BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( AbstractBundle.java:260) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( AbstractBundle.java:252) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start( FrameworkCommandProvider.java:260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute (FrameworkCommandInterpreter.java:150) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand( FrameworkConsole.java:291) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console( FrameworkConsole.java:276) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run( FrameworkConsole.java:218) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage (AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java :400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass (EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass( ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass( DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass( BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass( SingleSourcePackage.java:37) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal( BundleLoader.java:396) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass( BundleLoader.java:369) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass( BundleLoader.java:357) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass( DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at bundlea.Activator.start(Activator.java:12) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run( BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator( BundleContextImpl.java:993) ... 14 more Nested Exception: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage (AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java :400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass (EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass( ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass( DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass( BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass( SingleSourcePackage.java:37) at org.eclipse.osgi.framework.
Re: [equinox-dev] is this a service tracker bug?
Thanks. So that's expected behaviour - and all makes sense. Regards Mark On 25/01/2008, Jeremy Volkman <[EMAIL PROTECTED]> wrote: > > Mark, > > Since your service interface (IA.java) is contained within bundleA, > bundleB requires a package import from bundleA. The effect that > you're seeing is that the old version of bundleA remains in the system > and is still used by bundleB after you call "update". Therefore you > now have two instances of bundleA in the system: the old one, still > used by bundleB, and the new refreshed one. > > Since you called 'refresh', the old bundleA was stopped, and so were > any registered services (which is why you see 'removedService'). The > new bundleA was also started, and a new IA service was registered. > However, since bundleB is still using the package import from the old > bundleA, it does not get notified of the new bundleA's service (refer > to ServiceListener vs. AllServiceListener). > > Calling 'refresh' instructs the framework to perform the steps > outlined at > http://www2.osgi.org/javadoc/r4/org/osgi/service/packageadmin/PackageAdmin.html#refreshPackages(org.osgi.framework.Bundle[]) > . > This in turn stops bundleB, gets rid of the old bundleA and links > bundleB to the new bundleA's package source. When bundleB is > restarted and linked to the new bundleA, it can once again see the IA > service. > > Sorry if that was a bit confusing.. maybe someone else can clarify a bit > more. > > -Jeremy > > On Jan 25, 2008 11:33 AM, Mark <[EMAIL PROTECTED]> wrote: > > > > This is driving me mad. I have two bundles A and B. B track the service > > offered by A. > > > > However if I call update on A then I get a remove Service notification > but > > no add Service notification - that is until I issue a refresh command ? > is > > this a bug? > > > > I have written the same simple code 10 time .. see the results. > > > > I have attached the two bundles and the two eclipse plugin projects (as > one > > zip) - just in case a Eclipse/OSGi guru like yourself can figure it out? > > > > > > > > C:\eg>java -jar equinox.osgi.jar -console > > > > osgi> ss > > > > Framework is launched. > > > > id State Bundle > > 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 > > > > osgi> install file:bundleA_1.0.0.jar > > Bundle id is 1 > > > > osgi> install file:bundleB_1.0.0.jar > > Bundle id is 2 > > > > osgi> ss > > > > Framework is launched. > > > > id State Bundle > > 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 > > 1 INSTALLED bundleA_1.0.0 > > 2 INSTALLED bundleB_1.0.0 > > > > osgi> start 1 > > > > osgi> start 2 > > addingService > > > > osgi> stop 1 > > removedService > > > > osgi> start 1 > > addingService > > > > osgi> update 1 > > removedService <- no add ! > > > > osgi> stop 2 > > > > osgi> start 2 > > > > osgi> refresh <- Only get add after refresh > > > > osgi> addingService > > > > > > osgi> > > > > > > > > On 25/01/2008, Neil Bartlett <[EMAIL PROTECTED] > wrote: > > > > > > > > > Hi Mark, > > > > > > > > > Many thanks for your kind words! > > > > > > > > > Regarding the service tracker problem... that's not the behaviour I > would > > expect to see, and I've just put together a small test case which prints > a > > message in the addingService, removedService and modifiedService methods > of > > the ServiceTracker. When I update the bundle that registered the > service, I > > see the following: > > > > > > > > > osgi> update 5 > > > Removed service > > > Added service > > > > > > osgi> > > > > > > > > > > > > Which seems to be the way it should work. I suggest posting a message > to > > the equinox-dev mailing list ( > > https://dev.eclipse.org/mailman/listinfo/equinox-dev) explaining the > problem > > in detail and including a minimal code sample that reproduces the > problem. > > > > > > > > > Regards, > > > Neil > > > > > > > > > > > > > > > > > > > > > > > > On 25 Jan 2008, at 13:42, Ma
Re: [equinox-dev] Launching with Foundation 1.1 VM
Tom, Thanks for handing out the info on eRCP. John, I'm afraid that you will probably find that SWT has some dependencies outside of Foundation 1.1. JFace certainly does. It may be possible for you to choose widgets that don't have dependencies, though. Things could get dicey doing this since unless you build SWT against Foundation 1.1 you won't know where the issues are. I suggest you try using eRCP as it is a project specifically developed to work on Foundation 1.0. Mark Thomas Watson/Austin/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 09/06/2007 12:19 PM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] Launching with Foundation 1.1 VM The eRCP project has a XML parser they use. I believe they install them as framework extensions. See http://www.eclipse.org/downloads/download.php?file=/dsdp/ercp/eRCP-v20070801.win32-x86.zip It includes two xml bundles (org.eclipse.ercp.xml and org.eclipse.ercp.xmlParserAPIs). These two bundles are configured as framework extensions with the following config.ini property in eRCP. osgi.framework.extensions=org.eclipse.ercp.xml, org.eclipse.ercp.xmlParserAPIs The reason they use them as framework extensions is so they can support plugin.xml parsing for compatibility and more importantly to take advantage of the framework code which registers the xml parsers as OSGi services. Tom John Arthorne ---09/06/2007 12:08:59 PM---Thanks Tom. Registry is not resolved because it requires a SAX parser. I tried org.apache.xerces from orbit, but it requires John Arthorne <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/06/2007 12:08 PM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] Launching with Foundation 1.1 VM Thanks Tom. Registry is not resolved because it requires a SAX parser. I tried org.apache.xerces from orbit, but it requires a 1.2 EE. Does anyone know of a SAX parser that will run in Foundation 1.1? Thomas Watson <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/06/2007 12:47 PM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] Launching with Foundation 1.1 VM Can you run with -noExit -console and see if the org.eclipse.equinox.registry bundle is installed and resolved. If it is not resolved then run the 'diag' command to see why the registry bundle is not resolved. Tom John Arthorne ---09/06/2007 11:22:26 AM---I am trying to run a simple Equinox-based product with J9 (Foundation 1.1 profile). Is there some trick to getting running with John Arthorne <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/06/2007 11:21 AM Please respond to Equinox development mailing list To equinox-dev@eclipse.org cc Subject [equinox-dev] Launching with Foundation 1.1 VM I am trying to run a simple Equinox-based product with J9 (Foundation 1.1 profile). Is there some trick to getting running with this setup? Here is the command line that allows me to make the most progress: eclipse -product org.eclipse.prov.client.installer.product -debug -vm jre\bin\j9.exe -vmargs -jcl:ppro11 -Dorg.osgi.framework.executionenvironment="OSGi/Minimum-1.0,OSGi/Minimum-1.1,CDC-1.0/Foundation-1.0,CDC-1.1/Foundation-1.1" With this command line, I get various errors in the log, starting with: !ENTRY org.eclipse.equinox.app 4 0 2007-09-06 12:17:51.968 !MESSAGE !STACK 0 org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Missing Constraint: Require-Bundle: org.eclipse.equinox.registry; bundle-version="[3.2.0,4.0.0)" at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:350) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1118) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:634) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:508) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:282) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:468) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:209) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:319) I have tried invoking the VM directly rather than using eclipse.exe, but get the same result. The same launch runs fine with a 1.4 or Java 5 VM. Ideas?___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equi
