Hi, It can be released in its own cycle in the main repo.
For instance, ServiceMix Bundles are on an unique git repo, but I do release of each independently from the others. I think we can start like this. Regards JB On 14/11/2019 11:09, Christian Schneider wrote: > The fact that it evolves a lot at the start is even another argument to > keep it out of the karaf main repo as there you can only release together > with karaf. > > I think in the end it is your decision - either a new karaf repo (I can > create it for you) or a new aries repo (again I can create it) or the aries > main repo. So all options should be pretty quick to do. > (Of course if you decide for aries we need an approval from the pmc of > aries but I guess that is rather a formality as most are also in this list > and would have objected if they did not want it at aries). > > Christian > > Am Mi., 13. Nov. 2019 um 09:39 Uhr schrieb Romain Manni-Bucau < > [email protected]>: > >> I kind of share the fact code will likely be stable - that said, depending >> the adoption it can evolve quite a lot for ~1 year I think (adding method >> binding support is the one I have in mind if the module works great without >> this feature). >> Where I'm a bit less "easy" is cause karaf has jms, jpa, jdbc etc modules >> so it sounds it is on the same plan to me, no? >> That said, once again any home will be fine for me while it exists ;) >> >> Le mer. 13 nov. 2019 à 09:29, Christian Schneider <[email protected] >>> >> a écrit : >> >>> I would not put the new code into an existing Aries subproject. Instead >> we >>> could add a new one. >>> Either in its own git repo or in the shared one (depends on how we want >> to >>> release). >>> >>> @Romain .. do you plan to version by bundle or the whole interceptor >>> subproject? >>> If you plan to release by bundle then the aries main git would be a great >>> fit as the modules there are released in the same fashion. >>> If you plan to always release the whole interceptor tree then a new git >>> repo in aries or karaf would work great. >>> >>> The karaf main repo would be a bad choice as I think the interceptor code >>> will be quite stable after some time while karaf will always be changing. >>> >>> Christian >>> >>> Am Di., 12. Nov. 2019 um 11:23 Uhr schrieb Romain Manni-Bucau < >>> [email protected]>: >>> >>>> Updated the code, last changes are mainly: >>>> >>>> 1. moving the module in the right parent (I put it in service instead >> of >>>> service*s* originally) >>>> 2. added an E2E test using pax-exam >>>> 3. make it work :) >>>> >>>> I added a doc page ([1]) to try to share more what it tries to achieve. >>>> >>>> About aries, the proxy module looks almost 100% bound to blueprint so >>>> didn't see it as an option but I don't have a really strong blocker >>> there, >>>> I'll fully trust the OSGi@apache community on that. >>>> >>>> [1] >>>> >>>> >>> >> https://github.com/apache/karaf/pull/993/files#diff-6aaf055d932f602b06135e6446ee6c2eR15 >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>> <https://rmannibucau.metawerx.net/> | Old Blog >>>> <http://rmannibucau.wordpress.com> | Github < >>>> https://github.com/rmannibucau> | >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >>>> < >>>> >>> >> https://www.packtpub.com/application-development/java-ee-8-high-performance >>>>> >>>> >>>> >>>> Le mar. 12 nov. 2019 à 08:15, Grzegorz Grzybek <[email protected]> >> a >>>> écrit : >>>> >>>>> Hello >>>>> >>>>> pon., 11 lis 2019 o 20:45 Christian Schneider < >> [email protected] >>>> >>>>> napisał(a): >>>>> >>>>>> Great to hear that you already considered aspecio. >>>>>> If we want to put this into apache then I rather would suggest >> Apache >>>>>> Felix, Apache Aries or a Karaf submodule. >>>>>> >>>>> >>>>> Yes, IMO it'd fit more into Apache Aries Proxy. >>>>> >>>>> regards >>>>> Grzegorz Grzybek >>>>> >>>>> >>>>>> The interceptor support is a small standalone module that should >> have >>>> its >>>>>> own lifecycle. >>>>>> Putting it in the main karaf tree would mean it is released for >> every >>>>> karaf >>>>>> version. >>>>>> >>>>>> Christian >>>>>> >>>>>> Am Mo., 11. Nov. 2019 um 20:38 Uhr schrieb Romain Manni-Bucau < >>>>>> [email protected]>: >>>>>> >>>>>>> @Christian yes and no. Ray pointed out aspecio to me but I had a >>> few >>>>>> issues >>>>>>> with it: >>>>>>> >>>>>>> 1. it brings its own stack - and yes I care about each single dep >>> my >>>>> app >>>>>>> brings cause, a) network usage the size can implies with modern >>>>>>> deployments, b) security vulnerabilities the stack can hide. >>>>>>> 2. it is not at asf or asf influenced (as part of codehaus >> projects >>>> had >>>>>>> been in early times for exapple) with all it implies in terms of >>>>>> governance >>>>>>> and legal quality. >>>>>>> 3. the API is reinvented compared to the final step of my >> proposal >>>>> which >>>>>>> would be aligned on the standard. Current version of code is >> almost >>>>>> aligned >>>>>>> on interceptor API (you just sed the package for the mainstream >>>> usage) >>>>>> but >>>>>>> the consumer side is a bit different, I must refine it to be >> closer >>>> to >>>>>> CDI >>>>>>> but it is just a matter of handling RUNTIME interceptor >> annotations >>>> and >>>>>>> just using @Interceptors as a component property type of type >>> boolean >>>>> and >>>>>>> not a value holder which breaks interceptor simplicity. >>>>>>> 4. it is a one guy github project (even if code quality is not >> bad) >>>> so >>>>>> not >>>>>>> something you can reliably use in a professional project >> (<joke>we >>>>> don't >>>>>>> code in javascript ;)</joke>) >>>>>>> 5. no commit since > 1 year? >>>>>>> >>>>>>> Hope it clarifies a bit how I ended up on that proposal. >>>>>>> >>>>>>> Romain Manni-Bucau >>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog >>>>>>> <http://rmannibucau.wordpress.com> | Github < >>>>>>> https://github.com/rmannibucau> | >>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >>>>>>> < >>>>>>> >>>>>> >>>>> >>>> >>> >> https://www.packtpub.com/application-development/java-ee-8-high-performance >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Le lun. 11 nov. 2019 à 20:22, Jean-Baptiste Onofré < >>> [email protected]> >>>> a >>>>>>> écrit : >>>>>>> >>>>>>>> Hi Romain, >>>>>>>> >>>>>>>> that sounds great to me ! Thanks for that. >>>>>>>> >>>>>>>> First, you did well in terms of modules organization: it makes >>>> sense >>>>> to >>>>>>>> have interceptor in service (like staticcm). >>>>>>>> >>>>>>>> About the use case, it makes sense as well. I will take a >> deeper >>>> look >>>>>>> soon. >>>>>>>> >>>>>>>> Thanks again ! >>>>>>>> Regards >>>>>>>> JB >>>>>>>> >>>>>>>> >>>>>>>> On 11/11/2019 19:37, Romain Manni-Bucau wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I took some time this week-end to draft an interceptor module >>> in >>>>>> Karaf. >>>>>>>>> I tried to describe it in the related PR ([1]) - in WIP mode >> so >>>>> don't >>>>>>>> jump >>>>>>>>> on me yet cause tests are not there please ;). >>>>>>>>> >>>>>>>>> High level, I missed a lot interceptors (from javax.) when >>>> starting >>>>>> to >>>>>>>> use >>>>>>>>> SCR. >>>>>>>>> It mainly change the way to add transversal features >> (metrics, >>>>>>> security, >>>>>>>>> tracing, circuit-breaker, asynchronism to cite a few). >>>>>>>>> >>>>>>>>> I still have some API refinement to do but high level it >> would >>>>>> enable a >>>>>>>>> service to be marked as intercepted ([2]) and implement >>>>> interceptors >>>>>>> "as >>>>>>>>> usual" ([3]) and link them with a marker (in the PoC it is an >>>>>>>> annotation). >>>>>>>>> >>>>>>>>> It is in very early stages but before investing way more >> time, >>>> I'd >>>>>> like >>>>>>>> to >>>>>>>>> know if it sounds like a module Karaf could host and would >>>> benefit >>>>>> more >>>>>>>>> than me or if it is an "EE guy" idea ;). >>>>>>>>> >>>>>>>>> Wdyt? >>>>>>>>> >>>>>>>>> [1] https://github.com/apache/karaf/pull/993 >>>>>>>>> [2] >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> https://github.com/apache/karaf/pull/993/files#diff-5edc34da45232dc12a96cae52e620adcR22 >>>>>>>>> [3] >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> https://github.com/apache/karaf/pull/993/files#diff-412d137df581cff1938e723692a1ec45R24 >>>>>>>>> >>>>>>>>> Romain Manni-Bucau >>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog >>>>>>>>> <http://rmannibucau.wordpress.com> | Github < >>>>>>>> https://github.com/rmannibucau> | >>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >>>>>>>>> < >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> https://www.packtpub.com/application-development/java-ee-8-high-performance >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Jean-Baptiste Onofré >>>>>>>> [email protected] >>>>>>>> http://blog.nanthrax.net >>>>>>>> Talend - http://www.talend.com >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> -- >>>>>> 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 >>> >> > > -- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
