Fwd: Re: [icedtea-web] xml output for junit, transformation sheets for daily report

[Jiri Vanek]

On 05/11/2011 11:21 PM, Dr Andrew John Hughes wrote:
> On 17:06 Wed 11 May     , Jiri Vanek wrote:
>> On 05/11/2011 03:52 PM, Dr Andrew John Hughes wrote:
>>> On 14:51 Wed 11 May     , Jiri Vanek wrote:
>>>> ..snip..
>>>>>
>>>>>> 	*index.html: file which provides runtime transformation
>>>>>> 	of tests-output.xml and report.xml
>>>>>> 	* tests/styles/index.js: runtime transformation script and fast
>>>>>> 	navigation functions
>>>>>
>>>>> I think the transformation should be preformed by make as part of producing index.html,
>>>>> rather than having browser-specific hacks.
>>>>>
>>>>
>>>> Not exactly. My "task" ..or.. my "desire"..  was to produce full,
>>>> reusable report from testsuite. And this is XML (one for unit tests, one
>>>> for reproducers-tests). It will be used for anything we will want to
>>>> mine from results. (For now I'm aware about hystory, view of single run
>>>> and graphs and statistics). The sheet is designed to view the report in
>>>> human readable way for the single run. . It will be used to generate
>>>> htmls on torment.  But the generation itself should not be in
>>>> icedtea-web (makefile).
>>>
>>> Yes, it should, if the XML is being produced by make.  It's unintuitive for
>>> the index.html.in to be transformed to something that isn't the final HTML,
>>> but requires a further transformation.
>>>
>>
>> Still I must disagree. Add dependences to xalan-xercess is is quite big
>> step. And especially those two caused troubles in recent icedtea6 build
>> under f15. I do not want to provide result html after build. I would
>> like to provide results (xml) and some basic opinion to view them quicly
>> and comfortably.
>
> Oh, I certainly wasn't thinking of Xalan/Xerces when there is either xsltproc
> or in-tree JDK support.  Xalan/Xerces is used in IcedTea6 purely for
> bootstrap support and I intend to replace it with xsltproc.

My intention is really not to provide final html. It is to provide data, 
and some simple possibility to view them. Javascript have evolved into 
quite sufficient language, quite perfect for this usage. I see no reason 
why use xsltproc instead of it. I'm pretty sure that this solution is 
working in all common gui-based linux browser. In case somebody  still 
prefer  commandline browser then the xml is more suitable for him.

>
>> For daily report will be used xslt x xml on torment, so only resulted
>> html will be shown. Xml itself will be used also for statistics.
>>
>> Included runtime transformation should serve to develloper just as
>> "preview" of data  after control build.
>>>> On the other way the sheet prove itself useful when hunting bugs. So I
>>>> decide to include the html skeleton which provide fast access to tests`
>>>> results using xslt transformation...
>>>> Btw - its not an hack:) The mozzila (and company) behaviour is following
>>>> w3c specification for this thing.  Although... yes IE part is hack :-/.
>>>> So I'm willing to remove it (As i do not like M$ manners to :) ... ) but
>>>> no one ever knows...
>>>>
>>>
>>> No, I believe the standard is to include:
>>>
>>> <?xml-stylesheet href="templates/project.xsl" type="text/xsl" ?>
>>>
>>> in the XML.
>>
>> This will bound the xml to one concrete sheet. This means that when you
>> want several points of view to data (several xslt upon one XML) then you
>> need to have same number of XMLs. Also you will lost possibility to show
>> both reports simultaneously.
>>
>
> Ok.
>
>> As mentioned at the top, index.html is overview after make check and
>> make distcheck - especially for the one who made the build.
>>
>
> I still think something like xsltproc to generate the final HTML
> would be preferable.  Doing things in web pages tends to be horrible
> to support across multiple browsers.

Except M$IE javascript is moreover united IMHO.
>
>>>
>>> Displaying the results should not require Javascript.
>>>
>> True. Still the javascript is included in final html (although it is not
>> required - all traces are visible then) for hide/show full stack traces.
>>>>
>>>> ..snip..
>>>>
>>>>
>>
>> huh.. I hoped I described my point of view clearly (As I do not belive
>> my english :D )
>>
>
> I think so.  Unfortunately, I can't read your mind to verify this ;-)
>
>>>> Regards J.
>>>
>>
>> It Is very sad you did not mentioned your dislike to runtime
>> transformation after initial email (04/29/2011) (directly:
>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013904.html
>> and
>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-May/013983.html)
>> and draft in java-team even ore before. Now it cause unnecessary troubles:(
>>
>
> I didn't see this post.  My mailer shows the thread as started May 9th.
> Maybe it got buried during the time I was away with all the UK bank holidays.

That is  why I have threads turned off and  rely more to my (full of 
holes) memory :)
>
> I do remember the internal post and said at the time I wouldn't reply internally.
>
>>
>> Regards J.
>>
>>
>