[rfc] [icedtea-web] blacklist for reproducers
jvanek at redhat.com
Thu Apr 12 10:37:18 PDT 2012
On 04/12/2012 06:39 PM, Omair Majid wrote:
> On 04/12/2012 08:05 AM, Jiri Vanek wrote:
>>> [ snip lots of analysis ]
> So I am going to preface this email by pointing out that I like the
> overall change that you are proposing. Most of my
> arguments/disagreements/suggestions are about minute details. Perhaps
> you should just ignore them :)
>> So here is my suggestion, why so, see inline below. Namely the changes are:
>> * jnlp_testengine renamed to testsExtensions, and remains in tests
> This is probably going into the area of bikeshedding, but I feel the
> current name is better. Looking at existing names, I would be happy with
> jnlp-test-engine (jnlp-test-runner, or maybe even jnlp-runner).
But this is not true. The runner is still junit-runner and nothing else.
The content of jnlp_testengine is currently nothing more then dummy implementation of http server, and set of methods which make work with this server easy.
And what is it else then junit extension, if it set of util methods for running this server executing process, wrapping those two into launching some jnlp/html file upon this server in javaws/browser process?
And if some more functionalities (annotations in short term) will come, then it will be more and more set of..."extensions"... then just engine launching jnlp files.
Another issue here is that also html files are launched now. I would like (at least) to get rid of jnlp from name.
Yes, this is bikeshedding but i do not want to make some more refactoring in close future.
But it does not mean i like my suggested name to much;)
>> * all tests from jnlp_testengine are dedicated to
> I am guessing you meant 'moved'.
>> * testsExtensions I would like to pack into junit-runner.jar
> Is this necessary? I would like to keep them separate. When I originally
no. Just comfortable :)
> wrote the code for junit-runner (licensed under CPL), I intentionally
> kept it separate from the rest of the (L)GPL(+Classpath) code.
Yap. I have forgot of this license issue. I will stay away from merging this two packages together then.
>> * directory jnlp_tests have been renamed to reproducers and moved from
>> tests to tests/netx
> Sounds fantastic!
>>> And I agree; jnlp_testengine contains too much and does not really
>>> belong there.
>> Yap I have renamed it to testsExtensions (or tests-extensions?) For now
>> this extension is just virtual server and few util methods, But with eg
>>  or  there will be little bit more, and there always can be more
>> extensions necessary in future.
> Hm.. I don't know what's the right thing to do here. But I feel like
> extensions for testing (that is, extra annotations, utility methods)
> should be kept separate from the test engine (which just runs tests).
And they are. As told above. the test engine (which just runs tests) is junit-runner. jnlp-testengine is right the extension as you mean it.
>>>> 1) move all tests from tests/netx/jnlp_testsengine to tests/netx/unit
>>>> where they belongs IMHO
>>> A slightly different approach might be to move jnlp_testsengine itself
>>> to a top level directory in icedtea-web.
>> Hmhm. I'm against top level directory. Overall - it is still just for
>> testing, so it should stay in tests. Also there is eg junit-runner in
>> tests. Those two subdirectories (junit-runner and testsExtensions)
>> should be on same level.
> My reasoning for moving it to a top level directory is that it needs
> tests, while junit-runner doesn't :)
Can I ignore this reason as you wrote on the top of this email? O:)
/me hopes he does not to sounds impolitely
>>> jnlp_testsengine isn't a test
>>> itself so I would be happy if we moved it out from under tests/. I dont
>>> think moving the tests from tests/netx/jnlp_testsengine to
>>> tests/netx/unit is a good idea; they are not netx's tests. How about
>>> creating another directory (jnlp_testengine under tests/) to contain
>>> tests for the jnlp_engine itself? (which are distinct from netx's or the
>>> plugin's tests).
>> Aboslutly agree:)
>> So what about testsExtensionsTests (or tests-extensions-tests) on same
>> level as netx (which contains unittests and pactests (and I would like
>> to/I have move(d) reproducers into here) and styles and junit-runne
>> rand testsExtensions?
> I agree that testsExtensionTests (can we have a better name, please?)
> should be in the same level as netx.
any name suggestion is welcomed!!
Although <nameOfDirectoryWeWillAgree>-tests (or Tests without -) is not nice, it is at least self explaining.
>> but - when to run content of testsExtensionsTests? I would like to
>> include it inside netx unit test (or let it in netx reproducers tests
>> run as it is now) rather then run special tests-run for them.
> I think it would make sense to run it when we build jnlp_testengine.
> This ensure that the jnlp_testengine just built works as expected.
Do you really want to have one more tests run? Already now I need to keep en eye on 3 test-runs results (pac, unittests,reproducers runs)
I do not mind to have them where are they now (run with reproducers) or to move them to unittests-run, but I'm against third separate run.
But your sentence you moved me more to keep them where they are - with reproducers.
If I can use my right-of-veto you granted me in headline, then they will stay where they are.
>>>> 3) during reproducers run launch *just* compiled testcases
>>> Could you clarify what you mean here?
>> Right now also classes which are not "test-calses" (eg everything under
>> jnlp_testengine) are launched. It is definietly wrong. Some of this will
>> be easily fixed by this refactoring, but some issues can remain.
> Ah. so by "just" you meant "only" (as opposed to what just means in the
> acronym JIT). Makes complete sense now :)
>> Here I have (maybe interesting) idea:
>> All our java tests are executed from junit-runner classes, which are
>> packed to junit-runner.jar
>> I would (very!) like to include also all the testsExtensions clases in
>> this jar. It will make the unifications of classpaths much more
>> straightforward (and this jar hmhm... can be useful by its cntent)
> Please see my note about about mixing the CPL licensed code with other
More information about the distro-pkg-dev