[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359597#comment-359597 ]
Mark Morris commented on MNG-624: --------------------------------- If anyone?s looking for a custom solution for this issue, we implemented a modification in-house that allows you to replace your pom.xml parent versions with a dynamic value. You basically drop an aaa-mgs-maven-overrides.jar into your apache-maven\lib directory which then intercepts the parent version right when it's read (and replaces it with a properties file value). You can take a look at the attached Maven_overrides_for_dynamic_parent_version_MGS.zip file for the details (and the jar) but here is everything at a high level (posted with permission from my director at Monster Government Solutions): 1) Change your pom.xml parent versions to look like this (all our sub-projects use this): <parent> <groupId>com.monster.mgs.terra</groupId> <artifactId>terra-parent</artifactId> <version>$MGS{branch_configs/branch.properties#snapshot.version}</version> <relativePath>../../terra/terra-parent/pom.xml</relativePath> </parent> 2) Create a single root-level branch_configs folder with a branch.properties file containing property snapshot.version=ABC-SNAPSHOT (these can be modified to your values) Now when you run any maven command, the custom code will detect the "$MGS{}" string and replace it with the value from your properties file. The overrides jar contains modified versions of the maven MavenXpp3Reader and MavenXpp3ReaderEx classes and replaces functionality in their getTrimmedValue(String) methods (which is called for almost every value in the poms). Theoretically this approach could be used in the actual maven source as a permanent implementation option but you'd want to use something more generic than "$MGS{}" and you'd probably want to pass in the pom.xml's file location (to reduce complexity, this overrides jar doesn't handle relative paths). There are also a couple other steps that are needed when using IntelliJ and Jenkins (these steps are detailed in the Dynamic_Parent_Version_MGS_Wiki_Page.pdf in the Maven_overrides_for_dynamic_parent_version_MGS.zip ). This approach got rid of all our merge headaches when merging between branches (with over 90 pom.xmls in sub-projects) so hopefully this will be useful to others as well. Also thanks in advance if this or something like it is put into the actual maven codebase. Thanks, Mark Morris. > automatic parent versioning > --------------------------- > > Key: MNG-624 > URL: https://jira.codehaus.org/browse/MNG-624 > Project: Maven > Issue Type: Improvement > Components: FDPFC, Inheritance and Interpolation > Reporter: Brett Porter > Priority: Blocker > Fix For: Issues to be reviewed for 4.x > > Attachments: Maven_overrides_for_dynamic_parent_version_MGS.zip, > MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- This message was sent by Atlassian JIRA (v6.1.6#6162)