Hmmm, the patches that I supplied for Junit4 *require* 4.7 anyway, which I included in the patch... Is this a problem? Or just a document problem?
Erick On Wed, Nov 25, 2009 at 1:14 PM, Mark Miller <markrmil...@gmail.com> wrote: > junit 4 parallelization is still in its infancy. I think the docs for it > are just in the changes file that it was first released with. That > version had severe bugs that made it almost unusable - I think thats > mostly fixed in a newer release. There is also a much better impl of one > of the key classes (I think they call it computer) written by someone > else that will eventually go into the code base I think (written by the > guy(s) that I think found/fixed the initial buggy-ness) - essentially, I > think its still unbaked. > > Here are some docs from the release notes of 4.6: > > http://sourceforge.net/project/shownotes.php?release_id=675664&group_id=15278 > > Thats also an issue - it arrived only in 4.6 - so this would need to be > optional unless we bumped up our req from 4 - and it really requires at > least 4.7 for the fixes (if everything is even fixed). > > You also have to setup which tests run in parallel by hand essentially. > No ant task to help with this last I looked. So it will probably end up > being an alternate way to run the tests initially (at best). > > - Mark > > Erick Erickson wrote: > > They're ready to go, but at Uwe's suggestion, I've been waiting for > > 3.0 to get settled before prompting someone to apply this patch. I was > > going to generate a new patch for this and for 2037 (junit4 tests) > > just to make sure they were easy to apply. But if you're willing, the > > patches are already attached to the JIRA issues. Do note that the > > decision in MinBooleanShouldMatch to stop checking the query after 100 > > rather than checking all 1,000 is included in the patch.... > > > > Do you want to apply the patches or should I regenerate? It's no big > > deal to regenerate them and I'll have a better feel for reconciling > > any conflicts. I don't know whether there even *are* any conflicts, > > but just in case.... > > > > For my info, though, if I have a more recent patch that *replaces* an > > earlier patch, especially one that hasn't yet been applied, is it > > preferred to delete the earlier patch when providing a new one? > > > > I'm not pleased with the Junit4 documentation, most of what I've been > > able to glean has come from brave souls blogging. Does anyone have a > > gold mine or is it as hit-or-miss as I think? There are hints of > > parallelization capabilities in Junit4, but I'm having a hard time > > finding anything in much depth..... The Junit website is pathetic, I > > can't even find 4.7 javadocs, it keeps giving me 4.5, as evidenced by > > no @Rule docs or @Intercept. And no version information in the > > javadocs..... Or I'm completely missing the boat.... I was thinking > > about getting the entire project over the weekend and generating my > > own if I have the time > > > > Erick > > > > On Wed, Nov 25, 2009 at 11:49 AM, Michael McCandless (JIRA) > > <j...@apache.org <mailto:j...@apache.org>> wrote: > > > > > > [ > > > https://issues.apache.org/jira/browse/LUCENE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782497#action_12782497 > > < > https://issues.apache.org/jira/browse/LUCENE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782497#action_12782497 > > > > ] > > > > Michael McCandless commented on LUCENE-1844: > > -------------------------------------------- > > > > Is this ready to go in? I'd really love to see unit tests run > > faster :) > > > > > Speed up junit tests > > > -------------------- > > > > > > Key: LUCENE-1844 > > > URL: > > https://issues.apache.org/jira/browse/LUCENE-1844 > > > Project: Lucene - Java > > > Issue Type: Improvement > > > Reporter: Mark Miller > > > Attachments: FastCnstScoreQTest.patch, > > hi_junit_test_runtimes.png, LUCENE-1844.patch > > > > > > > > > As Lucene grows, so does the number of JUnit tests. This is > > obviously a good thing, but it comes with longer and longer test > > times. Now that we also run back compat tests in a standard test > > run, this problem is essentially doubled. > > > There are some ways this may get better, including running > > parallel tests. You will need the hardware to fully take > > advantage, but it should be a nice gain. There is already an issue > > for this, and Junit 4.6, 4.7 have the beginnings of something we > > might be able to count on soon. 4.6 was buggy, and 4.7 still > > doesn't come with nice ant integration. Parallel tests will come > > though. > > > Beyond parallel testing, I think we also need to concentrate on > > keeping our tests lean. We don't want to sacrifice coverage or > > quality, but I'm sure there is plenty of fat to skim. > > > I've started making a list of some of the longer tests - I think > > with some work we can make our tests much faster - and then with > > parallelization, I think we could see some really great gains. > > > > -- > > This message is automatically generated by JIRA. > > - > > You can reply to this email to add a comment to the issue online. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > > <mailto:java-dev-unsubscr...@lucene.apache.org> > > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > <mailto:java-dev-h...@lucene.apache.org> > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
