Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gradle-Plugin #92

Open
wants to merge 14 commits into
base: master
Choose a base branch
from
Open

Gradle-Plugin #92

wants to merge 14 commits into from

Conversation

jbellmann
Copy link

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

@ktoso
Copy link
Collaborator

ktoso commented Feb 11, 2014

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
Copy link
Collaborator

ktoso commented May 24, 2014

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 ktoso force-pushed the master branch 7 times, most recently from 97e085d to 7ee11ec Compare October 21, 2014 22:05
@mvitz
Copy link

mvitz commented Nov 26, 2015

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.

@ktoso
Copy link
Collaborator

ktoso commented Nov 30, 2015

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?

@jbellmann
Copy link
Author

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 ?

@ktoso
Copy link
Collaborator

ktoso commented Dec 1, 2015

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
Copy link
Collaborator

ktoso commented Dec 1, 2015

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

@TheSnoozer
Copy link
Collaborator

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!

@mvitz
Copy link

mvitz commented Dec 1, 2015

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.

@ktoso
Copy link
Collaborator

ktoso commented Dec 1, 2015

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 pushed a commit that referenced this pull request Dec 1, 2015
This allows adding another module 'core' which contains the core logic
which can be resued for other build tools like gradle, leiningen or sbt.

Discussion for this change took place in PR #92.
@ktoso
Copy link
Collaborator

ktoso commented Dec 1, 2015

Made the "make it a lib" a ticket, #228 and marked it as "3.0"

@mvitz mvitz mentioned this pull request Jan 3, 2016
autayeu added a commit to autayeu/maven-git-commit-id-plugin that referenced this pull request Jan 3, 2016
autayeu added a commit to autayeu/maven-git-commit-id-plugin that referenced this pull request Jan 3, 2016
…plugin-specific exception to address Michael comment about modularization (git-commit-id#92)
@kamilwlf
Copy link

How to use plugin with Gradle?

@pedrorlmarques
Copy link

Hello,

What is the status of this PR?

@TheSnoozer
Copy link
Collaborator

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 git-commit-id/git-commit-id-gradle-plugin#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 git-commit-id/git-commit-id-gradle-plugin#1.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants