I would like to speed up artifacts building process including javadocs but most important is time when artifacts will be ready to use without javadocs. I'd like to build and deploy first all artifacts and when they will be ready then I'd like to create and deploy javadocs for them.
Is there a solution to separate deploying javadocs from deploying artifacts?
I found a command "deploy:deploy-file" and I suppose that it might work for manual deploying javadocs but it seems to be very inconvenient. Is it a good direction to resolve my problem?
Related
I have a mission to develop an integration tool which allows from a source code folder to generate a WAR or OSGI Bundle and then deploys it in Tomcat or Karaf. I used Maven Embedder to create the artifacts, now my problem is how to configure my pom.xml to automatically deploy these artifacts.
on the internet I can't find any examples and also I'm new to the world of JEE and Maven.
please help me.
Find out how you can deploy artifacts to Tomcat or Karaf (without Maven).
Find out how you can deploy artifacts to Tomcat or Karaf programmatically.
Find a Maven plugin to use that deployment method.
The simplest solution would be to use something like the maven-resources-plugin to copy your built artifacts to the servers deployment directory but I am pretty sure that there are more sophisticated methods like http://tomcat.apache.org/maven-plugin-2.2/tomcat7-maven-plugin/deploy-only-mojo.html for deploying out of maven without plain file system mechanisms.
On a wider scale when working on problems like yours it always helps to take a step back and think about the abstract use case ("How to deploy something somewhere" followed by "How to deploy something somewhere programmatically") before going into detail and think about Tomcat or other application servers - and in most cases you will find out that there were hundreds of other who already had the same problem and solved it some way or the other.
Story
I know, that maven deploy command runs through the whole lifecycle. My problem, that it takes to much time in my case. Let me explain:
There is an application built up from a Server, and a single sourced Eclipse RAP&RCP client
The communication is defined by shared API projects which are built together
with the Server, but also needed by the GUI projects
The GUI projects are built by Tycho, so its impossible to build
both of them in one build (in one reactor, EDIT: since the P2 artifacts are different for RCP and RAP)
I build a release with a multi step Jenkins build. To make sure, that
everything is fine I first make a clean install for Server and the
GUI variations one by one, and then I deploy them, if nothing fails
Question
Building everything twice takes a lot of time. Is there anything like "please simply deploy all built artifacts as they are from my local repository to the POM defined repository with skipping the whole lifecycle"?
If you have the artifact already by the previous build, you may consider the deploy:deploy-file by following the Guide to deploying 3rd party JARs to remote repository. I always use this goal to publish some stable artifact to the developer public remote repository for letting other team to test/use.
I hope this may help.
I don't think that there is a pure Maven solution to this. The problem is that your deploy only build won't know which artifacts to deploy – AFAIK this information is only in the in-memory Maven model and not persisted to the target folder.
The problem can be solved with a Maven repository manager that supports staging, like the (commercial) Nexus Pro. Then, your build would deploy straight away into a staging repository, and only promote the artifacts to the (main) repository if everything succeeded.
Wherever you read about continuous delivery or continuous integration it's recommended to use an artifact repository to store the artifacts even though Jenkins already stores them for each build.
So why is it recommended to use an artifact repository? Is there a smooth solution to work with the artifacts of the Jenkins builds, ex. to use these artifacts for deployment?
An artifact repository and continuous integration tools serve two different purposes and one cannot be substituted with the other. Check this video from Artifactory, one of the providers of artifact repositories, about why one should use an artifact repository.
Jenkins stores the artifacts as plain files without versioning while artifacts in an artifact repository can be version controlled. So you have a lot more flexibility in retrieving artifacts and governing them. Read this very good article on why we need them. Surely not all of those things are supported by continuous integration tools like Jenkins.
Moreover, you can also look at the Artifactory plugin for Jenkins which integrates the two.
An artifact repository is needed but the artifact repo is a conceptual piece an not always a distinct tool. With Jenkins you should have MD5 signatures and (I think) a way of downloading the files you want (web service call, right?) from your remote server. Certainly, if you're doing something simple like using the Jenkins build pipeline plugin, it should be able to access the right versions of the files smoothly.
Alternatively, if you are using a separate deployment tool, the better ones bundle an artifact repository.
Regardless, you want what the ITIL folks call a Definitive Media/Software Library. Definitive in that the bits are secure, trusted, and official. And a library in that they can be easily looked up and accessed. When working with an artifact repository, you need to make sure its adequately secure. It is backed up. It is accessible for your deployments (including to production). If you look at Jenkins and it meets your criteria in those categories, consider yourself done. If it's lacking, and I wouldn't be surprised if it was, then you need either a dedicated tool like the Maven repos, or something bundled with the deploy tooling.
For more of my rambling on the subject, there's a recorded webcast. The slides for that are up on Slideshare.
I haven't kept up to date with Jenkins, we still use a version of the CI when it was orginally called Hudson.
In your projects your poms you should normally point to your own artifact repository were you can fetch and deploy your own (company) projects.
Using an artifact repository with your CI server, it can then deploy successfully built snapshot and releases which can be available to other developers.
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/
We have a multi-module Maven project who's primary artifact is a WAR. However our final build step is RPM packaging of that said WAR, and we really don't care about the WAR itself from a distributionManagement perspective. I would still like the JARS/source-jars uploaded to our Nexus repository, but it's just wasteful in terms of time/space to upload the WARs since no-one links agains that.
I would like to mark the WAR plugin as 'ignored' from a build life cycle point of view when going through the 'deploy' phase, since the RPM bundle itself is used.
I can't see any plugin configuration of the WAR plugin to avoid this, has anyone got any pointers?
Isn't that what the primaryArtifact property does? I've never used it, but I always assumed that's what it was for.