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/[email protected]/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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
