On Tue, Aug 4, 2009 at 1:27 PM, Anders Hammar<[email protected]> wrote: > Tim, > >> 4. Package, publish your new patched artifact to a repository manager >> (under a new groupId, artifactId, version). >> >> The key here is that you create a project that patches the original >> artifact and then publishes it under a different GAV coordinate. I >> would not recommend patching the JAR and then writing it back to the >> repository manager under the same GAV coordinate: 1. You are going to >> have a GAV collision, and 2. It makes it difficult to update to a new >> version of this binary dependency. > > Is it really best practise to change groupId and artifactId? I would > only change the version so that Maven has a chance to detect > collisions. Similar to what Brian recommends for converting a SNAPSHOT > version to a release version in this blog entry (see rule #5): > http://www.sonatype.com/people/2009/01/best-practices-for-releasing-with-3rd-party-snapshot-dependencies/ >
If it is something that is public, yes, only change the version. I was assuming this was some gnarly internal binary that someone handed to him because that's what has happened to me in the past. Example: you work on a system that depends on some proprietary, source-less JAR binary. In that case, I'd wrap it with my own GAV and call it a day. But, you are right, if you are patching something like commons-lang or plexus-utils, you would totally preserve the GA and change the V. > /Anders > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
