Where to look for Scala libraries?

http://implicit.lyhttp://github.com/languages/Scalahttp://www.scala-tools.org/

On Sun, Apr 18, 2010 at 11:15 PM, Toby Corkindale <toby@dryft.net> wrote:

Hi,
I wondered if people could tell me where they go to look for Scala libraries?
Currently I just hit Google and hope there's something useful there,
but it's really not a good way to go about it.
I wondered if there is a web site which collates all the available
libraries, preferably with their versions, changelogs and maybe
integrated bug-tracking?
(OK, so what I really want is the equivalent of
http://search.cpan.org/ except for Scala instead of Perl)

Is there anything like that out there?
How do YOU find libraries for things you need? Or does everyone on
Scala just reinvent the wheel every time they need to do something
like parse CSV files or RSS feeds?

Cheers,
Toby

--
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world

--
Daniel C. Sobral

I travel to the future all the time.

Hi Daniel,
Thanks for the responses - I've had a quick look at them, comments below.
I hope I don't come across as annoying in the responses to each; I'm
just trying to give some criticism from the point-of-view of someone
who is trying to pick up Scala, and coming from a much older language.

On 19 April 2010 12:45, Daniel Sobral wrote:
> http://implicit.ly

This looks like an interesting blog for keeping up to date with new
releases as they are developed, but isn't very useful as a repository
of available libraries - unless I'm missing something?

> http://www.scala-tools.org/

There might be good things here, but how do I find them?
Browsing the Maven repository just gives me useless top-level package
fragments like "eu", "hoffrocket", "org".

It would be much better, IMHO, to have a list of libraries by what
they do - eg. top level directories should be "file processing",
"networking", "multimedia", "math", etc.
I mean, I know what "Lift" is, due to seeing it linked from the
Scala-lang site; but I wouldn't know that just from the name. Whereas
if it was located in a category like "Web frameworks" I'd know
straight away.

> http://github.com/languages/Scala

Again, not very helpful for people who don't already know the name of
the project.
I see that "posterous", "pinky" and "scopt" are popular today, but I
have no idea what they do, and it doesn't help if I'm looking for
something to, say, process Apache log files, or transcode video on the
fly to a REST client.

I tried using the Search box, but in the Languages selection box there
is no option for Scala, and searching for "scala csv" turns up loads
of individual source files, rather than appropriate libraries.

So, is it just that everyone in the Scala world tends to like building
their own wheels or is Scala mainly used for projects that are
unlikely to have any commonly-reused parts after all, apart from the
stuff included in the core Scala library?

Or is it more than people tend to use Java libraries for much of the
underlying work, just glueing them together with Scala?

Cheers,
Toby

> On Sun, Apr 18, 2010 at 11:15 PM, Toby Corkindale wrote:
>>
>> Hi,
>> I wondered if people could tell me where they go to look for Scala
>> libraries?
>> Currently I just hit Google and hope there's something useful there,
>> but it's really not a good way to go about it.
>> I wondered if there is a web site which collates all the available
>> libraries, preferably with their versions, changelogs and maybe
>> integrated bug-tracking?
>> (OK, so what I really want is the equivalent of
>> http://search.cpan.org/ except for Scala instead of Perl)
>>
>> Is there anything like that out there?
>> How do YOU find libraries for things you need? Or does everyone on
>> Scala just reinvent the wheel every time they need to do something
>> like parse CSV files or RSS feeds?

Right now, scala seems to be getting used in one of 4 ways:
- New applications, totally written in Scala, maybe with one of the "big" frameworks such as Lift, Akka, or Scalaz- As a testing framework for an existing Java application, typically involving ScalaTest or Specs - As a gradual migration, slowly changing individual Java classes to Scala, leaving existing libraries largely as they are- Academically, exploring ideas such as Actors, Parsers and the Type System
Of those people using Scala in production, a java-hybrid approach still seems to be prevalent (with existing Java libraries, as you suggest), this will no doubt yield to more pure-scala solutions as time passes.
So yes, cross-fertilisation of the ecosystem is right now mostly taking place via the mailing lists, blogs, presentations, etc.  This likely won't scale so well as the community grows.

I can't help but wonder if this wouldn't be a very good candidate to go on the remit of the newly-announced Scala Foundation, as mentioned at the close of Scala Days 2010 last week.


On 19 April 2010 08:14, Toby Corkindale <toby@dryft.net> wrote:

Hi Daniel,
Thanks for the responses - I've had a quick look at them, comments below.
I hope I don't come across as annoying in the responses to each; I'm
just trying to give some criticism from the point-of-view of someone
who is trying to pick up Scala, and coming from a much older language.

On 19 April 2010 12:45, Daniel Sobral <dcsobral@gmail.com> wrote:
> http://implicit.ly

This looks like an interesting blog for keeping up to date with new
releases as they are developed, but isn't very useful as a repository
of available libraries - unless I'm missing something?

> http://www.scala-tools.org/

There might be good things here, but how do I find them?
Browsing the Maven repository just gives me useless top-level package
fragments like "eu", "hoffrocket", "org".

It would be much better, IMHO, to have a list of libraries by what
they do - eg. top level directories should be "file processing",
"networking", "multimedia", "math", etc.
I mean, I know what "Lift" is, due to seeing it linked from the
Scala-lang site; but I wouldn't know that just from the name. Whereas
if it was located in a category like "Web frameworks" I'd know
straight away.

> http://github.com/languages/Scala

Again, not very helpful for people who don't already know the name of
the project.
I see that "posterous", "pinky" and "scopt" are popular today, but I
have no idea what they do, and it doesn't help if I'm looking for
something to, say, process Apache log files, or transcode video on the
fly to a REST client.

I tried using the Search box, but in the Languages selection box there
is no option for Scala, and searching for "scala csv" turns up loads
of individual source files, rather than appropriate libraries.


So, is it just that everyone in the Scala world tends to like building
their own wheels or is Scala mainly used for projects that are
unlikely to have any commonly-reused parts after all, apart from the
stuff included in the core Scala library?

Or is it more than people tend to use Java libraries for much of the
underlying work, just glueing them together with Scala?

Cheers,
Toby


> On Sun, Apr 18, 2010 at 11:15 PM, Toby Corkindale <toby@dryft.net> wrote:
>>
>> Hi,
>> I wondered if people could tell me where they go to look for Scala
>> libraries?
>> Currently I just hit Google and hope there's something useful there,
>> but it's really not a good way to go about it.
>> I wondered if there is a web site which collates all the available
>> libraries, preferably with their versions, changelogs and maybe
>> integrated bug-tracking?
>> (OK, so what I really want is the equivalent of
>> http://search.cpan.org/ except for Scala instead of Perl)
>>
>> Is there anything like that out there?
>> How do YOU find libraries for things you need? Or does everyone on
>> Scala just reinvent the wheel every time they need to do something
>> like parse CSV files or RSS feeds?

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

At ScalaDays, a few people requested an easily discoverable catalog of
libraries, citing RubyGems as an example.

A small catalog already exists on the scala-lang website:

http://www.scala-lang.org/node/1209

Naturally, some if the information is a dated, perhaps library authors
could take this opportunity to review the content and suggest updates?

Toby: In your opinion, how could this page be easier to discover, and
how could the content be better structured?

-jason

On Mon, Apr 19, 2010 at 9:14 AM, Toby Corkindale wrote:
> Hi Daniel,
> Thanks for the responses - I've had a quick look at them, comments below.
> I hope I don't come across as annoying in the responses to each; I'm
> just trying to give some criticism from the point-of-view of someone
> who is trying to pick up Scala, and coming from a much older language.
>
> On 19 April 2010 12:45, Daniel Sobral wrote:
>> http://implicit.ly
>
> This looks like an interesting blog for keeping up to date with new
> releases as they are developed, but isn't very useful as a repository
> of available libraries - unless I'm missing something?
>
>> http://www.scala-tools.org/
>
> There might be good things here, but how do I find them?
> Browsing the Maven repository just gives me useless top-level package
> fragments like "eu", "hoffrocket", "org".
>
> It would be much better, IMHO, to have a list of libraries by what
> they do - eg. top level directories should be "file processing",
> "networking", "multimedia", "math", etc.
> I mean, I know what "Lift" is, due to seeing it linked from the
> Scala-lang site; but I wouldn't know that just from the name. Whereas
> if it was located in a category like "Web frameworks" I'd know
> straight away.
>
>> http://github.com/languages/Scala
>
> Again, not very helpful for people who don't already know the name of
> the project.
> I see that "posterous", "pinky" and "scopt" are popular today, but I
> have no idea what they do, and it doesn't help if I'm looking for
> something to, say, process Apache log files, or transcode video on the
> fly to a REST client.
>
> I tried using the Search box, but in the Languages selection box there
> is no option for Scala, and searching for "scala csv" turns up loads
> of individual source files, rather than appropriate libraries.
>
>
> So, is it just that everyone in the Scala world tends to like building
> their own wheels or is Scala mainly used for projects that are
> unlikely to have any commonly-reused parts after all, apart from the
> stuff included in the core Scala library?
>
> Or is it more than people tend to use Java libraries for much of the
> underlying work, just glueing them together with Scala?
>
> Cheers,
> Toby
>
>
>> On Sun, Apr 18, 2010 at 11:15 PM, Toby Corkindale wrote:
>>>
>>> Hi,
>>> I wondered if people could tell me where they go to look for Scala
>>> libraries?
>>> Currently I just hit Google and hope there's something useful there,
>>> but it's really not a good way to go about it.
>>> I wondered if there is a web site which collates all the available
>>> libraries, preferably with their versions, changelogs and maybe
>>> integrated bug-tracking?
>>> (OK, so what I really want is the equivalent of
>>> http://search.cpan.org/ except for Scala instead of Perl)
>>>
>>> Is there anything like that out there?
>>> How do YOU find libraries for things you need? Or does everyone on
>>> Scala just reinvent the wheel every time they need to do something
>>> like parse CSV files or RSS feeds?
>

In terms of scala-tools.org and project hosting/description... Well I have plans, but none that are implemented.  

For a better searching experience, please try http://nexus.scala-tools.org.   This should be easier to search for projects, but is still lacking useful information you would find from things like freshmeat.


- Josh

On Mon, Apr 19, 2010 at 3:14 AM, Toby Corkindale <toby@dryft.net> wrote:

Hi Daniel,
Thanks for the responses - I've had a quick look at them, comments below.
I hope I don't come across as annoying in the responses to each; I'm
just trying to give some criticism from the point-of-view of someone
who is trying to pick up Scala, and coming from a much older language.

On 19 April 2010 12:45, Daniel Sobral <dcsobral@gmail.com> wrote:
> http://implicit.ly

This looks like an interesting blog for keeping up to date with new
releases as they are developed, but isn't very useful as a repository
of available libraries - unless I'm missing something?

> http://www.scala-tools.org/

There might be good things here, but how do I find them?
Browsing the Maven repository just gives me useless top-level package
fragments like "eu", "hoffrocket", "org".

It would be much better, IMHO, to have a list of libraries by what
they do - eg. top level directories should be "file processing",
"networking", "multimedia", "math", etc.
I mean, I know what "Lift" is, due to seeing it linked from the
Scala-lang site; but I wouldn't know that just from the name. Whereas
if it was located in a category like "Web frameworks" I'd know
straight away.

> http://github.com/languages/Scala

Again, not very helpful for people who don't already know the name of
the project.
I see that "posterous", "pinky" and "scopt" are popular today, but I
have no idea what they do, and it doesn't help if I'm looking for
something to, say, process Apache log files, or transcode video on the
fly to a REST client.

I tried using the Search box, but in the Languages selection box there
is no option for Scala, and searching for "scala csv" turns up loads
of individual source files, rather than appropriate libraries.


So, is it just that everyone in the Scala world tends to like building
their own wheels or is Scala mainly used for projects that are
unlikely to have any commonly-reused parts after all, apart from the
stuff included in the core Scala library?

Or is it more than people tend to use Java libraries for much of the
underlying work, just glueing them together with Scala?

Cheers,
Toby


> On Sun, Apr 18, 2010 at 11:15 PM, Toby Corkindale <toby@dryft.net> wrote:
>>
>> Hi,
>> I wondered if people could tell me where they go to look for Scala
>> libraries?
>> Currently I just hit Google and hope there's something useful there,
>> but it's really not a good way to go about it.
>> I wondered if there is a web site which collates all the available
>> libraries, preferably with their versions, changelogs and maybe
>> integrated bug-tracking?
>> (OK, so what I really want is the equivalent of
>> http://search.cpan.org/ except for Scala instead of Perl)
>>
>> Is there anything like that out there?
>> How do YOU find libraries for things you need? Or does everyone on
>> Scala just reinvent the wheel every time they need to do something
>> like parse CSV files or RSS feeds?

On 19 April 2010 17:32, Jason Zaugg wrote:
> At ScalaDays, a few people requested an easily discoverable catalog of
> libraries, citing RubyGems as an example.

.. and its predecessors, Perl's CPAN and Python's Cheese Shop.

> A small catalog already exists on the scala-lang website:
>
>  http://www.scala-lang.org/node/1209
>
> Naturally, some if the information is a dated, perhaps library authors
> could take this opportunity to review the content and suggest updates?
>
> Toby: In your opinion, how could this page be easier to discover, and
> how could the content be better structured?

1) Fix the URL so it indexes better; eg.
http://libraries.scala-lang.org/ or
http://scala-lang.org/contributed-libraries.
2) Link to it from the front page Quick Links.

3) Set up a hierachy of categories, and then categorise or tag
packages into the appropriate places.
For example, see http://pypi.python.org/pypi?:action=browse
(And, see how you can drill down into several categories, platforms, like:
http://pypi.python.org/pypi?:action=browse&c=5&c=319&c=501
)
Perl's CPAN works in a similar way, for instance, drilling into "Data
and Data Types", then selecting "Dates" gets you:
http://search.cpan.org/modlist/Data_and_Data_Types/Date

4) Allow package authors to be able to enter their own libraries into
the system, with links to where they can be downloaded, and preferably
with information that allows a developer to evaluate whether the
package is reasonably stable and actively maintained.
eg. Ask the maintainer to include links to the library's bug tracker,
a list of releases, and the change logs.

5) While Scala is still in this transitive state, where people often
use Java libraries, I suggest that you should include placeholders in
various categories, pointing to the recommended Java libraries to use.
(I gather that the ease of integration with Java libraries varies a
bit, so some would be more appropriate than others.)

Cheers,
Toby

On 19 Apr 2010, at 09:05, Toby Corkindale wrote:
On 19 April 2010 17:32, Jason Zaugg wrote:
>> At ScalaDays, a few people requested an easily discoverable catalog of
>> libraries, citing RubyGems as an example.
>
> .. and its predecessors, Perl's CPAN and Python's Cheese Shop.

Is this not the role that sbaz is intended to fill? Or am I misunderstanding? Perhaps I am, as sbaz doesn't seem to know about the vast majority of Scala libraries that exist?

I have to say that, as another newcomer to Scala, this is one of my major concerns too - my most recent previous project was in Ruby, and it was incredibly easy to find libraries to reuse. And, just as important, to contribute libraries. This is an area where the Scala community is (severely) lagging behind.

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: paul@paulbutcher.com
AIM: paulrabutcher
Skype: paulrabutcher

I don't think rubygems is the reason for the proliferation and ease of
finding Ruby libraries. I think it's much more simple: there are a
lot of them, they get used a lot, and publicized a lot. A github
search of a topic and "ruby" usually turns up something.

For Scala, there is not all that much.

Certainly, rubygems is about a million times easier to deal with than
maven repos, and that may be part of the reason (it's trivial to put
your gem up on rubygems.org; not so with the official maven repo, as I
understand).

The fact is, any project using Scala is likely going to be using Maven
or SBT (or buildr, even), and those use the maven repository structure
for finding dependencies.

What I think would eliminate some barriers:

- canonical scala maven repo (like rubygems) that ANYONE can post to
without email or waiting periods, e.g. sbt publish and in seconds your
library is available to the world
- use github always and not (e.g.) google code - github is designed to
foster collaboration and patch management; this will make
contributions, even by one-time contributors much simpler

If you don't know about how rubygems.org works,
http://rubygems.org/pages/gem_docs is a fast read and could easily be
applied to Scala libraries, conceptually

Dave

---
My Blog: http://www.naildrivin5.com/blog
Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
Fork me on Github: http://davetron5000.github.com

On Mon, Apr 19, 2010 at 4:28 AM, Paul Butcher wrote:
> On 19 Apr 2010, at 09:05, Toby Corkindale wrote:
> On 19 April 2010 17:32, Jason Zaugg wrote:
>>> At ScalaDays, a few people requested an easily discoverable catalog of
>>> libraries, citing RubyGems as an example.
>>
>> .. and its predecessors, Perl's CPAN and Python's Cheese Shop.
>
> Is this not the role that sbaz is intended to fill? Or am I misunderstanding? Perhaps I am, as sbaz doesn't seem to know about the vast majority of Scala libraries that exist?
>
> I have to say that, as another newcomer to Scala, this is one of my major concerns too - my most recent previous project was in Ruby, and it was incredibly easy to find libraries to reuse. And, just as important, to contribute libraries. This is an area where the Scala community is (severely) lagging behind.
>
> --
> paul.butcher->msgCount++
>
> Snetterton, Castle Combe, Cadwell Park...
> Who says I have a one track mind?
>
> http://www.paulbutcher.com/
> LinkedIn: http://www.linkedin.com/in/paulbutcher
> MSN: paul@paulbutcher.com
> AIM: paulrabutcher
> Skype: paulrabutcher
>
>

I was thinking it would be really nice to have a maven and/or ivy
mechanism to refer to things to github in the same way we now refers to
things in a maven repository.

So, referring to a github URL and an optional revision, have it manage a
locally-built version of the same, and "just work" in the same way that
maven (usually) just works. I suppose really it could just be
git-specific, not tied to github.

Anybody see any obvious problems with this approach? Sound good? I'm
liking this so much, in fact, since I spend way too much time pulling
things down from github and sticking them in nexus that I'd like to Just
Do It.

cheers,
Eric

Josh Suereth wrote:
> In terms of scala-tools.org and project
> hosting/description... Well I have plans, but none that are
> implemented.
>
> For a better searching experience, please try
> http://nexus.scala-tools.org. This should be easier to search for
> projects, but is still lacking useful information you would find from
> things like freshmeat.
>
>
> - Josh
>
> On Mon, Apr 19, 2010 at 3:14 AM, Toby Corkindale > wrote:
>
> Hi Daniel,
> Thanks for the responses - I've had a quick look at them, comments
> below.
> I hope I don't come across as annoying in the responses to each; I'm
> just trying to give some criticism from the point-of-view of someone
> who is trying to pick up Scala, and coming from a much older language.
>
> On 19 April 2010 12:45, Daniel Sobral > wrote:
> > http://implicit.ly
>
> This looks like an interesting blog for keeping up to date with new
> releases as they are developed, but isn't very useful as a repository
> of available libraries - unless I'm missing something?
>
> > http://www.scala-tools.org/
>
> There might be good things here, but how do I find them?
> Browsing the Maven repository just gives me useless top-level package
> fragments like "eu", "hoffrocket", "org".
>
> It would be much better, IMHO, to have a list of libraries by what
> they do - eg. top level directories should be "file processing",
> "networking", "multimedia", "math", etc.
> I mean, I know what "Lift" is, due to seeing it linked from the
> Scala-lang site; but I wouldn't know that just from the name. Whereas
> if it was located in a category like "Web frameworks" I'd know
> straight away.
>
> > http://github.com/languages/Scala
>
> Again, not very helpful for people who don't already know the name of
> the project.
> I see that "posterous", "pinky" and "scopt" are popular today, but I
> have no idea what they do, and it doesn't help if I'm looking for
> something to, say, process Apache log files, or transcode video on the
> fly to a REST client.
>
> I tried using the Search box, but in the Languages selection box there
> is no option for Scala, and searching for "scala csv" turns up loads
> of individual source files, rather than appropriate libraries.
>
>
> So, is it just that everyone in the Scala world tends to like building
> their own wheels or is Scala mainly used for projects that are
> unlikely to have any commonly-reused parts after all, apart from the
> stuff included in the core Scala library?
>
> Or is it more than people tend to use Java libraries for much of the
> underlying work, just glueing them together with Scala?
>
> Cheers,
> Toby
>
>
> > On Sun, Apr 18, 2010 at 11:15 PM, Toby Corkindale
> > wrote:
> >>
> >> Hi,
> >> I wondered if people could tell me where they go to look for Scala
> >> libraries?
> >> Currently I just hit Google and hope there's something useful
> there,
> >> but it's really not a good way to go about it.
> >> I wondered if there is a web site which collates all the available
> >> libraries, preferably with their versions, changelogs and maybe
> >> integrated bug-tracking?
> >> (OK, so what I really want is the equivalent of
> >> http://search.cpan.org/ except for Scala instead of Perl)
> >>
> >> Is there anything like that out there?
> >> How do YOU find libraries for things you need? Or does everyone on
> >> Scala just reinvent the wheel every time they need to do something
> >> like parse CSV files or RSS feeds?
>
>

> - use github always and not (e.g.) google code - github is designed to
> foster collaboration and patch management; this will make
> contributions, even by one-time contributors much simpler

I would find that extremely limiting. There are many reasons to not like
git and probably just as many to not like github. It's great that there are
many project hosting alternatives around. That choice shouldn't be
artificially limited, imho.

Oh, I agree that would be useful. I think some kind of aggregator
site that tracks scala projects and their individual websites may work
out better. Even now folks are moving from github to assembla, or
perhaps they like hg better....

The point is, it's better to provide something that doesn't care who
hosts the documentation. Scala-tools currently stores a lot of binary
artifacts. Any ideas on how to share more information on those
projects is greatly appreciated. Also remember that all the resources
behind scala-tools.org are completely donated, so contributions
(ideas, servers, code, etc) are welcome.

- Josh

On Apr 19, 2010, at 11:15 AM, Eric Bowman wrote:

> I was thinking it would be really nice to have a maven and/or ivy
> mechanism to refer to things to github in the same way we now refers
> to things in a maven repository.
>
> So, referring to a github URL and an optional revision, have it
> manage a locally-built version of the same, and "just work" in the
> same way that maven (usually) just works. I suppose really it could
> just be git-specific, not tied to github.
>
> Anybody see any obvious problems with this approach? Sound good?
> I'm liking this so much, in fact, since I spend way too much time
> pulling things down from github and sticking them in nexus that I'd
> like to Just Do It.
>
> cheers,
> Eric
>
> Josh Suereth wrote:
>> In terms of scala-tools.org and project
>> hosting/description... Well I have plans, but none that are
>> implemented.
>> For a better searching experience, please try http://nexus.scala-tools.org
>> . This should be easier to search for projects, but is still
>> lacking useful information you would find from things like freshmeat.
>>
>>
>> - Josh
>>
>> On Mon, Apr 19, 2010 at 3:14 AM, Toby Corkindale > >> wrote:
>>
>> Hi Daniel,
>> Thanks for the responses - I've had a quick look at them, comments
>> below.
>> I hope I don't come across as annoying in the responses to each;
>> I'm
>> just trying to give some criticism from the point-of-view of
>> someone
>> who is trying to pick up Scala, and coming from a much older
>> language.
>>
>> On 19 April 2010 12:45, Daniel Sobral > > wrote:
>> > http://implicit.ly
>>
>> This looks like an interesting blog for keeping up to date with
>> new
>> releases as they are developed, but isn't very useful as a
>> repository
>> of available libraries - unless I'm missing something?
>>
>> > http://www.scala-tools.org/
>>
>> There might be good things here, but how do I find them?
>> Browsing the Maven repository just gives me useless top-level
>> package
>> fragments like "eu", "hoffrocket", "org".
>>
>> It would be much better, IMHO, to have a list of libraries by what
>> they do - eg. top level directories should be "file processing",
>> "networking", "multimedia", "math", etc.
>> I mean, I know what "Lift" is, due to seeing it linked from the
>> Scala-lang site; but I wouldn't know that just from the name.
>> Whereas
>> if it was located in a category like "Web frameworks" I'd know
>> straight away.
>>
>> > http://github.com/languages/Scala
>>
>> Again, not very helpful for people who don't already know the
>> name of
>> the project.
>> I see that "posterous", "pinky" and "scopt" are popular today,
>> but I
>> have no idea what they do, and it doesn't help if I'm looking for
>> something to, say, process Apache log files, or transcode video
>> on the
>> fly to a REST client.
>>
>> I tried using the Search box, but in the Languages selection box
>> there
>> is no option for Scala, and searching for "scala csv" turns up
>> loads
>> of individual source files, rather than appropriate libraries.
>>
>>
>> So, is it just that everyone in the Scala world tends to like
>> building
>> their own wheels or is Scala mainly used for projects that are
>> unlikely to have any commonly-reused parts after all, apart from
>> the
>> stuff included in the core Scala library?
>>
>> Or is it more than people tend to use Java libraries for much of
>> the
>> underlying work, just glueing them together with Scala?
>>
>> Cheers,
>> Toby
>>
>>
>> > On Sun, Apr 18, 2010 at 11:15 PM, Toby Corkindale
>> > wrote:
>> >>
>> >> Hi,
>> >> I wondered if people could tell me where they go to look for
>> Scala
>> >> libraries?
>> >> Currently I just hit Google and hope there's something useful
>> there,
>> >> but it's really not a good way to go about it.
>> >> I wondered if there is a web site which collates all the
>> available
>> >> libraries, preferably with their versions, changelogs and maybe
>> >> integrated bug-tracking?
>> >> (OK, so what I really want is the equivalent of
>> >> http://search.cpan.org/ except for Scala instead of Perl)
>> >>
>> >> Is there anything like that out there?
>> >> How do YOU find libraries for things you need? Or does
>> everyone on
>> >> Scala just reinvent the wheel every time they need to do
>> something
>> >> like parse CSV files or RSS feeds?
>>
>>
>

There is a reason scala-tools.org requires an email for access -
licensing. Folks need to determine an appropriate open source
license before we host code. Not enforcing this can get the hosting
party in trouble with users...

- Josh

On Apr 19, 2010, at 10:46 AM, David Copeland
wrote:

> I don't think rubygems is the reason for the proliferation and ease of
> finding Ruby libraries. I think it's much more simple: there are a
> lot of them, they get used a lot, and publicized a lot. A github
> search of a topic and "ruby" usually turns up something.
>
> For Scala, there is not all that much.
>
> Certainly, rubygems is about a million times easier to deal with than
> maven repos, and that may be part of the reason (it's trivial to put
> your gem up on rubygems.org; not so with the official maven repo, as I
> understand).
>
> The fact is, any project using Scala is likely going to be using Maven
> or SBT (or buildr, even), and those use the maven repository structure
> for finding dependencies.
>
> What I think would eliminate some barriers:
>
> - canonical scala maven repo (like rubygems) that ANYONE can post to
> without email or waiting periods, e.g. sbt publish and in seconds your
> library is available to the world
> - use github always and not (e.g.) google code - github is designed to
> foster collaboration and patch management; this will make
> contributions, even by one-time contributors much simpler
>
> If you don't know about how rubygems.org works,
> http://rubygems.org/pages/gem_docs is a fast read and could easily be
> applied to Scala libraries, conceptually
>
> Dave
>
> ---
> My Blog: http://www.naildrivin5.com/blog
> Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
> Fork me on Github: http://davetron5000.github.com
>
>
>
>
> On Mon, Apr 19, 2010 at 4:28 AM, Paul Butcher
> wrote:
>> On 19 Apr 2010, at 09:05, Toby Corkindale wrote:
>> On 19 April 2010 17:32, Jason Zaugg wrote:
>>>> At ScalaDays, a few people requested an easily discoverable
>>>> catalog of
>>>> libraries, citing RubyGems as an example.
>>>
>>> .. and its predecessors, Perl's CPAN and Python's Cheese Shop.
>>
>> Is this not the role that sbaz is intended to fill? Or am I
>> misunderstanding? Perhaps I am, as sbaz doesn't seem to know about
>> the vast majority of Scala libraries that exist?
>>
>> I have to say that, as another newcomer to Scala, this is one of my
>> major concerns too - my most recent previous project was in Ruby,
>> and it was incredibly easy to find libraries to reuse. And, just as
>> important, to contribute libraries. This is an area where the Scala
>> community is (severely) lagging behind.
>>
>> --
>> paul.butcher->msgCount++
>>
>> Snetterton, Castle Combe, Cadwell Park...
>> Who says I have a one track mind?
>>
>> http://www.paulbutcher.com/
>> LinkedIn: http://www.linkedin.com/in/paulbutcher
>> MSN: paul@paulbutcher.com
>> AIM: paulrabutcher
>> Skype: paulrabutcher
>>
>>

Since some time, central repository (and oss repository hosted by sonatype) require deploying artifact to provide information (via pom) : license, developpers, scm url, site url and also require files to be signed gpg. And Sonatype works to clean repository like java.net where every body were allowed to publish anything anywhere.
I agree its more work for lib creator but it provide a cleaner repository for end user.

/davidB

On Mon, Apr 19, 2010 at 11:28, Josh Suereth <joshua.suereth@gmail.com> wrote:

There is a reason scala-tools.org requires an email for access - licensing.   Folks need to determine an appropriate open source license before we host code. Not enforcing this can get the hosting party in trouble with users...

- Josh

On Apr 19, 2010, at 10:46 AM, David Copeland <davec@naildrivin5.com> wrote:

I don't think rubygems is the reason for the proliferation and ease of
finding Ruby libraries.  I think it's much more simple: there are a
lot of them, they get used a lot, and publicized a lot.  A github
search of a topic and "ruby" usually turns up something.

For Scala, there is not all that much.

Certainly, rubygems is about a million times easier to deal with than
maven repos, and that may be part of the reason (it's trivial to put
your gem up on rubygems.org; not so with the official maven repo, as I
understand).

The fact is, any project using Scala is likely going to be using Maven
or SBT (or buildr, even), and those use the maven repository structure
for finding dependencies.

What I think would eliminate some barriers:

- canonical scala maven repo (like rubygems) that ANYONE can post to
without email or waiting periods, e.g. sbt publish and in seconds your
library is available to the world
- use github always and not (e.g.) google code - github is designed to
foster collaboration and patch management; this will make
contributions, even by one-time contributors much simpler

If you don't know about how rubygems.org works,
http://rubygems.org/pages/gem_docs is a fast read and could easily be
applied to Scala libraries, conceptually

Dave

---
My Blog: http://www.naildrivin5.com/blog
Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
Fork me on Github: http://davetron5000.github.com




On Mon, Apr 19, 2010 at 4:28 AM, Paul Butcher <paul@paulbutcher.com> wrote:

On 19 Apr 2010, at 09:05, Toby Corkindale wrote:
On 19 April 2010 17:32, Jason Zaugg <jzaugg@gmail.com> wrote:

At ScalaDays, a few people requested an easily discoverable catalog of
libraries, citing RubyGems as an example.

.. and its predecessors, Perl's CPAN and Python's Cheese Shop.

Is this not the role that sbaz is intended to fill? Or am I misunderstanding? Perhaps I am, as sbaz doesn't seem to know about the vast majority of Scala libraries that exist?

I have to say that, as another newcomer to Scala, this is one of my major concerns too - my most recent previous project was in Ruby, and it was incredibly easy to find libraries to reuse. And, just as important, to contribute libraries. This is an area where the Scala community is (severely) lagging behind.

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: paul@paulbutcher.com
AIM: paulrabutcher
Skype: paulrabutcher

On Mon, 2010-04-19 at 11:15 +0200, Eric Bowman wrote:
> I was thinking it would be really nice to have a maven and/or ivy
> mechanism to refer to things to github in the same way we now refers to
> things in a maven repository.
>
> So, referring to a github URL and an optional revision, have it manage a
> locally-built version of the same, and "just work" in the same way that
> maven (usually) just works. I suppose really it could just be
> git-specific, not tied to github.
>
> Anybody see any obvious problems with this approach? Sound good? I'm
> liking this so much, in fact, since I spend way too much time pulling
> things down from github and sticking them in nexus that I'd like to Just
> Do It.

Why only Git and GitHub, Why not also Bazaar and Launchpad, Mercurial
and BitBucket, or any combination, even SourceForge! (NB GoogleCode now
supports Mercurial and so has entered the post-Subversion age.)

Git may have the marketing hype, and indeed the zeitgeist, but it is far
from having a monopoly - -and long may that remain so. Scala must not
tie itself to one and only one DVCS.

Russel Winder wrote:
> On Mon, 2010-04-19 at 11:15 +0200, Eric Bowman wrote:
>
>> I was thinking it would be really nice to have a maven and/or ivy
>> mechanism to refer to things to github in the same way we now refers to
>> things in a maven repository.
>>
>> So, referring to a github URL and an optional revision, have it manage a
>> locally-built version of the same, and "just work" in the same way that
>> maven (usually) just works. I suppose really it could just be
>> git-specific, not tied to github.
>>
>> Anybody see any obvious problems with this approach? Sound good? I'm
>> liking this so much, in fact, since I spend way too much time pulling
>> things down from github and sticking them in nexus that I'd like to Just
>> Do It.
>>
>
> Why only Git and GitHub, Why not also Bazaar and Launchpad, Mercurial
> and BitBucket, or any combination, even SourceForge! (NB GoogleCode now
> supports Mercurial and so has entered the post-Subversion age.)
>
> Git may have the marketing hype, and indeed the zeitgeist, but it is far
> from having a monopoly - -and long may that remain so. Scala must not
> tie itself to one and only one DVCS.
>
>

Yeah, would be v1 for me since that's where most of the stuff I'm
interested in, is. Obviously it would need to be easily extensible to
work with basically any code repository.

One of the obstacles to using the maven repository approach (which we
are seeing now with scala, IMO) is that it's not totally straightforward
to get replicated across the world of public maven repos.

So it would be pretty handy to be able to refer to code somewhere in a
pom or whatever, and have the build system just do the right thing.

I'm going to try to carve some time to look at this; I think this would
be insanely useful.

cheers,
Eric

This is what I use:

http://www.scala-lang.org/docu/files/api/index.html

Russ P.

I absolutely agree with you that Sbaz was intended to fill this role, and I still hope to make this the case.  However, for this to happen, I believe Sbaz needs to grow far beyond the client side installer (where most of the development work has been spent) and the simplistic server API.  The next point of focus for Sbaz needs to be developing a social style Universe management platform with the goal of cultivating a community focused on building quality collections of related libraries. I envision people using sbaz in a way similar to github, only for packages instead of code.  Through the use of Multiverse (a composite universe configuration) these could easily be layered both on the server side (a specialized personal Universe references EPFL's Scala distribution universe) or on the client side.
Generally, users would have common universes, such as the base Scala distribution, and maybe a "standard extended library" universe containing highly trusted third party packages.  More specialized universes could make installing entire development environments as easy as executing two command lines.  Sbaz does not require working in the SCALA_HOME, so it is feasible to have many specialized working directories for different purposes.
Note that the Universe is basically a directory, so no actual code is hosted there.  Additional work will be needed to support Maven, Ivy and other URL accessible repositories of non-sbp packages.  I do not envision using Maven and Ivy repositories without additional configuration because of the fundamental difference in the way Sbaz selects transitive dependencies.
I've been meaning to start work on this vision for quite some time now, but for the past several months, work and life have interfered with my making any progress.  If anyone is interested in participating in this effort, I am more than happy to hear your thoughts.  Code contributors are welcome as well.  The client Sbaz code is owned and hosted by EPFL, so any contributions there will require the proper paperwork be filled out on their side.  The Sbaz server application can be implemented from scratch and contributed as a third party application.  It only makes sense that this should be implemented in Scala, and I'm inclined to embrace Lift.

On Mon, Apr 19, 2010 at 4:28 AM, Paul Butcher <paul@paulbutcher.com> wrote:

On 19 Apr 2010, at 09:05, Toby Corkindale wrote:
On 19 April 2010 17:32, Jason Zaugg <jzaugg@gmail.com> wrote:
>> At ScalaDays, a few people requested an easily discoverable catalog of
>> libraries, citing RubyGems as an example.
>
> .. and its predecessors, Perl's CPAN and Python's Cheese Shop.

Is this not the role that sbaz is intended to fill? Or am I misunderstanding? Perhaps I am, as sbaz doesn't seem to know about the vast majority of Scala libraries that exist?

I have to say that, as another newcomer to Scala, this is one of my major concerns too - my most recent previous project was in Ruby, and it was incredibly easy to find libraries to reuse. And, just as important, to contribute libraries. This is an area where the Scala community is (severely) lagging behind.

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: paul@paulbutcher.com
AIM: paulrabutcher
Skype: paulrabutcher

On Mon, Apr 19, 2010 at 09:35:57PM -0400, James Matlik wrote:
> The next point of focus for Sbaz needs to be developing a social style
> Universe management platform with the goal of cultivating a community
> focused on building quality collections of related libraries. I
> envision people using sbaz in a way similar to github, only for
> packages instead of code.

I hate to be mr. skeptical, but couldn't we first target something a bit
less ambitious which directly leverages existing infrastructure? My
sense is that you hugely underestimate the critical mass (in packaging
effort, ongoing maintenance, and actual users) it takes before a whole
new distribution mechanism has any chance of rising above the level of
"good idea". If that kind of effort was available for scala I feel sure
I would have heard about it.

I'm trying to avert the stomach pains I will have seeing any significant
quantity of scala-focused effort disappearing into hypotheticaland when
there are so many tangible things to work on (like the 609 and counting
open tickets in trac.) To clarify that: unrealistic goals are fine if
that's what you want to do. There is no such thing as wasted effort,
it's all educational for the doer. But if the goal here is something
which will come to fruition and solve real problems, then let's have
open eyes about it. How about sketching out a few of the goalposts
lying between here and there and tunnelling for the closest.

On 20 April 2010 13:13, Paul Phillips wrote:
> On Mon, Apr 19, 2010 at 09:35:57PM -0400, James Matlik wrote:
>> The next point of focus for Sbaz needs to be developing a social style
>> Universe management platform with the goal of cultivating a community
>> focused on building quality collections of related libraries. I
>> envision people using sbaz in a way similar to github, only for
>> packages instead of code.
>
> I hate to be mr. skeptical, but couldn't we first target something a bit
> less ambitious which directly leverages existing infrastructure? My
> sense is that you hugely underestimate the critical mass (in packaging
> effort, ongoing maintenance, and actual users) it takes before a whole
> new distribution mechanism has any chance of rising above the level of
> "good idea".  If that kind of effort was available for scala I feel sure
> I would have heard about it.
>
> I'm trying to avert the stomach pains I will have seeing any significant
> quantity of scala-focused effort disappearing into hypotheticaland when
> there are so many tangible things to work on (like the 609 and counting
> open tickets in trac.) To clarify that: unrealistic goals are fine if
> that's what you want to do.  There is no such thing as wasted effort,
> it's all educational for the doer.  But if the goal here is something
> which will come to fruition and solve real problems, then let's have
> open eyes about it.  How about sketching out a few of the goalposts
> lying between here and there and tunnelling for the closest.

I think the success of the Perl, Python and now Ruby repositories can
be attributed to the low barrier to entry.
Anyone can sign up, registration is automated and takes only a minute,
and the tools to create conforming packages, or to download and
install them, are included with the core distributions of the
languages.

You do end up with some low quality modules in there, of course, and
often many modules that compete to do the same task. However users can
rate modules, check documentation, leave and check bug reports, and
make their own decisions as to which is the best modules to use for
their needs.

However I believe it is better to have too many modules, than not enough.

-Toby

I certainly see your point, and have been thinking about this concern for a long time. Please elaborate on what you have in mind.
From what I've been considering, implementing a competator to existing solutions like Maven or Ivy (a la carte library versioning, filling in the blanks as needed) seems counter productive and pointless, plus something on the large scale similar to a Linux distribution would require far too much coordination to be feasible. However, I do see a benefit in making popular libraries readily available via the sbaz tool to reduce the bar for entry in addition to an application (not just library) delivery tool.  
Sbaz exists today, and there are a few public universes available to pull libraries from; however, these libraries are both limited and somewhat broken. This tends to introduce confusion to new users, and are generally deemed irrelevant by others. I would like to introduce the concept of ownership to Universes, in addition to individual packages, as a way of improving the quality of what is contained within them. 
I believe targeting a large singular universe, or attempting to include all universes for a single workspace, would be folly.  In addition to the before mentioned excessive coordination required for such an approach, many (most?) nontrivial Scala libraries/applications will depend on Java libraries.  Guaranteeing zero collisions between all these in a bazaar environment is nearly impossible.  This is why I propose using smaller parallel universes that can either define their dependencies in totality, or reference libraries in a handful of linked and reliable universes.  This way, universes can grow and die on their own, just as any other software project.  Some will be general purpose while others will be more special interest. After a foundation exists, it should be possible to introduce a merit based system of ranking universes for relevance.

The existing sbp format is good for deploying complex applications (e.g. Tomcat), but requiring this format is a limiting factor for pulling in existing artifacts like those deployed to Maven and ivy repositories.  Some additional work would be needed to support them.  It should also be possible to create a Universe that parses POM files and the like for the more special interest universes.  Such a solution wouldn't likely be a good fit for the commonly used general purpose universes, however.

On Mon, Apr 19, 2010 at 11:13 PM, Paul Phillips <paulp@improving.org> wrote:

On Mon, Apr 19, 2010 at 09:35:57PM -0400, James Matlik wrote:
> The next point of focus for Sbaz needs to be developing a social style
> Universe management platform with the goal of cultivating a community
> focused on building quality collections of related libraries. I
> envision people using sbaz in a way similar to github, only for
> packages instead of code.

I hate to be mr. skeptical, but couldn't we first target something a bit
less ambitious which directly leverages existing infrastructure? My
sense is that you hugely underestimate the critical mass (in packaging
effort, ongoing maintenance, and actual users) it takes before a whole
new distribution mechanism has any chance of rising above the level of
"good idea".  If that kind of effort was available for scala I feel sure
I would have heard about it.

I'm trying to avert the stomach pains I will have seeing any significant
quantity of scala-focused effort disappearing into hypotheticaland when
there are so many tangible things to work on (like the 609 and counting
open tickets in trac.) To clarify that: unrealistic goals are fine if
that's what you want to do.  There is no such thing as wasted effort,
it's all educational for the doer.  But if the goal here is something
which will come to fruition and solve real problems, then let's have
open eyes about it.  How about sketching out a few of the goalposts
lying between here and there and tunnelling for the closest.

--
Paul Phillips      | Before a man speaks it is always safe to assume
Protagonist        | that he is a fool.  After he speaks, it is seldom
Empiricist         | necessary to assume it.
pal, i pill push   |     -- H. L. Mencken

On Mon, 2010-04-19 at 20:13 -0700, Paul Phillips wrote:
[ . . . ]
> I hate to be mr. skeptical, but couldn't we first target something a bit
> less ambitious which directly leverages existing infrastructure? My
> sense is that you hugely underestimate the critical mass (in packaging
> effort, ongoing maintenance, and actual users) it takes before a whole
> new distribution mechanism has any chance of rising above the level of
> "good idea". If that kind of effort was available for scala I feel sure
> I would have heard about it.
>
> I'm trying to avert the stomach pains I will have seeing any significant
> quantity of scala-focused effort disappearing into hypotheticaland when
> there are so many tangible things to work on (like the 609 and counting
> open tickets in trac.) To clarify that: unrealistic goals are fine if
> that's what you want to do. There is no such thing as wasted effort,
> it's all educational for the doer. But if the goal here is something
> which will come to fruition and solve real problems, then let's have
> open eyes about it. How about sketching out a few of the goalposts
> lying between here and there and tunnelling for the closest.

I too start by being a bit sceptical. I see an element of history
repeating itself.

At the language level there is Perl/CPAN, Ruby/Gems, Haskell/Cabal, etc.
These tend to create workable systems that are monocultures. They also
turn into complete self-standing dependency management systems and build
systems.

At the operating system level we have (Fedora|RHEL|CentOS|SUSE)/RPM,
(Debian|Ubuntu)/Deb which have complete self-standing dependency
management systems. Moreover due to the Debian policy, the Debian
system generally conflicts with any and all language specific systems.

I see two problems. Most JVM-based systems are now going to be
constructed using some combination of Java, Scala, Groovy, Clojure,
Jython and JRuby (possibly other languages), so any attempt to build a
Scala monoculture will lead to conflict. Secondly the whole
Maven/OSGi/Fedora/Debian situation will lead to conflict.

I don't have any hypothetical answer, just doubts and fears.

New is generally good, but new must provide an easy transition from old
or embrace old in order to get traction. Without this another ghetto
will be created leading to little progress.

Here are my 2cts to the debate.

I agree with everyone stating that it is futile to duplicate effort.
In the Java World and therefor I would include the Scala World too
maven repositories have established themselfs as the quasi standard
for distributing libraries on a per package level. If we could
standardize on this and provide a bridge mechanism for sbaz it would
be fairly powerfull and provide access to tons of useful code.
Since sbt already has a mechanism (through ivy) to access maven and
ivy repositories and it is written in Scala it might be feasable to
extend this and make it available through other mechanism besides sbt
itself. Sbt is under a BSD-License so it shouldn't be a problem to
extract code from it.

The second step to success would be to provide a repository which is
open to everyone if this is even possible considering legal
predicates. I myself must say as long as you have a valid domain and
you own the code it is fairly easy to get authorized for
scala-tools.org so I wouldn't object to limited access but an easy
sign up form would make it easy for people to see how to get their
libraries signed up cause the hardest part is to figure out who to
contact to gain access.

-Stefan

On Tuesday 20 April 2010, Stefan Langer wrote:
> Here are my 2cts to the debate.
>
> I agree with everyone stating that it is futile to duplicate effort.
> In the Java World and therefor I would include the Scala World too
> maven repositories have established themselfs as the quasi standard
> for distributing libraries on a per package level. If we could
> standardize on this and provide a bridge mechanism for sbaz it would
> be fairly powerfull and provide access to tons of useful code.
> Since sbt already has a mechanism (through ivy) to access maven and
> ivy repositories and it is written in Scala it might be feasable to
> extend this and make it available through other mechanism besides sbt
> itself. Sbt is under a BSD-License so it shouldn't be a problem to
> extract code from it.

You shouldn't need to copy the code. sbt's interface to Ivy is a separate module documented at:

http://code.google.com/p/simple-build-tool/wiki/IvyInterface

-Mark

Folks,

I am all in favor of figuring out ways to advertise Scala libraries to help people find Scala libraries and publish Scala libraries.  That's why I host Scala Tools and have been working with some very fine members of the Scala community (DavidB originally, Josh and Derek these days) to sustain and enhance Scala Tools.

There are two separate issues winding through this thread: advertising libraries and hosting libraries.

Let's deal with the latter first.  We have scala-tools.org for hosting.  Over the last year, it's been a reliable (at least on the download side ;-) ) place for hosting Scala-related JARs.  It can be accessed by all the major Scala-related build tools (Ant, Maven, sbt, buildr, etc.)  Anybody with an open source project that has a defined open source license and a reasonable contribution policy can publish their projects at Scala tools.  If you've got a project you'd like to host, the instructions are on the front page of http://scala-tools.org or you can send email to admin [at] scala-tools.org.  Yes, there's a manual step... but anyone who is likely to maintain their app is also likely to spend the 15 minutes sending us email.  There is no popular technical solution to JAR distribution and dependencies that's superior to Maven... that's why Ivy, etc. have grown up to use it.

Scala tools hosts 148 separate projects containing 1,608 releases (that does not include snapshots).  That's a non-trivial collection of projects.  I do not see any argument that we need yet another repository or distribution mechanism (although DavidB points to a potential change to the hosting policies that would allow more projects to be published on Scala-tools.org).

Advertising is the more challenging issue.  Back in 2004-2006, I was involved with the Ruby community.  RubyForge, based on the SourceForge open source code, was used to host most Ruby projects.  This was the main advertising and aggregation space for open source Ruby projects.  At the time I was part of the community, RubyForge was hosted on a machine in some guy's basement and communicated over DSL... and that gives you the circa 2005 idea of how much traffic the site actually had.

However, these days, GitHub is the place where all the cool kids do their Ruby work (and Scala work).

I think that the the new entrant to the Scala world will find the most popular Scala libraries at http://github.com/languages/Scala  They'd also find a lot of Java libraries that do what they need and unlike Ruby's wrapping of native libraries, it's less common in Scala-land to publish and support Scala-wrapped Java libraries because (with some notable exceptions like Databinder Dispatch) the Scala wrapping doesn't really change the flavor of the library.  Speaking of N8han,  there's also http://implicit.ly/ Implicit.ly is particularly important because it's going to help raise search rankings for Scala projects.

I'm all for a non-technical, non-replacement-for-Maven-repositories solution to address the advertising Scala projects issue.  If there's a reasonable or better solution, I'll be happy to put hosting and bandwidth resources behind a solution as a way to continue to support growth in the Scala community.

Thanks,

David

On Mon, Apr 19, 2010 at 8:13 PM, Paul Phillips <paulp@improving.org> wrote:

On Mon, Apr 19, 2010 at 09:35:57PM -0400, James Matlik wrote:
> The next point of focus for Sbaz needs to be developing a social style
> Universe management platform with the goal of cultivating a community
> focused on building quality collections of related libraries. I
> envision people using sbaz in a way similar to github, only for
> packages instead of code.

I hate to be mr. skeptical, but couldn't we first target something a bit
less ambitious which directly leverages existing infrastructure? My
sense is that you hugely underestimate the critical mass (in packaging
effort, ongoing maintenance, and actual users) it takes before a whole
new distribution mechanism has any chance of rising above the level of
"good idea".  If that kind of effort was available for scala I feel sure
I would have heard about it.

I'm trying to avert the stomach pains I will have seeing any significant
quantity of scala-focused effort disappearing into hypotheticaland when
there are so many tangible things to work on (like the 609 and counting
open tickets in trac.) To clarify that: unrealistic goals are fine if
that's what you want to do.  There is no such thing as wasted effort,
it's all educational for the doer.  But if the goal here is something
which will come to fruition and solve real problems, then let's have
open eyes about it.  How about sketching out a few of the goalposts
lying between here and there and tunnelling for the closest.

--
Paul Phillips      | Before a man speaks it is always safe to assume
Protagonist        | that he is a fool.  After he speaks, it is seldom
Empiricist         | necessary to assume it.
pal, i pill push   |     -- H. L. Mencken

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

Paul Phillips wrote:
> On Mon, Apr 19, 2010 at 09:35:57PM -0400, James Matlik wrote:
>> The next point of focus for Sbaz needs to be developing a social style
>> Universe management platform with the goal of cultivating a community
>> focused on building quality collections of related libraries. I
>> envision people using sbaz in a way similar to github, only for
>> packages instead of code.
>
> I hate to be mr. skeptical, but couldn't we first target something a bit
> less ambitious which directly leverages existing infrastructure? My
> sense is that you hugely underestimate the critical mass (in packaging
> effort, ongoing maintenance, and actual users) it takes before a whole
> new distribution mechanism has any chance of rising above the level of
> "good idea". If that kind of effort was available for scala I feel sure
> I would have heard about it.
>
> I'm trying to avert the stomach pains I will have seeing any significant
> quantity of scala-focused effort disappearing into hypotheticaland when
> there are so many tangible things to work on (like the 609 and counting
> open tickets in trac.) To clarify that: unrealistic goals are fine if
> that's what you want to do. There is no such thing as wasted effort,
> it's all educational for the doer. But if the goal here is something
> which will come to fruition and solve real problems, then let's have
> open eyes about it. How about sketching out a few of the goalposts
> lying between here and there and tunnelling for the closest.

I've used Python's Cheeseshop. Now that I'm developing mostly in Scala, and
building with SBT, I have a few related thoughts.

One of SBT's strengths is that it allows me to publish to a Maven or Ivy repo
with a minimum of hassle. Usually, one or two lines of configuration in my SBT
build class is sufficient to enable publishing. This simplicity is a major
win. The downside, of course, is getting access to a place to publish. To make
life easier on myself, I simply created my own Maven repo. (I'm not the only
one who's done that, judging from what I see elsewhere in the Scala community.)

This is one huge area where PyPI excels. Publishing to the Cheeseshop is simple:

- Create an account via the web site.
- Add some boilerplate to your setup.py.
- Run "python setup.py register" when you're ready to publish.

That's it. Once you've published, your new package shows up at the top of the
roster on the web site, and it's available for all to see and to download.

Using the Cheeseshop is also simple, since various tools (e.g., EasyInstall)
automatically look there.

I'd like to see something that simple to use for the Scala packages I develop.
For instance, a set of web-based administration screens for a Maven repo would
be sufficient, I think. Go to an SBaz web site, register an account, create a
namespace for yourself, and you can publish to the SBaz repository.

I'm not sure why it has to be any more complicated than that. Ease of use and
ease of publishing will go a long, long way toward enabling a vibrant bazaar
of Scala packages.

Actually, I think Scala Tools is a pretty good example of present frustration. You say it hosts 148 projects. Well, ok, how do I get a list of their _names_, let alone a one-liner description? If there's a way to do that, it is not obvious from the starting page.
I agree that Maven repo's are the way to go, and that storing them on Scala Tools is reasonable enough, and that having people e-mail to ask for an account is ok (though I had never noticed that was what was written in the starting page -- I assumed it was just the "contact the administrator about any problems" standard thingy).
But for a repository to be useful as anything more than a repository, it must be both searchable and browsable (by humans). Each package must have name, description and tags, and it must be inserted into a human-built hierarchy.

On Tue, Apr 20, 2010 at 10:23 AM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

Folks,

I am all in favor of figuring out ways to advertise Scala libraries to help people find Scala libraries and publish Scala libraries.  That's why I host Scala Tools and have been working with some very fine members of the Scala community (DavidB originally, Josh and Derek these days) to sustain and enhance Scala Tools.

There are two separate issues winding through this thread: advertising libraries and hosting libraries.

Let's deal with the latter first.  We have scala-tools.org for hosting.  Over the last year, it's been a reliable (at least on the download side ;-) ) place for hosting Scala-related JARs.  It can be accessed by all the major Scala-related build tools (Ant, Maven, sbt, buildr, etc.)  Anybody with an open source project that has a defined open source license and a reasonable contribution policy can publish their projects at Scala tools.  If you've got a project you'd like to host, the instructions are on the front page of http://scala-tools.org or you can send email to admin [at] scala-tools.org.  Yes, there's a manual step... but anyone who is likely to maintain their app is also likely to spend the 15 minutes sending us email.  There is no popular technical solution to JAR distribution and dependencies that's superior to Maven... that's why Ivy, etc. have grown up to use it.

Scala tools hosts 148 separate projects containing 1,608 releases (that does not include snapshots).  That's a non-trivial collection of projects.  I do not see any argument that we need yet another repository or distribution mechanism (although DavidB points to a potential change to the hosting policies that would allow more projects to be published on Scala-tools.org).

Advertising is the more challenging issue.  Back in 2004-2006, I was involved with the Ruby community.  RubyForge, based on the SourceForge open source code, was used to host most Ruby projects.  This was the main advertising and aggregation space for open source Ruby projects.  At the time I was part of the community, RubyForge was hosted on a machine in some guy's basement and communicated over DSL... and that gives you the circa 2005 idea of how much traffic the site actually had.

However, these days, GitHub is the place where all the cool kids do their Ruby work (and Scala work).

I think that the the new entrant to the Scala world will find the most popular Scala libraries at http://github.com/languages/Scala  They'd also find a lot of Java libraries that do what they need and unlike Ruby's wrapping of native libraries, it's less common in Scala-land to publish and support Scala-wrapped Java libraries because (with some notable exceptions like Databinder Dispatch) the Scala wrapping doesn't really change the flavor of the library.  Speaking of N8han,  there's also http://implicit.ly/ Implicit.ly is particularly important because it's going to help raise search rankings for Scala projects.

I'm all for a non-technical, non-replacement-for-Maven-repositories solution to address the advertising Scala projects issue.  If there's a reasonable or better solution, I'll be happy to put hosting and bandwidth resources behind a solution as a way to continue to support growth in the Scala community.

Thanks,

David

On Mon, Apr 19, 2010 at 8:13 PM, Paul Phillips <paulp@improving.org> wrote:

On Mon, Apr 19, 2010 at 09:35:57PM -0400, James Matlik wrote:
> The next point of focus for Sbaz needs to be developing a social style
> Universe management platform with the goal of cultivating a community
> focused on building quality collections of related libraries. I
> envision people using sbaz in a way similar to github, only for
> packages instead of code.

I hate to be mr. skeptical, but couldn't we first target something a bit
less ambitious which directly leverages existing infrastructure? My
sense is that you hugely underestimate the critical mass (in packaging
effort, ongoing maintenance, and actual users) it takes before a whole
new distribution mechanism has any chance of rising above the level of
"good idea".  If that kind of effort was available for scala I feel sure
I would have heard about it.

I'm trying to avert the stomach pains I will have seeing any significant
quantity of scala-focused effort disappearing into hypotheticaland when
there are so many tangible things to work on (like the 609 and counting
open tickets in trac.) To clarify that: unrealistic goals are fine if
that's what you want to do.  There is no such thing as wasted effort,
it's all educational for the doer.  But if the goal here is something
which will come to fruition and solve real problems, then let's have
open eyes about it.  How about sketching out a few of the goalposts
lying between here and there and tunnelling for the closest.

--
Paul Phillips      | Before a man speaks it is always safe to assume
Protagonist        | that he is a fool.  After he speaks, it is seldom
Empiricist         | necessary to assume it.
pal, i pill push   |     -- H. L. Mencken

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
Daniel C. Sobral

I travel to the future all the time.

Getting away from the tooling aspect for now... (Maven is a clear winner in the binary-repository space at the moment, especially considering Java interop)

all we really need is a way for project creators to state (and publish): - This is the name of my project- This is the repository/groupId/artifactId- This is a brief description- This is a list of tags that I think is relevant
So long as that lot can be put in one common location, I really don't see it being a problem to add a bit of tooling around that to support indexing, and then searching via website (initially) or ide/sbt/twitterbot/etc (at some point in the future)
And yes, all of that can be done with Maven (probably even the tags) and publishing of the information then automated following a successful publish to scala-tools



On 20 April 2010 17:12, Daniel Sobral <dcsobral@gmail.com> wrote:

Actually, I think Scala Tools is a pretty good example of present frustration. You say it hosts 148 projects. Well, ok, how do I get a list of their _names_, let alone a one-liner description? If there's a way to do that, it is not obvious from the starting page.
I agree that Maven repo's are the way to go, and that storing them on Scala Tools is reasonable enough, and that having people e-mail to ask for an account is ok (though I had never noticed that was what was written in the starting page -- I assumed it was just the "contact the administrator about any problems" standard thingy).
But for a repository to be useful as anything more than a repository, it must be both searchable and browsable (by humans). Each package must have name, description and tags, and it must be inserted into a human-built hierarchy.

On Tue, Apr 20, 2010 at 10:23 AM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

Folks,

I am all in favor of figuring out ways to advertise Scala libraries to help people find Scala libraries and publish Scala libraries.  That's why I host Scala Tools and have been working with some very fine members of the Scala community (DavidB originally, Josh and Derek these days) to sustain and enhance Scala Tools.

There are two separate issues winding through this thread: advertising libraries and hosting libraries.

Let's deal with the latter first.  We have scala-tools.org for hosting.  Over the last year, it's been a reliable (at least on the download side ;-) ) place for hosting Scala-related JARs.  It can be accessed by all the major Scala-related build tools (Ant, Maven, sbt, buildr, etc.)  Anybody with an open source project that has a defined open source license and a reasonable contribution policy can publish their projects at Scala tools.  If you've got a project you'd like to host, the instructions are on the front page of http://scala-tools.org or you can send email to admin [at] scala-tools.org.  Yes, there's a manual step... but anyone who is likely to maintain their app is also likely to spend the 15 minutes sending us email.  There is no popular technical solution to JAR distribution and dependencies that's superior to Maven... that's why Ivy, etc. have grown up to use it.

Scala tools hosts 148 separate projects containing 1,608 releases (that does not include snapshots).  That's a non-trivial collection of projects.  I do not see any argument that we need yet another repository or distribution mechanism (although DavidB points to a potential change to the hosting policies that would allow more projects to be published on Scala-tools.org).

Advertising is the more challenging issue.  Back in 2004-2006, I was involved with the Ruby community.  RubyForge, based on the SourceForge open source code, was used to host most Ruby projects.  This was the main advertising and aggregation space for open source Ruby projects.  At the time I was part of the community, RubyForge was hosted on a machine in some guy's basement and communicated over DSL... and that gives you the circa 2005 idea of how much traffic the site actually had.

However, these days, GitHub is the place where all the cool kids do their Ruby work (and Scala work).

I think that the the new entrant to the Scala world will find the most popular Scala libraries at http://github.com/languages/Scala  They'd also find a lot of Java libraries that do what they need and unlike Ruby's wrapping of native libraries, it's less common in Scala-land to publish and support Scala-wrapped Java libraries because (with some notable exceptions like Databinder Dispatch) the Scala wrapping doesn't really change the flavor of the library.  Speaking of N8han,  there's also http://implicit.ly/ Implicit.ly is particularly important because it's going to help raise search rankings for Scala projects.

I'm all for a non-technical, non-replacement-for-Maven-repositories solution to address the advertising Scala projects issue.  If there's a reasonable or better solution, I'll be happy to put hosting and bandwidth resources behind a solution as a way to continue to support growth in the Scala community.

Thanks,

David

On Mon, Apr 19, 2010 at 8:13 PM, Paul Phillips <paulp@improving.org> wrote:

On Mon, Apr 19, 2010 at 09:35:57PM -0400, James Matlik wrote:
> The next point of focus for Sbaz needs to be developing a social style
> Universe management platform with the goal of cultivating a community
> focused on building quality collections of related libraries. I
> envision people using sbaz in a way similar to github, only for
> packages instead of code.

I hate to be mr. skeptical, but couldn't we first target something a bit
less ambitious which directly leverages existing infrastructure? My
sense is that you hugely underestimate the critical mass (in packaging
effort, ongoing maintenance, and actual users) it takes before a whole
new distribution mechanism has any chance of rising above the level of
"good idea".  If that kind of effort was available for scala I feel sure
I would have heard about it.

I'm trying to avert the stomach pains I will have seeing any significant
quantity of scala-focused effort disappearing into hypotheticaland when
there are so many tangible things to work on (like the 609 and counting
open tickets in trac.) To clarify that: unrealistic goals are fine if
that's what you want to do.  There is no such thing as wasted effort,
it's all educational for the doer.  But if the goal here is something
which will come to fruition and solve real problems, then let's have
open eyes about it.  How about sketching out a few of the goalposts
lying between here and there and tunnelling for the closest.

--
Paul Phillips      | Before a man speaks it is always safe to assume
Protagonist        | that he is a fool.  After he speaks, it is seldom
Empiricist         | necessary to assume it.
pal, i pill push   |     -- H. L. Mencken

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
Daniel C. Sobral

I travel to the future all the time.

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

  I'm not a maven specialist, but are there tags (custom or not) in
the POM file in which we could but textile or markdown content ?
If we could standardized on a set of tags (category, name etc...) , we would just need a tool to
scan maven repos and publish the information in a structure defined by the tags.
I'm sure SBT could even shield us from manually editing the POMs...

 Regards

On Tue, Apr 20, 2010 at 12:12 PM, Daniel Sobral <dcsobral@gmail.com> wrote:

Actually, I think Scala Tools is a pretty good example of present frustration. You say it hosts 148 projects. Well, ok, how do I get a list of their _names_, let alone a one-liner description? If there's a way to do that, it is not obvious from the starting page.
I agree that Maven repo's are the way to go, and that storing them on Scala Tools is reasonable enough, and that having people e-mail to ask for an account is ok (though I had never noticed that was what was written in the starting page -- I assumed it was just the "contact the administrator about any problems" standard thingy).
But for a repository to be useful as anything more than a repository, it must be both searchable and browsable (by humans). Each package must have name, description and tags, and it must be inserted into a human-built hierarchy.

On Tue, Apr 20, 2010 at 10:23 AM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

Folks,

I am all in favor of figuring out ways to advertise Scala libraries to help people find Scala libraries and publish Scala libraries.  That's why I host Scala Tools and have been working with some very fine members of the Scala community (DavidB originally, Josh and Derek these days) to sustain and enhance Scala Tools.

There are two separate issues winding through this thread: advertising libraries and hosting libraries.

Let's deal with the latter first.  We have scala-tools.org for hosting.  Over the last year, it's been a reliable (at least on the download side ;-) ) place for hosting Scala-related JARs.  It can be accessed by all the major Scala-related build tools (Ant, Maven, sbt, buildr, etc.)  Anybody with an open source project that has a defined open source license and a reasonable contribution policy can publish their projects at Scala tools.  If you've got a project you'd like to host, the instructions are on the front page of http://scala-tools.org or you can send email to admin [at] scala-tools.org.  Yes, there's a manual step... but anyone who is likely to maintain their app is also likely to spend the 15 minutes sending us email.  There is no popular technical solution to JAR distribution and dependencies that's superior to Maven... that's why Ivy, etc. have grown up to use it.

Scala tools hosts 148 separate projects containing 1,608 releases (that does not include snapshots).  That's a non-trivial collection of projects.  I do not see any argument that we need yet another repository or distribution mechanism (although DavidB points to a potential change to the hosting policies that would allow more projects to be published on Scala-tools.org).

Advertising is the more challenging issue.  Back in 2004-2006, I was involved with the Ruby community.  RubyForge, based on the SourceForge open source code, was used to host most Ruby projects.  This was the main advertising and aggregation space for open source Ruby projects.  At the time I was part of the community, RubyForge was hosted on a machine in some guy's basement and communicated over DSL... and that gives you the circa 2005 idea of how much traffic the site actually had.

However, these days, GitHub is the place where all the cool kids do their Ruby work (and Scala work).

I think that the the new entrant to the Scala world will find the most popular Scala libraries at http://github.com/languages/Scala  They'd also find a lot of Java libraries that do what they need and unlike Ruby's wrapping of native libraries, it's less common in Scala-land to publish and support Scala-wrapped Java libraries because (with some notable exceptions like Databinder Dispatch) the Scala wrapping doesn't really change the flavor of the library.  Speaking of N8han,  there's also http://implicit.ly/ Implicit.ly is particularly important because it's going to help raise search rankings for Scala projects.

I'm all for a non-technical, non-replacement-for-Maven-repositories solution to address the advertising Scala projects issue.  If there's a reasonable or better solution, I'll be happy to put hosting and bandwidth resources behind a solution as a way to continue to support growth in the Scala community.

Thanks,

David

On Mon, Apr 19, 2010 at 8:13 PM, Paul Phillips <paulp@improving.org> wrote:

On Mon, Apr 19, 2010 at 09:35:57PM -0400, James Matlik wrote:
> The next point of focus for Sbaz needs to be developing a social style
> Universe management platform with the goal of cultivating a community
> focused on building quality collections of related libraries. I
> envision people using sbaz in a way similar to github, only for
> packages instead of code.

I hate to be mr. skeptical, but couldn't we first target something a bit
less ambitious which directly leverages existing infrastructure? My
sense is that you hugely underestimate the critical mass (in packaging
effort, ongoing maintenance, and actual users) it takes before a whole
new distribution mechanism has any chance of rising above the level of
"good idea".  If that kind of effort was available for scala I feel sure
I would have heard about it.

I'm trying to avert the stomach pains I will have seeing any significant
quantity of scala-focused effort disappearing into hypotheticaland when
there are so many tangible things to work on (like the 609 and counting
open tickets in trac.) To clarify that: unrealistic goals are fine if
that's what you want to do.  There is no such thing as wasted effort,
it's all educational for the doer.  But if the goal here is something
which will come to fruition and solve real problems, then let's have
open eyes about it.  How about sketching out a few of the goalposts
lying between here and there and tunnelling for the closest.

--
Paul Phillips      | Before a man speaks it is always safe to assume
Protagonist        | that he is a fool.  After he speaks, it is seldom
Empiricist         | necessary to assume it.
pal, i pill push   |     -- H. L. Mencken

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
Daniel C. Sobral

I travel to the future all the time.

There isn't a top level element for it but you could dump your tags in a custom property like so:<project>  ...
  <properties>    <project.tags>foo bar</project.tags>   </properties>  ...</project>You could write a plugin to consume the tags and publish them somewhere if you like.  Or you could configure the tags as part of a plugin.  There is precedent for both though the second one is more common.
--Nik
2010/4/20 Maxime Lévesque <maxime.levesque@gmail.com>

  I'm not a maven specialist, but are there tags (custom or not) in
the POM file in which we could but textile or markdown content ?
If we could standardized on a set of tags (category, name etc...) , we would just need a tool to
scan maven repos and publish the information in a structure defined by the tags.
I'm sure SBT could even shield us from manually editing the POMs...

 Regards

On Tue, Apr 20, 2010 at 12:12 PM, Daniel Sobral <dcsobral@gmail.com> wrote:

Actually, I think Scala Tools is a pretty good example of present frustration. You say it hosts 148 projects. Well, ok, how do I get a list of their _names_, let alone a one-liner description? If there's a way to do that, it is not obvious from the starting page.
I agree that Maven repo's are the way to go, and that storing them on Scala Tools is reasonable enough, and that having people e-mail to ask for an account is ok (though I had never noticed that was what was written in the starting page -- I assumed it was just the "contact the administrator about any problems" standard thingy).
But for a repository to be useful as anything more than a repository, it must be both searchable and browsable (by humans). Each package must have name, description and tags, and it must be inserted into a human-built hierarchy.

On Tue, Apr 20, 2010 at 10:23 AM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

Folks,

I am all in favor of figuring out ways to advertise Scala libraries to help people find Scala libraries and publish Scala libraries.  That's why I host Scala Tools and have been working with some very fine members of the Scala community (DavidB originally, Josh and Derek these days) to sustain and enhance Scala Tools.

There are two separate issues winding through this thread: advertising libraries and hosting libraries.

Let's deal with the latter first.  We have scala-tools.org for hosting.  Over the last year, it's been a reliable (at least on the download side ;-) ) place for hosting Scala-related JARs.  It can be accessed by all the major Scala-related build tools (Ant, Maven, sbt, buildr, etc.)  Anybody with an open source project that has a defined open source license and a reasonable contribution policy can publish their projects at Scala tools.  If you've got a project you'd like to host, the instructions are on the front page of http://scala-tools.org or you can send email to admin [at] scala-tools.org.  Yes, there's a manual step... but anyone who is likely to maintain their app is also likely to spend the 15 minutes sending us email.  There is no popular technical solution to JAR distribution and dependencies that's superior to Maven... that's why Ivy, etc. have grown up to use it.

Scala tools hosts 148 separate projects containing 1,608 releases (that does not include snapshots).  That's a non-trivial collection of projects.  I do not see any argument that we need yet another repository or distribution mechanism (although DavidB points to a potential change to the hosting policies that would allow more projects to be published on Scala-tools.org).

Advertising is the more challenging issue.  Back in 2004-2006, I was involved with the Ruby community.  RubyForge, based on the SourceForge open source code, was used to host most Ruby projects.  This was the main advertising and aggregation space for open source Ruby projects.  At the time I was part of the community, RubyForge was hosted on a machine in some guy's basement and communicated over DSL... and that gives you the circa 2005 idea of how much traffic the site actually had.

However, these days, GitHub is the place where all the cool kids do their Ruby work (and Scala work).

I think that the the new entrant to the Scala world will find the most popular Scala libraries at http://github.com/languages/Scala  They'd also find a lot of Java libraries that do what they need and unlike Ruby's wrapping of native libraries, it's less common in Scala-land to publish and support Scala-wrapped Java libraries because (with some notable exceptions like Databinder Dispatch) the Scala wrapping doesn't really change the flavor of the library.  Speaking of N8han,  there's also http://implicit.ly/ Implicit.ly is particularly important because it's going to help raise search rankings for Scala projects.

I'm all for a non-technical, non-replacement-for-Maven-repositories solution to address the advertising Scala projects issue.  If there's a reasonable or better solution, I'll be happy to put hosting and bandwidth resources behind a solution as a way to continue to support growth in the Scala community.

Thanks,

David

On Mon, Apr 19, 2010 at 8:13 PM, Paul Phillips <paulp@improving.org> wrote:

On Mon, Apr 19, 2010 at 09:35:57PM -0400, James Matlik wrote:
> The next point of focus for Sbaz needs to be developing a social style
> Universe management platform with the goal of cultivating a community
> focused on building quality collections of related libraries. I
> envision people using sbaz in a way similar to github, only for
> packages instead of code.

I hate to be mr. skeptical, but couldn't we first target something a bit
less ambitious which directly leverages existing infrastructure? My
sense is that you hugely underestimate the critical mass (in packaging
effort, ongoing maintenance, and actual users) it takes before a whole
new distribution mechanism has any chance of rising above the level of
"good idea".  If that kind of effort was available for scala I feel sure
I would have heard about it.

I'm trying to avert the stomach pains I will have seeing any significant
quantity of scala-focused effort disappearing into hypotheticaland when
there are so many tangible things to work on (like the 609 and counting
open tickets in trac.) To clarify that: unrealistic goals are fine if
that's what you want to do.  There is no such thing as wasted effort,
it's all educational for the doer.  But if the goal here is something
which will come to fruition and solve real problems, then let's have
open eyes about it.  How about sketching out a few of the goalposts
lying between here and there and tunnelling for the closest.

--
Paul Phillips      | Before a man speaks it is always safe to assume
Protagonist        | that he is a fool.  After he speaks, it is seldom
Empiricist         | necessary to assume it.
pal, i pill push   |     -- H. L. Mencken

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
Daniel C. Sobral

I travel to the future all the time.

I agree: I looked at the github page, but for a casual user it is very
hard to get any useful information there (assuming that he finds that
page at all). Not to mention that it is never clear when are you on a
scala-specific page or left that domain.

Even relatively obscure programming languages like Haskell or OCaml
have much clearer sites for finding ongoing projects

cf:
http://hackage.haskell.org/packages/archive/pkg-list.html
http://caml.inria.fr/cgi-bin/hump.cgi

But I think scala has the "java disease", because there seems to be no
decent site for finding out about java libraries and projects,
either...

On 4/20/10, Daniel Sobral wrote:
> Actually, I think Scala Tools is a pretty good example of present
> frustration. You say it hosts 148 projects. Well, ok, how do I get a list of
> their _names_, let alone a one-liner description? If there's a way to do
> that, it is not obvious from the starting page.
>
> I agree that Maven repo's are the way to go, and that storing them on Scala
> Tools is reasonable enough, and that having people e-mail to ask for an
> account is ok (though I had never noticed that was what was written in the
> starting page -- I assumed it was just the "contact the administrator about
> any problems" standard thingy).
>
> But for a repository to be useful as anything more than a repository, it
> must be both searchable and browsable (by humans). Each package must have
> name, description and tags, and it must be inserted into a human-built
> hierarchy.
>
>
> On Tue, Apr 20, 2010 at 10:23 AM, David Pollak
> wrote:
> > Folks,
> >
> > I am all in favor of figuring out ways to advertise Scala libraries to
> help people find Scala libraries and publish Scala libraries. That's why I
> host Scala Tools and have been working with some very fine members of the
> Scala community (DavidB originally, Josh and Derek these days) to sustain
> and enhance Scala Tools.
> >
> > There are two separate issues winding through this thread: advertising
> libraries and hosting libraries.
> >
> > Let's deal with the latter first. We have scala-tools.org for hosting.
> Over the last year, it's been a reliable (at least on the download side ;-)
> ) place for hosting Scala-related JARs. It can be accessed by all the major
> Scala-related build tools (Ant, Maven, sbt, buildr, etc.) Anybody with an
> open source project that has a defined open source license and a reasonable
> contribution policy can publish their projects at Scala tools. If you've
> got a project you'd like to host, the instructions are on the front page of
> http://scala-tools.org or you can send email to admin [at] scala-tools.org.
> Yes, there's a manual step... but anyone who is likely to maintain their app
> is also likely to spend the 15 minutes sending us email. There is no
> popular technical solution to JAR distribution and dependencies that's
> superior to Maven... that's why Ivy, etc. have grown up to use it.
> >
> > Scala tools hosts 148 separate projects containing 1,608 releases (that
> does not include snapshots). That's a non-trivial collection of projects.
> I do not see any argument that we need yet another repository or
> distribution mechanism (although DavidB points to a potential change to the
> hosting policies that would allow more projects to be published on
> Scala-tools.org).
> >
> > Advertising is the more challenging issue. Back in 2004-2006, I was
> involved with the Ruby community. RubyForge, based on the SourceForge open
> source code, was used to host most Ruby projects. This was the main
> advertising and aggregation space for open source Ruby projects. At the
> time I was part of the community, RubyForge was hosted on a machine in some
> guy's basement and communicated over DSL... and that gives you the circa
> 2005 idea of how much traffic the site actually had.
> >
> > However, these days, GitHub is the place where all the cool kids do their
> Ruby work (and Scala work).
> >
> > I think that the the new entrant to the Scala world will find the most
> popular Scala libraries at
> http://github.com/languages/Scala They'd also find a lot
> of Java libraries that do what they need and unlike Ruby's wrapping of
> native libraries, it's less common in Scala-land to publish and support
> Scala-wrapped Java libraries because (with some notable exceptions like
> Databinder Dispatch) the Scala wrapping doesn't really change the flavor of
> the library. Speaking of N8han, there's also http://implicit.ly/
> Implicit.ly is particularly important because it's going to help raise
> search rankings for Scala projects.
> >
> > I'm all for a non-technical,
> non-replacement-for-Maven-repositories solution to address
> the advertising Scala projects issue. If there's a reasonable or better
> solution, I'll be happy to put hosting and bandwidth resources behind a
> solution as a way to continue to support growth in the Scala community.
> >
> > Thanks,
> >
> > David
> >
> >
> >
> >
> >
> > On Mon, Apr 19, 2010 at 8:13 PM, Paul Phillips
> wrote:
> >
> > >
> > >
> > > On Mon, Apr 19, 2010 at 09:35:57PM -0400, James Matlik wrote:
> > > > The next point of focus for Sbaz needs to be developing a social style
> > > > Universe management platform with the goal of cultivating a community
> > > > focused on building quality collections of related libraries. I
> > > > envision people using sbaz in a way similar to github, only for
> > > > packages instead of code.
> > >
> > > I hate to be mr. skeptical, but couldn't we first target something a bit
> > > less ambitious which directly leverages existing infrastructure? My
> > > sense is that you hugely underestimate the critical mass (in packaging
> > > effort, ongoing maintenance, and actual users) it takes before a whole
> > > new distribution mechanism has any chance of rising above the level of
> > > "good idea". If that kind of effort was available for scala I feel sure
> > > I would have heard about it.
> > >
> > > I'm trying to avert the stomach pains I will have seeing any significant
> > > quantity of scala-focused effort disappearing into hypotheticaland when
> > > there are so many tangible things to work on (like the 609 and counting
> > > open tickets in trac.) To clarify that: unrealistic goals are fine if
> > > that's what you want to do. There is no such thing as wasted effort,
> > > it's all educational for the doer. But if the goal here is something
> > > which will come to fruition and solve real problems, then let's have
> > > open eyes about it. How about sketching out a few of the goalposts
> > > lying between here and there and tunnelling for the closest.
> > >
> > > --
> > > Paul Phillips | Before a man speaks it is always safe to assume
> > > Protagonist | that he is a fool. After he speaks, it is seldom
> > > Empiricist | necessary to assume it.
> > > pal, i pill push | -- H. L. Mencken
> > >
> >
> >
> >
> > --
> > Lift, the simply functional web framework http://liftweb.net
> > Beginning Scala
> http://www.apress.com/book/view/1430219890
> > Follow me: http://twitter.com/dpp
> > Surf the harmonics
> >
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

Folks,

So, suggestion #1 -- create a nicer landing page for Scala-tools.org based on the contents of the pom files.  That's doable.

What else can we do to make it easier to find the existing code?  A wiki?  If so, who maintains it?  Who makes sure it's spam-free?  What else?

Thanks,

David

On Tue, Apr 20, 2010 at 10:55 AM, Christian Szegedy <christian.szegedy@gmail.com> wrote:

I agree: I looked at the github page, but for a casual user it is very
hard to get any useful information there (assuming that he finds that
page at all). Not to mention that it is never clear when are you on a
scala-specific page or left that domain.

Even relatively obscure programming languages like Haskell or OCaml
have much clearer sites for finding ongoing projects

cf:
http://hackage.haskell.org/packages/archive/pkg-list.html
http://caml.inria.fr/cgi-bin/hump.cgi

But I think scala has the "java disease", because there seems to be no
decent site for finding out about java libraries and projects,
either...

On 4/20/10, Daniel Sobral <dcsobral@gmail.com> wrote:
> Actually, I think Scala Tools is a pretty good example of present
> frustration. You say it hosts 148 projects. Well, ok, how do I get a list of
> their _names_, let alone a one-liner description? If there's a way to do
> that, it is not obvious from the starting page.
>
> I agree that Maven repo's are the way to go, and that storing them on Scala
> Tools is reasonable enough, and that having people e-mail to ask for an
> account is ok (though I had never noticed that was what was written in the
> starting page -- I assumed it was just the "contact the administrator about
> any problems" standard thingy).
>
> But for a repository to be useful as anything more than a repository, it
> must be both searchable and browsable (by humans). Each package must have
> name, description and tags, and it must be inserted into a human-built
> hierarchy.
>
>
> On Tue, Apr 20, 2010 at 10:23 AM, David Pollak
> <feeder.of.the.bears@gmail.com> wrote:
> > Folks,
> >
> > I am all in favor of figuring out ways to advertise Scala libraries to
> help people find Scala libraries and publish Scala libraries.  That's why I
> host Scala Tools and have been working with some very fine members of the
> Scala community (DavidB originally, Josh and Derek these days) to sustain
> and enhance Scala Tools.
> >
> > There are two separate issues winding through this thread: advertising
> libraries and hosting libraries.
> >
> > Let's deal with the latter first.  We have scala-tools.org for hosting.
> Over the last year, it's been a reliable (at least on the download side ;-)
> ) place for hosting Scala-related JARs.  It can be accessed by all the major
> Scala-related build tools (Ant, Maven, sbt, buildr, etc.)  Anybody with an
> open source project that has a defined open source license and a reasonable
> contribution policy can publish their projects at Scala tools.  If you've
> got a project you'd like to host, the instructions are on the front page of
> http://scala-tools.org or you can send email to admin [at] scala-tools.org.
> Yes, there's a manual step... but anyone who is likely to maintain their app
> is also likely to spend the 15 minutes sending us email.  There is no
> popular technical solution to JAR distribution and dependencies that's
> superior to Maven... that's why Ivy, etc. have grown up to use it.
> >
> > Scala tools hosts 148 separate projects containing 1,608 releases (that
> does not include snapshots).  That's a non-trivial collection of projects.
> I do not see any argument that we need yet another repository or
> distribution mechanism (although DavidB points to a potential change to the
> hosting policies that would allow more projects to be published on
> Scala-tools.org).
> >
> > Advertising is the more challenging issue.  Back in 2004-2006, I was
> involved with the Ruby community.  RubyForge, based on the SourceForge open
> source code, was used to host most Ruby projects.  This was the main
> advertising and aggregation space for open source Ruby projects.  At the
> time I was part of the community, RubyForge was hosted on a machine in some
> guy's basement and communicated over DSL... and that gives you the circa
> 2005 idea of how much traffic the site actually had.
> >
> > However, these days, GitHub is the place where all the cool kids do their
> Ruby work (and Scala work).
> >
> > I think that the the new entrant to the Scala world will find the most
> popular Scala libraries at
> http://github.com/languages/Scala  They'd also find a lot
> of Java libraries that do what they need and unlike Ruby's wrapping of
> native libraries, it's less common in Scala-land to publish and support
> Scala-wrapped Java libraries because (with some notable exceptions like
> Databinder Dispatch) the Scala wrapping doesn't really change the flavor of
> the library.  Speaking of N8han,  there's also http://implicit.ly/
> Implicit.ly is particularly important because it's going to help raise
> search rankings for Scala projects.
> >
> > I'm all for a non-technical,
> non-replacement-for-Maven-repositories solution to address
> the advertising Scala projects issue.  If there's a reasonable or better
> solution, I'll be happy to put hosting and bandwidth resources behind a
> solution as a way to continue to support growth in the Scala community.
> >
> > Thanks,
> >
> > David
> >
> >
> >
> >
> >
> > On Mon, Apr 19, 2010 at 8:13 PM, Paul Phillips <paulp@improving.org>
> wrote:
> >
> > >
> > >
> > > On Mon, Apr 19, 2010 at 09:35:57PM -0400, James Matlik wrote:
> > > > The next point of focus for Sbaz needs to be developing a social style
> > > > Universe management platform with the goal of cultivating a community
> > > > focused on building quality collections of related libraries. I
> > > > envision people using sbaz in a way similar to github, only for
> > > > packages instead of code.
> > >
> > > I hate to be mr. skeptical, but couldn't we first target something a bit
> > > less ambitious which directly leverages existing infrastructure? My
> > > sense is that you hugely underestimate the critical mass (in packaging
> > > effort, ongoing maintenance, and actual users) it takes before a whole
> > > new distribution mechanism has any chance of rising above the level of
> > > "good idea".  If that kind of effort was available for scala I feel sure
> > > I would have heard about it.
> > >
> > > I'm trying to avert the stomach pains I will have seeing any significant
> > > quantity of scala-focused effort disappearing into hypotheticaland when
> > > there are so many tangible things to work on (like the 609 and counting
> > > open tickets in trac.) To clarify that: unrealistic goals are fine if
> > > that's what you want to do.  There is no such thing as wasted effort,
> > > it's all educational for the doer.  But if the goal here is something
> > > which will come to fruition and solve real problems, then let's have
> > > open eyes about it.  How about sketching out a few of the goalposts
> > > lying between here and there and tunnelling for the closest.
> > >
> > > --
> > > Paul Phillips      | Before a man speaks it is always safe to assume
> > > Protagonist        | that he is a fool.  After he speaks, it is seldom
> > > Empiricist         | necessary to assume it.
> > > pal, i pill push   |     -- H. L. Mencken
> > >
> >
> >
> >
> > --
> > Lift, the simply functional web framework http://liftweb.net
> > Beginning Scala
> http://www.apress.com/book/view/1430219890
> > Follow me: http://twitter.com/dpp
> > Surf the harmonics
> >
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

RubyGems has a very simple and basic metadata format; far simpler than
maven's. Even with it's basic nature, rubygems can do some good
queries:

http://rubygems.org/search?query=markdown

Producing something similar for scala-tools (or any maven repo) seems
possible. On the main (slow as heck) maven site:

http://mvnrepository.com/search.html?query=markdown

works similarly. Granted, it's not as pretty, but serviceable
(interesting that the only hit for that search is a scala library :)

Is the software running on that site open source and could be stood up
on scala-tools?

Dave

---
My Blog: http://www.naildrivin5.com/blog
Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
Fork me on Github: http://davetron5000.github.com

On Tue, Apr 20, 2010 at 1:59 PM, David Pollak
wrote:
> Folks,
>
> So, suggestion #1 -- create a nicer landing page for Scala-tools.org based
> on the contents of the pom files.  That's doable.
>
> What else can we do to make it easier to find the existing code?  A wiki?
> If so, who maintains it?  Who makes sure it's spam-free?  What else?
>
> Thanks,
>
> David
>
> On Tue, Apr 20, 2010 at 10:55 AM, Christian Szegedy
> wrote:
>>
>> I agree: I looked at the github page, but for a casual user it is very
>> hard to get any useful information there (assuming that he finds that
>> page at all). Not to mention that it is never clear when are you on a
>> scala-specific page or left that domain.
>>
>> Even relatively obscure programming languages like Haskell or OCaml
>> have much clearer sites for finding ongoing projects
>>
>> cf:
>> http://hackage.haskell.org/packages/archive/pkg-list.html
>> http://caml.inria.fr/cgi-bin/hump.cgi
>>
>> But I think scala has the "java disease", because there seems to be no
>> decent site for finding out about java libraries and projects,
>> either...
>>
>> On 4/20/10, Daniel Sobral wrote:
>> > Actually, I think Scala Tools is a pretty good example of present
>> > frustration. You say it hosts 148 projects. Well, ok, how do I get a
>> > list of
>> > their _names_, let alone a one-liner description? If there's a way to do
>> > that, it is not obvious from the starting page.
>> >
>> > I agree that Maven repo's are the way to go, and that storing them on
>> > Scala
>> > Tools is reasonable enough, and that having people e-mail to ask for an
>> > account is ok (though I had never noticed that was what was written in
>> > the
>> > starting page -- I assumed it was just the "contact the administrator
>> > about
>> > any problems" standard thingy).
>> >
>> > But for a repository to be useful as anything more than a repository, it
>> > must be both searchable and browsable (by humans). Each package must
>> > have
>> > name, description and tags, and it must be inserted into a human-built
>> > hierarchy.
>> >
>> >
>> > On Tue, Apr 20, 2010 at 10:23 AM, David Pollak
>> > wrote:
>> > > Folks,
>> > >
>> > > I am all in favor of figuring out ways to advertise Scala libraries to
>> > help people find Scala libraries and publish Scala libraries.  That's
>> > why I
>> > host Scala Tools and have been working with some very fine members of
>> > the
>> > Scala community (DavidB originally, Josh and Derek these days) to
>> > sustain
>> > and enhance Scala Tools.
>> > >
>> > > There are two separate issues winding through this thread: advertising
>> > libraries and hosting libraries.
>> > >
>> > > Let's deal with the latter first.  We have scala-tools.org for
>> > > hosting.
>> > Over the last year, it's been a reliable (at least on the download side
>> > ;-)
>> > ) place for hosting Scala-related JARs.  It can be accessed by all the
>> > major
>> > Scala-related build tools (Ant, Maven, sbt, buildr, etc.)  Anybody with
>> > an
>> > open source project that has a defined open source license and a
>> > reasonable
>> > contribution policy can publish their projects at Scala tools.  If
>> > you've
>> > got a project you'd like to host, the instructions are on the front page
>> > of
>> > http://scala-tools.org or you can send email to admin [at]
>> > scala-tools.org.
>> > Yes, there's a manual step... but anyone who is likely to maintain their
>> > app
>> > is also likely to spend the 15 minutes sending us email.  There is no
>> > popular technical solution to JAR distribution and dependencies that's
>> > superior to Maven... that's why Ivy, etc. have grown up to use it.
>> > >
>> > > Scala tools hosts 148 separate projects containing 1,608 releases
>> > > (that
>> > does not include snapshots).  That's a non-trivial collection of
>> > projects.
>> > I do not see any argument that we need yet another repository or
>> > distribution mechanism (although DavidB points to a potential change to
>> > the
>> > hosting policies that would allow more projects to be published on
>> > Scala-tools.org).
>> > >
>> > > Advertising is the more challenging issue.  Back in 2004-2006, I was
>> > involved with the Ruby community.  RubyForge, based on the SourceForge
>> > open
>> > source code, was used to host most Ruby projects.  This was the main
>> > advertising and aggregation space for open source Ruby projects.  At the
>> > time I was part of the community, RubyForge was hosted on a machine in
>> > some
>> > guy's basement and communicated over DSL... and that gives you the circa
>> > 2005 idea of how much traffic the site actually had.
>> > >
>> > > However, these days, GitHub is the place where all the cool kids do
>> > > their
>> > Ruby work (and Scala work).
>> > >
>> > > I think that the the new entrant to the Scala world will find the most
>> > popular Scala libraries at
>> > http://github.com/languages/Scala  They'd also find a lot
>> > of Java libraries that do what they need and unlike Ruby's wrapping of
>> > native libraries, it's less common in Scala-land to publish and support
>> > Scala-wrapped Java libraries because (with some notable exceptions like
>> > Databinder Dispatch) the Scala wrapping doesn't really change the flavor
>> > of
>> > the library.  Speaking of N8han,  there's also http://implicit.ly/
>> > Implicit.ly is particularly important because it's going to help raise
>> > search rankings for Scala projects.
>> > >
>> > > I'm all for a non-technical,
>> > non-replacement-for-Maven-repositories solution to address
>> > the advertising Scala projects issue.  If there's a reasonable or better
>> > solution, I'll be happy to put hosting and bandwidth resources behind a
>> > solution as a way to continue to support growth in the Scala community.
>> > >
>> > > Thanks,
>> > >
>> > > David
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On Mon, Apr 19, 2010 at 8:13 PM, Paul Phillips
>> > wrote:
>> > >
>> > > >
>> > > >
>> > > > On Mon, Apr 19, 2010 at 09:35:57PM -0400, James Matlik wrote:
>> > > > > The next point of focus for Sbaz needs to be developing a social
>> > > > > style
>> > > > > Universe management platform with the goal of cultivating a
>> > > > > community
>> > > > > focused on building quality collections of related libraries. I
>> > > > > envision people using sbaz in a way similar to github, only for
>> > > > > packages instead of code.
>> > > >
>> > > > I hate to be mr. skeptical, but couldn't we first target something a
>> > > > bit
>> > > > less ambitious which directly leverages existing infrastructure? My
>> > > > sense is that you hugely underestimate the critical mass (in
>> > > > packaging
>> > > > effort, ongoing maintenance, and actual users) it takes before a
>> > > > whole
>> > > > new distribution mechanism has any chance of rising above the level
>> > > > of
>> > > > "good idea".  If that kind of effort was available for scala I feel
>> > > > sure
>> > > > I would have heard about it.
>> > > >
>> > > > I'm trying to avert the stomach pains I will have seeing any
>> > > > significant
>> > > > quantity of scala-focused effort disappearing into hypotheticaland
>> > > > when
>> > > > there are so many tangible things to work on (like the 609 and
>> > > > counting
>> > > > open tickets in trac.) To clarify that: unrealistic goals are fine
>> > > > if
>> > > > that's what you want to do.  There is no such thing as wasted
>> > > > effort,
>> > > > it's all educational for the doer.  But if the goal here is
>> > > > something
>> > > > which will come to fruition and solve real problems, then let's have
>> > > > open eyes about it.  How about sketching out a few of the goalposts
>> > > > lying between here and there and tunnelling for the closest.
>> > > >
>> > > > --
>> > > > Paul Phillips      | Before a man speaks it is always safe to assume
>> > > > Protagonist        | that he is a fool.  After he speaks, it is
>> > > > seldom
>> > > > Empiricist         | necessary to assume it.
>> > > > pal, i pill push   |     -- H. L. Mencken
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Lift, the simply functional web framework http://liftweb.net
>> > > Beginning Scala
>> > http://www.apress.com/book/view/1430219890
>> > > Follow me: http://twitter.com/dpp
>> > > Surf the harmonics
>> > >
>> >
>> >
>> >
>> > --
>> > Daniel C. Sobral
>> >
>> > I travel to the future all the time.
>> >
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>

I think #1 first and foremost.

On Tue, Apr 20, 2010 at 2:59 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

Folks,

So, suggestion #1 -- create a nicer landing page for Scala-tools.org based on the contents of the pom files.  That's doable.

What else can we do to make it easier to find the existing code?  A wiki?  If so, who maintains it?  Who makes sure it's spam-free?  What else?

Thanks,

David

On Tue, Apr 20, 2010 at 10:55 AM, Christian Szegedy <christian.szegedy@gmail.com> wrote:

I agree: I looked at the github page, but for a casual user it is very
hard to get any useful information there (assuming that he finds that
page at all). Not to mention that it is never clear when are you on a
scala-specific page or left that domain.

Even relatively obscure programming languages like Haskell or OCaml
have much clearer sites for finding ongoing projects

cf:
http://hackage.haskell.org/packages/archive/pkg-list.html
http://caml.inria.fr/cgi-bin/hump.cgi

But I think scala has the "java disease", because there seems to be no
decent site for finding out about java libraries and projects,
either...

On 4/20/10, Daniel Sobral <dcsobral@gmail.com> wrote:
> Actually, I think Scala Tools is a pretty good example of present
> frustration. You say it hosts 148 projects. Well, ok, how do I get a list of
> their _names_, let alone a one-liner description? If there's a way to do
> that, it is not obvious from the starting page.
>
> I agree that Maven repo's are the way to go, and that storing them on Scala
> Tools is reasonable enough, and that having people e-mail to ask for an
> account is ok (though I had never noticed that was what was written in the
> starting page -- I assumed it was just the "contact the administrator about
> any problems" standard thingy).
>
> But for a repository to be useful as anything more than a repository, it
> must be both searchable and browsable (by humans). Each package must have
> name, description and tags, and it must be inserted into a human-built
> hierarchy.
>
>
> On Tue, Apr 20, 2010 at 10:23 AM, David Pollak
> <feeder.of.the.bears@gmail.com> wrote:
> > Folks,
> >
> > I am all in favor of figuring out ways to advertise Scala libraries to
> help people find Scala libraries and publish Scala libraries.  That's why I
> host Scala Tools and have been working with some very fine members of the
> Scala community (DavidB originally, Josh and Derek these days) to sustain
> and enhance Scala Tools.
> >
> > There are two separate issues winding through this thread: advertising
> libraries and hosting libraries.
> >
> > Let's deal with the latter first.  We have scala-tools.org for hosting.
> Over the last year, it's been a reliable (at least on the download side ;-)
> ) place for hosting Scala-related JARs.  It can be accessed by all the major
> Scala-related build tools (Ant, Maven, sbt, buildr, etc.)  Anybody with an
> open source project that has a defined open source license and a reasonable
> contribution policy can publish their projects at Scala tools.  If you've
> got a project you'd like to host, the instructions are on the front page of
> http://scala-tools.org or you can send email to admin [at] scala-tools.org.
> Yes, there's a manual step... but anyone who is likely to maintain their app
> is also likely to spend the 15 minutes sending us email.  There is no
> popular technical solution to JAR distribution and dependencies that's
> superior to Maven... that's why Ivy, etc. have grown up to use it.
> >
> > Scala tools hosts 148 separate projects containing 1,608 releases (that
> does not include snapshots).  That's a non-trivial collection of projects.
> I do not see any argument that we need yet another repository or
> distribution mechanism (although DavidB points to a potential change to the
> hosting policies that would allow more projects to be published on
> Scala-tools.org).
> >
> > Advertising is the more challenging issue.  Back in 2004-2006, I was
> involved with the Ruby community.  RubyForge, based on the SourceForge open
> source code, was used to host most Ruby projects.  This was the main
> advertising and aggregation space for open source Ruby projects.  At the
> time I was part of the community, RubyForge was hosted on a machine in some
> guy's basement and communicated over DSL... and that gives you the circa
> 2005 idea of how much traffic the site actually had.
> >
> > However, these days, GitHub is the place where all the cool kids do their
> Ruby work (and Scala work).
> >
> > I think that the the new entrant to the Scala world will find the most
> popular Scala libraries at
> http://github.com/languages/Scala  They'd also find a lot
> of Java libraries that do what they need and unlike Ruby's wrapping of
> native libraries, it's less common in Scala-land to publish and support
> Scala-wrapped Java libraries because (with some notable exceptions like
> Databinder Dispatch) the Scala wrapping doesn't really change the flavor of
> the library.  Speaking of N8han,  there's also http://implicit.ly/
> Implicit.ly is particularly important because it's going to help raise
> search rankings for Scala projects.
> >
> > I'm all for a non-technical,
> non-replacement-for-Maven-repositories solution to address
> the advertising Scala projects issue.  If there's a reasonable or better
> solution, I'll be happy to put hosting and bandwidth resources behind a
> solution as a way to continue to support growth in the Scala community.
> >
> > Thanks,
> >
> > David
> >
> >
> >
> >
> >
> > On Mon, Apr 19, 2010 at 8:13 PM, Paul Phillips <paulp@improving.org>
> wrote:
> >
> > >
> > >
> > > On Mon, Apr 19, 2010 at 09:35:57PM -0400, James Matlik wrote:
> > > > The next point of focus for Sbaz needs to be developing a social style
> > > > Universe management platform with the goal of cultivating a community
> > > > focused on building quality collections of related libraries. I
> > > > envision people using sbaz in a way similar to github, only for
> > > > packages instead of code.
> > >
> > > I hate to be mr. skeptical, but couldn't we first target something a bit
> > > less ambitious which directly leverages existing infrastructure? My
> > > sense is that you hugely underestimate the critical mass (in packaging
> > > effort, ongoing maintenance, and actual users) it takes before a whole
> > > new distribution mechanism has any chance of rising above the level of
> > > "good idea".  If that kind of effort was available for scala I feel sure
> > > I would have heard about it.
> > >
> > > I'm trying to avert the stomach pains I will have seeing any significant
> > > quantity of scala-focused effort disappearing into hypotheticaland when
> > > there are so many tangible things to work on (like the 609 and counting
> > > open tickets in trac.) To clarify that: unrealistic goals are fine if
> > > that's what you want to do.  There is no such thing as wasted effort,
> > > it's all educational for the doer.  But if the goal here is something
> > > which will come to fruition and solve real problems, then let's have
> > > open eyes about it.  How about sketching out a few of the goalposts
> > > lying between here and there and tunnelling for the closest.
> > >
> > > --
> > > Paul Phillips      | Before a man speaks it is always safe to assume
> > > Protagonist        | that he is a fool.  After he speaks, it is seldom
> > > Empiricist         | necessary to assume it.
> > > pal, i pill push   |     -- H. L. Mencken
> > >
> >
> >
> >
> > --
> > Lift, the simply functional web framework http://liftweb.net
> > Beginning Scala
> http://www.apress.com/book/view/1430219890
> > Follow me: http://twitter.com/dpp
> > Surf the harmonics
> >
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
Daniel C. Sobral

I travel to the future all the time.

I guess this thread is getting a bit long and hard to search, but can someone clarify exactly which suggestion is being tagged as #1?


On 20 April 2010 19:29, Daniel Sobral <dcsobral@gmail.com> wrote:

I think #1 first and foremost.

On Tue, Apr 20, 2010 at 2:59 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

Folks,

So, suggestion #1 -- create a nicer landing page for Scala-tools.org based on the contents of the pom files.  That's doable.

What else can we do to make it easier to find the existing code?  A wiki?  If so, who maintains it?  Who makes sure it's spam-free?  What else?

Thanks,

David

On Tue, Apr 20, 2010 at 10:55 AM, Christian Szegedy <christian.szegedy@gmail.com> wrote:

I agree: I looked at the github page, but for a casual user it is very
hard to get any useful information there (assuming that he finds that
page at all). Not to mention that it is never clear when are you on a
scala-specific page or left that domain.

Even relatively obscure programming languages like Haskell or OCaml
have much clearer sites for finding ongoing projects

cf:
http://hackage.haskell.org/packages/archive/pkg-list.html
http://caml.inria.fr/cgi-bin/hump.cgi

But I think scala has the "java disease", because there seems to be no
decent site for finding out about java libraries and projects,
either...

On 4/20/10, Daniel Sobral <dcsobral@gmail.com> wrote:
> Actually, I think Scala Tools is a pretty good example of present
> frustration. You say it hosts 148 projects. Well, ok, how do I get a list of
> their _names_, let alone a one-liner description? If there's a way to do
> that, it is not obvious from the starting page.
>
> I agree that Maven repo's are the way to go, and that storing them on Scala
> Tools is reasonable enough, and that having people e-mail to ask for an
> account is ok (though I had never noticed that was what was written in the
> starting page -- I assumed it was just the "contact the administrator about
> any problems" standard thingy).
>
> But for a repository to be useful as anything more than a repository, it
> must be both searchable and browsable (by humans). Each package must have
> name, description and tags, and it must be inserted into a human-built
> hierarchy.
>
>
> On Tue, Apr 20, 2010 at 10:23 AM, David Pollak
> <feeder.of.the.bears@gmail.com> wrote:
> > Folks,
> >
> > I am all in favor of figuring out ways to advertise Scala libraries to
> help people find Scala libraries and publish Scala libraries.  That's why I
> host Scala Tools and have been working with some very fine members of the
> Scala community (DavidB originally, Josh and Derek these days) to sustain
> and enhance Scala Tools.
> >
> > There are two separate issues winding through this thread: advertising
> libraries and hosting libraries.
> >
> > Let's deal with the latter first.  We have scala-tools.org for hosting.
> Over the last year, it's been a reliable (at least on the download side ;-)
> ) place for hosting Scala-related JARs.  It can be accessed by all the major
> Scala-related build tools (Ant, Maven, sbt, buildr, etc.)  Anybody with an
> open source project that has a defined open source license and a reasonable
> contribution policy can publish their projects at Scala tools.  If you've
> got a project you'd like to host, the instructions are on the front page of
> http://scala-tools.org or you can send email to admin [at] scala-tools.org.
> Yes, there's a manual step... but anyone who is likely to maintain their app
> is also likely to spend the 15 minutes sending us email.  There is no
> popular technical solution to JAR distribution and dependencies that's
> superior to Maven... that's why Ivy, etc. have grown up to use it.
> >
> > Scala tools hosts 148 separate projects containing 1,608 releases (that
> does not include snapshots).  That's a non-trivial collection of projects.
> I do not see any argument that we need yet another repository or
> distribution mechanism (although DavidB points to a potential change to the
> hosting policies that would allow more projects to be published on
> Scala-tools.org).
> >
> > Advertising is the more challenging issue.  Back in 2004-2006, I was
> involved with the Ruby community.  RubyForge, based on the SourceForge open
> source code, was used to host most Ruby projects.  This was the main
> advertising and aggregation space for open source Ruby projects.  At the
> time I was part of the community, RubyForge was hosted on a machine in some
> guy's basement and communicated over DSL... and that gives you the circa
> 2005 idea of how much traffic the site actually had.
> >
> > However, these days, GitHub is the place where all the cool kids do their
> Ruby work (and Scala work).
> >
> > I think that the the new entrant to the Scala world will find the most
> popular Scala libraries at
> http://github.com/languages/Scala  They'd also find a lot
> of Java libraries that do what they need and unlike Ruby's wrapping of
> native libraries, it's less common in Scala-land to publish and support
> Scala-wrapped Java libraries because (with some notable exceptions like
> Databinder Dispatch) the Scala wrapping doesn't really change the flavor of
> the library.  Speaking of N8han,  there's also http://implicit.ly/
> Implicit.ly is particularly important because it's going to help raise
> search rankings for Scala projects.
> >
> > I'm all for a non-technical,
> non-replacement-for-Maven-repositories solution to address
> the advertising Scala projects issue.  If there's a reasonable or better
> solution, I'll be happy to put hosting and bandwidth resources behind a
> solution as a way to continue to support growth in the Scala community.
> >
> > Thanks,
> >
> > David
> >
> >
> >
> >
> >
> > On Mon, Apr 19, 2010 at 8:13 PM, Paul Phillips <paulp@improving.org>
> wrote:
> >
> > >
> > >
> > > On Mon, Apr 19, 2010 at 09:35:57PM -0400, James Matlik wrote:
> > > > The next point of focus for Sbaz needs to be developing a social style
> > > > Universe management platform with the goal of cultivating a community
> > > > focused on building quality collections of related libraries. I
> > > > envision people using sbaz in a way similar to github, only for
> > > > packages instead of code.
> > >
> > > I hate to be mr. skeptical, but couldn't we first target something a bit
> > > less ambitious which directly leverages existing infrastructure? My
> > > sense is that you hugely underestimate the critical mass (in packaging
> > > effort, ongoing maintenance, and actual users) it takes before a whole
> > > new distribution mechanism has any chance of rising above the level of
> > > "good idea".  If that kind of effort was available for scala I feel sure
> > > I would have heard about it.
> > >
> > > I'm trying to avert the stomach pains I will have seeing any significant
> > > quantity of scala-focused effort disappearing into hypotheticaland when
> > > there are so many tangible things to work on (like the 609 and counting
> > > open tickets in trac.) To clarify that: unrealistic goals are fine if
> > > that's what you want to do.  There is no such thing as wasted effort,
> > > it's all educational for the doer.  But if the goal here is something
> > > which will come to fruition and solve real problems, then let's have
> > > open eyes about it.  How about sketching out a few of the goalposts
> > > lying between here and there and tunnelling for the closest.
> > >
> > > --
> > > Paul Phillips      | Before a man speaks it is always safe to assume
> > > Protagonist        | that he is a fool.  After he speaks, it is seldom
> > > Empiricist         | necessary to assume it.
> > > pal, i pill push   |     -- H. L. Mencken
> > >
> >
> >
> >
> > --
> > Lift, the simply functional web framework http://liftweb.net
> > Beginning Scala
> http://www.apress.com/book/view/1430219890
> > Follow me: http://twitter.com/dpp
> > Surf the harmonics
> >
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
Daniel C. Sobral

I travel to the future all the time.

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

DPP's #1 - "create a nicer landing page for Scala-tools.org based on the contents of the pom files."

On Tue, Apr 20, 2010 at 5:43 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

I guess this thread is getting a bit long and hard to search, but can someone clarify exactly which suggestion is being tagged as #1?


On 20 April 2010 19:29, Daniel Sobral <dcsobral@gmail.com> wrote:

I think #1 first and foremost.

On Tue, Apr 20, 2010 at 2:59 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

Folks,

So, suggestion #1 -- create a nicer landing page for Scala-tools.org based on the contents of the pom files.  That's doable.

What else can we do to make it easier to find the existing code?  A wiki?  If so, who maintains it?  Who makes sure it's spam-free?  What else?

Thanks,

David

On Tue, Apr 20, 2010 at 10:55 AM, Christian Szegedy <christian.szegedy@gmail.com> wrote:

I agree: I looked at the github page, but for a casual user it is very
hard to get any useful information there (assuming that he finds that
page at all). Not to mention that it is never clear when are you on a
scala-specific page or left that domain.

Even relatively obscure programming languages like Haskell or OCaml
have much clearer sites for finding ongoing projects

cf:
http://hackage.haskell.org/packages/archive/pkg-list.html
http://caml.inria.fr/cgi-bin/hump.cgi

But I think scala has the "java disease", because there seems to be no
decent site for finding out about java libraries and projects,
either...

On 4/20/10, Daniel Sobral <dcsobral@gmail.com> wrote:
> Actually, I think Scala Tools is a pretty good example of present
> frustration. You say it hosts 148 projects. Well, ok, how do I get a list of
> their _names_, let alone a one-liner description? If there's a way to do
> that, it is not obvious from the starting page.
>
> I agree that Maven repo's are the way to go, and that storing them on Scala
> Tools is reasonable enough, and that having people e-mail to ask for an
> account is ok (though I had never noticed that was what was written in the
> starting page -- I assumed it was just the "contact the administrator about
> any problems" standard thingy).
>
> But for a repository to be useful as anything more than a repository, it
> must be both searchable and browsable (by humans). Each package must have
> name, description and tags, and it must be inserted into a human-built
> hierarchy.
>
>
> On Tue, Apr 20, 2010 at 10:23 AM, David Pollak
> <feeder.of.the.bears@gmail.com> wrote:
> > Folks,
> >
> > I am all in favor of figuring out ways to advertise Scala libraries to
> help people find Scala libraries and publish Scala libraries.  That's why I
> host Scala Tools and have been working with some very fine members of the
> Scala community (DavidB originally, Josh and Derek these days) to sustain
> and enhance Scala Tools.
> >
> > There are two separate issues winding through this thread: advertising
> libraries and hosting libraries.
> >
> > Let's deal with the latter first.  We have scala-tools.org for hosting.
> Over the last year, it's been a reliable (at least on the download side ;-)
> ) place for hosting Scala-related JARs.  It can be accessed by all the major
> Scala-related build tools (Ant, Maven, sbt, buildr, etc.)  Anybody with an
> open source project that has a defined open source license and a reasonable
> contribution policy can publish their projects at Scala tools.  If you've
> got a project you'd like to host, the instructions are on the front page of
> http://scala-tools.org or you can send email to admin [at] scala-tools.org.
> Yes, there's a manual step... but anyone who is likely to maintain their app
> is also likely to spend the 15 minutes sending us email.  There is no
> popular technical solution to JAR distribution and dependencies that's
> superior to Maven... that's why Ivy, etc. have grown up to use it.
> >
> > Scala tools hosts 148 separate projects containing 1,608 releases (that
> does not include snapshots).  That's a non-trivial collection of projects.
> I do not see any argument that we need yet another repository or
> distribution mechanism (although DavidB points to a potential change to the
> hosting policies that would allow more projects to be published on
> Scala-tools.org).
> >
> > Advertising is the more challenging issue.  Back in 2004-2006, I was
> involved with the Ruby community.  RubyForge, based on the SourceForge open
> source code, was used to host most Ruby projects.  This was the main
> advertising and aggregation space for open source Ruby projects.  At the
> time I was part of the community, RubyForge was hosted on a machine in some
> guy's basement and communicated over DSL... and that gives you the circa
> 2005 idea of how much traffic the site actually had.
> >
> > However, these days, GitHub is the place where all the cool kids do their
> Ruby work (and Scala work).
> >
> > I think that the the new entrant to the Scala world will find the most
> popular Scala libraries at
> http://github.com/languages/Scala  They'd also find a lot
> of Java libraries that do what they need and unlike Ruby's wrapping of
> native libraries, it's less common in Scala-land to publish and support
> Scala-wrapped Java libraries because (with some notable exceptions like
> Databinder Dispatch) the Scala wrapping doesn't really change the flavor of
> the library.  Speaking of N8han,  there's also http://implicit.ly/
> Implicit.ly is particularly important because it's going to help raise
> search rankings for Scala projects.
> >
> > I'm all for a non-technical,
> non-replacement-for-Maven-repositories solution to address
> the advertising Scala projects issue.  If there's a reasonable or better
> solution, I'll be happy to put hosting and bandwidth resources behind a
> solution as a way to continue to support growth in the Scala community.
> >
> > Thanks,
> >
> > David
> >
> >
> >
> >
> >
> > On Mon, Apr 19, 2010 at 8:13 PM, Paul Phillips <paulp@improving.org>
> wrote:
> >
> > >
> > >
> > > On Mon, Apr 19, 2010 at 09:35:57PM -0400, James Matlik wrote:
> > > > The next point of focus for Sbaz needs to be developing a social style
> > > > Universe management platform with the goal of cultivating a community
> > > > focused on building quality collections of related libraries. I
> > > > envision people using sbaz in a way similar to github, only for
> > > > packages instead of code.
> > >
> > > I hate to be mr. skeptical, but couldn't we first target something a bit
> > > less ambitious which directly leverages existing infrastructure? My
> > > sense is that you hugely underestimate the critical mass (in packaging
> > > effort, ongoing maintenance, and actual users) it takes before a whole
> > > new distribution mechanism has any chance of rising above the level of
> > > "good idea".  If that kind of effort was available for scala I feel sure
> > > I would have heard about it.
> > >
> > > I'm trying to avert the stomach pains I will have seeing any significant
> > > quantity of scala-focused effort disappearing into hypotheticaland when
> > > there are so many tangible things to work on (like the 609 and counting
> > > open tickets in trac.) To clarify that: unrealistic goals are fine if
> > > that's what you want to do.  There is no such thing as wasted effort,
> > > it's all educational for the doer.  But if the goal here is something
> > > which will come to fruition and solve real problems, then let's have
> > > open eyes about it.  How about sketching out a few of the goalposts
> > > lying between here and there and tunnelling for the closest.
> > >
> > > --
> > > Paul Phillips      | Before a man speaks it is always safe to assume
> > > Protagonist        | that he is a fool.  After he speaks, it is seldom
> > > Empiricist         | necessary to assume it.
> > > pal, i pill push   |     -- H. L. Mencken
> > >
> >
> >
> >
> > --
> > Lift, the simply functional web framework http://liftweb.net
> > Beginning Scala
> http://www.apress.com/book/view/1430219890
> > Follow me: http://twitter.com/dpp
> > Surf the harmonics
> >
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
Daniel C. Sobral

I travel to the future all the time.

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

On 21 April 2010 02:12, Daniel Sobral wrote:
> Actually, I think Scala Tools is a pretty good example of present
> frustration. You say it hosts 148 projects. Well, ok, how do I get a list of
> their _names_, let alone a one-liner description? If there's a way to do
> that, it is not obvious from the starting page.

+1.
Actually, +1_000_000.

I honestly thought scala-tools hosted, like, four projects - Lift,
maven-scala-plugin, scalajpa and specs.
Why?
*because that's what is listed when i hit the "documentation sites" link.*
Hitting the other link (Maven repo) just gives me a tree of
meaningless abbreviations, and obviously seems like it's only meant to
be machine-readable.

If there's 150 projects under there, then for the love of god, expose
them somehow!
(Or am I being really daft and missing the obvious way to do it.)

Thanks ;)
Toby

As the creator of the scala-tools.org home page. I'll work (next week-end) on a proposal for a new home page with a search form
(last night, I did some test to use REST api of nexus).

Until there is a new home page, you could (already) request about artifact from :
  http://nexus.scala-tools.org/
(one of the raison I installed nexus some time ago was the ability to search artifact).

/davidB


On Wed, Apr 21, 2010 at 03:58, Toby Corkindale <toby@dryft.net> wrote:

On 21 April 2010 02:12, Daniel Sobral <dcsobral@gmail.com> wrote:
> Actually, I think Scala Tools is a pretty good example of present
> frustration. You say it hosts 148 projects. Well, ok, how do I get a list of
> their _names_, let alone a one-liner description? If there's a way to do
> that, it is not obvious from the starting page.

+1.
Actually, +1_000_000.

I honestly thought scala-tools hosted, like, four projects - Lift,
maven-scala-plugin, scalajpa and specs.
Why?
*because that's what is listed when i hit the "documentation sites" link.*
Hitting the other link (Maven repo) just gives me a tree of
meaningless abbreviations, and obviously seems like it's only meant to
be machine-readable.

If there's 150 projects under there, then for the love of god, expose
them somehow!
(Or am I being really daft and missing the obvious way to do it.)

Thanks ;)
Toby

On 21 April 2010 17:21, David Bernard wrote:
> As the creator of the scala-tools.org home page. I'll work (next week-end)
> on a proposal for a new home page with a search form
> (last night, I did some test to use REST api of nexus).
>
> Until there is a new home page, you could (already) request about artifact
> from :
>   http://nexus.scala-tools.org/
> (one of the raison I installed nexus some time ago was the ability to search
> artifact).

I did have a look at that page, when you mentioned it last, but it
didn't seem very useful, either.
Eg. if I search for "CSV" or "RSS" I get back a bunch of hits, but
they're mostly all the same package, and there's no way to tell if I'm
hitting anything useful or not..
The only info is "Artifact Information" which has:
* Group (eg. net.liftweb)
* Artifact (eg. lift-widgets)
* Version (eg. 2.0)
and then a link to download the POM.

What I would *like* to see in search results is a description of the
package, and a link to the API documentation.

That would be great if you can arrange that instead.

-Toby

This is a very positive discussion to be having, and seems timely given the up-coming 2.8 version of scala. Just my 2c...

Maven repositories are the way to go for distribution - they are supported by so many things in addition to maven. You can put extra info in the pom, or if you like, upload ancillary artefacts alongside the .jar and .pom in which we could store additional meta-data, and this stuff could be indexed as has been suggested.

The haskell/cabal stuff is very user-friendly, as I can, from the command-line, find libraries that may do what I need. The perl/cpan stuff is nice because of the user feedback, voting. I would expect that both could be supported through some RESTful extention to maven repositories or NEXUS or something.

In practice, OSGi has become the de-facto standard for componentised jvm code. However, I've no feel for if there should be a community effort to host plugin repositories of OSGi artifacts.

Lastly, I personally find that searching documentation is the major barrier to me using other people's code. Scaladoc seems not to help too much here - it's very tied to the code people wrote, rather than the functionality they expose. Also, I usually need to search by type signature (a-la hoogle), and right now I've not found a scala equivalent for this.

Anyway, I'm really impressed by what the scala community has achieved so far. If we treat this from the point of view of 'what would people who aren't scala geeks expect/need to get sucked in?' then I see a bright future ahead.

Matthew

In addition to adding support for advertising and searching for humans, some additional version information is needed for system driven dependency resolution that isn't tracked via the existing maven versioning conventions... I think.  This need is driven primarily from Scala's loss of Java's forward compatibility "guarantee" where (for example) code written and compiled in Java 1.3 is usable in Java 1.6 and beyond. To illustrate this, lets create a basic application.
matlikj@hydra:~/tmp/version_example$ cat Test.scala object Test {   def main(args: Array[String]) {    val string = "3,2,1,Blast Off"    val array = string.split(",")     array.foreach(println(_))    println(array.mkString("Ready? ", "... ", "!!!"))   }}
Then, lets compile it against an older version of Scala.  This happens to be Scala 2.7.5 final.
matlikj@hydra:~/tmp/version_example$ /home/matlikj/lib/scala-2.7.5.final/bin/scalac Test.scala matlikj@hydra:~/tmp/version_example$ java -cp $SCALA_HOME/lib/scala-library.jar:. Test 321Blast Off Ready? 3... 2... 1... Blast Off!!!
So we have a baseline.  Lets try running this with Scala 2.8 now.
matlikj@hydra:~/tmp/version_example$ java -cp /home/matlikj/lib/scala-2.8.0.Beta1-prerelease/lib/scala-library.jar:. Test Exception in thread "main" java.lang.NoClassDefFoundError: scala/Iterable at Test.main(Test.scala) Caused by: java.lang.ClassNotFoundException: scala.Iterable at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:303) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:316) ... 1 more
So this is not bytecode compatible.  Yet, if I attempt to compile against 2.8, I find it is clearly source code compatible.
matlikj@hydra:~/tmp/version_example$ /home/matlikj/lib/scala-2.8.0.Beta1-prerelease/bin/scalac Test.scala matlikj@hydra:~/tmp/version_example$ java -cp /home/matlikj/lib/scala-2.8.0.Beta1-prerelease/lib/scala-library.jar:. Test 321Blast Off Ready? 3... 2... 1... Blast Off!!!
This aspect of Scala makes the inclusion of third party libraries developed in Scala less safe than experienced in the Java culture, which is then compounded by transitive dependencies. Managing not only library versions but the versions of dependencies those libraries are compiled against becomes important. This is the reason why SBT has built in functionality to compile code against multiple versions of Scala. SBT also appears to have introduced a naming convention for embedding this detail into the generated artifact. Of course, none of the libraries on scala-tools.org (at least those I browsed through) support this naming convention.
This bytecode incompatibility issue can surface itself in more subtle areas, not just between major version changes of Scala's core libraries.  The issue of trait evolution requiring extending classes to recompile still exists, and people need to be educated that API evolution that supports source code compatibility does not ensure bytecode compatibility, etc.  I fear that this additional complexity to Java's "JAR hell" is a solid concern that needs to be addressed both in tools and documentation for Scala to thrive as a language for general purpose and broadly used libraries. Presently, the only robust solution I can think of that "dumbs down" artifact management for the masses is at the source code level. Users could download and compile, or a more managed server side solution could accept source packages and ensure dependents are recompiled for bytecode compatibility. This would require a fair amount of work to implement, and I have concerns with how well it could scale.  
I do not believe that the current state and conventions of Maven alone is enough to address these concerns.  Of course, I could just be playing the part of Chicken Little... Thoughts?

On Mon, Apr 26, 2010 at 3:16 PM, James Matlik wrote:
>This is the reason why SBT has built in
> functionality to compile code against multiple versions of Scala. SBT also
> appears to have introduced a naming convention for embedding this detail
> into the generated artifact. Of course, none of the libraries
> on scala-tools.org (at least those I browsed through) support this naming
> convention.

Many libraries in the scala-tools Snapshots repository adhere to the
convention of appending the scala version to the module ID. Once 2.8.0
is itself released, expect many projects to publish themselves to the
scala-tools releases repository.

http://scala-tools.org/repo-snapshots/com/googlecode/scalaz/
http://nexus-direct.scala-tools.org/index.html#nexus-search;quick~2.8.0.RC1

For those using Maven to consume and publish Scala libraries, it's
easy enough to define scala.version as a property, and suffix the
module ID of your project and its dependencies to approximate the
cross-build feature of SBT.

-jason

+1
Just like what I would have said, only clearer :)

On 26 April 2010 14:40, Jason Zaugg <jzaugg@gmail.com> wrote:

On Mon, Apr 26, 2010 at 3:16 PM, James Matlik <james.matlik@gmail.com> wrote:
>This is the reason why SBT has built in
> functionality to compile code against multiple versions of Scala. SBT also
> appears to have introduced a naming convention for embedding this detail
> into the generated artifact. Of course, none of the libraries
> on scala-tools.org (at least those I browsed through) support this naming
> convention.

Many libraries in the scala-tools Snapshots repository adhere to the
convention of appending the scala version to the module ID. Once 2.8.0
is itself released, expect many projects to publish themselves to the
scala-tools releases repository.

 http://scala-tools.org/repo-snapshots/com/googlecode/scalaz/
 http://nexus-direct.scala-tools.org/index.html#nexus-search;quick~2.8.0.RC1

For those using Maven to consume and publish Scala libraries, it's
easy enough to define scala.version as a property, and suffix the
module ID of your project and its dependencies to approximate the
cross-build feature of SBT.

-jason

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

Hi,   quite basic but I can't see it, maybe someone of you has some seconds left.   Would like to do something similar to this:   class NewAdd[X: Numeric](val x: X) {
  def +(that: NewAdd[X]) = new NewAdd(this.x + that.x)
}    I thought the "X: Numeric" is sufficient to make "this.x + that.x" well defined, but the compiler doesn't fine the numeric + and uses toString instead and crashes later on.   I also tried "X <: Number", but no change.   Many thanks in advance, Volker. 

Numeric does not have a "+" method defined. This is why "this.x + that.x" does not work.
Try defining "+" as
def +(that: NewAdd[X]) = new NewAdd(x.plus(x, that.x))
But, I am not sure if the result will be what you expect. Dow you have a concrete example of scala.math.Numeric[_] to test your NewAdd class?
Jeff.

On Mon, Apr 26, 2010 at 10:53 AM, Bardenhorst, Volker Dr. <Volker.Bardenhorst@eon.com> wrote:

Hi,   quite basic but I can't see it, maybe someone of you has some seconds left.   Would like to do something similar to this:   class NewAdd[X: Numeric](val x: X) {
  def +(that: NewAdd[X]) = new NewAdd(this.x + that.x)
}    I thought the "X: Numeric" is sufficient to make "this.x + that.x" well defined, but the compiler doesn't fine the numeric + and uses toString instead and crashes later on.   I also tried "X <: Number", but no change.   Many thanks in advance, Volker. 

--
Knowledge is power.
Power corrupts.
Study hard.
Be evil.

"You question the worthiness of my Code? I should kill you where you stand!"

On Mon, Apr 26, 2010 at 11:13:01AM -0300, Jefferson Andrade wrote:
> Numeric does not have a "+" method defined. This is why "this.x +
> that.x" does not work.

This is true but kind of misses the useful answer, which I gave all of
eight days ago. I think we must do something about more effectively
enshrining this sort of knowledge.

Date: Sun, 18 Apr 2010 11:32:22 -0700
From: Paul Phillips
To: Johannes Rudolph
Cc: Alex Cruise ,
scala User List
Subject: Re: [scala-user] How to use scala.math.Numeric?

On Sun, Apr 18, 2010 at 06:43:47PM +0200, Johannes Rudolph wrote:
> You have to require an implicit parameter of Numeric[T] to access the
> arithmetic methods. However, I didn't manage to make the implicit
> conversions to Numeric to kick in automatically.

The implicit is in the Numeric so it must be imported. This is
suboptimal but I don't see much to be done about it at this point.

scala> case class Add[T](numbers: T*)(implicit x: scala.math.Numeric[T]) { import x._ ; def eval = numbers.reduceLeft(_ + _) }
defined class Add

scala> Add(5L, 10L, 15L) eval
res0: Long = 30

On 26 April 2010 17:31, Paul Phillips <paulp@improving.org> wrote:

On Mon, Apr 26, 2010 at 11:13:01AM -0300, Jefferson Andrade wrote:
> Numeric does not have a "+" method defined. This is why "this.x +
> that.x" does not work.

This is true but kind of misses the useful answer, which I gave all of
eight days ago.  I think we must do something about more effectively
enshrining this sort of knowledge.

It's definitely one to be posted on StackOverflow, for posterity!
 

Date: Sun, 18 Apr 2010 11:32:22 -0700
From: Paul Phillips <paulp@improving.org>
To: Johannes Rudolph <johannes.rudolph@googlemail.com>
Cc: Alex Cruise <alex@cluonflux.com>,
       scala User List <scala-user@listes.epfl.ch>
Subject: Re: [scala-user] How to use scala.math.Numeric?

On Sun, Apr 18, 2010 at 06:43:47PM +0200, Johannes Rudolph wrote:
> You have to require an implicit parameter of Numeric[T] to access the
> arithmetic methods. However, I didn't manage to make the implicit
> conversions to Numeric to kick in automatically.

The implicit is in the Numeric so it must be imported.  This is
suboptimal but I don't see much to be done about it at this point.

scala> case class Add[T](numbers: T*)(implicit x: scala.math.Numeric[T]) { import x._ ; def eval = numbers.reduceLeft(_ + _) }
defined class Add

scala> Add(5L, 10L, 15L) eval
res0: Long = 30

--
Paul Phillips      | The most dangerous man to any government is the man who
Analgesic          | is able to think things out [...] Almost inevitably he
Empiricist         | comes to the conclusion that the government he lives under
slap pi uphill!    | is dishonest, insane, intolerable.   -- H. L. Mencken

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

It is, in at least two different questions. I'll grant neither of the questions I'm thinking of are easily searchable, as Numeric is in the answer, not the question.

On Mon, Apr 26, 2010 at 2:39 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

On 26 April 2010 17:31, Paul Phillips <paulp@improving.org> wrote:

On Mon, Apr 26, 2010 at 11:13:01AM -0300, Jefferson Andrade wrote:
> Numeric does not have a "+" method defined. This is why "this.x +
> that.x" does not work.

This is true but kind of misses the useful answer, which I gave all of
eight days ago.  I think we must do something about more effectively
enshrining this sort of knowledge.

It's definitely one to be posted on StackOverflow, for posterity!
 

Date: Sun, 18 Apr 2010 11:32:22 -0700
From: Paul Phillips <paulp@improving.org>
To: Johannes Rudolph <johannes.rudolph@googlemail.com>
Cc: Alex Cruise <alex@cluonflux.com>,
       scala User List <scala-user@listes.epfl.ch>
Subject: Re: [scala-user] How to use scala.math.Numeric?

On Sun, Apr 18, 2010 at 06:43:47PM +0200, Johannes Rudolph wrote:
> You have to require an implicit parameter of Numeric[T] to access the
> arithmetic methods. However, I didn't manage to make the implicit
> conversions to Numeric to kick in automatically.

The implicit is in the Numeric so it must be imported.  This is
suboptimal but I don't see much to be done about it at this point.

scala> case class Add[T](numbers: T*)(implicit x: scala.math.Numeric[T]) { import x._ ; def eval = numbers.reduceLeft(_ + _) }
defined class Add

scala> Add(5L, 10L, 15L) eval
res0: Long = 30

--
Paul Phillips      | The most dangerous man to any government is the man who
Analgesic          | is able to think things out [...] Almost inevitably he
Empiricist         | comes to the conclusion that the government he lives under
slap pi uphill!    | is dishonest, insane, intolerable.   -- H. L. Mencken

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

--
Daniel C. Sobral

I travel to the future all the time.

On 20/04/2010 08:54, Russel Winder wrote:
>
> Moreover due to the Debian policy, the Debian system generally
> conflicts with any and all language specific systems.
>

Can you please elaborate more on this?
It looks like plain wrong to me.

Regards,