Inline responses ...
Joakim:
It is my understanding that these files are generated, based on
the third party contribution details, which we submit as part of
the initial contribution. Prior to submission, the dependencies
were generated from Maven dependency analysis reports and may
include direct and indirect dependencies.
Committers can search the ipzilla bug database to determine if
the dependencies do, or do not match what has been recorded in
Eclipse back-end IP catalog. For example, All WebSocket IP details
can be viewed by searching for the component: ee4j.websocket
That list includes:
- 16060
- Google Guava Version: 18.0 (PB Orbit CQ12184)
- 16061
- atinject (Package javax.inject) Version: 1.0 (PB Orbit CQ3578)
- 16062
- javax.validation:validation-api:jar:1.1.0.Final (PB CQ15114
Type A)
These dependencies appear to be coming from Tyrus (the websocket-api RI).
It is plausible this is a mistake, but let's see what the
committer says (Roman Grigordi) before taking any action. I agree,
there is a bit of a question because in the initial CQ, Roman
indicates there are no third party dependencies (see 15333).
I'm not sure where these came into the picture.
It's truly is as simple as a project could get, with nothing it depends on.
There's not even a dependency on another eclipse-ee4j project.
To be totally clear, the only reference in websocket-api to another project is 2 lines in javadoc that point out behaviors within the Servlet API.
In short, I think the idea is that the NOTICE file should be
generated properly. I don't have enough experience to say if, once
it's generated -- can it be updated. If it is frequently
regenerated, adding custom text might be a problem. Let's see what
Roman says about these.
Thanks!
-- Ed
So once we have Roman's update on this, then it's possible that IPZilla's need updating and the websocket-api project would need to regenerate the NOTICE file.
Seems easy enough.
- Joakim