Enable publishing of incremental builds

[basil]

The intended use case of this is to be able to more easily test PR builds of this repository in realistic use cases, albeit with the additional effort of adding a custom <repository>.

Testing done

Compared the differential between the partially flattened (new) https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/plugin/4.50-rc1383.e2d11257662a/plugin-4.50-rc1383.e2d11257662a.pom and the unflattened (old) https://repo.jenkins-ci.org/public/org/jenkins-ci/plugins/plugin/4.49/plugin-4.49.pom and did not see anything of concern. I encourage reviewers to look at this differential for themselves. The only changes seem to be that properties seem to be in a random order (probably going through some HashMap internally somewhere) and the elements of the POM have been re-ordered according to the POM Code Convention (which we could re-order in the main branch if we wanted to reduce the diff even further).

Verified that I could successfully consume the resulting incremental build in Text Finder plugin by running mvn clean verify -DskipTests with

diff --git a/pom.xml b/pom.xml
index 9e32894..e7acdfc 100644
--- a/pom.xml
+++ b/pom.xml
@@ -4,7 +4,7 @@
     <parent>
         <groupId>org.jenkins-ci.plugins</groupId>
         <artifactId>plugin</artifactId>
-        <version>4.49</version>
+        <version>4.50-rc1383.e2d11257662a</version>
         <relativePath />
     </parent>
 
@@ -104,6 +104,13 @@
             <id>repo.jenkins-ci.org</id>
             <url>https://repo.jenkins-ci.org/public/</url>
         </repository>
+        <repository>
+            <snapshots>
+                <enabled>false</enabled>
+            </snapshots>
+            <id>incrementals</id>
+            <url>https://repo.jenkins-ci.org/incrementals/</url>
+        </repository>
     </repositories>
 
     <pluginRepositories>

[jglick]

See #462. I was nervous about enabling JEP-305 on this repo, but mainly it just needed testing.

[jglick]

I wonder if upstream https://www.mojohaus.org/flatten-maven-plugin/flatten-mojo.html#flattenMode could use a new value, or is our usage just sufficiently weird to not be of interest to anyone else?

[basil]

I doubt anyone else would want to use this particular configuration.

[jglick]

Could probably be dropped since I guess we do not expect this profile to ever be used inherited, only locally.

[basil]

But that would increase the differential between this profile and the copypasta from which it originated, for no good reason I think. Better to keep all copies of this code as similar as possible I think.

[jglick]

Fine but why not enable CD then? The only reason to hold off was the fear of regressions from incrementalification, not CD per se.

[basil]

I am not a fan of the version numbers used in JEP-229 releases.

[jglick]

🤷 well if this change is released and seems to cause no problems, I will propose CD at some point since the POMs are the last major thing that we have to release manually (Jenkins core being handled specially), and as developer-only artifacts their version aesthetics should be of the least concern.

[basil]

I should have mentioned that I am not a fan of JEP-229 more generally. The labeling scheme and automatically generated change logs have long been a source of frustration for me. If I have the choice between using JEP-229 and avoiding it, I will choose to avoid it.

[jglick]

automatically generated change logs

I am confused by that comment in this context, as we already do the same in this repository:

plugin-pom/.github/workflows/release-drafter.yml

Lines 11 to 15 in 7a900a5

	update_release_draft:
	runs-on: ubuntu-latest
	steps:
	# Drafts your next Release notes as Pull Requests are merged into the default branch
	- uses: release-drafter/release-drafter@v5

Anyway this is getting off topic; assuming that the testing done for this PR was sufficient, it seems like a clear benefit even while keeping the MRP flow. (On occasion I had tested against timestamped snapshots for proposed POM updates but it gets ugly.)

[jglick]

Anyway, seems fine so far.

[jglick]

@basil other than the merge conflict, is there anything holding this back?

[basil]

Just additional testing and hesitance to move forward with this given your intent to subsequently enable JEP-229 (which I prefer to avoid).

[jglick]

hesitance to move forward with this given your intent to subsequently enable JEP-229

That is an independent consideration. Enabling JEP-229 would simply be a subsuming PR. If you would block that, then I would not bother filing it to begin with.

[basil]

I would not block it, but ultimately it is a maintainer decision so I think it should be made by whoever is most actively maintaining the repository.