What should be stored in a maven repository? - maven

Should I store artifacts that are final products, not to be used as a dependency of another project within a maven repository? i.e. EAR, WAR, zip, tar, etc.
I've been unable to find any documents that explicitly state whether this is the proper usage or not but I see that there are EAR/WAR/zip/tar files in Maven Central: http://search.maven.org/#search%7Cga%7C1%7Cp%3A%22war%22
Is anyone aware of any documentation to support either position?

Related

Maven Central Repository Artifact Source Code / Project URL / License Identification

I'm new to working with Java and have questions regarding the Maven Central Repository. I am much more familiar with Python and PyPI, so I will provide the equivalent in PyPI that I would like to find in Maven.
How can I find the source code for the artifacts in Maven Central? Typically, I see the JAR file and prefer not to decompile these files. Typically, PyPI packages have the source file type in the "Download files" tab.
How can I find the associated project URL to a maven artifact? In PyPI, the package page has a set of project links and generally provides a repository link (e.g., Github, Bitbucket)
How can I identify open-source projects in the Maven central repository? The license for PyPI projects is tagged directly in the meta-reference on the sidebar of a project page.
I appreciate any insight into these questions. Thanks!
When a distributor decides to provide them, you can find -sources.jar and a -javadoc.jar files in the artifacts folder. (common IDE's are aware of that&provide buttons/menus, "Maven>Download XXX";)
like e.g. here
Artifact javadoc (for the sophisticated ones, javadoc and sources refers to the (common) "classifier" of the artifact)
how (easy) to produce them
In the pom:
project.url tag provides:
The project's home page.
project.scm element provides (should provide!) "source control" related (multiple) urls (read-only, contributer, public-browsing).
besides that many other things(and sub-things) can have url in a maven project/pom (distributionManagement(i.e repository), organisation, developer,...).
project.licenses element!
You can be sure to find all of these three (- four) in all (at least latest) artifacts in maven central, due to:
Their Publishing Requirements!;

Maven Central is which exactly repository?

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).

Use a maven repo which does not have pom files

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])"
}
}
}

How to export Maven dependencies or assembly artifact URLs

I have a large maven project with several dependencies. There is also an assembly that contains all files I want to deploy - which is not necessarily identical to the dependencies.
My question: How can I generate a textfile that contains all URLs to JAR-files maven usually downloads the artifacts from? Ideally only from those files in the assembly, but of all dependencies would do as well.
[Update]
My project consists of a root project which has several artifacts from subprojects and external artifacts as dependencies. All dependencies are either stored in my private Artifactory repository or can at least accessed via it using Artifactory as a proxy.
When I roll out a new release, I want to be able that the root project writes all it dependencies in a file, suitable that a client can download those dependencies. The client has no idea about repository structures (I'd like to avoid that), so I need full URLs or at least full pathes within an repository root.

What is the purpose of the pom.xml inside a jar's META-INF folder?

Typically, a maven built jar artifact will have it's pom included under META-INF. I recently noticed that the Spring jars don't have this. So, that causes me to wonder about the purpose of that pom.
It seems like maven retrieves the pom directly from the repository when it's doing things that require knowledge of the artifacts meta-data, e.g. when determining dependencies.
So, what's the embedded one for?
The Maven docs suggest two reasons for the pom in this location.
1) Merely for reference, as a convenience. As the docs say, it makes the artifact "self describing"
2) You can get at this information from within your application using Java. This enables the arfiact to auto-report it's version within the application.
http://maven.apache.org/guides/getting-started/index.html
The pom you will find in the repository is not necessarily the one used to build the artifact. It is aimed at the users of the artifact and can be customized when building your artifact.
The one included inside the artifact IS the one used to produce the artifact.
There are options to not have it included in the artifact.

Resources