Hi, > could adding an oak-core-api with independent lifecycle solve the >situation?
"All problems in computer science can be solved by another level of indirection" I would prefer if we get oak-segment-tar in line with the rest of oak (release it at the same time and so on). I understand, there are some disadvantages. But I think all alternatives also have disadvantages. Regards, Thomas On 21/10/16 12:46, "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 > >
