Hello JB, Thanks so much for all the work done in that. I think it would be fantastic if we could schedule that for Unomi 2.0
For the unomi:start, this was done for the purpose of migration, since in some cases you want to execute unomi:migrate before unomi:start... but if you have a cleaner solution I'm all in for it! Also I'm not sure how clean the migration process is with Docker. The biggest issue is that we have a team that is hard at work with the GraphQL integration (branch here: https://github.com/enonic/unomi/tree/UNOMI-180-CXS-GRAPHQLAPI) and they are also using a lot of services in their branch. This is also planned for Unomi 2.0. How would they be impacted ? They are reaching the point where they could soon create a PR. I also will send an email about cutting the 1.5 release which I would like to (ideally) do next week. Regards, Serge... Serge Huber CTO & Co-Founder T +41 22 361 3424 9 route des Jeunes | 1227 Acacias | Switzerland jahia.com <http://www.jahia.com/> SKYPE | LINKEDIN <https://www.linkedin.com/in/sergehuber> | TWITTER <https://twitter.com/sergehuber> | VCARD <http://www.jahia.com/vcard/HuberSerge.vcf> > JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained and to discover why Jahia is a leading User Experience Platform (UXP) for Digital Transformation. On Tue, Apr 21, 2020 at 7:16 AM Jean-Baptiste Onofre <[email protected]> wrote: > Hi everyone, > > As already discussed with some of you, I started a complete refactoring of > Unomi, not from a use case/logic perspective but more from a technical > standpoint. > > IMHO, Unomi is a bit mess today, and it’s normal because we wanted to > implement some features quickly. > Now that we are heading to Unomi 2.x, I think it’s time to do kind of > cleanup. > > Basically, here’s what I started: > > - Structure/Code: more fine grained modules/bundles to have a way more > clean features and structure > - Services: introduce more Unomi services (persistence, etc), to have a > better decoupled approach, with whiteboard to have service only when > required (for instance Cellar). Each service should have a REST (NOT > GraphQL) endpoint and a MBean allowing users to easily integrate with their > own applications > - Extensions: we can provide more extension (like Kafka injector) > - Distribution: remove of kar to use custom Karaf distribution, remove of > Unomi:start replaced by boot features, improved docker > - Commands: cleanup on shell commands, adding new ones > - Metrics/MBeans: it’s something I already started, but as more metrics > (dropwizard/codehale) and integrate Decanter (allowing us to easily plug > with prometheus, etc) > - Examples: we need more "concrete" examples describing "classic" use > cases. CDP is abstract for most of our users and they don’t know exactly > what they can do with unomi. > > I’m moving forward on a branch to better explain what I have in mind. > > I think it’s important: > 1. For us, as it would simplify the maintenance > 2. For community, as people will more easily join the project and submit > contributions > > Thoughts ? > > Regards > JB > > >
