Miscellaneous updates

[ctubbsii]

• Update maven build to use revelc prefixed property name for formatting profiles in the parent POM
• Drop the sonatype deploy snapshot configuration (not needed and not safe to use personal individual credentials on a shared repository this way - personal secrets still need to be deleted from the GitHub repository); discussed on [mvn] Change the name from 'ossrh' to 'sonatype-nexus-snapshots' (leg… #889
• Re-drop autogenerated CHANGELOG file and related README in favor of adding a link to the milestone or full changeset in the GitHub release notes; discussion on Please use change log or github releases #844
• Bump snapshot version to 2.25.0 and update the compatible Eclipse version in the site documentation
• Add missing scm section (Cannot release downstreams due to no scm data revelc#12)
• Drop site-specific distributionManagement section and related scmpublish plugin settings (those can be run manually entirely from the command-line with command-line parameters, if needed, but it shouldn't be necessary if the GitHub plugin defined in the site-deploy phase of the site lifecyle is used, as defined in the parent POM); discussed on [pom] Site still did not release, add scm data to allow it to occur #905
• Revert to using stable versions of maven site plugin and Fluido skin, defined in the parent POM, rather than override here (when these get stable releases, the parent POM can be updated, and then the site descriptor will need to be updated, but for now, these can use the latest stable versions)
• Add dependencyConvergence rule to the build, and exclude conflicting transitive dependencies, in order to affix them to specific versions (some of this might not be needed once some of the other plugins start doing dependency convergence also, like xml-formatter and jsdt-core)
• Make sure slf4j-api is marked as provided (address concerns from [tests] Add slf4j-simple to tests to clear warnings and correct jcl version to 1.7.36 #846) It would be easier if we could converge on what maven-core or maven-plugin-api uses, but those dependencies are opaque to us, so we just have to assume it's provided and compatible with what we're using; slf4j has a high degree of compatibility, though, so this shouldn't be much of a concern
• Drop plexus-xml dependency (we don't use it, and the one that comes with plexus-resources is fine with Maven 3); see comment on [pom] Use plexus xml 3.0.0 or we lose maven 3 support #851

[ctubbsii]

I'm not sure what exactly is the error on the Windows builds. I didn't change anything that would affect that. Also, the build fails for me locally in Linux, so I'm not sure what's going on with that. There seems to be something unrelated going on.

[ctubbsii]

I spent some time working on the apilyzer-maven-plugin, and I think I have a handle on some of the windows-related issues now, but I have some other priorities this week and I'm going to be on vacation next week. So, I might not be able to get to this right away. My ultimate goals are to make sure that:

1. All tests pass on Linux, MacOS, and Windows
2. Release profile ensures that the release is reproducible byte-for-byte from the tag (meaning, no line ending changes on any release artifacts)
3. GitHub Actions warns us about any misformatted files (but doesn't warn excessively when it checks out the project on Windows)

However, since I don't actually have a Windows machine to test things locally, there are likely going to be continued hiccups.

[hazendaz]

Thanks @ctubbsii Other than windows issue, LGTM.

I'm getting the same issue with windows. I'm on windows 11. The file line endings get changed. Its empty otherwise.

I'm at a loss as well for why it works on main now and this change causes failure. But my local does show that file touched every time I build. Sortpom is causing it though.

[ctubbsii]

@hazendaz Okay, I made substantial progress making it more friendly to build on both Windows and Linux. The only thing it doesn't have is build reproducibility for releases across platforms, because the project files are still going to change based on which platform you check it out, so that means the contents of the jar is going to change. But that's a problem for another day (and really, it's just a wishlist item anyway).

Since the last time you looked:

1. I fixed the problem with sortpom (there's a property you can set to make it ignore line endings when checking if the file changed)
2. I fixed the problem with the tests... two of the test files had wrong line endings (git hid this information from me when it did the conversion). I made updated the .gitattributes file to make git treat all the test resource files as if they were binary (but still show diffs), so it wouldn't mangle any line endings. That's a bit more work on our part to make sure they have the right endings when we check them in... but after that git won't change them on its own, which was the real problem.

Now that everything is passing again, and should be in a state that we can both contribute without mangling things for the other, I'm going to go ahead and merge this. There might be a few things that can still be tweaked, but I think this is major progress. Now I understand better what is going on, I can troubleshoot and fix the problems better when they happen.