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