This question already has an answer here:
Is it mandatory to provide SCM Url for getting project ID in maven central
(1 answer)
Closed 2 years ago.
I need few clarifications regarding releasing the artifacts in maven central. I could see in the requirements that for SCM information project URL need to be added, which means whether we supposed to share the source via SCM. Since my understanding as maven central is public repo and so they expect source need to be shared or we can share our github link (which may point to source related demos).
Since working in an organization we are not interested in share as open source. It is will be commercial project, whether we can release the artifacts in maven central with SCM Url pointing to source demos . Can anybody share your valuable suggestions?
Note: Artifact to be hosted is for commercial purposes.
Maven Central requires you to share the source. From your own link:
Supply Javadoc and Sources
Projects with packaging other than pom have to supply JAR files that contain Javadoc and sources.
While there's no technical requirement that your SCM is world-readable, there's no point in trying to hide it.
Artifact to be hosted is for commercial purposes.
That's not what Maven Central is for. If you have a commercially-licensed, closed-source library and want to provide Maven integration, then set up your own private repository for your customers. You'll also need to invest in some heavy obfuscation if you don't want people trivially decompiling or modifying it though.
Related
Currently I'm learning the details about Gradle. I'm just curious, there is central repository like MavenCentral, and there are many repositories stored in there. It seems there are no 'GradleCentral', do all Java Library is usually using Maven as a build tools? If yes, why does this happen? Is it because of Maven is the better choice to create a Java library?
It's not just Maven Central that is available to host libraries. There are tons of public and private options out there but by far Maven Central is the most popular and safe option. For closed source development projects, libraries are hosted on nexus and other similar solutions and I've seen open source projects hosting on others as well.
As for the popularity of Maven, It is an official Apache project thus enjoys more authenticity over other similar build solutions and others show compatibility towards Maven as well.
I have built a JAR and want to put it into Maven Central. How do I actually do that?
I have reviewed the instructions here:
https://maven.apache.org/guides/mini/guide-central-repository-upload.html
This has got to be the worst set of instructions I have ever seen. Seriously, try reading it.
These instructions make no sense to me. They are basically impossible to understand. Can someone please share with me a simple plain-English set of steps for how to actually get your JAR into Maven Central? Would really appreciate it.
Like explained between the lines on that page, you need a supported repository hosting location to be able to get your artifact into maven central. Since there is only a handful of such locations, the best bet to get something in there is to have it as open source release, as those have an open one:
The easiest way to upload another project is to use the Open Source
Software Repository Hosting (OSSRH), which is an approved repository
provided by Sonatype for any OSS Project that want to get their
artifacts into Central Repository.
That's what I've used as well. Refer to their instructions for details. In short, you need to
create a jira ticket for your project and get it approved
deploy your artifact (fulfilling the requirements, using either Maven or some other deployment tool) to their private staging area
promote the release to release area
If all goes well, after the last step the release will be synced to maven central in roughly ten minutes.
why use Maven when you have such quantity of local jars?
So we have a client that have a lot of private jars and custom jars.
For example commons-langMyCompanyCustom.jar which is commons-lang.jar with 10 more classes in it.
So on their environment we use 100% Maven without local dependencies.
But on our site we have the jars for development in Eclipse and have Maven build with the public ones, but we do not have permission to add their jars in our organizational repository.
So we want to use the Maven good things like: compile,test, build uber-jar, add static code analysis, generate java-docs, sources-jars etc. not to do this thinks one by one with the help of Eclipse.
So we have 70 jar some of them are public if I get the effective pom on their environment I found 50 of them in Maven Central, but the other 20 are as I called "custom" jars. I searched for decision of course but found this:
<dependency>
<groupId>sample</groupId>
<artifactId>com.sample</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${project.basedir}/src/main/resources/yourJar.jar</systemPath>
</dependency>
So for all 20 of them I have to add this in the development maven profile??
Is there a easy way like in Gradle where you can add all folder with its dependencies to the existing ones?
Also installing one by one in every developer's repo is not acceptable.
Please forget the system scope as mentioned before! Too problematic...
Ideally:
Ideally, all your developers have access to Repository Manager in your or their organization (if possible).
A central environment for your System Integration Testing, maybe?
Alternatively, you may have a central environment for testing where all the dependencies are provided. This approach can be used to simulate how a compilation would work as if it's in your client's environment. Plus you only setup jars once.
So on their environment we use 100% Maven without local dependencies.
But on our site we have the jars for development in Eclipse and have
Maven build with the public ones, but we do not have permission to add
their jars in our organizational repository.
According to what you're saying in the above-quoted excerpt I believe you want to have set in your build's pom.xml assuming that in the client setup the dependencies will be present.
Especially, as you indicate that the organization doesn't give you permission to add their jars in your repository, I would use the provided scope.
As stated in the Maven docs, the definition of a provided dependency is as followed:
This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.
So basically you assume that these dependencies will be present at your client's setup. However, this has some limitations. Meaning you can build solutions independently but cannot test it locally because you won't have the dependencies on your workstation.
If you won't even have access to the jars to configure your central environment ask if your client can provide a DEV/SIT environment.
None of the above? Inherit a parent pom.
To avoid the whole constant copy-paste process for every single (related) project, maven has the tools to centralize dependency and plugin configurations, one of such is by inheriting the configuration of a parent pom. As is explaining in the following documentation it is quite simple:
First you create a project with just a pom.xml where you define everything you wish to centralize (watch out, certain items have slight differences in their constructs);
Use as property of packaging tag the option pom: <packaging>pom</packaging>;
In the pom's that have to inherit these configurations set the parent configuration tags in <parent> ... </parent> (documentation is very clear with this);
Now everytime you update any "global" pom configuration only the parent version has to be updated on every project. As a result of this, you only need to configure everything once.
You can also apply this together with the abovementioned solutions, this way combining to find a solution that fits best to your needs.
But there is a big Maven world out there, so I advise a good read in its doc's to further acknowledge your possibilities. I remembered these situations because I've been in a similar situation you seem to be now.
Good luck!
Another alternative is the project RepoTree.
This one creates a Maven repository directory (not a server) from another directory which contains just the .jars. In other words, it creates the necessary .pom files and directory structure. It takes into account only the precise information from metadata contained in the archives (MANIFEST.MF, pom.xml).
Utility to recursively install artifacts from a directory into a local
Maven repository Based on Aether 1.7
This is 5 years old, but still should work fine.
TL;DR: MavenHoe creates a Maven repository server (not a directory) which serves the artefacts from a directory, guessing what you ask for if needed. The purpose is to avoid complicated version synchronizing - it simply takes whatever is closest to the requested G:A:V.
I have moved the MavenHoe project, which almost got lost with the decline of Google Code, to Github. Therefore I put it here for availability in the form of a full answer:
One of the options you have when dealing with conditions like that is to take whatever comes in form of a directory with .jar's and treat it as a repository.
Some time ago I have written a tool for that purpose. My situation was that we were building JBoss EAP and recompiled every single dependency.
That resulted in thousands of .jars which were most often the same as their Central counterpart (plus security and bug fixes).
I needed the tests to run against these artifacts rather than the Central ones. However, the Maven coordinates were the same.
Therefore, I wrote this "Maven repository/proxy" which provided the artifact if it found something that could be it, and if not, it proxied the request to Central.
It can derive the G:A:V from three sources:
MANIFEST.MF
META-INF/.../pom.xml
Location of the file in the directory, in combination with a configuration file like this:
jboss-managed.jar org/jboss/man/ jboss-managed 2.1.0.SP1 jboss-managed-2.1.0.SP1.jar
getopt.jar gnu-getopt/ getopt 1.0.12-brew getopt-1.0.12-brew.jar
jboss-kernel.jar org/jboss/microcontainer/ jboss-kernel 2.0.6.GA jboss-kernel-2.0.6.GA.jar
jboss-logging-spi.jar org/jboss/logging/ jboss-logging-spi 2.1.0.GA jboss-logging-spi-2.1.0.GA.jar
...
The first column is the filename in the .zip; Then groupId (with either slashes or dots), artifactId, version, artifact file name, respectively.
Your 70 files would be listed in this file.
See more information at this page:
https://rawgit.com/OndraZizka/MavenHoe/master/docs/README.html
The project is available here.
Feel free to fork and push further, if you don't find anything better.
Simple console maven artifacts with shared dependencies (some also provide public API's in addition to their own class) living on same production server. How to best organise/install on production server?
My instinct is for a single folder holding all (version numbered) jars (ie. a 'flattened'/dependency populated 'repository') however:
(a) Can't see how such a folder would increase, on a 'dependency' basis, it's population from maven deployment repository
(b) How a jar's manifest's classpath would change from the default 'lib/...,lib/...' (ie. relative to 'main' jar, sensible for dev/test using Eclipse) to just '...,...'
What is recommended best practice as regards organisation on production server?
Google'ing 'maven production classpath' (amongst others) resulted in http://blog.armstrongconsulting.com/?p=232 which seems related but light on detail.
Any pointers?
How experienced are you with Maven? If you are the process described in the blog you mention is pretty straightforward also without going into details.
Re (a): Dependencies are downloaded from a remote Maven repository into a local Maven repository on demand. Default in ${user.home}/.m2/repository or according to <localRepository> at the beginning of your settings.xml. See Introduction to Repositories. So, there's no need for a single 'flattened'/dependency populated 'repository' folder.
A local repository can also be populated with the install:install-file goal manually. But this can be a cumbersome process if there are many artifacts to install.
See Maven, Available Plugins for what the mentioned plugin:goals do.
It seems as though ivy , maven, grapes , and other dependency managers link to the same integrated repositories.
1) What do these different dependency managers have in common in terms of the way that
resources are checked and downloaded ?
2) When i have a package name in an ivy or maven file -- how can I find the curators of that package ? Where are these remote java resources unified and managed ?
I'm not asking for the "development lifecycle" scope of information here, but rather, I want to know specifically how grapes/maven/ivy are capable of playing nicely together, i.e. , is what is the standard for resolving remote java repositories ?
It's the Maven Central repository that ties together these tools. Tools like ivy can be configured to use their own repository format, but default to using the public Maven repository for downloads.
Maven Central is maintained by Sonatype, the creators of both Maven and the Nexus repository manager. It is estimated that it will soon host 90% of Java's open source libraries.
Maven central can be searched using the following URL:
http://search.maven.org
And the following guide gives information on how one can upload artifacts:
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
Information on the ownership of modules is normally available from the module's POM file. Artifacts are also signed, using PGP, to prove ownership.
In conclusion, while Maven may one of several dependency management clients, it has certainly established itself as the de-facto standard for server-side repository management.