RFC: Separation of JTreg tool into independent project

[Jiri Vanek]

On 07/07/2011 02:07 PM, Andrew John Hughes wrote:
> On Thu, Jul 07, 2011 at 11:57:57AM +0200, Jiri Vanek wrote:
>> On 07/05/2011 03:19 AM, Andrew John Hughes wrote:
>>> On Mon, Jul 04, 2011 at 02:24:03PM +0200, Pavel Tisnovsky wrote:
>>>> Hi all,
>>>>
>>>> some time ago I discussed with Andrew John Hughes about the separation
>>>> of JTreg tool from the IcedTea6 and IcedTea7 projects. In summary (ie
>>>> how I understand this task): JTreg should be developed as independent
>>>> project and in the future they should be synchronized with recent JTreg
>>>> version (used by Oracle guys AFAIK).
>>>>
>>>
>>> Yes, but that's not what this patch seems to do.  It just moves the source
>>> code out of the tree into a zip somewhere.  I was envisaging jtreg being
>>> a separate project like the visualvm one with its own build infrastructure.
>>> You'd then point configure at an installed jtreg.jar.  That could be built
>> >from the IcedTea jtreg project or alternatively, you could use the one
>>> Oracle provide if you were willing to accept the proprietary licensing
>>> this entails.
>>
>> When you are writing "like visualvm" you mean also specfile? I guess (and hope) not - as I do not see any reason why to make an distribution package for this suite.
>>
>
> No, I'm not talking about anything related to specfiles.  This is about a
> development tree, not distro. packaging.
>
>> For the rest - you suggest to have hg repository beside icedteas, inside jtreg sources with its makefile.am and configure scripts and possible patches. Yes?
>
> Exactly, bar the patches.  What would you need patches for?  The source would be in there.
>
>> Tests itself will remain in openjdk. (?)
>
> Well yes they are part of OpenJDK.
>
>> Build of icedtea will remain untouched unless some "test yourself" will be enabled. In case of enabled, it will download some released tarball and will use it [rfc].
>
> No, the idea is to have --with-jtreg=<path to jar>.
> IcedTea should not become some Maven clone.

What will happen when jar will be missing?
It will download drop? It will checkout hg and proceed build? it will skip testing? Will this decision depend on another --with-?-=... ?

My vote is for skip testing when jar is missing. (following from condition that huge amount of users is using icedtea, 1 user is using icedtea with testsuite; )
>
>>
>> In similar scenarios I will be happy to have jtreg in separate "package".
>>
>>>
>>>> In the attachment there's very first version of patched Makefile.am from
>>>> IcedTea6 HEAD. When user call command 'make jtreg' from command line,
>>>> archive containing stable version of JTreg tool sources is downloaded
>>>> into 'drops/' subdirectory, then this archive is unzipped into 'test/'
>>>> subdirectory and then JTreg is compiled&   run as usual.
>>>>
>>>> This functionality is similar as in the case of JAXP and JAXWS - these
>>>> two parts of JDK are also separated from JDK sources.
>>>>
>>>
>>> Yes, and it's one of the most annoying things Oracle have ever done, as
>>> there's no change visibility.  I've been thinking about reverting it
>>> in the IcedTea tree so at least we can see the changes between zips
>>> if not at the changeset level.
>>>
>>>> What do you think about this solution (which could be the same for
>>>> IcedTea6 and IcedTea7, also *probably* for IcedTea-web)?
>>>>
>>>
>>> Why would IcedTea-Web need jtreg?
>>
>> IcedTea-web do not have jtreg, but have its own set of unit-tests and reproducers-tests which are worthy to be run in daily report.
>> Now it is some 40 tests together, and its grow-rate will not be  to fast, so for now I do not thing it is good idea to separate them.
>> They are run as 'make check' and 'make run-netx-dist-tests' commands.
>
> We're only talking about moving the jtreg code out, so there is one common repository
> for IcedTea6, IcedTea7, IcedTea8 and all the release branches.  I don't fancy the
> alternative of patching all those with fixes (especially the release branches).
>
> I'm thinking this should wait until 1.12 now though, as not enough progress has been
> made for 1.11.  I'd like to get 1.11 out soon-ish (next few months) and something
> like this really needs time to soak.
>
>>
>>
>>>
>>>> Cheers,
>>>> Pavel
>>
>> Regards J.
>>
>


Thanx for ideas. J.