2 ms·
Or do some work to rid yourself of the logic in the build. Fit the build process into the build tool, rather than try to contort the build tool to suit the pro
by chii 2y ago
Or do some work to rid yourself of the logic in the build.
Fit the build process into the build tool, rather than try to contort the build tool to suit the project. After all, it's unlikely that the project is such a special snowflake that it needs custom build steps, rather than just rely on the standard build steps provided in maven.
- twic 2y agoIt's not at all unlikely. Most large projects i've worked on have need some element of custom building. Generation of files, compiling native code, multiple separate test suites, etc. The Gradle developers didn't just add that flexibility because they felt like it, there's a genuine need that Maven does not meet.
- SOLAR_FIELDS 2y agoYeah. I think it is tempting to overload Gradle however. It runs bash and can build oci images and call other languages, which is fine in theory, but in practice it turns out to be quite limiting and full of complex pitfalls. The best setups I’ve worked with let other tools build non JVM stuff and leave Gradle to compile and test the JVM stuff only, because that is what it is good at.
- chii 2y ago> a genuine need that Maven does not meet. i really fail to believe that tbh. Making a maven plugin, in the worst case, works. The flexibility of gradle (or any other procedural build tools) is to make the project _easy_ to customize, which means the tool encourages it. Maven deliberately forces _all_ builds to conform to their set of phases, and assign meaning to each phase. If you're coming in fresh to a project, it's easy to see what phases are being attached to, and guess what's being done without having to have intimate understanding of the actual work.