I hate having to bring up topics like this, but why the license choice for this repo? I totally get it for your other projects as it keeps people from profiting from your work and selling it as their own - but this project's whole point is to integrate it into likely closed source repo's (it if was open source, I wouldn't be publishing to S3, I'd just go to maven central, etc!) My concern is that in a legal battle, one might argue that my private project because it's using this project in its build.sbt file must now also be fully open source? I know the license issue is one of the big reasons the frugal mechanic project got started, but this project seems to be much more maintained and active, and I'd much rather use and contribute to it. Just wish it had a different license? I know y'all probably wont' change it, just curious the history behind the choice for this project?
no problem with the topic
so why AGPLv3
is just a matter of simplicity
we're fine with anyone selling whatever
as long as it's open too :)
anyway
for private projects
in a lot of cases AGPLv3 is not a big issue
the requirement is over users of your app
so for something internal
Yeah, I'm specifically bringing up private projects here where the project might be for some API for our business that customers hit. All the other licenses used by our API allow us to keep the project private and not share our API source to the world, but that last step in our build process of publishing this thing to a private s3 maven repo that now forces me to open source my whole API is a little disappointing because using your s3-resolver is just part of the process for the build management - I wasn't profiting off of the project for my API itself. So it's not that I really have a problem with y'all using APGLv3 for all of your other stuff, because that makes sense based on your business goals for your other intellectual work, but for a build process tool, it just kind of bugs me :smile: given that your work didn't assist in me in creating the intellectual work of what I'm trying to keep private, it only assisted in the process part of efficiently storing or retrieving my compiled work. For now, I've just being using the other library from frugal mechanic, but part of my developer soul is bleeding knowing there is a better project out there, but I can't use it :smile:
we could maybe move it to the sbt org
relicense it etc
that could be an option
Hi, thanks a ton for the useful package, but looks like this package is no longer available from your repo at https://s3-eu-west-1.amazonaws.com/releases.era7.com/, is that intended?
That sounds strange, we resolve from there daily
Maybe a misconfiguration, or something region related?
Proxies?
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::xxxx"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::xxxx/*"
}
]
}
that is an example of the bucket policy i'm currently using
Access Denied (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied;
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::xxxx"
},
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": "arn:aws:s3:::xxxx/*"
}
]
}
this seemed to work fine
hi @benoahriz.
As I see from the code in ivy-s3-resolver (which is used in this plugin), there is no much happening besides listObjects/putObject actions..
As I see from the code in ivy-s3-resolver (which is used in this plugin), there is no much happening besides listObjects/putObject actions..
probably
s3:PutObjectAcl is needed? (here)
on the other hand
s3:DeleteObject is not needed, because resolver cannot delete a published artifact
I've just tested it and I think
s3:PutObjectAcl is the missing chain. Here is the policy which I successfully used for publishing and resolving:{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::bucket.name"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:GetObject"
],
"Resource": "arn:aws:s3:::bucket.name/*"
}
]
}
In theory
s3:CreateBucket may be also needed if you publish to a non-existing bucket.
@benoahriz thanks for raising this concern, I should add this to the readme. Tell me if it works for you now.
also added an example of using the aws credentials and env vars if you set them which is how im implementing it
Hello, I tried to use the plugin like this
import com.amazonaws.auth._
lazy val root = (project in file(".")).settings(
name := "helpers",
version := "0.6.0",
scalaVersion := "2.10.6",
organization := "net.pishen",
libraryDependencies ++= Seq(
"com.typesafe.play" %% "play-json" % "2.3.10",
"com.github.nscala-time" %% "nscala-time" % "2.6.0"
),
publishMavenStyle := false,
s3credentials := new EnvironmentVariableCredentialsProvider(),
s3region := Region.fromValue("us-west-2"),
publishTo := Some(s3resolver.value("S3 Repository", s3("my-bucket")).withIvyPatterns)
)But it said that it can't find the value Region
error: not found: value Region
s3region := Region.fromValue("us-west-2"),
^
sbt.compiler.EvalException: Type error in expression
at sbt.compiler.Eval.checkError(Eval.scala:384)
at sbt.compiler.Eval.compileAndLoad(Eval.scala:183)
at sbt.compiler.Eval.evalCommon(Eval.scala:152)
at sbt.compiler.Eval.evalDefinitions(Eval.scala:122)
at sbt.EvaluateConfigurations$.evaluateDefinitions(EvaluateConfigurations.scala:271)
at sbt.EvaluateConfigurations$.evaluateSbtFile(EvaluateConfigurations.scala:109)
at sbt.Load$.sbt$Load$$loadSettingsFile$1(Load.scala:712)
at sbt.Load$$anonfun$sbt$Load$$memoLoadSettingsFile$1$1.apply(Load.scala:717)
...And if I add this line import com.amazonaws.services.s3.model._ to my build.sbt it will work. Seems that it can't see the type aliases in autoImport?
@/all v0.17.0 is out:
- #51: Upgraded to SBT 1.x (by @macalinao)
- #25: Published to Bintray community repository
- #35: Added storage class setting
- Upgraded to ivy-s3-resolver v0.11.0
@/all Thanks to the effort of Michael Ahlers @michaelahlers, we've got a new bugfix release that workarounds the problem with redundant delimiters in the ivy-style patterns introduced in sbt 1.0 (see #52 and sbt/sbt#3573).
Everybody is recommended to update to v0.17.1
