I couldn't find it in the docs (or, more probably, I missed it), so I presume these are the steps:
Copy existing Erlang application (or create a new one with rebar3 new app) into <umbrella_root>/apps/ (or <umbrella_root>/libs/
Add the new app to the relx section in <umbrella_root>/rebar.config:
{ relx
, [ {release
, { your_big_project_name, "0.1.0" }
, [ your_big_project_name_or_smth_else
, the_newly_copied_app
% , sasl
]
}
, {sys_config, "./config/sys.config"}
, {vm_args, "./config/vm.args"}
, {dev_mode, true}
, {include_erts, false}
, {extended_start_script, true}
]
}.
Add the new app's required configuration environment variables to <umbrella_root>/config/sys.config.
If the new app uses a plugin, configure it in <umbrella_root>/apps/<new_app>/rebar.config.
Am I close? If yes, does that mean that umbrella applications can be nested? (This should probably be a separate question).
Yes, that should be it all you need to include an app file in a release.
Regarding nested umbrella applications, please have a look at the following thread in rebar3's site
EDIT:
The linked thread talks about having umbrella apps as dependencies, which is not supported by rebar3. Quote:
Umbrella applications of that form are just not supported as
dependencies. Handling versioning and locking for a single
dependencies that contains multiple apps is not a thing we ever
figured out, so it's just not doable.
That does not mean that you cannot use some tricks, like using git submodules and multiple project_app_dirs configured in the root. For rebar3 those apps will be local apps, you'll need to handle them from 'outside' rebar3, though (not really 'nested' umbrella applications).
Related
Setting up a full "KMP" / "KMM" project seems like overkill, as only the commonMain/commonTest directories would be filled.
All the other templates seem to be platform-specific.
Is there something like a "pure" Kotlin library template?
It would just be a module with only commonMain and commonTest. You would need at least:
A Gradle module
Kotlin config with multiple targets in that module
Common code folders
Whether you put the app code in the same repo or have the shared code in a separate repo is up to you. I'm not sure how much simpler you can make the config, though.
One issue I think you'll run into is the need for platform-specific code on iOS because there are different interfaces for concurrency than you might want for a Kotlin-friendly (I.E. Android) environment. Same for things like default params.
My-KMP-Library
│ build.gradle.kts
└───src
└───commonMain
└───kotlin
└───mynamespace
What makes it multiplatform are the targets you specify in build.gradle.kts.
This is for Firebase 6.26.0 and 6.27.0 (I've tried both for reasons that will become clear)
I have a Swift application I'm trying to decompose into modules from its current monolith, but so far I have not been able to expose Firebase classes across the modules (i.e frameworks) by installing Firebase pods in each individual module. It will only work when there is only one existing library, and when that library is installed in the application target, where it is instantiated in AppDelegate.
Does anyone know if it's possible to implement Firebase across multiple modules in a single workspace?
Expected results
That Firebase classes will be exposed to all modules in a multi-module Swift application, with one or more copies of the Firebase library present, allowing all modules to call Firebase methods and implement Firebase classes within a single, global instance of FirebaseApp.
Actual results
Either Firebase refuses to instantiate because of the presence of more than one Firebase library in the workspace, or, when only one library is present, Firebase classes cannot be exposed to other modules in the workspace.
What I've done
Installed individual Firebase pods in every module requiring them. On launch I got this error:
.
The default FirebaseApp instance must be configured before the defaultFirebaseApp instance can be initialized
.
According to an answer from a Firebase team member on another StackOverflow post, this is caused by the presence of more than one Firebase library in the workspace.
Installed only one pod to create a "FirebaseProxy" module that both the application target and all other modules could share. By using typealiases and extensions I was able to let classes implement Firebase classes without having to be exposed to the actual Firebase library, for example:
import Firebase
public typealias FirebaseUserProxy = Firebase.User
public extension FirebaseUserProxy {}
So this way an implementing class could use the Firebase.User type by using FirebaseUserProxy instead, and without having to be directly exposed to the Firebase library.
.
However, there were some proxied classes that still seemed to require being exposed to the full library. (My brain is a bit addled from dealing with all this so I've forgotten exactly which ones, I believe it was FirebaseApp.) But even using #_exposed import Firebase in the proxy definition didn't do the trick, and I only got the message Missing required module 'Firebase'.
Same solution as in #2, but using use_frameworks! :linkage => :static in my Podfile. No luck. And yes, I did try using $(SRCROOT)/Stat in my frameworks search paths build settings.
Finally I tried integrating the library directly into my project without using Cocoapods. Here I was using 6.26.0 since the Firebase download link with a 6.27.0 in the URL resulted in a Not Found message, so I manually changed it to 6.26.0 and that downloaded fine
.
I installed the library in the application and in another module, hoping that somehow this method would obscure each library from the other, but ended up with the same error message as in #1... The default FirebaseApp...
.
I also tried using the proxy method from #2, but that resulted in the same error.
.
I had to set :linkage => :static in my Podfile so the installed pods would play nicely with the integrated library. Turning it off resulted in an error.
Alternatives
If I can't get this to work, I may have to refactor my code so that the Firebase-dependent code exists in the application itself instead of a standalone framework module. This would not impact functionality, but it would break the architecture and make the code a good deal more convoluted and brittle.
There is a solution on the Firebase git repo (that I haven't tried), that suggests reverting back to v.6.15.0. I am reluctant to do this though since the most recent release is at 6.27.0 and I don't want to be unable to upgrade and risk using an older version that later releases will undoubtedly break eventually.
Finally
It's disappointing that such a widely used and vital tool can only be used in monolith applications, basically limiting developers to a single, often suboptimal, type of architecture. Have I missed something? Maybe. It wouldn't be the first time. But if anyone can light the way out of my dilemma I would be happy to buy you a beer, and given the current social distancing regulations, consume it on your behalf.
I'm trying to rollup my completely es6 module repo which has both local imports/export for the projects, and imports to dependencies that are also either scripts or modules.
I'm also trying to have a dual build which creates legacy iife modules via rollup.
This works fine for just my project, no problems. The difficulty is that I have imports for my dependencies.
Rollup's globals and external options are supposed to help but thus far I haven't succeeded in exposing these and rolling up to an iffe. I get
http://backspaces.github.io/asx/libs/three.module.js' is imported by src/Three.js, but could not be resolved – treating it as an external dependency
errors and others. The resulting rollups are not what I want: converting the iife rollup to expect the dependencies to be globals thus removed from the rollup.
I realize this is a pretty general question, but I just want to know how to use these two options to manage my repo so that I have imports to dependencies and can "remove" them in the rollup.
Can anyone clearly explain them and what they do? The rollup wiki is slightly helpful but not complete enough.
For Rollup to be able to include a dependency, it has to be able to find it. It doesn't have any built-in logic for fetching a remote URL such as http://backspaces.github.io/asx/libs/three.module.js (that could be done as a plugin, but AFAIK that plugin hasn't been written, and I'd probably advise against it anyway).
Instead, you'd be better off importing the module from node_modules like so...
import THREE from 'three';
...and adding node-resolve and commonjs to the config that generates the IIFE.
For the config that generates the non-IIFE build where Three.js is kept external, you would need to use the paths config to point three back to the URL:
// rollup.config.js
export default {
entry: 'src/main.js', // or whatever
// ...
external: ['three'], // so it's not included
paths: {
three: http://backspaces.github.io/asx/libs/three.module.js
}
};
I have developed a generic app, which can ne customized for clients. Each app should be available in the app store.
Any idea what is the best way to deploy the different apps? This is of course also necessary on app updates.
Only the package name, some graphics and some settings change for different Apps. The Code will be the same for all.
Consider deploying your app as a framework, static library or CocoaPod. The clients should be able to use your framework/pod to customize the appearance (and anything else) and publish their apps.
CocoaPods: If your project is in progress and your client is using it, I wouldn't recommend it. Pods are great way for managing dependencies mostly if dependencies are not going to change on nightly basis. Also you'll have to make a few decisions about how to integrate it with your source control. If you and your clients will be working on their client app and pods simultanously. They'll most likely have to get your pods in a workspace, which defeats the purpose of pods. (If somebody knows a better way around editing pods and project simultanously, please let me know as well.)
Static Library/Frameworks: Rey Wenderlich has a good tutorial for creating frameworks. http://www.raywenderlich.com/65964/create-a-framework-for-ios
I would like to integrate an existing Xcode project A into another project B so the second one could reuse some features.
Project A :
quite complex, manage authenfication + session, a lot of dependencies betweens classes (notably UIViewController)
relies on a dozen of Cocoapods dependencies
the project lives on its own : it's a sale channel/ticket shop that is already deployed on the store as it
constant evolution
Project B :
Project customer side that would love to integrate some parts of the sale channel
Complexity might be very variable (using Cocoapods or not, etc)
Basically we can either deliver and package the e-commerce shop for one of our customer if he does not already have an iOS application, or we have to integrate it in their existing one.
Expectation :
ideally we could pursue the evolution and iteration on the core Project A without having a lot of work to make it available for integration (it would be more cost efficient for us to work on a single project than on the core one and separate SDK/Library made from scratch)
we want to make it easy to integrate for the customer on its own
The approach we have been thinking to are :
build a .a library file. But it does not seem really practical considering the size of the project
dropping the .xcodeproj from A into B (à la ZXing), but it was a pain because of Cocoapods dependencies
Simply adding all the classes from A into B (with a proper packaging into folders first), manage Cocoapods for B (add dependencies from A if Cocopoads already used or set it up), and make all imports easier by editing .pch accordingly.
What would be your suggestion ?
Since you are already using cocoapods I would try to do a private pod(s) with the shared characteristics. That way you can easily track versions across projects and use the same tool to manage all the dependencies.
This approach also would make easier for the customer to integrate as he will see the shared code from the pod as long he has access to the repository but not the complete main project.