Scala-tools.org going down

[Josh Suereth]

http://lift.la/scala-toolsorg-winding-down

Scala-tools.org is going down and not accepting any new OSS projects.   For those of us who wish to continue release software, I recommend migrating over to Sonatype.   They put a few (good practice) limitations on contributions, but scala-tools.org would have done the same before long anyway.   The benefit of Sonatype hosting is that your projects will make it onto the maven-central repository and benefit from the myriads of mirrors.  

Here's the link for how to get started contacting Sonatype:  http://nexus.sonatype.org/oss-repository-hosting.html

As an aside, I'd like to migrate the scala project itself to a sonatype hosted OSS repository.  Wanted to see what everyone else thinks of this.

- Josh

[Tommy Chheng]

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 clo...@clojars.org:

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

--
Tommy Chheng

[Erik Osheim]

On Tue, Jan 17, 2012 at 01:36:58PM -0800, Tommy Chheng wrote:
> 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 clo...@clojars.org:
>
> It would be great if there was a simple way to publish scala libs like this.

Agreed. The phrase "dead easy" is one I would love to be able to use
more w.r.t. things like this.

-- Erik

[Josh Suereth]

Requiring GPG keys and owning domains is something we're going to keep up for safety reasons.  Not doing so is asking for developers not to take your releases seriously.

That said, I want to make the release process for Scala software *almost* that simple.   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.

- Josh

[Daniel Spiewak]

[...] owning domains is something we're going to keep up for safety reasons.  Not doing so is asking for developers not to take your releases seriously.

This is actually an extremely onerous restriction, even for certain completely above-board applications.  A good example of this is my GLL combinators project, which was developed under the auspices of UW Milwaukee.  As such, I used the groupId and package name of edu.uwm.cs.  This is completely correct and (arguably) even a best practice w.r.t. crediting the university.  Unfortunately, as anyone who has worked in academia will tell you, getting any sort of confirmation or written permission takes years, if it happens at all.  This is why my GLL combinators project still hasn't been published to any repo.

I don't have a better solution than forcing domain ownership.  I just wanted to add my two cents about how it has severely hampered things in my case, despite the full legitimacy of what I'm attempting to do (publish my project).

Daniel

[Josh Suereth]

Does the university own the code?  If so, did they approve you going open-source?  This may be an implicit acknowledgement that you're allowed to use their domain to associate your code with the university. 

If they didn't give you any sort of permissions, then (a) you should not have released the library as OSS or (b) *you* own the code and it should be under your domain.

What you're talking of is an issue with OSS and universities.  When I was with Johns Hopkins, doing any sort of OSS was a PITA thanks to how many approvals I needed.   The solution there was to work on OSS that had nothing to do with work.

The burden here is in namespacing software so that we can have competing versions of things.  While I hate money-making-security-rackets, the burden here is as low as I think is practical.   Owning domain names is pretty cheap *and* scala-tools.org used to provide its usage to libraries.   

While I can't offer the scala-tools.org domain any longer, com.github.<username> makes an excellent substitute as you have control over your subdomain on github.  

Note:   The domain you publish to a repository with does not *have* to be the same as the package for your application.   I've deviated from this practice in a few core pieces of my software.

[Sonnenschein]

Hi Josh,

as the official build tool for OSS is SBT I'd like to be able to
publish releases with SBT:). Otherwise contributores are forced to
employ SBT *and* Maven. (Or just Maven?:()

Peter

[Josh Suereth]

You can publish to sonatype nexus with SBT.  scala-tools.org ran on sonatype software.  The only difference between using scala-tools.org and sonatype is that sonatype has dedicated resources to ensure things are working and scala-tools.org was volunteer.

- Josh

[Doug Tangren]

On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy....@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 clo...@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/

[Maxime Lévesque]

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.

ML

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

[Doug Tangren]

2012/1/18 Maxime Lévesque <maxime....@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?

 

[Johannes Rudolph]

2012/1/18 Maxime Lévesque <maxime....@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.

These are ssh keys and usually you use private keys for signing...

--
Johannes

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

[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...

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

[Daniel Spiewak]

Does the university own the code?  If so, did they approve you going open-source?  This may be an implicit acknowledgement that you're allowed to use their domain to associate your code with the university. 

I own the code.  There was no explicit or implicit approval of anything.  In any case, implicit acknowledgements have never really been accepted, at least not by scala-tools.  If that were the case, then the fact that I'm associated with the university would have been sufficient.
 

If they didn't give you any sort of permissions, then (a) you should not have released the library as OSS or (b) *you* own the code and it should be under your domain.

I do own the code, and it could go under my domain, but that would be…weird.  It's the solution I have to go with, but I'm not happy about it.  The code was developed in an academic setting under the auspices of a specific university, it should be using their package name.
 

What you're talking of is an issue with OSS and universities.  When I was with Johns Hopkins, doing any sort of OSS was a PITA thanks to how many approvals I needed.   The solution there was to work on OSS that had nothing to do with work.

UWM is a little better in that respect.  Generally speaking, they just assume you're going to launch everything into public domain.  OSS is only slightly more restrictive than that, and has never been a problem.
 

The burden here is in namespacing software so that we can have competing versions of things.  While I hate money-making-security-rackets, the burden here is as low as I think is practical.   Owning domain names is pretty cheap *and* scala-tools.org used to provide its usage to libraries.   

I'm all in favor of namespacing (and signing, for that matter), and there's really no technical problem with using my own domain for everything I write.  It's not a normal thing to do for academic work though, which is why it bugs me.
 

Note:   The domain you publish to a repository with does not *have* to be the same as the package for your application.   I've deviated from this practice in a few core pieces of my software.

Scala-tools was pretty strict about this.  They let me get away with not doing it for Anti-XML, but they weren't happy.  It's good to know that wasn't a normal Maven repo restriction.

Daniel

[Johannes Rudolph]

2012/1/18 Maxime Lévesque <maxime....@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.

[Josh Suereth]

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...@googlemail.com>

[Josh Suereth]

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

[Naftoli Gugenheim]

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.

[Josh Suereth]

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

[Marcus Downing]

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?

[Johannes Rudolph]

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