I will need to load 200+ external jars( form my local harddisc) into Springboot REST project. Tried many approaches but none of them are working, Much appreciated if someone has solution.
Note: Please do not suggest mvn install or system scope as i need to construct artifacts for 200+ jar's which i dont like to do manually
Tried google add jar's plugin too its just copying the ${basedir}/lib/*.jars into my Maven target folder but not found in runtime.
If your company works with Maven, it should run a Maven repository server like Nexus or Artifactory. When someone builds artifacts, they should be deployed to the Nexus/Artifactory and can then easily be read from there.
If this is not the case and you do not have a Nexus/Artifactory, you need to either install the JARs in your local repository (mvn install:install-file) or you need structure them in the standard repository layout (like log4j/log4j/1.2.17/log4j-1.2.17.jar) and import this directory as repository.
In any case, this will be a lot of manual work (as you already said).
Related
Stupide idea but ... is it possible to create a maven repository from a static website?
if I mannualy put pom and jar file on a website with a path similar to the one on any maven repository, then I reference the website as a maven repository from which I try to import dependency, will it work ?
I need it in order to store my snapshot version without publishing them. I don't care of security but I have 0 budget
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 see several options:
directly in pom.xml
in company super-pom
in settings.xml (global or user)
in a profile or directly (in settings.xml or pom.xml)
We want our Jenkins to push artifacts to internal repository, and developers to pull missing artifacts from there.
If I put the repository URL in pom.xml, and later the internal repository is moved to a different address, the released versions will all have a broken link.
Super-pom saves some repetition, but in a clean setup you need to somehow know where the repository is to find the parent POM — to tell you where the repository is.
Having the URL in settings allows one to change it without modifying the artifacts, but there are two problems:
build will fail due to unresolved dependencies, if maven settings have no reference to the internal repo
developers have to update their settings.xml files manually
I'm also unsure about the merits of putting repository configuration in profiles. I know it let's you easily switch the repositories on and off, but shouldn't the -o option and snapshot resolution settings be enough for most uses?
What about using a different repository (e.g. with instrumented classes) for integration tests?
Configure a single repository in the users ${HOME}/.m2/settings.xml and configure other needed repositories in your appropriate repository manager either Nexus, Artifactory or Archiva. In Jenkins there is the Config File Provider plugin which exactly handles such situations in a very convinient way.
If you want to have repeatable builds and good control over your organization internally, use a repository manager and use a mirrorOf entry in everyone’s settings.xml to point at that url.
If you are exposing your source and want to make it easy for others to
build, then consider adding a repository entry to your POM, but don’t
pick a URL lightly, think long-term, and use a URL that will always be
under your control.
http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
I'm trying to figure out if its possible to reuse Artifactory's maven repo on the local machine where the Artifactory server is running. The following details what I am trying to do.
I have a server where Artifactory runs and I'm planning on setting up Jenkins on the same server. If possible, I would like to have only one maven repository on the server. Since Artifactory already runs there, I would expect it is maintaining some kind of a maven repository (I looked around for it but couldn't find it).
Currently, when Jenkins uses Maven to build a maven project, it downloads the dependent jars into a local maven repo (a .m2 folder) on the server. Instead of this, would it be possible to point the settings.xml that maven is using to some local folder under Artifactory where artifactory stores all the jars? Basically, I would like maven to think that all the jars are already available in a local repo (which artifactory is maintaining) and so it wouldnt have to download all the jars from artifactory.
If maven and artifactory can share the same repo folder, this would be possible. But if Artifactory uses its own strucuture to maintain the maven repository (something other than the structure maven follows with its .m2 folder) this would not be possible.
I should state that I have very minimal knowledge of Artifactory, other than the fact that it is a maven repository manager.
Answering my own question here, as more research suggests that this is not possible. I found another question here on SO that states:
Artifactory uses Java Content Repository (JCR) standard to store artifacts. It is an abstraction above various storage implementations, which include filesystem, relational databases, etc. In any case, JCR manages the store by checksums (to reduce size and bandwith), so the repository is not directly browesable in the filesystem. The default implementation is storing the binaries on the filesystem (inside $ARTIFACTORY_HOME/data/filestore and the metadata in Derby DB.
How Artifactory manages repos
A blog post by the Nexus guys also suggests that this is not possible.
Contrasting Nexus and Artifactory -> Contrast #2