Hey Lee, You might find this PR useful, it is where we Apache-fied the Druid POM: https://github.com/apache/incubator-druid/pull/6482. It helps highlight the specific areas that are relevant to Apache-fying a build.
Also, it is more work upfront, but you might find that in the long run, you enjoy switching the project to a single repo with a multi-module Maven build. We do this in Druid and it works quite well. It makes it way easier to do patches and releases that span multiple modules. > So it seems that eventually, either we need to go whole hog having Maven do > everything, which seems overly complicated, or consider moving to Gradle > (which I am not familiar with either, but it seems lots of teams are moving > that way). Definitely doing as much as possible in the build system (whether Maven or Gradle) is a good thing, IMO, since they tend to reward living in their worlds. Also the more verifications you can push into the build tool, the better. In Druid we have also been considering moving to Gradle: https://github.com/apache/incubator-druid/issues/7866. However we are still using Maven for now and may be for some time to come, since it seems the benefits of switching to Gradle are definitely noticeable, but not huge. > - It doesn't appear that the Nexus artifacts require a GPG signature only > the DIST assembly requires GPG, which the script is handling. So why do we > need the gpg-plugin? IIRC it's because Sonatype's Central Repository (where the Maven-ready artifacts ultimately end up) requires GPG signatures. > - It is not clear to me when a profile should be used (e.g., for deploy) vs > using the deploy process as part of the pom main build lifecycle. I've found profiles to be most useful when you want something like "mvn package" to do different things based on a profile. e.g. having a profile to apply strict checks that takes extra time, having a profile to build extra assemblies, etc.
