You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Eugen Stan <eu...@netdava.com> on 2020/06/08 22:00:11 UTC
better dev experience - make integration tests OPT IN ?
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,
--
Eugen Stan
+40720 898 747 / netdava.com
Re: better dev experience - make integration tests OPT IN ?
Posted by Eugen Stan <eu...@netdava.com>.
Hi,
La 09.06.2020 16:33, Matthieu Baechler a scris:
>> I propose we make integration tests OPT-IN behind a maven profile ?!
> I hate maven profiles because everything becomes unpredictable very
> quickly when we use them.
>
> However, I agree that few people want a long testsuite to run when
> building a software and it should be OPT-IN. We invented CI for a thing
> after all.
>
> I suggest we just change the default behavior of surefire maven plugin
> to not run tests by default and document how to run tests when wanted.
You have my +1 for that. But since you mentioned Gradle see my reply
bellow.
>> I propose we document how people can OPT-IN FOR them.
>>
>> What are other ways of making a James build slimmer ?!
> There are many ways: we did experiments with gradle and the results
> were very promising (around 1 minute on my computer) but postponed the
> adoption for now.
I'm willing to put some effort into moving the project to gradle if we
decide we want to do that.
It has benefits for larger builds.
We can have both builds side by side until we make the switch.
We can announce it on the mailing list and we can start right after 3.5
is out.
> We could also, for component relying on stable APIs, move these
> components in their own git repository to avoid building them with the
> main codebase.
>
> Cheers,
Working with multiple git repositories is not the best experience. It
tends to slow things down.
I did not have a chance to look at gradle composite builds
https://docs.gradle.org/current/userguide/composite_builds.html .
I did not try it but I suspect we can:
- have our library repositories
- move the application parts in another git repo
- using a composite build to bring libraries and James App together
--
Eugen Stan
+40720 898 747 / netdava.com
Re: better dev experience - make integration tests OPT IN ?
Posted by Matthieu Baechler <ma...@apache.org>.
Hi, again,
On Tue, 2020-06-09 at 01:00 +0300, 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 hate maven profiles because everything becomes unpredictable very
quickly when we use them.
However, I agree that few people want a long testsuite to run when
building a software and it should be OPT-IN. We invented CI for a thing
after all.
I suggest we just change the default behavior of surefire maven plugin
to not run tests by default and document how to run tests when wanted.
> I propose we document how people can OPT-IN FOR them.
>
> What are other ways of making a James build slimmer ?!
There are many ways: we did experiments with gradle and the results
were very promising (around 1 minute on my computer) but postponed the
adoption for now.
We could also, for component relying on stable APIs, move these
components in their own git repository to avoid building them with the
main codebase.
Cheers,
--
Matthieu Baechler <ma...@apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: better dev experience - make integration tests OPT IN ?
Posted by Eugen Stan <eu...@netdava.com>.
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-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
--
Eugen Stan
+40720 898 747 / netdava.com
Re: better dev experience - make integration tests OPT IN ?
Posted by Eugen Stan <eu...@netdava.com>.
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-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
--
Eugen Stan
+40720 898 747 / netdava.com
Re: better dev experience - make integration tests OPT IN ?
Posted by Tellier Benoit <bt...@apache.org>.
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 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?
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.
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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org