What I always do is create a fork repo to maintain my fix and to release from. So Stephen's idea isn't ideal for me; I'd rather do pom surgery to change scm so I can use the release plugin.
On Mon, Dec 22, 2014 at 9:34 AM, jieryn <[email protected]> wrote: > On Sun, Dec 21, 2014 at 7:59 PM, Stephen Connolly > <[email protected]> wrote: >> >> mvn versions:set -DnewVersion=1.1-mycompany-01 && mvn clean javadoc:jar >> source:jar deploy -DaltDeploymentUrl=my-Id::default::my-url && mvn >> versions:revert >> >> Ok so it's a long command line, but really not that much work at the end of >> they day. I did it 4 times last month > > Which is why I keep it handy via a small bash function in my > environment. It's very easy grease for one-off type fixes to keep the > gears moving across large projects requiring many external plugins and > dependencies. We even have a dedicated Archiva repository for those > locally fixed third party hotfix deployments, so we can keep track and > manage them sanely. > > I think the only thing we are missing for this pattern is a > differential tracker for really slow (to release) upstream projects, > where our local fix has not been released, but other fixes are landing > there. It's too much work to do manually, maybe Jenkins has a hotfix > plugin where you can drop in a patch and have it keep track of > upstream and also manage the application of your local patch... hrm. > > --------------------------------------------------------------------- > 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]
