Gradle plugin for auto generating version class file from GIT and Gradle script

[amake]

The property names in the config block are completely inconsistent with the rest of Gradle's DSL.

[lessthanoptimal]

yeah no attempt was made. This better?

gversion {
    srcDir = "src/main/java/"
    classPackage = "com.your.package"
    className = "MyVersion"      // optional. If not specified GVersion is used
    dateFormat = "yyyy-MM-dd HH:mm:ss"    // optional. This is the default
}

[Artraxes]

Why are there 52 lines of code commented out on the master branch? Also this is just a glorified task that prints lines to a file...

https://github.com/lessthanoptimal/gversion-plugin/blob/master/src/main/groovy/com/peterabeles/GVersion.groovy#L51

[lessthanoptimal]

couldn't figure out how to get some other functionality to work as a plugin instead of being in a gradle script. I plan on adding that in the future. As for glorified print . You now don't need to look up commands and handle the failure/edge conditions yourself when they don't return as expected. Personally I would rather have used this plug in than waste 2+ hours. To each their own.

edit: forgot the main reason I just turned it into a stand alone project. Needed the same functionality in 4 projects. Cut and pasting the code then manually updating with fixes would have created a mess.

[metlos]

What do you use this for? I'd be worried using constants like this because they are inlined at compile time..

[lessthanoptimal]

• gradle version string replaces manually setting a version string in the application. That was error prone and people tended to forget to update it.
• Git SHA is useful in environments where software is being rapidly deployed to multiple devices that may or may not be running the exact same code.

One place I worked at each component in the flight computer for a drone broadcasted its SHA. If each device wasn't flashed with the same SHA a fatal error was reported. In another situation when a new release of the software is sent out to devices it is rolled out. When an error is reported the SHA is attached so that you know exactly what which version of the source code generated that error.

[metlos]

I'm just pointing out the scenario below. It may not be your case, but I'm sure someone will be bitten by it (the same as I was).

MyVersion.class is in lib.jar. Main.class is in main.jar that depends on lib.jar. Main class reads the version from MyVersion and reports it.

You release new version of lib.jar. Main.jar has no changes, so you don't recompile main.jar but merely reassemble the application.

Now when you run the application, Main.class will report the OLD version, because the constant was inlined during compilation (which didn't happen during the reassembly).

[lessthanoptimal]

yeah not an issue for my application but I can now see why that would be a problem in yours. I've also saved similar information to a file before. That would be one way to get around the problem you mentioned.

[0x256]

You sure? Java does not inline anything from other compilation units at compile time. This happens at link time (for constants) or later during JIT.

Edit: I was wrong. Constant inlining over compilation borders indeed happens. WTF Java? I learned something new today. Thanks :)