As the initial scenario doesn't mention it, I would like to stress the step of submitting the patch to the owner. This should as least make it feasible to get fixed quickly at the source.
In any case, the two important things I think are to keep the original groupId and artifactId (which was NOT the recommended way some time ago), and also to define dependency versions through dependencyManagament (so that there is just one place to change). /Anders On Mon, May 4, 2009 at 19:10, Geoffrey Wiseman <geoffrey.wise...@gmail.com> wrote: > On Mon, May 4, 2009 at 1:01 PM, Nick Stolwijk <nick.stolw...@gmail.com>wrote: > >> Normally I just check out the source, apply my patches, update the >> deploymentManament section to point to our inhouse repository, update >> the version to x.y.z-companyname-1 and do a maven deploy. Then update >> the documentation to mention which revision you checked out >> (preferably a tag) and for which issues you have applied a patch, so >> that the build is reproducible. >> > > That'd would be roughly similar to how I would typically handle it. If the > changes are significant, I might also check in to local source control. > > In all scenarios, I'd be hoping to get back on a public version ASAP. > > - Geoffrey > -- > Geoffrey Wiseman > http://www.geoffreywiseman.ca/ > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
