Question ad creating a testcase that needs a jar on class- or module path

Rony G. Flatscher Rony.Flatscher at
Mon Feb 17 15:40:20 UTC 2020

Over the weekend I was finally able to finalize the test unit in form of a module. Kept it as simple
as possible (but it includes a pseudo script engine).

May I just ask a few questions, before proceeding with submitting one or two PRs:

  * Every new program needs the Oracle license header at the top?

  * Would it be o.k. to dual license (AL 2.0 for the pseudo scripting engine)?

      o If not (it probably would introduce noise and problems) it would not be a real problem as I
        always can create a separate package using only the code that was authored by myself.

  * Where shall I explain/document how the test unit works, here in the mailing list or with the PR?

      o If the latter, then it would probably be a good idea to submit the test unit separately from
        the PR for fixing the bug as that will have its own set of explanations/documentations
        (briefly discussing the three scenarious how a script controller may define scripts and why
        the filenames were picked the way they are).

  * Maybe the explanations/documentations for the bug fix should be posted here upfront for discussion?


On 03.02.2020 15:04, Rony G. Flatscher wrote:

> Hi Kevin,
> On 31.01.2020 16:38, Kevin Rushforth wrote:
>> And if you need a modular jar, you might look at ModuleLauncherTest instead.
> thank you very much for this important hint as well!
> Having no knowledge about gradle it will take me a while to research and digest, but this definitely
> helps me to jump start to the section where tests get carried out with separately configured JVMs.
> Would it be o.k. to first submit a pull request for JDK-8234959
> <> and later, when an appropriate test unit using
> the SPI dependent pseudo script engine is available submitting the test app with different pull
> request? Or would it be better to submit both with the same pull request?
> ---rony

More information about the openjfx-dev mailing list