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.
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<mailto: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<mailto: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
