Hello OFBiz Dev Members, Sharing a quick update on the JUnit 5 (Jupiter) integration tests independent of JUnit 3 in Apache OFBiz trunk codebase:
Reference PR: https://github.com/apache/ofbiz-framework/pull/1648 1) Jupiter (JUnit 5) integration tests no longer impersonate JUnit 3 to get reported — the old classes that translated every JUnit 5 event back into junit.framework.TestResult calls are gone, replaced by execution through the real JUnit Platform Launcher. 2) A new shared reporting interface is now the single contract both JUnit 3 and Jupiter feed, backed by a XML writer producing the exact same schema Ant's formatter did, so the report generators needed zero changes. 3) ant-junit is fully dropped from the build now that its only consumer, the old Ant-based XML formatter, no longer exists. 4) Jupiter report rows carry real class and method names instead of a shared synthetic class with the real name jammed into a string prefix, so they read exactly like JUnit 3 rows already did. 5) A suite mixing junit-test-suite and jupiter-test-suite entries still produces one merged report with test-cases in the exact order declared in testdef XML, with no separate merge step. 6) A whole-branch review caught and fixed three real bugs on the failure path that a passing run alone could never surface, including one where a single illegal character in a failure message could make an entire suite's results unparseable and silently vanish from the report. 7) Verified with a full, non-cached run: 43 of 43 testIntegration suites and 644 tests passing, 611 unit tests passing, and checkstyle/codenarc clean across the branch. In last few days, I worked in the following files: *New files:* SuiteReportSink.java - The shared reporting contract both engines feed: startSuite / testStarted / testFinished / endSuite, plus a nested sealed Outcome (Passed / Failure / Error) replacing either vendor's own result type. SuiteEntry.java - Sealed Junit3Entry / JupiterEntry pair replacing List<junit.framework.Test> as what a parsed <test-suite> actually contains. SuiteXmlReportWriter.java - Hand-written XML writer, byte-for-byte the same <testsuite>/<testcase> schema Ant's XMLJUnitResultFormatter produced — so the report generators need zero changes. Junit3ResultBridge.java - The one remaining sanctioned junit.framework.TestListener. Translates unchanged JUnit 3 execution into SuiteReportSink calls — JUnit 3 itself doesn't move, only its reporting output does. SuiteReportLogger.java - Renamed from TestRunContainer's old JunitListener inner class; now also absorbs the old end-of-suite Debug.log summary that used to live as static methods on TestRunContainer. ReportingSupport.java - Extracted during final review: a stackTraceOf() / sink-fanout dispatch() helper pair that had been copy-pasted across three files. SuiteReportSinkTest.java - Unit tests for the Outcome factories. SuiteEntryTest.java - Unit tests confirming each entry type carries its payload correctly. SuiteXmlReportWriterTest.java - Parses the writer's own output back through a real DOM parser and asserts structure — not string-matching — against the Ant-compatible shape. Junit3ResultBridgeTest.java - Runs real pass/fail/error junit.framework.TestCase's through the bridge, asserts correct sink calls. RecordingSink.java - Shared in-memory SuiteReportSink test fixture reused by three different test classes. JupiterClassRunnerTest.java - Replaces the scenarios pulled out of JupiterInjectionGuardsTest: throwing @BeforeAll, an exception escaping launcher.execute() staying isolated to its own entry, @Disabled exclusion, ABORTED handling. *Modified files:* JupiterTestExtension.java - The center of the refactor: JupiterTestSuite / JupiterLeafTest deleted outright, replaced by JupiterClassRunner, which executes via the real Platform Launcher and reports real class/method names directly. Net: -307 lines, and zero junit.framework.* references left in the file — confirmed by grep, the whole point of this work. TestRunContainer.java - The per-suite loop rewritten as a directly-unit-testable static method, runSuiteEntries(), dispatching each SuiteEntry to the right engine and feeding both to the same sink instances. Old JunitListener inner class and static logging helpers removed (moved into SuiteReportLogger). ModelTestSuite.java - testList retyped from List<junit.framework.Test> to List<SuiteEntry>. makeTestSuite() removed, replaced by a plain accessor, getPreparedTestList(). Gained getDispatcher(), symmetric with the existing getDelegator() — a gap the plan itself hadn't accounted for, caught by an implementer mid-task. JunitSuiteWrapper.java - Test list retyped to SuiteEntry. Deleted the already-@Deprecated, zero-caller populateTestSuite(TestSuite) outright. JupiterTestHelper.java - Javadoc reference to the now-deleted JupiterTestSuite repointed to JupiterClassRunner. JupiterInjectionGuardsTest.java - Trimmed by 202 lines: the container-failure / class-execution-failure scenarios moved to the new JupiterClassRunnerTest.java. What's left is purely the ParameterResolver injection-guard tests the name promises. TestRunContainerTest.java - Adapted to assert against the new sink API instead of the old TestResult-based one. dependencies.gradle - ant-junit:1.10.17 dropped — its only consumer, TestRunContainer's XMLJUnitResultFormatter usage, no longer exists. gradle/libs.versions.toml - The corresponding ant-junit version entry removed. test-reports.gradle - The HTML report's Test column now renders SimpleClassName.methodName instead of a bare method name — needed because the classname-baked-into-name hack this refactor removes was, until now, the only class context the table had. This closes out one of the larger items from the JUnit 5 (Jupiter) improvements that I envisioned few months back for Apache OFBiz project -- happy to answer questions or point to the design doc for anyone curious about the internals. Thank you! 👍🙏 -- Kind Regards, Ashish Vijaywargiya Vice President of Operations *HotWax Systems* *Enterprise open source experts* http://www.hotwaxsystems.com On Tue, Aug 11, 2026 at 4:06 PM Chandan Khandelwal < [email protected]> wrote: > Great work, Ashish! Thanks for the JUnit 5 migration and the improved test > reports. Very useful improvements! > > Kind Regards, > Chandan Khandelwal > Senior Manager, Enterprise Software Development > > *HotWax Systems* > *Enterprise open source experts* > cell: +91-98934-81076 > office: 0731-409-3684 > http://www.hotwaxsystems.com > > > On Sat, Aug 8, 2026 at 7:08 PM Ashish Vijaywargiya < > [email protected]> wrote: > > > Hello Dev Members, > > > > Sharing a quick update on the JUnit test migration effort: > > > > 1) Retired the legacy Ant-based JUnit Integration Tests report > completely; > > Gradle-based reporting is now the only test report generated. > > > > 2) Reskinned Gradle's native unit test HTML report under > > build/reports/tests/test to match the integration test report's theme, so > > both now share a consistent look. > > > > 3) Retitled both reports with JUnit (Jupiter) branding, with an > idempotency > > fix so re-running tests keeps titles correct. > > > > Here are the screenshots from Integration Tests and JUnit Tests. > > > > > > > https://drive.google.com/file/d/1MtgVh_4f37sqGJh7a6vw5VhuaIJvcBap/view?usp=sharing > > > > > > > https://drive.google.com/file/d/1I6oRAD5PhrOYlEN_jk2rEBTerSz77xlb/view?usp=sharing > > > > > > > https://drive.google.com/file/d/17OIfNJSSU_BUnyPN9XGC-IHPRShWW28W/view?usp=sharing > > > > Below PR: This has been merged in the OFBiz trunk code base. Please pull > > the code from trunk and see the results on your end. > > > > https://github.com/apache/ofbiz-framework/pull/1605 > > > > -- > > Kind Regards, > > Ashish Vijaywargiya > > Vice President of Operations > > *HotWax Systems* > > *Enterprise open source experts* > > http://www.hotwaxsystems.com > > > > > > > > On Fri, Aug 7, 2026 at 10:41 PM Divesh Dutta < > > [email protected]> > > wrote: > > > > > Super, the new UI looks cool. > > > > > > Thanks > > > -- > > > Divesh Dutta > > > -- > > > www.hotwaxsystems.com > > > > > > > > > On Fri, Aug 7, 2026 at 12:53 PM Ashish Vijaywargiya < > > > [email protected]> wrote: > > > > > > > Hello Dev Members, > > > > > > > > I have added a modern new UI for the JUnit Integration Test Results > in > > > the > > > > Apache OFBiz project. Hopefully, you will like it as much as I do! 🙂 > > > > > > > > Please take a look at the new JUnit Reports UI here: > > > > > > > > > > > > > > https://drive.google.com/drive/folders/1Mcg83h07TxpHHluCZ0V0QM9dTtQA_D2a?usp=drive_link > > > > > > > > The Ant-based old JUnit Test Reports will be there as is for some > time > > in > > > > the OFBiz project. > > > > I will be deleting the old test reports format in the upcoming days. > > > > > > > > PR: https://github.com/apache/ofbiz-framework/pull/1584 > > > > > > > > The following points are covered in this commit/push. > > > > > > > > Add modern JUnit5 test reports (single-page and framed) and fix a > > testdef > > > > suite-name casing mismatch(just following the naming convention in > one > > > test > > > > suite name) > > > > > > > > 1. Add a createModernTestReport Gradle task that runs alongside the > > > > existing createTestReports (Ant-style) task > > > > > > > > 2. Parse the JUnit suite XML output into structured data shared by > both > > > new > > > > report renderers > > > > > > > > 3. Render a single filterable HTML page summarizing all suites and > > their > > > > test cases > > > > > > > > 4. Extract shared summary/detail rendering and add a URL-safe suite > > slug > > > > for reuse across report pages > > > > > > > > 5. Add a navigable framed report (suite list plus per-suite detail > > pages) > > > > alongside the single-page and Ant reports > > > > > > > > 6. Clear the framed report output directory before each run so stale > > > > suite-*.html pages cannot linger from earlier runs > > > > > > > > 7. Add per-suite summary cards > > > > (tests/failures/errors/skipped/time/timestamp/host) to both new > > reports, > > > > matching the classic report's per-class summary > > > > > > > > 8. Purge stale suite XML before each test run so reports never blend > > > > results from an earlier run with the current one > > > > > > > > 9. Share CSS/JS across the framed report's pages via > > > > junit-report.css/junit-report.js instead of duplicating them on every > > > page > > > > > > > > 10. Escape suite names before writing them into the framed report's > > > > title/heading > > > > > > > > 11. Sort suites by their reported name instead of by filename, and > > guard > > > > the summary totals against an empty suite list > > > > > > > > 12. Lowercase MinilangTests' suite-name/case-name for consistency > with > > > the > > > > naming used by the other test suites, and rename the testdef file to > > > match > > > > > > > > 13. Extract the modern/framed test report tasks and their helpers out > > of > > > > build.gradle into test-reports.gradle, applied from build.gradle so > it > > > > still runs on every Gradle invocation > > > > > > > > -- > > > > Kind Regards, > > > > Ashish Vijaywargiya > > > > Vice President of Operations > > > > *HotWax Systems* > > > > *Enterprise open source experts* > > > > http://www.hotwaxsystems.com > > > > > > > > > > > > > > > > On Mon, Aug 3, 2026 at 12:14 PM Ashish Vijaywargiya < > > > > [email protected]> wrote: > > > > > > > > > Hello Dev Members, > > > > > > > > > > Following up on my July 31 update, I'm glad to report that the > JUnit > > 3 > > > to > > > > > JUnit 5 (Jupiter) migration for Apache OFBiz Integration tests is > now > > > > > complete. Last week I migrated the remaining JUnit3 integration > test > > > > files > > > > > in the "applications" and "framework" folders, *which closes out > the > > > plan > > > > > I shared then and the broader vision from my original May 2026 > thread > > > on > > > > > modernizing our JUnit tooling - * > > > > > https://lists.apache.org/thread/ssh1m7s3qyn3126qm0q7d7n6shrvmcw2*. > * > > > > > > > > > > 1) Applications folder is fully migrated (PR #1541): all 62 > > > testdef-wired > > > > > JUnit3 test classes across accounting, content, manufacturing, > > > marketing, > > > > > order, party, product, and workeffort converted to Jupiter, using > the > > > > > JupiterTestHelper/JunitJupiterTest infrastructure introduced in PR > > > #1529. > > > > > > > > > > 2) Framework folder is fully migrated (PR #1542): all 20 > > testdef-wired > > > > > JUnit3 test classes across base, common, entity, minilang, > rest-api, > > > > > service, webapp, and widget were converted to Jupiter. > > > > > > > > > > 3) This migration also cleaned up along the way: 27 test files that > > > were > > > > > sitting under src/main instead of src/test got moved to their > correct > > > > > location (manufacturing 3, order 5, product 3 in applications; > common > > > 1, > > > > > entity 4, minilang 1, rest-api 1, service 8, widget 1 in > framework), > > > and > > > > 7 > > > > > dead no-op setUp()/tearDown() overrides were removed. > > > > > > > > > > 4) Real value beyond the mechanics: converting applications' tests > > > > > surfaced 8 pre-existing test-order-dependency bugs that JUnit 3's > > > > > nondeterministic method ordering had been silently masking - > > > > > manufacturing/ProductionRunTests, order/QuoteTests, party (3x), and > > > > > product/ProductTest. Each was verified as pre-existing, then fixed. > > > > > Jupiter's deterministic @Order is what made these visible in the > > first > > > > > place. > > > > > > > > > > 5) Combined with the plugins migration (PR #344: assetmaint, > > ecommerce, > > > > > lucene, scrum) and the infrastructure work (PR #1529), every real > > > JUnit3 > > > > > integration test file that existed across framework, applications, > > and > > > > > plugins now runs on JUnit5 Jupiter - on top of the JUnit4-to-JUnit6 > > > > upgrade > > > > > for standard unit tests completed back in May (PR #1301). Together, > > > this > > > > > brings our full test estate - unit and integration, framework, > > > > > applications, and plugins - onto actively maintained JUnit tooling. > > > > > > > > > > 6) Every migrated suite was verified via scoped and full > > > testIntegration > > > > > runs, all passing with 0 failures/errors. A small follow-up (PR > > #1543) > > > > also > > > > > fixed the noframes test-report output so HTML report generation > stays > > > > > consistent. > > > > > > > > > > 7) On my laptop, `./gradlew testIntegration` runs faster on trunk > > > > > (JUnit5-based) than on release24.09 (JUnit3-based): 86.929s vs > > > 113.327s. > > > > > `./gradlew test` shows a similar pattern: 22.638s vs 27.250s. These > > are > > > > > single-machine numbers, not a formal benchmark, but a promising > > signal. > > > > > > > > > > 8) With this, I consider my JUnit modernization work for Apache > OFBiz > > > > > complete, covering everything I set out to do in the May 2026 > thread: > > > > unit > > > > > tests on JUnit 6, and integration tests across framework, > > applications, > > > > and > > > > > plugins on JUnit 5 (Jupiter). > > > > > > > > > > Thank you, everyone for the feedback and support across my previous > > > > conversations > > > > > - it helped keep this moving. > > > > > > > > > > PRs: > > > > > https://github.com/apache/ofbiz-framework/pull/1529 > > > > > https://github.com/apache/ofbiz-framework/pull/1541 > > > > > https://github.com/apache/ofbiz-framework/pull/1542 > > > > > https://github.com/apache/ofbiz-framework/pull/1543 > > > > > https://github.com/apache/ofbiz-plugins/pull/344 > > > > > > > > > > As always, happy to help with any JUnit5/Jupiter-related questions > or > > > > > issues that come up. > > > > > I will provide quick assistance. > > > > > > > > > > *Note:* I am working on a document for the Apache OFBiz wiki for > this > > > > > JUnit 3 to JUnit 5 migration. I will share the document soon. > > > > > > > > > > Thank you! > > > > > > > > > > -- > > > > > Kind Regards, > > > > > Ashish Vijaywargiya > > > > > Vice President of Operations > > > > > *HotWax Systems* > > > > > *Enterprise open source experts* > > > > > http://www.hotwaxsystems.com > > > > > > > > > > > > > > > > > > > > On Sun, Aug 2, 2026 at 12:23 PM Ashish Vijaywargiya < > > [email protected] > > > > > > > > > wrote: > > > > > > > > > >> Thank you Arun! 🙏💐 > > > > >> > > > > >> -- > > > > >> Regards, > > > > >> Ashish Vijaywargiya > > > > >> > > > > >> On Fri, 31 Jul 2026 at 14:47, Arun Patidar < > [email protected]> > > > > >> wrote: > > > > >> > > > > >> > Great initiative, Ashish. This is a much-needed improvement for > > the > > > > >> OFBiz > > > > >> > integration testing ecosystem. > > > > >> > > > > > >> > +1 > > > > >> > > > > > >> > Regards, > > > > >> > Arun Patidar > > > > >> > > > > > >> > > > > > >> > On Fri, Jul 31, 2026 at 11:19 AM Ashish Vijaywargiya < > > > > >> > [email protected]> wrote: > > > > >> > > > > > >> > > Hello Apache OFBiz Dev Members, > > > > >> > > > > > > >> > > I have been working on adding JUnit 5 (Jupiter) support to > > > > >> > > framework/testtools, and using it to migrate every remaining > > > JUnit3 > > > > >> test > > > > >> > > file in the plugins folder. I want to share why this matters > and > > > > what > > > > >> it > > > > >> > > makes possible, and get the OFBiz community input before I > look > > at > > > > the > > > > >> > much > > > > >> > > larger applications folder. > > > > >> > > > > > > >> > > Taken together, this moves Apache OFBiz's Integration Testing > > > > >> capability > > > > >> > > from moderate to genuinely extensive - parameterized tests, > > > explicit > > > > >> > > lifecycle control, deterministic execution ordering, and > > fail-fast > > > > >> > > diagnostics now run natively against the very same entity and > > > > service > > > > >> > > engine our business logic already depends on, directly inside > > the > > > > real > > > > >> > > integration container rather than a mocked-out substitute. > > > > >> > > > > > > >> > > *Why move off JUnit 3* > > > > >> > > > > > > >> > > 1) JUnit 3 test classes are invisible to plain gradlew test > > today > > > - > > > > >> > > dependencies.gradle registers only the junit-jupiter-engine, > > with > > > no > > > > >> > > junit-vintage-engine bridge, so a JUnit3 class never appears > in > > a > > > > >> gradlew > > > > >> > > test run as passed, failed, or even skipped; it is simply > never > > > > >> > discovered, > > > > >> > > and every one of our ~86 remaining JUnit3 files has been > > silently > > > > >> relying > > > > >> > > on that gap for years. > > > > >> > > > > > > >> > > 2) JUnit 3 forces every test class to extend > > > > >> > > TestCase/EntityTestCase/OFBizTestCase and discovers tests by > > > > >> reflection > > > > >> > on > > > > >> > > a testXxx naming convention, so there is no real lifecycle, no > > > > >> > > parameterization, and no way to add a test-only helper without > > > > adding > > > > >> it > > > > >> > to > > > > >> > > the shared base class. > > > > >> > > > > > > >> > > 3) JUnit 3 has been unmaintained for past many years, while > > JUnit > > > 5 > > > > is > > > > >> > the > > > > >> > > actively developed, industry-standard test framework most > > > > contributors > > > > >> > > already know, which lowers the ramp-up cost for anyone new to > > the > > > > >> OFBiz > > > > >> > > codebase. > > > > >> > > > > > > >> > > 4) Some of our JUnit3 files are not really integration tests > at > > > all > > > > - > > > > >> a > > > > >> > > scan of all 86 candidate files found four (DateUelTest, > > > MathUelTest, > > > > >> > > MiscUelTest, StringUelTest in framework/base) that never touch > > the > > > > >> entity > > > > >> > > or service engine, yet still pay the full ofbiz --test > container > > > > boot > > > > >> > cost > > > > >> > > on every run purely because of the inherited constructor > > > convention; > > > > >> > > migrating those to plain Jupiter tests lets them run in > seconds > > > > under > > > > >> > > gradlew test instead of minutes under testIntegration, and > that > > > > >> migration > > > > >> > > has already been merged. > > > > >> > > > > > > >> > > 5) The migration does not force a rewrite of anything - > > > > >> junit-test-suite > > > > >> > > and jupiter-test-suite test-cases run side by side inside the > > > exact > > > > >> same > > > > >> > > test-suite, sharing the same Delegator/LocalDispatcher and the > > > same > > > > >> > > suite-level rollback, so JUnit3 files keep working exactly as > > > before > > > > >> for > > > > >> > as > > > > >> > > long as we want them to. > > > > >> > > > > > > >> > > *What the new infrastructure gives Integration tests > > specifically* > > > > >> > > > > > > >> > > 6) JunitJupiterTest is a composed annotation that keeps a > > > > >> > container-backed > > > > >> > > Jupiter test out of plain gradlew test (via a > jupiterIntegration > > > tag > > > > >> > > exclusion) while still registering it for testIntegration > > through > > > a > > > > >> new > > > > >> > > jupiter-test-suite testdef element, so the two Gradle > pipelines > > > stay > > > > >> > > cleanly separated. > > > > >> > > > > > > >> > > 7) JupiterTestHelper is a mixin interface that gives > > > getDelegator(), > > > > >> > > getDispatcher(), getUserLogin(), from(), and select() with > zero > > > > >> > constructor > > > > >> > > and zero field boilerplate, so a migrated test class becomes a > > > plain > > > > >> POJO > > > > >> > > instead of being forced into the OFBizTestCase inheritance > > chain. > > > > >> > > > > > > >> > > 8) @Test methods get real, descriptive, free-form names > instead > > of > > > > >> being > > > > >> > > constrained to a testXxx prefix, and @Disabled lets a test be > > > turned > > > > >> off > > > > >> > > with a visible, reported reason instead of being commented out > > or > > > > >> > silently > > > > >> > > deleted. > > > > >> > > > > > > >> > > 9) @ParameterizedTest with @CsvSource lets one method cover > many > > > > input > > > > >> > > variations, replacing the copy-pasted > testFoo1/testFoo2/testFoo3 > > > > style > > > > >> > > still common across the JUnit3 suite. > > > > >> > > > > > > >> > > 10) Method execution order is now explicit and enforced > > > project-wide > > > > >> via > > > > >> > > MethodOrderer.OrderAnnotation, closing a real gap in JUnit 3, > > > which > > > > >> never > > > > >> > > guaranteed any method order at all; converting scrum's test > > files > > > > >> > surfaced > > > > >> > > a genuine pre-existing bug that depended on JUnit 3's > > > undocumented, > > > > >> > > accidentally-stable reflection order, and @Order made that > > > > dependency > > > > >> > > visible and fixable instead of silently masked. > > > > >> > > > > > > >> > > 11) A Jupiter test class with no JunitJupiterTest annotation > and > > > no > > > > >> > > JupiterTestHelper needs no OFBiz container at all and runs > > > directly > > > > >> under > > > > >> > > gradlew test, so the same infrastructure now supports both > true > > > unit > > > > >> > tests > > > > >> > > and container-backed integration tests cleanly, something the > > old > > > > >> > > OFBizTestCase-based model could never offer. > > > > >> > > > > > > >> > > 12) Every injection failure mode fails loudly instead of > > silently > > > - > > > > >> > running > > > > >> > > outside the container, enabling unsupported parallel > execution, > > or > > > > >> > > misnaming a delegator/dispatcher field all throw a clear, > > specific > > > > >> error > > > > >> > at > > > > >> > > the injection site now, backed by a dedicated > > > > >> JupiterInjectionGuardsTest, > > > > >> > > instead of surfacing later as a confusing null pointer. > > > > >> > > > > > > >> > > *Where things stand and what is next* > > > > >> > > > > > > >> > > 13) The infrastructure itself (JupiterTestExtension, > > > > >> JupiterTestHelper, > > > > >> > > JunitJupiterTest, the jupiter-test-suite testdef element) is > > > > >> implemented, > > > > >> > > hardened, and already proven on real business logic, not just > > the > > > > >> > > example plugin > > > > >> > > - all four migrated plugins suites (assetmaint, ecommerce, > > lucene, > > > > >> scrum) > > > > >> > > pass in full under testIntegration. > > > > >> > > > > > > >> > > 14) The plugins folder is now fully migrated - all twelve > > > remaining > > > > >> real > > > > >> > > JUnit3 test files across assetmaint, ecommerce, lucene, and > > scrum > > > > have > > > > >> > been > > > > >> > > converted to Jupiter, with the plugins/example component's > > > original > > > > >> > JUnit3 > > > > >> > > test kept intentionally in place as a side-by-side > > old-versus-new > > > > >> > > reference. > > > > >> > > > > > > >> > > 15) The applications folder is intentionally not next as a > > > mandatory > > > > >> > sweep > > > > >> > > - there are roughly 86 JUnit3 files and 555 test methods left > > > there, > > > > >> and > > > > >> > > the plan is to keep migration opportunistic, converting a file > > > only > > > > >> when > > > > >> > > there is already a concrete reason to touch it, rather than a > > > > >> mechanical > > > > >> > > bulk PR that would conflict with everyone else's in-flight > work. > > > > >> > > > > > > >> > > 16) I plan to let the JUnit5-based Integration tests in > plugins > > > soak > > > > >> for > > > > >> > > the next few days before starting on applications, and would > > > welcome > > > > >> > > thoughts from anyone who has opinions on scope, pace, or files > > > worth > > > > >> > > prioritizing first. > > > > >> > > > > > > >> > > PRs: > > > > >> > > https://github.com/apache/ofbiz-framework/pull/1529 > > > > >> > > https://github.com/apache/ofbiz-plugins/pull/344 > > > > >> > > > > > > >> > > I look forward to getting the OFBiz community's support on > this > > > > JUnit > > > > >> > > 5(Jupiter) migration initiative for integration tests in > Apache > > > > OFBiz. > > > > >> > > > > > > >> > > Thank you! 👍 > > > > >> > > > > > > >> > > -- > > > > >> > > Kind Regards, > > > > >> > > Ashish Vijaywargiya > > > > >> > > Vice President of Operations > > > > >> > > *HotWax Systems* > > > > >> > > *Enterprise open source experts* > > > > >> > > http://www.hotwaxsystems.com > > > > >> > > https://www.linkedin.com/in/ashishvijaywargiya/ > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > > > > > >
