What is a better packaging practice?

[Sahoo <sa...@sun.com>]

I have a question with regards to packaging of bundles. Let's say a 
product consists of two modules, viz: A and B. The two modules 
communicate with each other using well defined APIs. The dependency is 
such that A statically depends on B's API and B statically depends on 
A's API. To solve the circular dependency problem at build time, we 
separate the APIs from implementations at build time. So we end up 
having 4 jar files, viz: A_api.jar, A_impl.jar, B_api.jar and 
B_impl.jar. When it comes to making bundles, there are two obvious choices:
1. Each of those 4 jars represent a bundle.
2. Merge API jar with corresponding impl jar to produce a single bundle. 
This way, we end up having two bundles: A.jar and B.jar. OSGi runtime 
can take care of circular dependency quite easily.

What is advisable? I would appreciate you sharing your views on this.

I definitely prefer option #2, because option #1 seems so artificial to 
me. After all, what's the use of a bundle like A_api.jar which can't be 
used in any meaningful way but compilation? From a bundle repository's 
(say OBR's) point of view also, option #2 is preferred, isn't it? If we 
choose option #1, then the repository will think B_impl's dependency can 
be satisfied by A_api, but actually that's not the case.

Thanks,
Sahoo

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: What is a better packaging practice?

[Stevens Gestin <sg...@gmail.com>]

Hi,

I think the best way is to refactor your packages avoiding circular
references. This is generally due to a bad architecture.

Best Regards,
Stevens

On Thu, Jul 31, 2008 at 9:19 AM, Sahoo <sa...@sun.com> wrote:

> I have a question with regards to packaging of bundles. Let's say a product
> consists of two modules, viz: A and B. The two modules communicate with each
> other using well defined APIs. The dependency is such that A statically
> depends on B's API and B statically depends on A's API. To solve the
> circular dependency problem at build time, we separate the APIs from
> implementations at build time. So we end up having 4 jar files, viz:
> A_api.jar, A_impl.jar, B_api.jar and B_impl.jar. When it comes to making
> bundles, there are two obvious choices:
> 1. Each of those 4 jars represent a bundle.
> 2. Merge API jar with corresponding impl jar to produce a single bundle.
> This way, we end up having two bundles: A.jar and B.jar. OSGi runtime can
> take care of circular dependency quite easily.
>
> What is advisable? I would appreciate you sharing your views on this.
>
> I definitely prefer option #2, because option #1 seems so artificial to me.
> After all, what's the use of a bundle like A_api.jar which can't be used in
> any meaningful way but compilation? From a bundle repository's (say OBR's)
> point of view also, option #2 is preferred, isn't it? If we choose option
> #1, then the repository will think B_impl's dependency can be satisfied by
> A_api, but actually that's not the case.
>
> Thanks,
> Sahoo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>


-- 
Le respect commence par celui de l'environnement

Re: What is a better packaging practice?

["Richard S. Hall" <he...@ungoverned.org>]

Sahoo wrote:
> I have a question with regards to packaging of bundles. Let's say a 
> product consists of two modules, viz: A and B. The two modules 
> communicate with each other using well defined APIs. The dependency is 
> such that A statically depends on B's API and B statically depends on 
> A's API. To solve the circular dependency problem at build time, we 
> separate the APIs from implementations at build time. So we end up 
> having 4 jar files, viz: A_api.jar, A_impl.jar, B_api.jar and 
> B_impl.jar. When it comes to making bundles, there are two obvious 
> choices:
> 1. Each of those 4 jars represent a bundle.
> 2. Merge API jar with corresponding impl jar to produce a single 
> bundle. This way, we end up having two bundles: A.jar and B.jar. OSGi 
> runtime can take care of circular dependency quite easily.
>
> What is advisable? I would appreciate you sharing your views on this.
>
> I definitely prefer option #2, because option #1 seems so artificial 
> to me. After all, what's the use of a bundle like A_api.jar which 
> can't be used in any meaningful way but compilation? From a bundle 
> repository's (say OBR's) point of view also, option #2 is preferred, 
> isn't it? If we choose option #1, then the repository will think 
> B_impl's dependency can be satisfied by A_api, but actually that's not 
> the case.

Like Karl, I was also going to point to the FAQ entry. If this entry is 
missing something, please help us update it.

To answer your first question it just depends and Marcel and the FAQ 
entry do a good job of explaining those different issues. I don't think 
there is one single answer.

To answer your second question, it doesn't really make a difference to 
OBR either depending on how you model your dependencies. For example, if 
the API was a service interface, then the API bundle would only export 
the packages, but it would not provide a service. Only the impl bundle 
would provide a service. Thus a client would depend not only on the API, 
but also on the service. Which means when resolving that client, OBR 
would need to pull in both the API bundle and the impl bundle.

If you are not using services, then you can create your own capability 
that your impl can provide that the API bundle would not.

-> richard

>
> Thanks,
> Sahoo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: What is a better packaging practice?

[Karl Pauls <ka...@gmail.com>]

There is an faq entry on this one as well I think:

http://felix.apache.org/site/apache-felix-osgi-faq.html

regards,

Karl

On Thu, Jul 31, 2008 at 10:31 AM, Marcel Offermans
<ma...@luminis.nl> wrote:
> On Jul 31, 2008, at 9:19 , Sahoo wrote:
>
>> I have a question with regards to packaging of bundles. Let's say a
>> product consists of two modules, viz: A and B. The two modules communicate
>> with each other using well defined APIs. The dependency is such that A
>> statically depends on B's API and B statically depends on A's API. To solve
>> the circular dependency problem at build time, we separate the APIs from
>> implementations at build time. So we end up having 4 jar files, viz:
>> A_api.jar, A_impl.jar, B_api.jar and B_impl.jar. When it comes to making
>> bundles, there are two obvious choices:
>> 1. Each of those 4 jars represent a bundle.
>> 2. Merge API jar with corresponding impl jar to produce a single bundle.
>> This way, we end up having two bundles: A.jar and B.jar. OSGi runtime can
>> take care of circular dependency quite easily.
>>
>> What is advisable? I would appreciate you sharing your views on this.
>
> I'd prefer to answer this question in a broader context, because in general
> there are a few things you can consider and this is definitely no black and
> white answer. In general there are a couple of things to consider, such as
> which bundles are you actually going to update together, what's the rate of
> change of the various bundles, are you going to have many bundles that
> implement the same service (#2 gives you more overhead then) and finally
> maybe some technical issues to consider (such as when you do the update, how
> many other bundles will be affected, because of the dependency graph and
> required refresh).
>
> First I want to introduce a third option, which is a variation on #1:
>
> 3. Merge all API jars into one (or a few) bundle(s).
>
> Motivation: if the API's you use don't change that much, and are usually
> used together, because for example they define the application domain, then
> looking at one criteria for bundling (rate of change), it makes sense to
> deploy them together.
>
> If you're building an application server that is used by many users in many
> different ways, you might not even be able to come up with really good
> answers to these questions for all use cases (or the answers might differ
> based on the use cases) so your end users (the application developers) might
> want to package the components in a different way that suits them better.
> This type of flexibility is something that is poorly supported by current
> build systems (especially maven is really a PITA if you decide to completely
> change your packaging strategy in the middle of a big project).
>
>> From a bundle repository's (say OBR's) point of view also, option #2 is
>> preferred, isn't it? If we choose option #1, then the repository will think
>> B_impl's dependency can be satisfied by A_api, but actually that's not the
>> case.
>
> OBR might conclude that all package dependencies are resolved, but I would
> be very careful in concluding that if package dependencies are resolved that
> the whole application is "should work". You need to specify the same
> requirements and capabilities on at least the service dependency level too
> (and maybe even other types of dependencies).
>
> In fact, this is food for an entirely different discussion about what
> actually is the best way to "materialize" "applications" in an OSGi context.
>
> Greetings, Marcel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>



-- 
Karl Pauls
karlpauls@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: What is a better packaging practice?

[Marcel Offermans <ma...@luminis.nl>]

On Jul 31, 2008, at 9:19 , Sahoo wrote:

> I have a question with regards to packaging of bundles. Let's say a  
> product consists of two modules, viz: A and B. The two modules  
> communicate with each other using well defined APIs. The dependency  
> is such that A statically depends on B's API and B statically  
> depends on A's API. To solve the circular dependency problem at  
> build time, we separate the APIs from implementations at build time.  
> So we end up having 4 jar files, viz: A_api.jar, A_impl.jar,  
> B_api.jar and B_impl.jar. When it comes to making bundles, there are  
> two obvious choices:
> 1. Each of those 4 jars represent a bundle.
> 2. Merge API jar with corresponding impl jar to produce a single  
> bundle. This way, we end up having two bundles: A.jar and B.jar.  
> OSGi runtime can take care of circular dependency quite easily.
>
> What is advisable? I would appreciate you sharing your views on this.

I'd prefer to answer this question in a broader context, because in  
general there are a few things you can consider and this is definitely  
no black and white answer. In general there are a couple of things to  
consider, such as which bundles are you actually going to update  
together, what's the rate of change of the various bundles, are you  
going to have many bundles that implement the same service (#2 gives  
you more overhead then) and finally maybe some technical issues to  
consider (such as when you do the update, how many other bundles will  
be affected, because of the dependency graph and required refresh).

First I want to introduce a third option, which is a variation on #1:

3. Merge all API jars into one (or a few) bundle(s).

Motivation: if the API's you use don't change that much, and are  
usually used together, because for example they define the application  
domain, then looking at one criteria for bundling (rate of change), it  
makes sense to deploy them together.

If you're building an application server that is used by many users in  
many different ways, you might not even be able to come up with really  
good answers to these questions for all use cases (or the answers  
might differ based on the use cases) so your end users (the  
application developers) might want to package the components in a  
different way that suits them better. This type of flexibility is  
something that is poorly supported by current build systems  
(especially maven is really a PITA if you decide to completely change  
your packaging strategy in the middle of a big project).

> From a bundle repository's (say OBR's) point of view also, option #2  
> is preferred, isn't it? If we choose option #1, then the repository  
> will think B_impl's dependency can be satisfied by A_api, but  
> actually that's not the case.

OBR might conclude that all package dependencies are resolved, but I  
would be very careful in concluding that if package dependencies are  
resolved that the whole application is "should work". You need to  
specify the same requirements and capabilities on at least the service  
dependency level too (and maybe even other types of dependencies).

In fact, this is food for an entirely different discussion about what  
actually is the best way to "materialize" "applications" in an OSGi  
context.

Greetings, Marcel


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org