-
Notifications
You must be signed in to change notification settings - Fork 66
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
base: master
Are you sure you want to change the base?
Conversation
ccb1794
to
703652a
Compare
Thanks for the first workflow run. A non-JAR-file in a |
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? |
There was a problem hiding this 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.
@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:
|
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:
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. |
Done. Hope my wording makes sense to you. |
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. |
Well, how do you want to mark a CVE in the original problematic coordinate? |
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 ); |
There was a problem hiding this comment.
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 ); |
There was a problem hiding this comment.
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: |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
orig --> original
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. |
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 thelocal 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
justto 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:
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.
[MPH-XXX] - Fixes bug in ApproximateQuantiles
,where you replace
MPH-XXX
with the appropriate JIRA issue. Best practiceis to use the JIRA issue title in the pull request title and in the first line of the
commit message.
mvn clean verify
to make sure basic checks pass. A more thorough check willbe performed on your pull request automatically.
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.
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.