Re: [osgi-dev] OSGi
Hi David, Neil is right, you can place any arbitrary header in the Manifest in order to provide the information you need. However, maybe some of the information you intend are already provided by someone or you're intended header is already at use by some other vendor. As a starting point, I would suggest to take a short peek at the following list of headers already in use: http://www.osgi.org/Specifications/ReferenceHeaders Cheers, Mirko On Wed, Jun 16, 2010 at 9:27 AM, Neil Bartlett njbartl...@gmail.com wrote: David, The JAR File Specification allows you to place whatever arbitrary headers you like in the MANIFEST.MF. They will be ignored by OSGi. Regards, Neil On Wed, Jun 16, 2010 at 7:36 AM, David Conde dco...@citic.es wrote: Hi, What could I use in order to provide some custom information in the MANIFEST file in order to read this information before installing the bundle in Equinox? I mean, I would like to provide some extra information in the bundle but I would like to be able to read the information before installing the bundle so I thought to do it in the MANIFEST by using some special label if it exists. Thank you in advance ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] How to get runtime Memory Usage for an OSGi bundle..?
Well, you can use the JVMTI interface of the JVM in order to build your own analysis agent. Unfortunately this means writing native C/C++ code, but if you feel the need - it might be worth the effort. Mirko On Tue, Jun 15, 2010 at 4:23 PM, Jeff McAffer j...@eclipsesource.comwrote: At one point in the past we (Equinox team) had connections to the IBM J9 JVM that could tell you about the space taken for each bundle wrt *classes* and literals. The Eclipse Core Tools [0] still have that support in but I doubt that the VM side still works. Also in the past (and perhaps still) the J9 guys worked on Resource Managed (RM) support that allowed for tracking and control of heap memory usage on a per classloader (e.g., bundle) basis. I don't know the status of this work. Jeff [0] http://wiki.eclipse.org/Core_Tools On 2010-06-15, at 7:57 AM, BJ Hargrave wrote: I don't know of such a command and I am not sure one can be properly written. There is no way to properly assign a memory object to a specific bundle. For example, which bundle should be the owner of a HashMap object? No matter what rules you construct to decide this, there is a reasonable case in which your rule is wrong. -- *BJ Hargrave* Senior Technical Staff Member, IBM OSGi Fellow and CTO of the *OSGi Alliance* http://www.osgi.org/* **hargr...@us.ibm.com* hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 From:Ashish Billore1 ashish.billo...@in.ibm.com To:osgi-dev@mail.osgi.org Date:2010/06/15 07:36 Subject:[osgi-dev] How to get runtime Memory Usage for an OSGi bundle..? Sent by:osgi-dev-boun...@mail.osgi.org -- Hello Everyone, I am working on optimization and performance tuning of an OSGi based server application (uses customized Equinox as runtime and has OSGi bundles and headless Eclipse Plugins as building block). For this, I need to get the profiling data about OSGi bundles and plugins running in the application. So, is there any command or utility which can give me memory footprint of a given bundle/plugin? Some command like: osgimemusage bundle_id I tried using some of the profilers out there (Eclipse TPTP) etc, however, they have problems like: - Too heavy, they introduce their own overheads and most of the time the app jvm crashes (due to out-of-memory errors or problem with the remote agent). - Give very low level profiling info (i.e. gives info about java classes and application class level info) however, I am more interested in knowing these details at the bundle level. Thanks for the help. Best Regards, Ashish Billore ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] launching API and resolving fragments
Thanks! That was exactly what I was looking for... On Fri, Dec 11, 2009 at 8:00 PM, Thomas Watson tjwat...@us.ibm.com wrote: PackageAdmin has the resolveBundles(Bundle[]) method. You may still have issues getting a fragment to attach to a host bundle if that host bundle is already in the resolved state. In that case you must refresh the host first to force it to re-resolve. PackageAdmin#refreshPackages(Bundle[]) can be used to force a host bundle to re-resolve. Hope that helps. Tom [image: Inactive hide details for Mirko Jahn ---12/11/2009 12:26:39 PM---Hey there,]Mirko Jahn ---12/11/2009 12:26:39 PM---Hey there, From: Mirko Jahn mirkoj...@gmail.com To: OSGi Developer Mail List osgi-dev@mail.osgi.org Date: 12/11/2009 12:26 PM Subject: [osgi-dev] launching API and resolving fragments -- Hey there, I am currently playing with the new launching API introduced with r4.2. I managed to get several bundles started without any problems. Now I don't want to start all bundles (just resolve them) and in particular I want to resolve fragments (starting will throw an exception of course and not resolve). Am I missing something, because I couldn't find a way to attach the fragments without using proprietary APIs. Cheers, Mirko___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev graycol.gifecblank.gif___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Same interface implemented multiple times
On Fri, Jun 5, 2009 at 9:32 AM, Daniel Dumitrescu dumitrescu.dan...@gmail.com wrote: but you should try to extract all these packages to a single bundle that is used by all your satellite bundles as well as the the main bundle. Ok, i'll try that. This is equivalent to Richards 2. proposal... btw.: your framework should tell you why the other bundles are not resolved! Nope, the framework (Eclipse Equinox) does not throw any problems, just the traces (sys.outs) doesn't appear for all satellite bundles. you can try to start these bundles manually. Usually then you see the error. Alternatively you can try diag bundleID to get some more information. Hope that helps a bit, Mirko ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Best practice to decouple remote technology from bundles
Hi Eugen, I have to admit, that I am not familiar with ECF and I don't know how tight it is coupled to Equinox/Eclipse, but as long as you rely on RFP 119 of the upcoming OSGi R4.2 specification, it doesn't really matter if the implementation is young or not. You should be able to switch the remoting implementation without affecting your clients. At least this was the idea behind the spec. Just my 2 cents. Maybe Scott can elaborate on this further... Cheers, Mirko On Wed, May 20, 2009 at 2:30 PM, Eugen Reiswich reisw...@informatik.uni-hamburg.de wrote: Hi Scott, thanks for the clarification, I indeed misunderstood some concepts behind ECF. I will consider your statement for our next project although I fear to run into truble with our project lead if I try to convince him to use the young ECF technology rather than matured RMI or something similar. Regards, Eugen Am May 19, 2009 um 23:18 schrieb Scott Lewis: Hi Eugen, Eugen Reiswich wrote: Hi Scott, ECF is definitely one approach (and it does it really good) but since it is not the only one remote framework I'm looking for a way to decouple my bundles from any technology as much as possible. The goal is to be able to switch from ECF to Riena or RMI or some other technology with a minimal effort. Yes, I understand this desire. But one thing to clarify: I think it's a common misconception that ECF's remote services API is actually a peer technology to Riena, RMI, r-OSGi, CXF, SOAP-based web services, etc. It is *not* this. The remote services API is just an abstract remoting/distribution API *separate* from any/every implementation. Of course, ECF also has provider/implementation bundles that implement the rs API, and we have several of these ...e.g. based upon/using r-OSGI, RMI, JMS, XMPP, and we expect soon Riena and others. So, clients that use the remote services API (and/or our RFC 119 implementation...which is layed on top of the ECF remote service API) have no effort to move to some other technology for distribution. I see that as one of the main advantages of separating out API from implementation technology for remoting/distribution...and given the frequency and the traditional difficulty of what you are doing (moving to some other distribution technology) we think this advantage is significant. In any case, sorry to all for the long-windedness on this point...but we've been what I consider mischaracterized before as being a peer/competitor with other distribution technologies...and so I wanted to clarify this point. Scott ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] Certificate access in Management Agent
Hey there, I am currently working on a general management agent for security. I have a somewhat working prototype, but it lacks several key features I was hoping to integrate. Most importantly, I wonna get rid of all proprietary code and that's the reason why am asking. The management agent (MA) gets installed first. At that time, no other bundle is installed yet. I have a synchronous bundle listener to get notified about attempts to install any further bundles and to asses if they should be installed or not. Now I am asking myself... - How could one get access to the ProtectionDomain information of a bundle from within the MA? Things like the signer, the certificates, etc. I don't have a Class or ClassLoader at hand to get this kind of information. I also don't have access to the jar to extract these kind of information manually. - Same is true for a custom Condition. How can I gain access to the ProtectionDomain information within that one? - As an alternative, I thought about using the BundleSignerCondition, but here I am very limited in my syntax of expressing a dependency on the certificate chain (simply f.i.: A - B - C vs. A - X - B` - C`, here a test for trust root A - like VerySign - and properties of C will also be valid for both cases, because the C` appears identical to C, but differs in the chain). Maybe I am wrong, but I don't know exactly how to express such constraints. (see 4.1 spec 2.3.6) Thanks, Mirko ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Certificate access in Management Agent
Hi Tom, sounds good. Hope the R4.2 is coming soon ;-) Well, concerning you're question, you're right. I am waiting for the INSTALLED event to get a notification about newly introduced bundles. Assuming I have a secure runtime, no other bundle will have the right to resolve that bundle other than my agent. After checking the certificates the build-in pseudo rule-engine decides what to do with the bundle... continue resolving or uninstalling it. Do you see any problems with this approach or do you have a better idea? I thought an installed bundle is still pretty safe, because it doesn't have a class loader, it can't be used as a library for resource lookups and native code isn't loaded as well. Just the meta-data is known to the framework, which shouldn't hurt I hope. Another alternative approach I was thinking about was having the management agent control the whole installation process. Meaning the framework starts with just one single bundle (the MA) and after the start, a configuration is read, which defines the certificate rules, start order,etc. in order to boot-up the whole system. However I preferred the other solution because of obvious reasons. I don't want to invent/implement everything from scratch. I thought this should be a not so unusual use case (although security isn't used that excessively), so I assumed the spec reflects it somehow. Any insights on how such things are done right now (in academia as well as industry) are more than welcome. Thanks, Mirko -- Mirko Jahn http://osgi.mjahn.net On Thu, Dec 11, 2008 at 3:31 PM, Thomas Watson [EMAIL PROTECTED] wrote: For the OSGi R4.2 specification there is a proposal to add a new method to Bundle to get the signer certificates. I think this would help out your scenario. But I am wandering how a synchronous bundle listener is going to prevent the installation of a bundle if the user chooses not to trust the bundle. There is no INSTALLING event, only INSTALLED event. This means the bundle has already been installed and is available. Would you then simply uninstall the bundle at that point? Tom Mirko Jahn ---12/11/2008 07:44:45 AM---Hey there, From: Mirko Jahn [EMAIL PROTECTED] To: OSGi Developer Mail List osgi-dev@mail.osgi.org Date: 12/11/2008 07:44 AM Subject: [osgi-dev] Certificate access in Management Agent Hey there, I am currently working on a general management agent for security. I have a somewhat working prototype, but it lacks several key features I was hoping to integrate. Most importantly, I wonna get rid of all proprietary code and that's the reason why am asking. The management agent (MA) gets installed first. At that time, no other bundle is installed yet. I have a synchronous bundle listener to get notified about attempts to install any further bundles and to asses if they should be installed or not. Now I am asking myself... - How could one get access to the ProtectionDomain information of a bundle from within the MA? Things like the signer, the certificates, etc. I don't have a Class or ClassLoader at hand to get this kind of information. I also don't have access to the jar to extract these kind of information manually. - Same is true for a custom Condition. How can I gain access to the ProtectionDomain information within that one? - As an alternative, I thought about using the BundleSignerCondition, but here I am very limited in my syntax of expressing a dependency on the certificate chain (simply f.i.: A - B - C vs. A - X - B` - C`, here a test for trust root A - like VerySign - and properties of C will also be valid for both cases, because the C` appears identical to C, but differs in the chain). Maybe I am wrong, but I don't know exactly how to express such constraints. (see 4.1 spec 2.3.6) Thanks, Mirko ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Asynchronous communication between the osgi services
And just to be complete. Here is the white paper covering the differences between Listeners and the Whiteboard Pattern. A must read so to speak, if you want to do serious OSGi development! ;-) http://www.osgi.org/wiki/uploads/Links/whiteboard.pdf Cheers, Mirko On Thu, Oct 23, 2008 at 7:58 AM, Difu [EMAIL PROTECTED] wrote: Dear Gul: One of the major pros of OSGi framework is, that she suggest us use White Board pattern to eliminate the drawbacks of the traditional Listener pattern. One of the services provided by the framework, called Event Admin Service may be a good example for you. It supports not only sync message delivery, but async delivery as well. Please refer to the specification of Event Admin Service [Service Compendium 113, OSGi Spec 4.1] for more information. Enjoy! BR Difu On Thu, Oct 23, 2008 at 5:22 PM, Gul Onural [EMAIL PROTECTED] wrote: Our current product architecture heavily relies on asynchronous communication (through the listeners) between the components. In the OSGI R4 spec, I can see how synchronous communication between the services are done, but I don't see anything about the asynchronous communication. What is the design pattern people used to implement asynchronous (event driven) communication between the osgi services ? Gul ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Importing of javax.* and friends
Silly question maybe, but how did you provide the jar? If you choose a simple bundle, it sounds like a missing import statement of sun.security.jca, because otherwise your bundle wouldn't resolve (assuming you didn't specify the dependency as optional). In my JVM the jce.jar is part of it, so you could simply add the package to the boot delegation: org.osgi.framework.bootdelegation=sun.*,com.sun.*,javax.crypto.* Another last possibility is creating a fragment bundle that contains this very export statement and is attached to the system.bundle. Depending on the implementation. you might also need to specify it as a framework extension. This is a nice way to show that you expose more than just java.* from your JVM, but has the drawback that for instance the Eclipse IDE won't recognize that (at least last time I tried it). So I guess, you should have some more possibilities to try out. On Tue, Sep 30, 2008 at 7:54 AM, David Leangen [EMAIL PROTECTED] wrote: Anyway, since the framework is not providing this, is this an error on the part of my framework (Equinox)? Or it is normal that I should have to ensure myself that these extensions are available, such as for example wrapping them in my own bundle or providing them to the bootdelegator? This is still not so clear to me... While waiting for some enlightenment on this subject... I provided my own wrapper bundle for jce.jar. However, boom: java.lang.NoClassDefFoundError: sun/security/jca/GetInstance at javax.crypto.KeyGenerator.init(DashoA12275) at javax.crypto.KeyGenerator.getInstance(DashoA12275) The sun.security.jca package is part of rt.jar. Just to be sure that bootdelegation is set up correctly, I specifically set this property: org.osgi.framework.bootdelegation=sun.*,com.sun.* The problem persists. Isn't rt.jar supposed to be part of bootdelegation? So, doesn't this make this a framework issue? Thanks! =David.Leangen ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev -- Mirko Jahn Heidelberger Str. 51 69126 Heidelberg Germany Fon: +49 [0] 6221 - 431 28 58 Mobile: +49 [0] 173 211 41 94 E-Mail: [EMAIL PROTECTED] Web: http://www.mjahn.net ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] Maven and official OSGi API jar
Hi, I am currently working on a new build environment and I again have to ask myself, what is actually the official Maven OSGi jar. I know, I can download the API from the osgi website and somehow refer to that one, but isn't there an official distribution on a public maven repository? After a quick search, I found these 3rd party versions floating around. dependency groupIdorg.osgi/groupId artifactIdosgi_R4_core/artifactId version1.0/version scopeprovided/scope /dependency == r4.0, not a bundle dependency groupIdorg.osgi/groupId artifactIdorg.osgi.core/artifactId version4.0/version scopeprovided/scope /dependency == r4.0.1, packaged as a bundle dependency groupIdorg.apache.felix/groupId artifactIdorg.osgi.core/artifactId version1.2.0/version /dependency == r4.1, packaged as a bundle Neither of them lead to a simple identifier (within maven) to actually see, which OSGi spec version we are having. At least the last two provide a Bundle-Version header with the correct version. So did I just miss the jars in the repo or if not, are there any plans to support such an official API maven jar? Cheers, Mirko ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Maven and official OSGi API jar
Thanks for the feedback. I guess until there will be an official maven distribution, I'll stick to the OPS4J repo. Right now I am hiding this behind an Archiva repository anyway, so it isn't a big issue to change this later. However, having an official distribution, which is ideally signed by the OSGi as well, would be perfect. Cheers, Mirko On Tue, Sep 30, 2008 at 12:03 PM, Alin Dreghiciu [EMAIL PROTECTED] wrote: I had signal this a while ago to Peter Kriens, but for the moment I guess the issue is pending. My wish is that the original OSGi Alliance arifacts are in maven central repo, but till then you can find them in OPS4J repository: http://repository.ops4j.org/maven2/org/osgi/org.osgi.core/ http://repository.ops4j.org/maven2/org/osgi/org.osgi.compendium/ So, what you have to do is to add a repository to your pom or settings.xml for OPS4J repository: http://repository.ops4j.org/maven2 The artifacts you can find on OPS4J are exactly the ones download from OSGi alliance and the version matches the specs version. On Tue, Sep 30, 2008 at 12:39 PM, Mirko Jahn [EMAIL PROTECTED] wrote: Hi, I am currently working on a new build environment and I again have to ask myself, what is actually the official Maven OSGi jar. I know, I can download the API from the osgi website and somehow refer to that one, but isn't there an official distribution on a public maven repository? After a quick search, I found these 3rd party versions floating around. dependency groupIdorg.osgi/groupId artifactIdosgi_R4_core/artifactId version1.0/version scopeprovided/scope /dependency == r4.0, not a bundle dependency groupIdorg.osgi/groupId artifactIdorg.osgi.core/artifactId version4.0/version scopeprovided/scope /dependency == r4.0.1, packaged as a bundle dependency groupIdorg.apache.felix/groupId artifactIdorg.osgi.core/artifactId version1.2.0/version /dependency == r4.1, packaged as a bundle Neither of them lead to a simple identifier (within maven) to actually see, which OSGi spec version we are having. At least the last two provide a Bundle-Version header with the correct version. So did I just miss the jars in the repo or if not, are there any plans to support such an official API maven jar? Cheers, Mirko ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev -- Alin Dreghiciu http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org- New Energy for Java - Domain Driven Development. http://malaysia.jayway.net - New Energy for Projects - Great People working on Great Projects at Great Places ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev -- Mirko Jahn Heidelberger Str. 51 69126 Heidelberg Germany Fon: +49 [0] 6221 - 431 28 58 Mobile: +49 [0] 173 211 41 94 E-Mail: [EMAIL PROTECTED] Web: http://www.mjahn.net ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Version constraints used in Import-Package
As for tooling, PDE now (as of 3.4) includes some API tooling that helps with version numbering violations and breaking API changes (amongst other things). See http://wiki.eclipse.org/Api_Tooling Thanks, this is what I was looking for! I am a very strong believer in developer defined dependencies. Tooling is essential in making this easy (we are getting there with PDE and bnd) but to create well-engineered components one must pay close attention to your dependencies. Reverse-engineering them from developed code can provide a great starting point and tools can help you stay in the bounds that you defined based on that starting point but ultimately a real live human developer needs to be involved in crafting these dependencies. Yeah, that's true. The only problem I am seeing here in general is that users, unfamiliar with the problem might end up producing a large number of components not following a reasonable versioning or dependency management strategy. Ultimately, I think it boils down to the fact that not every developer can be a modularization expert. I think this is too much to expect and should not be the requirement. As you stated, there are architects, which have to ensure that the overall software design fits. However, doing everything by hand is not only hard but also error prone. Using a tool to help you on the way is what we actually need. Of course, tools can't replace the knowledgeable developer/architect yet, but they should at least give the developer reasonable defaults and hints, where the tools suspects problems. The packages and versions you choose basically define the contract you are committing to. A lower lower bound means that you are constraining yourself to use only a certain level of function in a certain series of YOUR bundles. Raising your lower bound in a service release of your bundle for example can cause people's applications to stop running/resolving (they may not be able to supply the new version of the prereq). A higher upper bound means you are willing to take on more risk in your bundle as a wider range of changes in your prerequisites is going to be tolerated. You have to trust the producer to be reasonable and write your code to be robust. Sure, here you have to decide on a case by case basis. But again, tooling can provide you with a list of possibilities. Picking one of those is definitely easier than finding them manually and figuring out which ones fit and which ones don't. The goal should be to prevent the developer from doing unnecessary failures and support him by his decisions based on actual facts (tests). I think Eclipse is on the right track, so I am certainly keeping my eyes open to see what will come in the future. There is no silver bullet here IMHO. The tooling can be improved but ultimately the burden belongs to a developer. In fact, in several projects I know of it is the architects and senior people who design these dependencies. They don't just appear because some developer hit Ctrl-space and autocompleted to include whole new reams of function. Depending on your domain/software, this can make perfectly sense! Quite some time ago, I did that too, but right know I prefer pair programming component design, where an architect (or senior) is working with a developer (usually the code owner). This is great for both. Helping the junior understand the overall picture and potential flaws in his concept and the senior how well understood his architecture is and how knowledgeable the developers became. Cheers, Mirko Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:osgi-dev- [EMAIL PROTECTED] On Behalf Of Mirko Jahn Sent: Wednesday, June 04, 2008 7:34 PM To: OSGi Developer Mail List Subject: Re: [osgi-dev] Version constraints used in Import-Package Well, unfortunately this is kinda true. I think the spec is great in terms of capabilities, but first of all everyone needs to understand the implications of version number schemes. OSGi is great to gain quick benefits, but if it is adapted in a very simple way (only plain exports without version numbers, imports without version ranges and so on) the benefits are very limited. Actually, I even think it might cause sooner or later real problems with interoperability. More in the terms of awareness and training should be done. Otherwise we might end up with thousands of bundles not worth a thing, because we can't rely on them. Everything has to be done by hand. The ultimate goal should be to have tooling support to automatically generate these numbers. The tool should detect version changes between releases on a semantic and syntactic level and change the version numbers accordingly. No human interaction should be required. This is the way to go I think. The only thing the bundle developer should be involved with is defining the version to export - even imports with version ranges should be handled by the tool. This would
Re: [osgi-dev] Put API/SPI/implementation into separate bundles?
Concerning this... Huh? If only com.bar is present than these dependencies exist anyway? A: Import-Package: com.foo B: Export-Package: com.foo Import-Package: com.bar, com.baz A will resolve to B. B has dependencies that are required to implement com.foo. If I take implementation C: C: Export-Package: com.foo Import-Package: com.bzz I will get different dependencies, but A remains oblivious of all this. Agreed, but the problem David was talking about is a different one (I guess). What if you don't actually need the implementation right away. In a very dynamic and as small as possible environment, you just want to have an API and load the implementation later on an as needed basis. Now, if you always distribute the implementation all the dependencies of the Implementation (and their dependencies and so on) have to be present in the container and need to be resolved. Of course you can just define your implementation optional in this case and the question, if you should depend on the API in a fixed instead of an optional way remains, but I think this was the use case David was talking about. One example I can think of out of the top of my head is logging. You might want to have the API present, but no logging service deployed, because it is some sort of thin (ultra light) client. If the service is there, use it, if not... don't bother. Just for the sack of arguments, you can also provide a /dev/null logger as the default implementation, which wouldn't have any dependencies. I think there is plenty of space to argue here. Ultimately, there is no black or white only different shades of gray ;-) Just my 2 cents... Cheers, Mirko ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] About Chinese Character problem when export plug-in in eclipse
Actually, I guess this is more an issue with Eclipse or maybe Equinox, rather than the OSGi specification. So I would recommend you to re raise your question on one of the Eclipse developer mailing lists. Here is a list to all available projects with their mailing lists: http://www.eclipse.org/projects/listofprojects.php I think, I would ask in the pde developer list first. Cheers, Mirko On Mon, Apr 21, 2008 at 12:44 PM, Jin Mingjian [EMAIL PROTECTED] wrote: too coarse to see the problem. ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
