Gravelbones Most java project either require that it can be downloaded from the maven central repository (by version number)
Well, people have asked me about this here and there over the past couple of years, but I honestly never got the feeling that this, of all things, was the reason that adoption has been so slow. I mean, for one thing, the whole dependencies management side of Maven, as far as I can see, its value pretty much entirely relates to situations where you're redistributing a library.Then there are different versions of the library floating around and you want to state clearly which one you build and run with, I guess. But the approach that JavaCC (whether the original version or JavaCC) to all intents and purposes dispenses with the whole problem because there is no redistributable component . It generates code that is completely self contained with no dependencies beyond the core classes in JVM. And that was always a quite attractive aspect of the thing, as compared to ANTLR, say, which has a runtime engine that has to be redistributed. In that case, yes, you get into this dependencies management issue, I suppose, because there are different versions of that runtime floating around and presumably this Maven thing does a wonderful job of sorting this all out for you. But when the problem basically doesn't exist for JavaCC in the first place..., Frankly, it is quite unclear to me what Maven or Maven Central is doing for you, what problem is being solved in our case. And, frankly, having a whole bunch of stale versions of the tool sitting around on Maven Central (or anywhere else) is not something that appeals to me particularly.
Well, I've basically stated as a policy that users are expected to use the latest version. Now, obviously, people can do what they want, but my position is that there is no technical support for anything but the latest version. That's the policy I state here. Basically, I'm saying that there is no need for formal versioning because we're taking the stance that there really is only one version, the current version, and that's that! I guess some people might find that jarring or something.
Now, all that said, I'm not denying that this is important for some people, but I guess I see this as part of a larger phenomenon -- I mean, there are people out there who have a very, let's say.... formalistic or bureaucratic approach to software development. And a similar *or related issue) is that there are people (frequently the same people, I suppose) for whom it is extremely important that something they use comes from what they perceive as an approved channel. One glaring case of this that I recall distinctly was that back when I created the FreeCC fork in 2008, there was this guy who worked at a major corporation (I won't mention his name) but he was on the JavaCC mailing list trying to get their interest in terms of addressing various issues, most of which were already addressed in my fork, FreeCC. I wrote the guy and had some correspondence with him, but I'm pretty sure that he just never even considered switching over to using FreeCC, because somehow it just didn't come from the "approved channel". Something like that... But that guy was willing to waste quite significant amounts of energy in conversations with the JavaCC people, advocating that they should implement whatever attractive features he needed -- in the full knowledge that everything he wanted was already implemented elsewhere! (Also, unless the guy was born yesterday, he should have known perfectly well that those people were never going to implement anything anyway!)
So, all of that is a very real phenomenon.
I guess my point is that the same people, for whom it is so important that something should be on Maven Central, are probably never going to use JavaCC 21 anyway -- at least not until the thing is already very widely known and accepted out there, I guess, and then they'll somehow think that this is something they can use. (And then they'll use it whether it's on Maven Central or not!) And besides, in my experience, once you tell these people that they can't just drop in JavaCC 21 as a replacement and have it work with zero changes to their code, they just walk away from the conversation.
Gravelbones Legacy java is available in maven central and will therefore be the easy choice to go with.
Well... quite frankly, anybody who would use something that utterly inferior simply because it's on maven central... I would have serious doubts about that person's competence level. I have to admit that I don't really understand why it would be so important to download something from Maven Central as opposed to our web server. I mean, if you're downloading from the javacc.com server via the secure https protocol, then in pure theory, the provenance and integrity of the file is established. But, in any case, all of that is really kind of an ersatz problem, isn't it?. The whole idea that somebody would put up with all the existing bugs in the legacy JavaCC, in the full knowledge that there is a version available where all these things are fixed, simply because the broken, obsolete version is on Maven Central....
Anyway, on balance, I tend towards just maintaining the current policy regarding "versioning" because somehow, I don´t believe that getting into all this formalistic versioning stuff is really going to get us all kinds of new users. I could be wrong, I suppose, but that is my gut feeling.
