Consider the following project structure as a Gradle build:
backend
|- adapters
|- adapter-common
|- bar-adapter
|- bar-entrypoint
|- bar-models
\- bar-services
\- foo-adapter
|- foo-entrypoint
|- foo-models
\- foo-services
|- backend-common
|- db-conn
|- backend-entrypoint
|- build.gradle
\- settings.gradle
The dependency structure is as follows:
foo-adapter depends on foo-entrypoint and adapter-common
foo-entrypoint depends on foo-services
foo-services depends on foo-models
adapter-common depends on backend-common & db-conn
Now I have a separate project api where I need foo-adapter as a dependency. I found this Q&A which seems to be the same situation but when I tried it I get errors about how none of the other projects (adapter-common, db-conn, etc.) are found.
Am I asking too much from Gradle by telling it to just import foo-adapter and then expecting it to pull in and resolve all the dependencies itself?
Is there any way to get this to work without declaring basically the whole backend project in my api settings file?
If your foo-adapter project use some classes from other projects it cannot be added without the others. Not matters it's a jar or just uncompiled stuff. You need the others too. It's a really bad approach to depend a project on another. Better you use only interfaces and put them into a separate project. Thus your projects can be compiled independently and you need just one configuration project that combines all that stuff.
Related
My question is related to the structure or approach of Go applications. I have got the following application.
root
|- app
| |- services
| |- repositories
| |- handlers
| |- commands
|- go.mod
|- main.go
The Go files in the commands package are working independently. The rest of the packages are working for a web application. I start an HTTP web server in the main.go
So, I'd like to run the Go files in the commands packages in the crontab. But as I know, I'll build these whole packages into a single binary file. My question is how can I run the Go files in the commands packages independently in the crontab? I think I should separate them into 2 applications such as "web app" and "command app" but actually they are related to each other and I don't want to manage 2 apps differently. May I use commands Go files in the crontab and on the other hand start an HTTP web server in the main.go?
There's no reason why you can't import packages from your web application module into another one, but if you want to keep them together, you can just do what is quite common, and add additional main packages in specific directories, giving a directory structure like this:
root
|- app
| |-services
| |-...
|- cmd
| |- tools
| | |- main.go
|- main.go
You can build/install your CLI binary simply by running go build ./cmd/tools or go install ./cmd/tools
I want to use a project in my project as a git submodule, ideally without changing the upstream project (or if it makes sense, changing it in a way that will get merged there).
The problem is that the project consists of modules, 2 of which I want to directly use, with the one also depending on the other.
myProject
├ submodule
| ├ first
| | ├ build.gradle: implementation project(":second") <---- this fails if I don't change it to :submodule:second
| ├ second
| ├ settings.gradle: include ':first', ':second'
├ app
| ├ build.gradle: implementation project(":submodule:first"), implementation project(":submodule:second")
| ├ settings.gradle: include ':submodule:first', ':submodule:second', ':app'
As my project's settings.gradle replaces the submodule's settings.gradle, the submodule's absolute paths suddenly change. Can I somehow `include ':submodule:second as :second'?
I know I can use implementation project(somePrefix + ":second") and define this somePrefix accordingly but that would involve touching the submodule.
Gradle project paths (e.g. ':submodule:second')
actually represent project hierarchies. This means that using include ':submodule:second' in your settings.gradle will implicitly create a project called submodule, even if not relevant for the build at all.
do not need to match the directory structure (this is just a convention). You may set the project directory independent from the project path (and the project name).
Check out the following example from the documentation:
// include two projects, 'foo' and 'foo:bar'
// directories are inferred by replacing ':' with '/'
include 'foo:bar'
// include one project whose project dir does not match the logical project path
include 'baz'
project(':baz').projectDir = file('foo/baz')
However, I would recommend to not use include at all. Instead use includeBuild and setup a composite build. Composite builds differ from classical multi-project builds in their coupling. Since your Git submodule indicates a build that may be used as a standalone project (with its own settings.gradle), the strong coupling of a multi-project builds seems inappropriate. Multiple settings.gradle files may also cause problems in a multi-project build, but are fine for composite builds.
I currently want to add some self written classes ("mycode.cpp" and "mycode.hpp") to a big existing C++ project that is configured with Cmake. These classes are located in "myfolder" which is located in the "lib/pointrender" folder of the existing project (see dummy hierarchy below).
|- libs
| |- core
| | |- ...
| |- pointrender
| |- myfolder
| | |- mycode.cpp
| | |- mycode.hpp
| |- existingclasses.cpp
| |- existingclasses.hpp
| |- project.cmake
|- CMakeLists.txt
In the CMakesLists.txt the pointrender folder is declared as a subproject.
declare_subproject(libs/pointrender)
How do I best add my code to the existing cmake configuration? Do I add it as a subfolder in the project.cmake with a seperate CMakeLists.txt in myfolder? Or do I best add it as a subproject with a seperate project.cmake file? What's the difference?
This project.cmake is being include()d be some CMakeLists.txt and get's executed as part of it. Authors of project you are using rolled this out for some reason, so it's probably better to use their infrastructure to add custom code.
The usual way to do this is writing your own CMakeLists.txt and add_subdirectory()ing it from the upper level.
If you wish more details you should update your question with project.cmake contents.
I don't know if I totally got the concept wrong, but I want to create several projects with dependencies to other projects which are not part of the directory structure of a parent project. I know that the normal way of doing this would be to use an external dependency which fetches from some external repository. But in this case, where let's say in project called 'F' a framework is developed, which is used in project 'P'., then P uses F, but F should IMO not necessarily be a sub-project of P as P is only used to test-drive the development of F (but it's not only a unit test). Later in the process, when F is stable, F is separated and can be consumed by other projects via a repository. But during development of F with P as it's test case, it would be nice if that round-trip through the repository could be omitted.
To make matters worse, for the initial development there is more than one test-driving consumer project, which all need to have a dependency to F, but not via an external repository.
My idea is to develop F in some place on the disk with it's own git reposity. The other P like projects reside somewhere else on the disk and have a local file system based dependency to F. Would such a construct be possible in Gradle? If so, where do I start? I scanned the Java examples but couldn't find an appropriate example.
Any ideas?
The Gradle project hierarchy is fully virtual. It just has the default that the physical location corresponds to the virtual hierarchy. But you have complete control over this. See: http://gradle.org/0.9-rc-1/docs/userguide/build_lifecycle.html#sec:settings_file
Regarding your other ideas have a look at the following Jira: http://jira.codehaus.org/browse/GRADLE-1014
You could consider a folder hierarchy like this one:
Main folder
|- F folder
| |- .git
| |- sources
| |- build.gradle (with parts specific to F)
|- P folder
| |- sources
| |- build.gradle (with part specific to P)
|- build.gradle (with common parts)
|- settings.gradle
So you can always decide to run gradle on either the F project, the P project or the two alltoegether. It will also allows you to promote you F project alone without the P or any other side projects.
For more up-to-date information, check the Multi Project Builds chapter of the Gradle documentation.
I have a monolith Gradle project that contains multiple subprojects, each with its own subprojects, like so:
project
|
|-- subprojectA
| |-- models
|
|-- subprojectB
| |-- models
This compiles fine but the issue is when I try to add a dependency on :subprojectB:models to :subprojectA:models, Gradle thinks :subprojectA:models is trying to add a dependency on itself and complains of a circular dependency, even though I specify the fully qualified path like so (in subprojectA's build.gradle):
compile project(':subprojectB:models')
How can I avoid this? Can subprojects not have the same name even if their paths are unique?
Project identity for dependency resolution is based on the group:name:version or GAV coordinates, as explained in the linked Gradle issue.
So you need to make sure your different models project have different GAVs.
One way to make this happen is to make the subprojectA (or B) part of the group.
Another way is to assign names that are not based on the containing folder.
That's currently a known Gradle issue as Gradle by default uses the parent directory name as the project name. You can work around the issue as described here by assigning unique subproject names in the root project's settings.gradle like so:
include ':subprojectA:models', ':subprojectB:models'
project(':subprojectA:models-a').projectDir = file('subprojectA/models')
project(':subprojectB:models-b').projectDir = file('subprojectA/models')