Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MDEPLOY-118] - Enable deployment of attached release artifacts if POM is identical #28

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

mdrie
Copy link

@mdrie mdrie commented Sep 27, 2022

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:

  • 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 [MPH-XXX] - Fixes bug in ApproximateQuantiles,
    where you replace MPH-XXX with 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.
  • 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 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.

@mdrie mdrie changed the title WIP: [MDEPLOY-118] -: Untested first implementation. WIP: [MDEPLOY-118] - Untested first implementation. Sep 27, 2022
@mdrie mdrie force-pushed the MDEPLOY-118 branch 2 times, most recently from ccb1794 to 703652a Compare September 29, 2022 14:22
@mdrie mdrie changed the title WIP: [MDEPLOY-118] - Untested first implementation. [MDEPLOY-118] - Enable deployment of attached release artifacts if POM is identical Sep 29, 2022
@mdrie
Copy link
Author

mdrie commented Sep 29, 2022

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.

@mdrie mdrie marked this pull request as ready for review September 30, 2022 09:18
@mdrie
Copy link
Author

mdrie commented Sep 30, 2022

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. 😇

@mdrie
Copy link
Author

mdrie commented Oct 6, 2022

@cstamas Could you please approve the workflow run so I might be able to fix remaining issues?

Copy link
Contributor

@elharo elharo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you can merge with the latest changes at head and ping me, I can approve the workflow run.

@mdrie
Copy link
Author

mdrie commented Dec 20, 2022

@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.

@mdrie
Copy link
Author

mdrie commented May 17, 2023

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.

@elharo
Copy link
Contributor

elharo commented May 17, 2023

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:

  1. Is adding a new file a "change" in this sense?
  2. Does this patch allow not just adding but replacing existing files with something different?

@mdrie
Copy link
Author

mdrie commented May 17, 2023

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:

  1. How else would it be possible to deploy something built on several platforms?
  2. 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.

@elharo
Copy link
Contributor

elharo commented May 17, 2023

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.

@mdrie
Copy link
Author

mdrie commented May 17, 2023

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.

@elharo
Copy link
Contributor

elharo commented May 17, 2023

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.

@mdrie
Copy link
Author

mdrie commented May 23, 2023

Done. Hope my wording makes sense to you.

@KemalSoysal
Copy link

CVEs and their possible additional artifacts to a maven coordinate would be a great benefit.

@elharo
Copy link
Contributor

elharo commented May 23, 2023

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.

@KemalSoysal
Copy link

KemalSoysal commented May 23, 2023

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

@elharo
Copy link
Contributor

elharo commented May 23, 2023

CVEs are not tracked in the repo.

@KemalSoysal
Copy link

CVEs are not tracked in the repo.

yes, that is unlucky

import org.codehaus.plexus.util.*;

File file = new File( localRepositoryPath, "org/apache/maven/its/deploy/comparepom" );
System.out.println( "Deleting " + file );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You shouldn't need to print debug messages in tests.

FileUtils.deleteDirectory( file );

file = new File( basedir, "repo" );
System.out.println( "Deleting " + file );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

delete

LogInspector li = new LogInspector( buildLog )
String groupUrl = "file:///${basedir}/repo/org/apache/maven/its/deploy/comparepom"

// 1st and 2nd run: The POM tried to be downloaded and uploaded:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Log messages are not reliable over time. Tests should not use them to inspect behavior.

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import org.codehaus.plexus.util.FileUtils;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

prefer Apache commons-io for this functionality

private final RepositorySystemSession origSession;
private final RepositoryCache cache;
private final File tempBasedir;
private LocalRepositoryManager lrm;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

avoid abbreviation

*/
class TempLocalRepoSession extends AbstractForwardingRepositorySystemSession implements Closeable
{
private final RepositorySystemSession origSession;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

orig --> original

@mdrie
Copy link
Author

mdrie commented Jun 9, 2023

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.

@elharo
Copy link
Contributor

elharo commented Jun 9, 2023

No, do not assume that. No one has approved this yet, and there does not seem to be agreement that this feature is desirable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants