[
https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287554#comment-287554
]
Stanilslav Spiridonov edited comment on MNG-624 at 1/5/12 4:40 PM:
-------------------------------------------------------------------
I have one idea.
The main point of parent POM is collect all similar modules settings (property,
dependency, plugins, etc.) in one place (with possible hierarchy) and make the
DEVELOPMENT of project with multiple project more simple. All these have sense
only on source level. After the build and install/deploy artifact to local or
remote repository the parents poms only produce complications without any
additional value (is not?). So my suggestion is to install/deploy artifacts
with effective POM, now the real one. So the parent pom will exist only on
source level and disappear in produced artifact. It is backward compatible with
current implementation and will not break anything in existing projects.
May be is is stupid, but I believe it will simplify the issue with parent POM
and will allow to find the right solution. For example after that the SNAPSHOTS
artifact will not refereeing the SNAPSHOT parent, so even SNAPSHOTS will be
more fixed and stable.
was (Author: foal):
I have one idea.
The main point of parent POM is collect all similar modules settings (property,
dependency, plugins, etc.) in one place (with possible hierarchy) and make the
DEVELOPMENT of project with multiple project more simple. All these have sense
only on source level. After the build and install/deploy artifact to local or
remote repository the parents poms only produce complications without any
additional value (is not?). So my suggestion install deploy artifacts with
effective POM, now the real. So the parent poms will exist only on source level
and disappear in produced artifact. It is backward compatible with current
implementation and will not break anything in existing projects.
May be is is stupid, but I believe it will simplify the issue with parent POM
and will allow to find the right solution. For example after that the SNAPSHOTS
artifact will not refereeing the SNAPSHOT parent, so even SNAPSHOTS will be
more fixed and stable.
> automatic parent versioning
> ---------------------------
>
> Key: MNG-624
> URL: https://jira.codehaus.org/browse/MNG-624
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Inheritance and Interpolation
> Reporter: Brett Porter
> Assignee: Ralph Goers
> Priority: Blocker
> Fix For: 3.1
>
> Attachments: 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
