[jira] Commented: (MNG-1063) release-pom is changed too much
[ http://jira.codehaus.org/browse/MNG-1063?page=comments#action_50755 ] Brett Porter commented on MNG-1063: --- we still need to resolve some of the information (see comment above) > release-pom is changed too much > --- > > Key: MNG-1063 > URL: http://jira.codehaus.org/browse/MNG-1063 > Project: Maven 2 > Type: Bug > Components: maven-release-plugin > Reporter: Brett Porter > > > this needs a full review. > Expressions are populated that shouldn't be (only external settings should be > filled in, but not those like basedir or are otherwise path dependant like > project.file...) > basically need to use the pre-interpolation, post inheritence pom... or can > we live with the original one without inheritence and just fill in resolved > versions? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1063) release-pom is changed too much
[ http://jira.codehaus.org/browse/MNG-1063?page=comments#action_50709 ] John Casey commented on MNG-1063: - the release pom was meant to create a completely static build, to enable reproduction of a particular release's build from SCM if needed...without pollution from any changes in the environment post-release (or pre-release-where-env-is-stale, I suppose). The prompt/warning when using the release-pom.xml for release:perform is meant to keep people from releasing a completely static POM. It's possible to build using the release pom, and specify a different pom file to deploy (eg. the regular pom.xml) using a configuration parameter...but I can see where this ability is a bit dangerous. If we have the release-pom generation turned off by default (as it currently is in SVN, IIRC), then none of this is an issue, right? > release-pom is changed too much > --- > > Key: MNG-1063 > URL: http://jira.codehaus.org/browse/MNG-1063 > Project: Maven 2 > Type: Bug > Components: maven-release-plugin > Reporter: Brett Porter > > > this needs a full review. > Expressions are populated that shouldn't be (only external settings should be > filled in, but not those like basedir or are otherwise path dependant like > project.file...) > basically need to use the pre-interpolation, post inheritence pom... or can > we live with the original one without inheritence and just fill in resolved > versions? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1063) release-pom is changed too much
[ http://jira.codehaus.org/browse/MNG-1063?page=comments#action_50165 ]
Brett Porter commented on MNG-1063:
---
actually, no need to fill in the super pom - the modelVersion will control that.
currently, it warns about the deployed version having fixed versions when using
the release pom. This is an issue - we do not want that to be the case. Some
more thought is needed here. Perhaps release:perform, using deploy, defaults to
not using the release-pom, while generally building from a checkout defaults to
using it (ie, commit the release pom containing resolved versions, but
release:perform would use -f pom.xml).
Another thought is to revisit why we had release pom. If it is in fact just the
versions, then we could go back to populating an extra version tag (eg
suggestedVersion) that would be used as the suggested version in conjunction
with the given range.
The release pom was meant to capture any other environmental influences at the
time, however we don't really have a way to tell which of those actually modify
the build and which should be retained (eg profiles that attach artifacts,
${basedir}, etc).
> release-pom is changed too much
> ---
>
> Key: MNG-1063
> URL: http://jira.codehaus.org/browse/MNG-1063
> Project: Maven 2
> Type: Bug
> Components: maven-release-plugin
> Reporter: Brett Porter
>
>
> this needs a full review.
> Expressions are populated that shouldn't be (only external settings should be
> filled in, but not those like basedir or are otherwise path dependant like
> project.file...)
> basically need to use the pre-interpolation, post inheritence pom... or can
> we live with the original one without inheritence and just fill in resolved
> versions?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1063) release-pom is changed too much
[ http://jira.codehaus.org/browse/MNG-1063?page=comments#action_47638 ] Brett Porter commented on MNG-1063: --- it is necessary to fill in the super pom details, though. > release-pom is changed too much > --- > > Key: MNG-1063 > URL: http://jira.codehaus.org/browse/MNG-1063 > Project: Maven 2 > Type: Bug > Components: maven-release-plugin > Reporter: Brett Porter > > > this needs a full review. > Expressions are populated that shouldn't be (only external settings should be > filled in, but not those like basedir or are otherwise path dependant like > project.file...) > basically need to use the pre-interpolation, post inheritence pom... or can > we live with the original one without inheritence and just fill in resolved > versions? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
