how to build playorm JARs - gradle

I am new to playorm and gradle. My goal is to get playorm compiled (especially play 2.1 plugin) and deployed to local nexus repository manager.
What gradle tasks should I invoke to do this?
I tried to run gradlew clean assemble - creates workspace*.jar in output/libs so I assume build part was done. How to get these artefacts renamed and uploaded to my nexus?
https://github.com/deanhiller/playorm

You'll want to read this chapter of the user guide. It looks like the only repository configured for playorm is Maven Central, but the user guide tells you how to configure your own repository and interact with it. After following the guide, if you have a more specific question ask again here.

I created local.gradle and included it in build.gradle to create uploadArchives task using standard gradle upload procedure.
build.gradle was modified in upstream version to include local.gradle if exists.

Related

Gradle distribution remote repo

Does anyone know how to create a remote repo that pulls packages from https://services.gradle.org/distributions/ ?
This post seems to indicate it's possible, but I haven't had any luck.
This post refers to a video with some instructions, but those don't appear to apply to the version we're on (v7.15).
I suspect I probably need a custom layout, but the file names don't seem to play nicely with the parts Artifactory is expecting.
Here is one of my attempts:
and set this in the gradle-wrapper.properties:
distributionUrl=https://<server_name>:443/artifactory/gradle-dist/distributions/gradle-6.8-bin.zip
But it does not work. I'm not able to browse the repo in the Artifactory website nor can I execute the build.
To use Artifactory as a source for Gradle distributions, do the following:
Create a remote generic repository in Artifactory with the URL pointing to https://services.gradle.org/distributions.
Create the Gradle wrapper. As instructed in the Gradle wrapper documentation, you must provide the full URL to the Gradle distibution zip:
gradle wrapper --gradle-distribution-url=<artifactory-url>/gradle-dist/gradle-5.6.4-bin.zip
If authentication is needed, you can add username and password as system properties when running the Gradle commands:
./gradlew --version -Dgradle.wrapperUser=<artifactory-username> -Dgradle.wrapperPassword=<artifactory-password>
Read more:
Artifactory remote repositories
The Gradle wrapper

How do I setup & use the artifactory features provided by GitLab

I have looked up various Q&A's on how to use the artifactory features offered by GitLab, and they all talk about either JFrog (a.k.a Artifactory) or Nexus or something else. GitLab says that we could use it as Artifact management, and I was able to generate artifacts. But I am stuck now since I am completely lost on how to use this.
Here is the script I use to generate artifact using Gradle:
artifacts:
paths:
- build/libs/*.jar
Can anyone guide me on how I could refer to an artifact in my repo during CI/CD. Thanks in advance.
You can read up on them in the dependencies section of the Gitlab docs. Some quotes to guide you:
Note that artifacts from all previous stages are passed by default.
So every artifact you build in a prior job of the same pipeline is passed by default.
(...) the artifacts from job:x will be downloaded and extracted in
the context of the build.
In the context of the build means relative to the working path of the job.
To test this, add a job after the one you create the artifact in and add a ls -la command in the next job to see what has been extracted and is ready for use.

Is it possible to override existing resource on Nexus when publishing its newer version using Gradle?

I had a very simple Gradle script to publish a library to Nexus using Gradle Maven Publish plugin. I got the following error when I reran the task :
Could not write to resource 'some_resource.pom'
I can delete it manually from the Nexus UI but I am wondering if there is a more programmatic way to do it. Btw, I do have write access to Nexus.

What is the difference between gradle install and gradle publishToMavenLocal?

In gradle, the install task is introduced by the maven plugin.
The publishToMavenLocal task is introduced by the maven-publish plugin.
The documentation of both tasks says they install/publish the module/artifacts to the local maven cache (.m2 directory).
If I need to publish a local project to my local maven cache, so that another local project can depend on it, which of the two tasks should I use?
As far as I know, these two accomplish the same thing.
That said, I recommend using the maven-publish plugin because:
It's newer and has a nicer publishing DSL, see the Maven Publish Plugin page for more details
It doesn't explicitly depend on the java plugin, which is useful if you ever build non-Java projects
You can always write: task install(dependsOn: 'publishToMavenLocal') if you like the task name install.

Using artifactory in gradle

I want to use an artifactory in gradle. To be more specific, i want to use 4 customized jars that are not in the maven repository. So i'd like them to be at the artifactory server and will be downloaded when needed.
Do i need to install something other than "Gradle eclipse integration" ?
Can someone give me an example on how to do that in the gradle.build?
First, you need to deploy those jars to Artifactory.
Probably, using the UI will be the easiest way to go.
Next, you need to declare Artifactory as your repository. You can do it by using the standard repositories clause (as #lance-java suggested), or by using Artifactory Gradle plugin. Probably the easiest will be generating the build script snippet from Artifactory itself.
Last will be adding the dependencies to your script. You can navigate to the jars you uploaded in the tree browser, and copy the snippets of dependency declarations from there.
Both steps are documented in the User Guide as well.
I am with JFrog, the company behind Bintray and [artifactory], see my profile for details and links.
repositories {
maven {
url "http://repo.mycompany.com/maven2"
}
}
dependencies {
compile "com.foo.mycompany:dep1:1.0"
compile "com.foo.mycompany:dep2:1.0"
compile "com.foo.mycompany:dep3:1.0"
compile "com.foo.mycompany:dep4:1.0"
}

Resources