kobalt
kobalt copied to clipboard
cbeust
List of desired plug-ins
Which plug-ins would you like Kobalt to have? Add comments to this issue and I'll add them to this list.
- Shading
- OSGi
- SQLDelight (https://github.com/square/sqldelight)
Android:
- ~~SDK Manager (https://github.com/JakeWharton/sdk-manager-plugin)~~
- Android Extensions (https://kotlinlang.org/docs/tutorials/android-plugin.html)
- AndroidDevMetrics (https://github.com/frogermcs/AndroidDevMetrics)
- Hugo (https://github.com/JakeWharton/hugo)
- Dexcount (https://github.com/KeepSafe/dexcount-gradle-plugin)
Could there be a plugin that works with Git? For example, clone a repo from sources like Github, build and add to the list of dependencies.
@aneophyte Interesting idea, I'm guessing as a template then, e.g.
./kobaltw --init git http://github.com/cbeust/kobalt.git
?
That would be nice too. But I'm also thinking about including git repo as dependencies like say, git("http://github.com/someuser/niceproject.git") inside compile. I think this will be cool.
Ah. That's pretty much what jitpack does, though...
Cédric
On Mon, Mar 21, 2016 at 9:46 PM, aneophyte [email protected] wrote:
That would be nice too. But I'm also thinking about including git repo as dependencies like say, git("http://github.com/someuser/niceproject.git") inside compile. I think this will be cool.
— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/cbeust/kobalt/issues/159#issuecomment-199635676
Oh wow, been seeing that mentioned a lot. Hadn't checked it out. That's covered then. Templates are still nice.
But I'm also thinking about including git repo as dependencies like say, git("http://github.com/someuser/niceproject.git") inside compile
Ah. That's pretty much what jitpack does, though...
Maybe a smaller subset of what jitpack does would be useful functionality here. If the reference repo also uses kobalt, kobalt could essentially import the remote source from git and include it in the local build. So you would essentially have the ability to do cross-project / multi-module compiles simply by including the source URL. Its taking snapshots one step further.
This would be limited to repos that use kobalt -- other use cases need regular snapshot builds/jitpack.
Ratpack plugin, analogous to gradle-ratpack plugin: https://github.com/ratpack/ratpack/tree/master/ratpack-gradle
Artifactory Publishing: https://plugins.gradle.org/plugin/com.jfrog.artifactory Maven Central Publishing: (may already exist?)
While not a plugin itself, a plugin repository would be really valuable. plugins.gradle.org improved the quality of life and discoverability of Gradle plugins tremendously.
@zoltu bintray is already supported, so making it more generic to support any arbitrary artifactory should be trivial.
Right now, just maintaining a wiki page with the Kobalt plug-ins I know about: https://github.com/cbeust/kobalt/wiki
Everything here: https://plugins.gradle.org/search?term=zoltu
If you can get Kobalt working enough for it to work for me I may port those ones for free. 😄
com.zoltu.application-agent in particular saves a ton of complicated boilerplate. I'm not sure how much sense it makes in Kobalt if Kobalt doesn't implement the Gradle built-in Application plugin. If it doesn't, then I would add that to the list first.
The versioning plugin is super simple (but also a huge time saver IMO) assuming that a plugin can set the "version" of the Kobalt artifact.
Isn't an agent just an extra flag for the JVM? If yes then it's already supported in Kobalt with jvmArgs().
In theory, it is just an extra flag. However, it is an extra flag that has a parameter that needs run context because it needs to reference a library that was pulled in via dependency management. -javaagent $APP_HOME/dependencies/quasar-1.2.3.jar Unfortunately, in Gradle the $APP_HOME isn't exposed in the right places so a plugin is necessary (you can't just use the JVM Args that the Application plugin uses).