I have two separate gradle projects in the following structure. I want to write a task to move the build jar from projectA to projectB's lib folder.
projectA -> c:/User/someUser/dev/projectA
projectB -> c:/User/someUser/dev/projectB
In projectA's build script, I have the following to move the generated jar from projectA's build/lib folder to projectB's lib folder.
task deployJar(type: Copy) {
from('build/libs/')
into('C:/Users/someUser/dev/projectB/libs')
include('*.jar')
}
I'm using absolute path but it is not working. I was hoping if someone can point out what I am doing wrong.
Thanks
Have you considered setting up the projects as a multi-project? You could hook them together with includeFlat. What you would usually do is have projectA deploy to an artifact repository and resolve the jar in projectB through dependencies {} or set projectA/projectB up as a multi-project and have projectB depend on the output of projectA (also through dependencies {}). If you go the second route, you get nice things like projectA automatically rebuilding when necessary when you build projectB.
I don't see anything exactly wrong with what you have already. Does it fail with an error?
Keep in mind that setting up your build with absolute paths will make it non-portable/fragile.
Related
I am new to gradle. I am trying to write a gradle script that copies some scripts inside a dependency of a java project. How can I achieve that? I tried to read documentation to figure out how can specific files be pulled from a dependency but couldn't find anything.
So my projectA -> Depends on projectB:moduleB -> Depends on projectC:moduleC:{Has files that I need to copy in projectA tar}
I have 3 gradle projects, projectA, projectB, projectC. All of which build a jar file named projectX-0.0.0.jar. On my jenkins server, all of these projects deploy these jars to my companies artifactory.
In projectA, I have multiple compile dependencies used throughout my entire project. Then in project B, I include project A by stating: compile group: 'com.company.projectName', name: 'projectA, version '0.0.0' So I can use these dependencies (i.e. slf4j) I do the same for projectC to include projectB dependencies, which in result includes projectA's dependencies.
This works great for our jenkins servers on deployment, after I have pushed the code to the server, however when trying to test locally I can not get the dependencies to update for testing my code.
I have tried:
Updating the gradle cache that downloads project A from artifactory with locally built project A jar. Located in C:/users/username/.gradle/caches/path-to-jar.
Removed the compile group: 'com.company.projectName', name: 'projectA, version '0.0.0' and replaced it with compile files('libs/projectA-0.0.0.jar'), placing projectA's jar within a lib folder in projectB
Using gradle offline mode in IntelliJ and repeating #1
Going offline completely on my pc and repeating #1
With all 4 attempts above I still have not been able to resolve dependencies declared in project A for project B.
My goal is to be able to update a compile,testCompile,runtime,etc. dependency in my projectA.gradle file, and then run my projects down my pipeline to ensure this update effects the dependencies in my project as I intended.
You need to update the .jar and .pom file within your gradle cache. The .jar file contains the source code while the pom contains the dependencies you brought in the previous project. Using a gradlew clean build install you can create the jar and the pom.
So to solve your problem, do a gradle build clean install on project-a. Grab the jar and pom from the build file generated and replace the project-a.jar and project-a.pom within the cache. Then do the same for project-b and you will see the changes in project-c after a gradle refresh.
I have a root parent maven module which has lot of sub-modules that build jar files as artifacts.
I cannot change all sub-module pom.xml files.
From the root parent pom.xml is there a way I can get a list of all jars (artifacts) built by sub-modules?
Preferably after the package phase is complete?
PS: As a part of root module build I want to generate a report using a tool which requires this list of jar files.
There's a target/maven-status/maven-compiler-plugin/compile/default-compile/createdFiles.lst in a Maven project.
You can use the GMavenPlus Plugin and Walking the File Tree to gather these files and put their content where you want.
Another option is to develop an own Maven plugin that does the same.
Forgive me if this is remedial, but I am still new to Maven and it's functionality.
In my project, when it "builds" and gets to the compile phase, it will create a target directory with just compiled libraries and update (or create if not there) the local .m2 directory.
When I get to the "test" phase, I want it to build against the target directory's library files, and not the local .m2 directory.
Any hints, recommendations, or suggests would be greatly appreciated. Thanks!
Maven has this concept of “the reactor”, which is just a fancy term for the list of projects being built. At the start of a Maven build, and at the end, Maven prints out this list of projects (using /project/name if defined or groupId:artifactId otherwise).
For each project in the reactor, Maven maintains a list of artifacts that have been attached. By default, each module's pom.xml is attached, and as each plugin runs, they have the option of attaching additional artifacts. Most plugins do not attach artifacts, here are some plugins that do:
jar:jar creates a .jar and attaches it
war:war creates a .war and attaches it
source:jar creates a .jar of the source Java code and attaches it with a classifier of source
java doc:jar creates a .jar of the JavaDocs ad attaches it with a classifier of javadoc
There is also a default primary artifact (this is the one that gets replaced by jar:jar) which is actually a directory and not a file, as such it will not get installed or deployed to the local repository cache or a remote repository.
So when in the reactor, and a plugin that attaches the primary artifact has not run yet, and another plugin asks for the primary artifact, it will be given the directory ${project.build.outputDirectory}. If after the primary artifact as been attached, then that primary artifact will be provided.
The test phase happens before the package phase, so will use the directory and not the .jar. The integation-test phase happens after, so will always use the .jar.
Things get more complex in a multi-module project (which is where my long intro should help you out)
Maven has to build the test classpath. If one of the dependencies is within the reactor, Maven will use the artifact attached to the reactor. Otherwise it will use the local cache (populating from the remote repositories if necessary).
When you run
mvn test
In a multimdule project from the root, there is no replacement of the default (directory-based) artifact, so intra-module classpath will be to the target/classes directories.
When you run
mvn package
In the same project, however, because each module completes its life cycle sequentially, all the dependent modules will have swapped in their .jar files as their attached artifact.
All of this should show you that Maven is doing the sensible thing. Hope this has helped.
The test phase is going to execute tests on your project. The project won't reference itself via the dependency mechanism. Only dependencies will be referenced via your local repository, i.e. .m2/repository
Also, it's not the compile phase that installs the artifact to the local repository, it's the install phase. And, then, there's a later phase, called deploy, that will deploy the artifact to a remote repository, provided you have a remote repository configured as the deploy target. Note, install and deploy are nearly identical phases except install is a local only thing; thus, it's the common build phase to hit when doing dev environment work. Normally the build server will do the deploy stuff.
I have a maven project which is configured (via the use of pom.xml and assembly.xml) to package a zip file containing both the compiled webapp (war file) and all files under src/main/folder alongside it whenever we run mvn clean package assembly:single.
This project imports/uses another maven project (which becomes a jar file) and that project in turn also imports/uses a third maven project (again a jar file).
The third project also contains some files inside src/main/folder as well which I'd like to be placed alongside the other files in the zip file whenever I build the main project (the one on top of the chain that becomes a war file).
Is it possible somehow to tell maven to include all files in a specific folder inside all it's dependencies (Or in one specific dependency) alongside in the zip file?
Start here: Maven: The Complete Reference - 8.5. Controlling the Contents of an Assembly
Note that if you deploy a Maven project with assembly:assembly (which you really should configure as a <build> plugin, not use on the command line), the assemblies get "attached" to the project and installed in the repository. You can then reach them using the Maven dependency notation, i.e. mygroup:myartifact:extrafiles:zip
I've found the Assembly descriptor <dependencySets> cumbersome to configure. They really are for the simple case (including the JAR files your application needs at runtime).
Here is the general approach I would take for your desired outcome:
Use Maven Dependency Plugin dependency:copy to download the specific files from the other projects, placing them under a sub-directory of target/
Configure your assembly descriptor to add those downloaded/extracted files to your final assembly artifact.
Alternatively, hack something together using Maven Ant Run Plugin.
You will need to produce an additional assembly from the third project to package up the extra files. Append the assembly id so it produces a package named something like third-1.0.0-extrafiles.zip
Then add this as a dependency of your first project using <type>extrafiles</type> in the dependency descriptor. In the assembly for the first project you'll have to tell it to "unpack" the dependencies of this type (so you don't get a zip in a zip)