We can and should explore this as part of the gradle effort https://issues.apache.org/jira/browse/JAMES-3260 .
La 10.06.2020 13:04, Eugen Stan a scris: > 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
