A library to provide a true P2 repository view on Maven repositories
This project started to fill the gap between Tycho-based Eclipse RCP builds and the need for P2 repositories in a high-frequent read and write environment.
In such an environment one typically builds and deploys Maven artifacts but also OSGi artifacts to a central - commonly internal - artifact repository. There are tools that create P2 repositories out of the common Maven repositories, so that they can be consumed by Eclipse RCP developers.
Anyway in an environment with thousands of reads and writes - potentially concurrent - to such P2 repositories, lead to different challenges that must be tackled:
- Provide sophisticated locking mechanisms due to concurrent read and write access
- Treat multiple writes (inserts) of logically grouped features as atomic operations
- Guarantee consistency even for partially deployed artifacts
- Avoid blocking to not slow down read and write access
This library should be used when developing Eclipse RCP plugins, features or extensions and an in-house artifact repository - such as Nexus - is already used to store generated artifacts:
- Artifact repository (currently only Sonatype Nexus 2.x) internally available
- High-frequent parallel read and write operations to the repository
- Local build system already generates necessary metadata files (afaik only Tycho, probably also Buildship)
- Using Eclipse features as unit of deployments and not single plugins
- In-memory P2 view on existing Maven repositories - no copies or links of existing artifacts will be created
- Metadata files (artifacts.xml and content.xml) built upon existing artifacts (generated by Tycho)
- Metadata files only updated when all plugins of an feature have been inserted
- Metadata updates on both files in one atomic transaction
- Asynchronous & non-blocking metadata generation
- Available repository extensions: ** Sonatype Nexus 2.x
- Reporting based on kamon.io
- Support for bundle root files
- Persistent actor state for restarts
- Future repository extensions: ** Sonatype Nexus 3.x ** JFrog Artifactory ?.?
Since the repositories are also internally identified by its id, this must follow the actor naming convention.
The Scala API for the Maven-P2-View is fully asynchronous API internally calling the actor system. Every function - except the main entry point - returns a future.
import io.coding.me.m2p2.api._
// initial list of files in the repository
val files = ...
// create the view system, main entry point, should be unqiue within the JVM
val view = View()
// create repository
val repoFuture = view.create("snapshots")
repoFuture.andThen{ repo ->
repo.rebuild(files)
}.andThen{ metadata ->
}
![Actor System](http://g.gravizo.com/g? digraph G { node [ fontname=Helvetica, fontsize=16]; router[shape=box, label="Repository Router"]; rr1[label="Repository\nReceptionist\n(Repo 1)"]; rr2[label="Repository\nReceptionist\n(Repo n)"]; router -> {rr1, rr2}; mg[label="Metadata Generator"]; mgu[label="Metadata Updater"]; mgr[label="Metadata Rebuilder"]; mg -> {mgu, mgr}; ic[label="Artifact Collector"]; ici[label="Insert Artifact Collector"]; icd[label="Delete Artifact Collector"]; rr1 -> {ic, mg}; ic -> {ici, icd}; aa1[label="Artifact\nAnalyzer", fontsize=12]; aa2[label="Artifact\nAnalyzer", fontsize=12]; aa3[label="Artifact\nAnalyzer", fontsize=12]; aa4[label="Artifact\nAnalyzer", fontsize=12]; aa5[label="Artifact\nAnalyzer", fontsize=12]; aa6[label="Artifact\nAnalyzer", fontsize=12]; ici -> {aa1, aa2, aa3}; icd -> {aa4, aa5, aa6}; } )
The Repository Router is the main entry point for the actor system. He keeps track of the created and deleted repositories and for the rest he forwards messages to the appropriate repositories.
The Repository Receptionists are responsible for exactly one view on a Maven repository. The hold the P2 metadata and statistical information, and - most important - they manage the concurrent read and write access. Beside that the delegate all compute intensive task to their child actors.
- Klaus: for discussing actor systems on a whiteboard
- Stephan: for discussing about reactive systems in general
- Stefan (another one): for his fundamental knowledge about Eclipse RCP
- Juergen: for the deep knowledge about Eclipse and build tools
- Rainer: for the deep review discussions and the 5 why's