congo-cc / congo-parser-generator

The CongoCC Parser Generator, the Next Generation of JavaCC 21, which in turn was the next generation of JavaCC
https://discuss.congocc.org/
Other
36 stars 11 forks source link

Build jar with all dependencies by default. #37

Closed vsajip closed 1 year ago

stbischof commented 1 year ago

Could you please give me some information about the background and benefits of this PR?

i think it was good that the jar, that induces the dependencies was named -full.

default should be that id does just contains projects sources.

revusky commented 1 year ago

Could you please give me some information about the background and benefits of this PR?

i think it was good that the jar, that induces the dependencies was named -full.

Well, you could make that argument, I guess. Basically, this PR emerges from a conversation with Vinay of just a couple of days ago. Vinay expressed the view that it would be better for the default jar to be the uber-jar with all the dependencies. In fact, at the moment, the only dependencies are the freemarker classes. (This is not apache freemarker, by the way, and that's a long story that I could tell you separately...)

So, the idea would be that what was called congocc-full.jar before would now be called simply congocc.jar and what was called congocc.jar could be called congocc-minimal.jar. And, as you probably know, that can only be used if you have a freemarker.jar in the same directory. (And actually, failing that, it will use a freemarker.jar in the bin subdirectory. See https://github.com/congo-cc/congo-parser-generator/blob/main/build.xml#L158) The reason for the 2-jar setup is actually that I anticipated being able to swap in a different freemarker.jar for testing purposes, but the typical end-user is never going to do that, so the idea is that it's just simpler to have the single-jar with all the dependencies as the default.

That's the background. As for the benefit, well, it is fairly minor. The benefit would basically just be that, assuming the typical usage is just to use the uber-jar, then typical usage examples are just less verbose.

So, finally, I tend to think this is a bit better. In terms of the Maven plugin etc. does this pose any problem?

default should be that id does just contains projects sources.

stbischof commented 1 year ago

Thx for explaining,

Its just a small fix for maven. Will do fix after merge an release here.