I am building a Java project, call it A. A has sources in A/src/main/java. There are other projects B, C, D (more, actually), and they have B/src/main/java, C/src/main/java , D/src/main/java. When I took over this project A, I noticed that the old JBuilder build script for A referenced the sources of B, C and D in parallel directories. I don't like that, because source files in those other directories could change. I want to modify the build, using Gradle, so that versioned sources of the other projects are pulled from a local Maven repo, and, from A's perspective, during compilation I reference the source .zip files of the other projects. Can I do that with Gradle?
Related
I have two (Java) projects, a library and an executable which uses the library. The two projects reside in subfolders of the same folder but I don't want to add anything (like settings.gradle) in the root folder (they come from different git repositories, thus, I cannot have the files in the common parent source controlled). Here is my layout:
lib - has some runtime dependencies (from the maven repo)
app - depends on lib and has some (different) runtime dependencies
The goal is to produce a folder (Gradle's build\libs is good enough), containing a jar file and a lib subfolder with all runtime dependencies. What is the best approach with Gradle? Here is the result I am looking for:
app\
build\
libs\
app.jar
lib\ - all dependencies are here
With ant for instance, I bring everything together when building the executable (referencing the lib's source code via ../lib/). That's somewhat ugly, but get's the job done. Ideally, I would think that it's more flexible to have the lib build as a dependency, when building the executable, just adding another jar to the app's lib subfolder.
Thanks in advance
You can put your root build.gradle file and the settings.gradle file in a folder named master next to your lib and app folder:
lib - has some runtime dependencies (from the maven repo)
app - depends on lib and has some (different) runtime dependencies
master - root build.gradle file + settings.gradle file
gradle looks for a master folder when searching for a settings.gradle file
I have a maven project that contains some Kotlin source files and some web resources (HTML/CSS). During the compile phase, the Kotlin source is compiled to JavaScript and ends up in the build output location, along with some other folders that I am not familiar with.
I would like a build step that occurs after the compile is finished that will copy my resources and compiled output and dependencies (kotlin.js) into a folder with the correct hierarchy that I deploy or debug.
I know how to copy the resources into the build output folder, but the build output folder appears to have some other files in it that are auto-generated by maven which I do not want to deploy.
Ideally, I would also like the clean phase to delete this destination directory.
I have a very large scale java project whose structuring is like this:
java->ROOT/A, java->ROOT/B, java->ROOT/C java->ROOT/...
Where A, B ,C are individual java projects. I tried to use sonar ant task in the build.xml of A, B ... but it was giving "org.sonar.squid.api.AnalysisException" error as the packages in A, B are something like package ROOT.A.xyz.
So I was bound to add the sonar ant task target in build.xml file of ROOT.
Now I am specifying the sonar.sources and sonar.binaries to java directory and including the exact project to be build using sonar.inclusions property i.e. A/B/C.
But the problem is though its analysing only files of A/B/C but its searcing from dependencies i.e. jar dependencies etc in entire project (ROOT) and is taking a lot of time. May I know what is the solution I can have were only dependencies of the respective project will be resolved.
I have 2 Projects i.e Project A.war and Project B.jar .
Project B is added as a dependency in project A.
Currenctly Project B has some scripts in particular folder structure. I include these scripts in Project B.jar using maven includes.
I want to copy these files in Project A.war in another folder structure.
Is this correct way to do or can it be done in better way.
My final aim is to copy the scripts from Project B to Project A.war in differenct folder stucture.
Newbie question : I have 2 C# projects in TeamCity, call them A and B. A contains a reference to B.dll. B builds fine. However, A fails to build because it cannot find B : Could not locate the assembly "B"
It seems really simple : how do I tell my project A on the buildserver where to find the binaries from B\bin\Release?
You do this by creating 'Artifacts' and artifact dependencies.
If project A is dependent on project B, then you create an Artifact on project B using an artifact path like so:
bin/Release/B.dll
Then on project A you setup a artifact dependency on B with path like:
B.dll
And set the destination path to be where ever project A is expecting to find B.dll e.g.
./Libs
You can do other cool stuff like automatically archiving all your artifacts into a zip by using the syntax:
bin/Release/*.dll => B.zip
and access them via:
B.zip!B.dll
All these paths are relative to build directories so makes it easy and you dont need to worry about the TeamCity guid folders or use absolute paths.
The problem you're encountering is that Teamcity runs each build in it's own temporary directory and since this is a randomly generated name you can't set a reference directly from one to the other.
Typically you would write a build script that builds both A and B in the right order and just have Teamcity run that build script. (Since you're using C#, MSBuild is ideal for this).
The alternative would be to have B.dll copied to a known location (e.g. c:\currentbuild) at the end of its build and have A always reference it from here. You can set up build dependencies in Teamcity so that if B is rebuilt, A is also rebuilt.