> All of this is my understanding and I may be wrong, so please correct me > if I'm wrong. I'm right, could adding an oak-core-api with independent > lifecycle solve the situation?
While this may be possible, an arguably simpler solution would be to give oak-run and oak-upgrade a separate lifecycle. They are consumers of both segment-tar and oak-core (+ other bundles with same release cycle). Hence they require interoperable releases of both *before* they themselves can be released. The other alternative, as Thomas mentioned, is to release everything at once, including segment-tar. Regards Julian On Fri, Oct 21, 2016 at 12:46 PM, Davide Giannella <[email protected]> wrote: > Hello team, > > while integrating Oak with segment-tar in other products, I'm facing > quite a struggle with a sort-of circular dependencies. We have > segment-tar that depends on oak-core and then we have tools like oak-run > or oak-upgrade which depends on both oak-core and segment-tar. > > this may not be an issue but in case of changes in the API, like for > 1.5.12 we have the following situation. 1.5.12 has been released with > segment-tar 0.0.14 but this mix doesn't actually work on OSGi > environment as of API changes. On the other hand, in order to release > 0.0.16 we need oak-core 1.5.12 with the changes. > > Now oak-run and other tools may fail, or at least be in an unknown > situation. > > All of this is my understanding and I may be wrong, so please correct me > if I'm wrong. I'm right, could adding an oak-core-api with independent > lifecycle solve the situation? > > Davide > >
