Re: Complex Maven projects - Tutorials? Books?
On 06/13/2014 10:26 PM, Barrie Treloar wrote: On 14 June 2014 02:14, Robert Kuropkat rkurop...@t-sciences.com wrote: snip I'll add my cry of despair here as well. Modern Open Source documentation efforts tend be mostly disappointing. First of all, it's never in a nice neat collection. Second, most of the articles and examples supplied by Senior Mentor Google are stale, trivial and sparsely explained. Explanations are rarely more than a statement of the obvious (Property: enabled: true/false - enable or disable feature). The question of WHY is rarely addressed and downstream results never. Even if you do find a well detailed example it is very specific (cookbook style) with little explanation of the options NOT chosen and why. I'm running into this right now in fact. I did some proof of concept testing on a bunch of plugins for my group, things looked good and now I'm reviewing my configurations and documenting them. I've managed to run across a few issues where configurations I plucked off the Internet are working but don't seem to be valid. At least I can not find any documentation for the options I set. Is it stale documentation? Deprecated options? Just plain wrong examples? With a configuration file like XML which is designed to ignore options it doesn't understand, this is even more frustrating. With rapidly changing feature sets it's maddening. Sometimes the people implementing things can't see things from a fresh perspective - they can't unlearn what they already know. That is why we rely on the community to provide patches - even to documentation - to help clarify things. It's a great place to start if you want to get involved - it's where I started. We also need people withe skills and desire to improve documentation. Technical writing and cutting code are orthogonal skills that rarely sit in one individual. So if you have someone on your team who can write technical docs then convince them, your management, etc that it benefits your team to help improve these docs and give back to the project. It will also help future projects at your org. Definitely understand the issues, just wish I wasn't short on answers or suggestions. I usually try not to spend much time complaining when I have nothing useful to offer up... As you said, the skills don't usually align. My own documentation efforts are more desperation attempts to not be bothered by things I'm no longer working on. I mentioned in a reply off list some of what I am doing now might be possible to offer up, though I'm afraid it will likely at least start in one of the same categories I mentioned above of being overly specific. However, it may serve as a useful starting point, so I'll see what I can do. Thank you for the answers below. That reporting section thing was driving me nuts. Now if I can just figure out why setting altReleaseDeploymentRepository and altSnapshotDeploymentRepository in the settings.xml file don't seem to actually do anything, requiring you to use altDeploymentRepository property instead snip Robert Kuropkat - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: Complex Maven projects - Tutorials? Books?
the points of people who argument for the CD way-of-life. Nevertheless the links Pascal provided are very interesting. And I found even a few posts of Jez Humble, the author of that CD book I haven't read yet. :D I will definitely read the forum discussion and also have a look at the YouTube video. Again I want to thank all to all the people who responded to my mail. Now I have some material to read through and discuss it with my colleagues. I hope you're not getting mad if I come back for more questions. :) Regards, Gerrit -Ursprüngliche Nachricht- Von: Pascal Rapicault [mailto:pas...@rapicault.net] Gesendet: Freitag, 13. Juni 2014 04:32 An: Maven Users List Betreff: Re: Complex Maven projects - Tutorials? Books? If you are really aiming at doing continuous delivery (any potential build can be pushed to prod), then SNAPSHOT is not a great way to deal with dependencies since you will not be able to exactly know what you ship. To avoid this, one practice is to use the build number in the artifact version (1.0.0-b1 or 1.0.1). This has of course had the drawback that now you have to update the pom.xml of components using a specific artifact (move from build 1 to 2) but this also gives you greater control on the rate at which you consume libraries. You may be interested in these articles: - http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-td3245370.html - http://stackoverflow.com/questions/18456111/what-is-the-maven-way-for-project-versions-when-doing-continuous-delivery That said, if you add Artifactory to the mix, you can leverage its capabilities of obtaining specific versions of a SNAPSHOT through matrix parameters (https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution) quite handy. One example where this comes handy is when you split your build process over multiple jenkins jobs and you want to make sure that you use the same artifact throughout the process and this w/o blocking the whole pipeline for the whole duration of the process. HTH Pascal On 12/06/2014 10:46 AM, Hohl, Gerrit wrote: Hello everyone, :) I have a question which is not about a specific problem with Maven, but more a general question. I hope it is okay to ask this question here. We use Maven and Jenkins for about 1.5 years now, I guess. Until now the Maven projects have been very simple and - let's say - very monolithic. But recently we identify more and more internal libraries in our products. Of course we don't want to share this libraries by copy-n-paste between the products - especially as we have Maven. So we started to read books, tutorials on the Internet and so on. But most of them only deal with simple projects. They don't cover e.g. versioning the build process (especially if your build process consists of more than just one step). They also don't cover the problems of developing the libraries while your developing the products which depend on them. Especially at the beginning your libraries will go through a lot of changes. A few name snapshots as a solution, but don't explain how you can work using them, how you can use them in your pom.xml and how you deal with them if you finally switch your product and/or your library from the snapshot state to the release state. A few also say that you shouldn't use snapshots at all because it will result in many problems (e.g. having -SNAPSHOT entries in your pom.xml). Nightly builds or build triggered by the SCM are also an issue here. Does someone know a good book or tutorial which handles all of these issues around Maven and CI/CD in more depth? Regards, Gerrit - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Complex Maven projects - Tutorials? Books?
: Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation Authors: Jez Humble, David Farley Publisher: Addision-Wesley ISBN: 978-0321601919 I haven't read it yet. But I hope to get a deeper understanding of the whole process. But I'm not sure if it will help me solving our problems. I had a look on the books on the Maven site. Most look like they are already old and dealing with Maven 2 (like the book we have - unfortunately - also does). And the newest one got some poor reviews (okay, they are subjective, so maybe the book isn't that bad). Maybe one of you can give a recommendation for a book which is not dedicated to beginners, but instead handles some issues of developers who are already on the next level (but not on the highest level yet). Of course we are also reading the online documentation. But I have to admit that it sometimes lacks the one or another information which you find in some blogs or articles after some search. And some of the 3rd party plugins are explained really poorly (okay, that is not a problem of the Maven project). That doesn't make it easier as Maven offers some many possibilities and therefore *can* get complex. We also found a presentation on the Internet which described a solution like Pascal mentioned in his mail. But doesn't that mean that you will have hundreds and hundreds of releases in your repository? And doesn't it mean you have to update the pom.xml files of your projects which are developed simultaneously all the time? Somehow I prefer the idea - like Ron - of handling internal libraries not different from external libraries. But I also see the points of people who argument for the CD way-of-life. Nevertheless the links Pascal provided are very interesting. And I found even a few posts of Jez Humble, the author of that CD book I haven't read yet. :D I will definitely read the forum discussion and also have a look at the YouTube video. Again I want to thank all to all the people who responded to my mail. Now I have some material to read through and discuss it with my colleagues. I hope you're not getting mad if I come back for more questions. :) Regards, Gerrit -Ursprüngliche Nachricht- Von: Pascal Rapicault [mailto:pas...@rapicault.net] Gesendet: Freitag, 13. Juni 2014 04:32 An: Maven Users List Betreff: Re: Complex Maven projects - Tutorials? Books? If you are really aiming at doing continuous delivery (any potential build can be pushed to prod), then SNAPSHOT is not a great way to deal with dependencies since you will not be able to exactly know what you ship. To avoid this, one practice is to use the build number in the artifact version (1.0.0-b1 or 1.0.1). This has of course had the drawback that now you have to update the pom.xml of components using a specific artifact (move from build 1 to 2) but this also gives you greater control on the rate at which you consume libraries. You may be interested in these articles: - http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-td3245370.html - http://stackoverflow.com/questions/18456111/what-is-the-maven-way-for-project-versions-when-doing-continuous-delivery That said, if you add Artifactory to the mix, you can leverage its capabilities of obtaining specific versions of a SNAPSHOT through matrix parameters ( https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution ) quite handy. One example where this comes handy is when you split your build process over multiple jenkins jobs and you want to make sure that you use the same artifact throughout the process and this w/o blocking the whole pipeline for the whole duration of the process. HTH Pascal On 12/06/2014 10:46 AM, Hohl, Gerrit wrote: Hello everyone, :) I have a question which is not about a specific problem with Maven, but more a general question. I hope it is okay to ask this question here. We use Maven and Jenkins for about 1.5 years now, I guess. Until now the Maven projects have been very simple and - let's say - very monolithic. But recently we identify more and more internal libraries in our products. Of course we don't want to share this libraries by copy-n-paste between the products - especially as we have Maven. So we started to read books, tutorials on the Internet and so on. But most of them only deal with simple projects. They don't cover e.g. versioning the build process (especially if your build process consists of more than just one step). They also don't cover the problems of developing the libraries while your developing the products which depend on them. Especially at the beginning your libraries will go through a lot of changes. A few name snapshots as a solution, but don't explain how you can work using them, how you can use them in your pom.xml and how you deal with them if you finally switch your product and/or your library
Re: Complex Maven projects - Tutorials? Books?
On Fri, Jun 13, 2014 at 09:23:31AM +0930, Barrie Treloar wrote: On 13 June 2014 09:07, mike digioia mpd...@gmail.com wrote: So how does this book help you any more than all the detailed online Maven docs that exists and are updated? It's just another source of information. The docs don't really walk you through everything, they are mostly focused on a particular plugin and not on how to pull all this together. Indeed. One thing I really miss from the evil old mainframe days is the manuals that gave you the big picture and the developers' view of how they expected the tools to be used. There were usually two books for any product: o Reference Manual -- *complete* individual descriptions of each feature, command, and qualifier. o Programmer's (or User's) Guide -- fits all the pieces together and suggests good ways to think about the facility under discussion. I typically had both open when working on anything nontrivial. It's essential to have both the macro and the micro view of a tool, to use it well. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature
Re: Complex Maven projects - Tutorials? Books?
On 06/13/2014 10:27 AM, Mark H. Wood wrote: On Fri, Jun 13, 2014 at 09:23:31AM +0930, Barrie Treloar wrote: On 13 June 2014 09:07, mike digioia mpd...@gmail.com wrote: So how does this book help you any more than all the detailed online Maven docs that exists and are updated? It's just another source of information. The docs don't really walk you through everything, they are mostly focused on a particular plugin and not on how to pull all this together. Indeed. One thing I really miss from the evil old mainframe days is the manuals that gave you the big picture and the developers' view of how they expected the tools to be used. There were usually two books for any product: o Reference Manual -- *complete* individual descriptions of each feature, command, and qualifier. o Programmer's (or User's) Guide -- fits all the pieces together and suggests good ways to think about the facility under discussion. I typically had both open when working on anything nontrivial. It's essential to have both the macro and the micro view of a tool, to use it well. I'll add my cry of despair here as well. Modern Open Source documentation efforts tend be mostly disappointing. First of all, it's never in a nice neat collection. Second, most of the articles and examples supplied by Senior Mentor Google are stale, trivial and sparsely explained. Explanations are rarely more than a statement of the obvious (Property: enabled: true/false - enable or disable feature). The question of WHY is rarely addressed and downstream results never. Even if you do find a well detailed example it is very specific (cookbook style) with little explanation of the options NOT chosen and why. I'm running into this right now in fact. I did some proof of concept testing on a bunch of plugins for my group, things looked good and now I'm reviewing my configurations and documenting them. I've managed to run across a few issues where configurations I plucked off the Internet are working but don't seem to be valid. At least I can not find any documentation for the options I set. Is it stale documentation? Deprecated options? Just plain wrong examples? With a configuration file like XML which is designed to ignore options it doesn't understand, this is even more frustrating. With rapidly changing feature sets it's maddening. Actually having access to OLD documentation would help understand the difference between the old but still supported vs. the shiny, new preferred way. I still have not found a good discussion about the difference between using the POM reporting section and adding reporting plugins to the maven-site-plugin in the build section. All I know at the moment is more plugins seemed to work as I expected when adding the plugins to the maven-site-plugin in the build section than when trying to add them to the reporting section. For whatever reason, my career has been one of trouble shooting, proof of concept and other, very targeted activities. I almost never do the same job or use the same technologies for more than a year or two. My efforts historically rely on being clever, persistent and willing to buy every book I can find on the subject. Generally, the modern JavaDoc mentality of documentation blows. If I want to read the source code (and I can) I'll write the source code (which I can). If I have to dig in that deep to figure your plugin out, it's not really saving me much time is it? Robert Kuropkat - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Complex Maven projects - Tutorials? Books?
+1 Ron On 13/06/2014 12:44 PM, Robert Kuropkat wrote: On 06/13/2014 10:27 AM, Mark H. Wood wrote: On Fri, Jun 13, 2014 at 09:23:31AM +0930, Barrie Treloar wrote: On 13 June 2014 09:07, mike digioia mpd...@gmail.com wrote: So how does this book help you any more than all the detailed online Maven docs that exists and are updated? It's just another source of information. The docs don't really walk you through everything, they are mostly focused on a particular plugin and not on how to pull all this together. Indeed. One thing I really miss from the evil old mainframe days is the manuals that gave you the big picture and the developers' view of how they expected the tools to be used. There were usually two books for any product: o Reference Manual -- *complete* individual descriptions of each feature, command, and qualifier. o Programmer's (or User's) Guide -- fits all the pieces together and suggests good ways to think about the facility under discussion. I typically had both open when working on anything nontrivial. It's essential to have both the macro and the micro view of a tool, to use it well. I'll add my cry of despair here as well. Modern Open Source documentation efforts tend be mostly disappointing. First of all, it's never in a nice neat collection. Second, most of the articles and examples supplied by Senior Mentor Google are stale, trivial and sparsely explained. Explanations are rarely more than a statement of the obvious (Property: enabled: true/false - enable or disable feature). The question of WHY is rarely addressed and downstream results never. Even if you do find a well detailed example it is very specific (cookbook style) with little explanation of the options NOT chosen and why. I'm running into this right now in fact. I did some proof of concept testing on a bunch of plugins for my group, things looked good and now I'm reviewing my configurations and documenting them. I've managed to run across a few issues where configurations I plucked off the Internet are working but don't seem to be valid. At least I can not find any documentation for the options I set. Is it stale documentation? Deprecated options? Just plain wrong examples? With a configuration file like XML which is designed to ignore options it doesn't understand, this is even more frustrating. With rapidly changing feature sets it's maddening. Actually having access to OLD documentation would help understand the difference between the old but still supported vs. the shiny, new preferred way. I still have not found a good discussion about the difference between using the POM reporting section and adding reporting plugins to the maven-site-plugin in the build section. All I know at the moment is more plugins seemed to work as I expected when adding the plugins to the maven-site-plugin in the build section than when trying to add them to the reporting section. For whatever reason, my career has been one of trouble shooting, proof of concept and other, very targeted activities. I almost never do the same job or use the same technologies for more than a year or two. My efforts historically rely on being clever, persistent and willing to buy every book I can find on the subject. Generally, the modern JavaDoc mentality of documentation blows. If I want to read the source code (and I can) I'll write the source code (which I can). If I have to dig in that deep to figure your plugin out, it's not really saving me much time is it? Robert Kuropkat - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Complex Maven projects - Tutorials? Books?
On 14 June 2014 02:14, Robert Kuropkat rkurop...@t-sciences.com wrote: On 06/13/2014 10:27 AM, Mark H. Wood wrote: On Fri, Jun 13, 2014 at 09:23:31AM +0930, Barrie Treloar wrote: On 13 June 2014 09:07, mike digioia mpd...@gmail.com wrote: So how does this book help you any more than all the detailed online Maven docs that exists and are updated? It's just another source of information. The docs don't really walk you through everything, they are mostly focused on a particular plugin and not on how to pull all this together. Indeed. One thing I really miss from the evil old mainframe days is the manuals that gave you the big picture and the developers' view of how they expected the tools to be used. There were usually two books for any product: o Reference Manual -- *complete* individual descriptions of each feature, command, and qualifier. o Programmer's (or User's) Guide -- fits all the pieces together and suggests good ways to think about the facility under discussion. I typically had both open when working on anything nontrivial. It's essential to have both the macro and the micro view of a tool, to use it well. I'll add my cry of despair here as well. Modern Open Source documentation efforts tend be mostly disappointing. First of all, it's never in a nice neat collection. Second, most of the articles and examples supplied by Senior Mentor Google are stale, trivial and sparsely explained. Explanations are rarely more than a statement of the obvious (Property: enabled: true/false - enable or disable feature). The question of WHY is rarely addressed and downstream results never. Even if you do find a well detailed example it is very specific (cookbook style) with little explanation of the options NOT chosen and why. I'm running into this right now in fact. I did some proof of concept testing on a bunch of plugins for my group, things looked good and now I'm reviewing my configurations and documenting them. I've managed to run across a few issues where configurations I plucked off the Internet are working but don't seem to be valid. At least I can not find any documentation for the options I set. Is it stale documentation? Deprecated options? Just plain wrong examples? With a configuration file like XML which is designed to ignore options it doesn't understand, this is even more frustrating. With rapidly changing feature sets it's maddening. Sometimes the people implementing things can't see things from a fresh perspective - they can't unlearn what they already know. That is why we rely on the community to provide patches - even to documentation - to help clarify things. It's a great place to start if you want to get involved - it's where I started. We also need people withe skills and desire to improve documentation. Technical writing and cutting code are orthogonal skills that rarely sit in one individual. So if you have someone on your team who can write technical docs then convince them, your management, etc that it benefits your team to help improve these docs and give back to the project. It will also help future projects at your org. Actually having access to OLD documentation would help understand the difference between the old but still supported vs. the shiny, new preferred way. The previous plugin docs are always available they are versioned on the website. But they are unlikely to discuss why things were changed. You might get lucky and find that information in the jira changeset. I still have not found a good discussion about the difference between using the POM reporting section and adding reporting plugins to the maven-site-plugin in the build section. All I know at the moment is more plugins seemed to work as I expected when adding the plugins to the maven-site-plugin in the build section than when trying to add them to the reporting section. That discussion is in the mail archives, but you would have to hunt for it. If you are using maven 3 then the reporting section no longer works. For whatever reason, my career has been one of trouble shooting, proof of concept and other, very targeted activities. I almost never do the same job or use the same technologies for more than a year or two. My efforts historically rely on being clever, persistent and willing to buy every book I can find on the subject. Generally, the modern JavaDoc mentality of documentation blows. If I want to read the source code (and I can) I'll write the source code (which I can). If I have to dig in that deep to figure your plugin out, it's not really saving me much time is it? You've described my job too. I tend to write things up not for others but for myself in the future. I've been surprised more than once to google a problem only to find that I answered that myself a while ago...
Complex Maven projects - Tutorials? Books?
Hello everyone, :) I have a question which is not about a specific problem with Maven, but more a general question. I hope it is okay to ask this question here. We use Maven and Jenkins for about 1.5 years now, I guess. Until now the Maven projects have been very simple and - let's say - very monolithic. But recently we identify more and more internal libraries in our products. Of course we don't want to share this libraries by copy-n-paste between the products - especially as we have Maven. So we started to read books, tutorials on the Internet and so on. But most of them only deal with simple projects. They don't cover e.g. versioning the build process (especially if your build process consists of more than just one step). They also don't cover the problems of developing the libraries while your developing the products which depend on them. Especially at the beginning your libraries will go through a lot of changes. A few name snapshots as a solution, but don't explain how you can work using them, how you can use them in your pom.xml and how you deal with them if you finally switch your product and/or your library from the snapshot state to the release state. A few also say that you shouldn't use snapshots at all because it will result in many problems (e.g. having -SNAPSHOT entries in your pom.xml). Nightly builds or build triggered by the SCM are also an issue here. Does someone know a good book or tutorial which handles all of these issues around Maven and CI/CD in more depth? Regards, Gerrit
Re: Complex Maven projects - Tutorials? Books?
Am 2014-06-12 16:46, schrieb Hohl, Gerrit: Hello everyone, :) [..] Does someone know a good book or tutorial which handles all of these issues around Maven and CI/CD in more depth? Hi Gerrit, here is the approach I have been using all the years, I think this is quite common in companies: 1. Set up a Nexus instance in your company, mirroring Central and with release/snapshot repos for your company. 1.1 Make sure that Nexus works correctly. 2. Let the CI server deploy SNAPSHOTs of you libraries deploy to your Nexus instance frequently. 3. Refer to those SNAPSHOTs in your project POMs if you need bleeding edge. This makes it easier to soak in fixed bugs in deps. If you think that your lib is stable enough, release to SCM and Nexus. 4. Use the maven-versions-plugin to update your project dependencies and or fix to a release version. It is perfectly fine to rely on SNAPSHOTs during development but not when you perform mvn release:prepare release:perform. Gruß, Michael PS: Upgrade your Maven version to a new one if you are able to. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Complex Maven projects - Tutorials? Books?
Good questions. I have never heard anything negative about SNAPSHOTs from those who use them. Notice - Free advice: - Separate your utilities from your applications. If they have a life of their own, you can manage the dependencies more easily. - Test your utilities and libraries separately. Use SNAPSHOTs and a release process that is separate from your application. - Have your applications treat your utilities and libraries as if they were written by some other organization. - Use dependency management in the parent POM to control versions of utilities. This gives you one place to maintain the versions. End of free advice. Free commentary. At the beginning, you are correct, it will be harder to provide a stable environment but that is where SNAPSHOTs are a big help. Version 2.1.0-SHAPSHOT of the application depends on version 1.0-SNAPSHOT of file-manager-core until file-manager-core stabilizes and becomes version 1.0. Generally speaking, the application should still be a SNAPSHOT after your utilities become releases since you should be able to stabilize the functionality and finish the testing of the utilities before the same can happen to the application modules. End of fee commentary I think that you will find this advice at least worth the cost and you may get some comments from the smarter and more knowledgeable people here that refines or contradicts my advice. There is lots of good Maven information freely available and lots of projects that are very complex being developed with Maven. Our biggest project had over 70 Maven modules of which 10 where supporting libraries either written by us or aggregated from existing open source projects. We have some articles describing how we use Maven in our technical blog at http://blog.artifact-software.com/tech. Jokes are found at http://blog.artifact-software.com/fun if you need a smile to face the world of Maven. Ron On 12/06/2014 10:46 AM, Hohl, Gerrit wrote: Hello everyone, :) I have a question which is not about a specific problem with Maven, but more a general question. I hope it is okay to ask this question here. We use Maven and Jenkins for about 1.5 years now, I guess. Until now the Maven projects have been very simple and - let's say - very monolithic. But recently we identify more and more internal libraries in our products. Of course we don't want to share this libraries by copy-n-paste between the products - especially as we have Maven. So we started to read books, tutorials on the Internet and so on. But most of them only deal with simple projects. They don't cover e.g. versioning the build process (especially if your build process consists of more than just one step). They also don't cover the problems of developing the libraries while your developing the products which depend on them. Especially at the beginning your libraries will go through a lot of changes. A few name snapshots as a solution, but don't explain how you can work using them, how you can use them in your pom.xml and how you deal with them if you finally switch your product and/or your library from the snapshot state to the release state. A few also say that you shouldn't use snapshots at all because it will result in many problems (e.g. having -SNAPSHOT entries in your pom.xml). Nightly builds or build triggered by the SCM are also an issue here. Does someone know a good book or tutorial which handles all of these issues around Maven and CI/CD in more depth? Regards, Gerrit -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Complex Maven projects - Tutorials? Books?
Great advice. We depend on Nexus. If you are serious about Maven, you need a repo. The community version of Nexus is a great benefit to the Maven community. Ron On 12/06/2014 2:39 PM, Michael Osipov wrote: Am 2014-06-12 16:46, schrieb Hohl, Gerrit: Hello everyone, :) [..] Does someone know a good book or tutorial which handles all of these issues around Maven and CI/CD in more depth? Hi Gerrit, here is the approach I have been using all the years, I think this is quite common in companies: 1. Set up a Nexus instance in your company, mirroring Central and with release/snapshot repos for your company. 1.1 Make sure that Nexus works correctly. 2. Let the CI server deploy SNAPSHOTs of you libraries deploy to your Nexus instance frequently. 3. Refer to those SNAPSHOTs in your project POMs if you need bleeding edge. This makes it easier to soak in fixed bugs in deps. If you think that your lib is stable enough, release to SCM and Nexus. 4. Use the maven-versions-plugin to update your project dependencies and or fix to a release version. It is perfectly fine to rely on SNAPSHOTs during development but not when you perform mvn release:prepare release:perform. Gruß, Michael PS: Upgrade your Maven version to a new one if you are able to. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Complex Maven projects - Tutorials? Books?
On 13 June 2014 00:16, Hohl, Gerrit g.h...@aurenz.de wrote: We use Maven and Jenkins for about 1.5 years now, I guess. Until now the Maven projects have been very simple and - let's say - very monolithic. But recently we identify more and more internal libraries in our products. Of course we don't want to share this libraries by copy-n-paste between the products - especially as we have Maven. So we started to read books, tutorials on the Internet and so on. But Can you list what you've read so far? I assume you've gone through the ones we link at the Maven site? http://maven.apache.org/articles.html most of them only deal with simple projects. They don't cover e.g. versioning the build process (especially if your build process consists of more than just one step). They also don't cover the problems of developing the libraries while your developing the products which depend on them. Especially at the beginning your libraries will go through a lot of changes. A few name snapshots as a solution, but don't explain how you can work using them, how you can use them in your pom.xml and how you deal with them if you finally switch your product and/or your library from the snapshot state to the release state. A few also say that you shouldn't use snapshots at all because it will result in many problems (e.g. having -SNAPSHOT entries in your pom.xml). Nightly builds or build triggered by the SCM are also an issue here. I highly recommend that you sit down locally with your group and write up a list of questions, and then document them on your internal wiki. Work through which ones are causing you the most pain (whatever that may be; confusion, build stability, slow build times, etc) And after you've done some googling, searched the archives, etc, then come back and ask the questions individually here. A lot of the problem you will find when you get to this level is that it's hard to express the concepts if you haven't already been exposed to them before. And we can't give the advice you want because we have to both upskill and explain options and their alternatives. Look for blogs by active members of the community, some that come to mind are (in no particular order): * Brian Fox - http://blog.sonatype.com/author/brian/ * Stephen Connolly - http://javaadventure.blogspot.com.au/ * Ron Wheeler - http://blog.artifact-software.com/tech/?author=2 And when you think you've found the answers - contribute them back to the community.
Re: Complex Maven projects - Tutorials? Books?
So how does this book help you any more than all the detailed online Maven docs that exists and are updated? On Thu, Jun 12, 2014 at 4:10 PM, Barrie Treloar baerr...@gmail.com wrote: On 13 June 2014 00:16, Hohl, Gerrit g.h...@aurenz.de wrote: We use Maven and Jenkins for about 1.5 years now, I guess. Until now the Maven projects have been very simple and - let's say - very monolithic. But recently we identify more and more internal libraries in our products. Of course we don't want to share this libraries by copy-n-paste between the products - especially as we have Maven. So we started to read books, tutorials on the Internet and so on. But Can you list what you've read so far? I assume you've gone through the ones we link at the Maven site? http://maven.apache.org/articles.html most of them only deal with simple projects. They don't cover e.g. versioning the build process (especially if your build process consists of more than just one step). They also don't cover the problems of developing the libraries while your developing the products which depend on them. Especially at the beginning your libraries will go through a lot of changes. A few name snapshots as a solution, but don't explain how you can work using them, how you can use them in your pom.xml and how you deal with them if you finally switch your product and/or your library from the snapshot state to the release state. A few also say that you shouldn't use snapshots at all because it will result in many problems (e.g. having -SNAPSHOT entries in your pom.xml). Nightly builds or build triggered by the SCM are also an issue here. I highly recommend that you sit down locally with your group and write up a list of questions, and then document them on your internal wiki. Work through which ones are causing you the most pain (whatever that may be; confusion, build stability, slow build times, etc) And after you've done some googling, searched the archives, etc, then come back and ask the questions individually here. A lot of the problem you will find when you get to this level is that it's hard to express the concepts if you haven't already been exposed to them before. And we can't give the advice you want because we have to both upskill and explain options and their alternatives. Look for blogs by active members of the community, some that come to mind are (in no particular order): * Brian Fox - http://blog.sonatype.com/author/brian/ * Stephen Connolly - http://javaadventure.blogspot.com.au/ * Ron Wheeler - http://blog.artifact-software.com/tech/?author=2 And when you think you've found the answers - contribute them back to the community.
Re: Complex Maven projects - Tutorials? Books?
On 13 June 2014 09:07, mike digioia mpd...@gmail.com wrote: So how does this book help you any more than all the detailed online Maven docs that exists and are updated? It's just another source of information. The docs don't really walk you through everything, they are mostly focused on a particular plugin and not on how to pull all this together.
Complex Maven projects - Tutorials? Books?
Hello everyone, :) I have a question which is not about a specific problem with Maven, but more a general question. I hope it is okay to ask this question here. We use Maven and Jenkins for about 1.5 years now, I guess. Until now the Maven projects have been very simple and - let's say - very monolithic. But recently we identify more and more internal libraries in our products. Of course we don't want to share this libraries by copy-n-paste between the products - especially as we have Maven. So we started to read books, tutorials on the Internet and so on. But most of them only deal with simple projects. They don't cover e.g. versioning the build process (especially if your build process consists of more than just one step). They also don't cover the problems of developing the libraries while your developing the products which depend on them. Especially at the beginning your libraries will go through a lot of changes. A few name snapshots as a solution, but don't explain how you can work using them, how you can use them in your pom.xml and how you deal with them if you finally switch your product and/or your library from the snapshot state to the release state. A few also say that you shouldn't use snapshots at all because it will result in many problems (e.g. having -SNAPSHOT entries in your pom.xml). Nightly builds or build triggered by the SCM are also an issue here. Does someone know a good book or tutorial which handles all of these issues around Maven and CI/CD in more depth? Regards, Gerrit
Re: Complex Maven projects - Tutorials? Books?
If you are really aiming at doing continuous delivery (any potential build can be pushed to prod), then SNAPSHOT is not a great way to deal with dependencies since you will not be able to exactly know what you ship. To avoid this, one practice is to use the build number in the artifact version (1.0.0-b1 or 1.0.1). This has of course had the drawback that now you have to update the pom.xml of components using a specific artifact (move from build 1 to 2) but this also gives you greater control on the rate at which you consume libraries. You may be interested in these articles: - http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-td3245370.html - http://stackoverflow.com/questions/18456111/what-is-the-maven-way-for-project-versions-when-doing-continuous-delivery That said, if you add Artifactory to the mix, you can leverage its capabilities of obtaining specific versions of a SNAPSHOT through matrix parameters (https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution) quite handy. One example where this comes handy is when you split your build process over multiple jenkins jobs and you want to make sure that you use the same artifact throughout the process and this w/o blocking the whole pipeline for the whole duration of the process. HTH Pascal On 12/06/2014 10:46 AM, Hohl, Gerrit wrote: Hello everyone, :) I have a question which is not about a specific problem with Maven, but more a general question. I hope it is okay to ask this question here. We use Maven and Jenkins for about 1.5 years now, I guess. Until now the Maven projects have been very simple and - let's say - very monolithic. But recently we identify more and more internal libraries in our products. Of course we don't want to share this libraries by copy-n-paste between the products - especially as we have Maven. So we started to read books, tutorials on the Internet and so on. But most of them only deal with simple projects. They don't cover e.g. versioning the build process (especially if your build process consists of more than just one step). They also don't cover the problems of developing the libraries while your developing the products which depend on them. Especially at the beginning your libraries will go through a lot of changes. A few name snapshots as a solution, but don't explain how you can work using them, how you can use them in your pom.xml and how you deal with them if you finally switch your product and/or your library from the snapshot state to the release state. A few also say that you shouldn't use snapshots at all because it will result in many problems (e.g. having -SNAPSHOT entries in your pom.xml). Nightly builds or build triggered by the SCM are also an issue here. Does someone know a good book or tutorial which handles all of these issues around Maven and CI/CD in more depth? Regards, Gerrit - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
