maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MNG-5667) Either install or deploy
Date Mon, 24 Sep 2018 18:59:00 GMT

    [ 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)

Mime
View raw message