- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Scala-tools.org going down
Tue, 2012-01-17, 21:47
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
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
Tue, 2012-01-17, 23:21
#2
Re: Scala-tools.org going down
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+Reposito...
>
> with Clojure's main repo:
> http://clojars.org/
> $ lein pom
> $ scp pom.xml mylib.jar clojars [at] clojars [dot] 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.
Tue, 2012-01-17, 23:21
#3
Re: Scala-tools.org going down
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+Reposito...
>
> with Clojure's main repo:
> http://clojars.org/
> $ lein pom
> $ scp pom.xml mylib.jar clojars [at] clojars [dot] 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.
Tue, 2012-01-17, 23:21
#4
Re: Scala-tools.org going down
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+Reposito...
>
> with Clojure's main repo:
> http://clojars.org/
> $ lein pom
> $ scp pom.xml mylib.jar clojars [at] clojars [dot] 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.
Tue, 2012-01-17, 23:31
#5
Re: Re: Scala-tools.org going down
On Tue, Jan 17, 2012 at 2:11 PM, Erik Osheim wrote:
>> with Clojure's main repo:
>> http://clojars.org/
>> $ lein pom
>> $ scp pom.xml mylib.jar clojars [at] clojars [dot] org:
>>
>> It would be great if there was a simple way to publish scala libs like this.
That seems a little too easy. I wouldn't be comfortable adding
dependencies to jars on clojars.org knowing that at any time, someone
could trivially replace a jar on which I depend with one containing
malicious code.
The fact that SonaType prevents anyone from uploading to a groupId
claimed by an existing library maintainer is a good thing, IMO. I'd
prefer there were fewer hoops to jump through, but these hoops are
pretty painless. It requires *far* less effort than, say, maintaining
an open source library used by a non-zero number of third parties.
Once you have SonaType credentials that allow you to publish to a
given groupId, the remainder of the process is pretty close to dead
easy. The vast majority of the complexity at that point is figuring
out how to get SBT to perform the appropriate machinations. Lucky for
you, I've already done that. Just cargo cult from here:
https://github.com/samskivert/pom-util/blob/master/build.sbt
Wed, 2012-01-18, 05:21
#6
Re: Scala-tools.org going down
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
On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy [dot] chheng [at] gmail [dot] com> wrote:
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
On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy [dot] chheng [at] gmail [dot] 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 [at] clojars [dot] org:
It would be great if there was a simple way to publish scala libs like this.
On Tue, Jan 17, 2012 at 12:47 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
> 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
Wed, 2012-01-18, 05:31
#7
Re: Scala-tools.org going down
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
On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy [dot] chheng [at] gmail [dot] com> wrote:
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
On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy [dot] chheng [at] gmail [dot] 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 [at] clojars [dot] org:
It would be great if there was a simple way to publish scala libs like this.
On Tue, Jan 17, 2012 at 12:47 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
> 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
Wed, 2012-01-18, 05:31
#8
Re: Scala-tools.org going down
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
On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy [dot] chheng [at] gmail [dot] com> wrote:
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
On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy [dot] chheng [at] gmail [dot] 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 [at] clojars [dot] org:
It would be great if there was a simple way to publish scala libs like this.
On Tue, Jan 17, 2012 at 12:47 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
> 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
Wed, 2012-01-18, 05:31
#9
Re: Scala-tools.org going down
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
On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy [dot] chheng [at] gmail [dot] com> wrote:
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
On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy [dot] chheng [at] gmail [dot] 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 [at] clojars [dot] org:
It would be great if there was a simple way to publish scala libs like this.
On Tue, Jan 17, 2012 at 12:47 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
> 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
Wed, 2012-01-18, 07:41
#10
Re: Re: Scala-tools.org going down
[...] 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
Wed, 2012-01-18, 07:41
#11
Re: Re: Scala-tools.org going down
[...] 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
Wed, 2012-01-18, 07:41
#12
Re: Re: Scala-tools.org going down
[...] 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
Wed, 2012-01-18, 07:51
#13
Re: Re: Scala-tools.org going down
[...] 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
Wed, 2012-01-18, 09:31
#14
Re: Scala-tools.org going down
Yo all,
"The benefit of Sonatype hosting is that your projects will make
it onto the maven-central repository and benefit from the myriads of
mirrors."
Correct me if I'm wrong, but scala-tools repository WAS mirrored to
maven-central (it take some day to see your package in it, but it was
mirrored).
I never published Sindi somewhere else than ScalaTools and you can see
it is in maven central:
http://repo1.maven.org/maven2/org/scala-tools/sindi/sindi-compiler_2.9.1...
+1 with Daniel, forcing signing could be difficutl in some situation.
Couldn't typesafe setup a maven repository for the open-source
community?
I don't think it's such a big deal for a company like typesafe and it
will help users to find library related to scala development in one
place instead of having them mixed with whole JVM universe.
Stil the typesafe OSS repo could be mirrored into maven-central like
was scala-tools.
Just my 2 cents,
Cheers,
Alois Cochard
On Jan 18, 7:39 am, Daniel Spiewak wrote:
> > [...] 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
Wed, 2012-01-18, 10:01
#15
Re: Scala-tools.org going down
On Wednesday, January 18, 2012 8:30:38 AM UTC, Alois Cochard wrote:
Wasn't it only parts of the repo, e.g. below org.scala-tools? I don't believe Scalariform was mirrored, for example.
-- Matt
Correct me if I'm wrong, but scala-tools repository WAS mirrored to
maven-central (it take some day to see your package in it, but it was
mirrored).
Wasn't it only parts of the repo, e.g. below org.scala-tools? I don't believe Scalariform was mirrored, for example.
-- Matt
Wed, 2012-01-18, 10:11
#16
Re: Re: Scala-tools.org going down
I don't think Josh meant that it's a benefit over scala-tools --- he wasn't explaining why it was going down. He just recommended Sonatype as an alternative over other alternatives, because it's mirrored to central.
On Wed, Jan 18, 2012 at 3:30 AM, Alois Cochard <alois [dot] cochard [at] gmail [dot] com> wrote:
On Wed, Jan 18, 2012 at 3:30 AM, Alois Cochard <alois [dot] cochard [at] gmail [dot] com> wrote:
Yo all,
"The benefit of Sonatype hosting is that your projects will make
it onto the maven-central repository and benefit from the myriads of
mirrors."
Correct me if I'm wrong, but scala-tools repository WAS mirrored to
maven-central (it take some day to see your package in it, but it was
mirrored).
I never published Sindi somewhere else than ScalaTools and you can see
it is in maven central:
http://repo1.maven.org/maven2/org/scala-tools/sindi/sindi-compiler_2.9.1/0.3/sindi-compiler_2.9.1-0.3.pom
+1 with Daniel, forcing signing could be difficutl in some situation.
Couldn't typesafe setup a maven repository for the open-source
community?
I don't think it's such a big deal for a company like typesafe and it
will help users to find library related to scala development in one
place instead of having them mixed with whole JVM universe.
Stil the typesafe OSS repo could be mirrored into maven-central like
was scala-tools.
Just my 2 cents,
Cheers,
Alois Cochard
On Jan 18, 7:39 am, Daniel Spiewak <djspie [dot] [dot] [dot] [at] gmail [dot] com> wrote:
> > [...] 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
Wed, 2012-01-18, 11:51
#17
Re: Scala-tools.org going down
Ok, I found an alternative for ones who don't want to setup the Nexus
thing (i.e. for small experimental project)
You can use github as maven repository:
http://cemerick.com/2010/08/24/hosting-maven-repos-on-github/
Cheers,
On Jan 18, 7:39 am, Daniel Spiewak wrote:
> > [...] 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
Wed, 2012-01-18, 14:31
#18
Re: Re: Scala-tools.org going down
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.
On Wed, Jan 18, 2012 at 1:39 AM, Daniel Spiewak <djspiewak [at] gmail [dot] com> wrote:
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.
On Wed, Jan 18, 2012 at 1:39 AM, Daniel Spiewak <djspiewak [at] gmail [dot] com> wrote:
[...] 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
Wed, 2012-01-18, 14:31
#19
Re: Re: Scala-tools.org going down
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.
On Wed, Jan 18, 2012 at 1:39 AM, Daniel Spiewak <djspiewak [at] gmail [dot] com> wrote:
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.
On Wed, Jan 18, 2012 at 1:39 AM, Daniel Spiewak <djspiewak [at] gmail [dot] com> wrote:
[...] 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
Wed, 2012-01-18, 14:31
#20
Re: Re: Scala-tools.org going down
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.
On Wed, Jan 18, 2012 at 1:39 AM, Daniel Spiewak <djspiewak [at] gmail [dot] com> wrote:
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.
On Wed, Jan 18, 2012 at 1:39 AM, Daniel Spiewak <djspiewak [at] gmail [dot] com> wrote:
[...] 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
Wed, 2012-01-18, 14:31
#21
Re: Re: Scala-tools.org going down
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.
On Wed, Jan 18, 2012 at 1:39 AM, Daniel Spiewak <djspiewak [at] gmail [dot] com> wrote:
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.
On Wed, Jan 18, 2012 at 1:39 AM, Daniel Spiewak <djspiewak [at] gmail [dot] com> wrote:
[...] 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
Wed, 2012-01-18, 14:41
#22
Re: Re: Scala-tools.org going down
I can recommend against this for anything long term. I've had issues with repositories in github. For experimental projects it may be ok,but it's best to get yourself on nexus or somewhere better quickly.
On Wed, Jan 18, 2012 at 5:40 AM, Alois Cochard <alois [dot] cochard [at] gmail [dot] com> wrote:
On Wed, Jan 18, 2012 at 5:40 AM, Alois Cochard <alois [dot] cochard [at] gmail [dot] com> wrote:
Ok, I found an alternative for ones who don't want to setup the Nexus
thing (i.e. for small experimental project)
You can use github as maven repository:
http://cemerick.com/2010/08/24/hosting-maven-repos-on-github/
Cheers,
On Jan 18, 7:39 am, Daniel Spiewak <djspie [dot] [dot] [dot] [at] gmail [dot] com> wrote:
> > [...] 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
Wed, 2012-01-18, 14:51
#23
Re: Re: Scala-tools.org going down
On Wed, Jan 18, 2012 at 3:30 AM, Alois Cochard <alois [dot] cochard [at] gmail [dot] com> wrote:
Yo all,
"The benefit of Sonatype hosting is that your projects will make
it onto the maven-central repository and benefit from the myriads of
mirrors."
Correct me if I'm wrong, but scala-tools repository WAS mirrored to
maven-central (it take some day to see your package in it, but it was
mirrored).
I never published Sindi somewhere else than ScalaTools and you can see
it is in maven central:
http://repo1.maven.org/maven2/org/scala-tools/sindi/sindi-compiler_2.9.1/0.3/sindi-compiler_2.9.1-0.3.pom
+1 with Daniel, forcing signing could be difficutl in some situation.
If you aren't signing your *released* software with your name, then you're doing all of us a disservice. PGP signatures are *easy* and there is support in all major build tools. I released a plugin for SBT where you can generate a PGP key and sign your code using just the JVM, so there's no excuse in SBT.
In fact, scala-tools.org, as part of being mirrored to maven-central, was going to start requiring PGP signatures in the near future. That was until Derek and I got busy.
Couldn't typesafe setup a maven repository for the open-source
community?
I don't think it's such a big deal for a company like typesafe and it
will help users to find library related to scala development in one
place instead of having them mixed with whole JVM universe.
Stil the typesafe OSS repo could be mirrored into maven-central like
was scala-tools.
Mirroring to maven-central requires help from Sonatype. scala-tools.org got special permission, call it being "grandfathered" in. While I'm sure typesafe will provide a repository if needed, I'm not sure it's necessary or would improve upon the free offerings of Sonatype. The PGP signature requirement is a must for any newly made repository. I'd prefer it if tools like SBT warned when using non-signed software, like APT or YUM.
I totally understand wanting a repository for *just* Scala software. I'm hoping projects like http://ls.implicit.ly can fill in the gap (that scala-tools.org wanted to be, but wasn't). There's also the other side to this coin. Rather than isolating scala software, if we push to maven-central we become more visible to JVM citizens. I'd prefer if maven-central became 90% Scala projects with a smattering of Java here and there.
Wed, 2012-01-18, 15:01
#24
Re: Scala-tools.org going down
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
Wed, 2012-01-18, 15:11
#25
Re: Re: Scala-tools.org going down
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
On Wed, Jan 18, 2012 at 8:56 AM, Sonnenschein <peter [dot] empen [at] arcor [dot] de> wrote:
- Josh
On Wed, Jan 18, 2012 at 8:56 AM, Sonnenschein <peter [dot] empen [at] arcor [dot] de> wrote:
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
Wed, 2012-01-18, 15:31
#26
Re: Scala-tools.org going down
> I totally understand wanting a repository for *just* Scala software. I'm
> hoping projects likehttp://ls.implicit.lycan fill in the gap (that
> scala-tools.org wanted to be, but wasn't). There's also the other side to
> this coin. Rather than isolating scala software, if we push to
> maven-central we become more visible to JVM citizens. I'd prefer if
> maven-central became 90% Scala projects with a smattering of Java here and
> there.
Fair point!
I forgot to look at the other side to this coin ;)
Thanks,
Wed, 2012-01-18, 16:11
#27
Re: Scala-tools.org going down
On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy [dot] chheng [at] gmail [dot] com> wrote:
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/
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 [at] clojars [dot] 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/
Wed, 2012-01-18, 16:11
#28
Re: Scala-tools.org going down
On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy [dot] chheng [at] gmail [dot] com> wrote:
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/
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 [at] clojars [dot] 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/
Wed, 2012-01-18, 16:11
#29
Re: Scala-tools.org going down
On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy [dot] chheng [at] gmail [dot] com> wrote:
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/
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 [at] clojars [dot] 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/
Wed, 2012-01-18, 16:11
#30
Re: Scala-tools.org going down
On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy [dot] chheng [at] gmail [dot] com> wrote:
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/
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 [at] clojars [dot] 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/
Wed, 2012-01-18, 16:31
#31
Re: Re: Scala-tools.org going down
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 [dot] tangren [at] gmail [dot] com>
On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy [dot] chheng [at] gmail [dot] 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 [at] clojars [dot] 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/
Wed, 2012-01-18, 16:31
#32
Re: Re: Scala-tools.org going down
2012/1/18 Maxime Lévesque <maxime [dot] levesque [at] gmail [dot] 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 [dot] tangren [at] gmail [dot] com>
On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy [dot] chheng [at] gmail [dot] 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 [at] clojars [dot] 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/
Wed, 2012-01-18, 16:31
#33
Re: Re: Scala-tools.org going down
2012/1/18 Maxime Lévesque <maxime [dot] levesque [at] gmail [dot] 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 [dot] tangren [at] gmail [dot] com>
On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy [dot] chheng [at] gmail [dot] 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 [at] clojars [dot] 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/
Wed, 2012-01-18, 16:31
#34
Re: Re: Scala-tools.org going down
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 [dot] tangren [at] gmail [dot] com>
On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy [dot] chheng [at] gmail [dot] 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 [at] clojars [dot] 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/
Wed, 2012-01-18, 16:41
#35
Re: Re: Scala-tools.org going down
2012/1/18 Maxime Lévesque <maxime [dot] levesque [at] gmail [dot] 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 [dot] tangren [at] gmail [dot] com>
On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy [dot] chheng [at] gmail [dot] 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 [at] clojars [dot] 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/
Wed, 2012-01-18, 16:41
#36
Re: Re: Scala-tools.org going down
2012/1/18 Maxime Lévesque <maxime [dot] levesque [at] gmail [dot] 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 [dot] tangren [at] gmail [dot] com>
On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy [dot] chheng [at] gmail [dot] 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 [at] clojars [dot] 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/
Wed, 2012-01-18, 16:51
#37
Re: Re: Scala-tools.org going down
2012/1/18 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.
These are ssh keys and usually you use private keys for signing...
Wed, 2012-01-18, 16:51
#38
Re: Re: Scala-tools.org going down
2012/1/18 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.
These are ssh keys and usually you use private keys for signing...
Wed, 2012-01-18, 17:01
#39
Re: Re: Scala-tools.org going down
2012/1/18 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.
These are ssh keys and usually you use private keys for signing...
Wed, 2012-01-18, 17:01
#40
Re: Re: Scala-tools.org going down
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
Wed, 2012-01-18, 17:01
#41
Re: Re: Scala-tools.org going down
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
Wed, 2012-01-18, 17:01
#42
Re: Re: Scala-tools.org going down
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
Wed, 2012-01-18, 17:01
#43
Re: Re: Scala-tools.org going down
2012/1/18 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.
These are ssh keys and usually you use private keys for signing...
Wed, 2012-01-18, 17:01
#44
Re: Re: Scala-tools.org going down
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
Wed, 2012-01-18, 17:11
#45
Re: Re: Scala-tools.org going down
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 [dot] rudolph [at] googlemail [dot] com>
2012/1/18 Maxime Lévesque <maxime [dot] levesque [at] gmail [dot] 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
Wed, 2012-01-18, 17:11
#46
Re: Re: 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.
Wed, 2012-01-18, 17:11
#47
Re: Re: Scala-tools.org going down
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 [dot] rudolph [at] googlemail [dot] com>
2012/1/18 Maxime Lévesque <maxime [dot] levesque [at] gmail [dot] 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
Wed, 2012-01-18, 17:31
#48
Re: Re: Scala-tools.org going down
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 [dot] rudolph [at] googlemail [dot] com>
- Josh
2012/1/18 Johannes Rudolph <johannes [dot] rudolph [at] googlemail [dot] com>
2012/1/18 Maxime Lévesque <maxime [dot] levesque [at] gmail [dot] 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
Wed, 2012-01-18, 17:31
#49
Re: Re: Scala-tools.org going down
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 [dot] tangren [at] gmail [dot] com> wrote:
- Josh
On Wed, Jan 18, 2012 at 10:29 AM, Doug Tangren <d [dot] tangren [at] gmail [dot] com> wrote:
2012/1/18 Maxime Lévesque <maxime [dot] levesque [at] gmail [dot] 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 [dot] tangren [at] gmail [dot] com>
On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy [dot] chheng [at] gmail [dot] 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 [at] clojars [dot] 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/
Wed, 2012-01-18, 17:31
#50
Re: Re: Scala-tools.org going down
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 [dot] tangren [at] gmail [dot] com> wrote:
- Josh
On Wed, Jan 18, 2012 at 10:29 AM, Doug Tangren <d [dot] tangren [at] gmail [dot] com> wrote:
2012/1/18 Maxime Lévesque <maxime [dot] levesque [at] gmail [dot] 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 [dot] tangren [at] gmail [dot] com>
On Tue, Jan 17, 2012 at 4:36 PM, Tommy Chheng <tommy [dot] chheng [at] gmail [dot] 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 [at] clojars [dot] 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/
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+Reposito...
with Clojure's main repo:
http://clojars.org/
$ lein pom
$ scp pom.xml mylib.jar clojars [at] clojars [dot] org:
It would be great if there was a simple way to publish scala libs like this.
On Tue, Jan 17, 2012 at 12:47 PM, Josh Suereth wrote:
> 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