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 Bernd Fondermann <be...@googlemail.com> on 2006/11/10 11:05:46 UTC
[DISCUSSION] Include Unit Tests in regular build
Hi,
Currently, unit tests have to be run separate with
"ant run-unit-tests"
This makes it very easy to forget to run them prio to a commit.
For me, unit tests are integral part of the quality management of the
code base, not just an appendix on the outer rim of the James source
code universe.
If we would include the run-unit-tests target in dist-lite, this would
happen with every build and immediate feedback is given if something
breaks in the tests.
The result would be that maintaining the main code line and unit test
code line is a one stop shop.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Include Unit Tests in regular build
Posted by Danny Angus <da...@gmail.com>.
+1
On 11/10/06, Bernd Fondermann <be...@googlemail.com> wrote:
> Hi,
>
> Currently, unit tests have to be run separate with
> "ant run-unit-tests"
>
> This makes it very easy to forget to run them prio to a commit.
> For me, unit tests are integral part of the quality management of the
> code base, not just an appendix on the outer rim of the James source
> code universe.
>
> If we would include the run-unit-tests target in dist-lite, this would
> happen with every build and immediate feedback is given if something
> breaks in the tests.
> The result would be that maintaining the main code line and unit test
> code line is a one stop shop.
>
> Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Include Unit Tests in regular build
Posted by Stefano Bagnara <ap...@bago.org>.
+1
Like maven does by deafult.
Stefano
Bernd Fondermann wrote:
> Hi,
>
> Currently, unit tests have to be run separate with
> "ant run-unit-tests"
>
> This makes it very easy to forget to run them prio to a commit.
> For me, unit tests are integral part of the quality management of the
> code base, not just an appendix on the outer rim of the James source
> code universe.
>
> If we would include the run-unit-tests target in dist-lite, this would
> happen with every build and immediate feedback is given if something
> breaks in the tests.
> The result would be that maintaining the main code line and unit test
> code line is a one stop shop.
>
> Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Emacs and Eclipse
Posted by Alan Donovan <ad...@csail.mit.edu>.
On Sat, Nov 11, 2006 at 11:19:20AM -0500, Noel J. Bergman wrote:
> > > > > I will think about using Eclipse when it has an editor worthy of
> > > > > being called one.
> > > > > Then you probably want to try Intellij IDEA.
> > > Really? Does it integrate with emacs -- The One True Editor? ;-)
>
> Also see:
> http://asynchronous.org/blog/archives/2004/11/17/mx_returntoemacs.html
>
> > Well, it is, let's say... the incarnation. ;-)
>
> I came across http://pag.csail.mit.edu/~adonovan/hacks/eclipse-emacs.html,
> but from the dates, I'm wondering if it still works with current Eclipse.
> Cc'ing the author to ask, but the changes in the Eclipse platform seemed to
> kill a lot of integration projects.
The code on my page works only with v2, breaks with v3 due to reliance
on "internal" classes.
I haven't had a chance to bring it up to date; I no longer use
Eclipse.
alan
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Include Unit Tests in regular build
Posted by Danny Angus <da...@gmail.com>.
On 11/11/06, Noel J. Bergman <no...@devtech.com> wrote:
> AIUI, your proposal means multiple jars (instead of just james.jar),
> multiple separate components,
Yes.
> and complicates refactoring/introduction of
> new internal modules. No?
No, it doesnlt have to. I understand why you wouldn't want to take my
word for it, but next time I see you I'll show you how it can be done.
We did exactly this at work, moved from 1big jar in an ear to dozens
of tiny ones in an ear, it really helps agility and testing.
>
> > James is a collection of such things, mostly we don't need to build
> > the whole thing over and over.
>
> And generally we don't, although I just changed that for a dist build, which
> should be built from scratch. The topic is running tests.
Yeah, we should only run tests on things which have changed. So the
scope of change is on topic.
> Selective testing would need to know the internal dependency graph in order
> to know if a change in a seemingly unrelated file requires running a test on
> a given component.
Yeah unless you are strict and unit test compliance with interfaces
and only test functionally and for integration later.
> Compile time and assembly level dependencies would need
> to be kept in synch with the test configuration, and that doesn't include
> tracking "hidden" dependencies, such as global services exposed via a
> locator. It can be done, but I'd consider it safer to just run all of the
> tests, except when a developer makes a conscious decision to run just one
> that he or she needs.
Those things are functional and integration tests, we were talking
about unit testing. I'm happy to talk about automated functional and
integration testing, but that is a very different kettle of fish..
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [DISCUSSION] Include Unit Tests in regular build
Posted by "Noel J. Bergman" <no...@devtech.com>.
Danny Angus wrote:
> 1/ Ant is the *only* sanctioned way to build James
> 2/ we should run the unit tests every time we build with ant
I've added the latter to the dist build. I think that the overhead is
excessive during development.
> > you're talking about adding 8 minutes to every build, instead of a few
seconds.
> > doing that will cause people [to] abort the tests, and won't provide the
> > desired results.
> Agreed, therfore we need to solve *that* problem, not abandon the use
> of the tests.
No one has ever suggested abandoning the use of the tests. The tests are
great to have, and improve (but are not sufficient to ensure) our ability to
deliver a trustworthy server
> > Show me tests that run in a few seconds instead of 8 minutes, and we
> > can talk about adding them to the build cycle.
> Sounds perfectly reasonable, and pretty much where I was trying to go with
this.
:-)
> > > One way to achieve this would be to break james out into many small
> > > library "projects"
> > So now we want to complicate the environment further to fix a spectre.
> No, it doesn't complicate things, it separates out concerns and allows
> people to focus on packages which have a single clear responsibility.
AIUI, your proposal means multiple jars (instead of just james.jar),
multiple separate components, and complicates refactoring/introduction of
new internal modules. No?
> James is a collection of such things, mostly we don't need to build
> the whole thing over and over.
And generally we don't, although I just changed that for a dist build, which
should be built from scratch. The topic is running tests.
Selective testing would need to know the internal dependency graph in order
to know if a change in a seemingly unrelated file requires running a test on
a given component. Compile time and assembly level dependencies would need
to be kept in synch with the test configuration, and that doesn't include
tracking "hidden" dependencies, such as global services exposed via a
locator. It can be done, but I'd consider it safer to just run all of the
tests, except when a developer makes a conscious decision to run just one
that he or she needs.
> In the meantime, I suggest that we do add the unit tests to the dist
target,
> and ask ourselves (social contract) to run the unit tests before
committing.
> Seems like a fine compromise.
The coding part of the plan is committed to svn.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Include Unit Tests in regular build
Posted by Danny Angus <da...@gmail.com>.
On 11/11/06, Noel J. Bergman <no...@devtech.com> wrote:
> > We should run the unit tests every time we build using ant, that is
> > the official way to build James.
Sorry my bad, I expressed myself badly.
1/ Ant is the *only* sanctioned way to build James
2/ we should run the unit tests every time we build with ant
> Since when? And ant is the only way I build JAMES, so you're talking about
> adding 8 minutes to every build, instead of a few seconds. As Bernd said,
> independent of me, doing that will cause people --- including me --- to
> abort the tests, and won't provide the desired results.
Agreed, therfore we need to solve *that* problem, not abandon the use
of the tests.
>
> Bernd suggested it specifically because he felt that Committers are not
> running the tests before committing changes. I don't actually think that
> has been a significant problem. Perhaps Bernd's suggestion was inspired by
> the recent change I made for which the unit test failed. In that case, I
> was testing the fix via other means than junit, and the unit test itself was
> in error; it took several times more time to fix the unit test than to fix
> JAMES.
Welcome to test driven development :-(
> And keep in mind Bernd's comment that he thinks that most of the guys are
> using an IDE, and so they would still able to do all of their builds without
> running the unit tests, anyway. Only if they run ant will they be "forced"
> to test. So it is a selective penalty without any real value.
I agree.
> > If running the tests is a problem because of the time taken, then we
> > should solve that problem first.
>
> Fine. Show me tests that run in a few seconds instead of 8 minutes, and we
> can talk about adding them to the build cycle.
Sounds perfectly reasonable, and pretty much where I was trying to go with this.
> > One way to achieve this would be to break james out into many small
> > library "projects"
>
> So now we want to complicate the environment further to fix a spectre.
No, it doesn't complicate things, it separates out concerns and allows
people to focus on packages which have a single clear responsibility.
James is a collection of such things, mostly we don't need to build
the whole thing over and over.
> I think that we would be better off focusing on real things. In the meantime,
> I suggest that we do add the unit tests to the dist target, and ask
> ourselves (social contract) to run the unit tests before committing.
Seems like a fine compromise.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Include Unit Tests in regular build
Posted by Bernd Fondermann <be...@googlemail.com>.
On 11/11/06, Noel J. Bergman <no...@devtech.com> wrote:
> Bernd suggested it specifically because he felt that Committers are not
> running the tests before committing changes. I don't actually think that
> has been a significant problem. Perhaps Bernd's suggestion was inspired by
> the recent change I made for which the unit test failed.
Inspired - yes. I noticed then, that I myself do often miss to run the
tests :-) About others, I don't know, until something breaks :-)
With this discussion, I also wanted to hightlight the importance of
our unit test code base.
If I get all comments right there is an unanimous consense that the
tests are regarded as fundamentally important. This test-aware mindset
is making me very happy and is much more important than actually
forcing the tests to be run.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [DISCUSSION] Include Unit Tests in regular build
Posted by "Noel J. Bergman" <no...@devtech.com>.
> We should run the unit tests every time we build using ant, that is
> the official way to build James.
Since when? And ant is the only way I build JAMES, so you're talking about
adding 8 minutes to every build, instead of a few seconds. As Bernd said,
independent of me, doing that will cause people --- including me --- to
abort the tests, and won't provide the desired results.
Bernd suggested it specifically because he felt that Committers are not
running the tests before committing changes. I don't actually think that
has been a significant problem. Perhaps Bernd's suggestion was inspired by
the recent change I made for which the unit test failed. In that case, I
was testing the fix via other means than junit, and the unit test itself was
in error; it took several times more time to fix the unit test than to fix
JAMES.
And keep in mind Bernd's comment that he thinks that most of the guys are
using an IDE, and so they would still able to do all of their builds without
running the unit tests, anyway. Only if they run ant will they be "forced"
to test. So it is a selective penalty without any real value.
> If running the tests is a problem because of the time taken, then we
> should solve that problem first.
Fine. Show me tests that run in a few seconds instead of 8 minutes, and we
can talk about adding them to the build cycle.
> One way to achieve this would be to break james out into many small
> library "projects"
So now we want to complicate the environment further to fix a spectre. I
think that we would be better off focusing on real things. In the meantime,
I suggest that we do add the unit tests to the dist target, and ask
ourselves (social contract) to run the unit tests before committing.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Include Unit Tests in regular build
Posted by Danny Angus <da...@gmail.com>.
Oh just listen to yourselves!
We should run the unit tests every time we build using ant, that is
the official way to build James.
Anything anyone does with any other tools is not our concern, we can't
control it so we should step back from getting involved.
If running the tests is a problem because of the time taken, then we
should solve that problem first. Not just give up.
One way to achieve this would be to break james out into many small
library "projects", that way you can narrow your focus to a single
area by depending upon the jars of the things you don't want to change
and therfore don't want to test. its what we do at work but we use
Maven because the repository plays a key part in this.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Include Unit Tests in regular build
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Stefano Bagnara wrote:
>
>> I think that using maven we could simply configure our pom to run unit
>> tests just before the scm:checkin target.
>
>> mvn -Dmessage="<commit_log_here>" scm:checkin
>
> How hard is to to run svn commit -m "<commit_log_here>"?
The point is that it is not harder or easier, but with maven you can
make it automatically execute tasks (check tests are running and even
more) if you want to ;-)
Furthermore using maven scm you have to learn a single way to manage the
repository, being it svn, cvs or something else.
I never used it, but now that I noticed such a plugin exists I think I
will use it much more, because I can't remember the usage of each scm
out there.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [DISCUSSION] Include Unit Tests in regular build
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> I think that using maven we could simply configure our pom to run unit
> tests just before the scm:checkin target.
> mvn -Dmessage="<commit_log_here>" scm:checkin
How hard is to to run svn commit -m "<commit_log_here>"?
> I don't know if a plugin for ant exists to manage commit/update tasks in
svn.
I don't know if ant needs one.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Include Unit Tests in regular build
Posted by Stefano Bagnara <ap...@bago.org>.
Stefano Bagnara wrote:
> A "command line fan" like you should be much
> more excited by maven than by ant: maven stands to ant like unix-shell
> stands to the dos prompt ;-)
I think that using maven we could simply configure our pom to run unit
tests just before the scm:checkin target.
---
mvn -Dmessage="<commit_log_here>" scm:checkin
This would be the best thing because it would force tests to pass before
to commit something.
Btw this, again, need mvn and not ant: I don't know if a plugin for ant
exists to manage commit/update tasks in svn.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [DISCUSSION] Include Unit Tests in regular build
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > We do have nightly builds.
> Right, but nighly means once per day (per night?)
> 1) often it happens after many hours from the commit
> 2) often multiple commits have been done and we need
> time to identify the bad commit
As I said, I can change the frequency. That's easy. But I don't know if
Infrastructure will allow anything to be linked into our svn server to drive
per-commit processing. We already have hooks for mail and selected
(Infrastructure required) operations.
> 3) the subject of the nighly build is always the same: to see that it
> fails you have to read the content.
> I like what continuum does: run the check often (every commit) and send
> the notification only if it fails or if the status changed from the
> previous (fail => success).
> If you can do this or something similar it would be cool!
I would still want to see the report on a daily basis, but for interim
builds during the day, the script could check to see if ant succeeded or
failed, and only mail when it fails. A bit more work, due to the script's
structure, but do-able.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [DISCUSSION] Include Unit Tests in regular build
Posted by "Noel J. Bergman" <no...@devtech.com>.
>>>> ant run-unit-test -Dtest=org.apache.james.smtpserver.SMTPServerTest
>>> I think that generally speaking it is not a good idea to complicate the
>>> build.xml with unused targets
>> And why is this bad, as opposed to the `mvn test -Dtest=SMTPServerTest`,
>> which you just suggested? And why would it be unused?
> You instead proposed to change our build.xml (if I understood you).
> This is different, isn't it?
A trivial change to build.xml vs adopting Maven? Oh yes, very different.
:-) Ant lets me do what I want, with a little effort. Maven lets you do
what they want, with no effort at all. ;-)
It was a trivial, one-time, change to build.xml. I've just commited it
after testing it. Sample below.
--- Noel
$ ant run-unit-test -Dtest=SMTPServerTest
Buildfile: build.xml
[...]
compile-unit-tests:
[echo] Compiling James Unit Test Java sources
ensure-test-name:
run-unit-test:
[echo] Running A Single James Unit Test
[junit] Running org.apache.james.smtpserver.SMTPServerTest
[junit] Tests run: 42, Failures: 0, Errors: 0, Time elapsed: 9.959 sec
[...]
BUILD SUCCESSFUL
Total time: 21 seconds
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Include Unit Tests in regular build
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Stefano Bagnara wrote:
>
>> +1 for the dist: it is where the real check has to be forced.
>> In other scenario it won't help forcing something.
>
> Agreed.
>
>> The long-running tests issues is solved using a decent CI environment.
>
> We do have nightly builds. And the nightly build pointed out the failed
> test.
Right, but nighly means once per day (per night?) and
1) often it happens after many hours from the commit
2) often multiple commits have been done and we need time to identify
the bad commit
3) the subject of the nighly build is always the same: to see that it
fails you have to read the content.
Only the first 3 issues I identified comparing current nightly builds vs
my continuum.
>> I have continuum monitoring the james repositories every 5 minutes
>
> I doubt that anyone wants for me to be posting automated results many times
> daily, but if that's what people want, I can adjust the cron job
> accordingly, although I'd only upload the builds once per day.
I like what continuum does: run the check often (every commit) and send
the notification only if it fails or if the status changed from the
previous (fail => success).
If you can do this or something similar it would be cool!
>> Does ASF provide infrastructure to put there our continuum?
>
> We already have GUMP, remember? And, yes, there is continuum running
> somewhere on the infrastructure.
GUMP is not the same: we already discussed it.
GUMP is intended to check integration between apache projects and not as
a continuos build/test tool specific to the Apache James projects.
As an example in this very moment GUMP is not testing james because of
jakarta-velocity failing. So it does not really help us for the issue we
are talking about.
>>> ant run-unit-test -Dtest=org.apache.james.smtpserver.SMTPServerTest
>
>> I think that generally speaking it is not a good idea to complicate the
>> build.xml with unused targets
>
> And why is this bad, as opposed to the `mvn test -Dtest=SMTPServerTest`,
> which you just suggested? And why would it be unused?
What I proposed does not need changes to our sources ;-)
You instead proposed to change our build.xml (if I understood you).
This is different, isn't it?
>> it would be interesting to have an overview of tools every james
>> committer use to work on james projects (platform, ide, compilers,
>> debuggers, profilers, svn tools and so on).
>
> ant, emacs, java, javac, svn
win, eclipse, jprofiler/netbeans profiler, clover, maven, ant (rarely svn)
>> 1) It was not a memory-leak: Wikipedia has a simple "Is it a memory
>> leak?" explanation: http://en.wikipedia.org/wiki/Memory_leak
>
> <<sigh>> From your link:
>
> a memory leak is a particular kind of unintentional memory
> consumption by a computer program where the program fails
> to release memory when no longer needed
>
> Memory consumed permanently for transient conditions meets that definition.
We have different opinion.
That cache is not lost: if an IP is looked up again later it will hit
the cache. Imho "unbounded cache" is a perfect definition for what we
had so I'll never misuse "memory leak" for this. I can efford the 4
additional chars needed ;-)
>> We simply said that you had no enough information to say "confirmed
>> memory leak in james": facts proved that there was no memory-leak,
>> and that the problem was not in james server code.
>
> The FACT is that there was an error (using InetAddress for resolution, which
> we already knew that we cannot use) that caused the heap to be consumed
> until JAMES crashed due to lack of memory. I would call that a problem.
> :-) Fortunately, I always keep my own counsel.
I agree that was an error: not a memory leak.
And in fact it was already fixed in trunk and I proposed a workaround
for 2.3.
You can tell what you want, but no one ever said that there was no error
in james. We simply said that the informations you provided within the
bug report was not enough to "confirm" a memory leak. And in fact I
still think we was 100% right.
> As I observed earlier, we could consider configuring JAMES to use a subclass
> of the dnsjava resolver for the JRE that is instrumented to log a warning if
> it is called. That would call out offending code, even in third party code.
This is a good idea, but I think that the "-D" workaround is enough to
consider this a "minor" issue. But you're idea is good, feel free to
implement it.
>> 6) If you used a real profiler (netbeans profiler, jprofiler or another
>> "real" tool and not a simple heap dump) it would have been much more
>> easy to find the problem
>
> The problem was very easy to find once I managed to keep the JVM from
> crashing, which ended up just meaning cranking the heap size to 256MB (and
> also limiting the dnsjava cache). And it was necessary to do it in a
> production environment, not some toy lab testbench.
>
> --- Noel
Jprofiler and netbeans profiler can be used also on the real production
environment, not only in "toy labs". IN fact they give you much more
data in the same time you had instrumented the production environment
for heap profiling. But you are your own judge, I just suggested tools
that make me work much faster: of course you have to learn them, and
this is a cost.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [DISCUSSION] Include Unit Tests in regular build
Posted by "Noel J. Bergman" <no...@devtech.com>.
Noel J. Bergman wrote:
> Stefano Bagnara wrote:
> > +1 for the dist: it is where the real check has to be forced.
> > In other scenario it won't help forcing something.
I am committing a change to build.xml that forces two additional targets to
run when doing a dist build. It forces a clean, first, so that any
distribution build is done from a clean state. I always do that, anyway,
and it is a best practice. The second target is the agreed upon
run-unit-tests.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [DISCUSSION] Include Unit Tests in regular build
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> +1 for the dist: it is where the real check has to be forced.
> In other scenario it won't help forcing something.
Agreed.
> The long-running tests issues is solved using a decent CI environment.
We do have nightly builds. And the nightly build pointed out the failed
test.
> I have continuum monitoring the james repositories every 5 minutes
I doubt that anyone wants for me to be posting automated results many times
daily, but if that's what people want, I can adjust the cron job
accordingly, although I'd only upload the builds once per day.
> Does ASF provide infrastructure to put there our continuum?
We already have GUMP, remember? And, yes, there is continuum running
somewhere on the infrastructure.
> > ant run-unit-test -Dtest=org.apache.james.smtpserver.SMTPServerTest
> I think that generally speaking it is not a good idea to complicate the
> build.xml with unused targets
And why is this bad, as opposed to the `mvn test -Dtest=SMTPServerTest`,
which you just suggested? And why would it be unused?
> it would be interesting to have an overview of tools every james
> committer use to work on james projects (platform, ide, compilers,
> debuggers, profilers, svn tools and so on).
ant, emacs, java, javac, svn
> 1) It was not a memory-leak: Wikipedia has a simple "Is it a memory
> leak?" explanation: http://en.wikipedia.org/wiki/Memory_leak
<<sigh>> From your link:
a memory leak is a particular kind of unintentional memory
consumption by a computer program where the program fails
to release memory when no longer needed
Memory consumed permanently for transient conditions meets that definition.
> We simply said that you had no enough information to say "confirmed
> memory leak in james": facts proved that there was no memory-leak,
> and that the problem was not in james server code.
The FACT is that there was an error (using InetAddress for resolution, which
we already knew that we cannot use) that caused the heap to be consumed
until JAMES crashed due to lack of memory. I would call that a problem.
:-) Fortunately, I always keep my own counsel.
As I observed earlier, we could consider configuring JAMES to use a subclass
of the dnsjava resolver for the JRE that is instrumented to log a warning if
it is called. That would call out offending code, even in third party code.
> 6) If you used a real profiler (netbeans profiler, jprofiler or another
> "real" tool and not a simple heap dump) it would have been much more
> easy to find the problem
The problem was very easy to find once I managed to keep the JVM from
crashing, which ended up just meaning cranking the heap size to 256MB (and
also limiting the dnsjava cache). And it was necessary to do it in a
production environment, not some toy lab testbench.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Include Unit Tests in regular build
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
>> To make everyone happy, why not have a default goal, which runs tests,
>> builds james, etc. And one goal which compiles james too, just without
>> the tests.
>
> For what benefit? How hard would it be to run `ant dist-liter` instead of
> `ant`. That doesn't address the "problem", if there even is a problem (I
> don't believe that there actually is one).
>
> I do suggest that we add the unit tests to the dist target, which is the one
> that builds the packages.
+1 for the dist: it is where the real check has to be forced.
In other scenario it won't help forcing something.
The long-running tests issues is solved using a decent CI environment.
I have continuum monitoring the james repositories every 5 minutes and
trying to build/test everything after each commit: this make it really
easy to find out what break tests.
In fact I'm the one that notified the list about the test problem, and
it was notified to me by the continuos build server.
Does ASF provide infrastructure to put there our continuum?
If it helps I can add the server-dev to the notified addresses but the
mail is almost 100KB and continuum will notify once a SUCCESSFUL build
serie, but will notify FAILUREs for each commit until fixed.
> [...]
>> If the tests failed, he can examine which test failed an run this test
>> alone. Modify his source, run it alone until it passes.
>
> Or the test. As we've seen, sometimes it is the test that is broken. And
> we still need to add support for running individual tests, e.g.,
>
> ant run-unit-test -Dtest=org.apache.james.smtpserver.SMTPServerTest
I think that generally speaking it is not a good idea to complicate the
build.xml with unused targets (it seems that we all use an IDE, but
you). Btw I also think we are a bunch of committers and everyone should
have an easy way to work on the project.
That said if adding the "-Dtest" option to build.xml helps you, then
feel free to do that. Remember this when someone else will propose to
add eclipse's .classpath/.project files ;-)
I also think it would be interesting to have an overview of tools every
james committer use to work on james projects (platform, ide, compilers,
debuggers, profilers, svn tools and so on).
If noone but you needs this target in build.xml you should assign the
JIRA issue to yourself to be sure we (bad guys) won't close it as won't fix.
Do you know what is the cool thing? *Maven* provides
"test:single"/"test:match" targets without the need to clobber the
project build definition. A "command line fan" like you should be much
more excited by maven than by ant: maven stands to ant like unix-shell
stands to the dos prompt ;-)
>> ... and everyone is happy for a, long believed not to be there, memory
> leak fix.
>
> Totally unrelated to this discussion. That memory leak would not have been
> detected by unit tests, at least not as we have them. Testing that would
> have required simulating connections from many separate IP addresses, and a
> fake DNS provider inserted underneath java.net.InetAddress. Or a more
> thorough audit of the code, perhaps with a DNS provider that warns that it
> is called at all. Over-reliance on unit tests and presumption that if it
> didn't occur in their environment then it didn't exist is why no one else
> believed that it existed at all. What resolved that problem was my
> personality in the face of everyone else wanting to close the bug as
> invalid, and my performing extended heap evaluations on a production server.
1) It was not a memory-leak: Wikipedia has a simple "Is it a memory
leak?" explanation: http://en.wikipedia.org/wiki/Memory_leak
2) It was an unbounded cache and it was not in james code.
3) No one ever said there was no problem. We simply said that you had no
enough information to say "confirmed memory leak in james": facts proved
that there was no memory-leak, and that the problem was not in james
server code.
4) No one ever said that james is good because tests passed.
5) *I* replied to your "Confirmed but unidentified memory leak in RC2"
message I said: "we may simply make misuse/abuse of the memory because
of *non-weak* *caches* with *bad* *defaults* or similar things":
http://www.mail-archive.com/server-dev@james.apache.org/msg09908.html
I also wrote "Btw, I don't care of this formal discussions. I'm
interested in resolving this bug. I think I did everything I could have
done with the informations you provided, so I will wait for you."
So you can't simply say that we ignored you. STOP. I spent a lot of time
(probably more than the time you spent on this issue) trying to
reproduce this issue.
6) If you used a real profiler (netbeans profiler, jprofiler or another
"real" tool and not a simple heap dump) it would have been much more
easy to find the problem and this would have helped both you and us to
fix this issue for 2.3.0 final.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [DISCUSSION] Include Unit Tests in regular build
Posted by "Noel J. Bergman" <no...@devtech.com>.
> To make everyone happy, why not have a default goal, which runs tests,
> builds james, etc. And one goal which compiles james too, just without
> the tests.
For what benefit? How hard would it be to run `ant dist-liter` instead of
`ant`. That doesn't address the "problem", if there even is a problem (I
don't believe that there actually is one).
I do suggest that we add the unit tests to the dist target, which is the one
that builds the packages.
> That way non-IDE Developers, using only true editors and the command line,
can
> compile without the tests to see if their modifications compile. Before
they
> check-in they should run ant again with the default goal
Why would this happen with any more frequency than `ant run-unit-tests`?
Either one requires a specific action that is additional to the build
process.
> If the tests failed, he can examine which test failed an run this test
> alone. Modify his source, run it alone until it passes.
Or the test. As we've seen, sometimes it is the test that is broken. And
we still need to add support for running individual tests, e.g.,
ant run-unit-test -Dtest=org.apache.james.smtpserver.SMTPServerTest
> ... and everyone is happy for a, long believed not to be there, memory
leak fix.
Totally unrelated to this discussion. That memory leak would not have been
detected by unit tests, at least not as we have them. Testing that would
have required simulating connections from many separate IP addresses, and a
fake DNS provider inserted underneath java.net.InetAddress. Or a more
thorough audit of the code, perhaps with a DNS provider that warns that it
is called at all. Over-reliance on unit tests and presumption that if it
didn't occur in their environment then it didn't exist is why no one else
believed that it existed at all. What resolved that problem was my
personality in the face of everyone else wanting to close the bug as
invalid, and my performing extended heap evaluations on a production server.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
AW: [DISCUSSION] Include Unit Tests in regular build
Posted by Jürgen Hoffmann <jh...@byteaction.de>.
Hi Danny,
> One way to achieve this would be to break james out into many small
> library "projects", that way you can narrow your focus to a single
> area by depending upon the jars of the things you don't want to change
> and therfore don't want to test. its what we do at work but we use
> Maven because the repository plays a key part in this.
maven + emacs ... are not so close friends ;-)
Fun aside.
To make everyone happy, why not have a default goal, which runs tests,
builds james, etc.
And one goal which compiles james too, just without the tests. That way
non-IDE Developers, using only true editors and the command line, can
compile without the tests to see if their modifications compile. Before they
check-in they should run ant again with the default goal, go and grab a cup
of coffee, and reconcile about what they have just accomplished.
When they are finished, they hopefully see that all tests have passed, and
check their stuff in. If the tests failed, he can examine which test failed
an run this test alone. Modify his source, run it alone until it passes.
Then time for another coffee and a little reminiscence of good old times.
All tests pass ... check in ... and everyone is happy for a, long believed
not to be there, memory leak fix.
Does that sound like a reasonable solution for everyone?
Kind regards
Juergen
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Emacs and Eclipse
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > > > I will think about using Eclipse when it has an editor worthy of
> > > > being called one.
> > > > Then you probably want to try Intellij IDEA.
> > Really? Does it integrate with emacs -- The One True Editor? ;-)
Also see:
http://asynchronous.org/blog/archives/2004/11/17/mx_returntoemacs.html
> Well, it is, let's say... the incarnation. ;-)
I came across http://pag.csail.mit.edu/~adonovan/hacks/eclipse-emacs.html,
but from the dates, I'm wondering if it still works with current Eclipse.
Cc'ing the author to ask, but the changes in the Eclipse platform seemed to
kill a lot of integration projects.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Include Unit Tests in regular build
Posted by Bernd Fondermann <be...@googlemail.com>.
On 11/11/06, Noel J. Bergman <no...@devtech.com> wrote:
> Bernd Fondermann wrote:
>
> > > And I will think about using Eclipse when it has an editor worthy of
> being
> > > called one.
>
> > Then you probably want to try Intellij IDEA.
>
> Really? Does it integrate with emacs -- The One True Editor?
Well, it is, let's say... the incarnation. ;-)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [DISCUSSION] Include Unit Tests in regular build
Posted by "Noel J. Bergman" <no...@devtech.com>.
Bernd Fondermann wrote:
> > And I will think about using Eclipse when it has an editor worthy of
being
> > called one.
> Then you probably want to try Intellij IDEA.
Really? Does it integrate with emacs -- The One True Editor?
> But we are drifting away into religious topics... ;-)
Ya think? ;-)
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Include Unit Tests in regular build
Posted by Bernd Fondermann <be...@googlemail.com>.
On 11/11/06, Noel J. Bergman <no...@devtech.com> wrote:
> Bernd Fondermann wrote:
> > Agreed. While developing, only relevant tests should be run.
>
> > Many people achive this by letting the IDE compile (incrementally) and
> > run only tests they choose.
>
> > But those developing using command line could get annoyed.
>
> Exactly.
>
> And I will think about using Eclipse when it has an editor worthy of being
> called one.
Then you probably want to try Intellij IDEA. All is within the reach
of just one keystroke.
It is the absolute productivity booster, but takes time to learn.
But we are drifting away into religious topics... ;-)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Include Unit Tests in regular build
Posted by Joachim Draeger <jd...@joachim-draeger.de>.
Am Samstag, den 11.11.2006, 01:02 +0100 schrieb Bernd Fondermann:
> > Except for one thing ... a build takes a few seconds, even from scratch, and
> > the unit tests take anywhere from 3 minutes on up, especially the very slow
> > IMAP-related tests.
>
> Slow tests are a unit test anti-pattern on its own ;-)
Right. Those tests are more integration tests than unit tests. Tests
that involve much JavaMail and much Derby will always take its time. :-)
I don't like the idea of tuning existing tests just because they are too
slow. I would not mind moving them to a special TestSuite.
I hope for some real unit tests when having a deeper look at the IMAP
code.
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [DISCUSSION] Include Unit Tests in regular build
Posted by "Noel J. Bergman" <no...@devtech.com>.
Bernd Fondermann wrote:
> Agreed. While developing, only relevant tests should be run.
> Many people achive this by letting the IDE compile (incrementally) and
> run only tests they choose.
> But those developing using command line could get annoyed.
Exactly.
And I will think about using Eclipse when it has an editor worthy of being
called one.
> > Although I appreciate your reasoning, I'm against it. The tests just
take
> > too long, and are far too annoying when someone is working in a
particular
> > area of the server.
> Slow tests are a unit test anti-pattern on its own ;-)
> and would lead to people disabling tests altogether in their local env.
I just said as much in a follow up message, where I also put some numbers to
the topic. Adding the tests to the dist target, though, seems perfectly
reasonable.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Include Unit Tests in regular build
Posted by Bernd Fondermann <be...@googlemail.com>.
On 11/10/06, Noel J. Bergman <no...@devtech.com> wrote:
> > Currently, unit tests have to be run separate with
> > "ant run-unit-tests"
>
> > This makes it very easy to forget to run them prio to a commit.
>
> But that's not the highest duty cycle. I agree that people should run the
> tests before they commit, but forgettfulness is not sufficient justification
> to increase development time by many-fold.
Agreed. While developing, only relevant tests should be run.
Many people achive this by letting the IDE compile (incrementally) and
run only tests they choose.
But those developing using command line could get annoyed.
>
> > If we would include the run-unit-tests target in dist-lite, this would
> > happen with every build and immediate feedback is given if something
> > breaks in the tests.
>
> Except for one thing ... a build takes a few seconds, even from scratch, and
> the unit tests take anywhere from 3 minutes on up, especially the very slow
> IMAP-related tests.
Slow tests are a unit test anti-pattern on its own ;-)
>
> Although I appreciate your reasoning, I'm against it. The tests just take
> too long, and are far too annoying when someone is working in a particular
> area of the server.
... and would lead to people disabling tests altogether in their local env.
mmhhh....
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Include Unit Tests in regular build
Posted by Norman Maurer <nm...@byteaction.de>.
+1
Norman
Stefano Bagnara schrieb:
> +1
>
> Like maven does by deafult.
>
> Stefano
>
> Bernd Fondermann wrote:
>> Hi,
>>
>> Currently, unit tests have to be run separate with
>> "ant run-unit-tests"
>>
>> This makes it very easy to forget to run them prio to a commit.
>> For me, unit tests are integral part of the quality management of the
>> code base, not just an appendix on the outer rim of the James source
>> code universe.
>>
>> If we would include the run-unit-tests target in dist-lite, this would
>> happen with every build and immediate feedback is given if something
>> breaks in the tests.
>> The result would be that maintaining the main code line and unit test
>> code line is a one stop shop.
>>
>> Bernd
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
> !EXCUBATOR:1,455450f853076972244038!
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [DISCUSSION] Include Unit Tests in regular build
Posted by "Noel J. Bergman" <no...@devtech.com>.
Bernd Fondermann wrote:
> should be easy to write some plug-in for vim/emacs to run a single
> unit test, shouldn't it?
The direct approach would be to add something to our ant script.
> IDEs are at their best if they support you fully on working on the
> developers current stuff _only_.
IDEs generally have editors that suck. That tends to be the weakest link.
> That means: Just compile the relevant + changed files, just run the
> specific test (not test class, the test method!)
Yes, I am very familar with Eclipse. Too bad that every project to provide
it with a decent editor has failed.
> > > JUnit has some stand-alone utilities for this (test runner).
> > Something that we can integrate with ant?
> not as far as I know.
See http://today.java.net/pub/a/today/2003/09/12/individual-test-cases.html
And it appears that the <test name="${test.class.name}" /> element of the
<junit> task may be a solution, too.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Include Unit Tests in regular build
Posted by Bernd Fondermann <be...@googlemail.com>.
On 11/11/06, Noel J. Bergman <no...@devtech.com> wrote:
> Bernd Fondermann wrote:
>
> > > By the way, is there a way to run a single, specific, unit test?
>
> > In IDEs like Eclipse
>
> Let's talk about real tools (i.e., emacs and javac) shall we? ;-)
should be easy to write some plug-in for vim/emacs to run a single
unit test, shouldn't it? ;-)
IDEs are at their best if they support you fully on working on the
developers current stuff _only_.
That means: Just compile the relevant + changed files, just run the
specific test (not test class, the test method!)
>
> > JUnit has some stand-alone utilities for this (test runner).
>
> Something that we can integrate with ant?
not as far as I know.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [DISCUSSION] Include Unit Tests in regular build
Posted by "Noel J. Bergman" <no...@devtech.com>.
Bernd Fondermann wrote:
> > By the way, is there a way to run a single, specific, unit test?
> In IDEs like Eclipse
Let's talk about real tools (i.e., emacs and javac) shall we? ;-)
> JUnit has some stand-alone utilities for this (test runner).
Something that we can integrate with ant?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Include Unit Tests in regular build
Posted by Bernd Fondermann <be...@googlemail.com>.
On 11/10/06, Noel J. Bergman <no...@devtech.com> wrote:
> By the way, is there a way to run a single, specific, unit test?
In IDEs like Eclipse with JUnit integration this is only a right mouse
click away.
JUnit has some stand-alone utilities for this (test runner).
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Include Unit Tests in regular build
Posted by Bernd Fondermann <be...@googlemail.com>.
On 11/11/06, Noel J. Bergman <no...@devtech.com> wrote:
> > Except for one thing ... a build takes a few seconds, even from scratch,
> and
> > the unit tests take anywhere from 3 minutes on up, especially the very
> slow
> > IMAP-related tests.
>
> To put this in perspective, on my normal working environment, the unit tests
> take almost 8 minutes to run. If we put them into the standard build
> target, I'll end up ^C-ing out of the build and just being annoyed.
>
> On the nightly build server, a dual core Athlon 3800 X2, we went from 1
> minute to over 3 minutes. I used that server today, since I did about 20
> builds while playing with the TCP/IP backlog test, and wasting an hour of my
> time waiting for the superfluous tests when I only wanted to run one (which
> happens after the dreadfully slow IMAP tests) was not something I enjoyed.
> And that was when I *wanted* to run a unit test --- but only one.
That is a limitation of monolithic build test round trip you are using
for ordinary-every-day development.
See the other part of this thread about running a single unit tests.
> I have no issue about adding the unit tests to the dist target.
ok.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Include Unit Tests in regular build
Posted by Stefano Bagnara <ap...@bago.org>.
> Stefano Bagnara wrote:
>> mvn test -Dtest=SMTPServerTest
>
> Ant, apparently, supports the same.
> --- Noel
No. Ant needs 20 custom lines in the build.xml: they have to be mantained.
It is not the same :-)
Btw I think that even things that make one single active committer more
happy are good to the project.
So it's OK to me to have 20 more lines to be mantained: but it is not
the same as maven2 would give us.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [DISCUSSION] Include Unit Tests in regular build
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> > By the way, is there a way to run a single, specific, unit test?>
> I bet you thought to something [using ant]
Yes, our build tool.
> mvn test -Dtest=SMTPServerTest
Ant, apparently, supports the same.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [DISCUSSION] Include Unit Tests in regular build
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> By the way, is there a way to run a single, specific, unit test?
>
> --- Noel
I bet you thought to something starting with the letters "a", "n" and
"t".. but you didn't specify it, so here is the answer:
mvn test -Dtest=SMTPServerTest
:-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [DISCUSSION] Include Unit Tests in regular build
Posted by "Noel J. Bergman" <no...@devtech.com>.
By the way, is there a way to run a single, specific, unit test?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [DISCUSSION] Include Unit Tests in regular build
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Except for one thing ... a build takes a few seconds, even from scratch,
and
> the unit tests take anywhere from 3 minutes on up, especially the very
slow
> IMAP-related tests.
To put this in perspective, on my normal working environment, the unit tests
take almost 8 minutes to run. If we put them into the standard build
target, I'll end up ^C-ing out of the build and just being annoyed.
On the nightly build server, a dual core Athlon 3800 X2, we went from 1
minute to over 3 minutes. I used that server today, since I did about 20
builds while playing with the TCP/IP backlog test, and wasting an hour of my
time waiting for the superfluous tests when I only wanted to run one (which
happens after the dreadfully slow IMAP tests) was not something I enjoyed.
And that was when I *wanted* to run a unit test --- but only one.
I have no issue about adding the unit tests to the dist target.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [DISCUSSION] Include Unit Tests in regular build
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Currently, unit tests have to be run separate with
> "ant run-unit-tests"
> This makes it very easy to forget to run them prio to a commit.
But that's not the highest duty cycle. I agree that people should run the
tests before they commit, but forgettfulness is not sufficient justification
to increase development time by many-fold.
> If we would include the run-unit-tests target in dist-lite, this would
> happen with every build and immediate feedback is given if something
> breaks in the tests.
Except for one thing ... a build takes a few seconds, even from scratch, and
the unit tests take anywhere from 3 minutes on up, especially the very slow
IMAP-related tests.
Although I appreciate your reasoning, I'm against it. The tests just take
too long, and are far too annoying when someone is working in a particular
area of the server.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org