mosabua
commented
2 years ago That is definitely a larger effort. And honestly I am not sure if thats worth it .. you would basically have to fork and rebuild to some degree since you never really know where classpath/gav references are used and sprinkled across. At least whenever I had to do such a move in the past I forked the project, managed all the changes in a git repo and did it all manually . automating this would be awesome .. but also a huge task..
I wonder how common this is and if making it easy is actually kind of a bad thing.. since it discourages proper fix or contribution to upstream.
cstamas
Use case: you have a project (maybe not even yours, for example on Central, an OSS project) that you need to fork. As we know, best practice is to change GAV of fork (either "move" it under your groupID, or at least change version to 1.0.0-simpligility). So, would be cool, if I could make it get G:A:V from Central, but deploy it as G2:A:V (or G:A:V2 or whatever) to my hosted repository. As this would then allow me to "patch" selectively, instead to rebuild whole (potentially huge) project, I could just "fix" the spot I have to, one or two modules. Example: https://issues.apache.org/jira/browse/MNG-7475
(note: this is just a rough idea, and the example above may not be even feasible due complex project tree and POM imports and so on)
This is NOT trivial, as it would require POM "rewrites" as well (and nearly impossible in case of maven-plugins as there plugin artifact GAV and plugin metadata embedded in JAR must be aligned). So, let's keep it simple (could simply fail for some known packaging that cannot be processed like this). Re-checksumming (due POM rewrites) could happen automatically using resolver/aether on deploy.