Maven 1.x Dashboard Plugin

Link aggregator results with full reports

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 1.7
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    2

Description

Add a link to the results so clicking on them takes you to the full report.
e.g. link test failures to junit report of each project

  1. dashboard.patch
    08/Aug/04 8:46 AM
    5 kB
    Carlos Sanchez
  2. patch.txt
    17/Jan/05 4:56 AM
    39 kB
    pkernevez

Activity

Hide
Carlos Sanchez added a comment -

A junit sample (not working). Just hope anyone with a better knowledge of the plugin could implement it faster

Show
Carlos Sanchez added a comment - A junit sample (not working). Just hope anyone with a better knowledge of the plugin could implement it faster
Hide
Vincent Massol added a comment -

Hi Carlos,

Are you sure the multiproject plugin will always be loaded in the context before the dashboard project executes? If not, the maven.multiproject.aggregateDir property will not be set...

Also, how is %%PROJECTID%% resolved?

It seems to me all those properties are getting complex. Maybe it's time to create an interface for aggregators so that an aggregator script has to implement some methods such as: getLink(), getDescription(), etc. Dunno, just an idea.

Lastly, could you please also add the modifications to changes.xml + to the aggregator how to page which explains how to create an aggregator. It seems aggregators now accept a new property (the link one). Or is that specific only to the juniterrors aggregator? (in which case, I think it needs to be differentiated from the other properties which are generic).

Thanks!

Show
Vincent Massol added a comment - Hi Carlos, Are you sure the multiproject plugin will always be loaded in the context before the dashboard project executes? If not, the maven.multiproject.aggregateDir property will not be set... Also, how is %%PROJECTID%% resolved? It seems to me all those properties are getting complex. Maybe it's time to create an interface for aggregators so that an aggregator script has to implement some methods such as: getLink(), getDescription(), etc. Dunno, just an idea. Lastly, could you please also add the modifications to changes.xml + to the aggregator how to page which explains how to create an aggregator. It seems aggregators now accept a new property (the link one). Or is that specific only to the juniterrors aggregator? (in which case, I think it needs to be differentiated from the other properties which are generic). Thanks!
Hide
Carlos Sanchez added a comment -

The first attachment was only a very small idea, now I have implemented it.

I think it's a better idea to move the "Add link attribute" to the aggregator jelly script, so the linked file can be obtained by loading another plugin property instead of hardcoding it.

<!-- Add link attribute -->
<j:set var="linkProperty"
value="maven.dashboard.aggregator.${aggregatorName}.link"/>
<j:set var="link"
value="${context.getVariable(linkProperty)}"/>
<j:if test="${link != null}">
<x:attribute name="link">${link}</x:attribute>
</j:if>

But I get an error
<j:import> could not import script
Do you know why?

Show
Carlos Sanchez added a comment - The first attachment was only a very small idea, now I have implemented it. I think it's a better idea to move the "Add link attribute" to the aggregator jelly script, so the linked file can be obtained by loading another plugin property instead of hardcoding it. <!-- Add link attribute --> <j:set var="linkProperty" value="maven.dashboard.aggregator.${aggregatorName}.link"/> <j:set var="link" value="${context.getVariable(linkProperty)}"/> <j:if test="${link != null}"> <x:attribute name="link">${link}</x:attribute> </j:if> But I get an error <j:import> could not import script Do you know why?
Hide
Carlos Sanchez added a comment -

Any aggregator can have the link property, not just the junit report.

Show
Carlos Sanchez added a comment - Any aggregator can have the link property, not just the junit report.
Hide
Carlos Sanchez added a comment -

My idea was to add
<x:attribute name="link">junit-report.html</x:attribute>
to juniterrors.jelly for example, instead of
<!-- Add link attribute -->
<j:set var="linkProperty"
value="maven.dashboard.aggregator.${aggregatorName}.link"/>
<j:set var="link"
value="${context.getVariable(linkProperty)}"/>
<j:if test="${link != null}">
<x:attribute name="link">${link}</x:attribute>
</j:if>

The actual error is
<attribute> tag must be enclosed inside an <element> tag

Seems that the imported file don't know about the <x:element name="aggregator"> in plugin.jelly

Show
Carlos Sanchez added a comment - My idea was to add <x:attribute name="link">junit-report.html</x:attribute> to juniterrors.jelly for example, instead of <!-- Add link attribute --> <j:set var="linkProperty" value="maven.dashboard.aggregator.${aggregatorName}.link"/> <j:set var="link" value="${context.getVariable(linkProperty)}"/> <j:if test="${link != null}"> <x:attribute name="link">${link}</x:attribute> </j:if> The actual error is <attribute> tag must be enclosed inside an <element> tag Seems that the imported file don't know about the <x:element name="aggregator"> in plugin.jelly
Hide
Vincent Massol added a comment -

My initial idea was different. It was to define an interface that each jelly aggregator has to implement. For example the interface is that each jelly aggregator has to define the following goals:

"dashboard-[agrgegator name]-getLink"
"dashboard-[agrgegator name]-parse"
...

And then the main plugin.jelly would call these different goals as required to generate the raw ${maven.dashboard.report.single} file.

The master dashboard.jsl will then render the report into HTML using all the elements defined in the XML format.

ATM, I'm using a <j:import> tag but in that scheme we would need to use the <j:include> tag instead to import all scripts.

What do you think?

BTW, here's a comment I've found on the Jelly import tag: "By default, the imported script does not have access to the parent script's variable context. This behaviour may be modified using the inherit attribute.". That may (or may not!) explain your problem.

Show
Vincent Massol added a comment - My initial idea was different. It was to define an interface that each jelly aggregator has to implement. For example the interface is that each jelly aggregator has to define the following goals: "dashboard-[agrgegator name]-getLink" "dashboard-[agrgegator name]-parse" ... And then the main plugin.jelly would call these different goals as required to generate the raw ${maven.dashboard.report.single} file. The master dashboard.jsl will then render the report into HTML using all the elements defined in the XML format. ATM, I'm using a <j:import> tag but in that scheme we would need to use the <j:include> tag instead to import all scripts. What do you think? BTW, here's a comment I've found on the Jelly import tag: "By default, the imported script does not have access to the parent script's variable context. This behaviour may be modified using the inherit attribute.". That may (or may not!) explain your problem.
Hide
Carlos Sanchez added a comment -

Using your approach we'll need the following goals
getArtifact
getLabel
getGoal
getDescription
getLink
getValue

Do you think the parse goal is needed? it will only be used in "getValue".

The scripts can be in a well-known location and a new property can be used to set another location for user scripts.

About j:import the inherit attribute is already used so it should work, but it doesn't

Show
Carlos Sanchez added a comment - Using your approach we'll need the following goals getArtifact getLabel getGoal getDescription getLink getValue Do you think the parse goal is needed? it will only be used in "getValue". The scripts can be in a well-known location and a new property can be used to set another location for user scripts. About j:import the inherit attribute is already used so it should work, but it doesn't
Hide
Vincent Massol added a comment -

> Do you think the parse goal is needed? it will only be used
> in "getValue".

Agreed. It's not required and the getValue is better.

> The scripts can be in a well-known location and a new property can
> be used to set another location for user scripts.

Sure. The scripts are already in a well-known location. I also agree about extensibility for user scripts.

Show
Vincent Massol added a comment - > Do you think the parse goal is needed? it will only be used > in "getValue". Agreed. It's not required and the getValue is better. > The scripts can be in a well-known location and a new property can > be used to set another location for user scripts. Sure. The scripts are already in a well-known location. I also agree about extensibility for user scripts.
Hide
pkernevez added a comment -

This is a patch that manage mutliprojet and all aggregators excepts the clovers ones (only because with my configuration, I don't succed in generating the clover report, there isn't any technical difficulty).

Show
pkernevez added a comment - This is a patch that manage mutliprojet and all aggregators excepts the clovers ones (only because with my configuration, I don't succed in generating the clover report, there isn't any technical difficulty).
Hide
Vincent Massol added a comment -

Applied thanks. I've had to make several modifications to make it work. Also I've noticed that the report links get generated only for subproject1 and not for the other subprojects in the plugin tests. Is that normal?

Show
Vincent Massol added a comment - Applied thanks. I've had to make several modifications to make it work. Also I've noticed that the report links get generated only for subproject1 and not for the other subprojects in the plugin tests. Is that normal?
Hide
pkernevez added a comment -

I'm surprised that you had to make some changes, I expected that it was to many work (I use it on real projects without any trouble).

That's normal that links are only generated for the first project (and this is tested : cf the comment
<!-- The project2 don't have any report we check that there isn't any link --> in the maven.xml that test the plugin

The reasons are:

  • The project2 : has only XML report, so the dashbord has information about the number of errors, bit we don't have any html report to make links.
  • The project3 : hasn't any XML or Html report, so there isn't any link.
Show
pkernevez added a comment - I'm surprised that you had to make some changes, I expected that it was to many work (I use it on real projects without any trouble). That's normal that links are only generated for the first project (and this is tested : cf the comment <!-- The project2 don't have any report we check that there isn't any link --> in the maven.xml that test the plugin The reasons are:
  • The project2 : has only XML report, so the dashbord has information about the number of errors, bit we don't have any html report to make links.
  • The project3 : hasn't any XML or Html report, so there isn't any link.
Hide
Nascif A. Abousalh-Neto added a comment -

Hi,

I just updated to the latest version of the dashboard plugin hoping to see the links to the sub-project reports but the only links I saw are from the sub-project name to its main page.

From the comments I had the impression that all aggregators would also generate links to their specific reports. Is there anything else I need to udpate other then the dashboard jar? (I checked and I am using version 1.7)

Regards,
Nascif

Show
Nascif A. Abousalh-Neto added a comment - Hi, I just updated to the latest version of the dashboard plugin hoping to see the links to the sub-project reports but the only links I saw are from the sub-project name to its main page. From the comments I had the impression that all aggregators would also generate links to their specific reports. Is there anything else I need to udpate other then the dashboard jar? (I checked and I am using version 1.7) Regards, Nascif
Hide
Vincent Massol added a comment -

Nascif, your assumpotions are right. You should see links to the individual reports, provided they have been generated. Maybe we can discuss it on the mailing list i you have some issues?

Show
Vincent Massol added a comment - Nascif, your assumpotions are right. You should see links to the individual reports, provided they have been generated. Maybe we can discuss it on the mailing list i you have some issues?

People

Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: