Re: Develocity
Hello Jean, I think this is a great initiative, thank you! The build are regularly unstable and painful to maintain, such tooling to maybe make builds faster, not rebuilding and retesting everything every time for small changes and scans to understand better about where we spend build time sound like very good news to me. A big +1 on this :) Rene. On 2/5/24 21:52, Jean Helou wrote: Hello fellow james devs, I'm not sure how much context to provide in the email you can read more in https://issues.apache.org/jira/projects/JAMES/issues/JAMES-3978?filter=allopenissues TLDR; A few months ago the apache foundation announced a sponsorship of the "gradle" company for a tool to diagnose, monitor and optimize builds ( called gradle enterprise at the time and renamed develocity since) I posted a first PR to plug james build in that tool https://github.com/apache/james-project/pull/1972 This first integration brings only build scans and local caching - build scans can help us understand what slows our build - local caching allows local build perf improvements (I posted a small benchmark which shows a divide by 3 the time spent building james-server-core in a repeat build with no changes) The build scans also show that many tasks in the build are not actually cached so there is room for more improvement. The local cache does apply to surefire tasks,unfortunately the benefits for CI are very small : In the first stage we cache the compilation result itself but that represents a very small part of the test stages (even if we had to compile everything from scratch that's barely 20 minutes out of the 3h30 of the build so caching only marginally improves the build time at the moment the next stage would be to : - make more tasks cacheable - enable the remote build cache The remote build cache allows to share caching accross builds which means that if a change affects only a small portion of the build, only that change would effectively be recompiled and retested, so the closer to the "leafs" of the reactor a change would be the shorter its CI pipelines would be. I pinged INFRA in https://issues.apache.org/jira/browse/INFRA-25461 to know what the process is for enabling the remote build cache and it seems it starts with a mailing list thread :D note that - only the CI would be allowed to write to the remote build cache - build caches both local and remote can be disabled with properties (IIRC there are pretty strict constraints on release processes in the apache foundation) - I think it is possible to have the remote build cache be activated in readonly mode for everyone so that anyone pulling the repo would experience a very fast first build (but that remains to be confirmed as I have never experienced it) what do you think ? jean - To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org For additional commands, e-mail: server-user-h...@james.apache.org
Re: James 3.8 one OpenSuSE 15.5
Well, just as an update: As the OpenSuSE forums are as helpful as always: not at all - I looked up options to change James listen directly on TCP/25 itself - and had not much luck. I don't want to spam the list with the details as it doesn't belong here, the short version is: The packet filter doesn't seem to work the way I expected it to according to its own docs. There also seem other options such as privilege dropping or enabling non-root processes to bind to ports below 1024 - but the former isn't supported by Java and the latter works not on a per-process basis but global on a per-executable scope: When I allow James to bind to ports below 1024 so can any other Java process, not exactly what I wanted. I'm also not quite sure if it's just OpenSuSE biting me once again as it did for so many years with the somehow screwed up MySQL/MariaDB packages as when testing in a VM with Arch it works as expected. I guess I should start to reconsider keep using OpenSuSE for my servers as it keeps throwing rocks into my path, its community isn't really helpful and many informations one finds just don't work for one reason or another with no clue why or how to fix it. Anyway ... As for developing a client for the web-admin api: As its only security seems to be the JWT I still have to get my head around how to implement that securely so that only authorized admins with access to a valid token can access the web-admin. I also plan to keep it modular so that each function can get implemented independently without much spaghetti code. I'm aware about some sort of markup languages so one can just write a simple parser and then define such functionalities via config files. But I guess that's something for someone with more experience in that style of coding. Unfortunately I won't have much time in the next few weeks as overtime and extra work is planed throughout february. But I'll keep it in mind as I want to give something back to such a great project. So long, have a good one y'all. Matt On 15.01.24 03:45, Rene Cordier wrote: Hi Matt, Happy to see the transition didn't look too hard for you ! Regarding the webadmin, no there is no UI at the moment. It's been a task in the backlog for a long time though. But if you want to take a look, and even contribute, the task is here: https://issues.apache.org/jira/browse/JAMES-1931 . I'm sure people would be happy to see a contribution about this and support you regarding the coding standards of the project with reviews, even if the UI is not really good looking, it is ok I think. It's destined more to sys admins than lambda users for a backend software, as long as it does the job, it's enough already IMO :) Cheers, Rene. On 1/14/24 09:07, cryptearth wrote: Hi everyone, so, I had a look into Guice+JPA and it's quite easy to setup by just reuse the configs I have for the Spring build. And although I still can use james-cli (although a bit different) I now have access to the REST-api via the webadmin (until now it seems I misunderstood it: I thought the "web admin" to be some browser admin panel instead of just an REST-api). And although it seems rather easy to use it to do the same as with the james-cli and even more - looking in the list archive: Is there any "client" for it like some webpage or some standalone gui? Guess if not it'd be a nice project to get something together - although I'm only a hobbyist and hence the "most advanced" I was able to get done was a simple networked battle ships game with some very ugly ui-code for the placement of the ships. So I guess if at all I can only provide some simple stuff and far from the code standards of ASF. The next will now be to switch over to Guice+JPA and also upgrade my backup server. Nice to see I still can learn about James - just another confirmation it was the right choice after Citadel/UX got broken, although I'll re-visit other setups with sendmail, postfix or exim just for the fun of additional knowledge. So long ... have a good one. Matt Am 11.01.24 um 05:40 schrieb Rene Cordier: Hello Matt, Thanks for keeping reporting dead links, I try to fix them every time firing PRs :) Regarding the correct link to the jpa guice sample conf: https://github.com/apache/james-project/tree/master/server/apps/jpa-app/sample-configuration Regarding the link in a previous email with jpa-guice installation guide (but I think the readme is likely more complete): https://james.apache.org/server/install/guice-jpa.html For this though: https://james.staged.apache.org/james-project/3.8.0/servers/basic/conf/index.html, yes that's still not done, it's normal atm, as said this new doc is still a work in progress ^^' Regarding your mail with INVALID suffixed to it... No idea really^^' Might want to ask the people managing the mailing lists I guess. Well if anything else don't hesitate :) Rene. On 1/11/24 02:45, cryptearth wrote: Hello Rene,
Develocity
Hello fellow james devs, I'm not sure how much context to provide in the email you can read more in https://issues.apache.org/jira/projects/JAMES/issues/JAMES-3978?filter=allopenissues TLDR; A few months ago the apache foundation announced a sponsorship of the "gradle" company for a tool to diagnose, monitor and optimize builds ( called gradle enterprise at the time and renamed develocity since) I posted a first PR to plug james build in that tool https://github.com/apache/james-project/pull/1972 This first integration brings only build scans and local caching - build scans can help us understand what slows our build - local caching allows local build perf improvements (I posted a small benchmark which shows a divide by 3 the time spent building james-server-core in a repeat build with no changes) The build scans also show that many tasks in the build are not actually cached so there is room for more improvement. The local cache does apply to surefire tasks,unfortunately the benefits for CI are very small : In the first stage we cache the compilation result itself but that represents a very small part of the test stages (even if we had to compile everything from scratch that's barely 20 minutes out of the 3h30 of the build so caching only marginally improves the build time at the moment the next stage would be to : - make more tasks cacheable - enable the remote build cache The remote build cache allows to share caching accross builds which means that if a change affects only a small portion of the build, only that change would effectively be recompiled and retested, so the closer to the "leafs" of the reactor a change would be the shorter its CI pipelines would be. I pinged INFRA in https://issues.apache.org/jira/browse/INFRA-25461 to know what the process is for enabling the remote build cache and it seems it starts with a mailing list thread :D note that - only the CI would be allowed to write to the remote build cache - build caches both local and remote can be disabled with properties (IIRC there are pretty strict constraints on release processes in the apache foundation) - I think it is possible to have the remote build cache be activated in readonly mode for everyone so that anyone pulling the repo would experience a very fast first build (but that remains to be confirmed as I have never experienced it) what do you think ? jean
