My team uses an internal team maven repo that is shared from a development server using Apache. We also run the Continuum CI server on the same machine. Maven builds in Continuum are run with the "install" goal, which copies the final artifact directly into the shared directory.
The question is, what is the difference between adding files to the shared repo using mvn install and using the deploy goal (mvn-deploy plugin)?
It seems to me that using mvn deploy creates additional configuration hassles, but I have read somewhere that installing files into a shared repo is a bad idea for some reason related to the internal workings of maven.
update: I get the functional differences between deploy and install; I am actually more interested in the low level details in terms of what files are created in the maven repo.
Ken, good question. I should be more explicit in the The Definitive Guide about the difference. "install" and "deploy" serve two different purposes in a build. "install" refers to the process of installing an artifact in your local repository. "deploy" refers to the process of deploying an artifact to a remote repository.
Example:
When I run a large multi-module project on a my machine, I'm going to usually run "mvn install". This is going to install all of the generated binary software artifacts (usually JARs) in my local repository. Then when I build individual modules in the build, Maven is going to retrieve the dependencies from the local repository.
When it comes time to deploy snapshots or releases, I'm going to run "mvn deploy". Running this is going to attempt to deploy the files to a remote repository or server. Usually I'm going to be deploying to a repository manager such as Nexus
It is true that running "deploy" is going to require some extra configuration, you are going to have to supply a distributionManagement section in your POM.
From the Maven docs, sounds like it's just a difference in which repository you install the package into:
install - install the package into the local repository, for use as a dependency in other projects locally
deploy - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
Maybe there is some confusion in that "install" to the CI server installs it to it's local repository, which then you as a user are sharing?
"matt b" has it right, but to be specific, the "install" goal copies your built target to the local repository on your file system; useful for small changes across projects not currently meant for the full group.
The "deploy" goal uploads it to your shared repository for when your work is finished, and then can be shared by other people who require it for their project.
In your case, it seems that "install" is used to make the management of the deployment easier since CI's local repo is the shared repo. If CI was on another box, it would have to use the "deploy" goal.
Related
How can I support these NPM/ember addon scenarios?
developers build ember addon A and use build ember application B which uses their A local package
developers only builds B installing A from our nexus NPM integration repository
build system builds ember addon A installing into our nexus NPM release repository
Maven
developer desktop builds install packages to a local repo to be used later in the build.
build system builds deploy packages to our internal shared repo to be used by developers so they don't need to build all
NPM
build system builds can use npm publish --registry http://ourrepo/nexus/.... to publish into a private registry
develop desktop builds do????
We could use DependsOnMe with relative paths but that requires us to setup some kind of rule where builds work one way locally and another on the build machine.
While possible, I hope there's a more elegant solution to making this happen.
Can I have developers generate packages that go into the local npm cache for later use and if so can you point me to that documentation?
Related
locally build npm package in project
nexus npm deploy doc
Because we use maven front end plugin to manage npm and ember we can encapsulate an additional npm module (in this case an ember addon) as a maven artifact and make use of maven dependency management for our various scenarios
Ember Add On module
add 'npm pack' to generate local package in npm repository (in our case root/target/tmp/.npm//)
add assembly to generate tar.gz containing tar file (a little silly) and attach it to module as an artifact (type: tar.gz, classifer: ember-addon)
Client module
add maven-dependency-plugin unpack which unpacks addon module's tar.gz classifier: ember-addon to target/ember-addons prior to npm execution for this module
modify package.json to use local dependency "our-addon" : "file:../../target/ember-addons///package.tgz"
If a user builds ember and client, then addon module build placing the artifact in local maven repository. Client module unpacks from local repository and pulls into node_modules via npm ember build process.
If a user only builds client, then client module fetches addon artifact from our nexus repository prior to the unpack and use phases.
I am experimenting the use of Rational Asset Manager to store our binaries and/or build artifacts. I am running a mvn deploy command to deploy my build artifacts to RAM. Although it recognizes the connection its throwing me a Http status code: 500 error.
I have also checked RAM logs for more information but i don't see any specific exception. All the examples or documents out on internet says we have to configure RTC build engine to run the builds.
I just want to know if anyone have tried publishing to RAM from command line using Mvn deploy ( without using RTC client ) ? is this do-able?
If you have successfully published artifacts to RAM using maven, can you please elaborate on how you did it?
It seems to be possible, if you follow the steps described in:
"Creating and using Maven assets", and
"Deploying from Maven to assets":
Before you can use Maven assets, a repository administrator must enable the Maven model library. For more information, see Enabling the Maven library.
The mvn client can integrate with Rational Asset Manager, using Rational Asset Manager as a Maven repository.
Before you deploy from Maven to Rational Asset Manager, you must add a repository entry to the pom.xml file on the computer where you plan to run the mvn client. See Creating and using Maven assets for more information.
I was able to deploy the artifact using mvn deploy after changing the following things in RAM
Pointed to a JRE version in RAM ( originally was pointing to JDK
version) and
Changed permissions for my role for saving my artifacts
in RAM ("save Work Item") Reference
Currently I have a simple maven project that is building a jar file and putting it inside target/some-1.0.jar when i run mvn install.
I want to copy this file to another location when I run mvn deploy.
Currently the location is on the same machine, but it would also be great if the solution could be applied for multiple targets, some of them being on other machines (scp deployment).
What is the easiest solution to do this? I would be nice, if you could include an example too.
Details: I have few jira plugins that are compiled as jar files and I just want to be able to run a single maven command that would copy the files to the server and eventually restart the server.
mvn deploy is intended for deployment to a remote Maven repository. mvn install is used for copying to the local Maven repo (so actually, the jar is also ending up in $HOME/.m2/repository, as well as target).
I'm not sure what you're intending to do, but I suggest you look at deploying something like http://www.sonatype.org/nexus/ if you want Maven artifacts to be available to multiple machines. This will integrate nicely with the rest of Maven.
Edit: based on your updated question, it's probably best to investigate the Wagon ssh plugin, or see if there's an Ant plugin. A suitable phase would be pre-integration-test: install and deploy should be run after you've run your integration tests to check the artefact works as expected. Use profiles to distinguish the local vs. remote cases.
I am setting up an ant build system on a project with dependency resolution being managed by ivy. I have it up and running with the file system being used for the local and shared repository currently. My ultimate goal would be that when developers are fixing bugs or creating new functionality, they would only be able to put artifacts into their local repository. When they belive their code is ready to be used by the rest of the team, it would be promoted to the proper branch in SVN and the group in charge of doing official builds would compile and publish the new artifacts.
So I guess my questions are how can you control who can publish to a repository? Does ivy just rely on filesystem permissions?
Also, I would eventually like to make my shared repository available via http. I think I could point apache to the file system repository directories for retrieving artifacts, but how do you setup publishing to an http repository?
I would suggest that you setup a repository manager to manage your project's build artifacts.
The best choices are one of the following:
nexus
artifactory
archiva
Publishing to a Maven repository means that your artifacts can be consumed by projects using other build technologies. All modern build systems support Maven (Including ivy, see the ibiblio resolver).
You could specify three resolvers in your ivy settings file. First would be a chain resolver which include remote and local ivy repositories. Second would be a local resolver for local ivy repository. Third a resolver to remote ivy repository only.
Every developer retrieves artifacts using first chain resolver.
Usual developer publish artifacts using second local resolver.
Your special team could use third remote resolver to publish in remoter ivy repository.
To protect remote repository from usual developers place it on (S)FTP server with write protection by password.
The only problem in this case is how to set versions on artifacts so that artifacts published in remote repository in some cases override locally published in some not.
Our team used such scheme few years ago. But now we use only local ivy repositories and CI server to build and run tests from various branches. We came up to this after switching to git.
for existing ivy repo easy to setup this: rest-ivy
I think there should be some difference, but can anyone tell me the details?
mvn:install copies your packaged Maven module to your local repository (by default, in ~/.m2/repository), to be accessed by other local Maven builds.
mvn:deploy uploads your packaged Maven module to another (usually remote) repository, to be accessed by other, not necessarily local, Maven builds.
See the documentation for the build lifecycle for more info.
The install phase is responsible for the installation of artifacts into local caching repositories. This basically applies to the Maven repository, but a well-known example is also the OSGi Bundle Repository supported by maven-bundle-plugin.
The deploy phase is responsible for the installation of artifacts into published repositories. This usually applies to remote repositories, but is could perfectly be a local repository exposed to the outside world.
As all Maven phases, you can do with them anything you want. You can shuffle plugin phases as you see fit, but the above semantics is the conventional one and you should stick to it in order to be consistent with the default phases of other plugins' goals.
mvn:deploy performs deployment to remote reposiory/environment, mvn:install installs all compiled packages to a local repository making them available to other builds performed on the local machine.
In one sentence: mvn:install compiles and installs your component in your local Maven repository, so that you can use it when other components used and developed locally depend on it. mvn:deploy deploys your (previously installed) component to a remote repository.