add `compile` goal to combine `assemble` and `verify`

[volodya-lombrozo]

I have some concerns related to the implementation of VerifyMojo and the 205 in eoc issue.

It seems that we added a new mojo to the compilation process as an additional mandatory step, which broke eoc entirely (and maybe something else?). This is a clear indicator of a problem in the architecture.

Why did this happen? The answer is simple – we violate encapsulation by exposing all the internal compilation steps to everyone outside. This is extremely dangerous. I would suggest leaving only one mojo (e.g., CompileMojo) and placing all the internal steps inside it. In this case, we will have the freedom to change internal compilation steps without altering high-level components that depend on this mojo.

[volodya-lombrozo]

@yegor256 @maxonfjvipon , please, take a look.

[yegor256]

@volodya-lombrozo this was the intention of assemble mojo - to put all necessary mojos into one. We can also create compile mojo, which will be even larger. Everything that is needed for compilation will fit into it. We do need to let users use smaller mojos, I believe, mostly because there are many more scenarios of using our plugin that just compilation.

[maxonfjvipon]

@volodya-lombrozo I like the idea about CompileMojo, let's do it

[yegor256]

@maxonfjvipon maybe there is a Maven plugin that can take a list of mojos and, in compile time, generate a synthetic new mojo and place it into target/generated-sources? Creating such a CompileMojo would be a rather boring task: we will need to make sure all params are shared between this new mojo and all sub-mojos that it will call (similar to what AssembleMojo is doing). If such a plugin doesn't exist, let's do it manually, of course.

[volodya-lombrozo]

@yegor256 Do you know where I can find more examples of how we can use all these separate mojos? It would be useful to see all the use cases.

Anyway, keeping many different mojos seems a bit strange to me. Let me provide a different analogy. Usually, in a simple Java program, we use the public static void main(String… args) method as an entry point for the program. This method is similar to a mojo, where a mojo serves as the entry point for a Maven plugin. We don’t usually create 1..N main methods for each use case, do we? Instead, we create a single main method and provide many different arguments.

Another issue with mojos is testing. Let’s be honest. Each time we use FakeMaven in tests, we are actually performing integration testing, which significantly decreases compilation time. Currently, we use it to test all test cases, but it would be better to test only the important paths using FakeMaven and cover all the corner cases with unit tests. Unfortunately, we can’t simply add unit tests for mojos because it is a flaw in the Maven mojo architecture.

I’m not suggesting that we should put all the logic in one class. No. I propose having a single entry point (CompilationMojo) that will use many other classes (VerifyCompilationStep, PullCompilationStep, AssembleCompilationStep, and so on), which will be POJOs that we can cover with unit tests much more easily.

[yegor256]

Do you know where I can find more examples of how we can use all these separate mojos?

@volodya-lombrozo of course, they are used separately in the eoc command line tool. There are compile, parse, and other commands. They would not work if we would have only one compile goal in eo-maven-plugin

[levBagryansky]

@yegor256 Now in other repos do we just add VerifyMojo to pom.xml or waiting for the closing of this issue?

[yegor256]

@levBagryansky verify is a mandatory step, that must go after the assemble. If you skip verify, the pipeline will break. We may (still thinking about this) add a new compile goal that will enclose assemble+verify