compile-only and "library" like bundle

[Clément Delgrange]

Hi,

The EnRoute directive "compile-only" leads to have a clean separation between API and Provider bundles but with the cost to be not able to build kinds of "Library" bundles. Example :

• API Bundle A : defines some services interface and  some constants (enum).
• Provider Bundle B: implements a service and export the API.
• Library Bundle C: implements something (no service : classic factory, builder or new operator), uses the constants and export the API.
• Consumer bundle D: uses a service and so imports the API and needs bundle C and so imports it. 

In this case, I have a split package in my bundle D (comes from bundle A and C), what are my best options :

1. Merge.
2. Do not create "Library" bundle, it's a poor design. But in this case how to deal with cases where the implementation is really important, like when you need a LinkedList, you don't want to rely on a constant string that identifies an implementation and then filter a DS reference with the target, no ?
3. My import and export are not correct !
4. Other...  

Thank you for your help.

Clement.

[Timothy Ward]

Hi Clément,

I would say first and foremost *never* make a split package. All bundles that contain a package must contain the *whole* package, and there will definitely be a problem if your library if it tries to add types to the API package. Note that it is *not* a split package if two bundles both contain the whole package, and this situation is perfectly fine.

In this scenario the Library bundle must export the package(s) for what it provides (either the package for the factory class, or the package for the type that gets newed up). The important thing is that as far as the library is concerned, the “implementation” class is API. If the library API is coupled to the service API (i.e. receives or returns types from the API package) then it must also express a uses constraint on the service API package when it is exported. Bnd will correctly generate this constraint for you unless you deliberately override it (please don’t ever override it!).

The result should be that Bundle D imports the API package and the library implementation package. Ideally the library and the API bundle will substitutably export the API package (i.e. both export and import it). Substitutable exports are the default behaviour in bnd.

In a system with substitutable imports the wiring will work, with uses constraints ensuring that the API is shared in a valid way.

I hope this helps.

Regards,

Tim

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Clément Delgrange]

Hi Tim,

Thanks for your reply. My library do not add types to the API package but I still get a package split warning ! List of exported package:

• API Bundle A : a.b.c ; a.b.d ; a.b.e
• Provider Bundle B: a.b.c ; a.b.d ; a.b.e (not added types to this package, impls are in a.s.r)
• Library Bundle C: a.b.c ; a.b.d (not added types to this package, impls are in a.q.r)
• Consumer bundle D: -> split package for : a.b.c ; a.b.d (this 2 contains the same things and come from API)

Maybe I missed something...

[Clément Delgrange]

Hum ! 

 Sorry I've made a mistake with my explanation. It is not the consumer Bundle where I get a warning but the Provider bundle that needs the library. And the warning arises when the provider export the api.

[Raymond Auge]

If you are designing this system from a clean slate, never deliberately export the same packages from different bundles!

Here's what I think a clean design would look like:

• API A
  Export-Package: a.b.c, a.b.d, a.b.e
  Import-Package: none
  
  
• Provider B:
  Export-Package: none (assuming a.s.r just provides services)
  Import-Package: a.b.c, a.b.d, a.b.e (let bnd figure this out)
  
  
• Library C:
  Export-Package: a.q.r
  Import-Package: a.b.c, a.b.d (let bnd figure this out)
  
  
• Consumer D:
  Export-Package: none
  Import-Package: a.b.c, a.b.d, a.q.r (let bnd figure this out)

HTH,

- Ray

--

You received this message because you are subscribed to the Google Groups "bndtools-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)