On 2002.09.19 19:32:25 -0400 Scott M Stark wrote: > I still don't buy it. Many of the existing tests involve several > functional modules > so how do I associate the test with its module?
I see your point, many of the "jmx" tests that test system module functionality rely on ejbs, etc etc, to provide a sufficient environment. The compilation issue is > a simple > by product of having a huge monolithic build file, and further > complicated by > xdoclet having to be run as a first pass to generate the code. I better > not wake > up one morning and have the testsuite laying in pieces in CVS without a > clear > consensus on this approach. So are you suggesting that there be, more or less, a build file per testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then the testsuite/build.xml calls each of them? I think that would accomplish essentially the same thing I was suggesting with the generic targets for "run xdoclet in one directory" and "build jars from one directory" suggestion. Smaller build files might be easier to understand individually, but might also be significantly slower. The ant 1.5.1 include task might help, we could include the specific xdoclet and jar targets from small build files while keeping a single global javac task. david jencks > > xxxxxxxxxxxxxxxxxxxxxxxx > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxxxxxxxxxxxxxxxxxxxxxx > > ----- Original Message ----- > From: "David Jencks" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, September 19, 2002 4:15 PM > Subject: Re: [JBoss-dev] Build System... any ideas > > > > On 2002.09.19 18:05:46 -0400 Scott M Stark wrote: > > > Add -Dnojars=true during the run of the single test and zero > compilation > > > time is the result. > > > > Umm, yes, I know about nojars, I wrote it. > > > > It doesn't help much if you changed the test and need to recompile, the > > situation I find time consuming. > > > > > Add -Djbosstest.nodeploy=true and you can also avoid having to deploy > the > > > tests > > > into the server. > > > > Doesn't this require you to copy the appropriate test jar into the > deploy > > directory? Are there any deployments that take a significant amount of > > time? > > > > I routinely run single tests in 10 seconds with these > > > options. Refactoring > > > the entire testsuite for a simple usage problems is silly. > > > > Having to spend 7 minutes to try a simple change to a test is a lot > > sillier. > > > > > > > > > > Breaking up the huge monolithic build file into seperates test files > > > would be a good thing. > > > This is what we had in 2.4 and it was nice when we had < 200 tests. > Now > > > as we > > > approach 1000 its time to revisit this as well. > > > > Agreed, this is a better solution, but also more work. I think the > > test/module in the modules is the way to go here. > > > > david jencks > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
