Hi All,
The logic we used to have separate orbits is like below.
carbon project
|--orbit (top level orbit) : bundled 3rd party libraries with no
modifications to the source (eg: rabbitmq)
|
|--kernel/dependencies : forked non-osgi libraries used in kernel with
source code modifications (eg: axis2
On Wed, May 22, 2013 at 10:32 AM, Senaka Fernando wrote:
> Hi Nuwan,
>
> That's what's desired, but it is not what you find in practice, :). Take a
> look @ platform/dependencies and then platform/dependencies/orbit. So, you
> find things that are not inside platform/dependencies to be referenced
Hi Nuwan,
That's what's desired, but it is not what you find in practice, :). Take a
look @ platform/dependencies and then platform/dependencies/orbit. So, you
find things that are not inside platform/dependencies to be referenced
inside platform/dependencies/orbit. Such things are directly taken
Hi,
Well, platform/orbit and kernal/orbit has its meaning right. if we put some
non osgi components to kernal/dependencies we wrap it at kernal/orbit. but
top level orbit is the stuff we directly take from outside. So IMO there is
a meaning in having top level /orbit. its not confusing, its rather
Hi Miyuru,
IMHO, I see no point in having a separate orbit, so I too am +1 for this. A
separate orbit has always been a confusion, since you also find orbit
inside kernel/dependencies and platform/dependencies, making it highly
confusing for anyone who tries to understand (or explain) our SVN stru
Hi all,
What is the point of having a separate orbit? [1]
We either release kernel or platform and we don't release orbit. So any
orbit bundle which required for kernel can live inside
kernel/dependencies/orbit and platform required orbits can live inside
/platform/dependencies/orbit
[1] https:/
