Re: [osgi-dev] Best practice for defining imports and exports

[Tim Ward via osgi-dev]

The example that you’ve just given is an excellent candidate for splitting into 
two bundles. Small bundles are not a sign of bad code, just well-purposed code. 
Having the servlet in there is a smell because it’s unrelated to the actual 
purpose of the bundle (namely providing a ready service). It really looks like 
the purpose of the servlet is to be a plugin for the web console (why else 
would you use system/console in the pattern), at which point this really should 
be a separate bundle!

> So back to my question is the manually defined import still the best practice 
> (in case of the bad practice to use optionals :-) ?

Yes, you do it by putting "resolution:=optional” against the import in your bnd 
file. Then you look at it, decide it’s ugly, then refactor your bundle so that 
you don’t need the optional import any more. :-)

Tim

> On 5 Jul 2018, at 12:39, Christian Schneider  wrote:
> 
> I generally agree about optional packages in most cases I simply avoid them.
> 
> In some rare cases they are not so bad though. For example in felix system 
> ready we used it to provide a servlet if the servlet spec is available. DS 
> helps nicely with this so we did not have to handle ClassNotFoundException. 
> In this case an additional bundle seemed a bit overkill especially as the 
> code is very small at the moment.
> 
> So back to my question is the manually defined import still the best practice 
> (in case of the bad practice to use optionals :-) ?
> 
> Christian
> 
> Am Do., 5. Juli 2018 um 10:03 Uhr schrieb Tim Ward  >:
> One of the big challenges with optional imports is that they are so rarely 
> actually optional, and that they end up not being wired to you in future if 
> the dependency becomes available as a result of a later bundle installation
> 
> Every time I see an optional import it tells me that the bundle has poor 
> cohesion, and should probably be split into two bundles, one containing the 
> “optional” piece as a mandatory import. Then if you want the optional 
> behaviour you install the optional bundle, and don’t have to worry about 
> handling optional packages. 
> 
> Optional packages are also often misused as a “pluggable” mechanism where you 
> can use one of a set of libraries to provide a piece of function. In this 
> case each individual library is “optional” but you must have at least one of 
> them for your bundle to work. This results in bundles with broken metadata 
> which will resolve even when they can’t run. Again the plug point should be 
> implemented with a mandatory package dependency supplied by a bundle with a 
> mandatory dependency on one of the bundles, ideally using a service.
> 
> Even if you do have a truly optional package dependency you need to do lots 
> of error-prone reflective access with try/catch blocks, and have a 
> Dynamic-Import for it as well.
> 
> In summary, optional packages are a bad thing, and I don’t think that we 
> should be encouraging people to use them. Instead we should be encouraging 
> people to write cohesive modular bundles which therefore do not need optional 
> imports.
> 
> Best Regards,
> 
> Tim
> 
> P.S. This is the same advice that I have given for years - see from slide 30 
> of this (rather old) lightning talk 
> https://www.slideshare.net/mfrancis/when-is-optional-really-optional-tim-ward 
> 
> 
> 
>> On 5 Jul 2018, at 07:41, Christian Schneider via osgi-dev 
>> mailto:osgi-dev@mail.osgi.org>> wrote:
>> 
>> I am currently looking into improving the OSGi setup of bundles. 
>> 
>> For package exports I have found the package-info.java to be the best 
>> practice (see below):
>> 
>> @org.osgi.annotation.versioning.Version("1.0.0")
>> @org.osgi.annotation.bundle.Export
>> package my.package;
>> 
>> Imports are normally computed automatically. Some cases that still need 
>> special handling are changes in import range or optional imports.
>> 
>> Currently I use this for optional imports:
>> 
>> bnd.bnd
>> Import-Package: \
>>  javax.servlet*;resolution:=optional,\
>>  *
>> 
>> Is this still best practice or do we have something better? The 
>> maven-bundle-plugin makes imports optional if the maven dependency is 
>> optional. Is there a way to make the bnd-maven-plugin to behave in the same 
>> way? Any better solution?
>> 
>> Thanks
>> Christian
>> 
>> -- 
>> -- 
>> Christian Schneider
>> http://www.liquid-reality.de 
>> 
>> Computer Scientist
>> http://www.adobe.com 
>> 
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org 
>> https://mail.osgi.org/mailman/listinfo/osgi-dev 
>> 
> 
> 
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de 
> 
> Computer Scientist
> 

Re: [osgi-dev] Best practice for defining imports and exports

[Christian Schneider via osgi-dev]

I generally agree about optional packages in most cases I simply avoid them.

In some rare cases they are not so bad though. For example in felix system
ready we used it to provide a servlet if the servlet spec is available. DS
helps nicely with this so we did not have to handle ClassNotFoundException.
In this case an additional bundle seemed a bit overkill especially as the
code is very small at the moment.

So back to my question is the manually defined import still the best
practice (in case of the bad practice to use optionals :-) ?

Christian

Am Do., 5. Juli 2018 um 10:03 Uhr schrieb Tim Ward :

> One of the big challenges with optional imports is that they are so rarely
> actually optional, and that they end up not being wired to you in future if
> the dependency becomes available as a result of a later bundle installation
>
> Every time I see an optional import it tells me that the bundle has poor
> cohesion, and should probably be split into two bundles, one containing the
> “optional” piece as a mandatory import. Then if you want the optional
> behaviour you install the optional bundle, and don’t have to worry about
> handling optional packages.
>
> Optional packages are also often misused as a “pluggable” mechanism where
> you can use one of a set of libraries to provide a piece of function. In
> this case each individual library is “optional” but you must have at least
> one of them for your bundle to work. This results in bundles with broken
> metadata which will resolve even when they can’t run. Again the plug point
> should be implemented with a mandatory package dependency supplied by a
> bundle with a mandatory dependency on one of the bundles, ideally using a
> service.
>
> Even if you do have a truly optional package dependency you need to do
> lots of error-prone reflective access with try/catch blocks, and have a
> Dynamic-Import for it as well.
>
> In summary, optional packages are a bad thing, and I don’t think that we
> should be encouraging people to use them. Instead we should be encouraging
> people to write cohesive modular bundles which therefore do not need
> optional imports.
>
> Best Regards,
>
> Tim
>
> P.S. This is the same advice that I have given for years - see from slide
> 30 of this (rather old) lightning talk
> https://www.slideshare.net/mfrancis/when-is-optional-really-optional-tim-ward
>
>
> On 5 Jul 2018, at 07:41, Christian Schneider via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
> I am currently looking into improving the OSGi setup of bundles.
>
> For package exports I have found the package-info.java to be the best
> practice (see below):
>
> @org.osgi.annotation.versioning.Version("1.0.0")
> @org.osgi.annotation.bundle.Export
> package my.package;
>
> Imports are normally computed automatically. Some cases that still need
> special handling are changes in import range or optional imports.
>
> Currently I use this for optional imports:
>
> bnd.bnd
> Import-Package: \
> javax.servlet*;resolution:=optional,\
> *
>
> Is this still best practice or do we have something better? The
> maven-bundle-plugin makes imports optional if the maven dependency is
> optional. Is there a way to make the bnd-maven-plugin to behave in the same
> way? Any better solution?
>
> Thanks
> Christian
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>

-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Best practice for defining imports and exports

[Tim Ward via osgi-dev]

One of the big challenges with optional imports is that they are so rarely 
actually optional, and that they end up not being wired to you in future if the 
dependency becomes available as a result of a later bundle installation

Every time I see an optional import it tells me that the bundle has poor 
cohesion, and should probably be split into two bundles, one containing the 
“optional” piece as a mandatory import. Then if you want the optional behaviour 
you install the optional bundle, and don’t have to worry about handling 
optional packages. 

Optional packages are also often misused as a “pluggable” mechanism where you 
can use one of a set of libraries to provide a piece of function. In this case 
each individual library is “optional” but you must have at least one of them 
for your bundle to work. This results in bundles with broken metadata which 
will resolve even when they can’t run. Again the plug point should be 
implemented with a mandatory package dependency supplied by a bundle with a 
mandatory dependency on one of the bundles, ideally using a service.

Even if you do have a truly optional package dependency you need to do lots of 
error-prone reflective access with try/catch blocks, and have a Dynamic-Import 
for it as well.

In summary, optional packages are a bad thing, and I don’t think that we should 
be encouraging people to use them. Instead we should be encouraging people to 
write cohesive modular bundles which therefore do not need optional imports.

Best Regards,

Tim

P.S. This is the same advice that I have given for years - see from slide 30 of 
this (rather old) lightning talk 
https://www.slideshare.net/mfrancis/when-is-optional-really-optional-tim-ward 



> On 5 Jul 2018, at 07:41, Christian Schneider via osgi-dev 
>  wrote:
> 
> I am currently looking into improving the OSGi setup of bundles. 
> 
> For package exports I have found the package-info.java to be the best 
> practice (see below):
> 
> @org.osgi.annotation.versioning.Version("1.0.0")
> @org.osgi.annotation.bundle.Export
> package my.package;
> 
> Imports are normally computed automatically. Some cases that still need 
> special handling are changes in import range or optional imports.
> 
> Currently I use this for optional imports:
> 
> bnd.bnd
> Import-Package: \
>   javax.servlet*;resolution:=optional,\
>   *
> 
> Is this still best practice or do we have something better? The 
> maven-bundle-plugin makes imports optional if the maven dependency is 
> optional. Is there a way to make the bnd-maven-plugin to behave in the same 
> way? Any better solution?
> 
> Thanks
> Christian
> 
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de 
> 
> Computer Scientist
> http://www.adobe.com 
> 
> ___
> 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-dev] Best practice for defining imports and exports

[Christian Schneider via osgi-dev]

I am currently looking into improving the OSGi setup of bundles.

For package exports I have found the package-info.java to be the best
practice (see below):


@org.osgi.annotation.versioning.Version("1.0.0")

@org.osgi.annotation.bundle.Export

package my.package;

Imports are normally computed automatically. Some cases that still need
special handling are changes in import range or optional imports.

Currently I use this for optional imports:

bnd.bnd

Import-Package: \

javax.servlet*;resolution:=optional,\

*

Is this still best practice or do we have something better? The
maven-bundle-plugin makes imports optional if the maven dependency is
optional. Is there a way to make the bnd-maven-plugin to behave in the same
way? Any better solution?

Thanks
Christian

-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev