Re: Why is distributionManagement inside the pom?
Le dimanche 21 décembre 2014 21:30:49 Mirko Friedenhagen a écrit : Hello Benson, we work around the distributionManagement issue for our in-house projects by defining a property which is picked up from Maven settings.xml in our department parent pom. I suppose this works well for repository or snapshotRepository, ie what's absolutely necessary But for site, there is a strong issue http://jira.codehaus.org/browse/MSITE-604 and fixing it isn't trivial... do you use such property with site too? My question here: if you do not define distributionManagement (via a property) in a pom, all users of Maven would have to fiddle around with their settings to deploy anything. Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Sun, Dec 21, 2014 at 6:30 PM, Benson Margulies bimargul...@gmail.com wrote: I'd like to submit the concept that distributionManagement has something in common with repositories. Here's the common event that leads me to think about this: 1. Find a useful open source component. 2. Discover that it has a missing feature or a bug(let) that gets in the way of what I want to do. 3. Submit to owner, meanwhile ... 4. Want to make release into my own infrastructure of fork while waiting a long time for owner to absorb and release. Step 4 has always felt to me like much too much work. If it's entirely my infrastructure, I need to diddle with scm, distributionManagement, url, and version. If I am actually making a public fork, then I've got the groupId (and perhaps the package) to deal with. This case, however, is outside of the scope of this message. I've mulled over a maven-fork-plugin that would pom-edit for this purpose, but I've also wondered about the subject line of this message: should _all_ the information that concerns 'extrinsic' infrastructure be factored in some way that makes all this trivial? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Why is distributionManagement inside the pom?
On Sun, Dec 21, 2014 at 7:59 PM, Stephen Connolly stephen.alan.conno...@gmail.com 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: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Why is distributionManagement inside the pom?
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 jie...@gmail.com wrote: On Sun, Dec 21, 2014 at 7:59 PM, Stephen Connolly stephen.alan.conno...@gmail.com 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: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Why is distributionManagement inside the pom?
mvn release:prepare release:perform -DpushChanges=false -DlocalCheckout=true Will do what you want if working on a GIT repo On Monday, 22 December 2014, Benson Margulies bimargul...@gmail.com wrote: 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 jie...@gmail.com javascript:; wrote: On Sun, Dec 21, 2014 at 7:59 PM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; 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: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:; - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:; -- Sent from my phone
Why is distributionManagement inside the pom?
I'd like to submit the concept that distributionManagement has something in common with repositories. Here's the common event that leads me to think about this: 1. Find a useful open source component. 2. Discover that it has a missing feature or a bug(let) that gets in the way of what I want to do. 3. Submit to owner, meanwhile ... 4. Want to make release into my own infrastructure of fork while waiting a long time for owner to absorb and release. Step 4 has always felt to me like much too much work. If it's entirely my infrastructure, I need to diddle with scm, distributionManagement, url, and version. If I am actually making a public fork, then I've got the groupId (and perhaps the package) to deal with. This case, however, is outside of the scope of this message. I've mulled over a maven-fork-plugin that would pom-edit for this purpose, but I've also wondered about the subject line of this message: should _all_ the information that concerns 'extrinsic' infrastructure be factored in some way that makes all this trivial? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Why is distributionManagement inside the pom?
Hello Benson, we work around the distributionManagement issue for our in-house projects by defining a property which is picked up from Maven settings.xml in our department parent pom. My question here: if you do not define distributionManagement (via a property) in a pom, all users of Maven would have to fiddle around with their settings to deploy anything. Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Sun, Dec 21, 2014 at 6:30 PM, Benson Margulies bimargul...@gmail.com wrote: I'd like to submit the concept that distributionManagement has something in common with repositories. Here's the common event that leads me to think about this: 1. Find a useful open source component. 2. Discover that it has a missing feature or a bug(let) that gets in the way of what I want to do. 3. Submit to owner, meanwhile ... 4. Want to make release into my own infrastructure of fork while waiting a long time for owner to absorb and release. Step 4 has always felt to me like much too much work. If it's entirely my infrastructure, I need to diddle with scm, distributionManagement, url, and version. If I am actually making a public fork, then I've got the groupId (and perhaps the package) to deal with. This case, however, is outside of the scope of this message. I've mulled over a maven-fork-plugin that would pom-edit for this purpose, but I've also wondered about the subject line of this message: should _all_ the information that concerns 'extrinsic' infrastructure be factored in some way that makes all this trivial? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Why is distributionManagement inside the pom?
On Sun, Dec 21, 2014 at 3:30 PM, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello Benson, we work around the distributionManagement issue for our in-house projects by defining a property which is picked up from Maven settings.xml in our department parent pom. Maybe my plugin idea that automates 'fork' pom edits is really the answer here. My question here: if you do not define distributionManagement (via a property) in a pom, all users of Maven would have to fiddle around with their settings to deploy anything. Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Sun, Dec 21, 2014 at 6:30 PM, Benson Margulies bimargul...@gmail.com wrote: I'd like to submit the concept that distributionManagement has something in common with repositories. Here's the common event that leads me to think about this: 1. Find a useful open source component. 2. Discover that it has a missing feature or a bug(let) that gets in the way of what I want to do. 3. Submit to owner, meanwhile ... 4. Want to make release into my own infrastructure of fork while waiting a long time for owner to absorb and release. Step 4 has always felt to me like much too much work. If it's entirely my infrastructure, I need to diddle with scm, distributionManagement, url, and version. If I am actually making a public fork, then I've got the groupId (and perhaps the package) to deal with. This case, however, is outside of the scope of this message. I've mulled over a maven-fork-plugin that would pom-edit for this purpose, but I've also wondered about the subject line of this message: should _all_ the information that concerns 'extrinsic' infrastructure be factored in some way that makes all this trivial? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Why is distributionManagement inside the pom?
Am Sun, 21 Dec 2014 21:30:49 +0100 schrieb Mirko Friedenhagen mfriedenha...@gmail.com: My question here: if you do not define distributionManagement (via a property) in a pom, all users of Maven would have to fiddle around with their settings to deploy anything. I think you have to do that in some way anyway, as you need to define servers and logins. I guess it only works for ssh without special setup. But you are correct some form for distributing those settings would be a good addition. Something like an environment mechanism which could also cover staging/localtest/snapshot/release differences would be cool. Gruss Bernd - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Why is distributionManagement inside the pom?
On Sunday, December 21, 2014, Benson Margulies bimargul...@gmail.com wrote: I'd like to submit the concept that distributionManagement has something in common with repositories. Here's the common event that leads me to think about this: 1. Find a useful open source component. 2. Discover that it has a missing feature or a bug(let) that gets in the way of what I want to do. 3. Submit to owner, meanwhile ... 4. Want to make release into my own infrastructure of fork while waiting a long time for owner to absorb and release. Step 4 has always felt to me like much too much work. mvn versions:set -DnewVersion=1.1-mycompany-01 mvn clean javadoc:har 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 If it's entirely my infrastructure, I need to diddle with scm, distributionManagement, url, and version. If I am actually making a public fork, then I've got the groupId (and perhaps the package) to deal with. This case, however, is outside of the scope of this message. I've mulled over a maven-fork-plugin that would pom-edit for this purpose, but I've also wondered about the subject line of this message: should _all_ the information that concerns 'extrinsic' infrastructure be factored in some way that makes all this trivial? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:; -- Sent from my phone
