OSGi Blog
Showing posts with label eclipse. Show all posts
Showing posts with label eclipse. Show all posts
Wednesday, September 13, 2023
BND Tools 7.0 Release Candidate 1 is available
We are happy to announce the BND Tools 7.0.0 Release Candidate, which can now be downloaded here. Thanks to the support by members of the OSGi Working Group the code base has been ported to Java 17 and the release features the support of multi release JARs (among many other changes). For the changelog and release notes, please check out Github. You can also contribute via the issue tracker or discuss the latest release in the bnd forums.
Tuesday, March 16, 2021
Update on the OSGi Working Group
Dear OSGi enthusiasts,
It has been a couple of months since we announced the move of your favorite Specification Organization to the Eclipse Foundation. We have been silent since, but this does not mean that we have been inactive. So we want to use this chance to give you a brief update on the current state of affairs.
In early January we started our work, by forming the OSGi Working Group Steering Committee. We basically started the Working Group (WG) up by ratifying the Charter. Despite our Veterans on the Committee, we needed to find our feet and learn how to navigate the new waters of the Eclipse Foundation. Thanks to the tremendous support we receive from the Eclipse Team we persevered and made a lot of progress to manage the necessary formalities.
What is the current status you ask? We have formed the following bodies:
OSGi WG Steering Committee
The Steering Committee is the overall governing body of the WG. If you are interested in details on the function of the committee, have a look at the Powers and Duties section in the Charter. At the moment we have two elected Participant members in addition to the Strategic members with a permanent seat. The seat for an elected Committer representative is currently vacant and an election will take place in the May timeframe, as soon as the Projects are completely set up and everyone has had sufficient time to join.
For the time being, we have adopted the vanilla Eclipse Specification Process as suggested by the Specification Committee. All the specification work will fall under the Implementation Patent License. We are currently working on the migration of the old Alliance assets (Website, Twitter etc.) and to chaperon the projects that are being set up as we speak.
OSGi WG Specification Committee
This committee governs the Specification Process and votes on the final Specifications. It thus steers the technological direction our Specifications will take. For more details you can again look at the charter.
At the moment it is composed of the same members as the Steering Committee. The real work of the committee will start once specification work begins in the OSGi Specification Project. We need to get a feeling for the Eclipse Specification Process and need to see if we want to make adjustments.
OSGi Specification Project
This is where the magic happens. All specification work will be done in this project. It is already open to join, however you must be a member of the OSGi Working Group to be a project committer. The original OSGi github repository was handed over to the Eclipse Foundation and is now public. It is currently undergoing final integration into Eclipse Foundation processes. As soon as this is done, we can commence our actual specification work. How we will proceed with the design repository, is still an open point and will be addressed soon. We are currently discussing things like: Do we want to keep RFPs and RFCs?, How will they be written in the future?, etc. If you want to get on the notification train for this project, please subscribe to the project's mailing list. The
OSGi Technology Project
Here our companion projects like osgi-test or OSGi enRoute. If you are a committer already or plan to become one, please join the project. Becoming a committer in this project does not require you to be a member of the OSGi Working Group.
What else?
The old osgi.org website is dead and the current version is just a placeholder. Creating fitting and prevailing content is currently discussed and we hope to get the new version online as soon as possible. Javadoc and Specifications are still available under docs.osgi.org.
There are a lot of other minutiae we will not bother you with. We still have a lot of work ahead of us and as a volunteer army, everyone who is willing to help is welcome. So please spread the word.
We try to get everything up and running as soon as possible and will keep you posted.
You Committee Team.
Wednesday, December 9, 2020
OSGi Core Release 8 is now final and published
The specifications, reference implementations, and compliance tests for OSGi Core Release 8 have been approved as final by the members of the OSGi Alliance as one of the final actions of the OSGi Alliance as we transition the mission to the OSGi Working Group at the Eclipse Foundation.
You can find the online version of the Core Release 8 specification on the OSGi Specification Project Documentation website. A PDF version is also available for download. Javadoc is also available and the artifacts are now available on Maven Central.
As part of the mission transfer to the OSGi Working Group, the work will of course be done in open source projects. So I have recently submitted project proposals at Eclipse to form the OSGi Specification Project and the OSGi Technology Project. The OSGi Specification Project will be responsible for OSGi specification development and evolution and will take direction from the OSGi Working Group as a specification project under the Eclipse Foundation Specification Process. The OSGi Technology Project will host OSGi technology-related (non-specification) projects like the exciting osgi-test project we recently presented at EclipseCon 2020.
One of the immediate results of moving the mission to Eclipse is that we have now made the OSGi git repositories public. Check out the OSGi GitHub organization and, in particular, the OSGi Specification Project Build repository.
Finally, I would like to encourage everyone to consider joining the OSGi Working Group and get involved in continuing to evolve the OSGi specifications. Your company can join and individuals can also join as well. Work on Compendium Release 8 was well underway in the OSGi Alliance when we started the mission transfer to the OSGi Working Group at the Eclipse Foundation and we will get right back at it once we get the OSGi Working Group and OSGi Specification Project bootstrapped at Eclipse. I hope to see you there!
Monday, October 19, 2020
Sunday, October 15, 2017
OSGi Tooling Workshop Oct 23 - Ludwigsburg
The German OSGi Users' Forum is holding an OSGi Tooling Workshop on Monday, October 23, 2017 in Ludwigsburg starting at 10.30 am.
Its free to attend and you will hear the latest news about development tooling for OSGi. This will include IntelliJ, Eclipse, Bndtools, Gradle, Maven, Eclipse RCP and PDE.
So anyone attending the OSGi Community Event and EclipseCon Europe should be very interested in this as its being held at the same location in the Forum am Sclosspark.
The full schedule and presenters can be found on the German OSGi Users' Forum event page HERE.
To register and reserve you place please send an email to germany-info@osgiusers.org
Its free to attend and you will hear the latest news about development tooling for OSGi. This will include IntelliJ, Eclipse, Bndtools, Gradle, Maven, Eclipse RCP and PDE.
So anyone attending the OSGi Community Event and EclipseCon Europe should be very interested in this as its being held at the same location in the Forum am Sclosspark.
The full schedule and presenters can be found on the German OSGi Users' Forum event page HERE.
To register and reserve you place please send an email to germany-info@osgiusers.org
Wednesday, May 17, 2017
OSGi Community Event 2017 CFP
 |
|
is licensed under CC BY_SA 2.0.
|
The OSGi Community Event Program Committee is pleased to announce that the Call For Papers (CFP) for the 2017 event is NOW OPEN.
We are looking for submissions from anyone who has something to share about OSGi technology, the OSGi ecosystem or OSGi community. All successful submissions receive a free speaker all access pass to the OSGi Community Event and EclipseCon Europe.
Popular topics often include use cases and case studies of using OSGi, OSGi open source projects or commercial OSGi products where you have some experience to share. Presentations on tools and frameworks that can improve the developer experience are also well received. We are also looking for a 3-hour tutorial, so if you have a project or some examples on an OSGi specification where the audience can participate with you then we would welcome your submissions.
OSGi is used in many different environments and markets and we are interested in hearing from your use in any of them, be it enterprise, telecommunications, transport, retail, IoT, Industry 4.0, M2M, Cloud, or Smart Home, to name just a few.
It's always great to get submissions from new members to the community and/or new speakers so please don't be shy and get your submissions in. Whether what you have to share is small or large, state-of-the-art or traditional, business critical or a pet project, we want to hear from you.
It's always great to get submissions from new members to the community and/or new speakers so please don't be shy and get your submissions in. Whether what you have to share is small or large, state-of-the-art or traditional, business critical or a pet project, we want to hear from you.
Your submission should be either for a 35-minute talk or a 3-hour tutorial.
We are sharing the submission system with EclipseCon Europe so please be sure to select OSGi as the track when making your submission to be sure the OSGi Program Committee will get to review your proposal.
The CFP is open until July 17, however the Early Bird submission deadline is June 30.
As an added incentive to get your submissions in for the Early Bird deadline we will award a €50 Amazon Voucher to the talk selected for the OSGi Early Bird pick. Be sure to submit by June 30 to be in with a chance of winning this.
The OSGi Community Event 2017 will be taking place between October 24 to 26. Once again this year the event is being held at the Forum am Schlosspark in Ludwigsburg, Germany. As always there will be plenty of talks, BOFs, social events, beer, wine and food so make sure you have the dates in diary and start planning your travel and accommodation early.
If you have any questions please contact us by email.
Thursday, March 9, 2017
OSGi at CeBIT 2017
The OSGi Alliance is pleased to be returning to CeBIT again this year between Monday March 20 to Friday March 24.
We will be showcasing the popular OSGi IoT Demo which uses a number of different OSGi open source projects, and commercial products from OSGi Alliance members (Bosch, Eclipse, Eurotech, imec, Makewave, Paremus and Skelmir) to manage and control the operation of LEGO® trains. This really is a great example of the interoperability of the OSGi specifications and demonstration of how an IoT ecosystem can be created using OSGi technology.
You can find us on Stand C62 in the IoT / M2M Pavilion located in Hall 12 [Map].Be sure to stop by and say hello . You will also be able to find out more about what we are doing in the demo and broader OSGi activities. You can also take the opportunity to interact with the sensors and RFID tags in the demo to see the affect they have on the LEGO® trains running around the track.
A number of the OSGi IoT and Enterprise Expert Group members will be on hand to answer any questions you may have about OSGi and its use in IoT and also Enterprise and Cloud. We would also be pleased to discuss with you about how you can get involved and contribute to new specifications and also join the OSGi Alliance.
IoT Expert Conference Keynote Presentation
'How OSGi can help to build open IoT ecosystems ?"
Complimentary Tickets to CeBIT
Hope to see you in Hanover March 20 to 24.
Wednesday, August 24, 2016
OSGi BoF - We Want Your Topic Suggestions
The OSGi Alliance will be hosting a Birds of a Feather (BoF) on the evening of Tuesday 25 Oct at the OSGi Community Event in Ludwigsburg, Germany. The BoF will be open to all attendees of the OSGi Community Event and EclipseCon Europe (registration for the conference Oct 25 to Oct 27 is open so book your tickets today). Full details on the timing and room location will be confirmed n due course.
The BoF is a regular occurrence at our annual event. This year we are asking you, the OSGi community, to provide us with your suggestions on topics that you think would be good to consider and discuss at the BoF. You can send us your ideas, even if you are not able to join us for the event or the BoF. We would, of course, love to have you there on person too to participate, so please do attend if you can.
To make your suggestions please visit our online form. You can optionally provide us with your name and email address if you would like to receive an update on the final BoF topic list.
The program for the conference has been announced. We will have 1 OSGi Keynote, 1 tutorial, 25 talks, the BoF, the OSGi IoT Demo, and lots of opportunity to meet and mingle with your peers and colleagues and participate in the included conference evening social events. Attendees to OSGi Community Event also get full access to the EclipseCon schedule and talks, so there is plenty to keep you busy for all 3 days.
Paul Fraser is presenting on OSGi enRoute and he has put together a 40-second fun video to entice you to join his talk - Its Beautiful enRoute. The talk is taking place on Tuesday 25 October between 15.45 and 16.20 in Seminarräume 1-3.
Finally, but definitely importantly, many thanks to our OSGi Community Event sponsors, whose support ensures we can continue to provide an excellent conference value every year.
For 2016 we are pleased to have sponsorship so far from:
If you would like to explore how your company could join the sponsors please contact us by email.
And a final big thank you to our event partners EclipseCon Europe with whom we are co-located and who provide all of the logitstics and organisation for running OSGi Community Event.
 |
| By Richard Taylor (originally posted to Flickr as Birds of a feather) [CC BY 2.0 (http://creativecommons.org/licenses/by/2.0)], via Wikimedia Commons |
To make your suggestions please visit our online form. You can optionally provide us with your name and email address if you would like to receive an update on the final BoF topic list.
The program for the conference has been announced. We will have 1 OSGi Keynote, 1 tutorial, 25 talks, the BoF, the OSGi IoT Demo, and lots of opportunity to meet and mingle with your peers and colleagues and participate in the included conference evening social events. Attendees to OSGi Community Event also get full access to the EclipseCon schedule and talks, so there is plenty to keep you busy for all 3 days.
Paul Fraser is presenting on OSGi enRoute and he has put together a 40-second fun video to entice you to join his talk - Its Beautiful enRoute. The talk is taking place on Tuesday 25 October between 15.45 and 16.20 in Seminarräume 1-3.
Finally, but definitely importantly, many thanks to our OSGi Community Event sponsors, whose support ensures we can continue to provide an excellent conference value every year.
For 2016 we are pleased to have sponsorship so far from:
If you would like to explore how your company could join the sponsors please contact us by email.
And a final big thank you to our event partners EclipseCon Europe with whom we are co-located and who provide all of the logitstics and organisation for running OSGi Community Event.
Monday, February 25, 2013
New OSGi Tool Chain Documentation
People sometimes say that OSGi is hard to use because tooling support is lacking. Well, there are actually quite a lot of OSGi-related tools out there, but many of them address a specific area. They often work together with other tools to address a larger context. A modular approach to tooling, if you like... One of the issues with this approach was however that it could be hard to find out how these tools are working together to address a real life scenario. An example scenario would be how to set up an entire development environment that includes a headless build, and IDE with debugging facilities and a testing environment. Documentation describing how to do all this using a combination of existing tools was not easily available.
Over the past months a number of people have worked together on creating a set of documentation pages that describe various OSGi toolchains: how a number of tools can be combined to create an end-to-end solution. For example, it describes how Bndtools can be used with Ant and Eclipse to create a comprehensive development setup. But there are more options. Not everyone uses Bndtools, other people might use Tycho with Eclipse and Maven. This is also documented. As is how to use Maven with Bnd, Eclipse and Pax-Exam.
Additionally there is a page describing how to set up a Scala build environment for OSGi using SBT.
All the details of how to get going are described on a new set of pages focusing on documenting OSGi tool chains on the OSGi wiki. You can find them here: http://wiki.osgi.org/wiki/ToolChains
All the details of how to get going are described on a new set of pages focusing on documenting OSGi tool chains on the OSGi wiki. You can find them here: http://wiki.osgi.org/wiki/ToolChains
The pages that are there now are just a starting point. They should get you going with a number of OSGi tooling technologies. As most of the pages use a similar example it is also possible to compare the various approaches. However, there is always room for improvement. As this is an open environment feel free to contribute. If you are using a different toolset, document it! Or if you have anything to improve the descriptions add it in!
http://wiki.osgi.org/wiki/ToolChains
http://wiki.osgi.org/wiki/ToolChains
Thursday, October 4, 2007
Universal OSGi
There is an idea that has been simmering in the OSGi Alliance for quite some time: Universal OSGi. My first recollection of this idea is from 1999, when I was working in Linkoping at Ericsson Wireless Technology, a place in the middle of nowhere. I worked there a couple of days a week helping them to use the OSGi specifications on the Ericsson ebox. This was not an easy task because there were virtually no Java programmers and lots of native Linux device driver developers. These guys have it in their genes to see anything between them and the Linux API as a personal insult. The fact that the ebox was severely underpowered for Java, 25Mhz 486 - 32Mb RAM - 8Mb flash, did obviously not do anything for my popularity either. However, these guys are intelligent and once they understood the modularity model and the remote management model that this enabled, they decided that they wanted to have it too. well, not the Java but the modularity. They even had visions to replace the OSGi specifications with something more native.I objected to that model, and I still do. Though I am all too aware of the many flaws that the language was born with (I am a Smalltalker by heart, how could they miss closures!), I am profoundly impressed with what has been done on security and the abstraction of the the operating system. The OSGi technology provides some very crucial missing parts in Java, but a very large number of the features we provide are enabled by Java. I really do not believe that what is done in the modularity layer, the life cycle management layer, the service layer, and the security model can be done in any other existing environment. Not even .NET, though they get closest.
However, the need for integrating with native code does not go away because our model is better. The battlefield is littered with corpses that had a better model. It is a plain fact that in many of the markets that use OSGi technology, native code integration plays a major role. Java is good, but there is a lot of legacy code out there that is just not Java.
The only thing we have on offer for native code integration is through the Java Native Interface (JNI) and remote procedure calls like with web services, CORBA, etc. Anybody that tried to program with JNI knows how painful and intrusive it can be. I do not think I would have survived Linkoping proposing JNI. Remote procedure calls are better, and well known in the industry. However, remote procedure calls provide interoperation but no modularity, life cycle, or security. The interoperation through remote procedure calls works well as is proven many times, it lacks the tight integration of all important computing aspects that the OSGi technology provides.
Meet Universal OSGi. This is not a worked out concept but work in progress. Universal OSGi is an attempt to use the normal run of the mill Java based OSGi service platform but provide a model where native code can be integrated. This means that you should be able to download bundles with a native executable, like a DLL or shared library. Lets call these native bundles.
You should be able to express the dependencies of these native bundles in the manifest on other native bundles so that a management system could calculate the transitive dependencies, just like a Java bundle. Then you should be able to start and stop these bundles, which should result in loading the native code in another process and providing it with its dependencies, and starting it. The native code should be able to get and register services which are used by the native code to communicate with the rest of the system.
Handling the native code dependencies and the life cycle issues is not trivial but definitely doable. A native handler bundle can use the extender model to detect native bundles of a type it recognizes. This bundle would somehow have to interact with the resolver because the Java resolver needs to know when a native bundle can be resolved (or maybe this could be expressed with Require-Bundle). If the native bundle is started, the native handler will load the native code in another process. When the native bundle is stopped, the native handler cleans up by killing the process. Not trivial, but doable.
The hard part is the communication aspect. Obviously, the service layer is the crucial middle man, requiring that the native code can communicate with the OSGi service registry, hosted in the Java VM process. This requires a native API that maps the primitives of the OSGi service registry to C, C++, .NET, PHP, Haskell, etc. Primitives like registering a service, getting a service, and listening for services. And of course coupled to the life cycle layer. If a bundle is stopped, all its services must be unregistered. This registry is still doable, albeit a bit less trivial. The hardest part is how the services are mapped in the remote procedure calls. This is the problem that many have tried and few really succeeded because it somehow always remains messy. CORBA has the Interface Definition Language (IDL) which was supposed to be the mother of all languages but largely failed in the Java world because its C++ orientation made mapping it to Java painful. I remember a long ago project where we had two class for every parameter because that was the way output parameters could be modeled, a concept well known to C++ but unkown to Java.
For Universal OSGi, it is likely that the best solution is the Java interface as an "IDL". Not only do we already have a lot of experience with Java interfaces, they are also conceptually very clean, not associated with an implementation. In Java it is already trivial to proxy interfaces. it will therefore be necessary to map Java interfaces in a mechanical way to concepts known in the native environment. For example, in C++ a Java interface can be mapped to an abstract base class that can be used as mixin. Most OSGi service specifications are very suitable for this mapping.
A key problem in designing such a communication system is how the remote procedure calls are handled. A remote procedure call crosses the process boundary and pointers to memory locations are therefore no longer valid. Each process has its own memory. There are two solutions to this problem. One can pass the value to which the pointer is pointing, or one can pass a symbolic reference of the object. Passing a value can be done with immutable objects like int, String, etc. but it can not be done for complex objects like java.lang.Class. If a mutable object is passed by value, changes on the remote side are not reflected on the caller's side, changing the behavior for remote and local calling. However, one can proxy any complex object by passing a symbolic reference and doing the same for any objects that are exchanged in method calls. The other side must recognize this reference and do a remote procedure call back into the caller's process for all methods. This model is called proxying. It is too expensive for real life communications due to the latency and bandwidth constraints. For Universal OSGi it might be viable because it runs all the participants on the same device. That allows all communications tobe done with very fast techniques like shared memory.
These are intriguing and exciting ideas that could truly make OSGi technology more universally applicable. However, there are a lot of technical details to iron out and even when that has been done, there is a lot of spec work for different native languages. We need members that are willing to make this work. Interested?
Peter Kriens
Subscribe to:
Posts (Atom)