You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Eric Brown (JIRA)" <ji...@codehaus.org> on 2007/02/22 11:40:32 UTC

[jira] Updated: (MNG-624) automatic parent versioning

     [ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eric Brown updated MNG-624:
---------------------------

    Attachment: MNG-624-tests.tar.gz
                MNG-624-maven-2.0.x-r507648.patch

The attached patch and 16 integration tests fixes this issue by allowing the following:
* Variable expansion works in the <parent> section of pom-s for version, groupId and artifactId
* The same elements are all optional. At the extreme, this means most times <parent/> will work.

There is a rule for this to work, however. You must have enough of your development tree on disk that maven can walk the directories (<relativePath> still works) to resolve variables and/or find inferred elements that are missing.

Implementation Notes:
* All existing and 16 new integration tests are passing. The code-path and what's going on really doesn't change for existing projects that have explicit <parent> sections.
* It passes my complex 202-module project.
* Most of what is going on is that maven now guesses and does re-interpolation later to verify (and/or) continue its inferencing. I call it "expansion" in a few places because it is more than just interpolation, profiles also have to be expanded - but the code was all there, I just refactored slightly.
* When pom-s are installed and deployed, if any part of their <parent> specification was inferred or re-expanded, it is no longer possible to simply copy the source pom.xml unmodified to the local and/or remote repository. Doing so would make it impossible to build from somewhere other than "trunk" as when building from the middle of a tree, artifacts that are elsewhere in sibling or cousin nodes of the tree are actually fetched from the repository and their parents in-turn from the repository as well. But the parents couldn't be found in the repository because the parent section was missing! So maven now detects that the parent section was missing or needed expansion due to the presence of variables and makes sure the parent section is present before writing a pom to a repository. I'm not fantastically pleased with this implementation for a couple reasons: (though it works and my vote would be to accept it as is - I doubt it is the worst ugliness in the code)
** The pom in the repository looses all comments and formatting from the original.
** The way I hooked it into the artifact and suck it back out again when installing and deploying pom-s just felt hackish. Though I really don't see any other way to pass the needed information around as this information obviously was not intended to be passed between the maven-project and maven-artifact modules in the architecture.

BTW, The reason I spent so much time on this is because I have 202 modules and release twice / month. My svn logs are littered with crap from changing version information in my 202 pom-s and I find it very annoying. Maven is a great tool, but I've never worked with or built a build system where I had to keep version information in so many places. I know there are tools to manage it, but it is still uglier than the patch I've submitted here IMO. YMMV :)

> automatic parent versioning
> ---------------------------
>
>                 Key: MNG-624
>                 URL: http://jira.codehaus.org/browse/MNG-624
>             Project: Maven 2
>          Issue Type: Improvement
>          Components: Inheritance and Interpolation
>            Reporter: Brett Porter
>         Assigned To: Brett Porter
>            Priority: Blocker
>             Fix For: 2.1.x
>
>         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 contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira