git-commit-id-maven-plugin icon indicating copy to clipboard operation
git-commit-id-maven-plugin copied to clipboard

Gradle-Plugin

Open jbellmann opened this issue 11 years ago • 14 comments

Hi Konrad,

I use your maven-commit-id-plugin in my projects. Thank you for that.

But I also use gradle more and more and I was looking for something similar in the gradle-world. I couldn' t find a plugin. So I decided to try to reuse your code, refactor some pieces to extract code into a 'common'-module and reuse that in the gradle-plugin.

This pullrequest seems to be big, but this comes mostly because I moved files into different folders to match maven-multi-module directory layout. So please have look. It is not that much.

I'm not finally done. There are some tasks to do for me (fix the test I set to Ignore).

How would someone use the gradle-plugin.

buildscript {
    repositories {
            mavenLocal()
            jcenter()
    }
    dependencies {
            classpath("pl.project13.maven:git-commit-id-plugin-gradle:2.1.10-SNAPSHOT")
    }
}

project("aSubProject"){

        apply plugin: "git-commit-id"


    // we can pick up this file in the app
    task createBuildInfoFile << {
        def buildInfoFile = new File("$buildDir/build-info.properties")
        Properties properties = new Properties();
        properties.setProperty('version', project.version.toString())
        properties.setProperty('timestamp', project.buildTimeStamp)
                // the plugin adds the information to the systemproperties at the moment
        properties.setProperty('git.commit.id', System.getProperty('git.commit.id'))
        properties.store(buildInfoFile.newWriter(), null)
    }

       // or in MANIFEST
    jar {
            manifest.attributes["Created-By"] =
                    "${System.getProperty("java.version")}        (${System.getProperty("java.specification.vendor")})"
            manifest.attributes["Implementation-Title"] = subproject.name
            manifest.attributes["Implementation-Version"] = subproject.version
                        // as above get it from systemproperties
                        manifest.attributes["git.commit.id"] = "${System.getProperty("java.version")}"
        }
}

The big question is, are you willing to accept the change if I put some more work into it?

If not, no problem. I will drive my own little project then because I need this plugin (now).

Thank you Jörg

jbellmann avatar Feb 11 '14 10:02 jbellmann

Hi Jörg! I really like the idea, and in fact I wanted to do this for a while too, but never got to it. In my case it's sbt, since I've been "a scala guy" for around 3 years now, and don't use maven too much recently.

I'll have a look at this PR and let's work towards modularising this :-) Also, we could release the "however we call the core module", separately to maven central, which would make it even easier to use for outside libs. :-)

So - am I happy to pull this in, definitely! Will give more comments once I look over the code :-)

ktoso avatar Feb 11 '14 14:02 ktoso

Hi @jbellmann, sorry I was not able to take care of this previously. Are you still interrested in getting this merged? Or am I on my own with this PR now? :)

ktoso avatar May 24 '14 22:05 ktoso

Is there still interest in this? I need the same functionality in leiningen and would like to reuse some code ;-) I'm willing helping here.

mvitz avatar Nov 26 '15 18:11 mvitz

I would definitely be interested in seeing it happen, sadly cannot devote the time to it right now.. What needs to be done is splitting up the plugin into a library, and the plugin, then others can depend on it and we'll have a family of plugins for different build tools :)

Do you think you could help out with trying to split it out as a separate module like that?

ktoso avatar Nov 30 '15 21:11 ktoso

Let's start this. Maybe we got it working before 2 years are over ;-)

Would it help if I try to get this PR 'mergeable' again ?

jbellmann avatar Dec 01 '15 00:12 jbellmann

I have just checked out your branch @jbellmann and in general the direction is exactly what we need here I think. Splitting up into common / gradle / maven / lein / sbt(?) modules.

Some other shuffling around needs to be done, but rather mechanical AFAICS – for example common should contain pl.project13.git.commit.id.* stuff, and not mention maven explicitly etc... But I think it's doable.

Would you be willing to give reviving this PR a shot @jbellmann and we'll try to take it from there? I promise to this time be on time with reviewing and merging (I'm sorry I wasn't able to last time this PR was worked on), I'm able carve out enough time for that and minor help, most likely not pulling through the entire thing though.

We could fork off from the master branch and attempt to get this work onto a modularization branch, where we'll aggressively merge changes, and once happy, call it done and merge to master and release (yay!). That's a pretty nice/big move – I think it would warrant calling it a 3.0 even. Sounds like a good plan?

// I created the modularization-effort it directly forked from the current master. Let's put our work towards the modularization over there, so it does not interfere 2.x maintenance.

Also, cc @TheSnoozer for your opinion about this – sounds exciting?

ktoso avatar Dec 01 '15 00:12 ktoso

(I'm somewhat familiar with gradle and lein, but will need your help guys to maintain those – hope you're up for that? :smile:)

ktoso avatar Dec 01 '15 00:12 ktoso

This sounds very exiting :-) I could merge and review too :-) Well I would be kind a new to gradle too but I'm exited so let's go for it! Branch sounds perfect for this!

TheSnoozer avatar Dec 01 '15 00:12 TheSnoozer

I would maintain this for leiningen. Maybe this should happen in a separate repo as leiningen plugins are build with leiningen itself. Alternative option would be to have a folder in this repo.

mvitz avatar Dec 01 '15 07:12 mvitz

Thanks for stepping up @mvitz! I don't mind either solutions – happy to change repo name for example and keep other lang plugins in here, or have you guys maintain the other tools separately. Maintaining separately most likely will detach the release cycles, so release of maven plugin wouldn't be blocked by missing something in gradle plugin and vice versa, so having separate repos makes sense I think (though we risk diverging functionality more then, maybe not too bad).

Most important is making this plugin a plugin "and library" :)

ktoso avatar Dec 01 '15 09:12 ktoso

Made the "make it a lib" a ticket, https://github.com/ktoso/maven-git-commit-id-plugin/issues/228 and marked it as "3.0"

ktoso avatar Dec 01 '15 17:12 ktoso

How to use plugin with Gradle?

kamilwlf avatar Jun 26 '17 13:06 kamilwlf

Hello,

What is the status of this PR?

pedrorlmarques avatar Oct 06 '20 08:10 pedrorlmarques

Wow, I can't believe it's getting close to the 10 year (TEN YEAR HOLY COW) anniversary of this ticket. Well it's open source and I can only commit free time here when I actually have time free...but anyhow I think the large chunk of making the code pieces an actual module are now complete and are actually a separate project now https://github.com/git-commit-id/git-commit-id-plugin-core.

I now have created https://github.com/git-commit-id/git-commit-id-gradle-plugin/issues/1 to officially track this request. The maven plugin as the name of this project suggest will not work with maven and not gradle. So if you are still interested, please follow https://github.com/git-commit-id/git-commit-id-gradle-plugin/issues/1.

I will only close this issue once the first prototype of the gradle plugin is available. May take some time :-)

TheSnoozer avatar Apr 12 '23 22:04 TheSnoozer