Over time, OSGi has become a very important part of the Eclipse technology stack. For instance, it enables Eclipse SCADA to be configured at runtime as well as providing the possibility to deploy bug-fixes while the SCADA applications are running. During this time we also improved our build process. Nevertheless bridging the worlds between Maven, Tycho, Eclipse PDE and other tools like BND is still a major pain point. A big missing puzzle piece was a software artifact repository where OSGi bundles are first class citizens. Each of the existing repositories have Maven in mind, OSGi is only an afterthought. To solve this, we developed Package Drone, an OSGi first software artifact repository.
The scope of this project is to create an open source, OSGi based, web enabled repository for software artifacts with special considerations for the necessities of OSGi bundles and its metadata. It is however not limited to the specific use case of OSGi bundles, but also provides extension points to allow for other artifacts and repository formats like DEB/APT and RPM/YUM.
- Storing and serving software artifacts (support for Maven Tycho deployments, manually uploaded OSGi bundles)
- Extracting metadata and aggregating information of these (e.g. to provide automatically generated features)
- Providing a local developer workflow (channels can be created for specific releases and made public when they are finished)
- Allowing extensions to the system to also support other software artifact and repository formats (automatic provision of P2 or R5 repositories)
- Provide a Web UI and build a foundation to support an OSGi enabled Web UI
The focus is not on recreating every feature which already exists in other repositories, but to focus on flexibility in providing different views on the same existing artifacts. Additional functionality like seraching bundles by exported packages would be a very good extension, but is not planned as part of the core project.
Package Drone is a software artifact repository where OSGi bundles are first class citizens. The basic idea is, that through some process, be it a build or some manual upload, OSGi bundles get deployed to the repository. This can be restricted to specific named channels. In that way it is possible to tweak the code and the build process to a point where the developers are satisfied with the state of the channel and then it can be made public (e.g. a release). That means for a user of such a channel, it will always have a consistent state, and its not only half there because some build broke in the middle. Metadata to the artifacts can be deployed and will be stored alongside the artifacts (e.g. maven checksum files), alternatively they can also be either extracted from the uploaded artifacts (e.g. OSGi bundle name, file size, ...) or created automatically (e.g. checksums) through a so called channel aspect.
On the other side, artifacts can be consumed by other parties. That could be a build process, but it also could be the Eclipse IDE in the shape of a software site. Package Drone provides different views on its stored artifacts. So the same bundles can be provided as repositories of different formats: P2, OSGi R5 or even as apt or rpm repositories. Through its extensible nature it is easily possible to support other formats as well.
Package Drone can for instance jump in the gap in the beginning of a software project, where you might already have some software developed but the whole deployment process is not finished. Lets say you want to provide one or more bundles for testing, then with Package Drone you just throw it into a channel and any interested party can use it as an Eclipse update site.
Or you are a user of bndtools and want to use a P2 site. Thats not possible unless somebody writes a repository adapter for P2. With Package Drone you can just import an existing P2 site (or deploy to it through Maven Tycho) and have it available as a R5 repository which in turn can be used by bndtools out of the box.
Package Drone is intended for use by a local developer team, not as a central instance (like Maven Central).
Eclipse is the best home for OSGi development which also relates to Eclipse PDE, Maven Tycho and Bndtools.
Also is the current core based on Jetty, Equinox, Eclipse Link and a few others.
It could also be used within the Eclipse infrastructure to make it easy for any Eclipse project to provide its software in easy to consume form.
At the moment there is no known blocker since the project already is based on either Eclipse projects, or projects which are licensed under the Apache License.
There is one exception to this, the default JDBC connector which is currently provided is the MySQL Connector. This would have to be removed and a different default JDBC driver would be needed (e.g. H2). MySQL could still be provided as a separate download in combination with the Gemini DBAccess components of MySQL which we currently use anyway.
In addition we do use Boostrap (which already has an approved CQ, as far as I have seen), jquery (same here), Dropzone (could be removed if it should be problematic).
We did not check for a trademark on "Package Drone" though. However this should be quite a common name, so I am note sure if there are trademark issues.
The initial contribution would come right now. There are a few alpha releases and ind the next few weeks the 0.1.0 version would arrive which provides a feature set for the basic use cases.
The next features would be to:
- Provide support consumation as Maven 2 repositories (currently it can be used as a Maven 2 deployment target)
- Provide support for DEB and RPM with APT and YUM as repository format
Add method to import and export from various other repository systems
- Mirror from maven (central)
- Mirror from P2
- Export to P2 ZIP file
- Spool out to file system
- Add fine grained security