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.
Hth, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Mon, May 4, 2009 at 6:10 PM, daniel.green <[email protected]> wrote: > > The situation: > > * Company finds a show stopping bug in dependency Foo > * Company can not wait for the owner of Foo to fix it > * Company branches the source code locally and applies patch > * Company now needs to maintained a modified third party dependency > > Currently some crazy system of relative paths and fake version numbers is > being used to resolve the modified dependencies. However, this is obviously > an eye soar sore and is cluttering up our source repository. What are some > solutions for ensuring that changes don't get overwritten and our repository > stays clean? > > Any suggestion will be welcomed! > > I appreciate your time, thank you at least for that :-), > Daniel. > > -- > View this message in context: > http://www.nabble.com/Managing-Modified-Dependencies-tp23371539p23371539.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > 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]
