Re: Why jtreg
Hi Zsolt, Create a pull request and I’ll merge it in Thanks Dennis > On Aug 10, 2020, at 7:15 AM, Zsolt Kúti wrote: > > > Hi guys, > > Based on the SVN and Dennis' git repos, I now have a local git repo that > contains a gradlefied new test module. It accomplishes little for the time > being: > - follows River's gradle project format > - rectified (removed unused imports, corrected some package definitions etc.) > that prevented compiling > - can now be compiled > > I planned to create at least one working Spock unit test to see how it works > out, but unfortunately was overwhelmed with other duties. > I thought that moving unit tests to their respective modules may come in a > later phase, or as soon as a new test is created. > > Now, before leaving for long holidays it may be the time to merge this work > to somewhere. > Should I make my own github repo and put these changes there? I do not know > how pull request on Dennis' would work with large number of files/changes (~ > 5000). > > Ideas? > > Zsolt > >> On Tue, Jul 14, 2020 at 12:23 AM Peter Firmstone >> wrote: >> Why not indeed :) >> >> I'd be in favour of moving "unit tests" out of the jtreg and qa tests >> suites into junit first . I'd suggesting leaving the jtreg bug >> regression tests where they are for now at least, as far more work is >> required and they may not all be relevant; we no longer have bug >> descriptions or information on these bug's, as Oracle has removed them >> from the Sun bug database. I have looked into the undocumented >> regression tests previously, some are very difficult to figure out. I >> have made some attempts at recovering information on older bugs for >> these regression tests from release notes of earlier versions of Jini, >> but haven't had much luck, requests for information from Oracle go >> unanswered. >> >> The tests can be broken down into: >> >> 1. Unit tests - simple tests that don't need more than one running jvm, >> eg a lookup service, or activation and don't require a >> SecurityManager (maybe junit is ok with a security manager? Just >> need appropriate policy files?). >> 2. Integration tests - requires multiple jvm's, eg testing network >> functionality (typically in the qa suite). >> 3. Bug regression tests - testing a known, or often in our case, an >> undocumented bug. >> >> River never received an upload of the Sun bug database relating to Jini, >> Oracle has long since made it inaccessible. Many of the bug regression >> tests in jtreg lack documentation, I guess there might be some >> information in the Jini users mail list archives. >> >> I'd suggest grabbing the low hanging fruit first. >> >> Cheers, >> >> Peter. >> >> On 7/14/2020 6:58 AM, Dennis Reedy wrote: >> > As the title says, why use jtreg? We have modern test frameworks (Junit, >> > Spock, etc...). Asd we move forward with River, why not migrate tests to >> > use these? >> > >> > Regards >> > >> > Dennis Reedy >> >
Re: Why jtreg
Hi guys, Based on the SVN and Dennis' git repos, I now have a local git repo that contains a gradlefied new test module. It accomplishes little for the time being: - follows River's gradle project format - rectified (removed unused imports, corrected some package definitions etc.) that prevented compiling - can now be compiled I planned to create at least one working Spock unit test to see how it works out, but unfortunately was overwhelmed with other duties. I thought that moving unit tests to their respective modules may come in a later phase, or as soon as a new test is created. Now, before leaving for long holidays it may be the time to merge this work to somewhere. Should I make my own github repo and put these changes there? I do not know how pull request on Dennis' would work with large number of files/changes (~ 5000). Ideas? Zsolt On Tue, Jul 14, 2020 at 12:23 AM Peter Firmstone < peter.firmst...@zeus.net.au> wrote: > Why not indeed :) > > I'd be in favour of moving "unit tests" out of the jtreg and qa tests > suites into junit first . I'd suggesting leaving the jtreg bug > regression tests where they are for now at least, as far more work is > required and they may not all be relevant; we no longer have bug > descriptions or information on these bug's, as Oracle has removed them > from the Sun bug database. I have looked into the undocumented > regression tests previously, some are very difficult to figure out. I > have made some attempts at recovering information on older bugs for > these regression tests from release notes of earlier versions of Jini, > but haven't had much luck, requests for information from Oracle go > unanswered. > > The tests can be broken down into: > > 1. Unit tests - simple tests that don't need more than one running jvm, > eg a lookup service, or activation and don't require a > SecurityManager (maybe junit is ok with a security manager? Just > need appropriate policy files?). > 2. Integration tests - requires multiple jvm's, eg testing network > functionality (typically in the qa suite). > 3. Bug regression tests - testing a known, or often in our case, an > undocumented bug. > > River never received an upload of the Sun bug database relating to Jini, > Oracle has long since made it inaccessible. Many of the bug regression > tests in jtreg lack documentation, I guess there might be some > information in the Jini users mail list archives. > > I'd suggest grabbing the low hanging fruit first. > > Cheers, > > Peter. > > On 7/14/2020 6:58 AM, Dennis Reedy wrote: > > As the title says, why use jtreg? We have modern test frameworks (Junit, > > Spock, etc...). Asd we move forward with River, why not migrate tests to > > use these? > > > > Regards > > > > Dennis Reedy > > >
Re: Your project website
Hi Andrew, As no reaction has arrived until now, I, as probably the last one who dealt with our website, take the liberty of answering. Yes, our project uses Apache CMS [see here: https://river.apache.org/user-doc/website.html]. I hope somebody is going to step up for being a contact and/or for transferring our website content to one of the alternatives. If not, I'll be around somewhen in September, after back from my holidays and may do what is needed for it. Thanks for contacting us and offering help! Zsolt On Fri, Aug 7, 2020 at 2:51 PM Andrew Wetmore wrote: > Hi: > > I am part of the Infrastructure team, and am writing to ask whether your > project is still using the Apache CMS for your project website. As you > know, the CMS is reaching end-of-life, and we need projects to move their > websites onto a different option within the next few weeks. > > There are several alternatives available, including those listed on this > page [1] on managing project websites. Infra is assembling a Wiki page [2] > on migrating a website from the CMS, and is looking forward to helping > projects with this transition. > > Please let me know whether your site is still on the Apache CMS and, if so, > who will be the project point-of-contact with Infra for the migration. > > Thank you! > > > > > [1] https://infra.apache.org/project-site.html > > [2] > > https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS > > > -- > Andrew Wetmore > > http://cottage14.blogspot.com/ > > > > > > < > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > Virus-free. > www.avast.com > < > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >
