Hi Stefan. I'm sorry to be so slow to answer this. Mostly, I was just so utterly absorbed in other things. Now I see that you've put in an issue on this also.
Well, okay, you're posing two questions (or is it three?) -- whether a Maven plugin is planned and then whether it would help others. (Because maybe the maven artifact is a third question.)
Well, I guess the short answer is that, yes, the intention now, as of the Congo rebranding, is to jump through these hoops. And since it seems you're willing to actually do some work on this, I guess we ought to do it sooner rather than later.
Now, as for your other question of whether this would "help others"? Well.... I would have to admit that it is entirely possible that I suffer from some sort of blind spot here. But I am basically just bewildered by the whole "issue" frankly. I still don't really understand why people can't just download the thing and use it.
Heck, even building (and running) from the source is really quite easy. It's just:
git clone https://github.com/congo-cc/congo-parsers-generator.git congocc
java -jar congocc-full.jar
In fact, even that is so easy that putting up the prebuilt jarfile with a direct download link could even be considered superfluous. But regardless, to me, it seems like it's all so easy that it's very strange to me that anybody thinks that there is some kind of pressing problem here.
Well, there is sort of a deeper problem in all of this, which is that, from the outset, in the whole JavaCC 21 period, I guess you could say that I adopted a very iconoclastic approach. I don't know whether you saw this. Basically, I said there that I wasn't going to bother with any of this, so just download the thing, use it and be happy...
And I also took a similar uncompromising approach on the tool's name. Back in ancient history, when I downloaded the JavaCC code and started doing some work on it (we're talking 2008!) I sort of played the game. First I tried to donate my work to the canonical project. They told me to go pound sand and I created a "fork" and called it "FreeCC" and so on... And then, when I picked up that work again over a decade a later, I decided this time round not to bother with any of that and just said basically: "That legacy JavaCC project is dead and this is the continuation of work on that codebase and it's name is JavaCC." Okay, "JavaCC 21" but I acquired the domain javacc.com and...
Well, I think it's obvious after three years that that was a total failure. Pretty much... Somehow, the way things are structured, it's just about impossible to displace an entrenched nothingburger project when the insiders in the legacy project are totally intransigent. Now, to be clear, I do not believe that I did anything wrong morally or ethically. Recently, one guy whose name I won't mention, but he's pretty active in open source, told me in private that he really admired my uncompromising stance on this. I think he strongly sympathized with my standing up to these people. Basically, I was saying implicitly: "Look, I'm not taking any of this shit from you. This is not a fork. A fork means a bifurcation of effort, which means that you are doing something and I'm doing something, except you guys are not doing anything, and the whole idea that you guys have exclusive right to the canonical name is really just ridiculous..."
But the problem is that what I did just didn't work. So, it was an interesting socio-political experiment, you could say, and I am totally satisfied I did nothing wrong, but I couldn't keep ploughing forward with that... But I've been (painfully) aware that this was a failed experiment (the positioning/branding side) for over a year, and I distinctly remember a chat on WhatsApp with Vinay, late 2021, where we were floating different new names. And we settled on CongoCC, but it finally took me until now to buckle down and get the rebranding done. (2022 was not a great year for me, lots of distractions...)
So, similarly, I still hold the view that my iconoclastic stance that all this official release stuff was basically bullshit that I wasn't going to bother with -- I think this was (and is) quite well founded. (At least, for a project of this scale and characteristics that is this undermanned...) So, now, if we talk concretely about Maven, well, the motivation of that thing is dependencies management. Except that, in this speciic case.... there are no dependencies to manage. The tool itself is totally self-contained. You have an ueber-jar that simply contains everything that is needed. AND the code that the tool generates has no dependencies aside from the standard Java classes.
In short, as best I can see, insisting that this project needs Maven is akin to insisting that a flat-chested girl should wear a bra. (Of course she should! Every decent, god-fearing woman should wear a bra!)
So, okay, sorry to go on at length, but I guess it's worthwhile to share my thinking on all this. Let's see.... to get back on point... I had alreay basically decided that I was going to relent on my previous position.
So, my intention is to put out some regular releases -- again, not because I changed my views particularly -- but because, okay, this is somehow important for people. And we can put up the releases on Maven Central and we can have a Maven plugin for CongoCC.
So here is my pitch on this, Stefan. This is not some huge amount of work, but it's not totally trivial. Are you willing to step into the role of... let's see... "release manager" and take responsibility for making this happen? Basically, I think we just want to get this to the point where we just have some script and it does the whole thing. It rolls up the Maven artifact, with some incremental release number, digitally signs it, puts it on the server, and we have the Maven plugin that you can use from the pom.xml file and all that.
So, what do you think?