Jetty may be modular, and each of their jars may include OSGI metadata so they
are bundles, but the use of service loader (implied I think by the discussion
of spi-fly; I haven’t looked at jetty myself) carries an extremely strong
presumption that the jetty modularity is not very compatible
David,
I don't believe that the OSGi support in jetty is just an afterthought and
those modules are used in many high profile OSGi environments, such as the
eclipse IDE. In fact, Jetty is hosted by the eclipse foundation who is all
about OSGi.
I think a reasonable explanation of the usage of
I'm of the mind that the Service Loader Mediator spec (implemented by
SpiFly) is an excellent (if not the only reasonable one) approach to handle
exactly the case that jetty uses it for which is to allow them to remain
plain JARs while also being usable OSGi bundles. The fact that it relies on
I agree, this solution would suffice for now and impact would be nihil.
Op za 20 okt. 2018 om 14:25 schreef Carsten Ziegeler :
> Let's focus for a minute on having jetty as separate bundles. This will
> potentially create a lot of problems as people will use the wrong jetty
> version. I just
Cool, it's a start!
- Ray
On Sat, Oct 20, 2018 at 8:38 AM Naftali wrote:
> I agree, this solution would suffice for now and impact would be nihil.
>
> Op za 20 okt. 2018 om 14:25 schreef Carsten Ziegeler >:
>
> > Let's focus for a minute on having jetty as separate bundles. This will
> >
Carsten and others,
Well, if the newer jetty version of the jetty artifacts causes the code to
not compile then perhaps that is an issue you would want to raise with the
jetty folks to not make incompatible changes to the public APIs without
incrementing the major version numbers of their
6 matches
Mail list logo
