Maven Central (was Re: Version 1.1.0)

[Ealden Escañan]

Hi,

On Thu, Dec 1, 2011 at 8:36 PM, Ealden Escañan <eal...@gmail.com> wrote:

Is it just me, or is http://codehaus.org not accessible?

Looks like I can access Codehaus again, and took a look at their project migration page which looks too tedious to do.

One of the projects that we use for work, AndroidAnnotations, is now in Maven Central, so I took a look at how they did it and they went with the Sonatype route (guide).  Looks much simpler than via Codehaus.

I'll start with this route, and send other the POM that I plan to include for it.  Let me know if there are any problems with this :-).

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

[Fabio Da Soghe]

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

It seems ok to me.

Only one thing: in the <developers> tag, I'ld add all the people that has commit right on the official repository.

Who knows for sure this list? Jason? Maybe we could do a quick listing here...

[Ladislav Thon]

This is absolutely awesome!

I looked at the rules for getting stuff into Maven Central (via Sonatype, too, since I already went through this way with ddmlib from Android SDK) and didn't exactly understand how are Gradle plugins supposed to get there. All of them depend on Gradle, which itself isn't in Maven Central, so they are not supposed to get there either. But I know that a lot of Gradle plugins in fact ARE in Maven Central, so it's doable... somehow. I'm glad that Ealden took the chance.

I'm not going to tell you how to do it, but I think it would be great if the POM would be generated by our build (Gradle is capable of that) and the artifacts as well (Gradle can even sign them: http://www.gradle.org/signing_plugin). But if you decide to do it in other way, that's fine too.

LT

[Matthias Käppler]

Hi,

I have worked with Sonatype's community Nexus before for my Signpost
OAuth library. I didn't find the process to be that simple to be
honest. They have very strict requirements on your POM (they need, for
instance, a fingerprint for every artifact), and although your
snapshot and release repos are self-managed, I never understood how
you get something on Central. In the beginning it seemed to be
automatic, i.e. whenever I released to my releases repo it would show
up on Central after a while. That stopped working at some point,
however, and I've never received response from Sonatype support why
that is.

So, I think Sonatype is great for a do-it-yourself hosted platform,
but don't expect things to always be smooth and straight forward.

-Matthias

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

--
-Matthias

[Jason Voegele]

On Dec 5, 2011, at 4:19 AM, Fabio Da Soghe wrote:
> Only one thing: in the <developers> tag, I'ld add all the people that has commit right on the official repository.
> Who knows for sure this list? Jason? Maybe we could do a quick listing here...

The current list on GitHub is:

* jvoegele (Jason Voegele)
* ncarroll (Nick Carroll)
* kaeppler (Matthias Käppler)
* think01 (Fabio Da Soghe)
* Ladicek (Ladislav Thon)

I believe that there are a couple of others out there that should be added to the list (Ealden and Marcin, maybe others?). Can someone give me the list of GitHub IDs for anyone who should have commit rights?

--
Jason Voegele
Keep the number of passes in a compiler to a minimum.
-- D. Gries

[Ladislav Thon]

I believe that there are a couple of others out there that should be added to the list (Ealden and Marcin, maybe others?). Can someone give me the list of GitHub IDs for anyone who should have commit rights?

ealden (Ealden Escañan)
erdi (Marcin Erdmann)

LT

[Marcin Erdmann]

Thx for the commit rights, I've already received a confirmation email
from github. I will use them with care! :)

Marcin

[Jason Voegele]

Thanks, I've added them both as collaborators.

If we are going to start publishing to Maven Central repository I will stop adding releases to jvoegele.com. Are we in a position to do that now, and if so who will be doing the build and push? Is that something I should do myself, or does someone else want to take a crack at it?

-- 

Jason Voegele

While it may be true that a watched pot never boils, the one you don't

keep an eye on can make an awful mess of your stove.

-- Edward Stevenson

[Fabio Da Soghe]

2011/12/5 Jason Voegele <jason....@gmail.com>

On Dec 5, 2011, at 10:07 AM, Ladislav Thon wrote:

I believe that there are a couple of others out there that should be added to the list (Ealden and Marcin, maybe others?). Can someone give me the list of GitHub IDs for anyone who should have commit rights?

ealden (Ealden Escañan)
erdi (Marcin Erdmann)

Thanks, I've added them both as collaborators.

If we are going to start publishing to Maven Central repository I will stop adding releases to jvoegele.com. Are we in a position to do that now, and if so who will be doing the build and push? Is that something I should do myself, or does someone else want to take a crack at it?

I would suggest to not limit the publishing role to one person, in order to avoid getting stuck when there is need for a fresh release.

It would be ok for me to give publishing right to every one with commit rights: it seems we are all responsible of what we commit so I hope it will be the same for publishing; and if a broken build was ever published, it's easy to fallback to the previous version: you have to choose the exact plugin version in your build.gradle, after all.

My two cents.

Fabio

[Ealden Escañan]

Hi,

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

I'll start with this route, and send other the POM that I plan to include for it.  Let me know if there are any problems with this :-).

I made a branch and a pull request on all the changes necessary to meet Sonatype's requirements.  Sorry it took so long.  PR is at:

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

Please let me know if there are any changes that I need to add to the POM.  I also have a list of things that still need to be done and things that we should agree upon in the PR - I'll post it here for everyone's convenience:

This pull request is not yet complete, as we still need the following in the POM:

1. Nick Carroll's email address
2. <dependencies> section based from Gradle's dependencies list (I haven't figured this out yet)

And with the build process:

1. Generate -sources and -javadocs automatically.

Aside from this, I think we should agree on the following points:

1. Do we rename this from android-plugin to gradle-android-plugin? The latter should be more descriptive, though of course it will change how dependencies are defined.
2. Do we go ahead with Apache 2.0 license or some other license? If so I'll add license-gradle-plugin and configure it with the build.

Best regards,

[Ealden Escañan]

Hi,

On Mon, Dec 5, 2011 at 11:13 PM, Jason Voegele <jason....@gmail.com> wrote:

On Dec 5, 2011, at 10:07 AM, Ladislav Thon wrote:

I believe that there are a couple of others out there that should be added to the list (Ealden and Marcin, maybe others?). Can someone give me the list of GitHub IDs for anyone who should have commit rights?

ealden (Ealden Escañan)
erdi (Marcin Erdmann)

Thanks, I've added them both as collaborators.

Thank you!  I started using it already :-).

[Ealden Escañan]

Hi,

On Mon, Dec 5, 2011 at 11:45 PM, Fabio Da Soghe <fabiod...@gmail.com> wrote:

I would suggest to not limit the publishing role to one person, in order to avoid getting stuck when there is need for a fresh release.

It would be ok for me to give publishing right to every one with commit rights: it seems we are all responsible of what we commit so I hope it will be the same for publishing; and if a broken build was ever published, it's easy to fallback to the previous version: you have to choose the exact plugin version in your build.gradle, after all.

My two cents.

+1 here

[Ealden Escañan]

Hi,

On Tue, Dec 6, 2011 at 9:06 AM, Ealden Escañan <eal...@gmail.com> wrote:

I made a branch and a pull request on all the changes necessary to meet Sonatype's requirements.  Sorry it took so long.  PR is at:

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

[SNIP]

This pull request is not yet complete, as we still need the following in the POM:

1. Nick Carroll's email address
2. <dependencies> section based from Gradle's dependencies list (I haven't figured this out yet)

[SNIP]

Aside from this, I think we should agree on the following points:

1. Do we rename this from android-plugin to gradle-android-plugin? The latter should be more descriptive, though of course it will change how dependencies are defined.
2. Do we go ahead with Apache 2.0 license or some other license? If so I'll add license-gradle-plugin and configure it with the build.

Ping? :)

[Fabio Da Soghe]

Yes, of course you're right, my apologies.

My answers below.

On Tue, Dec 6, 2011 at 9:06 AM, Ealden Escañan <eal...@gmail.com> wrote:

I made a branch and a pull request on all the changes necessary to meet Sonatype's requirements.  Sorry it took so long.  PR is at:

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

[SNIP]

This pull request is not yet complete, as we still need the following in the POM:

1. Nick Carroll's email address

Cannot help here :o) 

1. <dependencies> section based from Gradle's dependencies list (I haven't figured this out yet)

mmh... I fear I cannot help here, too. At least not without a bit of studying (and today I'm not able to, sorry - probably in the weekend).  

[SNIP]

Aside from this, I think we should agree on the following points:

1. Do we rename this from android-plugin to gradle-android-plugin? The latter should be more descriptive, though of course it will change how dependencies are defined.

+1 for rename to android-gradle-plugin.

And, what about the group id?  

1. Do we go ahead with Apache 2.0 license or some other license? If so I'll add license-gradle-plugin and configure it with the build.

Maybe we already discussed this some time ago, but cannot remember if and what we decided.

In my opinion, the original author should choose a license (open, of course). Jason?

 

[Ladislav Thon]

Maybe we already discussed this some time ago, but cannot remember if and what we decided.

In my opinion, the original author should choose a license (open, of course). Jason?

I was always operating under the assumption that Gradle Android Plugin is Apache 2.0 licensed :-), although it isn't stated anywhere (IIRC). Which it definitely should, whatever the license is.

LT

[Jason Voegele]

On Dec 7, 2011, at 10:15 AM, Fabio Da Soghe wrote:

On Tue, Dec 6, 2011 at 9:06 AM, Ealden Escañan <eal...@gmail.com> wrote:

I made a branch and a pull request on all the changes necessary to meet Sonatype's requirements.  Sorry it took so long.  PR is at:

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

[SNIP]

This pull request is not yet complete, as we still need the following in the POM:

1. Nick Carroll's email address

I cannot track down Nick's email address. He's @nlcarroll on Twitter and his web site is http://ca.rroll.net/ . However, I don't think he's actually contributed any code. He showed some interest in the plugin in the early days but has sent in any patches or commits. Therefore, I think he can be left out of the developers list.

1. <dependencies> section based from Gradle's dependencies list (I haven't figured this out yet)

Apart from dependencies on Gradle itself, ProGuard is a dependency.

[SNIP]

Aside from this, I think we should agree on the following points:

1. Do we rename this from android-plugin to gradle-android-plugin? The latter should be more descriptive, though of course it will change how dependencies are defined.

+1 for rename to android-gradle-plugin.

And, what about the group id?

I don't know what's best for a groupId. I don't want to use com.jvoegele, though, since my contributions have been pretty minimal lately. Is there a common groupId for Gradle plugins to use?

 

1. Do we go ahead with Apache 2.0 license or some other license? If so I'll add license-gradle-plugin and configure it with the build.

Maybe we already discussed this some time ago, but cannot remember if and what we decided.

In my opinion, the original author should choose a license (open, of course). Jason?

I'm open to any liberal license, so Apache would be a reasonable choice.

-- 

Jason Voegele

Mother told me to be good but she's been wrong before.

[Ealden Escañan]

Hi,

On Wed, Dec 7, 2011 at 11:33 PM, Jason Voegele <jason....@gmail.com> wrote:

I cannot track down Nick's email address. He's @nlcarroll on Twitter and his web site is http://ca.rroll.net/ . However, I don't think he's actually contributed any code. He showed some interest in the plugin in the early days but has sent in any patches or commits. Therefore, I think he can be left out of the developers list.

Gotcha.  I'll make the change and force update the branch to remove it from history.

 

I don't know what's best for a groupId. I don't want to use com.jvoegele, though, since my contributions have been pretty minimal lately. Is there a common groupId for Gradle plugins to use?

There really doesn't seem to be a common groupId based on the plugins I've seen.  What I did notice is that https://github.com/bmuschko uses the same groupId the standard plugins used, which is org.gradle.api.plugins.  I sent him an email BTW asking about it too, just in case.  His plugins are listed in the Gradle Plugins site though, so I guess the Gradle developers don't have a problem with it.

I did a quick search through the Gradle dev list and I don't believe there really is a discussion about this.  The only meaningful thread I found was from... Jason in 2010!

http://markmail.org/thread/7qtey2bvy2k2qsaf

I'm open to any liberal license, so Apache would be a reasonable choice.

I'll pattern it after the one used in the standard plugins, which essentially says: Copyright 2010 the original author or authors.

https://github.com/gradle/gradle/blob/master/subprojects/plugins/plugins.gradle

[Ladislav Thon]

I cannot track down Nick's email address. He's @nlcarroll on Twitter and his web site is http://ca.rroll.net/ . However, I don't think he's actually contributed any code. He showed some interest in the plugin in the early days but has sent in any patches or commits. Therefore, I think he can be left out of the developers list.

Gotcha.  I'll make the change and force update the branch to remove it from history.

Force update is almost never a good idea and you should _not_ try to change history of stuff that you already published. (We've been through this pain once.) Especially in this case -- there's no reason for it disappearing from history.

LT

[Ealden Escañan]

Hi,

On Thu, Dec 8, 2011 at 12:49 AM, Ladislav Thon <lad...@gmail.com> wrote:

Force update is almost never a good idea and you should _not_ try to change history of stuff that you already published. (We've been through this pain once.) Especially in this case -- there's no reason for it disappearing from history.

Sorry, I was under the impression that it's OK for feature branches until it's merged to master.  I just did it a few minutes ago, but will avoid it in the future.

[Ladislav Thon]

Force update is almost never a good idea and you should _not_ try to change history of stuff that you already published. (We've been through this pain once.) Especially in this case -- there's no reason for it disappearing from history.

Sorry, I was under the impression that it's OK for feature branches until it's merged to master.  I just did it a few minutes ago, but will avoid it in the future.

Well, it kinda is... until someone clones your branch. It's a safety measure to never change history of something that left your machine.

Nothing horrible happened, just to let you know.

LT

[Ealden Escañan]

Hi,

On Thu, Dec 8, 2011 at 12:27 AM, Ealden Escañan <eal...@gmail.com> wrote:

 

I don't know what's best for a groupId. I don't want to use com.jvoegele, though, since my contributions have been pretty minimal lately. Is there a common groupId for Gradle plugins to use?

There really doesn't seem to be a common groupId based on the plugins I've seen.  What I did notice is that https://github.com/bmuschko uses the same groupId the standard plugins used, which is org.gradle.api.plugins.  I sent him an email BTW asking about it too, just in case.  His plugins are listed in the Gradle Plugins site though, so I guess the Gradle developers don't have a problem with it.

I asked this in the Gradle dev list, and got this reply:

http://markmail.org/thread/4q3t7iewvhca6x3k

I'll push this change to the PR later unless if anyone has a different opinion on this.

[Ealden Escañan]

Hi,

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

I'll push this change to the PR later unless if anyone has a different opinion on this.

Merged the PR to master already: https://github.com/jvoegele/gradle-android-plugin/pull/36 and have filed the request at OSSRH https://issues.sonatype.org/browse/OSSRH-2573 - just waiting for their reply.

[Ladislav Thon]

Merged the PR to master already: https://github.com/jvoegele/gradle-android-plugin/pull/36 and have filed the request at OSSRH https://issues.sonatype.org/browse/OSSRH-2573 - just waiting for their reply.

Had a quick look at the code in the PR and I think it is a great work! Getting Gradle Android Plugin into Maven Central would be just awesome!

LT