On 08/03/11 15:00, Stefan Bodewig wrote:
> On 2011-07-31, Robert Burrell Donkin wrote:
> 
>> On 07/20/11 09:26, Stefan Bodewig wrote:
>>> Hi,
> 
>>> I'm trying to document the attribbutes of the new license matcher I
>>> added to the Antlib yesterday, basically they are the same as those of
>>> described in
>>> <http://ci.apache.org/projects/rat/apache-rat-plugin/examples/custom-license.html>
> 
>>> I wanted to show the impact of the attributes, i.e. where does which
>>> value show up inside the report.  So I dug into pieces of RAT's code
>>> that I've never really visited before.
> 
>>> So far I have
> 
>>> * notes
> 
>>>   Ends up in a metadata attribute RAT_URL_HEADER_SAMPLE and becomes the
>>>   text content of the <header-sample/> element.
> 
>>>   Invisible inside the plain text report as header samples are only
>>>   emitted for unknown licenses.
> 
>>> * licenseFamilyName
> 
>>>   Ends up in a metadata attribute RAT_URL_LICENSE_FAMILY_NAME and
>>>   becomes the name attribute of a <license-family/> element.
> 
>>>   This one is checked against the list of approved license names and
>>>   results in <license-approval name='false'/> (or true, depending on the
>>>   approved licenses, of course).
> 
>>> * licenseFamilyCategory
> 
>>>   Ends up in a metadata attribute RAT_URL_HEADER_CATEGORY and becomes
>>>   the name attribute of the <header-type/> element.
> 
>>>   This is the only visual impact any of the attributes has on a plain
>>>   text report.  It is shown next to the file name in the list of scanned
>>>   files.
> 
>>>   BUT it also ends up in a metadata attribute
>>>   RAT_URL_LICENSE_FAMILY_CATEGORY and becomes the name attribute of a
>>>   (second) <license-family/> Element.
> 
>>> So we end up with two <license-family/> elements, one with the "short
>>> name" and one with the longer one.  Is this intentional?  The plain text
>>> report ignores those elements completely.
> 
>> IIRC the original intent was to support license reasoning but I'd be
>> very happy to see the reporting simplified by removing them
> 
> Removing whom, exactly?  I'd propose to remove the license-family for
> RAT_URL_LICENSE_CATEGORY since its value will still be available from
> the header-type element.

works for me :-)

Robert

Reply via email to