MyFavMirrors
/
minio
mirror of https://github.com/minio/minio.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
minio/vendor/vendor.json

137 lines
4.0 KiB
JSON
Raw Normal View History

Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
{
"comment": "",
web: Removing dependency for gpg and downloading assets. Assets are vendorized from now on and updated for each release.
2016-02-23 16:05:47 -05:00
"ignore": "appengine test",
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
"package": [
logrus logger
2015-09-09 23:28:09 -04:00
{
Migrate to new govendor
2015-10-11 01:28:56 -04:00
"path": "github.com/Sirupsen/logrus",
logrus logger
2015-09-09 23:28:09 -04:00
"revision": "418b41d23a1bf978c06faea5313ba194650ac088",
"revisionTime": "2015-09-08T20:46:18Z"
},
jwt: Add JWT support for minio server. Please read JWT.md before using this feature.
2016-01-21 19:28:15 -05:00
{
"path": "github.com/dgrijalva/jwt-go",
"revision": "afef698c326bfd906b11659432544e5aae441d44",
"revisionTime": "2015-12-30T10:00:00-08:00"
},
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
{
Migrate to new govendor
2015-10-11 01:28:56 -04:00
"path": "github.com/dustin/go-humanize",
Migrate this project to minio micro services code
2015-10-16 14:26:01 -04:00
"revision": "c20a8bde38c8f5ba06f6600edf473705c96829d1",
"revisionTime": "2015-08-24T01:38:10-07:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
},
UI: vendorize github.com/elazarl/go-bindata-assetfs which is needed by ui-assets.go
2016-02-04 06:20:34 -05:00
{
"path": "github.com/elazarl/go-bindata-assetfs",
ui-assets: Integrate UI assets.
2016-02-04 19:00:52 -05:00
"revision": "57eb5e1fc594ad4b0b1dbea7b286d299e0cb43c2",
"revisionTime": "2015-12-24T06:54:52+02:00"
UI: vendorize github.com/elazarl/go-bindata-assetfs which is needed by ui-assets.go
2016-02-04 06:20:34 -05:00
},
Add WebUI assetfs initial version
2015-09-25 03:37:28 -04:00
{
Migrate this project to minio micro services code
2015-10-16 14:26:01 -04:00
"path": "github.com/fatih/color",
"revision": "76d423163af754ff6423d2d9be0057fbf03c57c2",
"revisionTime": "2015-08-24T00:44:34+03:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
},
{
Migrate this project to minio micro services code
2015-10-16 14:26:01 -04:00
"path": "github.com/gorilla/context",
"revision": "1c83b3eabd45b6d76072b66b746c20815fb2872d",
"revisionTime": "2015-08-19T22:12:45-07:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
},
{
Migrate this project to minio micro services code
2015-10-16 14:26:01 -04:00
"path": "github.com/gorilla/mux",
"revision": "ee1815431e497d3850809578c93ab6705f1a19f7",
"revisionTime": "2015-08-19T22:15:06-07:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
},
Bring in the list APIs implemented by Bala <bala@minio.io>
2016-01-23 22:44:32 -05:00
{
"path": "github.com/gorilla/rpc/v2",
"revision": "64e20900b8aa38bb0771dec71ba3bcc2b07fc8ec",
"revisionTime": "2015-11-05T07:45:51+08:00"
},
{
WebUI: move from rpc/v2/json to rpc/v2/json2 which has better error response structure.
2016-02-11 13:11:43 -05:00
"path": "github.com/gorilla/rpc/v2/json2",
rpc: Fix json rpc to handle array and object request params. rpc/v2/json2 code has a bug where it treats all jsonrpc 2.0 request params like an 'object'. In accordance with the spec it could be both 'object' or an 'array'. Handle both cases.
2016-02-13 21:50:21 -05:00
"revision": "64e20900b8aa38bb0771dec71ba3bcc2b07fc8ec",
"revisionTime": "2015-11-05T07:45:51+08:00"
Bring in the list APIs implemented by Bala <bala@minio.io>
2016-01-23 22:44:32 -05:00
},
rewrite minio runtime checks
2016-02-15 07:26:56 -05:00
{
"path": "github.com/hashicorp/go-version",
"revision": "7e3c02b30806fa5779d3bdfc152ce4c6f40e7b38",
"revisionTime": "2016-01-19T13:13:26-08:00"
},
cpu: Remove pkg/cpu in favor of better klauspost/cpuid. Fixes #1128
2016-02-15 15:45:02 -05:00
{
"path": "github.com/klauspost/cpuid",
"revision": "349c675778172472f5e8f3a3e0fe187e302e5a10",
"revisionTime": "2016-01-06T11:44:51+01:00"
},
First time mode for controller - Upon first time invocation ``minio controller`` would create access keys and secret id - Upon request passing 'keys' arg ``minio controller`` would provide the keys - Add colorized notification
2015-10-04 19:31:07 -04:00
{
Migrate this project to minio micro services code
2015-10-16 14:26:01 -04:00
"path": "github.com/mattn/go-isatty",
"revision": "7fcbc72f853b92b5720db4a6b8482be612daef24",
"revisionTime": "2015-08-14T09:26:29+09:00"
First time mode for controller - Upon first time invocation ``minio controller`` would create access keys and secret id - Upon request passing 'keys' arg ``minio controller`` would provide the keys - Add colorized notification
2015-10-04 19:31:07 -04:00
},
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
{
Migrate this project to minio micro services code
2015-10-16 14:26:01 -04:00
"path": "github.com/minio/cli",
cli: vendorize to new CLI package updates. - Fix a new line issue for minioHelpTemplate. - Fixes #974
2015-11-21 11:57:38 -05:00
"revision": "c4a07c7b68db77ccd119183fb1d01dd5972434ab",
"revisionTime": "2015-11-18T20:00:48-08:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
},
rewrite minio runtime checks
2016-02-15 07:26:56 -05:00
{
"path": "github.com/minio/go-homedir",
vendor update for go-homedir
2016-02-18 02:32:41 -05:00
"revision": "0b1069c753c94b3633cc06a1995252dbcc27c7a6",
"revisionTime": "2016-02-15T17:25:11+05:30"
rewrite minio runtime checks
2016-02-15 07:26:56 -05:00
},
Bring in the list APIs implemented by Bala <bala@minio.io>
2016-01-23 22:44:32 -05:00
{
"path": "github.com/minio/minio-go",
getObject: Add support for special response headers. Supports now response-content-type, response-content-disposition, response-cache-control, response-expires.
2016-02-07 06:37:54 -05:00
"revision": "280f16a52008d3ebba1bd64398b9b082e6738386",
"revisionTime": "2016-02-07T03:45:25-08:00"
Bring in the list APIs implemented by Bala <bala@minio.io>
2016-01-23 22:44:32 -05:00
},
web: Removing dependency for gpg and downloading assets. Assets are vendorized from now on and updated for each release.
2016-02-23 16:05:47 -05:00
{
"path": "github.com/minio/miniobrowser",
"revision": "b2835d0f671b5d539269bd2d9191b7c9c6ed87b3",
"revisionTime": "2016-02-23T13:18:37-08:00"
},
rewrite minio runtime checks
2016-02-15 07:26:56 -05:00
{
"path": "github.com/mitchellh/go-homedir",
"revision": "d682a8f0cf139663a984ff12528da460ca963de9",
"revisionTime": "2015-10-24T22:24:27-07:00"
},
Enable controller to have CORS
2015-08-31 04:47:05 -04:00
{
Migrate to new govendor
2015-10-11 01:28:56 -04:00
"path": "github.com/rs/cors",
Enable controller to have CORS
2015-08-31 04:47:05 -04:00
"revision": "eb527c8097e0f19a3ff7b253a3fe70545070f420",
"revisionTime": "2015-08-29T22:34:20-07:00"
},
First time mode for controller - Upon first time invocation ``minio controller`` would create access keys and secret id - Upon request passing 'keys' arg ``minio controller`` would provide the keys - Add colorized notification
2015-10-04 19:31:07 -04:00
{
Migrate to new govendor
2015-10-11 01:28:56 -04:00
"path": "github.com/shiena/ansicolor",
First time mode for controller - Upon first time invocation ``minio controller`` would create access keys and secret id - Upon request passing 'keys' arg ``minio controller`` would provide the keys - Add colorized notification
2015-10-04 19:31:07 -04:00
"revision": "a5e2b567a4dd6cc74545b8a4f27c9d63b9e7735b",
"revisionTime": "2015-07-19T16:15:31+09:00"
},
jwt: Add JWT support for minio server. Please read JWT.md before using this feature.
2016-01-21 19:28:15 -05:00
{
"path": "golang.org/x/crypto/bcrypt",
"revision": "7b85b097bf7527677d54d3220065e966a0e3b613",
"revisionTime": "2015-11-30T17:07:01-05:00"
},
{
"path": "golang.org/x/crypto/blowfish",
"revision": "7b85b097bf7527677d54d3220065e966a0e3b613",
"revisionTime": "2015-11-30T17:07:01-05:00"
},
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
{
Migrate to new govendor
2015-10-11 01:28:56 -04:00
"path": "gopkg.in/check.v1",
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
"revision": "11d3bc7aa68e238947792f30573146a3231fc0f1",
"revisionTime": "2015-07-29T10:04:31+02:00"
Add new logging connectors
2015-10-20 02:03:01 -04:00
},
{
"path": "gopkg.in/mgo.v2",
"revision": "f402e3a216db333ae6b3ba68b9152a34a0bc6984",
"revisionTime": "2015-10-05T19:07:38-07:00"
},
{
"path": "gopkg.in/mgo.v2/bson",
"revision": "f402e3a216db333ae6b3ba68b9152a34a0bc6984",
"revisionTime": "2015-10-05T19:07:38-07:00"
},
{
"path": "gopkg.in/mgo.v2/internal/sasl",
"revision": "f402e3a216db333ae6b3ba68b9152a34a0bc6984",
"revisionTime": "2015-10-05T19:07:38-07:00"
},
{
"path": "gopkg.in/mgo.v2/internal/scram",
"revision": "f402e3a216db333ae6b3ba68b9152a34a0bc6984",
"revisionTime": "2015-10-05T19:07:38-07:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
}
]
Migrate to new govendor
2015-10-11 01:28:56 -04:00
}