Closed plevart closed 12 years ago
Very interesting idea. Now I'm composing git properties into buildnumber after extracting them from Manifest. But this approach: "add plugin to pom - get ready-to-use buildnumber" may be more convenient.
I'm not ready to decide whether JS is overkill here. I'll not merge it right now, but definitely will play with JS. Maybe to add more generic git.buildnumber
property that may be composed by input JS snippet.
...and as I proposed, you can have both (the convenient ready-to-use predefined git.XXX properties and 0..* additional properties composed by input JS snippets). As it's written now, It's non-obtrusive. It doesn't impose the overhead of JS engine initialization if no JS properties are configured and, as JS engine is not part of Java spec (the generic scripting API is), you can still use the plug-in on the platform that doesn't support JS - without the JS properties.
I added your changes without merging. I simplified it to only one git.buildnumber
property (made it less powerful of course). I mention you as author of these changes (under 'Create ready to use buildnumber' header), please comment if you don't like such attribution to rather different implementation. Otherwise I'll close this request.
It's better now that you can access individual BuildNumber fields directly as JavaScript variables as opposed to my way of indirection through BuildNumber object. I somehow liked the approach where you could have multiple properties, but I see that you wish to maintain the duality of maven and ant plug-ins where the features are more or less implemented in both. The ant plug-in does not support changing property names and JavaScript customization of git.buildnumber property though, so If there is a way to specify those, perhaps you could reconsider enabling multiple JavaScript custom properties in the future. As it is now, it is usable for my needs.
Here's another hack from my part. Use it if you want or drop it.
When I build assemblies with maven, I want generated file names to reflect Git repository info of the source version. For example, we use the following assembly.xml:
I want the value of property git.tagOrShortRevision to hold Git tag if the revision I am building is tagged or a short revision id if there is no tag available. I could hard-code that logic into the plug-in itself but that would be of limited use for other users. Rather I came up with a more generic approach which you can review in this pull request. The above property is configured in the pom.xml as follows:
Is this too much?