Deploying to Package Drone with Maven Tycho
Join the DZone community and get the full member experience.Join For Free
this article is a sneak peek into deploying osgi artifacts from a maven tycho build directly into package drone .
installation and setup
the first thing is to setup up an instance of package drone. in short you will need a linux machine, a mysql instance and java 8. there already are a few pages in the wiki of package drone, so this article will focus on the actual deployment process:
there also is a video on youtube on how to perform the initial configuration.
creating and configuring a channel
the first thing which is required is a new channel. got the "channels" view (from the top menu) and click "create channel".
this will create an unnamed channel. which can then be given a name using "edit channel".
for this tutorial we will use
as channel name. the id of the channel will be different since it is generated automatically.
channels are mostly only a container for artifacts (blobs) and can be extended with functionality by adding "aspects".
go to "edit" -> "configure aspects" and add the following aspects:
- hasher – create hashes of the blob
- mime – extract the mime type
- osgi – extract osgi meta data
- p2 repository – create information for p2
since the channel is still empty, there will be no visible difference to the state before.
the next step is to add "deploy keys". so instead of re-using the users credentials, package drone uses "deploy keys" to authenticate applications which want to deploy content to the repository. the idea is to create a deploy group, which contains one are more deploy keys. the deploy groups get assigned to channel, so all keys in the assigned groups are allowed to deploy to these channels. if a deploy key gets compromised, it can easily be removed from the group, and replaced by a different one, without the requirement to re-configure all channels.
switching to the tab "deploy keys" allows you do configure the deploy groups/keys for this channel. initially there is none, so you need to create at least one.
once it is created it can be added to the channel in the same screen as before. clicking on the key (the element on right side) will pop up a dialog with the maven deploy settings. the password which has to be used in the actual deployment is present in the <password> tag.
it is also possible to click in the deploy group (on the left side) and get a full list of all deploy keys for this group.
building and deploying
so instead of creating a creating a full maven tycho project in this article, we will re-use one of the demo projects provided by maven tycho in their repositories and deploy them to package drone using the maven option "
first of course, we need to fetch the source code of the demo projects using "
" from the command line:
git clone http://git.eclipse.org/gitroot/tycho/org.eclipse.tycho-demo.git
this will check out a few samples projects, and we will use "
" for this step. building and deploying is easy a changing into the right directory and issuing "mvn deploy" with the correct parameters. since we don't want to change to demo project's "
", we will use the maven property "
", specified on the command line. for more information on this property see .
the important part of this property is the server url. since maven deploy uses basic http authentication, it is possible to provided the deploy key from package drone in the form of username:password, directly in the url:
where "deploy-key" of course is the deploy key from package drone (the one from the <password> element in the previous section), not the id of the deploy key and not the term "deploy-key" ;-) so the key used in the next command (a06b637e…) will not work on your setup, since your server will create a different key and you have to replace it with one of your keys (see the previous section).
cd org.eclipse.tycho-demo/itp01 mvn deploy -daltdeploymentrepository=pdrone::default::http://deploy:a06b637e55a75d501d879c09079d189a796208cbd6d220395df4c5749e42f88f@localhost:8080/maven/maven1
so after a while of download, building and uploading, maven should finish with "build success" and looking back into the channel, you should see a few artifacts. basically this what maven uploaded and package drone stored it it as is. peeking into the "details" of one ".jar" artifact, you will see that package drone extracted the osgi meta data during the upload process, and checking out the view "osgi" -> "bundles" will give you a nicer overview of osgi related artifacts. please note that the osgi view will only be visible when the "osgi" aspect was added to the channel.
since we also added the "p2 repository" aspect earlier, it is possible to follow the "p2 repository" link, directly to the p2 repository adapter of this channel. looking into the
will give you the same meta data that tycho generated and uploaded.
note: this scenario re-uses the p2 meta data which was generated by maven tycho during the build process. it got uploaded and will be re-assembled as a complete p2 repository. however it also is possible to let package drone drop the tycho meta data during upload and create its own version. this is useful if you also want to upload artifacts from non-maven tycho build, where p2 meta data is not being generated and uploaded during the build. but this setup might be part of a follow up article.
accessing the channel using p2
after the artifacts got uploaded to the channel these can be accessed by and p2 compatible software (like eclipse pde or maven tycho). the entry point for the p2 adapter is
where "channel" is either the channel id or name ("maven1" in this case).
if course, in the current there is no eclipse feature or category present. this is why the eclipse p2 dialog will not find anything in that repository. but this is a limitation of the dialog itself. all p2 tools will be able to pull out the bundle
so the next step would be to add an eclipse feature to the maven tycho build and deploy it together with the bundle, or create another bundle, depending on "tycho.demo.itp01" and configuring maven tycho to resolve from
for the build.
Opinions expressed by DZone contributors are their own.
IDE Changing as Fast as Cloud Native
DevOps in Legacy Systems
SeaweedFS vs. JuiceFS Design and Features
Core Knowledge-Based Learning: Tips for Programmers To Stay Up-To-Date With Technology and Learn Faster