On Fri, Mar 27, 2020 at 3:09 PM Henrik Rentz-Reichert (hrr) <h...@protos.de> wrote:
> Aleksandar, > > > > thanks for the explanations and for looking into this! I completely > understand your situation and didn’t want to bother the Platform team with > personal mails. I assume (and you confirmed it) that they are busy also > without caring about my problems. > Actually I am advertising exactly that. Ping bug/mailing lists/people/etc. I have to admit that nowadays it's the most persistent that get attention :) > > > But to be able to move forward I’ve posted my question for the possibility > of a kind of fork. > > I didn’t mean this is any way as a complaint about poor responsiveness of > the Platform team. > > So for now we will duplicate the code (following Ed Willink’s > suggestions). And later I would be happy to drop it again and use the > refactored Platform code. > > > > Thanks, > > Henrik > > > > *Von:* cross-project-issues-dev-boun...@eclipse.org < > cross-project-issues-dev-boun...@eclipse.org> *Im Auftrag von *Aleksandar > Kurtakov > *Gesendet:* Freitag, 27. März 2020 12:18 > *An:* Cross project issues <cross-project-issues-dev@eclipse.org> > *Betreff:* Re: [cross-project-issues-dev] fork of EPL code in EPL project > allowed? > > > > > > > > On Fri, Mar 27, 2020 at 12:28 PM Henrik Rentz-Reichert (hrr) < > h...@protos.de> wrote: > > Hi, > > the Eclipse eTrice project filed a bug [1] against the Text component of > the Platform. > We would like to use the org.eclipse.jface.text.rules.RuleBasedScanner in > a headless application. The RuleBasedScanner and related classes aren't > depending on UI stuff, which is fine. However, the org.eclipse.jface.text > bundle is depending on SWT. So we asked for a split into UI dependent and > UI independent parts into separate bundles. > > Since [1] didn't receive an answer within 3 month and I also assume that > it's not likely that this part would be split off and moved to a separate > bundle, my question is: > Is it allowed that the eTrice project forks the needed classes unchanged > into its own code base? Of course this would require to place them inside a > new bundle, e.g. org.eclipse.jface.text.rules, to avoid conflicts. > > > > I'm sorry for the late reply! > > We don't have the manpower to triage all the incoming bugs. Please be a > bit more patient with us and try to actively ping on bugs, send mails to > project links, even direct mails to people that worked on given area is > just fine. It's not like we want to actively ignore people (especially > proactive people trying to help improving the codebase) it's just that > there are so many hours in the day and when you get hundreds of emails per > day you act on 10-20 and on the next day you start afresh, that's why > consistency in communication is key. > > With all of the above said, I've replied to the bug and brought it to > discussion so we can work on proper solution. Initial idea was easy to > implement but would have introduced issues with JPMS and we try our APIs to > stay stable for years. > > > > > Thanks, > Henrik > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=558350 > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > -- > > Alexander Kurtakov > > Red Hat Eclipse Team > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > -- Alexander Kurtakov Red Hat Eclipse Team
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
