Inline... > On Apr 12, 2020, at 3:23 PM, Christian Schneider <ch...@die-schneider.net> > wrote: > > Hi David, > > actually I did not think about Aries but you are right, it could also fit > there. If the Felix community thinks Aries is the better place I will > propose it there too. > I think for marketing purposes Felix is a lot more known than Aries. > The main purpose I want to achieve is that people consider doing > microservices with OSGi. So I wanted to leverage a well known brand that > people associate with OSGi. > Apart from that the only Aries project I use in my experiments is Aries > JAX-RS whiteboard but I use lots of felix bundles.
That seems like a conceptual circular dependency with which I am not entirely comfortable. However, it wouldn’t be blocking for me. > > I agree about the naming. Blueprint was a bad choice. What do you think > about "felix cloud native starter”. Names are hard…. ’native’ to me suggests you will be targeting one (or more) of the nontraditional javas (that I am only vaguely acquainted with from watching the Camel list) such as graalvm or quarkus. (I know so little about this that I could be wrong about what these are). I do think that this initiative is a great idea! Maybe you could start it at GitHub while the location/name/description is hammered out? Thanks, David Jencks > > Christian > > > Am Mo., 13. Apr. 2020 um 00:05 Uhr schrieb David Jencks < > david.a.jen...@gmail.com>: > >> Hi Christian, >> >> I’d like to know why felix is a better location for this than aries. >> >> I also think that you should find a description or name other than >> “blueprint” as that term has unfortunately been taken by the osgi blueprint >> spec. Seeing your subject line I wondered why a blueprint (as in spring >> for osgi) project would fit in felix. >> >> Thanks >> David Jencks >> >>> On Apr 12, 2020, at 2:05 PM, Karl Pauls <karlpa...@gmail.com> wrote: >>> >>> Hi Christian, >>> >>> I don't think we are at that point just yet. Given that this is a >>> holiday surrounded weekend for a lot of us (due to the easter break) I >>> would say we should at least give it a couple of more days to see >>> where the discussion is going. >>> >>> That said, I personally would like to see a little bit more about what >>> you had in mind. Is there already some existing body of work or are >>> you planning to create something from scratch? >>> >>> regards, >>> >>> Karl >>> >>> On Sun, Apr 12, 2020 at 9:32 PM Christian Schneider >>> <ch...@die-schneider.net> wrote: >>>> >>>> There seems to be some interest in having such a blueprint or even more >>>> than one variant at felix. >>>> >>>> Should I start in felix-dev or use a new repo? >>>> I would prefer a new repo as the code will be a multi module maven >> project. >>>> I propose a repo name "felix-cloud-native-starter". >>>> We could have and have different blueprints (e.g. CDI and DS) inside. >>>> I thought about but disliked to have "blueprint" in the name as people >>>> might confuse it with the blueprint dependency injection. >>>> >>>> Christian >>>> >>>> Am So., 12. Apr. 2020 um 11:58 Uhr schrieb Christian Schneider < >>>> ch...@die-schneider.net>: >>>> >>>>> 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 >>> >>> >>> >>> -- >>> Karl Pauls >>> karlpa...@gmail.com >> >> > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Computer Scientist > http://www.adobe.com
