Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedback: Manual Dependency Management #2

Open
MarcDahlem opened this issue Jun 11, 2018 · 1 comment
Open

Feedback: Manual Dependency Management #2

MarcDahlem opened this issue Jun 11, 2018 · 1 comment

Comments

@MarcDahlem
Copy link

MarcDahlem commented Jun 11, 2018

Dear @DmitryBespalov,

very intersting article; thanks for that and your provided solution.

In our company, we faced similar problems, as we have a very modular environment in which every 'module' is an own *.framework.

We were also unhappy with the dependency management with cocoapods, third-party libraries, recursive dependencies, dependency conflicts and so on.

For this reason, we migrated all our projects to kind of a manual dependency management.

But we didnt build it our own: We used gradle!
That was a very good choice.

How does it work from the console (sketch):

  • we run ./gradlew build to build a framework, or the app itself
  • Our gradle-build-task depends on the download and extraction of the gradle/maven dependencies of all used frameworks
  • in xcode, we define the framework dependencies to local *.framework files
  • if we build framework, the final framework is published to our gradle/maven repository, including in the maven description the transitive dependencies to other modules

How does it work from XCode (sketch):

  • We have a prebuild-task to run as external tool: `./gradlew dependencyUpdate' which downloads all dependencies
    • reason: if you checkout a module, you can directly build it from xcode, without the need to open the console

How do we handle external libraries:

  • We upload all external libraries also to our gradle/maven repository
  • If an own module depends on such an external library, it can define its dependcy also in gradle
  • There are two downsides:
    • You need to manage new versions of external libraries by yourself and re-upload the new version to the maven repository (cannot automatically find new versions)
    • For closed-source PODs it can be tricky to tranform their artifacts to reusable frameworks or static libraries

All in all, the positive aspects outweigh the downsides:
You use a well-known dependency management system, dependency conflicts are shown during build time. The use of gradle not only allows dependency management, but we also added build-tasks to easily and automatically increase version, publish modules to maven and tag our git repository.

@DmitryBespalov
Copy link
Owner

Hi @MarcDahlem, that's so sweet! Thank you for sharing this, it solves all those manual steps and allows for dependency tree configuration. Nice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants