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
