You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@unomi.apache.org by Jean-Baptiste Onofre <jb...@nanthrax.net> on 2020/04/21 05:16:26 UTC
[PROPOSAL] Heading to Unomi 2.0/3.0 ?
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
Re: [PROPOSAL] Heading to Unomi 2.0/3.0 ?
Posted by Francois Papon <fr...@openobject.fr>.
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
fpapon@apache.org
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 <jb...@nanthrax.net>
> 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
>>
>>
>>
Re: [PROPOSAL] Heading to Unomi 2.0/3.0 ?
Posted by Serge Huber <sh...@jahia.com>.
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 <jb...@nanthrax.net>
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
>
>
>