We use Gradle for for our builds. After our CI, we publish our Jar artifacts to our Nexus Maven Repo which other Internal teams can access and use.
We have a problem now wherein one of our Internal teams who does not have access to codebase requires the Jsp tag files and TLD files in a shared repo to compile their custom JSPs.
To achieve this, I have created a "raw" repository in our Nexus with a plan to publish/upload the required tag files using a Gradle task which the Other team can download to their workspace from the same repo using another Gradle task which downloads them.
I got stuck on how to publish/upload all the JSP tag files available in one particular folder to Nexus Raw repo from Gradle
Any help is highly appreciated.!
Related
I want to publish my maven artifacts to standard maven repositories. For that the first example I chose is bintray Jfrog. Unfortunately this didn’t go well.
I had to add two hacks.
Remove existing artifacts if pushing same version again
Delete some corrupted versions after maven publish
The entire code can be found at https://github.com/pPanda-beta/cassandra-java-driver-reactive-mapper/blob/4b1395db443facb188ed4aee120c6db7864908b7/cassandra-java-driver-reactive-mapper-reactor-core/build.gradle#L93-L122
The uploaded artifacts are at https://bintray.com/ppanda-beta/maven/cassandra-java-driver-reactive-mapper-reactor-core
Why maven-publish?
The main objective here is to keep maven artifactories as a standard specification not specific to any provider. I want to represent an repo as { url, username, password } . The way of publishing should not change based on the repo provider.
PLEASE DO NOT SUGGEST ANY OTHER PLUGIN THAN 'maven-publish', I DONT WANT TO USE com.jfrog.bintray or com.jfrog.artifactory PLUGINS WHICH ARE VERY SPECIFIC TO BINTRAY JFROG.
What is wrong with current solution?
It is hacky. It is no better than jfrog gradle plugins. The solution is already using custom hacks which are not valid for other maven repos.
Why not switch to Jfrog altogether ?
The future of those artifacts is to reside in a more popular and standard maven repo like : maven central, github maven repo, ...etc. So anyway I'm gonna leave jFrog in near future. Till that time comes, I want to standardise the gradle script to work with any maven repo. This is very similar to docker container registry. Whether it is global docker hub or redhat cr or google cr, we use the same docker clients.
I'm working on a multi-module build which is needed to create an artifact from all WSDLs available on an internal repository. But they are a lot and I don't want to make a list of it, because it might be possible that later another WSDL project is created and needs to be included in the list, if that doesn't happen then the final artifact will be incomplete.
So I need to know if there's any way I can tell gradle to fetch artifacts present on a certain path like domain.com/path/to/repo/wsdls/ and fetch all available artifacts from this path.
I was thinking of creating a configuration which then has this specific repository to download from but it seems configuration does not include a repository and will use defined in build.gradle.
Any way to define a download-everything-pattern in dependencies block?
EDIT: Note: WSDL project means soap services in a zip archive
We maintain an artifactory within our intranet which is used by the development team.
When ever any new dependency is added to any project , we upload the new jars into artifactory.
This is currently a tedious process and we are trying to find if there is any simple way out.
The current process is - if a project defines a new dependency , we need to connect to internet and build the project using gradle so that we get to know what are the new dependencies ( we in fact track the logs what are the dependant and transitive dependant jars which are getting downloaded fresh )
Then we create a zip of these new jars alone and upload to artifactory. This is time consuming and error prone as well
Is there any better way to achieve this ? When i build using gradle connecting to internet , is it possible to publish the new dependencies as well to maven local repo or to some new folder so that we can zip that folder alone and upload to artifactory ?
Kindly revert if anybody has a simple solution for the above problem.
This is a maven answer but the same will apply to gradle.
You should be able to define a virtual repository in your artifactory, which is a combination of the local (artifactory hosted) and the maven central repo (internet hosted).
Your maven/gardle users will configure the virtual repository (not the internet) in their settings.xml, then when a dependency is loaded maven will look in repostories in the following order:
1) local user repo at ~/.m2/repo
2) artifactory local repository
3) maven central
Each time a new artifact is loaded from 3 (no one has ever asked for it before) it will be added to 2 and 1, so the next user who calls for that dependency will only ever go as far as 2.
See https://www.jfrog.com/confluence/display/RTF/Virtual+Repositories
We are currently migrating from Nexus to Artifactory and one thing we are missing is an API call to resolve maven dependencies in artifactory. Nexus has this endpoint /service/local/dependency?r=snapshots,releases&c=&e=pom&s=compile&f=list&g=<my.group>&a=<my-artifact>&v=<my-version> which gives a compiled list of all, including transitive, depdendencies.
We need this because we (mis)use maven as a generic deployment/versioning system to create artifacts (zip files of shell scripts actually) and to manage depenedencies. These dependencies are also necessary for production deployments.
Since we migrate from Nexus we don't have builds accessible and I am not yet sure if we want to use them. Is there a way to get a rest endpoint like the nexus one in Artifactory? Maybe a user plugin? Any hints on how this could be done?
I'm confused about how Archiva fully works. I understand that if we had a core set of dependencies, we could use Archiva as our local maven repo.
The thing I don't understand, is how Archiva manages build artifacts from your own projects.
Say I have a multi-module maven project - we can even use the one from the Sonaytpe for example. http://www.sonatype.com/books/mvnex-book/reference/multimodule-sect-building-multimodule.html
What if I wanted to have one team working on the Simple Model app, while I wanted another to work on the Simple webapp. But I didn't want either to have the projects they AREN'T assigned to, in their local workspace. Webapp needs Model to build, but I don't want the Wepapp team having direct access to Model.
Is there any way Maven can detect that the build artifact for Model wasn't in a Webapp dev's workspace, and pull it from our local Archiva repo, so they can still build the Webapp despite not having the model (maven module project) code in their workspace?
The Model project will be like any other third-party dependency and be downloaded by Archiva automatically, provided
the Webapp project specifies Model project as a dependency
the Model project is deployed to Archiva periodically (by a Continuous Integration system or other means).