gistfile1.txt

Luca Molteni> Rebasing JP is something that happens every six months, I think we can handle a few patches a year
11:31:14 <Luca Molteni> Let’s do like this @marekn, give me your local branch you’re trying to rebase against and I’ll apply the changes
11:31:26 <marekn> maybe get back to contributing back and handle it like 3rd party will help
11:31:54 <Luca Molteni> ?
11:32:05 <Luca Molteni> the reason why we forked that is not that we don’t want to contribute back
11:32:13 <marekn> @Luca Molteni I can handle that, just that fork is really not standard and we have similar forks in kiegroup and we could get rid off them
11:32:26 <Luca Molteni> in fact I already contributed to some patches to JP 
11:32:51 <marekn> great, what stops us to use basically java-parser from upstream?
11:33:07 <marekn> and not having it on our maintenance?
11:33:17 <Luca Molteni> that we need a grammar that is both java and drl and grammars don’t compose
11:34:44 <marekn> isn't then better to extend java-parser only?
11:35:11 <Luca Molteni> and therefore losing the tests?
11:35:36 <Luca Molteni> Nevertheless, we have a solution but as I said before, it’s medium term (it’s already a development but it’s not done yet)
11:35:38 <marekn> losing tests, how it comes?
11:35:46 <Luca Molteni> (they’re in a different project0
11:35:56 <Luca Molteni> So this will be probably your last drlx-parser rebase ever
11:35:59 <marekn> you can reuse their tests, or not?
11:36:57 <Luca Molteni> I was replying to "isn't then better to extend java-parser only?” I thought you meant using the java-parser module only
11:37:01 <Luca Molteni> tests are in another module
11:38:25 <marekn> no, I was asking why we don't have only drlx-parser code and maven module in repo and if we need to use jp tests we can reuse them while building the drlx-parser and we always have the latest or fixed version of them from maven just for build/rebuild
11:39:27 <Luca Molteni> Let me try to explain that better
11:41:16 <Luca Molteni> Javaparser is a Java Parser, therefore it has a grammar and some compiled classes. We support a programming language which is a superset of Java (drlx), therefore it includes the Java grammar and our rules grammar. Grammars don’t compose: this means you cannot take the `java.jj` file and concatenate to `drools.jj` file. You have to explictly modify the original grammar file, regenerate classes and then you have the parser
11:42:44 <Luca Molteni> What we decided to do at the time is to fork the original `java.jj` file by adding our parts instead of making a copy of it. That wasn’t the best choice but it was the fastest. To update JP now we have to rebase the modification the original team do to the grammar with ours, and it’s a cumbesome work to do (that’s why we do it twice a year)
11:43:35 <Luca Molteni> Still the alternative at the time, to make a copy of the original grammar would have been impossible to update. I’m not sure that’d been the best choice but there are still other details I’m superseeding here
11:44:18 <Luca Molteni> The “new” idea drops support for Java (and therefore drlx), so we don’t need to rebase the grammar anymore
11:44:57 <Luca Molteni> As I told you before, we’re working on that, but it won’t be ready for 7.3
New messages since you tabbed out
11:46:38 <marekn> ok, i got that, I still think you could do the old idea in a little different way, as download the source into a pre-generated area and change it on the fly would be less error prone way
But if you are dropping the java parser in future it is good 😉
11:46:55 <Luca Molteni> :) let me know if you need some help in applying patches