search

fedora-java / javapackages

Macros and scripts for Java packaging support
Other
7 stars 15 forks source link

Possible to automate some maven plugin disabling? #70

Closed mbooth101 closed 4 years ago

mbooth101 commented 5 years ago

I have a bunch of specfiles that do this kind of thing, because IMO these plug-ins are never relevant for RPM builds:

# Version of Java and bytecode level is always fixed in distro, disable for RPM build
%pom_remove_plugin ":animal-sniffer-maven-plugin"
%pom_remove_plugin ":maven-enforcer-plugin"
# Static analysis and code style is upstream's business, disable for RPM build
%pom_remove_plugin ":findbugs-maven-plugin"
%pom_remove_plugin ":spotbugs-maven-plugin"
%pom_remove_plugin ":maven-checkstyle-plugin"
%pom_remove_plugin ":maven-pmd-plugin"
# Code coverage is upstream's business, disable for RPM build
%pom_remove_plugin ":jacoco-maven-plugin"
%pom_remove_plugin ":coveralls-maven-plugin"
%pom_remove_plugin ":cobertura-maven-plugin"
# Cannot code sign in downstream builds, disable for RPM build
%pom_remove_plugin ":maven-gpg-plugin"
# Cannot push artifacts to nexus server, disable for RPM build
%pom_remove_plugin ":nexus-staging-maven-plugin"

Can we automatically black-list these plug-ins so we don't have every specfile disabling the same stuff?

mizdebsk commented 5 years ago

Idea: introduce %mvn_prep macro that would remove these plugins. In future it could be extended to do other cleanup (such as removal of bundled *.class etc.) What do you think?

mbooth101 commented 5 years ago

Interesting. What if %mvn_build could do it to avoid introducing another macro? Doing it at the start of %build has the same net effect as doing it at the end of %prep...

mizdebsk commented 5 years ago

I would prefer if modification of POM files was done before %build section - this way you can examine contents of POM files used during build, or short-circuit rpmbuild phases.

Alternative approach that doesn't require adding extra macro calls to spec files would be to dynamically modify Maven model without modifying POM files on disk. This approach is already used by XMvn, for example to remove test dependencies when %mvn_build is called with -f. See customizeModel() method of XMvnModelValidator. That method could be extended to remove blacklisted plugins or even dependencies, based on configuration.

mbooth101 commented 5 years ago

Alternative approach that doesn't require adding extra macro calls to spec files would be to dynamically modify Maven model without modifying POM files on disk. This approach is already used by XMvn, for example to remove test dependencies when %mvn_build is called with -f. See customizeModel() method of XMvnModelValidator. That method could be extended to remove blacklisted plugins or even dependencies, based on configuration.

Hmm, I like this way even more...

mizdebsk commented 5 years ago

@mbooth101 Please review PR #71 - it adds a global list of plugins which will be dynamically removed from Maven model during build, without modifying POM files on disk. If this looks good then I'll merge it.

mbooth101 commented 5 years ago

@mbooth101 Please review PR #71 - it adds a global list of plugins which will be dynamically removed from Maven model during build, without modifying POM files on disk. If this looks good then I'll merge it.

Yeah that looks correct to me

mbooth101 commented 5 years ago

@mbooth101 Please review PR #71 - it adds a global list of plugins which will be dynamically removed from Maven model during build, without modifying POM files on disk. If this looks good then I'll merge it.

Actually I have one more addition:

apache-rat-plugin should also be always ignored