Make java_object_gen.py friendly to use via API.

[Stewori]

No description provided.

[Stewori]

@jeff5 if you don't object I would like to slightly adjust this script to have a convenient entry point for use via API. This makes it more convenient for me to automate source generation in context of a larger setup for generating API documentation. It is preferable (for me) over spawning a new process (popen etc) due to involvement of virtual envs.

[jeff5]

This seems unobjectionable to me. I can't guarantee stability in the way this works, though.

If you were looking for an approach that would be applicable to more than one project, it would be worth looking at Gradle and its targets.

Gradle has strong conventions about project structure and targets. You can configure anything you want, but I will certainly keep that to an absolute minimum. I don't think I'm uniquely dim for finding that going outside those conventions is so horribly complicated and fragile that I have no wish to deal with it. So, ranting aside, you may find a group of projects that put their generated code in consistent places if you can manage to invoke (say) their compileJava target.

You'd know better than I whether Maven is as stylised.

[Stewori]

Jeff, thank you for the pointers. I know gradle can be very convenient, but I found it annoyingly difficult to debug (complex?) gradle setups as soon as something does not go as expected. Yes make setups can be nightmares as well, but at least one can see which command lines are executed, which is not so simple with gradle ("Darn. All I want is the feature that Make has had for 30+ years."). Maybe it's due to my system with multiple Javas and Pythons in virtual envs that gradle frequently fails to work out of the box for me. Probably much of that could be solved if I learned more about gradle(.properties). A systematic solution for those issues is a todo, but for now it is easiest to keep it within Python if that happens to be feasible. My Jython 3-snashot setup is provisorical anyway.

[jeff5]

I know gradle can be very convenient, but I found it annoyingly difficult to debug

Oh good. I'm not uniquely dim then. :-D

You ought to be able to leave that complexity to the project. If you can manage to invoke the standard Gradle command, it should leave files in fairly predictable places (<subproject>/build/generated/sources/<tool>/java/main) as discussed here. You still have to get the project's choice of Java (and for us Python). I was assuming you ran in a container like the CI does so you could safely configure that.

It does not seem to scale if you have to negotiate a hook with each project. I'm happy to try it here, of course. Whatever works for you is fine.

If the scaled idea is to rely on a source JAR there's no problem. I think one such intended to help debugging a client application (of Jython) should include the generated source or we reproduce the difficulty I have with exposed classes.

[Stewori]

Currently I preferably just take the source jars and pom files from maven central, which do not include a gradle config. Using gradel would AFAIK mean to pull a project from version control, e.g. github, which is (in memory and time) way more expensive (and polluted with additional stuff) than exploring maven central. Also, often enough the pom-provided version control handle is crappy. Okay, now that I think of it, the pom file is like a gradle config for maven, so it might contain the source gen targets for maven (there may be tools to convert it into a gradle config as well, but I guess the plugin architectures make that difficult).
Then, there are relatively few projects that do gen sources. So it's really an 80/20 thing. For a proper scaling, the gradle/maven path will be the way to go as a fallback (then there is e.g. OpenJDK which uses make), I'm just not there yet.

should include the generated source

That would be the easiest solution also for my setup and I think most projects handle it that way. Maybe there are cases where platform-specific info is generated into the source files (that's e.g. the case for OpenJDK). A maven-central distributed Jython 3 would include the generated sources I guess (in Jython 2 all xDerived classes are generated). As I said, this is only a provisoric solution for the snapshot. BTW, I don't expect you to keep the java_object_gen.py-API stable. Please do not bother with that at all. I might just hand in a PR from time to time like this one to fix stuff for me in a minimally intrusive way.