Hi, I'm agree, we need to improve the modularity to help user to contribute more to the source code and help us for the maintenance.
Another pain point today is the integration tests, I started to work on some improvements, espacially for ES by removing the ES maven plugin. Actually I have to refactor a bunch of part around the feature.xml and the maven-bundle-plugins... It would be nice to synchronize this work with the 2.0.0. Regards, François [email protected] Le 21/04/2020 à 15:44, Serge Huber a écrit : > 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 >> >> >>
