Another issue that is worth considering (and yet another reason to
separate into api and impl) is that due to osgi resolution
requirements if you put your impl in the same bundle as the api this
effectively requires client code to resolve bundles that your impl
uses but they may have no need of using.
Hmm, these client bundles are only bound to the package. Most API code
has
no (or at least few) uses clauses. This is the beauty of package
import, you
might be wired to an actual bundle but you never know nor care.
Consider if you have an api com.foo and an impl of foo that imports
com.bar. If client code wishes to use com.foo in the case where
there is only one bundle they also need to resolve com.bar to use
classes com.foo Even worse if com.bar imports com.baz...the spider
web can get very large and very sticky very quickly...
Huh? If only com.bar is present than these dependencies exist anyway?
A:
Import-Package: com.foo
B:
Export-Package: com.foo
Import-Package: com.bar, com.baz
A will resolve to B. B has dependencies that are required to implement
com.foo. If I take
implementation C:
C:
Export-Package: com.foo
Import-Package: com.bzz
I will get different dependencies, but A remains oblivious of all
this. Obviously, if you
use Require-Bundle you are out of luck ... but that is a bad pattern
anyway.
As usual, I seem to be contrarian :-( , but I fail to see what the
problem is in packaging
API in bundles?
Kind regards,
Peter Kriens
On 2 jun 2008, at 17:35, David Savage wrote:
Hi All,
Leaping on this thread as it's something I've had a lot of
experience unpicking and wouldn't want others to have same pain.
Another issue that is worth considering (and yet another reason to
separate into api and impl) is that due to osgi resolution
requirements if you put your impl in the same bundle as the api this
effectively requires client code to resolve bundles that your impl
uses but they may have no need of using.
This can rapidly get out of control and in the worst case a client
needs to import a much larger set of bundles to use a client api
than would otherwise be needed.
Consider if you have an api com.foo and an impl of foo that imports
com.bar. If client code wishes to use com.foo in the case where
there is only one bundle they also need to resolve com.bar to use
classes com.foo Even worse if com.bar imports com.baz...the spider
web can get very large and very sticky very quickly...
Save your clients time and separate early - you and they will thank
you a million times over for it in the end.
But agree with sentiment of use common sense consider who the end
users of the api are - if it's just internal it's sometimes ok to
bend the rules - just be aware of the consequences...
Regards,
Dave.
Mirko Jahn wrote:
Here I agree with Jeff. Separating API and implementation on package
level is crucial on several different ways. Not only is it a cleaner
design, it also gives you the chance to later refactor your code and
move the implementation into a new bundle very easily (if you haven't
done so already).
The question on using different bundles for api/spi/implementation or
not is hard to answer in a general manner. I usually ask myself, who
is going to use it, how frequently and how likely is it, that there
will be several implementations. If it is just internally used, not a
major service and not likely to have different implementations, why
should I create a (and maintain) a completely different bundle with
maybe just one or two classes in it? I think, it is a mixture of
common sense and experiences, but if I'm in doubt, I don't separate
them. Refactoring is your friend and if the application is done
right,
it is no problem at all. Just remember to use version ranges on
package dependencies and package versioning according to the OSGi
Spec.
Cheers,
Mirko
On Mon, Jun 2, 2008 at 3:29 PM, Toni Menzel <[EMAIL PROTECTED]>
wrote:
You should put API and implementation into separate bundles.
This decouples the specification (api) from one or even multiple
implementations and allows implementation changes without
restarting the framework (the osgi way).
When it comes to exporting, well you just export what you either
really want to export (usually just api/spi stuff) or you imported
yourself (known as package substitution).
There are hardly reasons to include the api into the
implementation's bundle.
Instead you must be aware of class loading issues if you expose
services.
"Do you even recommend to separate API and SPI on package level?"
yes. same as above. (separation of concerns).
/Toni
-------- Original-Nachricht --------
Datum: Mon, 2 Jun 2008 15:06:39 +0200
Von: "Peter Niederwieser" <[EMAIL PROTECTED]>
An: osgi-dev@mail.osgi.org
Betreff: [osgi-dev] Put API/SPI/implementation into separate
bundles?
When building an OSGi-based system, do you recommend to put a
component's API/SPI/implementation into separate bundles, or is it
good enough to put them into separate packages (exporting only
API and
SPI)? Has the "separate bundle" approach advantages when it comes
to
updating/replacing bundles at runtime? Do you even recommend to
separate API and SPI on package level?
Cheers,
Peter Niederwieser
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________________________________
This email has been scanned by both Message Labs and Paremus
internal systems for viruses and inappropriate attachments. Email
suspected of carrying a virus payload or inappropriate attachment
will not be delivered to you, and the sender will receive an
appropriate warning notice.
_______________________________________________________________________
_______________________________________________________________________
Paremus Limited. Registered in England
No. 4181472
Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA
Postal Address: 107-111 Fleet Street, London, EC4A 2AB
The information transmitted is intended only for the person(s) or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or
other use of, or taking of any action in reliance upon, this
information by persons or entities other than the intended recipient
is prohibited.
If you received this in error, please contact the sender and delete
the material from any computer.
_______________________________________________________________________
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
