There is multi project sbt build config that contains bunch of microservices in one repo. Each microservice is self-contained. Also there is separate repository called common that contains shared model for the microservices.
What I would to know is how to handle dependencies between common project and microservices that use it.
Does git submodules approach properly fit in this case?
The one possible solution is to create submodule common in main repo and make each microservice dependent on that module:
serviceA.dependsOn(common)
serviceB.dependsOn(common)
...
Another solutions is just to add specific dependency to common to every microservice:
serviceA
.settings(
libraryDependencies ++= Dependencies.common
)
What is the pros/cons each of these approaches?
And what is the proper way to manage shared code relation in general?
Thanks is advance!
Related
I am primarily a java developer, but I am developing a dotnet core 2 platform of restful services (webapi's). In Java/Maven, I can have a parent POM that includes all the outside dependencies of the project, enforces unit tests on the build, runs various static code analysis, etc.
Is there any way to do these things in dotnet core 2? Can I have a "parent solution" file that does some of these things? Is there a dotnet core 2 standard for tying multiple projects together in this sense? Or do I have to trust that my developers will have the discipline to make sure their projects follow the same structure?
You can define common elements in a main msbuild file, then import it in your various .csproj files.
For example, corefx has a file that lists all dependency versions. This file then gets imported into various other build files: https://github.com/dotnet/corefx/blob/master/dependencies.props
We have a multi module project consisting of two modules, modA and modB.
modA depends on modB.
modB in turn depends on a list of libraries (libA and libB) where we also have the source code. This sources have already been adapted by us.
At last, libB and libC are independend from each other, but depend on a third library, libC.
What I want to have is a setup, where the three libraries (which are in principle also a multi-module SBT project) can just be "included" in the top level project.
The point here is also that these libraries can be re-used for other projects, too, so the changed sources should not belong to this super project only.
Currently I tried to solve it by including the library as GIT submodule.
Unfortunately SBT does not (seem to) support hierarchical sub modules, so I cannot really just have a second, also multi-module SBT file for all libraries which just gets included in the "super-super" project.
This current setup is clearly not the SBT way.
What is the intended method of solving this?
Just adapting the library separately and re-using it just as JAR file in the super project is possible, but clumsy, because the using project(s) are the main reason to hack the library, so it would be nice if this works in a smooth way.
In a Karaf features file if I include certain bundles then Karaf stops working correctly.
How can I know what bundles I should not include in a features file? for example, if I added these bundles in the features file in Karaf on Windows, Karaf is not happy and acts strange. I assume its because Karaf already provides Java interfaces for these bundles.
<bundle>mvn:org.osgi/org.osgi.core/4.3.1</bundle>
<bundle>mvn:org.osgi/org.osgi.compendium/5.0.0</bundle>
Also is there a programmatic way to determine this?
Is there a list of bundles which I should not include?
I understand that Karaf uses pax-logging rather than those slf4j.
In more detail, my SBT project compiles a list of dependent bundles for my bundle, in my list that I get back from my code I get the org.osgi.core and org.osgi.compendium. They are dependents of my osgi bundle which is my main project. Now, the problem is, how can I know that Karaf does not want this installed as part of my features?
Thou' shall not install other framework packages besides the framework ;)
This is an absolut NOGO!
As Karaf already provides everything you need, in that case the Framework.
So don't even think about adding the std. framework packages to your OSGi env, they are already all there.
If you want to have certain compendium packages.
Make sure you Install the implementing bundle, as you already pointed out, the pax-logging bundles already provide everything needed for the osgi logging compendium services.
Same is true for Pax-Web and the OSGi HttpService packages.
You'll find a lot of already pre-registered OSGi compendium services with Karaf,
if you need more, install the implementation, not the spec bundle.
edit
nop programmatic or Karaf internal way can tell you about to not include those bundles. It's just something commonly known.
An implementing bundle always also will bring you the needed osgi packages.
I keep seeing sbt projects with the following resolvers setting in their build definition:
resolvers += "Local Maven Repository" at "file://"+Path.userHome.absolutePath+"/.m2/repository"
It's also described in the official documentation of sbt in Resolvers section.
My limited knowledge of using sbt and build management tools in general lets me however consider it as a kind of anti-pattern.
The reason is that if a project declares a dependency on a library in the Local Maven Repository it somehow got downloaded there in the first place so it's available somewhere outside the local maven repository. If it is, why not using the original repository as the source?
If the dependency is not in a public repository, and is a dependency of a project, the project can use dependsOn to declare it without the additional repository in resolvers.
Please advice as I may be missing something obvious that makes the resolvers setting indispensable.
One obvious reason would be if one of your dependencies is a local project built with maven.
One scenario:
You have a project x which you build with sbt
X depends on y. Y is built with maven.
There is a bug in y which you need to fix/test, and you want to regression test x before you check it in.
You build a snapshot of y, and then you can test x before you commit the change to y.
I have been trying to find more information on RootProject and ProjectRef, but looks like it is not mentioned at all in sbt documentation.
I understand that if you are referencing a root project you should use RootProject and ProjectRef when you are referencing a sub-project. However it is not clear how the behavior will be different between them. Can somebody please help explain?
Also the fact that it is not documented, does it mean that RootProject and ProjectRef are not the recommended way to reference other sbt projects?
Thanks.
A single sbt build has a single project/ directory for .scala build definitions and plugin definitions. There can be multiple subprojects within that build with their own .sbt files, but not their own project/*.scala files.
When you want to include other, separate builds directly instead of using their published binaries, you use "source dependencies". This is what RootProject and ProjectRef declare. ProjectRef is the most general: you specify the location of the build (a URI) and the ID of the project in the build (a String) that you want to depend on. RootProject is a convenience that selects the root project for the build at the URI you specify.
Source dependencies do have an overhead: startup time, memory usage, and command line usability. If the group of projects don't need to be separate, it is best to use a single build with standard subprojects.