rife2
Add `bld-kawa` extension to your organization
Hello!
I've just created an extension for building Kawa sources with your promising build system. Could you please:
- add it to a list of extensions in Wiki, and
- transfer a repo to your organization?
Resulting extension turned to be very simple, I've used bld-kotlin as blueprint. Here it is:
- https://github.com/tribals/bld-kawa
Hi. I'm sorry for some reason I wasn't getting notifications and completely missed your request.
I'll have a look at it very shortly.
It the course of addition this to Wiki: let's not miss opportunity to discuss it a bit first!
😊
Recently I've faced with some interesting findings about how Kawa compiler integrates with the rest world.
I've read some implementation of bld features and found a bunch of methods named somethingClasspath. I also faced a problem when compiling mixed Kawa/Java codebase: if you import your own classes written in Java (from same codebase, not from any library) - compiler will miss them because I think it is set up with wrong class path - compiler need to access already built classes, not (Java) sources, and build/main is not included in Kawa compiler classpath somehow (I think).
Which turns me to think of more clean separation of processes "compiling project", and "the project itself". I'm not sure, how it is commonly done in Java world, but I think this creates inevitable "chicken-and-egg" problem: you need to spawn some Java machine in order to compile your project, but this machine need to access both compiler classes and your codebase classes.
And I'm not sure I understood precisely blds mode of operation, but I think the way I did integration with Kawa compiler in extension reuses the same classpath from "currently operating JVM" (which runs bld).
This is what exactly struggle me when I'm into Java... Java, as a platform, doesn't have a "standard linker" (it is a "linker" whose job is "to find some binaries in system, and compose them into running application"). Java's linking is "you get those JARs - you put them into JVM yourself!"
It turns out that every "sub-community" in Java world tend to re-implement "linker" to their needs. Current "standard linker" of Java is mvn.
Another take on "linking" is Clojure's tools.deps (and tools.build) - it is an attempt to "do it the right way". In a nutshell, tools.build provides a standard way to:
- enumerate a set of "dependencies"
- calculate proper classpath for them
- cache it, so you don't need to re-calculate it until dependencies change
- spawn a new JVM with classpath set according to above ^
It doesn't bother itself with "where those classpath reside on disk" nor "how those disk paths are populated", but provides a way to populate them from Maven repos. So, it build upon Maven heavily (and even reuses some "canonical" libraries from Maven ecosystem).
Although I agree with many design principles incorporated in tools.deps from Clojure, I disagree that only Clojure should benefit from them - and currently it is rarely possible to use tools.deps outside Clojure ecosystem.
One of the problem is that it uses Clojure's native format for "data dumped to disk" - an EDN format (which looks mostly like "Clojure, but without functions").
This is a problem because "Java build tool" should be available for all "Java languages", not only specific ones.
(On the other hand, tools.build also provides "implementation of standard Java & Clojure compilation process".)
So, to me, a "Java build tool" should provide exactly this functionality: let me keep track of "dependencies", compose and re-compose them to "set of classpaths", and spawn as many VMs with those classpaths as needed.
To that end, seems like bld tend to "invent their own standard sets of classpaths", available in "build API".
Can you please elaborate more on those "classpath sets"? I feel this will be most "hot point" of interest for "build class writers", but it dynamic world of Scheme - things get more interesting!
I'm really not that familiar with Kwata. Give me a bit of time to get up to speed with it, before I put my foot in my mouth.
Take your time!
Feel free to use this exemplary repository to jump-start compiling Kawa & Java:
- https://gitlab.com/soccoop-platform/lambda/wordbook/-/commit/3aff77506af70fd2cce8e8f3bd61a73f698767b9
I've looked at the Kawa plugin for Maven implementation and I don't really see anything that can't be done in bld.
As you suspected, they are spawning a new process to execute Kawa commands. This is easily done in a bld extension, for example:
https://github.com/rife2/bld-kotlin/blob/main/src/main/java/rife/bld/extension/dokka/DokkaOperation.java#L86
You can get all needed paths from bld and pass them as arguments.
Hopefully that solves your issues.
Thanks for your time!
^_^
I'll check your example and try to update extension accordingly.
BTW, how about transferring that extension to your org?
BTW, how about transferring that extension to your org?
@gbevin would have to do that.
Hi @tribals, I think you have to initiate the transfer yourself from your project's settings. Once that's started, I should be able to accept it on the other side. Please let me know if you need any further assistance
@gbevin I've just started transfer to your account - couldn't do that for rife2 org.
@tribals I sent you an invite to be a member of the rife2 organization, could you try the transfer again to there afterwards?
Just did that - seems everything is working!
Thanks! Will return later to a transferred repo with MR.
^_^