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

Feature publisher #534

Closed
wants to merge 10 commits into from
Closed

Conversation

jdegroot
Copy link

First mojo for the Play store publisher.

Using the same file structure for store listing, what's new, etc. as the Gradle publisher.
https://github.com/Triple-T/gradle-play-publisher

Can be used inside or outside a project,

<android.publisher.email>xxx</android.publisher.email>
<android.publisher.p12>xxx</android.publisher.p12>

Publisher email and p12 file are required (https://developers.google.com/android-publisher/getting_started).

Close #418

Co-authored by @Shusshu

@Shusshu
Copy link
Member

Shusshu commented Dec 11, 2014

Anyone wanna look into this?

Otherwise I will merge it soon.

@Shusshu
Copy link
Member

Shusshu commented Dec 12, 2014

As you can see it's getting really good, more features :)
Planning to get some ascii doc today

@mosabua
Copy link
Member

mosabua commented Dec 12, 2014

I will look at this asap ... I have a feeling we should cut a 4.1.0 release very soon!

@mosabua
Copy link
Member

mosabua commented Dec 12, 2014

Going forward it would be cool to also support publishing to other stores. Do you think we should have a different mojo for each publishing (then we should rename this mojo to publish2play maybe or so) if we use one mojo then we would have a config parameter for what store(s) to publish to. I think it might be easier to have each store be separate and therefore vote for renaming the mojo..

@william-ferguson-au
Copy link
Contributor

OK, first of all I am highly unlikely to use this Mojo, so consider that
when counting/discounting my opinion.

But I would argue that it should be a single Mojo for all stores that uses
a strategy to deploy to those configured.
We already have way too many Mojos in this plugin. Most of which I
suspect aren't used. Let's not add an army more.

[image: photo]
William Ferguson
Founder and CEO, XandarMob
m:+61 425 716 870 | e:[email protected] |
w:https://wylas-timing.com
http://lexathon.com <http://wylas-timing.com http://lexathon.com>

On Sat, Dec 13, 2014 at 9:18 AM, Manfred Moser [email protected]
wrote:

Going forward it would be cool to also support publishing to other stores.
Do you think we should have a different mojo for each publishing (then we
should rename this mojo to publish2play maybe or so) if we use one mojo
then we would have a config parameter for what store(s) to publish to. I
think it might be easier to have each store be separate and therefore vote
for renaming the mojo..


Reply to this email directly or view it on GitHub
#534 (comment)
.

@mosabua
Copy link
Member

mosabua commented Dec 13, 2014

That was my concern to some degree as well... I just have a feeling it has the potential to get messy. On the other hand we might never get another publish implementation for any other store..

@william-ferguson-au
Copy link
Contributor

Both very true.

Where it has the potential to get messy is with the config as the code can
be easily segmented into separate classes for each strategy. What I would
suggest is that we have a single config element for this Mojo, eg
and within that an element for each store, eg
and each of those can have whatever elements (why doesn't
Maven use attributes - much more succinct?) it needs.

That way the Mojo just picks up each store config and feeds it to the
relevant strategy.

[image: photo]
William Ferguson
Founder and CEO, XandarMob
m:+61 425 716 870 | e:[email protected] |
w:https://wylas-timing.com
http://lexathon.com <http://wylas-timing.com http://lexathon.com>

On Sat, Dec 13, 2014 at 10:30 AM, Manfred Moser [email protected]
wrote:

That was my concern to some degree as well... I just have a feeling it has
the potential to get messy. On the other hand we might never get another
publish implementation for any other store..


Reply to this email directly or view it on GitHub
#534 (comment)
.

@mosabua
Copy link
Member

mosabua commented Dec 13, 2014

Alright... so for now I would suggest that we add the store related parameters (you choose what you want to name it and default it to the play store. And name the configs so that it is clear they apply to the play store somehow. Also keep in mind that Play might be a bad name since it used to be Market right ;-) Maybe just use Google. The rest of the refactor into separate classes and config stuff can imho wait until we have to add another store because someone steps up to do it (not gonna be me or @william-ferguson-au it seems ;-)

@william-ferguson-au
Copy link
Contributor

:-) +1
On 13 Dec 2014 10:40 am, "Manfred Moser" [email protected] wrote:

Alright... so for now I would suggest that we add the store related
parameters (you choose what you want to name it and default it to the play
store. And name the configs so that it is clear they apply to the play
store somehow. Also keep in mind that Play might be a bad name since it
used to be Market right ;-) Maybe just use Google. The rest of the refactor
into separate classes and config stuff can imho wait until we have to add
another store because someone steps up to do it (not gonna be me or
@william-ferguson-au https://github.com/william-ferguson-au it seems ;-)


Reply to this email directly or view it on GitHub
#534 (comment)
.

@Shusshu
Copy link
Member

Shusshu commented Dec 13, 2014

So just adding google as android.publisher.store parameter? (btw if we do not support any other store it's a useless parameter that might confuse the user, only useful if we support the pullparameter but I don't think it is even needed see below)
Or you want a PullParameter stuff? which is ugly as hell to implement....

I don't think we need to add the PullParameter now since we only have 1 store anyway plus there is actually no parameter to set in the pom.
Only the email & the p12 key path needs to be specified an that can't be written in the pom (for security reasons).

So I vote for merging as is... and I see a nice use case where we prepare store data in the folder and then run 1 command instead of updating each field manually on the play store. :) less manual work!

The play store data can even be committed to git and would be safe there. (src/main/play)

@william-ferguson-au
Copy link
Contributor

Why can't/wou'dn't the email and p12 key path be specified in the POM?

[image: photo]
William Ferguson
Founder and CEO, XandarMob
m:+61 425 716 870 | e:[email protected] |
w:https://wylas-timing.com
http://lexathon.com <http://wylas-timing.com http://lexathon.com>

On Sat, Dec 13, 2014 at 3:51 PM, Benoit Billington <[email protected]

wrote:

So you want a PullParameter stuff? which is ugly as hell to implement....

I don't think we need to add the PullParameter now since we only have 1
store anyway plus there is actually no parameter to set in the pom.
Only the email & the p12 key path needs to be specified an that can't be
written in the pom.

So I vote for merging as is... and I see a nice use case where we prepare
store data in the folder and then run 1 command instead of updating each
field manually on the play store. :) less manual work!

The play store data can even be committed to git and would be safe there.
(src/main/play)


Reply to this email directly or view it on GitHub
#534 (comment)
.

@Shusshu
Copy link
Member

Shusshu commented Dec 13, 2014

Well the email is generated by google on the play store console and that would be sort of ok but the p12key can't be placed in the repo so it might be in different location on different computers and it can't be placed into the repository as it is an access key for the google play account

@william-ferguson-au
Copy link
Contributor

I would have thought the p12 key would either be a reference to a location
or the key itself, either of which would likely be a parameter coming from
your Settings.xml
In any case you need to be able to configure it, unless you expect the Mojo
to magically guess the answer.

If you need to configure it then it will be a config param of the Mojo.

[image: photo]
William Ferguson
Founder and CEO, XandarMob
m:+61 425 716 870 | e:[email protected] |
w:https://wylas-timing.com
http://lexathon.com <http://wylas-timing.com http://lexathon.com>

On Sat, Dec 13, 2014 at 4:27 PM, Benoit Billington <[email protected]

wrote:

Well the email is generated by google on the play store console and that
would be sort of ok but the p12key can't be placed in the repo so it might
be in different location on different computers and it can't be placed into
the repository as it is an access key for the google play account


Reply to this email directly or view it on GitHub
#534 (comment)
.

@jdegroot
Copy link
Author

If you use the Mojo inside a project the only required parameters are indeed the publisher email and the p12,most likely located in settings.xml (see the asciidoc as well).

For the multiple store issue I think agree with @Shusshu since there is only one store at the moment

@Shusshu
Copy link
Member

Shusshu commented Dec 14, 2014

William yes they are already defined as parameter for the mojo.
On 14 Dec 2014 01:57, "William Ferguson" [email protected] wrote:

I would have thought the p12 key would either be a reference to a location
or the key itself, either of which would likely be a parameter coming from
your Settings.xml
In any case you need to be able to configure it, unless you expect the
Mojo
to magically guess the answer.

If you need to configure it then it will be a config param of the Mojo.

[image: photo]
William Ferguson
Founder and CEO, XandarMob
m:+61 425 716 870 | e:[email protected] |
w:https://wylas-timing.com
http://lexathon.com <http://wylas-timing.com http://lexathon.com>

On Sat, Dec 13, 2014 at 4:27 PM, Benoit Billington <
[email protected]

wrote:

Well the email is generated by google on the play store console and that
would be sort of ok but the p12key can't be placed in the repo so it
might
be in different location on different computers and it can't be placed
into
the repository as it is an access key for the google play account


Reply to this email directly or view it on GitHub
<
https://github.com/simpligility/android-maven-plugin/pull/534#issuecomment-66867051>

.


Reply to this email directly or view it on GitHub
#534 (comment)
.

@william-ferguson-au
Copy link
Contributor

So as per Manfred's suggestion wrap the 2 Google Play params into a
containing GooglePlay element (which is contained within your Stores
element) so that
a) it's clear what they pertain to
b) if/when another store is introduced we don't need to rename the Google
Play params.

On Mon, Dec 15, 2014 at 12:06 AM, Benoit Billington <
[email protected]> wrote:

William yes they are already defined as parameter for the mojo.
On 14 Dec 2014 01:57, "William Ferguson" [email protected]
wrote:

I would have thought the p12 key would either be a reference to a
location
or the key itself, either of which would likely be a parameter coming
from
your Settings.xml
In any case you need to be able to configure it, unless you expect the
Mojo
to magically guess the answer.

If you need to configure it then it will be a config param of the Mojo.

[image: photo]
William Ferguson
Founder and CEO, XandarMob
m:+61 425 716 870 | e:[email protected] |
w:https://wylas-timing.com
http://lexathon.com <http://wylas-timing.com http://lexathon.com>

On Sat, Dec 13, 2014 at 4:27 PM, Benoit Billington <
[email protected]

wrote:

Well the email is generated by google on the play store console and
that
would be sort of ok but the p12key can't be placed in the repo so it
might
be in different location on different computers and it can't be placed
into
the repository as it is an access key for the google play account


Reply to this email directly or view it on GitHub
<

https://github.com/simpligility/android-maven-plugin/pull/534#issuecomment-66867051>

.


Reply to this email directly or view it on GitHub
<
https://github.com/simpligility/android-maven-plugin/pull/534#issuecomment-66898215>

.


Reply to this email directly or view it on GitHub
#534 (comment)
.

@Shusshu
Copy link
Member

Shusshu commented Dec 15, 2014

Rename from android.publisher.p12 to android.publisher.google.p12
and android.publisher.email to android.publisher.google.email

No need to use the PullParameter as it will either be added to the command line or in a profile

@mosabua
Copy link
Member

mosabua commented Dec 18, 2014

I merged this and all the stuff is there and should be working. For some weird reason however the commits are from your branch from @jdegroot are gone. Not sure what went wrong. Didnt do anything different than on other times. I hope thats not a problem. So sorry about that. Thanks a lot for the contribution..

@jdegroot
Copy link
Author

@mosabua No worries, it's cool that it's in : -)

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

Successfully merging this pull request may close these issues.

Support API for publishing to Google Play
4 participants