I manage many maven projects. Most of them deploy to our internal maven repository. Now I would like to start releasing one project to Maven Central. Up until now, I have had a parent POM that specified the distributionManagement of our internal repository. It doesn't make sense to deploy this information to Maven Central.
How should I specify the distribution management for my internal projects? Should I have a seperate parent pom group-internal for internal projects?
Sonatype mentions a way to deploy directly to their repositories, but they recommend using their own parent pom (oss-parent). Looking at projects using mvnrepository.org, I couldn't find any projects with oss-parent as the parent. Do most project manually deploy their artifacts to Sonatype? Where and how do they deploy them first?
So many questions! I'm amazed at how complicates this is...
Update: it turns out some of the projects I identified do use oss-parent. It's just hidden as it's the parent of a parent.
Once you are all set up, you can deploy staged releases and SNAPSHOTs directly to Sonatype's OSS repository. Stages releases can then be released through Sonatype's Nexus UI.
To create a repository folder for your application to which you can deploy, you open a ticket with Sonatype on their JIRA along with a reference to the open-source project you will deploy. The process is very smooth and Sonatype will help you if you don't supply all the necessary information.
While on first glace it doesn't look like many projects have oss-parent as a parent, they often do when you navigate up the POM tree. For example, Google Guava has the parent guava-parent, which has the parent oss-parent. Once your project has oss-parent and the repository is configured, you can easily deploy SNAPSHOTs and releases with mvn deploy or mvn release:prepare release:perform.
It seems overwhelming, but it's easily understood if you just plow through the steps for the first time.
The first I recommend to read is the following:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide
The OSS parent makes under special circumstance sense under other not. That depends what kind of project you like to distribute.
UPDATE: That link is dead now. Look here for help deploying to Sonatype.
UPDATE: For Maven Central check this: http://central.sonatype.org/
Related
I know how to do it for an external repository but not for my local repository, since I don't have a <repository> for my local repository in my settings.xml.
I use snapshot versions for my sub-projects, so when I re-build the parent project I want maven to get all the sub-projects snapshot versions from my local repository not only once a day (which seems to be what happens by default) but always.
If I'm understanding your comment, I think #FrVaBe may have the correct answer. When you change code for a child project on your development machine, it's up to you to rebuild the snapshot and get it into your local artifact repo (via mvn install) so it's available for the parent project to use.
If, however, you want your parent project build to pull in changes made by your teammates and published to the corporate remote repository more often than once per day, read on.
Here is a summary of how Maven central (and kin), remote repositories (e.g a company instance of Nexus or Artifactory) and your local repository work together. If you always want the latest version of snapshots to download on every build, go into your settings.xml file, find <snapshot> repository containing the snapshot you want, and change the <updatePolicy> value to "always". Personally I rarely do this, I simply add the '-U' option to my mvn command line when I want to ensure I have the latest version of a snapshot from my remote repo.
There is no update policy for the local repository!
The local repository is just a bunch of files. When you install to your local repository your local projects already reference the artifacts directly. There is no update that needs to be performed except that maybe your IDE needs to be refreshed to pickup the newer files.
In this manner you can build local snapshots all day long with no versioning headaches, no updates required and no old artifacts left hanging around afterwards. Nice and clean but not so obvious if you're new to Maven and still getting to grips with all these repositories and their fancy update mechanisms.
I think you missunderstood something. Maven will always take the latest/newest SNAPSHOT from your local respository. But in your project setup (Project Inheritance) you need to build the sub projects on their own if you changed something.
An automatical build of the sub project only happens on a Project Aggregation layout.
The difference is explained in the Project Inheritance vs Project Aggregation section of the documentation.
Every time I make a new proper project using Maven hosted on Github I have to go look at either one of my own old projects and copy the pom file or I go find a project that I think does a good job and copy there POM file. Then I have to go search and replace things like project name... etc.
Now Maven has a solution to this through archetypes but I have yet to see one that is modern enough such that it:
Uses the release plugin and deploys to SonaType Central Maven reop.
Connects to Github (meaning the scm connections and release plugin work do the right thing)
Makes all three jar artifacts (sources, javadoc, and regular jar)
I have contemplated make some giter8 templates but was hoping somebody already did something like this (most of the g8 templates are for sbt).
You can use com.jcabi:parent:pom which does exactly what you need and many more. It deploys to Sonatype, defines common dependencies with versions, pre-configures most popular plugins, and defines a few useful profiles.
This article explains more: Don't Repeat Yourself in Maven POMs; Use Jcabi-Parent
You could have a look at the parent pom released by Sonatype. It's intended to be used as a parent pom for projects that deploy to oss.sonatype.org (which may or may not be promoted to Maven Central).
When the sonatype-oss-release profile is enabled, it will ensure that sources and javadocs are built. It also includes an example of the <scm> pom element.
It turns out its incredible easy to create your own maven archetype.
Just make a generic project with stuff you like to use
In the project directory run mvn archetype:create-from-project
Generally Maven guesses the right things to make variable but if not you just edit the Velocity templates.
Install your archetype locally with mvn install
To use your new archetype: mvn archetype:generate -DarchetypeGroupId=com.mygroup -DarchetypeArtifactId=my-archetype
Now the only caveat is that there is not very good doc on the web that I could find on the archetype system. Like its unclear what variables you have available to you for Velocity (although most of them are obvious).
http://maven.apache.org/archetype/maven-archetype-plugin/create-from-project-mojo.html
I have a little problem that´s occurs in my computer, when I make deploy to artifactory, the name of the library changes as follows:
servico-disponibilizacao-2.0.0.0-20120117.194415-1.ear
In my project on Eclipse, I can see normally how this is:
servico-disponibilizacao-2.0.0.0-SNAPSHOT.ear
I really don´t know how to fix this, anyone have some ideia?
Thank´s so much for any help!
When publishing to a snapshot repository Maven will substitute the "SNAPSHOT" part of the revision with a timestamp, to create a unique version for that build.
See the Maven documentation on the distributionManagement section of your POM.
Additionally checkout this answer:
Maven Snapshot Repository vs Release Repository
Update
The Nexus book has a section describing the differences in artifact handling between snapshot and release repositories. I should think this information also applies to Artifactory, considering Nexus is the reference Maven repository manager.
I want to create a maven project, which has to depend on a non maven project which in turn depends on 2 other non maven projects. I do not have ownership of any of the other projects and it would not be possible for me to change anything in those projects let alone the structure to conform to the maven structure.
I asked if I could just get jars -- but was told that because of multiple levels of dependency, it would be "difficult" -- although I haven't understood why.
Is this possible or should I just abandon the use of maven to create my project and go with a regular project with jars in the lib folder?
Inxsible
If you can go with a regular project build that means you must have access to the other project's jar files?
It doesn't really matter how the other project builds them, you can still gain more control over your own build process by loading the jars you depend on into a Maven repository.
I'd suggest using one of the following repository managers:
Nexus
Artifactory
Archiva
They'll give you management screens to uploading 3rd party jars, they'll also a more efficient way to use other Maven repositories like Maven Central.
Once you've got your Maven build process working, you could encourage the other projects to automatically publish their versions into your Maven repo.
They could use the ANT tasks provided by the Maven or Apache ivy projects. Worst case you just continue to load their libraries until they see the light :-)
I have a following problem. We have a central maven repository hosted on our company server. Our team is working on a project. Everyone here uses that repository to get the required artifacts. If something is missing at the moment and is required for the task that the developer is currently dealing with, he installs this artifact manually to the central repository, so that his commits don't break the automated builds.
Now, each developer also has Glassfish v2 installed on his machine. That is for testing and debugging purposes. Before committing the changes, developer makes the .ear for the project with Maven help. However, after the developer deploys the ear to it's local glassfish, frequent errors arise, because the set of glassfish libraries may not contain all the latest dependencies of the central company repository.
Right now in case of the error the developer simply reads the log and looks what exactly is missing. After that he manually copies the required jar inside his local $GLASSFISH_HOME$/lib dir. But that seems a little bit frustrating. How can this be done automatically?
Right now we are trying to implement the following solution. The developer has to synchronize his local maven repository gathering all the artifacts from the central one that are required by the project. This local repository has to be placed on the java classpath, so that glassfish would also see it. Is that a correct approach? Maybe there is a way to install directly all the required artifacts from the central repository inside $GLASSFISH_HOME$/dir and this can be done automatically during deploy?
About having to install dependencies. If the developers need to install dependencies missing from public maven repositories, take into account that usually maven proxies have the ability to cache public repos. For instance, archiva has a proxying cache. If the dependencies are your own project deliverables you should consider releasing and deploying with maven to your company repo.
About latest versions. You need to specify maven what version of dependencies should use. I would prefer editing my poms manually, anyway there's a variety of ways to achieve that.
The libraries should be part of the project, I think. If not standard libraries of glassfish, they should be included, for instance, in your war file as part of your project. If not standard but not part of your project (not the regular approach) consider managing this glassfish as a project on its own (own git/svn repo, own pom, own versions, own everything).
Good luck.