One interesting question is if CDI based applications and declarative services based applications share enough commonalities to share the same repo. CDI builds a lot upon its extensions which are not reusable in declarative services.
I definitively support an Aries CDI based blueprint for microservices too. I think it is a very valid foundation. I also wonder which parts of quarkus can be reused for this. Christian Am So., 12. Apr. 2020 um 16:12 Uhr schrieb Raymond Auge < raymond.a...@liferay.com>: > Hi Christian, > > I also think it's a good idea. You might be aware that Aries CDI project is > also working toward this exact goal by implementing key Eclipse > MicroProfile parts (with the assistance of Apache Geronimo) which deliver > some of the feature areas you've outlined. The Apache Aries CDI BOM already > contains a great value and a repository of this nature I think is the most > useful resource as a _repo_. > > We could do something similar for Felix? > > This is just to say that I think it's a great idea and would like to help > work toward that goal. > > - Ray > > > On Sun, Apr 12, 2020 at 7:58 AM Christian Schneider < > ch...@die-schneider.net> > wrote: > > > Hi Neil, > > > > indeed the idea is to build upon the same building blocks as the enroute > > microservice example but enrich it with everything you need to get a > fully > > cloud ready service. It would be ideal to make it modular like spring > boot > > with the individual starters you can simply combine. Not sure though if > > that is achievable. The simpler alternative is to provide a OSGi bundle > > repo that has maybe too many bundles but let the resolver choose the > needed > > ones. > > > > Christian > > > > > > Am So., 12. Apr. 2020 um 12:44 Uhr schrieb Neil Bartlett < > > njbartl...@gmail.com>: > > > > > Hi Christian, > > > > > > I think this would be great, but it does have a fair degree of overlap > > with > > > enRoute, at least in the early stages. It's always been a problem that > > OSGi > > > offers too many competing ways to do simple things, and if not done > well > > > your idea would exacerbate the problem. > > > > > > On the other hand, enRoute is limited to working with OSGi > specification > > > technologies, because it is funded by Alliance members who are in > > > competition with each other. So it would be ideal if your effort could > be > > > built as an extension to the existing enRoute microservices > > > tutorial/example. The original idea for enRoute was to have a bunch of > > > these extensions, perhaps even linked (though not endorsed) from the > > > enRoute page. > > > > > > Neil > > > > > > On Sun, 12 Apr 2020 at 10:58, Christian Schneider < > > ch...@die-schneider.net > > > > > > > wrote: > > > > > > > In recent years we saw a big trend towards micro services and cloud. > > > > Lately people discovered though that such services are often made too > > > fine > > > > grained. > > > > The newest trend goes to building bigger micro services on the level > of > > > > domain driven design bounded contexts. > > > > > > > > Especially for these services OSGi is a very interesting platform as > > they > > > > need more internal structure than the more fine grained services. > > > > Unfortunately it is quite hard to build a cloud native service in > OSGi > > > from > > > > scratch. > > > > > > > > So I would like to offer a blueprint for cloud native micro services > > > inside > > > > the felix community. The goal is to provide all parts of a cloud > native > > > > system that are usually needed, like: > > > > > > > > * Declarative services as dependency injection > > > > * Aries Jaxrs Whiteboard for REST > > > > * Dropwizard metrics exported as Prometheus metrics > > > > * Swagger > > > > * Halbrowser > > > > * Felix healthchecks > > > > * Configuration using OSGi configurator + Environment variables > plugin > > > > * Logging to console > > > > * Final application is provided as a runnable jar > > > > * Example docker build files > > > > * Example kubernetes yaml > > > > > > > > What do you think? > > > > > > > > Christian > > > > > > > > -- > > > > -- > > > > Christian Schneider > > > > http://www.liquid-reality.de > > > > > > > > Computer Scientist > > > > http://www.adobe.com > > > > > > > > > > > > > -- > > -- > > Christian Schneider > > http://www.liquid-reality.de > > > > Computer Scientist > > http://www.adobe.com > > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
