Scala-tools.org going down

2012/1/18 Maxime Lévesque :
>
> Of course, what I meant is that when you do a github push, you have your
> github private key around,
> so I'm saying why not use this private key to sign artifacts,
> then it can be easily verified that whoever built a jar has the private key
> that corresponds to the corresponding github repo...

I don't think you can query the public keys of other users with the
api. And even if it would be possible we'd still need a solution
compatible with maven IMO.

I don't think the barriers to entry for sonatype are much higher than
with scala-tools. You need
1. register your groupId with sonatype through a well documented process
2. build your artifacts with sbt
3. upload your artifacts with maven (step 7b), this step should be
integrated into sbt as soon as possible

The alleged "9-step" process is mostly the registration with sonatype
which isn't so bad compared to scala-tools.org where if you were
unfortunate you've got a process with an infinite number of steps.

If the homework is done, sbt can even start to check signatures and
we've then got a system which is based on standards, more secure and
not more complicated to use than now.

You don't need maven to publish to sonatype.  We're working on instructions for SBT.  scala-tools.org *used* nexus, so publishing to sonatype is *the same* as publishing to scala-tools.org was.  If you liked one, you should like the other.  The only difference is you may have to use the GPG pluigin to sign your artifacts (which you should have been doing anyway).
- Josh

2012/1/18 Johannes Rudolph <johannes.rudolph@googlemail.com>

2012/1/18 Maxime Lévesque <maxime.levesque@gmail.com>:
>
> Of course, what I meant is that when you do a github push, you have your
> github private key around,
> so I'm saying why not use this private key to sign artifacts,
> then it can be easily verified that whoever built a jar has the private key
> that corresponds to the corresponding github repo...

I don't think you can query the public keys of other users with the
api. And even if it would be possible we'd still need a solution
compatible with maven IMO.

I don't think the barriers to entry for sonatype are much higher than
with scala-tools. You need
 1. register your groupId with sonatype through a well documented process
 2. build your artifacts with sbt
 3. upload your artifacts with maven (step 7b), this step should be
integrated into sbt as soon as possible

The alleged "9-step" process is mostly the registration with sonatype
which isn't so bad compared to scala-tools.org where if you were
unfortunate you've got a process with an infinite number of steps.

If the homework is done, sbt can even start to check signatures and
we've then got a system which is based on standards, more secure and
not more complicated to use than now.

--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

Yes, I'd like to create some kind of central auth service for PGP keys such that I can mark my key as 'trusted scala OSS key' and users can use it to validate that software coming from me is indeed Scala OSS.  It's a rough idea, but more to follow (and it involves using github, oauth2, etc.)
- Josh

On Wed, Jan 18, 2012 at 10:29 AM, Doug Tangren <d.tangren@gmail.com> wrote:

2012/1/18 Maxime Lévesque <maxime.levesque@gmail.com>

Github has an api for publishing a user's public key :

  http://developer.github.com/v3/users/keys/

maybe a plugin (such as this one : https://github.com/sbt/xsbt-gpg-plugin )

could use the github key to sign the artifacts, it would remove a few steps and a bit of config.

Josh, did you say you had some thoughts on using gh as a platform for publishing?

 

ML

2012/1/18 Doug Tangren <d.tangren@gmail.com>

On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy.chheng@gmail.com> wrote:

Migrating to a single OSS repo like Sonatype would be great.

My only complain is:
Compare this lengthy complex 9 step process:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

with Clojure's main repo:
http://clojars.org/
$ lein pom
$ scp pom.xml mylib.jar clojars@clojars.org:

It would be great if there was a simple way to publish scala libs like this.

I really like this.

It's simple/ https://github.com/ato/clojars-web/wiki/tutorial looks like it uses an existing authentication mechanism, ssh keys.

npm, the node equiv, also has a super simple flow for publishing http://npmjs.org/doc/publish.html, http://npmjs.org/doc/developers.html I assume this also uses ssh keys to identify the publisher.

I have not as familiar with pgp, but it would be great to create an interface for something that as simple and straight forward to register for, as say clojars or npm, for the scala community exploiting this. When I hear, "just follow these simple nine steps", my stomache turns a little. I get the feeling that sonatype is really geared towards "the enterprise", but I personally really only care about small libraries made by "mom-and-pop" type authors in the open source community. For these, I feel like a complex and time consuming process just to publish a binary causes friction and may lead to downward trend of decent mom-and-pop authored libraries when it's visibly easier to publish in other communities. It was personally frustrating for me to get onto scala-tools because it was a long and drawn out process. This was in no way the fault of scala tools maintainers, but I think this had to do with the complexity and centralization of the administration of the project. Complexity -> bad.

Moving forward, people in the community have added first class build support for things like pgp signing that, I think?, could identify an authorized author to publish to "some repository in the cloud". It would be great to use something like this instead of a 9-step program which leads to a "we'll get to it when we get it" response for requests to publish.

I feel a bit a fervor in this area because I only recently got on scala-tools after some years in the community and now I hear its going down. I feel like others feel the same way too. Publishing should be simple. Finding Scala libraries should be simple[1]. Building Scala libraries should be simple [2]. Writing Scala libraries with good documentation should be simple [2]. There are a handful of projects out there tackling a handful of those problems, but I still feel like the publishing side of the dice is still not as simple as it could be. At least for a mom-and-pop type author who is excited about their new library, but cant publish it because the have to get in the back of the line.

That's my two cents

[1]: http://ls.implicit.ly/
[2]: https://github.com/harrah/xsbt/wiki
[3]: http://docs.scala-lang.org/

Yes, I'd like to create some kind of central auth service for PGP keys such that I can mark my key as 'trusted scala OSS key' and users can use it to validate that software coming from me is indeed Scala OSS.  It's a rough idea, but more to follow (and it involves using github, oauth2, etc.)
- Josh

On Wed, Jan 18, 2012 at 10:29 AM, Doug Tangren <d.tangren@gmail.com> wrote:

2012/1/18 Maxime Lévesque <maxime.levesque@gmail.com>

Github has an api for publishing a user's public key :

  http://developer.github.com/v3/users/keys/

maybe a plugin (such as this one : https://github.com/sbt/xsbt-gpg-plugin )

could use the github key to sign the artifacts, it would remove a few steps and a bit of config.

Josh, did you say you had some thoughts on using gh as a platform for publishing?

 

ML

2012/1/18 Doug Tangren <d.tangren@gmail.com>

On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy.chheng@gmail.com> wrote:

Migrating to a single OSS repo like Sonatype would be great.

My only complain is:
Compare this lengthy complex 9 step process:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

with Clojure's main repo:
http://clojars.org/
$ lein pom
$ scp pom.xml mylib.jar clojars@clojars.org:

It would be great if there was a simple way to publish scala libs like this.

I really like this.

It's simple/ https://github.com/ato/clojars-web/wiki/tutorial looks like it uses an existing authentication mechanism, ssh keys.

npm, the node equiv, also has a super simple flow for publishing http://npmjs.org/doc/publish.html, http://npmjs.org/doc/developers.html I assume this also uses ssh keys to identify the publisher.

I have not as familiar with pgp, but it would be great to create an interface for something that as simple and straight forward to register for, as say clojars or npm, for the scala community exploiting this. When I hear, "just follow these simple nine steps", my stomache turns a little. I get the feeling that sonatype is really geared towards "the enterprise", but I personally really only care about small libraries made by "mom-and-pop" type authors in the open source community. For these, I feel like a complex and time consuming process just to publish a binary causes friction and may lead to downward trend of decent mom-and-pop authored libraries when it's visibly easier to publish in other communities. It was personally frustrating for me to get onto scala-tools because it was a long and drawn out process. This was in no way the fault of scala tools maintainers, but I think this had to do with the complexity and centralization of the administration of the project. Complexity -> bad.

Moving forward, people in the community have added first class build support for things like pgp signing that, I think?, could identify an authorized author to publish to "some repository in the cloud". It would be great to use something like this instead of a 9-step program which leads to a "we'll get to it when we get it" response for requests to publish.

I feel a bit a fervor in this area because I only recently got on scala-tools after some years in the community and now I hear its going down. I feel like others feel the same way too. Publishing should be simple. Finding Scala libraries should be simple[1]. Building Scala libraries should be simple [2]. Writing Scala libraries with good documentation should be simple [2]. There are a handful of projects out there tackling a handful of those problems, but I still feel like the publishing side of the dice is still not as simple as it could be. At least for a mom-and-pop type author who is excited about their new library, but cant publish it because the have to get in the back of the line.

That's my two cents

[1]: http://ls.implicit.ly/
[2]: https://github.com/harrah/xsbt/wiki
[3]: http://docs.scala-lang.org/

On Tue, Jan 17, 2012 at 8:20 PM, Josh Suereth wrote:
> For PGP signatures, there's an SBT plugin that can generate a key for you
> and you can use it to sign all your releases.  Small steps, but there's a
> lot to do.

Speaking of which, this is extremely annoying to use if you have a
password on your GPG key.

The Maven GPG signing plugin manages to ask you for your password once
and use it for the duration of the Maven invocation. The SBT plugin
asks you for your password half a dozen times during the course of an
"sbt publish". And it also asks you half a dozen times (instead of the
desired zero) during an "sbt publish-local".

On Wed, Jan 18, 2012 at 12:51 PM, Michael Bayne <mdb@samskivert.com> wrote:

On Tue, Jan 17, 2012 at 8:20 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:
> For PGP signatures, there's an SBT plugin that can generate a key for you
> and you can use it to sign all your releases.  Small steps, but there's a
> lot to do.

Speaking of which, this is extremely annoying to use if you have a
password on your GPG key.

The Maven GPG signing plugin manages to ask you for your password once
and use it for the duration of the Maven invocation. The SBT plugin
asks you for your password half a dozen times during the course of an
"sbt publish". And it also asks you half a dozen times (instead of the
desired zero) during an "sbt publish-local".

On Wed, Jan 18, 2012 at 11:11 AM, Josh Suereth wrote:
> (1) Use the gpg agent if you're using the GPG command line tool  *I use this
> method on linux*
> (2) Set the gpgPassphrase option in the current console only  (set
> gpgPassphrase := Some("foo".toCharArray)) and use bouncy castle encryption
> *I use this method in windows*.

What do you use on Mac OS? :)

You can use the gpgPassphrase option.  I don't know Mac well at all, but bouncy castle is pure java solution.

On Wed, Jan 18, 2012 at 2:18 PM, Michael Bayne <mdb@samskivert.com> wrote:

On Wed, Jan 18, 2012 at 11:11 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:
> (1) Use the gpg agent if you're using the GPG command line tool  *I use this
> method on linux*
> (2) Set the gpgPassphrase option in the current console only  (set
> gpgPassphrase := Some("foo".toCharArray)) and use bouncy castle encryption
> *I use this method in windows*.

What do you use on Mac OS? :)

See http://www.scala-sbt.org/xsbt-gpg-plugin/usage.html at the bottom.
- Josh

On Wed, Jan 18, 2012 at 2:18 PM, Michael Bayne <mdb@samskivert.com> wrote:

On Wed, Jan 18, 2012 at 11:11 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:
> (1) Use the gpg agent if you're using the GPG command line tool  *I use this
> method on linux*
> (2) Set the gpgPassphrase option in the current console only  (set
> gpgPassphrase := Some("foo".toCharArray)) and use bouncy castle encryption
> *I use this method in windows*.

What do you use on Mac OS? :)

For what it's worth, reactive was always published to Sonatype, via sbt. You can see the build definition here: https://github.com/nafg/reactive/blob/master/project/Build.scala. Note how it includes the pom xml that's required for releases, and how it selects a repository depending on whether version ends with "SNAPSHOT". At the moment I'm booted into Windows so I can't bring up the configuration for the GPG signer plugin.


On Wed, Jan 18, 2012 at 11:26 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Yes, I'd like to create some kind of central auth service for PGP keys such that I can mark my key as 'trusted scala OSS key' and users can use it to validate that software coming from me is indeed Scala OSS.  It's a rough idea, but more to follow (and it involves using github, oauth2, etc.)
- Josh

On Wed, Jan 18, 2012 at 10:29 AM, Doug Tangren <d.tangren@gmail.com> wrote:

2012/1/18 Maxime Lévesque <maxime.levesque@gmail.com>

Github has an api for publishing a user's public key :

  http://developer.github.com/v3/users/keys/

maybe a plugin (such as this one : https://github.com/sbt/xsbt-gpg-plugin )

could use the github key to sign the artifacts, it would remove a few steps and a bit of config.

Josh, did you say you had some thoughts on using gh as a platform for publishing?

 

ML

2012/1/18 Doug Tangren <d.tangren@gmail.com>

On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy.chheng@gmail.com> wrote:

Migrating to a single OSS repo like Sonatype would be great.

My only complain is:
Compare this lengthy complex 9 step process:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

with Clojure's main repo:
http://clojars.org/
$ lein pom
$ scp pom.xml mylib.jar clojars@clojars.org:

It would be great if there was a simple way to publish scala libs like this.

I really like this.

It's simple/ https://github.com/ato/clojars-web/wiki/tutorial looks like it uses an existing authentication mechanism, ssh keys.

npm, the node equiv, also has a super simple flow for publishing http://npmjs.org/doc/publish.html, http://npmjs.org/doc/developers.html I assume this also uses ssh keys to identify the publisher.

I have not as familiar with pgp, but it would be great to create an interface for something that as simple and straight forward to register for, as say clojars or npm, for the scala community exploiting this. When I hear, "just follow these simple nine steps", my stomache turns a little. I get the feeling that sonatype is really geared towards "the enterprise", but I personally really only care about small libraries made by "mom-and-pop" type authors in the open source community. For these, I feel like a complex and time consuming process just to publish a binary causes friction and may lead to downward trend of decent mom-and-pop authored libraries when it's visibly easier to publish in other communities. It was personally frustrating for me to get onto scala-tools because it was a long and drawn out process. This was in no way the fault of scala tools maintainers, but I think this had to do with the complexity and centralization of the administration of the project. Complexity -> bad.

Moving forward, people in the community have added first class build support for things like pgp signing that, I think?, could identify an authorized author to publish to "some repository in the cloud". It would be great to use something like this instead of a 9-step program which leads to a "we'll get to it when we get it" response for requests to publish.

I feel a bit a fervor in this area because I only recently got on scala-tools after some years in the community and now I hear its going down. I feel like others feel the same way too. Publishing should be simple. Finding Scala libraries should be simple[1]. Building Scala libraries should be simple [2]. Writing Scala libraries with good documentation should be simple [2]. There are a handful of projects out there tackling a handful of those problems, but I still feel like the publishing side of the dice is still not as simple as it could be. At least for a mom-and-pop type author who is excited about their new library, but cant publish it because the have to get in the back of the line.

That's my two cents

[1]: http://ls.implicit.ly/
[2]: https://github.com/harrah/xsbt/wiki
[3]: http://docs.scala-lang.org/

For what it's worth, reactive was always published to Sonatype, via sbt. You can see the build definition here: https://github.com/nafg/reactive/blob/master/project/Build.scala. Note how it includes the pom xml that's required for releases, and how it selects a repository depending on whether version ends with "SNAPSHOT". At the moment I'm booted into Windows so I can't bring up the configuration for the GPG signer plugin.


On Wed, Jan 18, 2012 at 11:26 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Yes, I'd like to create some kind of central auth service for PGP keys such that I can mark my key as 'trusted scala OSS key' and users can use it to validate that software coming from me is indeed Scala OSS.  It's a rough idea, but more to follow (and it involves using github, oauth2, etc.)
- Josh

On Wed, Jan 18, 2012 at 10:29 AM, Doug Tangren <d.tangren@gmail.com> wrote:

2012/1/18 Maxime Lévesque <maxime.levesque@gmail.com>

Github has an api for publishing a user's public key :

  http://developer.github.com/v3/users/keys/

maybe a plugin (such as this one : https://github.com/sbt/xsbt-gpg-plugin )

could use the github key to sign the artifacts, it would remove a few steps and a bit of config.

Josh, did you say you had some thoughts on using gh as a platform for publishing?

 

ML

2012/1/18 Doug Tangren <d.tangren@gmail.com>

On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy.chheng@gmail.com> wrote:

Migrating to a single OSS repo like Sonatype would be great.

My only complain is:
Compare this lengthy complex 9 step process:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

with Clojure's main repo:
http://clojars.org/
$ lein pom
$ scp pom.xml mylib.jar clojars@clojars.org:

It would be great if there was a simple way to publish scala libs like this.

I really like this.

It's simple/ https://github.com/ato/clojars-web/wiki/tutorial looks like it uses an existing authentication mechanism, ssh keys.

npm, the node equiv, also has a super simple flow for publishing http://npmjs.org/doc/publish.html, http://npmjs.org/doc/developers.html I assume this also uses ssh keys to identify the publisher.

I have not as familiar with pgp, but it would be great to create an interface for something that as simple and straight forward to register for, as say clojars or npm, for the scala community exploiting this. When I hear, "just follow these simple nine steps", my stomache turns a little. I get the feeling that sonatype is really geared towards "the enterprise", but I personally really only care about small libraries made by "mom-and-pop" type authors in the open source community. For these, I feel like a complex and time consuming process just to publish a binary causes friction and may lead to downward trend of decent mom-and-pop authored libraries when it's visibly easier to publish in other communities. It was personally frustrating for me to get onto scala-tools because it was a long and drawn out process. This was in no way the fault of scala tools maintainers, but I think this had to do with the complexity and centralization of the administration of the project. Complexity -> bad.

Moving forward, people in the community have added first class build support for things like pgp signing that, I think?, could identify an authorized author to publish to "some repository in the cloud". It would be great to use something like this instead of a 9-step program which leads to a "we'll get to it when we get it" response for requests to publish.

I feel a bit a fervor in this area because I only recently got on scala-tools after some years in the community and now I hear its going down. I feel like others feel the same way too. Publishing should be simple. Finding Scala libraries should be simple[1]. Building Scala libraries should be simple [2]. Writing Scala libraries with good documentation should be simple [2]. There are a handful of projects out there tackling a handful of those problems, but I still feel like the publishing side of the dice is still not as simple as it could be. At least for a mom-and-pop type author who is excited about their new library, but cant publish it because the have to get in the back of the line.

That's my two cents

[1]: http://ls.implicit.ly/
[2]: https://github.com/harrah/xsbt/wiki
[3]: http://docs.scala-lang.org/

I wrote instructions for anyone wishing to publish to sonatype:
https://github.com/sbt/sbt.github.com/blob/gen-master/src/jekyll/using_sonatype.md

On Mon, Jan 23, 2012 at 9:56 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

For what it's worth, reactive was always published to Sonatype, via sbt. You can see the build definition here: https://github.com/nafg/reactive/blob/master/project/Build.scala. Note how it includes the pom xml that's required for releases, and how it selects a repository depending on whether version ends with "SNAPSHOT". At the moment I'm booted into Windows so I can't bring up the configuration for the GPG signer plugin.


On Wed, Jan 18, 2012 at 11:26 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Yes, I'd like to create some kind of central auth service for PGP keys such that I can mark my key as 'trusted scala OSS key' and users can use it to validate that software coming from me is indeed Scala OSS.  It's a rough idea, but more to follow (and it involves using github, oauth2, etc.)
- Josh

On Wed, Jan 18, 2012 at 10:29 AM, Doug Tangren <d.tangren@gmail.com> wrote:

2012/1/18 Maxime Lévesque <maxime.levesque@gmail.com>

Github has an api for publishing a user's public key :

  http://developer.github.com/v3/users/keys/

maybe a plugin (such as this one : https://github.com/sbt/xsbt-gpg-plugin )

could use the github key to sign the artifacts, it would remove a few steps and a bit of config.

Josh, did you say you had some thoughts on using gh as a platform for publishing?

 

ML

2012/1/18 Doug Tangren <d.tangren@gmail.com>

On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy.chheng@gmail.com> wrote:

Migrating to a single OSS repo like Sonatype would be great.

My only complain is:
Compare this lengthy complex 9 step process:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

with Clojure's main repo:
http://clojars.org/
$ lein pom
$ scp pom.xml mylib.jar clojars@clojars.org:

It would be great if there was a simple way to publish scala libs like this.

I really like this.

It's simple/ https://github.com/ato/clojars-web/wiki/tutorial looks like it uses an existing authentication mechanism, ssh keys.

npm, the node equiv, also has a super simple flow for publishing http://npmjs.org/doc/publish.html, http://npmjs.org/doc/developers.html I assume this also uses ssh keys to identify the publisher.

I have not as familiar with pgp, but it would be great to create an interface for something that as simple and straight forward to register for, as say clojars or npm, for the scala community exploiting this. When I hear, "just follow these simple nine steps", my stomache turns a little. I get the feeling that sonatype is really geared towards "the enterprise", but I personally really only care about small libraries made by "mom-and-pop" type authors in the open source community. For these, I feel like a complex and time consuming process just to publish a binary causes friction and may lead to downward trend of decent mom-and-pop authored libraries when it's visibly easier to publish in other communities. It was personally frustrating for me to get onto scala-tools because it was a long and drawn out process. This was in no way the fault of scala tools maintainers, but I think this had to do with the complexity and centralization of the administration of the project. Complexity -> bad.

Moving forward, people in the community have added first class build support for things like pgp signing that, I think?, could identify an authorized author to publish to "some repository in the cloud". It would be great to use something like this instead of a 9-step program which leads to a "we'll get to it when we get it" response for requests to publish.

I feel a bit a fervor in this area because I only recently got on scala-tools after some years in the community and now I hear its going down. I feel like others feel the same way too. Publishing should be simple. Finding Scala libraries should be simple[1]. Building Scala libraries should be simple [2]. Writing Scala libraries with good documentation should be simple [2]. There are a handful of projects out there tackling a handful of those problems, but I still feel like the publishing side of the dice is still not as simple as it could be. At least for a mom-and-pop type author who is excited about their new library, but cant publish it because the have to get in the back of the line.

That's my two cents

[1]: http://ls.implicit.ly/
[2]: https://github.com/harrah/xsbt/wiki
[3]: http://docs.scala-lang.org/

I'm not fond of the Credentials step where I type my Sonatype password and save it in clear text. Surely there's a better way?

On Thu, Feb 16, 2012 at 9:56 AM, Marcus Downing
wrote:
> I'm not fond of the Credentials step where I type my Sonatype password and
> save it in clear text. Surely there's a better way?

Yeah, you can put all your repository credentials in a central file
and reference that one.

See here for a complete working sonatype setup:

https://github.com/jrudolph/sbt-dependency-graph/blob/master