juneau-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Bognar <james.bog...@salesforce.com>
Subject Re: Does Hammock + Juneau make sense?
Date Fri, 01 Jul 2016 01:02:06 GMT
Fat-jars was the first approach.  But that did work for encrypted jars that
teams wanted to use.  So then we specified that you had to add classpath
entries to the main jar.  Then teams wanted a service API with lifecycles.
So based on where it was heading, I started thinking maybe just using a
bare-bones OSGi app.  I guess it depends on just how lean it can be made.

On Thu, Jun 30, 2016 at 8:12 PM, John D. Ament <johndament@apache.org>
wrote:

> Inherently, the OSGi approach doesn't make sense for uber-jar based
> microservices, which is the most popular pattern.  You're not deploying
> something on top of an existing container, you're spinning up something new
> independently.
>
> John
>
> On Thu, Jun 30, 2016 at 2:29 PM Jochen Wiedmann <jochen.wiedmann@gmail.com
> >
> wrote:
>
> > On Thu, Jun 30, 2016 at 8:24 PM, James Bognar
> > <james.bognar@salesforce.com> wrote:
> > > The build scripts already produce OSGi bundles in addition to a single
> > > juneau-all.jar file for non-OSGi apps.  So converting it to OSGi
> > shouldn't
> > > be difficult.
> > >
> > > Anyone know if there are any difficulties developing OSGi while using
> > Maven?
> >
> > AllI can tell you is the URL of the Apache Felix Maven Bundle Plugin:
> >
> >
> >
> http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html
> >
> > Sorry,
> >
> > Jochen
> >
> >
> >
> > --
> > The next time you hear: "Don't reinvent the wheel!"
> >
> >
> >
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> >
>



-- 
James Bognar

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message