Change build pom naming from xxx-build.pom to xxx-build-pom.xml

[gnodet]

Following this checklist to help us incorporate your
contribution quickly and easily:

• Make sure there is a JIRA issue filed
  for the change (usually before you start working on it). Trivial changes like typos do not
  require a JIRA issue. Your pull request should address just this issue, without
  pulling in other changes.
• Each commit in the pull request should have a meaningful subject line and body.
• Format the pull request title like [MNG-XXX] SUMMARY,
  where you replace MNG-XXX and SUMMARY with the appropriate JIRA issue.
• Also format the first line of the commit message like [MNG-XXX] SUMMARY.
  Best practice is to use the JIRA issue title in both the pull request title and in the first line of the commit message.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Run mvn clean verify to make sure basic checks pass. A more thorough check will
  be performed on your pull request automatically.
• You have run the Core IT successfully.

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004

• In any other case, please file an Apache Individual Contributor License Agreement.

[michael-o]

This does not look wrong. What is the motivation behind this? How will the attached artifact looked like if then main POM is still foo.pom?

[gnodet]

This does not look wrong. What is the motivation behind this?

The problem seems to be that sonatype oss release validation fail staging repositories deployed with Maven 4. The issue is there is now more than one .pom file in the repo.

How will the attached artifact looked like if then main POM is still foo.pom?

foo-build-pom.xml ?

[michael-o]

This does not look wrong. What is the motivation behind this?

The problem seems to be that sonatype oss release validation fail staging repositories deployed with Maven 4. The issue is there is now more than one .pom file in the repo.

That really feels like fixing the symptom...

How will the attached artifact looked like if then main POM is still foo.pom?

foo-build-pom.xml ?

This names is reasonable since it is the original one with a classifier. Does foo.build-pom makes sense, too?

[gnodet]

This does not look wrong. What is the motivation behind this?

The problem seems to be that sonatype oss release validation fail staging repositories deployed with Maven 4. The issue is there is now more than one .pom file in the repo.

That really feels like fixing the symptom...

It is. Maybe we should just do nothing and let Sonatype fix on their side ?

How will the attached artifact looked like if then main POM is still foo.pom?

foo-build-pom.xml ?

This names is reasonable since it is the original one with a classifier. Does foo.build-pom makes sense, too?

Yes, I don't have a clear opinion. I wonder if the - in build-pom used as a classifier could cause parsing problems, as - is used to separate the artifactId from the classifier in foo-build-pom.xml... Is that why you suggested foo.build-pom ?

I think the best would still be the current state, i.e. foo-build.pom ...

[michael-o]

This does not look wrong. What is the motivation behind this?

The problem seems to be that sonatype oss release validation fail staging repositories deployed with Maven 4. The issue is there is now more than one .pom file in the repo.

That really feels like fixing the symptom...

It is. Maybe we should just do nothing and let Sonatype fix on their side ?

this is also my expectation...

I think the best would still be the current state, i.e. foo-build.pom ...

I also agree on this one.

[michael-o]

@brianf, can you help?

[rmannibucau]

+1 to fix the name on our side

rational is:

• ensure we don't break tools getting the pom with a ls *.pom (sonatype is not the single one probably since it was our way to do)
• ensure we use the right extension to avoid to hack editors when opening the file (.pom is not supported everywhere but .xml seems to be more common)
• avoid to make it look too much like a consumer thing cause this version will be more fragile than default one (maven version dependent)