I need a tool that will help to find all artifacts that reference another artifact.
When I rebuild an artifact, I need to update/rebuild all artifacts that were using the old version. But I work in a big organisation, and nobody knows really where the artifact is spread in the organisation, so nobody is ever completely sure that everybody use the latest versions.
What I need would be a tool - maybe an artifactory plugin or feature, or a maven plugin doing a lookup in the repository - that indexes all the known poms, and is able to make a listing of all artifacts that have the updated artifact in their dependencies, either directly and transitively. Thus a list of artifacts I would need to rebuild. Quite the opposite of dependency:tree.
Filtering that list by repository, groupId, packaging, etc. is a nice to have. But I can live without.
Any idea?
You can use the Artifactory Query Language with the REST API to do that. For example, if you want to find all builds that use "MySuperAwesomeDependency-1.0.2" your AQL statement would be something like:
//Find builds that use a dependency that is a snapshot
builds.find({"module.dependency.item.name":{"$match":"MySuperAwesomeDependency-1.0.2*"}})
The key in the above statement would be the module.dependency.item.name, which allows you to search for dependencies by name, assuming you store the dependencies in Artifactory.
Related
Are https://mvnrepository.com/repos/central and http://central.maven.org/maven2/ the same maven repository (called Maven Central)?
Also there is https://repo.maven.apache.org/maven2/ which also calles itself a Central Repository.
I use mvnrepository.com as I find it more convenient, but many referencies to Maven Central in Internet lead to http://central.maven.org
Besides both sites above are for Maven2, right?
What are the analogues for Maven3?
Besides is Maven3 widely used?
As far as I know, mvnrepository is just a search site that is not maintained by the maven people directly. It's a search site as I see it. It has been around for a while. Since it contains multiple repository source to search in and lets you select which one you work with its pretty transparent and I don't see any harm there.
If you execute mvn help:effective-settings you should be able to determine what repositories are used, in case some changes where made. The current central default in maven seems to be https://repo.maven.apache.org/maven2/ - the official search interface being https://search.maven.org/
You can also look into the maven sources of the pom what config you running on.
The /maven2/ part in the Uri only means what repository format is used within. This has not changed for maven 3 (it was different for maven 1). So it's the correct and current one today, there is no maven 3 repository format. Everything new could be added to the maven 2 format (for example some search index files or checksum files).
I have various projects (lets say Project 1, project 2, project 3 etc....). They are in different repositories in the BitBucket.
Some of these Projects share the same Versions. I wanted to check if I can use a Super Parent POM ? I want the Projects to listen to the Parent POM for Version changes, is this possible ? Did google around however dint find any useful information on this.
Any pointers will be helpful
Thanks,
You can use one parent POM for all you projects no matter where you store them. The only requirement is that that POM is deployed in a Maven repository and is available in any of that projects. It can be Maven Central or JCenter or your corporate Maven repository like Artifactory or Nexus. Actually, a lot of open-source projects depend on so-called oss-parent POMs. Take a look at Guava, for example, it depends on sonatype/oss-parents. Some companies make their own parents, like FasterXML.
The answer to second question is generally "no". You cannot simply "watch" for the version changes in such parent POMs, unless you:
Own them. The easiest way. You can trigger downstream builds, or fire alarms, or automatically create issues / tickets in children POMs whenever you update parent POM.
Configure you CI/CD to do that. Basically, it's the same as 1, but you just have to watch for the updates and trigger things.
Use third-party service that will do that. Once, there was one called VersionEye, but they are gone. I've heard that Snyk is doing something similar.
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 have a question regarding the AQL (Artifactory Query Language) used by JFrog Artifactory to find "things" in the artifactory. The AQL seems to be very powerful, but i'm wondering how to build (correct) search queries, using the correct terms.
The AQL documentation (https://www.jfrog.com/confluence/display/RTF/Artifactory+Query+Language) offers several object types. But what's the exact difference between an item, artifact, build and entry?
If i'm searching for a specific "file" (JAR) - is it an artifact, an item, or both?
Responding your last question, this is indeed an artifact. Every file in Artifactory is an artifact. With that being said, every artifact is an Item. Therefore use the item.artifact closer. :)
Build is something a bit different, as Artifactory is a binary repository manager, it can connect and serve different build agents, such as Maven, Gradle, Nuget, PyPi etc... When using those clients in a CI server, that JFrog has plugin for (For example, Jenkins, Bamboo, TeamCityetc..) , it will produce a build info JSON that includes all of the information on your build. Also, the artifacts produced during this build will be associated to that build using properties. Long story short, you can use the 'build' closer in AQL to search for details in a specific build or to search for builds that contains specific data.
Hope this was helpful :)
In a project with an online dependency management done by ivy/maven, is it good practice to back-up the artifacts e.g. by including them in the projects source code / version control (e.g. svn, git) or is it (safe) enough to so so with pom.xml / ivy.xml? Of course, having the artifacts not backed up somehow makes the project totaly depend on the availability of the maven repo.
EDIT:
The reason for my question is that I fear that certain artifacts are no longer available on the official maven repository, or even that the repository itself is down. In such a case, having the libs under version control gives the security to be able to build the project in such a case.
My advice is not to backup the artifacts . if the artifact is not available , then you should consider it to change with replacement however I see very rare possibility of this to happen . Any way , you can always get old artifact JAR from your previous build for the scenario when we do't have any option and you have to use old artifact So i will not suggest to keep separate backup .
thanks ..