My view is that there are places where stuff can be inferred, such as groupId and version of children can be inferred *if and only if* the child is always checked out with the parent (at the specified relative path)... There are plans to tackle those cases.
There is, though a bit of a dual purpose to the Pom... One which may have to be split... On the one hand the deployed Pom should be fully resolved, and properties at those xpaths won't work... On the other hand, for inheritance to work we need the deployed Pom to be fully unresolved... >From my point of view, those xpaths should never allow property expansion, but more smarts in inferring based on other Pom files would be good... Version numbers coming from a SCM branch name is a bad smell to me... So I would not favour without a very good case being made On Wednesday, 7 March 2012, Seth Call <[email protected]> wrote: > Hi Stephen, > > Thank you for clarifying. That tells me what constraints I have to work > with, which is a big help. > > Is there any intent to change these restrictions? I don't think anyone > wants to change version mid-run (I've seen in other threads where you > mention something about the reactor getting confused if the version were to > change mid-run?), but I think there is a desire to change it 'at the start' > of maven process execution in a more dynamic-yet-friendly way than just > 'pass it in via command line'. > > The desire here, to be clear, is to give developers a correct default > behavior when they type 'mvn clean install', and to never force them to type > -Dproject.version = something-wrong > > Matt (posted after you) wanted to do something similiar point with the > buildnumber plugin, too. > > Seth > > > > > > > -- > View this message in context: http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5545298.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
