[HUDI-1597] remove deprecated spring repos from pom

[caidezhi]

• maven build fail as spring repo no longer support anonymous download of 3rd-party Maven Central artifacts from repo.spring.io. backport the fix from master branch.

Tips

• Thank you very much for contributing to Apache Hudi.
• Please review https://hudi.apache.org/contributing.html before opening a pull request.

What is the purpose of the pull request

remove deprecated spring repos from pom

Brief change log

remove deprecated spring repos from pom.xml

Verify this pull request

(Please pick either of the following options)

This change added tests and can be verified as follows:

• run maven build successfully

Committer checklist

• Has a corresponding JIRA in PR title & commit

• Commit message is descriptive of the change

• CI is green

• Necessary doc changes done or have another open PR

• For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

[yanghua]

@caidezhi Hi, thanks for your contribution. It seems you opened many same PRs, right?

[caidezhi]

@caidezhi Hi, thanks for your contribution. It seems you opened many same PRs, right?

hi @yanghua , multiple branches have the same problem ( 0.7.0, 0.6.0, 0.5.3, 0.5.2 , 0.5.1). each pull request backport the fix to the different branch. please let me know, if it is not the right way to do this. Many thanks.

[yanghua]

@caidezhi Hi, thanks for your contribution. It seems you opened many same PRs, right?

hi @yanghua , multiple branches have the same problem ( 0.7.0, 0.6.0, 0.5.3, 0.5.2 , 0.5.1). each pull request backport the fix to the different branch. please let me know, if it is not the right way to do this. Many thanks.

IMO, we only change the code hosted in the master branch, the old released branches are immutable. But, hold on, let @vinothchandar chime in, keep these PRs there.

[vinothchandar]

@yanghua in general yes, we only support real fixes on master. but I see the point here, that if we dont do these PRs, the older releases are not buildable anymore. So anyone trying to patch things on top of older releases all have this issue.

So may be actually good to do this? I don't know what typically is done here. We are not going to release new artifacts or alter any tags, for older releases, but updating the release branches should be okay?

cc @bvaradar @n3nash @nsivabalan as well. any body have ideas on how we proceed generally.

cc @danny0405 also given you might have prior experience with situation like this

[yanghua]

My thought:
The released artifacts are official and verified, and should not be changed. The current problem does not affect users to obtain and run related artifacts from the Maven public repository.

If we need to fix an earlier issue like this, we should release some minor versions on the corresponding release branch. Similar to 0.x.1 or 0.x.2.

[vinothchandar]

Doing a release for each of these versions is not a good use of time IMO.

To be clear, I am not suggesting mutating the release (thats not a thing anyway). I was merely talking about adding the commit to older release branches.

How about we just add a section on the README about Building Older Releases with this pom change? That way people who want to build releases can manually apply and build locally. Most of all, I would love to understand how other projects do it, before we make a call.

[caidezhi]

AFAIK, backport some fix to older release branches is very common in other project (eg: apache flink ).
Adding a section on the README may be a choice, but older release branches will not be buildable until the users notice the section and modify the pom.xml themselves. It may give some surprise to some users (eg: myself ). :)

[yanghua]

AFAIK, backport some fix to older release branches is very common in other project (eg: apache flink ).
Adding a section on the README may be a choice, but older release branches will not be buildable until the users notice the section and modify the pom.xml themselves. It may give some surprise to some users (eg: myself ). :)

Yes, it's true in Flink. We can see that the release branch can still be evolved after some major branch release. While the minor release tag would be immutable.

@vinothchandar What I mean is that whether we need to freeze the more changes via releasing a minor branch. And tell users we would not maintain these versions after we fix the pom issues. Of cause, we can just backport the released branch and let it go.

[vinothchandar]

What I mean is that whether we need to freeze the more changes via releasing a minor branch.

definitely the cleaner approach. but not sure if the time is worth investing in, to re-release 0.5.3.1, 0.6.0.1 etc. All of them need to run validation, voting, etc. :(

if these sort of fixes are accepted in other large projects, we can follow suit and land the PRs. So the release branches are buildable again.

[yanghua]

What I mean is that whether we need to freeze the more changes via releasing a minor branch.

definitely the cleaner approach. but not sure if the time is worth investing in, to re-release 0.5.3.1, 0.6.0.1 etc. All of them need to run validation, voting, etc. :(

if these sort of fixes are accepted in other large projects, we can follow suit and land the PRs. So the release branches are buildable again.

Maybe 0.5.4 not 0.5.3.1? The simplest and rude way is not to freeze, just pick the commit into the relevant release branch.

[vinothchandar]

@yanghua lets make a call here and move on.

My vote is for just merging these PRs and not do the new versions. The existing artifacts are out there already.

[yanghua]

My vote is for just merging these PRs and not do the new versions. The existing artifacts are out there already.

+1 for only merging the commit.

[vinothchandar]

@caidezhi Thanks for your patience. It took us a while to sort this out, given this is the first time we faced somethign like this.

We deeply appreciate your initiative!