We have a lot of dependencies in a network folder (let's call it \dep-set.io.org) organized like this:
\\\\dep-set.io.org\[project]\[version]\[build]\artifact.jar
We are planning to move to a RepositoryManager (Artifactory or Nexus) but in the meantime I need to be able to pull those dependencies using Maven or Gradle but I couldn't find a way to do it.
Looks like Maven provides me a way to customize the Build lifecycle but I couldn't find where is doing the actual request for the artifact and how to override that mechanism.
Gradle isn't helping that much, the repositories supported are Maven, Ivy or Local but not through a network though have to assume that I didn't research much on Gradle filesystem support.
I would like to define my dependencies in a certain way that allows me to mark these special dependencies as downloadable from network folder with certain layout
Thanks
Related
I want to publish a common build script which i will include across various projects in my application.
This will contain only the common set of dependencies, i.e dependencies with particular versions that will be common across all the artifacts in my enterprise application..
My applications will refer to this file from the url.
How can i achieve this?
EDIT1: my exploration in this direction is based on this answer on SO:
How to share a common build.gradle via a repository?
There are a few different options for this.
One is to publish a project with the dependencies you want to share defined as API dependencies. Projects that depend on this will inherit the dependencies.
Or you could write and publish a Gradle plugin that will configure your projects with the common dependencies. Projects can apply the plugin, and will automatically be configured in a certain way. (You don't need to publish a plugin to do this - first try creating a project-local buildSrc convention plugin.)
I would actually recommend neither of these approaches.
It's easy to get into a tangled web of dependency hell when transitive dependencies are inherited. It's likely that at some point some dependency will clash, and excluding dependencies can be a big headache, and will easily cancel out any benefit in trying to reduce a little duplication.
Additionally, it's nice when a project is explicit about its dependencies. Being able to look at a build.gradle.kts and understand exactly what dependencies are set is very convenient.
Instead, what I would recommend is controlling the versions of common dependencies in a central location. This can be achieved with the Java Platform plugin. This plugin can be applied to a single build.gradle.kts file, and it lists all versions of all possible dependencies. (It can also import existing Maven BOMs, like the Spring Boot BOM).
Now, all subprojects can add a platform dependency on the 'Java Platform' project.
dependencies {
// import the platform from a Maven repo
implementation(platform("my.company:my-shared-platform:1.2.3"))
// or import a platform from a local project
implementation(platform(":my-project:version-platform"))
// no need to define a version, if it's defined in the platform
implementation("com.fasterxml.jackson.core:jackson-databind")
}
This is the best of both worlds. Projects can be explicit about their dependencies, retain autonomy, while the versions can be aligned across independent projects.
We have a large custom artifact repository which is used by our old internal ant builds.
It stores jars in much the same way that a maven repository does. i.e.
http://repo/root/<group>/<artifact>/<version>/<artifact>-<version>.jar
But, this repository does_not_ contain pom files. Just jars and src jars.
We are now migrating a whole lot of projects to using maven/gradle, these use an Artifactory installation that we have. But the projects still have a lot of dependencies on artifacts stored in the old repository.
I was wondering if anyone knew a way of accessing this old style repo (which does not have poms) using maven/gradle?
We could synthesize and insert a whole lot of simple poms, which just have group/artifact/version etc, and no dependencies. But was wondering if there might be a simpler way.
After all, the group/artifact/version is in the path itself. The poms never contain dependencies, so in this situation the poms wouldn't (as far as I can see) provide any additional info.
Any advice/help would be greatly appreciated.
When you transform the projects to Maven, you need to touch the dependency definitions. You need to to replace old, file-based accesses by Maven coordinates.
Therefore, I would suggest the following (we did something very similar, only with a Windows network drive instead of a http based repository):
Write a script that uploads all your artifacts from the old repository to your artifactory. If you use maven deploy:deploy-file, Maven will create stub poms for you.
Write scripts for the developers that translate the references on the old repository by the respective Maven coordinates for the pom.
As a side note: In our company, the old "repository" and the Maven repository were actively used (and written to) at the same time, so we developed a two-way synchronisation job between our Nexus and the old "repository".
Gradle doesn't need pom files, if they aren't available it should just reference the jars directly. So this should "just work"
repositories {
maven {
url "http://repo/root"
}
}
If, for some reason, there's slight differences you could use the Ivy repository. See custom ivy repositories and IvyArtifactRepository Eg:
repositories {
ivy {
url "http://repo/root"
layout "pattern", {
artifact "[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier])(.[ext])"
}
}
}
I've inherited a few maven projects which have added a /dependencies directory to capture Java jar libraries that aren't part of the project war and must be installed by a DevOps into a Tomcat installation.
The libraries in this directory seem to fall into four categories:
"provided" scope libraries,
downstream dependencies of those provided libraries, and
discoverable implementations of api jars
"mystery" libraries, i.e., not available in an external repository, and maybe unsure where they ever came from.
Is there a strategy to get Maven to help manage these dependencies and perhaps fetch them for external install?
There are probably several strategies to choose from.
Number one: leave it as it is. If it works and the build is reproducible (on different environments) that seems one valid solution.
The "mystery" part of the build might not be more of an issue for new people working with it.
I think it is valid to create an own maven module to be delivered to the infrastructure team. This module can contain the jars in the /dependencies folder.
What you would need to do is create a pom.xml and add all dependencies currently in that directory (of course not the transitive ones). The magic ones would need to go in a repository proxy (nexus, artifactory, ...). If you don't have a maven repository yet: you want one! (its easy to setup and it does help a lot!)
I would then use the assembly plugin or some ant task to build the zip do be delivered. So the infrastructure team is able to just unzip / copy the files where they need to be. This step can then even be scripted (so the upload / unzip is done through SSH or something like that).
This is probably only one way to do it. I would assume to resolve the jar's in the /dependencies directory may be a bit of a pain.
The advantage is obviously that you document and simplify the management of those libraries. I would also assume if you update some of them it is easier across branches to merge since there are no binary files around. So it may be worth the effort.
I searched a lot in apache documentation and ibiblio.org and I could not find a decent straight answer.
My questions:
When I download a jar using maven dependency (setup in pom), how can I be sure that the file does not change on the remote repository? for example, if I'm using log4j version 1.2.3, downloaded from ibiblio.org (or any other repo for that matter), how can I be sure I'm getting the exact same jar each time?
Does maven delete jars from the local repository? let's assume I'm not clearing the repository at all, will it fill up eventually? or does maven have some kind of mechanism to clear old jars?
In Maven conventions a released version like log4j 1.2.3 will never be changed. It will be left in your locale repository until you manually delete it. It can't be changed by anyone except for the admins on maven central, but i suppose they don't do such a stupid thing.
Furthermore the download by default is done from maven central (repo1.maven.org/maven2 instead of ibiblio).
One of the "tricks" in Maven is download an artifact (released) only once...that improved your build performance in contradiction to the SNAPSHOT dependencies.
You could configure your own repository, and point all your project poms at that. It's easy to configure your poms to use a different (private) repository, but I've never set one up myself. Doesn't seem too hard, other than managing it to keep all the needed artifacts available.
I'm working on a project with several corporate remote Maven repositories, each hosting many dozens of dependencies. The entire project uses hundreds of dependencies and I need a way to quickly determine which remote repository a dependency is stored on.
Does Maven provide an easy way to do this or do I need to search through each repository's dependency listing myself?
The project dependencies report has the information you want. You can quickly generate just this report using
mvn project-info-reports:dependencies
and open the target/site/dependencies.html file. Look at the last section in this report (dependency repository locations) for the info you want.
A sample of this report is here.