[
https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359597#comment-359597
]
Mark Morris edited comment on MNG-624 at 12/23/14 4:29 PM:
-----------------------------------------------------------
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.
was (Author: morrism):
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)
