Your SlideShare is downloading. ×
0
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Version Management in Maven
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Version Management in Maven

5,804

Published on

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,804
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
76
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Version Mgmt in Maven SOME BEST PRACTICES
  • 2. Agenda What is software versioning How can maven help us? ◦ Maven release plugin Best practices ◦ What to version? ◦ How to manage versions? Tips and tricks ◦ Version handling with maven-versions-plugin ◦ Dependency analysis with maven-dependency-plugin
  • 3. Version identifies software artefacts: Software Versioning ◦ modules, applications, assemblies, … ◦ Uniquely identifies source code ◦ Build should be repeatable from that version of code Most used: ◦ Major.minor[.bugfix][-qualifier[-build]] Qualifiers: ◦ ◦ ◦ ◦ ◦ Alpha: not feature complete Beta: contains critical bugs CR: release candidate, not fully tested Final: final version SNAPSHOT ◦ Floating version, not an actual identification ◦ Should allways be used for code under development
  • 4. Versioning with Source Code Management Basics of SCM (Git, Subversion, CVS, …) ◦ Synching software changes between developers ◦ Allowing multiple branches to be developed simultaneously ◦ Maintenance branches ◦ Feature branches ◦ Merge branches again  ◦ Tagging versions of code ◦ So you can find out later which bugs you solved when SCM does not put a version number in your artifacts!
  • 5. Maven in a nutshell
  • 6. Maven Basics Convention over configuration ◦ Convention for source code organization ◦ src/main/java ◦ src/webapp ◦ src/test/java ◦ Plugins with default configurations ◦ Jar, war, ear ◦ Surefire tests ◦ Reporting Dependency Management ◦ Remote repository and local repository ◦ Transactional dependencies
  • 7. Snapshots In maven, versions under development have classifier ‘-SNAPSHOT’ ◦ When building versions on a development system, you should always build SNAPSHOTS. ◦ When depending on a SNAPSHOT version of another module, maven will give you the latest (timestamped) version ◦ Could give surprises of code that suddenly stops building ◦ Preferrably have the source code of your SNAPSHOT dependencies built locally Non SNAPSHOT versions should be built only once and deployed once ◦ Should be tagged in Subversion/Git/CVS, and never changed ◦ (Unless you know for sure nobody got a copy yet) ◦ Released versions should never have SNAPSHOT dependencies ◦ See release plugin later
  • 8. Organizing Maven Modules Aggregator POM vs. Parent POM ◦ Aggregator POM organizes build of multiple modules ◦ One per subfolder ◦ Declares which subfolders contain modules ◦ Parent POM centralizes common configuration ◦ Plugin configuration ◦ Dependencies ◦ Dependency Management Convention: Aggregator POM == Parent POM ◦ Exceptions are allowed
  • 9. Typical Maven Workspace Hierarchy Workspace POM ◦ Godfather aka archon (development team) ◦ Application System(s) (set of related applications) ◦ Application or Library ◦ Module Group(s) (if necessary) ◦ Module
  • 10. Workspace POM Dummy Aggregator POM Just to launch other POM’s Can use symbolic links to point to actual application roots to be built.
  • 11. Godfather POM Defines <distributionManagement> and <repositories> ◦ <distributionManagement>: where your artifacts are deployed ◦ <repositories>: where other necessary artifacts can be found Rarely changes ◦ Simple fixed version number, e.g. 1, 2, 3, … Do not put shared dependencies here ◦ Use maven import (since maven 2.0.9)
  • 12. Application System POM Inherits from Godfather Defines external dependency versions in <dependencyManagement> Defines common plugin configuration ◦ E.g. java compiler version Could build an assembly containing all applications
  • 13. Application or Library POM Module groups Defines internal dependency management ◦ Sibling modules ◦ Can use ${project.version} Define more shared configuration ◦ Inapplicable on a higher level ◦ E.g. aspect jars to use
  • 14. Module POM Defines all direct dependencies ◦ Do not rely on transitive dependencies ◦ Use scopes when applicable ◦ ◦ ◦ ◦ Compile Runtime (e.g. JDBC Drivers) Test (e.g. JUnit, DBUnit) Provided (e.g. Java EE jars)
  • 15. Maven release plugin mvn release:prepare release:perform ◦ Verifies if you checked in everything ◦ Verifies if you have SNAPSHOT dependencies ◦ outside the current released modules ◦ Tries to build and test your modules ◦ Updates the version to the release version and tags it in SCM ◦ Recursively ◦ Checks out the tagged version and build and deploys the release version ◦ Updates the version to the next SNAPSHOT version and checks it in ◦ Recursively
  • 16. Maven release plugin prerequisites <distributionManagement> ◦ in godfather POM ◦ point to repository server (nexus) <server> with login for repository ◦ authorized to deploy ◦ in settings.xml <scm> tag ◦ Point to subversion/git/CVS
  • 17. Demo1 Command line release cascade Jenkins demo
  • 18. What to Version / What to release Could be: Individual Modules, Applications, Application System? Depends on the lifecycle of your product ◦ Do you want to deploy/upgrade a single module or application? ◦ Can you test a single module? ◦ Can you test an application without testing the rest of the application system? ◦ Can you trace bugs in one application without knowing what other applications are running?
  • 19. What if… you release individual modules Every module can have its own version Maintenance releases with individual modules ◦ Dependants can stick to release versions if they want ◦ For big refactorings you need snapshot dependencies Need big cascaded release to build a new version
  • 20. What if… you version an application system Only one version to manage Release all at once Every change need a full release
  • 21. Mix and match Release some individual modules ◦ Those that are used in multiple applications Release some applications as a whole ◦ Applications in maintenance Release some application systems ◦ With strong intra-application dependencies
  • 22. More interesting plugins http://maven.apache.org/plugins/index.html maven-help-plugin ◦ mvn help:effective-pom maven-dependency-plugin ◦ mvn dependency:tree ◦ mvn dependency:analyze ◦ mvn dependency:analyze-dep-mgmt maven-versions-plugin ◦ mvn versions:use-next-snapshots -DexcludeReactor=false -Dincludes=group:* ◦ mvn versions:update-child-modules
  • 23. Demo2 maven-help-plugin maven-dependency-plugin maven-versions-plugin
  • 24. Questions

×