[
https://issues.apache.org/jira/browse/MNG-5667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625548#comment-16625548
]
Stephen Connolly commented on MNG-5667:
---------------------------------------
Hmmm actually I think this proposal is the wrong way to do this.
I think we should keep the linear lifecycle, *but* _either_ the install plugin
(in fact plugins in general) should be aware of the final phase and if that
final phase is {{deploy}} then it should skip pushing the artifacts to the
local repository cache but instead put a dirty flag on the artifacts in the
local repository cache _or_ the deploy plugin should put the dirty flag in
place so that the hash gets checked and that way we can save re-downloading a
very large artifact.
Use Case 1: I have a number of projects where some artifacts should never be
deployed but other artifacts should. But allow for sub-reactor builds I need to
install them, but they should never be deployed. (So I have something like this
in those pom files:
{code:xml}
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
<plugin>
<groupId>org.sonatype.plugins</groupId>
<artifactId>nexus-staging-maven-plugin</artifactId>
<configuration>
<skipNexusStagingDeployMojo>true</skipNexusStagingDeployMojo>
</configuration>
</plugin>
{code}
Now if we fork the lifecycle, then I cannot build something that depends on
that locally without including the non-deployed module in the reactor.
Given that these are time-consuming docker images used for integration testing,
i'd rather not rebuild them every time I want to run {{mvn test -f
integration-tests/pom.xml -Dtest=SomeNewTestCaseIAmWriting}} during iterative
development.
Use Case 2: The large artifacts.
I have had projects in the past where Maven builds a 9GB artifact (ISO image of
a VM... yeah don't ask). That can be a pain to upload... but if I then need to
turn around and download it again immediately after uploading it... that would
be really bad.
It may be that the solution for use case 2 is to have the deploy plugin also do
an install... but you can see why I think this is not entirely a trivial
solution.
Use Case 3: What should we then do with {{mvn clean install deploy}}
Once we actually have a forked lifecycle then {{mvn clean install deploy}}
actually becomes a legitimate request (and unlike now where we can say "Well
{{deploy}} implies {{install}} so please don't do that) we may find that we
have users crawling out of the woodwork with more exotic use cases.
> Either install or deploy
> ------------------------
>
> Key: MNG-5667
> URL: https://issues.apache.org/jira/browse/MNG-5667
> Project: Maven
> Issue Type: Sub-task
> Components: FDPFC, Plugins and Lifecycle
> Reporter: Robert Scholte
> Assignee: Robert Scholte
> Priority: Major
>
> Original proposal
> {quote}
> PROPOSAL 2: Either install or deploy
> In general one should either run 'mvn verify' or 'mvn deploy', there's often
> no reason to run 'mvn install'. The only reason I can think of is when you
> have 2 separate projects (not part of the same multimodule), one depending on
> the other and you want to test this.
> To ensure that your projects build the same as your co-workers, you should
> always try to deploy it. However, there are several reasons why a deploy
> could fail: network problems, authentication/authorization issues, repository
> manager policies, etc. However, this is still after every install-phase, so
> the local repository is polluted.
> This is as unpleasant as for a developer local repository as for a CI-server
> local repo.
>
> The proposal is to "branch" the final phases.
> Calling any phase up until the verify will stay the same.
> Calling 'mvn install' would call these phases: validate ... verify, install
> (nothing new here)
> Calling 'mvn deploy' would call these phases: validate ... verify, deploy
> (no more install)
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
