When looking at the gradle documentation, the example it gives for multi-project builds states:
Note that the root project does not have a Gradle build file, only a settings file that defines the subprojects to include.
The thing I am wondering is whether or not a root project not having a build file would be considered best practices or if the documentation is vague in that regard.
If you have a need for it, you could yes! For example, I have a few check-environment tasks run at root before running any multi-modules.
If you don't think you need it though, I'm fairly sure you can do without it!
It is commonly used to load project-wide plugins, so one probably should include it.
And it is rather the other way around - one does not need any of the subprojects.
Related
We have a directory structure like so
java
build/build.gradle (This does NOT exist yet, but we want this)
servers
server1/build.gradle
server2/build.gradle
libraries
lib1/build.gradle
lib2/build.gradle
We have 11 servers and 14 libraries with varying uses of dependencies. EACH server is a composite build ONLY depending on libraries (we don’t allow servers to depend on each other). In this way, as our mono-repo grows, opening up server1 does NOT get slower and slower as more and more gradle code is added(ie. gradle only loads server1 and all it’s libraries and none of the other libraries OR servers are loaded keeping things FAST).
Ok, so one problem we are running into is duplication now which is why we need build/build.gradle file AND we want EVERY module in our mono repo to include that somehow for a few goals(each goal may need a different solution)
GOAL 1: To have an ext { … } section containing a Map of Strings to gradle dependencies much like so
deps = [
'web-webserver': "org.webpieces:http-webserver:${webpiecesVersion}",
'web-webserver-test': "org.webpieces:http-webserver-test:${webpiecesVersion}",
'web-devrouter': "org.webpieces:http-router-dev:${webpiecesVersion}"
]
In this way, we want ALL our projects to them import dependencies like so
compile deps['web-webserver']
GOAL 2: We want to 'include' a standard list of plugins so we are versioning all gradle plugins the same across the repo. While the above configures all jars to avoid jar hell in a mono-repo, we would like to do the same with just this section
plugins {
id 'com.github.sherter.google-java-format' version '0.9'
}
Of course, it each project may also want to add a few more plugins OR even not depend on this section(in case of an emergency and trying to just get the job done).
GOAL 3: We want checkstyle configuration (or any plugin config) to be defined the SAME for all projects (eventually!!!). We would like the checkstyle gradle to live in a common area but have all libraries somehow pull it in. Again, it would be nice for it to be optional in that, I can pull the gradle section into my build.gradle OR can create a new one in case of emergencies so I don't have to fix all projects in the monorepo right away.
IDEALLY, perhaps I kind of want configuration injection where when I run server1/build.gradle, it actually runs java/build/build.grade as it’s parent somehow but with overrides (IF I declare 'extends xxx.gradle' maybe) then all libraries it uses also use java/build/build.gradle as their parent. I am not sure this is possible or feasible. I am pretty sure 'extends xxx' doesn't exist in gradle.
Are any of these GOALS possible?
thanks,
Dean
I have been working on a monorepo with the exact same requirement as you, using gradle composite builds as well. The way we have solved this problem is by using pre compiled plugins
You need to do a new gradle project with only the code you want to share. This will create a plugin, that you can just add as a composite build and apply to the other projects.
I'm a bit confused by why you don't just use a "standard" gradle top level build file and compose the others as subprojects.
This solves all 3 of your goals
If you are concerned by build speed, you can target each server individually simply by running
./gradlew :server1:build
But if you are not able to do this for some reason you can use the apply from: syntax as described here
I'm new to Gradle and I want to ask if Gradle can implement this kind of project structure
Yes it can, and it is called multi-project builds. For information on it, take a look here in the Gradle user guide.
If you are completely new to Gradle, you may want to follow a guide such as this one for creating the basic structure.
I have a maven multi-module project (please see the attached image for the structure). I am in the process of migrating to Gradle.
We have multiple profiles inside AppBuild/pom.xml like shown below; and we run our maven build from AppBuild with -P option for the profiles.
Since I am new to Gradle, I am not able to decide what is the best way to go about it. Now, I am thinking to put some conditional include in settings.gradle based on some -P argument, but I am not too sure. Could someone help me how to go about this? What is the best way with some examples.
Thanks in advance.
~ Niranjan
I recently came across the same question, since I have a multiproject build where I want to include a special subproject only on some occasions.
This special subproject only depends on one other subproject and takes approx 1-2min to configure. So I don't want to have it included if I don't want to build it. That saves some build time.
So, what I did was to modify the settings.gradle
if(file('MySpecialProject').exists()){
include ':MySpecialProject'
}
When I do not want to build MySpecialProject I can simply rename/delete its folder. In my case, the folder is a symlink, since this 'subproject' resides in it's own git repo.
Even if #spy writes that if/then/else is not possible in settings, it did work for me.
Conditional include isn't straightforward in Gradle (it's not a first-class feature), and it's unclear why you would need it for so few subprojects. I recommend to start without and add all four subprojects to settings.gradle.
I apologize that this is surely basic maven/war plugin stuff, but I'm totally not a maven user. I just have to hack this one thing into a project that is maven based.
What I need to do is to copy an (essentially arbitrary) directory and files into the root of my war. I need them to appear as resources available via HTTP when the war deploys.
I cannot simply put them in the "right place" in the source tree. This is because the files in question are actually the source files of my project. I realize this is a bit odd, but this is a documentation project, and I need to show the source and the effect all in the same war.
So, in the general case, how would I configure the maven war plugin to copy a given directory, along with it's contents, to the root of my war? (BTW, I have tried to make sense of the documentation of this tool, but it seems to be predicated on so much understanding of maven that it feels like I'll never understand it without learning maven first, and I'm a bit too pressed for time to do that just now!)
Many TIA
Toby.
You could try:
use the copy-resources plugin. Use the plugin to copy your source files under target prior to when the war is packaged.
or, configure the maven-war-plugin to include additional resources.
Thanks Drew, that got me where I needed to go. Bottom line, I added the sample pom fragment from the link you gave for copy-resources to my pom.xml with the following changes:
<outputDirectory>target/${project.name}-${project.version}/sources ...
<directory>src/main/java ...
I copied this from the link you gave, then edited the element to point at src/main/java, which picked up my files, and the outputDirectory to the aggregate target/${project.name}-${project.version}/sources . I found that ${project.name} mapped to the project, and the version came from ${project.version}, which seemed to resolve the last little bits of issue.
Thanks again.
Toby
I am working on a project and using Maven to build it. The project is a quite big Java web application and it is supposed to work with both Mysql and Oracle databases.
The problem is that there are some specific annotations related to either of the two databases in the source code, plus some other differences, so that I am forced to manually comment/uncomment part of the code before building the application for one of the two databases.
Basically what I would like to achieve is to have my build script, maybe via a Maven profile, to automatically switch the source classes before building depending on the database I want my war to work against.
Putting it simply, the idea is to have MyClass.oracle and MyClass.mysql, and depending on my build profile I should move one of the two in the source dir, rename it MyClass and build. This should be done for some packages, classes, and also configuration files.
Is there any way I can achieve it via "pure" Maven? The only solution I came across till now is to use an antrun plugin and reference an Ant build.xml inside of it.
Thank you,
Mattia
A pure maven solution would be to develop your own maven plugin. Depending on your requirements this can be an overkill, however it is not hard at all, you can see how to achieve this here.
This is a limitation of Maven. One of Maven's purposes is to not have a build script. You should simply use the plugins as available, and setup your project the right way, and magically, everything will build!
There is one solution: Use Ant. Well, not to redo your whole project with Ant, but with the antrun plugin, you can run a few Ant tasks at various phases of your Maven build life cycle.
It's been a long, long time since I've used this, so I am not going to try to write a test pom.xml, but I don't remember it being very difficult to use.
Of course, the correct Maven solution is to divide your project up into "common core" code, and then a separate Oracle and MySql client that uses the "common core". By the way, I hope you're not patching source code. Instead, you're using a properties file to do this for you.