Community
Participate
Working Groups
The current state of the art appears to be: Xtext is a really cool innovative project that other Eclipse projects exploit. Every so often Xtext gets a new IP in support of its innovation; e.g. CQ 5804. As a result, all projects using Xtext must raise piggy-back CQs (e.g. CQ 5827, 5879, 5897). I suspect there is only a 50% appreciation of this need for compliance. It would avoid considerable bureaucracy if Xtext's primary CQs could be pre-approved for re-use.
Actually, there is no such requirement. Eclipse projects only require a CQ for those libraries on which they have a direct dependency. If project A uses project B and project B has a CQ for library C, there is no requirement for project A to also have a CQ (piggyback or otherwise) on library C. Project A would require the CQ only if project code makes direct use of library C. This is captured in the wiki: http://wiki.eclipse.org/Development_Resources/Contribution_Questionnaire#Third_Party_Libraries I'm changing the summary of this bug to indicate a documentation problem.
It would be helpful if you can tell me how you arrived at your understanding. Intuitively, I'm inclined to take another pass at streamlining the Development Resources [1] page, which--I believe--is really the only shot at identifying the Contribution Questionnaire page indicated in comment 1. [1] http://wiki.eclipse.org/Development_Resources
http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf page 2 covers Orbit re-use and doesn't distinguish direct or indirect re-use so a (piggy-back) CQ is required for all downstream projects of an Orbit re-using project.
(In reply to comment #3) > http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf page 2 covers Orbit > re-use and doesn't distinguish direct or indirect re-use so a (piggy-back) CQ > is required for all downstream projects of an Orbit re-using project. Thanks for this. Does my response in comment 1 clarify things well enough?
(In reply to comment #2) Just reviewed http://wiki.eclipse.org/Development_Resources/Contribution_Questionnaire#Third_Party_Libraries which is more helpful but not really so. If a project inherits com.google.guava from Xtext, it is almost inevitable that at some point code will evolve to have a direct re-use. The chances of a CQ being filed at this point are minimal. Worse, Xtext can auto-generate class references into dependent projects. Are projects expected to review all auto-generated code and re-review it for CQ-bombs in case Xtext changes or Xtext options vary. Perhaps Xtext should have a CQ that does/doesn't permit bundle export. This would at least force projects to know that they were using a CQ controlled bundle, but then there could be a significant risk of version conflict. Much better to approve for arbitrary downstream re-use of an Orbit bundle.
FWIW, I assumed that Xtext was just an example in comment 0. Can I safely assume (based on comment 5) that you mean Xtext very specifically? (In reply to comment #5) > Much better to approve for arbitrary downstream re-use of an Orbit bundle. It's doubtful that this will happen. The whole point of tracking piggybacks is so that we can trace usage in the event that IP problems are detected later. I have been discussing an option with the IP team to eliminate piggyback CQs with some tooling support for ferreting out those dependencies. Unfortunately, we're all focused on other things at the moment, and this is nothing more than an idea at the moment. I'll discuss this further with the IP Team.
(In reply to comment #6) > FWIW, I assumed that Xtext was just an example in comment 0. Can I safely > assume (based on comment 5) that you mean Xtext very specifically? Xtext is the greatest challenge because Xtext is very innovative. But EMF codegen could evolve to inject downstream dependencies into dependent, or even independent projects. (In reply to comment #6) > (In reply to comment #5) > > Much better to approve for arbitrary downstream re-use of an Orbit bundle. > > It's doubtful that this will happen. The whole point of tracking piggybacks is > so that we can trace usage in the event that IP problems are detected later. Unless you have tooling that detects constructed strings used by Class.forName(), I think you have no chance of tracking the ripple of an IP problem. I suspect that actual piggy-back CQ accuracy is less than 50% either through wrong versions or just ignorant re-use. [Try loading the full Indigo release and see how the plugin dependency hierarchy compares with your records for e.g. org.apache.log.]
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Still very relevant. How many Luna Guava 15 users have a piggy-back CQ?
(In reply to Ed Willink from comment #9) > Still very relevant. Even more relevant now. Yesterday I raised nearly 20 piggyback CQs for OCL and QVTd projects. Last year I was pragmatic and took the view that it was really stupid to raise them all. New reminders this year suggest that I really should raise them. Now the PMC very reasonably objects to approving so many CQs. (https://dev.eclipse.org/ipzilla/show_bug.cgi?id=11458#c2).
(In reply to Ed Willink from comment #11) > Last year I was pragmatic and took the view that it was really stupid to > raise them all. Hopefully, by the end of this quarter we'll have started the process of eliminating them. See Bug 475400.
(In reply to Wayne Beaton from comment #12) > (In reply to Ed Willink from comment #11) > > Last year I was pragmatic and took the view that it was really stupid to > > raise them all. > > Hopefully, by the end of this quarter we'll have started the process of > eliminating them. See Bug 475400. That is future. What is the state of play for Neon for a project that uses Guava 12 to 18 inclusive? Is it necessary to have piggy-back CQs for EVERY version of an Orbit bundle that they use, or just for a SAMPLE one? Even if it is necessary to have ALL, do we continue to ignore that requirement?
Can you answer this one, Sharon? (In reply to Ed Willink from comment #13) > That is future. What is the state of play for Neon for a project that uses > Guava 12 to 18 inclusive? > > Is it necessary to have piggy-back CQs for EVERY version of an Orbit bundle > that they use, or just for a SAMPLE one? > > Even if it is necessary to have ALL, do we continue to ignore that > requirement?
(In reply to Wayne Beaton from comment #14) > Can you answer this one, Sharon? > > (In reply to Ed Willink from comment #13) > > That is future. What is the state of play for Neon for a project that uses > > Guava 12 to 18 inclusive? > > > > Is it necessary to have piggy-back CQs for EVERY version of an Orbit bundle > > that they use, or just for a SAMPLE one? > > > > Even if it is necessary to have ALL, do we continue to ignore that > > requirement? We look forward to the implementation of Bug 475400 which will have the effect of reducing the workload associated with piggyback CQs for both the community and the IP Team. For the time being, the current process, where a CQ is required, remains unchanged. Thanks, Sharon (IP Team)
I think that the documentation changes in the handbook cover this. https://www.eclipse.org/projects/handbook/#ip-third-party I'm going to optimistically close this bug. Reopen if you feel that the handbook does not adequately address the issue.
