apache
[MDEPLOY-118] - Enable deployment of attached release artifacts if POM is identical
See MDEPLOY-118 for motivation.
The challenge was to reliably retrieve the POM from the deployment repository. In order to be
fully compatible with what Maven usually does, org.eclipse.aether.RepositorySystem has to be used.
However, that only offers the method resolveArtifact (and similar), which provides artifacts in the
local repository, does not offer the possibility to specify an alternate location and possibly never even
retrieves them from the remote repository, if present in the local repository.
The solution was to use an alternate local repository via a clone of the RepositorySystemSession just
to resolve the wanted POM into it.
The comparison is done on the level of the XML Model. This was done mainly to address the "platform-dependent line-break concerns" mentioned in the issue. Alternatives are possible but this seems to be the one most appropriate for a POM.
=======================
Following this checklist to help us incorporate your contribution quickly and easily:
- [x] 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.
- [x] Each commit in the pull request should have a meaningful subject line and body.
- [x] Format the pull request title like
[MPH-XXX] - Fixes bug in ApproximateQuantiles, where you replaceMPH-XXXwith the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
- [x] Run
mvn clean verifyto make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (
mvn -Prun-its clean verify).
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.
-
[x] I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004
-
[x] In any other case, please file an Apache Individual Contributor License Agreement.
Thanks for the first workflow run. A non-JAR-file in a target directory within the unit-tests was missing due to ignore rules. Added it with my last force-push.
I think, I am done now. Let me know if anything is missing or needs to be done differently!
Otherwise, I am patiently awaiting a successful workflow run, merge, and new release of the plugin. 😇
@cstamas Could you please approve the workflow run so I might be able to fix remaining issues?
@elharo, I rebased my branch onto current master. Could you, please, approve the workflow run?
Sorry for slow response. I must have overlooked the email.
Is there any chance for this to be merged any time soon? In that case, I would try to find the time to resolve the current conflicts.
It can be considered. I'm personally not sure this is a good idea. This seems like it might break some Maven repos stare decisis properties. It's generally not possible to change an artifact after it's been uploaded, and that's worth keeping. The two questions I have are:
- Is adding a new file a "change" in this sense?
- Does this patch allow not just adding but replacing existing files with something different?
Thanks, @elharo, for the quick response!
I ran into the problem described in #MDEPLOY-118.
I think, I implemented this in a way, that current behavior of the plugin is unchanged if no additional parameters are set. If the feature is enabled, artifacts are still never overwritten. Only additional artifacts are attached to an existing POM.
To your questions:
- How else would it be possible to deploy something built on several platforms?
- Replacing was done be the deploy plugin before - unless repos prohibited it. Now, the plugin can add artifacts, while the repo ensures, existing artifacts (including the POM) are never changed.
I guess I kinda asked my question at the wrong time for my schedule. Sorry. If you would be interested in more discussion and an eventual merge, I would try to find time for the conflicts, more questions and fixes in about a week from now. I guess, I need to have a closer look myself after such a long time.
Ideally things wouldn't be built on several platforms but if they were, the binaries could be copied from one machine to another before deployment. As soon as a build process involves different machines and OS's, I don't see anyway to avoid assembling files from several machines. The only question is whether you do it before the one and only deployment, or piece by piece as different machines upload to the repo. I can see why we might want to insist that a single bundle is provided to the repo once, rather than adding to it over time.
Could you explain, why you might want to insist?
In the company I was doing this for, it is regular practice to publish artifacts for the same version for additional platforms when needed. (...and when build hosts became available.) Building a new version possibly from a stability branch every time some minor RHEL version when some user needed it would be quite impractical for them.
Probably worth discussing on the dev list to see what everyone thinks. Maven has gotten a lot of mileage out of the principle that an "artifact" is uniquely identified by coordinates, without any time dependence.
CVEs and their possible additional artifacts to a maven coordinate would be a great benefit.
Not sure what CVEs has to do with anything. We absolutely do NOT want to address CVEs with the same pom.xml. A fix for a CVE should and MUST have a new version so it can be clearly distinguished which version is in use and whether it's vulnerable or not.
Not sure what CVEs has to do with anything. We absolutely do NOT want to address CVEs with the same pom.xml. A fix for a CVE should and MUST have a new version so it can be clearly distinguished which version is in use and whether it's vulnerable or not.
Well, how do you want to mark a CVE in the original problematic coordinate? Why don't we mark a coordinate vulnerable if it is? I agree with the fixing version, that has to be a new coordinate
Hey @elharo, thanks for your review. Can I assume you would agree to a merge, when I fix these issues and resolve the conflicts? I will not have the time for that in the next weeks, but maybe over the summer, though.
No, do not assume that. No one has approved this yet, and there does not seem to be agreement that this feature is desirable.
