I would like to override the basic enroute distro settings by adding some
runsystempackages and runproperties for all my workspace projects.
Usually I do this including property files in my project's bnd/bndrun files,
but I would prefer to simply inherit those settings from the distro without
Hi,
I attended to this presentation at the OSGi Community event 2015 in Ludwigsburg
(this one is from EclipseCon Europe) and I found it very interesting:
https://www.youtube.com/watch?v=-U8j8KAhlBA
I don't know if it covers all the aspects you are interested in, but I think
this is a good
I think we have opened an old discussion. But I don't recall why things
have ended up where they are with recommending multiple osgi.contract
version capabilities from the same bundle that exports the packages. So
from https://www.osgi.org/portable-java-contract-definitions/ it states
the
As Tom mentions, when a bundle provides multiple contracts, the filter of the requirement only has to match one of the contracts. So adding an additional filter _expression_ like (version<=2.1) does not exclude the bundle which also offers the contract at version=3.
As an implementation bundle,
What do you think about writing a wiki page about this. So people can
find this information more easily.
I think we should also recommend certain maven bundles that provide each
persistence api.
Would enroute be a good place for such a page?
Christian
On 15.09.2016 20:12, Timothy Ward wrote:
Regardless, should the best practice for providing osgi.contract
capabilities be to only provide one capability per osgi.contract name? And
use Lists for attributes where you want to express multiple version
support?
I know for a fact there are Servlet 2.5 applications that will simply
break
I agree with Christian that this should be clearly documented in a wiki
somewhere. My personal opinion is that a bare-bones enroute JPA example
would be a good place for this.
Elliot
On Fri, Sep 16, 2016 at 9:26 AM, Thomas Watson wrote:
> Regardless, should the best
I would definitely support this - I’m not sure how else to make bundles that
implement contracts work reliably, and that impacts users too.
Regards,
Tim
> On 16 Sep 2016, at 08:26, Thomas Watson wrote:
>
> Regardless, should the best practice for providing osgi.contract
Hi,
Are there any publicly-available memory usage comparisons of the various
OSGi framework impls...e.g. equinox, felix, concierge, others? Perhaps
also compared with a Java app, with multiple bundles/libs of different
sizes and memory usage patterns, etc?
thanks,
Scott
>
> I agree with Christian that this should be clearly documented in a wiki
> somewhere.
Please someone, DO document this!
I already moved this thread to my "Things about OSGi that you need to read
at least 5 times before they start making sense" folder :) but for anyone
not on this list, it
10 matches
Mail list logo