Fwd: [JIRA] (OSSRH-2573) Gradle Android Plugin - Android plugin for the Gradle build system

[Ealden Escañan]

I'll prepare the codebase so we can push a 1.1.0-SNAPSHOT to the snapshot repository.

---------- Forwarded message ----------
From: Juven Xu (JIRA) <iss...@sonatype.org>
Date: Wed, Dec 14, 2011 at 3:08 PM
Subject: [JIRA] (OSSRH-2573) Gradle Android Plugin - Android plugin for the Gradle build system
To: eal...@gmail.com



    [ https://issues.sonatype.org/browse/OSSRH-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juven Xu resolved OSSRH-2573.
-----------------------------

   Resolution: Fixed

Configuration has been prepared, now you can:
* Deploy snapshot artifacts into repository https://oss.sonatype.org/content/repositories/snapshots
* Deploy release artifacts into the staging repository https://oss.sonatype.org/service/local/staging/deploy/maven2
* Promote staged artifacts into repository 'Releases'
* Download snapshot and release artifacts from group https://oss.sonatype.org/content/groups/public
* Download snapshot, release and staged artifacts from staging group https://oss.sonatype.org/content/groups/staging

please comment on this ticket when you promoted your first release, thanks

> Gradle Android Plugin - Android plugin for the Gradle build system

> ------------------------------------------------------------------

>
>                 Key: OSSRH-2573
>                 URL: https://issues.sonatype.org/browse/OSSRH-2573
>             Project: Community Support - Open Source Project Repository Hosting
>          Issue Type: New Project
>            Reporter: Ealden Esto E. Escanan
>            Assignee: Juven Xu
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.sonatype.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

--
Ealden Escañan
http://ealden.net

[Fabio Da Soghe]

Great news! Congratulations :-D

But... I'ld vote for a stable release: the plugin is in good shape for me, so we could do a 1.1.0 release? Is anyone having problems with it?

2011/12/14 Ealden Escañan <eal...@gmail.com>

[Ealden Escañan]

Hi,

On Wed, Dec 14, 2011 at 4:39 PM, Fabio Da Soghe <fabiod...@gmail.com> wrote:

But... I'ld vote for a stable release: the plugin is in good shape for me, so we could do a 1.1.0 release? Is anyone having problems with it?

Yeah, I was actually thinking of putting something in snapshot first, try it out, then doing a 1.1.0.

[Fabio Da Soghe]

2011/12/14 Ealden Escañan <eal...@gmail.com>

Ok great.

[Marcin Erdmann]

Thanks for that Ealden! This will motivate me even more to work on
releasing the Gradle Discobot plugin. I just have to verify if it all
works for me with the latest SDK, as I've seen you guys talking here
that there were some major compatibility problems you had to fix for
1.1.0.

Marcin

[Ladislav Thon]

I'll prepare the codebase so we can push a 1.1.0-SNAPSHOT to the snapshot repository.

Awesome!

LT 

[Ealden Escañan]

Hi,

On Wed, Dec 14, 2011 at 3:14 PM, Ealden Escañan <eal...@gmail.com> wrote:

I'll prepare the codebase so we can push a 1.1.0-SNAPSHOT to the snapshot repository.

Looks like I got a snapshot release to the snapshot repository. The updated buildscript entry would be:

buildscript {

    repositories {

        maven {

            url 'https://oss.sonatype.org/content/groups/public'

        }

    }

    def gradleAndroidPluginVersion = '1.1.0-SNAPSHOT'

    dependencies {

        classpath "org.gradle.api.plugins:gradle-android-plugin:$gradleAndroidPluginVersion"

    }

}

Once we push to staging and then promote it to release we should be able to remove repositories {} :-)

I opened a pull request to track 1.1.0 release preparations.  I've listed down the things that needs to be done but I'll probably merge this to master after 1.1.0 is done (so I can verify if the changes to buildscript would actually work with the released version).  Let me know if I forgot anything:

https://github.com/jvoegele/gradle-android-plugin/pull/37

After 1.1.0 I'll figure out how we can all create releases so anyone can upload a new release as needed.

Best regards,

[Ealden Escañan]

On Thu, Dec 15, 2011 at 9:45 AM, Ealden Escañan <eal...@gmail.com> wrote:

Once we push to staging and then promote it to release we should be able to remove repositories {} :-)

On second though, I think we'll still need repositories { mavenCentral() } at the very least - I'll check when I stage 1.1.0 and before I merge the pull request to master.

[Ealden Escañan]

Hi,

I've staged it already.  Should I release?

https://oss.sonatype.org/content/repositories/orggradleapiplugins-150/

[Ladislav Thon]

After 1.1.0 I'll figure out how we can all create releases so anyone can upload a new release as needed.

All people that should be able to release new versions have to have an account at Sonatype JIRA. Then you will ask Sonatype people (via creating an JIRA issue) to add specific user accounts for the Gradle Android Plugin project.

For example, when I wanted do get ddmlib into Maven Central, I created an Sonatype JIRA account named "ladicek" and Rob Manning then created this issue https://issues.sonatype.org/browse/OSSRH-1420 for me getting the privileges.

On second though, I think we'll still need repositories { mavenCentral() } at the very least

Yes, you need to do repositories { mavenCentral() } for stuff that is in Maven Central :-)

LT

[Ealden Escañan]

Hi,

On Thu, Dec 15, 2011 at 5:36 PM, Ladislav Thon <lad...@gmail.com> wrote:

After 1.1.0 I'll figure out how we can all create releases so anyone can upload a new release as needed.

All people that should be able to release new versions have to have an account at Sonatype JIRA. Then you will ask Sonatype people (via creating an JIRA issue) to add specific user accounts for the Gradle Android Plugin project.

For example, when I wanted do get ddmlib into Maven Central, I created an Sonatype JIRA account named "ladicek" and Rob Manning then created this issue https://issues.sonatype.org/browse/OSSRH-1420 for me getting the privileges.

Gotcha.  I'll take care of the issues once I get the Sonatype accounts of the other guys.

[Ladislav Thon]

I've staged it already.  Should I release?

https://oss.sonatype.org/content/repositories/orggradleapiplugins-150/

This is a little hurry for my taste. I think there should be this process:

1. We agree that current state of jvoegele/master is in the right shape to release. I think we have this agreement now, but if anyone feels different, please raise your voice.

2. Someone must update the README if necessary (changelog is always necessary :- ) ).

3. Then, the "release manager" updates the version property in build.gradle, creates a tag in git repository from this commit, then changes the version property again. All this has to be in jvoegele/master, that is the canonical repository. We can't release from some other repository, this would be a mess.

4. The "release manager" creates the artifacts _from the tag_, uploads it to Sonatype and releases it from there to Maven Central.

I don't think that this is overly complicated, it is basically what we were always doing (except of step 4, Jason uploaded the artifacts to his own Maven repo) and we should stick with it.

On my side, I think that the PR 37 is _almost_ ready to go in. What is missing:

1. Updating a changelog. This must be done _before_ the commit that changes the version property.

2. After the commit that changes the version property to 1.1.0, there should be a commit that changes it to 1.1.1-SNAPSHOT.

Then, you will create a tag pointing to the exact commit that changes the version to 1.1.0. You will build the artifacts from this tag. As said, this tag and everything must be in jvoegele repo.

LT

[Ealden Escañan]

Hi,

On Thu, Dec 15, 2011 at 5:54 PM, Ladislav Thon <lad...@gmail.com> wrote:

I've staged it already.  Should I release?

https://oss.sonatype.org/content/repositories/orggradleapiplugins-150/

This is a little hurry for my taste. I think there should be this process:

No problem.  I'll just drop this and create a new one.

 

On my side, I think that the PR 37 is _almost_ ready to go in. What is missing:

1. Updating a changelog. This must be done _before_ the commit that changes the version property.

Hmm I may have to rearrange the commits from the branch...

 

2. After the commit that changes the version property to 1.1.0, there should be a commit that changes it to 1.1.1-SNAPSHOT.

Then, you will create a tag pointing to the exact commit that changes the version to 1.1.0. You will build the artifacts from this tag. As said, this tag and everything must be in jvoegele repo.

Gotcha.  There are some lines that are commented out in build.gradle that are related to releasing (signing and repository) so I figured I'll include uncommenting them together with the version change to 1.1.0, and then comment them out again in the next commit.

Also, do we create a 1.1.0-maint branch, with the version at 1.1.1-SNAPSHOT, with master set to 1.2.0-SNAPSHOT?

[Ladislav Thon]

1. Updating a changelog. This must be done _before_ the commit that changes the version property.

Hmm I may have to rearrange the commits from the branch...

True. The point is that there must be only one commit that contains the version property '1.1.0', so that you can precisely point to the state of the repository at any time and know what was released as 1.1.0.

 

 

2. After the commit that changes the version property to 1.1.0, there should be a commit that changes it to 1.1.1-SNAPSHOT.

Then, you will create a tag pointing to the exact commit that changes the version to 1.1.0. You will build the artifacts from this tag. As said, this tag and everything must be in jvoegele repo.

Gotcha.  There are some lines that are commented out in build.gradle that are related to releasing (signing and repository) so I figured I'll include uncommenting them together with the version change to 1.1.0, and then comment them out again in the next commit.

I don't know exactly how Jason did it, but I think that the buildscript could be rearanged so that you don't need commenting out release-related stuff. For example, if the task graph contains a task called "release", apply some configuration, otherwise apply different configuration.

 

Also, do we create a 1.1.0-maint branch, with the version at 1.1.1-SNAPSHOT, with master set to 1.2.0-SNAPSHOT?

Probably good idea, but not sure if it's needed now. We can do it anytime in the future.

LT

[Fabio Da Soghe]

So, what is described here could be inserted in a wiki page titled "Release procedure", right?

+1 for me to release current master as 1.1.0.

2011/12/15 Ladislav Thon <lad...@gmail.com>

[Ladislav Thon]

So, what is described here could be inserted in a wiki page titled "Release procedure", right?

I think so. I did never release a version of Gradle Android Plugin, but I believe this is what we and Jason were basically doing :-)

LT

[Ealden Escañan]

HI,

On Thu, Dec 15, 2011 at 7:07 PM, Ladislav Thon <lad...@gmail.com> wrote:

True. The point is that there must be only one commit that contains the version property '1.1.0', so that you can precisely point to the state of the repository at any time and know what was released as 1.1.0.

Thanks for the inputs.  I've made the necessary changes in PR 37.  Once merged to master I'll tag and then use it as based for the actual 1.1.0 release.

 

Gotcha.  There are some lines that are commented out in build.gradle that are related to releasing (signing and repository) so I figured I'll include uncommenting them together with the version change to 1.1.0, and then comment them out again in the next commit.

I don't know exactly how Jason did it, but I think that the buildscript could be rearanged so that you don't need commenting out release-related stuff. For example, if the task graph contains a task called "release", apply some configuration, otherwise apply different configuration.

 

Apparently the Gradle docs includes dealing with this situation, and I just needed to read some more :-).  The build will only be signed if it is a "release" build, meaning if the version does not have SNAPSHOT in it.

Another earlier problem was if gradle.properties was not present, hence the build script couldn't find sonatypeUsername and sonatypePassword even if uploadArchives wasn't called.  I worked around this by checking if these properties are present and only using them if they are.

 

Also, do we create a 1.1.0-maint branch, with the version at 1.1.1-SNAPSHOT, with master set to 1.2.0-SNAPSHOT?

Probably good idea, but not sure if it's needed now. We can do it anytime in the future.

Makes sense.  PR 37 now ends with 1.1.1-SNAPSHOT.

[Ealden Escañan]

Hi,

+1 for me on the wiki page on releasing.

[Jason Voegele]

On Dec 15, 2011, at 6:22 AM, Ladislav Thon wrote:

So, what is described here could be inserted in a wiki page titled "Release procedure", right?

I think so. I did never release a version of Gradle Android Plugin, but I believe this is what we and Jason were basically doing :-)

Hi all, I too am in favor of a 1.1.0 release. Just to provide a little bit of clarification on how previous releases have worked, here is part of a previous message to this list that describes how I had done releases:

1. Make sure local repo is up to date.
2. Update README with any relevant information for the release.
3. Update version number in build.gradle to the release version.
4. Run gradle clean uploadArchives*
5. Tag the release
6. Update version in build.gradle to the next SNAPSHOT version.
7. Update the wiki on GitHub.

* Note: due to an unfortunate bug somewhere in the deployment stack, I cannot directly upload to the remote repository using Gradle. I have to rsync my entire Maven repo to a local tmp directory, then do the gradle uploadArchives thing to this local tmp directory, then rsync the whole updated repo back to the remote site. That's why there is a line in the build.gradle that says repository(url: "file:///tmp/maven2")

This should be adapted to use Maven Central instead of jvoegele.com, and also should include a step to update the CHANGELOG, but other than that I think the process is fairly sound.

-- 

Jason Voegele

A student who changes the course of history is probably taking an exam.

[Ealden Escañan]

Hi,

On Thu, Dec 15, 2011 at 9:06 PM, Jason Voegele <jason....@gmail.com> wrote:

Hi all, I too am in favor of a 1.1.0 release. Just to provide a little bit of clarification on how previous releases have worked, here is part of a previous message to this list that describes how I had done releases:

Thanks for the clarification.  PR 37 should have all of these already.  To be clear, I'm waiting for a go signal to merge PR 37 to master.  Once that's done I'll:

1. Tag the specific commit that releases 1.1.0
2. Build the 1.1.0 release and stage to Sonatype
3. Release 1.1.0 to Maven Central

[Ladislav Thon]

Thanks for the clarification.  PR 37 should have all of these already.  To be clear, I'm waiting for a go signal to merge PR 37 to master.  Once that's done I'll:

1. Tag the specific commit that releases 1.1.0
2. Build the 1.1.0 release and stage to Sonatype
3. Release 1.1.0 to Maven Central

Looked at the diffs and it looks okay! Go ahead with 1 and 2, then let us know to take a look at it (let's make sure it all goes well), then 3 :-)

Oh... and did I mention that you are doing great work? :-) Thanks!

LT 

[Ealden Escañan]

Hi,

On Fri, Dec 16, 2011 at 5:07 AM, Ladislav Thon <lad...@gmail.com> wrote:

Looked at the diffs and it looks okay! Go ahead with 1 and 2, then let us know to take a look at it (let's make sure it all goes well), then 3 :-)

Gotcha.  PR 37 merged, tagged, built, and staged for release:

https://github.com/jvoegele/gradle-android-plugin/tags

https://oss.sonatype.org/content/repositories/orggradleapiplugins-172/

This is a copy of the buildscript I am using:

buildscript {

    repositories {

        maven {

            url 'https://oss.sonatype.org/content/repositories/orggradleapiplugins-172'

        }

    }

    def gradleAndroidPluginVersion = '1.1.0'

    dependencies {

        classpath "org.gradle.api.plugins:gradle-android-plugin:$gradleAndroidPluginVersion"

    }

}

 

Oh... and did I mention that you are doing great work? :-) Thanks!

This is exciting stuff :-)

[Ladislav Thon]

Gotcha.  PR 37 merged, tagged, built, and staged for release:

https://github.com/jvoegele/gradle-android-plugin/tags

https://oss.sonatype.org/content/repositories/orggradleapiplugins-172/

Current master builds for me, tests are OK.

My small application builds fine with Gradle Android Plugin imported like this:

buildscript {

    repositories {

        maven {

            url 'https://oss.sonatype.org/content/repositories/orggradleapiplugins-172'

        }

    }

    dependencies {

        classpath 'org.gradle.api.plugins:gradle-android-plugin:1.1.0'

    }

}

apply plugin: "android"

But it keeps failing on Failure [INSTALL_PARSE_FAILED_UNEXPECTED_EXCEPTION] when trying to install to the emulator.

Let's wait till someone confirms it works for him, I'll try to investigate why it keeps failing for me (and it didn't not so long ago)...

LT

[Ealden Escañan]

Hi,

On Fri, Dec 16, 2011 at 5:48 AM, Ladislav Thon <lad...@gmail.com> wrote:

Current master builds for me, tests are OK.

My small application builds fine with Gradle Android Plugin imported like this:

buildscript {

    repositories {

        maven {

            url 'https://oss.sonatype.org/content/repositories/orggradleapiplugins-172'

        }

    }

    dependencies {

        classpath 'org.gradle.api.plugins:gradle-android-plugin:1.1.0'

    }

}

apply plugin: "android"

But it keeps failing on Failure [INSTALL_PARSE_FAILED_UNEXPECTED_EXCEPTION] when trying to install to the emulator.

Let's wait till someone confirms it works for him, I'll try to investigate why it keeps failing for me (and it didn't not so long ago)...

That's very strange.  Works for me locally using androidEmulatorStart and androidInstall.

Can someone else confirm?

[Ladislav Thon]

But it keeps failing on Failure [INSTALL_PARSE_FAILED_UNEXPECTED_EXCEPTION] when trying to install to the emulator.

Guys, I'm terribly sorry for this stupid false alarm. I installed Java 7 and didn't realize that Android SDK isn't compatible with it. After switching back to Java 6, it works OK.

I'm +1 on releasing 1.1.0 to Maven Central.

Also, if someone wants to do so, it would be nice to detect Java 7 and report a warning early in the build.

LT

[Ealden Escañan]

Hi,

On Sat, Dec 17, 2011 at 10:52 PM, Ladislav Thon <lad...@gmail.com> wrote:

I'm +1 on releasing 1.1.0 to Maven Central.

Do we need a certain number of votes to release?

[Ladislav Thon]

I'm +1 on releasing 1.1.0 to Maven Central.

Do we need a certain number of votes to release?

I don't think we are doing some formal voting process. We already agreed that current master is OK, so I think you should feel free to release as you will.

LT 

[Ealden Escañan]

On Sun, Dec 18, 2011 at 6:50 PM, Ladislav Thon <lad...@gmail.com> wrote:

I don't think we are doing some formal voting process. We already agreed that current master is OK, so I think you should feel free to release as you will.

Oh man.

I just realized that while we set the package to org.gradle.api.plugins, I didn't change the packages in the source.  Sorry for the major oversight!  Do we roll out a 1.1.1 or something?

[Marcin Erdmann]

On 12/18/2011 05:05 PM, Ealden Esca�an wrote:
> Oh man.
>
> I just realized that while we set the package to org.gradle.api.plugins,
> I didn't change the packages in the source. Sorry for the major
> oversight! Do we roll out a 1.1.1 or something?

I don't think we need or even want to change the packages. Change
packages is always a bad idea in my opinion as anybody who has directly
used the classes in their code (like me in Discobot Plugin) will get his
code broken and will have to update all imports... But maybe I'm the
only one thinking like that...

Marcin

P.s. You're doing a great job with releasing it!

[Ladislav Thon]

I just realized that while we set the package to org.gradle.api.plugins,
I didn't change the packages in the source.  Sorry for the major
oversight!  Do we roll out a 1.1.1 or something?

I don't think we need or even want to change the packages.

Second to that. Changing packages is not needed, IMHO.

LT 

[Ealden Escañan]

Hi,

On Mon, Dec 19, 2011 at 3:10 AM, Marcin Erdmann <erd...@gmail.com> wrote:

On 12/18/2011 05:05 PM, Ealden Escañan wrote:

Oh man.

I just realized that while we set the package to org.gradle.api.plugins,
I didn't change the packages in the source.  Sorry for the major
oversight!  Do we roll out a 1.1.1 or something?

I don't think we need or even want to change the packages. Change packages is always a bad idea in my opinion as anybody who has directly used the classes in their code (like me in Discobot Plugin) will get his code broken and will have to update all imports... But maybe I'm the only one thinking like that...

Good point, I haven't considered that.

I do think the packages should align with the new ones eventually, but will need to be planned more and announced so other projects that deal with it directly can manage.  I did a test rename locally and figured that more thought should go into it... not to mention that I was breaking tests for some reason.

I'll leave 1.1.0 as is.

[Ealden Escañan]

:-).

Already pointed to mavenCentral() and was able to retrieve the artifacts.

---------- Forwarded message ----------
From: Juven Xu (JIRA) <iss...@sonatype.org>
Date: Mon, Dec 19, 2011 at 1:28 PM
Subject: [JIRA] (OSSRH-2573) Gradle Android Plugin - Android plugin for the Gradle build system
To: eal...@gmail.com



    [ https://issues.sonatype.org/browse/OSSRH-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juven Xu closed OSSRH-2573.
---------------------------


Central sync is activated for org.gradle.api.plugins, it runs about every 2 hours.

> Gradle Android Plugin - Android plugin for the Gradle build system

> ------------------------------------------------------------------

>
>                 Key: OSSRH-2573
>                 URL: https://issues.sonatype.org/browse/OSSRH-2573
>             Project: Community Support - Open Source Project Repository Hosting
>          Issue Type: New Project
>            Reporter: Ealden Esto E. Escanan
>            Assignee: Juven Xu
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.sonatype.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira