Hi, Forgot to reply to you.
La 09.06.2020 07:34, Tellier Benoit a scris: > Hello, > > Thanks for this email. I had back in the days similar issues when trying > to build the various James related projects and can recall how > frustrating it was. > > I do believe that every developer or people interested in the James > project should be able to build it, and test it easily. > > In the recent years we contributed an integration test suite (most > notably for distributed James) that is quite expensive to run. It > requires docker, in order to mimic as much as possible real world usage. We should work to improve the build speed. Maybe gradle can help with the separation of projects and integration tests. Before we decide to switch tools I think we should address the issue with "distributed part". I keep thinking about this and maybe it's time to voice it. There are a lot of possible use-cases for James. IMO two deployment scenarios stand out: 1. Run James as an email server for a small-medium-large?! business on a single server or 2-3 servers. Vertical scaling, most components are co-located in the same jvm process or same physical machine. 2. Run James as part of a mail hosting service for lots of users. Horizontal scaling, distributed. Components run on many machines. Distributed is always complex and maybe we can rearange components based on these criteria. I imagine there are lots of companies that fit in scenario 1 and less so in scenario 2. However, people working on scenario 1 are not interested in scenario 2 and IMO should not pay the complexity price (or the build times). I don't know if this kind of separation is possible on the tooling side. It's unlikely with maven IMO. But I think it has some merit to put on the table. > We had a trial at not requiring (ignoring) tests requiring docker but I > am unsure of the status of it. And it don't address memory integration > tests that don't have external dependencies and are still expensive to run. > > I would then tend to agree with you proposal. > > We have some components implementation with complex testing dependencies > (say mailbox-cassandra relies on a dockerized Cassandra for its unit > tests), which had allowed us to achieve a high confidence with that > component. I'm unsure these components tests should be OPT-IN. Yet they > add to the build entry barrier. > > Would a solution be relying on a `mvn clean package --project XXX > --also-make` be acceptable as a developper, and then leave the hard, > long testing work to a continuous integration server? I think gradle might be of some help here with it's composite builds https://docs.gradle.org/current/userguide/composite_builds.html . Building on my ideas from above, we could have a single profile and a distributed profile. The distributed profile would include all of the implementations that are designed for that + their integration tests. I am optimistic we can have some compose-able build options with gradle. > Otherwise, I think reducing the count of Guice servers would help > reducing build complexity. > > I also think some advanced features could live as extensions, part of > James project source code but bundled in separate Jars that would then > be added to the classpath. That way building a server would only require > building its core components. I'm going to shoot an email to open discussion for what should we focus on the next release. Let's see what we can gather. > Sorry, I don't know what is going wrong for the compilation error you > have attached to your mail. > > Cheers, > > Benoit > > On 09/06/2020 05:00, Eugen Stan wrote: >> Hello, >> >> It's been a while since I wrote on this list. I just tried to build >> James locally and failed. >> >> I `git clone`d master and `mvn clean package` using adoptopenjdk 11 . >> >> The compilation fails on my machine (Debian Buster+Testing). That is >> however besides the point. >> >> I noticed the integration tests are ran as part of the normal build. >> Especially Casandra, ActiveMQ and DB integration tests. >> >> These have a habbit of taking a lot of time and personally I believe >> they should be OPT-IN. >> >> I don't use Casandra and ActiveMQ and I don't test on them. It's fine >> that we have integration tests but they should be activated on CI or >> locally for interested parties. >> >> I believe we need to improve the developer experience a bit and this is >> my proposal that I would like to discuss with everyone. >> >> >> I propose we make integration tests OPT-IN behind a maven profile ?! >> >> I propose we document how people can OPT-IN FOR them. >> >> What are other ways of making a James build slimmer ?! >> >> >> This is the error that I get locally. If someone can give me some clues >> on what is happening I would appreciate it. Thanks, >> >> ---- >> >> [ERROR] Failed to execute goal >> net.alchim31.maven:scala-maven-plugin:3.4.4:compile >> (scala-compile-first) on project event-sourcing-event-store-api: wrap: >> org.apache.maven.shared.dependency.graph.DependencyGraphBuilderException: >> Could not resolve following dependencies: >> [org.apache.james:event-sourcing-pojo:jar:tests:3.6.0-SNAPSHOT (test)]: >> Could not resolve dependencies for project >> org.apache.james:event-sourcing-event-store-api:jar:3.6.0-SNAPSHOT: >> Failure to find >> org.apache.james:event-sourcing-pojo:jar:tests:3.6.0-SNAPSHOT in >> https://jcenter.bintray.com was cached in the local repository, >> resolution will not be reattempted until the update interval of central >> has elapsed or updates are forced -> [Help 1] >> [ERROR] >> [ERROR] To see the full stack trace of the errors, re-run Maven with the >> -e switch. >> [ERROR] Re-run Maven using the -X switch to enable full debug logging. >> [ERROR] >> [ERROR] For more information about the errors and possible solutions, >> please read the following articles: >> [ERROR] [Help 1] >> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException >> [ERROR] >> [ERROR] After correcting the problems, you can resume the build with the >> command >> [ERROR] mvn <args> -rf :event-sourcing-event-store-api >> ---- >> >> >> Regards, >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > -- Eugen Stan +40720 898 747 / netdava.com
<<attachment: eugen_stan.vcf>>
signature.asc
Description: OpenPGP digital signature
