run gradle test suit through jenkins: where do dependencies download - jenkins

When a gradle test script is run through jenkins, should dependencies be downloaded to a folder?
When i run on my laptop i use MavenLocal in the build.gradle and every dependency is present in the .m2 folder.

Usually your dependencies will be downloaded from public repositories that you configured in the gradle script, e.g. mavenCentral() or jcenter().
If you have your own libraries, which cannot be downloaded from any public repository, you have to push them to your personal repository first, e.g. Nexus. After creating a user on Nexus, you set up the credentials in jenkins and pass them as environment variables to gradle.

Related

Isolate maven jar dependencies that are unavailable from maven central

I am attempting to refactor a maven build process, and I am trying to populate a local maven repository to help with this refactor.
My build depends on obsolete versions of jar files that exist only in a maven repo on my network (not in maven central). Example: org.foo:example:1.7:jar
I have been attempting to run my maven build in a docker image image with the hope that I could identify all of the obsolete components being pulled from my maven repository.
My goal is to explicitly pull down dependencies from my maven repo and then build the application using only maven central as an external repository.
I have a docker file to run the build
FROM maven:3-jdk-8 as build
WORKDIR /build
# This pom.xml file only references maven central.
COPY pom.xml .
# Explicitly download artifacts into /root/.m2/...
RUN mvn dependency:get -Dartifact=org.foo:example:1.7.jar \
-DrepoUrl=https://my.maven.repo
# Run the build making use of the dependencies loaded into the local repo
RUN mvn install
Unfortunately, I see an error: could not resolve dependencies for project ... The following artifacts could not be resolved: org.foo:example:jar:1.7.
I presume there might be some metadata in my local org.foo:example:1.7:pom that has an awareness of its origin repository. I had hoped I could satisfy this dependency by pulling it into my local repository.
I also attempted to add the following flag
RUN mvn install --no-snapshot-updates
After further investigation, I discovered that the downloads in my .m2/repository contained files named _remote.repositories.
Solution: set -Dmaven.legacyLocalRepo=true when running dependency:get
With this flag, the _remote.repositories files are not created.
RUN mvn dependency:get -Dmaven.legacyLocalRepo=true \
-Dartifact=org.foo:example:1.7.jar \
-DrepoUrl=https://my.maven.repo
This question helped to provide a solution: _remote.repositories prevents maven from resolving remote parent

Download/Copy zip file from Nexus repository via jenkins pipeline

I am new to this. I have a .NET project, GIT is being used as a SCM. We are keeping Third party binaries(in a zip file) inside Nexus.
Now, while building the project, via Jenkins, I need to copy and unzip binaries from Nexus to build machine via Jenkins Pipeline Script.
You can use the Maven dependency plugin.
A very basic example would be:
sh "mvn dependency:get -DrepoUrl=YOUR_URL Dartifact=com.foo.something:component:LATEST:jar -Ddest=component.jar"
Of course this requires java and maven to be properly installed on your node.

.m2 is not getting updated with latest xmlbeans jar files

I do have a jenkins job that builds XML beans jar files from the internal gitlab project and puts it on the artifactory. While having a build, this XML beans jar files are downloaded to the .m2 maven local repository. However, if this jar file exists in the .m2 repository then maven does not bother to download it from the artifactory. With being said, if there is a gitlab change, it does build it and put it on the artifactory. As there is already a jar file exist in .m2 repository, an old jar file is not being replaced with the new one. We ended up a wrong dependency to the customer with a release.
The question is , What am I doing wrong here?
mvn clean install -U
-U means maven will force update snapshot dependencies. Release dependencies can't not be updated this way.

POM not released using Jenkins and Artifactory Release

We're trying to use the Artifactory release process in Jenkins to publish a jar file created by a Gradle build into a Maven repo in our Artifactory server.
It nearly all works, the only issue is that the pom file isn't being copied into the Artifactory repo.
The Gradle build includes the Gradle Maven plugin and running gradlew install locally results in both the jar and the pom inserted into the local Maven repo.
I've added a task in the Gradle build that generates the pom file in the same directory as the jar file and changed the Jenkins build to run that task too.
When the build has completed I can see both the jar and the pom file in the workspace.
Any ideas on what I need to do to get the pom file published along with the jar?
We're using:
Jenkins 2.10
Artifactory plugin 2.4.4
Gradle 2.14
The Gradle build file does not inlcude the Gradle Artifactory plugin.
Cheers, Andy
The Jenkins project is configured to use the Gradle-Artifactory integration (rather than the Generic-Artifactory integration).
As suggested by Dakota Brown I'm answering my own question, the solution to my problem was to un-tick the maven3 integration option. With that option unslected, everything works as expected.

When deploying to Archiva from Jenkins is it necessary to change a settings.xml file where maven is concerned?

I am trying to deploy from Jenkins to Archiva. I'm not very sure how it all works. I have a maven project and I have read that I need to change a settings.xml file. I cannot find such a file in my Archiva 2.0 directories.
While in Jenkins I am using the ArtifactDeployer plugin. When I try to enter the directory from which to get the artifacts there is an error saying it does not exist.
How can I resolve this problem?
Within Jenkins, you need to register the build tools that Jenkins will use.
In regard to the buld tool Maven, I suggest:
Download, unzip, and install Apache Maven to the server on which Jenkins runs.
Configure your Maven's conf/settings.xml to point to your Archiva installation.
Configure the M2_HOME and PATH variables so that the mvn command can be executed.
Configure Jenkins to use the Apache Maven installation that you just configured.
The point is, that's a sure fire way to locate and edit a settings.xml file.
If you have Jenkins download Maven for you (I generally don't do this), then you'll have to look for a path to where Jenkins installed Maven.

Resources