<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.18.3">
</HEAD>
<BODY>
Jaikiran Pai p&#237;&#353;e v Po 28. 11. 2011 v 15:05 +0530:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Comments inline.
</PRE>
</BLOCKQUOTE>
-&quot;-<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Since these flags apply to the EAP testing, why 
not have a specific script which deals with all these flags and that 
script can then be used for EAP testing? 
</PRE>
</BLOCKQUOTE>
Well, since the testsuite is maven-based, the script can only use what's really in pom.xml's.<BR>
I could move some steps (e.g. server config) to the script.<BR>
But I think that having all in one place is beneficial: If a bug in EAP is found, then it's easy for the developer to reproduce - they'll simply use same set of maven properties.<BR>
<BR>
Maybe my words &quot;more and more&quot; scared you a bit :)&nbsp;&nbsp; It's not that bad, especially after splitting to modules, the pom.xml's are not that hard to read anymore.<BR>
And since we have gone the modularized way, I can keep the functionality outside of scope of the &quot;normal&quot; build, i.e. not include some modules at all - only for EAP builds / test runs.<BR>
<BR>
What I mean is:<BR>
testsuite<BR>
&nbsp; + integration<BR>
&nbsp;&nbsp;&nbsp;&nbsp; + configure-database<BR>
&nbsp;&nbsp;&nbsp;&nbsp; + configure-ipv6<BR>
&nbsp;&nbsp;&nbsp;&nbsp; + group-smoke<BR>
&nbsp;&nbsp;&nbsp;&nbsp; + group-basic<BR>
&nbsp;&nbsp;&nbsp;&nbsp; + group-iiop<BR>
<BR>
And activate the submodules on demand.<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
My point is not about adding 
these new flags but is more about having to expect the non-QA developers 
(for whom those are irrelevant) to understand and use these flags for 
the builds.
</PRE>
</BLOCKQUOTE>
Actually, I try not to change the behavior unless someone asks for some change - that's the case of -DskipTests btw.<BR>
I didn't assume anyone relying on that.<BR>
And, this was not in testsuite requirements, which we discussed for a while on this list.<BR>
But as I wrote - it's coming back.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>

&gt; But I can keep you uninformed and keep the testsuite running without 
&gt; changes of &quot;API&quot; if that helps.
I guess, you meant informed. Yes, that would help - if adding the flags 
helps QA testing but doesn't have any impact on the &quot;API&quot; and helps keep 
the testsuite running, then I have no objection to those changes/flags.
</PRE>
</BLOCKQUOTE>
Okay. How about others?<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
&gt;&gt;   The actual
&gt;&gt; question for this specific issue is what's the real usecase of skipping
&gt;&gt; unit tests (which potentially can have failures) but still want to run
&gt;&gt; the integration tests?
&gt; Often it happens that some unit tests fail and block one step AS build 
&gt; &amp; testsuite execution.
So far I haven't seen any unit test fail in AS7 (and if some of them are 
failing then those need to be fixed). Yes, there are integration test 
failures which are intermittent. But those issues need to be fixed. Like 
I said in my earlier reply, building the entire project by using 
-DskipTests (to skip all tests) and then cd testsuite/integration; mvn 
clean install (to run the integration tests) is what you are looking for 
in such cases. Ofcourse it's a 2 step process but to me that's more 
logical (and can even be added to a script) than adding and integrating 
some new property.
</PRE>
</BLOCKQUOTE>
Okay. Someone from QA wanted to be able to run in one step due to some Jenkins issue with Maven-based build, I'll discuss that.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>

&gt; And let me ask the other way around - what is the use case of 
&gt; -DskipTests, skipping all tests?
Yes.
</PRE>
</BLOCKQUOTE>
That was like a part of the question - what is the use case of skipping _all_ tests?<BR>
* As you said, unit tests should be rock solid and you rarely see a failure.<BR>
* So you skip tests to make the build faster, not because of unit tests failures.<BR>
* So you'd probably like to skip testsuite module to make it even faster.<BR>
Then I don't understand why you dislike the idea of having a separated flag to skip the testsuite. ?<BR>
<BR>
<BR>
Ondra
</BODY>
</HTML>