You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
any plan to export individual APIs as separate artifacts? #70
I've noticed the the datastore and storage packages aren't setup to generate their own artifacts. Are there any plans to do this? Java developers would typically expect each service API to be broken out and included as their own artifact.
There is some discussion about it also in issue #39. The current plan is to keep having the aggregate jar that includes all services and then later on (based on demand or when we will have more services and such separation would be meaningful) we will add an artifact per service (likely via pom modules).
My preference would be for it to happen as soon as you have more than one API. It looks like you'll need separate documentation pages for datastore vs gcs pretty soon, you probably wouldn't want to include the markdown in the java package path so you'll need to break them out by parent directories. At that point you basically have the directory structure you need for the multi-module setup.
Not trivial as this will including structural changes, code changes and deployment related changes ( (travis, maven, site, ..). As suggested above, I did plan to. My plan was to deal with it when we have more services and it will become more meaningful though I thought to give it a try after finishing storage. I will give a try sooner.
Activity
aozarov commentedon May 18, 2015
There is some discussion about it also in issue #39. The current plan is to keep having the aggregate jar that includes all services and then later on (based on demand or when we will have more services and such separation would be meaningful) we will add an artifact per service (likely via pom modules).
patflynn commentedon May 19, 2015
My preference would be for it to happen as soon as you have more than one API. It looks like you'll need separate documentation pages for datastore vs gcs pretty soon, you probably wouldn't want to include the markdown in the java package path so you'll need to break them out by parent directories. At that point you basically have the directory structure you need for the multi-module setup.
ludoch commentedon May 19, 2015
Current Veneer trend is to bundle and document every thing in the same doc:
https://googlecloudplatform.github.io/gcloud-python/latest/
https://googlecloudplatform.github.io/gcloud-node/#/docs/v0.14.0
jgeewax commentedon May 20, 2015
This also follows the AWS Java trend, where everything is in a single jar.
patflynn commentedon May 20, 2015
AWS seems to offer both. Each API individually, and an uber-jar for the
whole thing. That would be my preference.
On Wed, May 20, 2015 at 11:32 AM, JJ Geewax notifications@github.com
wrote:
jgeewax commentedon May 21, 2015
Ah that's a good point. I'm fine with singular pieces as well as the jar with everything... is that a complicated thing for us to do ?
aozarov commentedon May 22, 2015
Not trivial as this will including structural changes, code changes and deployment related changes ( (travis, maven, site, ..). As suggested above, I did plan to. My plan was to deal with it when we have more services and it will become more meaningful though I thought to give it a try after finishing storage. I will give a try sooner.
aozarov commentedon May 26, 2015
Fixed by #74
deps: update dependency com.google.cloud:google-cloud-shared-dependen…
5 remaining items
chore(main): release 0.5.1-SNAPSHOT (#70)
deps: update dependency com.google.cloud:google-cloud-shared-dependen…
chore(main): release 0.3.3 (#71)
chore(main): release 0.3.2 (#70)
chore(main): release 0.3.4 (#70)
deps: update dependency markupsafe to v2.1.1 (#70)
chore(deps): update dependency com.google.cloud:google-cloud-batch to…
chore(main): release 0.2.5 (#86)
chore(main): release 0.2.5 (#82)
chore(main): release 0.4.0 (#52)
test(deps): update dependency com.google.truth:truth to v1.0.1 (#70)
chore: use java helper for templates (#70)
test(deps): update dependency com.google.truth:truth to v1.0.1 (googl…
chore(deps): update dependency com.google.cloud:libraries-bom to v4.4…
chore(deps): update dependency com.google.cloud:libraries-bom to v4.4…