[
https://issues.apache.org/jira/browse/MNG-5667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16626268#comment-16626268
]
Robert Scholte commented on MNG-5667:
-------------------------------------
Thanks for these usecases. In general I see that we agree that the install with
deploy should be improved, but in a way that mentioned cases still work.
UC1: If these artifacts are part of the reactor, there should be no issue,
right? However, if these are modules from a multimodule project but not part of
the reactor, you have the issue. This demonstrates my main reason why the
finalName should be removed from plugin configuration. This should open
possibilities for improvements regarding multimodule projects. One idea: Maven
should have the option to collect all modules as artifacts, using
project.build.finalName as the default filename. This way those dependencies
are not pulled from the local repository but from the latest full reactor build.
Not sure if this usecase fits another proposal, but I'm also thinking about
(maven) module-support for non-poms. In short: if a jar-packaged pom has
modules, all those modules won't be installed, but will be merged in this main
jar. This idea was confirmed by [~sanne] who had a usecase with Hibernate for
it.
Another thing I need to reconsider: should we still assume that the
"deploy"-phase should be called on every module, or should we decide per module
if it should stop earlier during the lifecycle?
UC2: To me this looks like a library versus application issue. If you consider
repositories are dependency caches, then why do you store application here? In
your case, how did you get your ISO image? From local repo? From remote repo?
Both look weird to me, I would expect from target or some other process pushing
it to some location.
UC3: Right, I'd say the new {{mvn clean install deploy}} is the old {{mvn clean
deploy}} and we can explain quite well why.
> 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)
