Introduction
Background
This project grew out of a proposal on this mailing list thread started by Harald Wellmann in January 2012 titled: Pax Tipi: A third-party bundle repository.
A number of discussion participants, including fellows of ServiceMix and Eclipse' EBR concluded that something like Tipi is a worthwhile idea.
Interaction with original projects
Before starting a new Pax Tipi subproject for a given third-party library, you should always contact the original developers and kindly ask them to osgify their artifacts, offering to submit a patch or a pull request.
Only if this has no effect, use Pax Tipi to wrap and redistribute the given artifacts.
On the fly bundling
The pros and cons of pre-packaging vs. on-the-flying bundling have been discussed on the mailing list. For ease of use and to guarantee immutability, pre-packaging is the preferred approach.
Licensing
As a general rule, OPS4J projects are released under the Apache Software License v2.
To avoid license conflicts for repackaged distributions of non-ASL third-party libraries, Pax Tipi adopts the following licensing policy:
Each repackaged artifact shall be released under the license of the original project.
Any additions of Pax Tipi to the original projects shall be dual licensed under the Apache Software License v2 and the original license.
Classification
TODO: Classify Pax Tipi artifacts regarding explicit OSGi support or known problems under OSGi.
Source Repository & Release Strategy
Outline:
One source repository org.ops4j.pax.tipi on GitHub.
One subdirectory for each repackaged third-party library version.
Pax Tipi is never released as a whole. Each new subdirectory is released separately.
Additional Features
Eclipse Source Bundles
Each released bundle shall have a source JAR attached. For the benefit of Eclipse users, the source JAR shall be an Eclipse source bundle. This requires nothing but a few additional manifest headers.
OBR
TODO: Can Pax Tipi provide an OBR?
P2
TODO: Can Pax Tipi act as a P2 repository/Eclipse Update Site?