Howdy, I cannot reproduce any of the issues you linked, moreover all the other issues are IMHO non reproducible with m-install-p 3.0.1 and m-deploy-p 3.0.0.
There is ONE issue that still stands, and it is the one you mention: when m-install-p/m-deploy-p is not part of a module build at all, but IMHO is simple fix. No need for any magic, fix is almost trivial... T On Wed, Oct 19, 2022 at 11:22 PM Slawomir Jaranowski <s.jaranow...@gmail.com> wrote: > I'm. > > In plugins each processed module are marked with one of flags: SKIPPED, > INSTALLED, TO_BE_INSTALLED or SKIPPED, DEPLOYED, TO_BE_DEPLOYED > > And finally we check if all modules have a flag set to detect end of > session in method allProjectsMarked > But if one module not used install / deploy plugins at all - nothing will > be installed / deployed. > > To reproduce - in multimodule project - bind install / deploy plugin to > none phase in one of modules. > > > > śr., 19 paź 2022 o 22:59 Tamás Cservenák <ta...@cservenak.net> napisał(a): > > > Slawek, > > > > Are you sure those issues still stand for 3.0.x of plugins? > > > > T > > > > > > On Wed, Oct 19, 2022, 22:07 Slawomir Jaranowski <s.jaranow...@gmail.com> > > wrote: > > > > > Hi, > > > > > > I'm looking for how to resolve issues connected with the feature > > > installAtEnd / deployAtEnd of install and deploy plugins. > > > > > > We have a similar feature in clean plugin where it is implemented by > > > wrapping session.getRequest().getExecutionListener() [1] > > > Because ExecutionListener on request is not chained by default it will > be > > > difficult implement the next wrappers in two plugins. > > > > > > In current implementation we assume that install or deploy plugins are > > > executed in all modules, > > > but it can not be true e.g. one module can use different packaging > > > which doesn't have those plugins in their lifecycle > > > so detecting the last executing module does not work. > > > > > > We can also have skipped or not used install / deploy plugins in the > last > > > executed module. > > > > > > I'm thinking of using AbstractMavenLifecycleParticipant to detect the > end > > > of a Maven session and to finish the job in afterSessionEnd callback. > > > > > > But in this way I see another issue - > > > AbstractMavenLifecycleParticipant.afterSessionEnd method is called > after > > > session.request.ExecutionListene which prints a summary of whole build, > > > so we have additional tasks not computed in the build summary - Can it > be > > > accepted? > > > > > > I don't have a sure which callback method will be called first from > > install > > > or from deploy plugin. > > > So we can have a situation where deployment will be executed first. > > > Can it be accepted? > > > > > > Of course when we will use the AbstractMavenLifecycleParticipant plugin > > > must be configured as an extension - but it is not an issue I think. > > > > > > Any other suggestions ... > > > > > > Some of related issues: > > > https://issues.apache.org/jira/browse/MINSTALL-102 > > > https://issues.apache.org/jira/browse/MDEPLOY-226 > > > > > > [1] > > > > > > > > > https://github.com/apache/maven-clean-plugin/blob/master/src/main/java/org/apache/maven/plugins/clean/Cleaner.java#L514-L527 > > > > > > -- > > > Sławomir Jaranowski > > > > > > > > -- > Sławomir Jaranowski >
