Community
Participate
Working Groups
The org.eclipse.jface.text.rules.RuleBasedScanner isn't depending on any UI stuff (SWT in particular) and we (the Eclipse eTrice project) need it in a headless application. A consistent set of classes that can be moved to org.eclipse.text is EndOfLineRule ICharacterScanner IPredicateRule IRule IToken ITokenScanner IWhitespaceDetector IWordDetector MultiLineRule NumberRule PatternRule RuleBasedScanner SingleLineRule Token WhitespaceRule WordPatternRule WordRule Please move these classes to the org.eclipse.text bundle.
Would there be any risk associated with that change? I think it would be ok to move those classes (without changing package) to org.eclipse.text and reexport them from org.eclipse.jface.text. The only concern is about the versions: to ensure some backward compatibility in case Import-Package is used, we'd probably need to make the verison of org.eclipse.text directly jump from 3.10 to 3.16 (current version of org.eclipse.jface.text). WDYT?
(In reply to Mickael Istria from comment #1) > Would there be any risk associated with that change? > I think it would be ok to move those classes (without changing package) to > org.eclipse.text and reexport them from org.eclipse.jface.text. The only > concern is about the versions: to ensure some backward compatibility in case > Import-Package is used, we'd probably need to make the verison of > org.eclipse.text directly jump from 3.10 to 3.16 (current version of > org.eclipse.jface.text). > WDYT? Sounds OK to me. Bumping the version from 3.10 to 3.16 sounds like best option. I'll bring it to PMC list.
(In reply to Alexander Kurtakov from comment #2) > (In reply to Mickael Istria from comment #1) > > Would there be any risk associated with that change? > > I think it would be ok to move those classes (without changing package) to > > org.eclipse.text and reexport them from org.eclipse.jface.text. The only > > concern is about the versions: to ensure some backward compatibility in case > > Import-Package is used, we'd probably need to make the verison of > > org.eclipse.text directly jump from 3.10 to 3.16 (current version of > > org.eclipse.jface.text). > > WDYT? > > Sounds OK to me. Bumping the version from 3.10 to 3.16 sounds like best > option. I'll bring it to PMC list. On second thought I think we should move to new package org.eclipse.text.rules package and deprecate the old ones. Reason for that is that JPMS (which we don't use now but that day may come) is not accepting split packages and we should try to not introduce one more now knowing this limitation.
(In reply to Alexander Kurtakov from comment #3) > > Sounds OK to me. Bumping the version from 3.10 to 3.16 sounds like best > > option. I'll bring it to PMC list. > > On second thought I think we should move to new package > org.eclipse.text.rules package and deprecate the old ones. Reason for that > is that JPMS (which we don't use now but that day may come) is not accepting > split packages and we should try to not introduce one more now knowing this > limitation. How realistic is it that we could ever really use JPMS? Split packages is one thing, but there is a list of other things that make moving to JPMS impossible without terrible disruption and requiring a much larger team than we have today. * no split packages (we have many) * no fragments (we have many and it is how we deliver NLS) * no lazy activation * no weaving hooks * no multiple versions of packages * ... I fail to see a plan where we can overcome these things in JPMS and I have yet to see the benefits that outweigh these pains we would have to overcome. Unless we have committers involved in the jigsaw project that can help drive some requirements into JPMS I don't see how we will move without a massive reengineering of Eclipse. Reengineering of Eclipse is technically possible, we did it before when moving to OSGi. But then we had ~20 people on the core team alone AND we had to implement a compatibility layer that would understand the old stuff (which we only recently have gotten rid of finally). Finally, we did have many of the core committers participating in the OSGi specification process to add things needed for Eclipse. Don't get me wrong. I don't want another split package either. If we have a solution to avoid splitting then we should take it. Split packages are annoying and hard to consume properly. But avoiding it with hopes to move to JPMS I don't think should be the realistic motivation to avoid split packages.
(In reply to Thomas Watson from comment #4) > (In reply to Alexander Kurtakov from comment #3) > > > Sounds OK to me. Bumping the version from 3.10 to 3.16 sounds like best > > > option. I'll bring it to PMC list. > > > > On second thought I think we should move to new package > > org.eclipse.text.rules package and deprecate the old ones. Reason for that > > is that JPMS (which we don't use now but that day may come) is not accepting > > split packages and we should try to not introduce one more now knowing this > > limitation. > > How realistic is it that we could ever really use JPMS? Split packages is > one thing, but there is a list of other things that make moving to JPMS > impossible without terrible disruption and requiring a much larger team than > we have today. > > * no split packages (we have many) > * no fragments (we have many and it is how we deliver NLS) > * no lazy activation > * no weaving hooks > * no multiple versions of packages > * ... > > I fail to see a plan where we can overcome these things in JPMS and I have > yet to see the benefits that outweigh these pains we would have to overcome. > Unless we have committers involved in the jigsaw project that can help drive > some requirements into JPMS I don't see how we will move without a massive > reengineering of Eclipse. > > Reengineering of Eclipse is technically possible, we did it before when > moving to OSGi. But then we had ~20 people on the core team alone AND we > had to implement a compatibility layer that would understand the old stuff > (which we only recently have gotten rid of finally). Finally, we did have > many of the core committers participating in the OSGi specification process > to add things needed for Eclipse. > > Don't get me wrong. I don't want another split package either. If we have > a solution to avoid splitting then we should take it. Split packages are > annoying and hard to consume properly. But avoiding it with hopes to move > to JPMS I don't think should be the realistic motivation to avoid split > packages. I don't have hopes to move to JPMS but I want us to have less things to fix in case we are forced to at some point.
Yet more deprecated classes seems like an ugly solution. :-( It's not as if the downstream consumer base will want to pay a cost for migrating with absolutely no value added. For example, I use these things (in my JET editor) and my stuff runs on Helios too. And my stuff depends on JDT, so the question immediately comes up, which other parts keep using the deprecated things and which parts start using the new ones and will that interact well.(I'm not sure it will or won't.) But the general question is how will things that use two parts together still keep working as the parts migrate? Please reconsider this approach. I suspect you'll find this isn't really even technically feasible because the to-be-copied-and-deprecated things are used directly in the APIs of things that are not to be moved. E.g., org.eclipse.jface.text.rules.DefaultDamagerRepairer uses these and it hasn't been asked to be moved because it depends on SWT. And then it must keep using deprecated things, which makes it impossible for clients to avoid deprecated things. Please no...
OK. Point taken. So we can introduce the class hierarchy with the jface.text.rules one doing nothing but extending so API is preserved and not be deprecated. Does should fix this concern too.
Yes, that seems better. This is all to avoid split packages, which admittedly is not very nice? Another very ugly solution is optional greedy dependency on SWT and then "buyer beware" on what works and what doesn't; that's also the least amount of effort...
