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

Reply via email to