Remember that 'deploy' still calls 'install'. -Chris
On Thu, Feb 23, 2012 at 4:35 PM, Chas Emerick <c...@cemerick.com> wrote: > > On Feb 22, 2012, at 11:54 PM, Manfred Moser wrote: > >> On 12-02-22 08:11 PM, Chas Emerick wrote: >>> I am working on a Clojure facade for Aether,[1] and would like to clarify >>> some semantics. Though I'm working with Aether, I think this question is >>> generally applicable for all Maven tools…but let me know if I should simply >>> bounce to the Aether ML. >>> >>> In short, I'd like to know what the functional differences are between the >>> install and deploy operations, and whether the latter safely supersets the >>> former. >>> >>> I know that 'install' is intended for local file-based repositories, and >>> 'deploy' is for remote repositories using any of a half-dozen well-known >>> transports. I can readily see that installs produce a slightly different >>> set of files and metadata than deploying to the same local file repository; >>> however, those differences do not seem to affect the resolution of >>> dependencies in any way. >>> >>> I presume there must be some subtle ways in which 'install' must remain a >>> distinct operation with its own semantics, but I've not discovered them >>> (and I've not found any documentation which points the way, official or >>> otherwise). Without knowing this, it seems like there's no reason for >>> 'install' to exist at all, insofar as it seems you just use 'deploy' to >>> push artifacts into a file-based repository and successfully use the >>> results. >>> >>> Thanks, >>> >>> - Chas >>> >>> [1] https://github.com/cemerick/pomegranate >>> >> The main difference is probably that install installs the artifacts in the >> local repository of the user. This is normally .m2/repository. This local >> repository is different for each user and will be created when Maven is >> first run and be populated with the plugins and whatever else comes down as >> dependencies required for the Maven invocations. This is all done by the >> install plugin >> >> Deploy on the other hand deploys to a repository as defined in the pom. >> Without that repository defined the deployment will not work. Typically this >> is done together with username/password in settings.xml and the target is a >> repository server like nexus. That server in terms is accessed by other >> developers in with access as well as CI servers and so on. Once a artifact >> is deployed to a repo it does not need to be built locally by developer >> because a team member or ci server made it available on the repo server. All >> this is done by the deploy plugin. >> >> So there are distinct differences and the goals/lifecycle phases serve >> different purposes. As such I think you should not collapse them.. > > Sure, I understand the userland distinction well, but I fail to see what the > 'deploy' operation provides from an API/semantics standpoint that is not > provided by 'deploy'. That is, what would be the consequences of always > performing a 'deploy' in order to push artifacts into a local file-based > repository (like that at ~/.m2/repository)? i.e. Should *any* other Maven > tooling be able to resolve dependencies "installed" into a local repo in such > a fashion, or would resolution potentially fail because, say, the 'deploy' > operation targeting a file-based repository won't create certain files that > are required/expected in a local repository? > > Note that the portion of pomegranate that provides a natural Clojure API for > Aether is decidedly _not_ a user-oriented API. It is intended for > consumption by tools that handle the user-facing bits, like Leiningen[1] and > Counterclockwise[2]. In any case, simplifying its API if possible is a > primary concern, and the (artificial?) distinction between installation and > deployment seems like it's ripe for optimization. :-) > > Thanks, > > - Chas > > [1] https://github.com/technomancy/leiningen > [2] http://code.google.com/p/counterclockwise/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
