Apktool: [RFE] Maven repo (revisited) or Jitpack compatibility

[Lanchon]

hi Connor,

thanks for maintaining this project!

i've been publishing gradle plugins with apktool tasks for years now. these includes a non-opinionated base plugin with apktool tasks that users can use at their discretion (https://plugins.gradle.org/plugin/com.github.lanchon.dexpatcher.base), and several opinionated plugins in which apktool tasks are integrated in dexptacher workflows.

in all cases, a local clone of a repo with several binary tools (including apktool) is needed. this is similar to how the android gradle plugins need a local copy of the sdk (and a link to it in 'local.properties').

this sucks because the versions of the tools are not specified in the 'build.gradle' file, and thus updating the tool repo can break old builds. (also, versions of the various tools are locked among themselves by belonging to a single binary repo.)

i want to update my plugins to have them dynamically download, cache, expand and use the various binary tools. this brings easier setup (no local repo needed, and no linking from project to local repo) and self-contained builds with proper versioning.

i wanted to use the release mechanism of github as a target for a custom repo implementation in gradle, so that files would be picked directly from github. unfortunately i ran into this showstopper issue: https://github.com/gradle/gradle/issues/5322

it turns out github redirects to AWS and they don't support HEAD (!!!). and gradle has no intention of working around this issue. to make things worse, bitbucket also uses AWS and has the same issue.

so basically there are 3 solutions:

1. that you revisit your decision not to publish to maven. it's easy (though a bit cumbersome) to publish to maven via sonatype's OSS repo.
2. that you make your project compatible with Jitpack. Jitpack automatically clones repos, builds them, caches their artifacts, and publish them in a repo. as you can see, people have been trying to use it on your project: https://jitpack.io/#iBotPeaches/Apktool. unfortunately the uber jar of the project is not being published. if you could make your project compatible with jitpack, you would get maven releases automatically and for free just by creating your usual version tags.
3. that i create a repo myself and republish your tools. but i don't want your updates to apktool to depend on me!

i am hoping you'll consider an automated distribution solution for apktool, in enables all sorts of automation.

thanks for reading!

[iBotPeaches]

I might give Jitpack another try. They really pissed me off, because they built this project without any approval from me and sent buggy-broken builds into the wild and left me with plenty of extra support work.

I believe I asked them to perma disable Apktool on it, but it seems that has been reversed. I'll take another look since back then they didn't allow custom build commands which has since been changed.

Not sure on priority though - lots of pending PRs and things to do.

[Lanchon]

hey Connor,

i've fixed it myself for the time being:
https://dexpatcher.github.io/dexpatcher-repo/

not as good as official, but for now it'll have to do.

thanks!!!

[jkushmaul]

Not a solution, but a workaround:

I created url2maven to do something similar, https://gitlab.com/jkushmaul/gradle-url2maven-plugin
(Because patterLayout's - which would work using the bitbucket releases, don't - because of apktools being hosted on S3, which doesn't seem to support the standard HEAD request ivy/maven expect.
(https://github.com/gradle/gradle/issues/5322)

You can see an example of using it to download apktool to local maven cache here: https://gitlab.com/jkushmaul/gradle-smali-plugin another plugin I made which does something similar it sounds to the dexpatcher plugin you mentioned.

[Lanchon]

i already did a gradle repo that points to github/bitbucket/etc releases, and as you found out, none of those work because theu don't support HEAD. stupid amazon. that's why i published my own repo.

and dexpatcher is nothing like smali or a smali plugin.

[jkushmaul]

Not sure how to take your comment there, but you had an issue with hosting your own repo, so I offered up url2maven as a workaround since we are blocked because of amazon (and apparently other providers as well, didn't know they too had the same problem).

I was simply stating that I too need apktool.jar for my smali plugin, similar to how you do, and you could use that as an example to pull it in the same way. Thought it would help.

[Lanchon]

yes, i see what you mean.

i really need the full power of gradle's dependency management. i need customizable configurations, not just downloading a file with gradle caching. and i need the configurations to be built not by me, but users of my tools. so they need to be pretty standard. instead of hacking my own downloads in every client, i chose to hack my own repo and use standard clients.

this ended up being a better choice because it allowed me extra freedoms, such as publishing constituent parts of apktool as separate artifacts (https://dexpatcher.github.io/dexpatcher-repo/), better artifact naming, and publishing from sources other than github releases if needed.

my local repo is maintained automatically with a cron script. (but origin pushes are done when needed under my supervision.)

the repo updater script is free software too, so you can easily do your own apktool repo if you want to stop using your download plugin but not use my repo.

finally, yes, dexpatcher is nothing like smali :)

thanks!

[iBotPeaches]

Took another look. I still hate Jitpack sorry. The interface is god-awful for someone trying to manage their own repos. It continues to just want to build build build things automatically and who knows how many support requests I deal with it if their download counters are accurate.

Don't have time or drive to dig into automating this. Glad they have a override yml file now, I committed one to break the service. If you want to explore a fix upstream directly - I may consider it, but I don't want to spend anytime on this thing.

Closing.