Hello Kai;
Apologies for the delay in responding.
I believe Jens and I had a discussion on this back some time ago concerning Spring Framework and utilizing only one CQ. At the end of the day I’m pretty sure we tried but it failed
in that particular scenario. I believe there were several factors in why it did not work. I’m happy to do a post mortem if you require the details.
That said, we have many projects who only require several modules from a single project and we are happy to accept one CQ in that case. We try to notate the relevant components
in the CQ Summary which helps with reuse.
Unfortunately, we simply do not have the resources to review an entire project if it is not required by the community. We cannot spend cycles on review of content that may never
be required. That would not be efficient for us nor the community.
I hope this helps. If you would like to have a larger discussion on this, I’m happy to arrange a call.
Best Regards,
Sharon
Hi Sharon,
the Ditto project filed a CQ [1] for a component they want to use which consists of multiple sub-modules (very much like the Spring Framework). I can remember a discussion we had about filing a single CQ for the complete source code of the Spring Framework
but then using and distributing only a subset of the modules.
IIRC you wanted us to create separate CQs for each of the sub modules we wanted to use. Does the same apply here? From a piggy-backing standpoint I do not think that the approach taken by the Ditto project is very helpful because they have created a CQ for
an arbitrary selection of the component's sub-modules that is useful for their project, but which may not be sufficient for others trying to use the component.
I therefore think that it would be better to either
a) allow creating a CQ for the whole source code at once and then allow projects to just use and distribute an arbitrary selection of the sub-modules
or
b) require the projects to file separate CQs for each sub-component to allow for others to easily piggy-back.
Personally, I would rather have option a) because it generates less work for the projects (but more work for you poor people of the IP team, I know :-() ...
[1]
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=14494
--
Mit freundlichen Grüßen / Best regards
Kai Hudalla
Chief Software Architect
Bosch Software Innovations GmbH
Ullsteinstraße 128
12109 Berlin
GERMANY
www.bosch-si.com
Registered Office: Berlin, Registration Court: Amtsgericht Charlottenburg; HRB 148411 B
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors: Dr.-Ing. Rainer Kallenbach, Michael Hahn
![EclipseCon Europe 2017]()
