The version 0.9 is out. While the last version post here was 0.3, but that doesn't mean that the project was dead. In fact, I am using this in most of my (JVM) projects now - and I am not willing to go back to other build systems.
Anyway, what has changed since 0.3? Mostly quality of life things. For example, converting existing IntelliJ project into Wemi can be done with a single button click (at least for simple projects, complex ones may need some tweaking), Maven dependency resolution has been vastly improved (mostly for correctness), CLI gives some nice real-time feedback on running tasks, and, of course, many bug fixes and improvements.
Anyway, what has changed since 0.3? Mostly quality of life things. For example, converting existing IntelliJ project into Wemi can be done with a single button click (at least for simple projects, complex ones may need some tweaking), Maven dependency resolution has been vastly improved (mostly for correctness), CLI gives some nice real-time feedback on running tasks, and, of course, many bug fixes and improvements.
Many projects, and especially games (I know, in Java, *gasp*, don't throw stones at me, please), can benefit greatly from the ability to hotswap code of the running application. Unfortunately, I have not been able to find any existing build systems that support it. I know that IntelliJ IDEA does, but only for code compiled and launched through it, which is often not possible to do correctly when the project is using a build system - which is true for almost all projects, at least for me.
Therefore, I have had a hotswap plugin for Wemi on my roadmap for quite some time now, and I have finally got to implementing it. The plugin itself was not that hard, as I have already created such plugin for SBT. The harder part was designing a minimalistic plugin API. Initially, I didn't want to have any API at all (and I still want to keep it minimal), as all the functionality that a plugin has, should be available to standard build scripts as well. The only reason Wemi has an one-interface, optional, plugin API, is because without it, it was impossible to inject default implementations of keys added by the plugin into the predefined Archetypes.
Long story short, it is now possible for libraries/plugins to say "hey, Wemi, when you add me to the classpath of build script, make sure to call this method so I can initialize myself and add some extra functionality to user's project". And it works pretty well.
Next up, I have been rewriting and simplifying some internal classes and keys. Also, build-script dependencies (such as aforementioned plugins) were previously added by "comment" directives, but those were not checked by the compiler and IDE didn't understand them as anything special, so I have rewritten them to use Kotlin's file-annotations. Oh and bugs, many tiny bugs were squashed in the last few days.
Before the release of 0.4, I still want to fix some bugs found in the command line argument parsing, and improve some introspection commands. But that shouldn't take too long.
If you have read this far, thanks! Feel free to let me know what you think - even though I am still doing this mostly for myself, I'd be happy to hear your opinion. And help, if you decide to try it!
Therefore, I have had a hotswap plugin for Wemi on my roadmap for quite some time now, and I have finally got to implementing it. The plugin itself was not that hard, as I have already created such plugin for SBT. The harder part was designing a minimalistic plugin API. Initially, I didn't want to have any API at all (and I still want to keep it minimal), as all the functionality that a plugin has, should be available to standard build scripts as well. The only reason Wemi has an one-interface, optional, plugin API, is because without it, it was impossible to inject default implementations of keys added by the plugin into the predefined Archetypes.
Long story short, it is now possible for libraries/plugins to say "hey, Wemi, when you add me to the classpath of build script, make sure to call this method so I can initialize myself and add some extra functionality to user's project". And it works pretty well.
Next up, I have been rewriting and simplifying some internal classes and keys. Also, build-script dependencies (such as aforementioned plugins) were previously added by "comment" directives, but those were not checked by the compiler and IDE didn't understand them as anything special, so I have rewritten them to use Kotlin's file-annotations. Oh and bugs, many tiny bugs were squashed in the last few days.
Before the release of 0.4, I still want to fix some bugs found in the command line argument parsing, and improve some introspection commands. But that shouldn't take too long.
If you have read this far, thanks! Feel free to let me know what you think - even though I am still doing this mostly for myself, I'd be happy to hear your opinion. And help, if you decide to try it!
This has been mostly a polish and bugfix release, but there have been some nice features. Changes:
Full changelog is available here.
- Change CLI options to follow GNU standard, including long/short options and --help/--version convention.
Old Java-style options are no longer supported. - Initial support for Kotlin's incremental compilation
- Windows support
- Disallow the `.wemi` build script extension, as it only added complexity and broke things. Use `.kt` instead.
Full changelog is available here.
Hello everyone!
I am happy that Wemi build system has been accepted to be here, with other great projects. First off, the current state of the project: I am using it for all my projects (that don't need any extra features that are not supported yet) and so far, it has been great. Wemi makes it very easy to do complex setups, which would be impossible or messy in other systems (for example the build setup of Wemi itself), as well as simple quality of life improvements, such as the "debug:" configuration (which will be included in the next release), that allows to debug any java process forked from Wemi. Want to debug tests?
will do it.
Next up, there is not much getting-started documentation yet. The code itself is documented and something like specification also exists, but it is pretty dense. So in the near future I will try to create a few tutorial pages. I don't expect anyone to use this for anything even little serious just yet, but it would be nice if people could play with it and provide feedback.
Also, the project doesn't have a license yet. I usually license everything with MIT license, but for this one, I'm thinking of Mozzila Public License 2.0. Let me know if you have an opinion about this, I don't want to discourage anyone from using and/or contributing to the project.
After that is done, I want to focus on testing and improving the core and, most importantly, start working on plugins. Currently, I'm planning to add these:
That is it for today. I will release version 0.3 soon, I just need to do some more (mostly IDE plugin) testing. Among many other fixes, it will feature support for incremental compilation of Kotlin (Java already compiles pretty quickly).
I am happy that Wemi build system has been accepted to be here, with other great projects. First off, the current state of the project: I am using it for all my projects (that don't need any extra features that are not supported yet) and so far, it has been great. Wemi makes it very easy to do complex setups, which would be impossible or messy in other systems (for example the build setup of Wemi itself), as well as simple quality of life improvements, such as the "debug:" configuration (which will be included in the next release), that allows to debug any java process forked from Wemi. Want to debug tests?
1 | ./wemi debug:test |
Next up, there is not much getting-started documentation yet. The code itself is documented and something like specification also exists, but it is pretty dense. So in the near future I will try to create a few tutorial pages. I don't expect anyone to use this for anything even little serious just yet, but it would be nice if people could play with it and provide feedback.
Also, the project doesn't have a license yet. I usually license everything with MIT license, but for this one, I'm thinking of Mozzila Public License 2.0. Let me know if you have an opinion about this, I don't want to discourage anyone from using and/or contributing to the project.
After that is done, I want to focus on testing and improving the core and, most importantly, start working on plugins. Currently, I'm planning to add these:
- Hotswap - to test the plugin system and allow code hotswapping. This functionality is already in the JVM, and I have already done it for SBT, so it shouldn't be hard.
- Android - probably the most useful one
- MOE/RoboVM - two plugins actually, both to allow JVM code on iOS (ultimate goal is to support libGDX on all supported platforms)
That is it for today. I will release version 0.3 soon, I just need to do some more (mostly IDE plugin) testing. Among many other fixes, it will feature support for incremental compilation of Kotlin (Java already compiles pretty quickly).