Community
Participate
Working Groups
The org.eclipse.php.core.parser bundle is a redistribution of java_cup.runtim 0.10.0 which should be disclosed in the PDT IP Log: http://www.eclipse.org/projects/ip_log.php?projectid=tools.pdt In fact, rather than redistributing java_cup.runtime under a different bundle name, PDT should instead leverage the Orbit version of java_cup.runtime: http://www.eclipse.org/downloads/download.php?r=1&file=/tools/orbit/downloads/drops/S20110515001817/repository/plugins/java_cup.runtime_0.10.0.v201005080400.jar That version has been approved for redistribution with Eclipse under CQ 1950 https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1950 So filing a piggyback CQ for redistributing under PDT should be easy and little effort. It can be done in the http://portal.eclipse.org by choosing "request redistribution of a library maintained in Orbit". On the positive side and in defence of the PDT project it must be said that the about.html shipped with org.eclipse.php.core.parser properly declares java_cup.runtime and properly ships about.html as well as about_files.
I don't understand. as you said it has been approved already... and we haven't changed it since the last two years when we delivered Galileo and Helios. What has been changed since then? do we do something wrong?
For the CQ, It's more a matter of "tracking" than a matter of "approval". As of today, the IP Log for PDT does not mention that java_cup is being redistributed. This may cause a problem for adopters who want to ship PDT with their products, and are thus legally obliged to disclose all redistributed software. At Eclipse, every project redistributing a lib must file the CQ for redistribution. java_cup has been approved for redistribution with Orbit but the CQ for redistribution with PDT is currently missing. So the request is to file a CQ asking for redistribution with PDT (as piggyback on top of the Orbit CQ). This is simple and easy. Independent of this CQ requirement, there is the Simultaneous Release requirement to consume java_cup from Orbit rather than renaming and rolling your own. See the "Re-use and share" paragraph under the Indigo must do's: http://eclipse.org/indigo/planning/EclipseSimultaneousRelease.php
For completeness, the link to use in http://portal.eclipse.org is under "project leads" and is labelled [use] a third-party library from Orbit
(In reply to comment #3) > For completeness, the link to use in http://portal.eclipse.org is under > "project leads" and is labelled > [use] a third-party library from Orbit got it, thanks. I asked to use CQ 1950. Do you happen to know when should I see an updated iplog? the current one doesn't include CQ 1950.
I think it'll appear in your IP Log once it's approved by the IP Team.
Actually, I think there must be a misunderstanding. I don't see a new Cq on tools.pdt asking to re-use cq 1950. To be clear, you need to go to http://portal.eclipse.org, pick "project lead" and then [use] a 3rd party lib maintained at orbit. Enter 1950 and a new CQ should be created for you (asking to re-use 1950). Fill in additional details as appropriate and click "submit" (perhaps you missed that step). Next step is then that the tools PMC gets an E-Mail - they need to approve your re-use of 1950. They will do so by putting a pmc+ on your new CQ. Then the EMO IP Team approves it, and then it goes into your IP log. A recent example of how it's done properly was tools.edt when they re-used cq 1950: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=4772
(In reply to comment #6) > Actually, I think there must be a misunderstanding. > > I don't see a new Cq on tools.pdt asking to re-use cq 1950. To be clear, you > need to go to http://portal.eclipse.org, pick "project lead" and then [use] a > 3rd party lib maintained at orbit. Enter 1950 and a new CQ should be created > for you (asking to re-use 1950). Fill in additional details as appropriate and > click "submit" (perhaps you missed that step). > > Next step is then that the tools PMC gets an E-Mail - they need to approve your > re-use of 1950. They will do so by putting a pmc+ on your new CQ. Then the EMO > IP Team approves it, and then it goes into your IP log. > > A recent example of how it's done properly was tools.edt when they re-used cq > 1950: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=4772 you are sharp! actually I did it but the UI asked me to do one more click... ok, now email is ready...
That fast! CQ 5239 got approved immediately and it's in your log: http://www.eclipse.org/projects/ip_log.php?projectid=tools.pdt So first part of the issue is resolved (you may want to resubmit your IP log to Eclipse Legal). For the 2nd part, would it be possible to 1. Change PDT releng to download java_cup from Orbit, 2. pdt.core to "require" java_cup from orbit rather than pdt.server.parser 3. Change the pdt feature to "include" java_cup from orbit
(In reply to comment #8) > That fast! CQ 5239 got approved immediately and it's in your log: > http://www.eclipse.org/projects/ip_log.php?projectid=tools.pdt > > So first part of the issue is resolved (you may want to resubmit your IP log to > Eclipse Legal). For the 2nd part, would it be possible to > > 1. Change PDT releng to download java_cup from Orbit, > 2. pdt.core to "require" java_cup from orbit rather than pdt.server.parser > 3. Change the pdt feature to "include" java_cup from orbit Not that fast, there are technical issues to resolve first. Since we use the parser to generate the code we need to be careful with this process. Our builder generates the code on clean so it means that whoever needs to "build" PDT will need to have Orbit in his hands. Is this right?
(In reply to Martin Oberhuber from comment #8) > That fast! CQ 5239 got approved immediately and it's in your log: > http://www.eclipse.org/projects/ip_log.php?projectid=tools.pdt > > So first part of the issue is resolved (you may want to resubmit your IP log > to Eclipse Legal). For the 2nd part, would it be possible to > > 1. Change PDT releng to download java_cup from Orbit, > 2. pdt.core to "require" java_cup from orbit rather than pdt.server.parser > 3. Change the pdt feature to "include" java_cup from orbit We have to start again. PDT is while switching to javacup 11b-20150326, CQ 9437. CQ is approved. What should be our next move?
I added java_cup and java_cup-runtime 0.11.20150326 to eclipse orbit. No we should switch to this bundles.
(In reply to Dawid Pakula from comment #11) > I added java_cup and java_cup-runtime 0.11.20150326 to eclipse orbit. No we > should switch to this bundles. Actually PDT is using java_cup 0.11.20160615 since many PDT releases. It was only a bugs fix release for java_cup 0.11.20150326 (no new features), if I remember well, no new CQ was needed.
If cup code has been changed also CQ is needed. We can’t use never lib (even bug fix) without CQ. Are we affected by these bugs?
(In reply to Dawid Pakula from comment #13) > If cup code has been changed also CQ is needed. We can’t use never lib (even > bug fix) without CQ. Are we affected by these bugs? There was a major bug in java_cup that caused parsers to be wrongly generated, and I contacted Michael Petter (the maintainer of java_cup) to report the problem so he could fix it (btw he was surprised that we used java_cup to do complex parsers in PDT ;). The regression was introduced somewhere after 0.11.20140808 and it was mainly fixed in 0.11.20150326 (changelog says "Fixed an issue with empty productions having non-empty location information"), but more recent releases reworked a bit the fix (if I remember well, sorry, and the java_cup changelogs won't say much). Anyway, latest release is 0.11.20160615, and it proved to work very well, I *hugely* prefer keeping that version by doing a CQ than going back to older versions.
