Time for a new Scala extensions repository?

On Wed, 2009-11-04 at 11:53 +0100, martin odersky wrote:
> Hi all,
>
> The recent discussions about experimental, Zero, and I/O point to a
> systemic problem we have: There is no good way to let code for the
> standard library mature. For the compiler, we have plugins which
> provide a good way to develop things gradually, at least as long as
> they fit into the phase model. But for the library, it's all or
> nothing. What we'd need instead is an incubator in which classes or
> methods can be tentatively added to the distribution, tested by the
> community, commented on, and eventually, when most people are happy,
> migrated into the standard distribution. So I propose to give some
> serious thought how this could be achieved.

Yes, this is definitely very important.

> So, how about an officially blessed scala extension library? The
> library could be distributed as a jar through official channels (e.g.
> EPFL, scala-tools). It would live in the scala package, so it could
> contain duplicates of standard Scala classes with new methods or
> fields. This means, if you put scala-library-x.jar (to pick a name) in
> front of scala-library.jar on your classpath, you'll automatically
> pick up all the extensions. I believe the source code of the library
> should be in a git repository, because that makes it easier to develop
> parallel branches to trunk. Once things are sufficiently mature and
> user feedback is overwhelmingly positive that some parts of the
> library should be included, it should be easy to push those parts into
> trunk.

Maybe this could be an additional repository (e.g. scala-extensions) in
the scala incubator started by Miles:

http://github.com/scala-incubator/

To start with, the people with push access to that repository could be
the currently active committers to the Scala standard library.

> We'd need a gatekeeper who watches out that things
> are consistent that will have final authority what should be included
> or not.

That makes sense.

> Do you think such a scheme could work?

Yes.

> Are there modifications you want to propose?

More of a question, have you thought about how methods would be added to
existing classes? Would the extensions library contain the full source
code or just an overlay? If the former, wouldn't this imply quite a bit
of work to keep in sync with trunk?

> Are there volunteers to do parts of it?

I would like to contribute.

Best,
Ismael

This would all be much easier if the modularization effort bear fruits first. I think time is better spent on that effort.

On Wed, Nov 4, 2009 at 8:53 AM, martin odersky <martin.odersky@epfl.ch> wrote:

Hi all,

The recent discussions about experimental, Zero, and I/O point to a
systemic problem we have: There is no good way to let code for the
standard library mature. For the compiler, we have plugins which
provide a good way to develop things gradually, at least as long as
they fit into the phase model. But for the library, it's all or
nothing. What we'd need instead is an incubator in which classes or
methods can be tentatively added to the distribution, tested by the
community, commented on, and eventually, when most people are happy,
migrated into the standard distribution. So I propose to give some
serious thought how this could be achieved.

Let me start with approaches that we tried and that do not seem to work:

1. Putting things in trunk and removing them again when there's
sufficient opposition. That might have been workable in the run-up to
2.8, where trunk has been in fairly fluid state for a long time. After
the beta is out and we go to regular RC's and minor releases I don't
see that happening anymore.

2. Separate community libraries such as scalax or scalaz. These are
fine, but lack in several points. First, granularity: They let you
only add whole classes, not experimental methods to existing classes.
Second, user feedback. The fact that these are separate projects means
that relatively fewer people will test and comment, and that therefore
relatively fewer people will contribute. If we get a contribution to
trunk and we tell the contributor to put in into scalax or scalaz
instead, they are not always happy. Third, migration. If a scalax or
scalaz project should make it into trunk, clients have to change at
least their imports because scalax will become scala.

3. scala-tools.org. It's a great resource for hosting whole projects,
but I don't see them maintaining small increments. On the other and,
what I propose might well be hosted as a whole on scala-tools.org.

So, how about an officially blessed scala extension library? The
library could be distributed as a jar through official channels (e.g.
EPFL, scala-tools). It would live in the scala package, so it could
contain duplicates of standard Scala classes with new methods or
fields. This means, if you put scala-library-x.jar (to pick a name) in
front of scala-library.jar on your classpath, you'll automatically
pick up all the extensions. I believe the source code of the library
should be in a git repository, because that makes it easier to develop
parallel branches to trunk.  Once things are sufficiently mature and
user feedback is overwhelmingly positive that some parts of the
library should be included, it should be easy to push those parts into
trunk.

I believe that if we have such an official extended library, people
would be happy to use it, and to contribute to it, in particular once
we have demonstrated a couple of times that extensions will make it
back into trunk. We'd need a gatekeeper who watches out that things
are consistent that will have final authority what should be included
or not. But the discussion leading up to this would be driven by the
community.

There's no lack of items already in development that could go tomorrow
into such a library. Examples are Zero, GenericRange, work on STM,
work on 2/3D Vectors, work on parallel collections,  or (and that's
the one I most care about), Paul's I/O proposal. What would be good
about it is that we'd have an answer to people who complain that Scala
does not yet have a decent I/O library, or STM, or parallel
collections. There would be something solid that they could use
immediately. Sure, it's not finalized yet, but at least they see that
things are moving.

Do you think such a scheme could work? Are there modifications you
want to propose? Are there volunteers to do parts of it?

Cheers

On Wed, Nov 4, 2009 at 12:46 PM, Daniel Sobral wrote:
> This would all be much easier if the modularization effort bear fruits
> first. I think time is better spent on that effort.
>
AFAIK that effort has stopped, no? But I believe anyway the two are
orthogonal. scala-extensions is mostly about making extensions that
will corss module boundaries.

Cheers

On Wed, Nov 4, 2009 at 11:55 AM, martin odersky wrote:
> On Wed, Nov 4, 2009 at 12:46 PM, Daniel Sobral wrote:
>> This would all be much easier if the modularization effort bear fruits
>> first. I think time is better spent on that effort.
>>
> AFAIK that effort has stopped, no?

Yes, unfortunately it seems that way ...

Cheers,

Miles

I'd contribute whatever time I can spare towards areas i have
expertise over.

So of we're building some form of build infrastructure/integration to
the evosysytem, I'm there.

Also, would this extension library live against trunk, a partiilar
release, or both?

Sent from my iPhone

On Nov 4, 2009, at 5:53 AM, martin odersky
wrote:

> Hi all,
>
> The recent discussions about experimental, Zero, and I/O point to a
> systemic problem we have: There is no good way to let code for the
> standard library mature. For the compiler, we have plugins which
> provide a good way to develop things gradually, at least as long as
> they fit into the phase model. But for the library, it's all or
> nothing. What we'd need instead is an incubator in which classes or
> methods can be tentatively added to the distribution, tested by the
> community, commented on, and eventually, when most people are happy,
> migrated into the standard distribution. So I propose to give some
> serious thought how this could be achieved.
>
> Let me start with approaches that we tried and that do not seem to
> work:
>
> 1. Putting things in trunk and removing them again when there's
> sufficient opposition. That might have been workable in the run-up to
> 2.8, where trunk has been in fairly fluid state for a long time. After
> the beta is out and we go to regular RC's and minor releases I don't
> see that happening anymore.
>
> 2. Separate community libraries such as scalax or scalaz. These are
> fine, but lack in several points. First, granularity: They let you
> only add whole classes, not experimental methods to existing classes.
> Second, user feedback. The fact that these are separate projects means
> that relatively fewer people will test and comment, and that therefore
> relatively fewer people will contribute. If we get a contribution to
> trunk and we tell the contributor to put in into scalax or scalaz
> instead, they are not always happy. Third, migration. If a scalax or
> scalaz project should make it into trunk, clients have to change at
> least their imports because scalax will become scala.
>
> 3. scala-tools.org. It's a great resource for hosting whole projects,
> but I don't see them maintaining small increments. On the other and,
> what I propose might well be hosted as a whole on scala-tools.org.
>
> So, how about an officially blessed scala extension library? The
> library could be distributed as a jar through official channels (e.g.
> EPFL, scala-tools). It would live in the scala package, so it could
> contain duplicates of standard Scala classes with new methods or
> fields. This means, if you put scala-library-x.jar (to pick a name) in
> front of scala-library.jar on your classpath, you'll automatically
> pick up all the extensions. I believe the source code of the library
> should be in a git repository, because that makes it easier to develop
> parallel branches to trunk. Once things are sufficiently mature and
> user feedback is overwhelmingly positive that some parts of the
> library should be included, it should be easy to push those parts into
> trunk.
>
> I believe that if we have such an official extended library, people
> would be happy to use it, and to contribute to it, in particular once
> we have demonstrated a couple of times that extensions will make it
> back into trunk. We'd need a gatekeeper who watches out that things
> are consistent that will have final authority what should be included
> or not. But the discussion leading up to this would be driven by the
> community.
>
> There's no lack of items already in development that could go tomorrow
> into such a library. Examples are Zero, GenericRange, work on STM,
> work on 2/3D Vectors, work on parallel collections, or (and that's
> the one I most care about), Paul's I/O proposal. What would be good
> about it is that we'd have an answer to people who complain that Scala
> does not yet have a decent I/O library, or STM, or parallel
> collections. There would be something solid that they could use
> immediately. Sure, it's not finalized yet, but at least they see that
> things are moving.
>
> Do you think such a scheme could work? Are there modifications you
> want to propose? Are there volunteers to do parts of it?
>
> Cheers
>

Oh yes please!

This would help in so many ways.

On Wednesday, November 4, 2009, Miles Sabin wrote:
> On Wed, Nov 4, 2009 at 11:55 AM, martin odersky wrote:
>> On Wed, Nov 4, 2009 at 12:46 PM, Daniel Sobral wrote:
>>> This would all be much easier if the modularization effort bear fruits
>>> first. I think time is better spent on that effort.
>>>
>> AFAIK that effort has stopped, no?
>
> Yes, unfortunately it seems that way ...
>
> Cheers,
>
>
> Miles
>
> --
> Miles Sabin
> tel: +44 (0)7813 944 528
> skype:  milessabin
> http://www.chuusai.com/
> http://twitter.com/milessabin
>

On Wed, Nov 4, 2009 at 12:53, martin odersky wrote:
> Hi all,
>
> The recent discussions about experimental, Zero, and I/O point to a
> systemic problem we have: There is no good way to let code for the
> standard library mature. For the compiler, we have plugins which
> provide a good way to develop things gradually, at least as long as
> they fit into the phase model. But for the library, it's all or
> nothing. What we'd need instead is an incubator in which classes or
> methods can be tentatively added to the distribution, tested by the
> community, commented on, and eventually, when most people are happy,
> migrated into the standard distribution. So I propose to give some
> serious thought how this could be achieved.
>
> Let me start with approaches that we tried and that do not seem to work:
>
> 1. Putting things in trunk and removing them again when there's
> sufficient opposition. That might have been workable in the run-up to
> 2.8, where trunk has been in fairly fluid state for a long time. After
> the beta is out and we go to regular RC's and minor releases I don't
> see that happening anymore.
>
> 2. Separate community libraries such as scalax or scalaz. These are
> fine, but lack in several points. First, granularity: They let you
> only add whole classes, not experimental methods to existing classes.
> Second, user feedback. The fact that these are separate projects means
> that relatively fewer people will test and comment, and that therefore
> relatively fewer people will contribute. If we get a contribution to
> trunk and we tell the contributor to put in into scalax or scalaz
> instead, they are not always happy. Third, migration. If a scalax or
> scalaz project should make it into trunk, clients have to change at
> least their imports because scalax will become scala.
>
> 3. scala-tools.org. It's a great resource for hosting whole projects,
> but I don't see them maintaining small increments. On the other and,
> what I propose might well be hosted as a whole on scala-tools.org.
>
> So, how about an officially blessed scala extension library? The
> library could be distributed as a jar through official channels (e.g.
> EPFL, scala-tools). It would live in the scala package, so it could
> contain duplicates of standard Scala classes with new methods or
> fields. This means, if you put scala-library-x.jar (to pick a name) in
> front of scala-library.jar on your classpath, you'll automatically
> pick up all the extensions. I believe the source code of the library
> should be in a git repository, because that makes it easier to develop
> parallel branches to trunk.  Once things are sufficiently mature and
> user feedback is overwhelmingly positive that some parts of the
> library should be included, it should be easy to push those parts into
> trunk.
>
> I believe that if we have such an official extended library, people
> would be happy to use it, and to contribute to it, in particular once
> we have demonstrated a couple of times that extensions will make it
> back into trunk. We'd need a gatekeeper who watches out that things
> are consistent that will have final authority what should be included
> or not. But the discussion leading up to this would be driven by the
> community.
>
> There's no lack of items already in development that could go tomorrow
> into such a library. Examples are Zero, GenericRange, work on STM,
> work on 2/3D Vectors, work on parallel collections,  or (and that's
> the one I most care about), Paul's I/O proposal. What would be good
> about it is that we'd have an answer to people who complain that Scala
> does not yet have a decent I/O library, or STM, or parallel
> collections. There would be something solid that they could use
> immediately. Sure, it's not finalized yet, but at least they see that
> things are moving.
>
> Do you think such a scheme could work? Are there modifications you
> want to propose? Are there volunteers to do parts of it?
>
> Cheers
>
>  -- Martin
>

I see all of this favourably.

I think the most crucial part of the proposal is the scala.*
namespace. It will surely feel good to develop under this namespace
and the transition when and if parts go to the official distribution
will be with less pain.

We will also need some pre-thought organizational constraints before
we delve into a realisation of the scheme, though. A few thoughts for
discussion (but not too much discussion, as we need something in place
soon):

1. I think that a fat top project with contributions spanning all the
library code-base will not scale.

2. Distributed Version Control is the only way. I believe I have seen
a general consesus in the lists about using GIT. Related to that,
GitHub seems to be the de-facto choice for a repository nowadays.

3. We can take advantage of GIT's branching capabilities and Gitub's
forking etc infrastructure to organize things, in order to cope with
my observation in 1. In particular:
* There will be a single master reference branch, the build outcome
of which will be the officially endorsed scala-library-ext.jar.
* Anyone with an idea to try something, is free to fork this branch
and work one of his own. A fork owner is responsible for keeping in
sync with the master branch.
* A coordinator is needed here. The master branch coordinator will
choose (along with EPFL I assume) which forked stuff can go into the
master branch and selectively decide if the fork owner is granted
access to directly commit in the master branch or just keep commiting
in the fork.
* If things get more complex and there are bigger areas of interest
(IO is a candidate now), the coordinator can choose to have
lieautenants in charge of "blessed" branches that are responsible for
collaborating with the relevant forks.

4. The "coordination" process, as described above, will take feedback
from the user base commenting, complaining, proposing, etc in the
lists.

5. We need a build infrastructure (continuous integration)

6. Integrated Issue Tracking is needed also

7. When and if the scala-modularization effort is reattempted, can it
be supported by the above?

8. I assume scala-tools.org will host the ready-to-grab stuff.

9. How do we proceed with existing projects, like scalax and scalaz?
Think of the "problem" the other way around: These projects already
have a user-base and we suddenly a) rename their packages, b) re-host
the code-base. I can think of approaches but my intention here is to
mention the issue and let the most relevant people share their
opinion.

10. If the official scala-library.jar gets stuff from
scalalibrary-ext.jar, would it be beneficial for both to share a
common version control approach?

12. Do we try this "wholesale"? That is, do we launch and advertise
the feature in one step or do we start using it for a couple of things
(Scala IO, Zero?) and then come back in one or two months, comment on
the progress and decide on the effectiveness?

Christos

On Wed, Nov 4, 2009 at 11:38 PM, Christos KK Loverdos
wrote:
>  * There will be a single master reference branch, the build outcome
> of which will be the officially endorsed scala-library-ext.jar.
>  * Anyone with an idea to try something, is free to fork this branch
> and work one of his own. A fork owner is responsible for keeping in
> sync with the master branch.
>  * A coordinator is needed here. The master branch coordinator will
> choose (along with EPFL I assume) which forked stuff can go into the
> master branch and selectively decide if the fork owner is granted
> access to directly commit in the master branch or just keep commiting
> in the fork.
> * If things get more complex and there are bigger areas of interest
> (IO is a candidate now), the coordinator can choose to have
> lieautenants in charge of "blessed" branches that are responsible for
> collaborating with the relevant forks.

I support this idea in general and particularly all the above
proposals for dev process, which sound practically workable.

I would emphasize the ability of this scheme to support a multi-level,
topic-focused hierarchy of branches, not just direct variants of the
master branch. As well all know, trees scale like nothing else!

Master (managed by head-gatekeeper)
IO (managed by IO gatekeeper/commitee/despot)
MyIO
YourIO
STM (managed by STM lieautenants)
MySTM
YourSTM

> 9. How do we proceed with existing projects, like scalax and scalaz?

(i) Invite them into the scala namespace. (ii) make a sub-branch of
master to accept their contributions, (iii) treat them like anyone
else, except realize that they have alot more, and higher-maturity,
content on offer, earlier.

> 12. Do we try this "wholesale"? That is, do we launch and advertise
> the feature in one step or do we start using it for a couple of things
> (Scala IO, Zero?) and then come back in one or two months, comment on
> the progress and decide on the effectiveness?

I vote for the gradual, try-it-and-review approach.

13: How likely and/or problematic is it if branches seriously diverge?
Eg If in the CategoryTheoryAppreciationSociety branch, after a
herculean effort, Traversable and the collections hierarchy now
extends from Functor, but in many other branches it doesnt, will there
will be strong, possibly irreconcilable, differences on where the
master library should head? Even if all the alternative sub-branches
on offer are in themselves coherent and viable.

-Ben

Who do you have in mind to be the gatekeeper?  It seems like this person is key to the success, and should probably get started setting up infrastructure and determining where/how the process will unfold before things make into "Scala proper"


- Josh

On Wed, Nov 4, 2009 at 5:53 AM, martin odersky <martin.odersky@epfl.ch> wrote:

Hi all,

The recent discussions about experimental, Zero, and I/O point to a
systemic problem we have: There is no good way to let code for the
standard library mature. For the compiler, we have plugins which
provide a good way to develop things gradually, at least as long as
they fit into the phase model. But for the library, it's all or
nothing. What we'd need instead is an incubator in which classes or
methods can be tentatively added to the distribution, tested by the
community, commented on, and eventually, when most people are happy,
migrated into the standard distribution. So I propose to give some
serious thought how this could be achieved.

Let me start with approaches that we tried and that do not seem to work:

1. Putting things in trunk and removing them again when there's
sufficient opposition. That might have been workable in the run-up to
2.8, where trunk has been in fairly fluid state for a long time. After
the beta is out and we go to regular RC's and minor releases I don't
see that happening anymore.

2. Separate community libraries such as scalax or scalaz. These are
fine, but lack in several points. First, granularity: They let you
only add whole classes, not experimental methods to existing classes.
Second, user feedback. The fact that these are separate projects means
that relatively fewer people will test and comment, and that therefore
relatively fewer people will contribute. If we get a contribution to
trunk and we tell the contributor to put in into scalax or scalaz
instead, they are not always happy. Third, migration. If a scalax or
scalaz project should make it into trunk, clients have to change at
least their imports because scalax will become scala.

3. scala-tools.org. It's a great resource for hosting whole projects,
but I don't see them maintaining small increments. On the other and,
what I propose might well be hosted as a whole on scala-tools.org.

So, how about an officially blessed scala extension library? The
library could be distributed as a jar through official channels (e.g.
EPFL, scala-tools). It would live in the scala package, so it could
contain duplicates of standard Scala classes with new methods or
fields. This means, if you put scala-library-x.jar (to pick a name) in
front of scala-library.jar on your classpath, you'll automatically
pick up all the extensions. I believe the source code of the library
should be in a git repository, because that makes it easier to develop
parallel branches to trunk.  Once things are sufficiently mature and
user feedback is overwhelmingly positive that some parts of the
library should be included, it should be easy to push those parts into
trunk.

I believe that if we have such an official extended library, people
would be happy to use it, and to contribute to it, in particular once
we have demonstrated a couple of times that extensions will make it
back into trunk. We'd need a gatekeeper who watches out that things
are consistent that will have final authority what should be included
or not. But the discussion leading up to this would be driven by the
community.

There's no lack of items already in development that could go tomorrow
into such a library. Examples are Zero, GenericRange, work on STM,
work on 2/3D Vectors, work on parallel collections,  or (and that's
the one I most care about), Paul's I/O proposal. What would be good
about it is that we'd have an answer to people who complain that Scala
does not yet have a decent I/O library, or STM, or parallel
collections. There would be something solid that they could use
immediately. Sure, it's not finalized yet, but at least they see that
things are moving.

Do you think such a scheme could work? Are there modifications you
want to propose? Are there volunteers to do parts of it?

Cheers

I will take my apparently usual position that it sounds good in theory
and I fear the result in practice. Also, I think the idea of annotating
with @experimental (I didn't mark @experimental as @experimental but
should have) is a good one and offers a happy middle ground for a lot of
situations. The annotation needs to be more fully leveraged, i.e.
scaladoc knows about it and alters documentation accordingly, but I
haven't been able to work on scaladoc.

I'm not suggesting the annotation makes an extensions repository
unnecessary, but if there is to to be an extensions repo I'd sure hate
to have only a binary decision between trunk and over-there. We can go
in with the best of intentions but it's hard not to notice the usual
fate of "other" repos.

I can see by your comments you are aware of that risk. If it was
tightly enough integrated that it "felt like" trunk then maybe it could
work. The litmus test I would say is the number of extra steps
necessary to build a distribution with the extras. Ideally it's zero
("ant dist-extras" or something, in a git meta-repo which has both trunk
and extras as submodules) since each step beyond zero will drop the
usage by (scientifically measured) 90%.

On Thu, Nov 05, 2009 at 01:06:40AM +1100, Ben Hutchison wrote:
> 13: How likely and/or problematic is it if branches seriously diverge?
> Eg If in the CategoryTheoryAppreciationSociety branch, after a
> herculean effort, Traversable and the collections hierarchy now
> extends from Functor, but in many other branches it doesnt, will there
> will be strong, possibly irreconcilable, differences on where the
> master library should head? Even if all the alternative sub-branches
> on offer are in themselves coherent and viable.

Let's just say you'd better be undertaking such herculean efforts for
the intrinsic rewards. I infer from your question that you seriously
underestimate how far reaching such changes are and how tedious it is to
keep them coordinated with trunk. The herculean implementation effort
is the easy part.

On Wed, Nov 4, 2009 at 4:50 PM, Ismael Juma wrote:

>
> Maybe this could be an additional repository (e.g. scala-extensions) in
> the scala incubator started by Miles:
>
> http://github.com/scala-incubator/
>
> To start with, the people with push access to that repository could be
> the currently active committers to the Scala standard library.
>

How about http://github.com/scala/scala-extensions ?

I think it would great because it would appear under "scala" namespace
and since I have created that username, I can transfer the account to
community as you guys decide.

On Wed, Nov 4, 2009 at 11:20 AM, Ismael Juma wrote:
> Maybe this could be an additional repository (e.g. scala-extensions) in
> the scala incubator started by Miles:
>
> http://github.com/scala-incubator/

Actually, EPFL is welcome to take this account and it's associated repository.

Cheers,

Miles

On Wed, Nov 4, 2009 at 8:14 PM, Miles Sabin wrote:
> On Wed, Nov 4, 2009 at 11:20 AM, Ismael Juma wrote:
>> Maybe this could be an additional repository (e.g. scala-extensions) in
>> the scala incubator started by Miles:
>>
>> http://github.com/scala-incubator/
>
> Actually, EPFL is welcome to take this account and it's associated repository.
>
Actually, I don't think EPFL should be doing that. I'd much prefer
another organization to run this, to spread the load. I see EPFL's
roie more as a relay for distributing the library than as someone
organizing it.

Cheers

On Wed, Nov 4, 2009 at 7:37 PM, martin odersky wrote:
> On Wed, Nov 4, 2009 at 8:14 PM, Miles Sabin wrote:
>> On Wed, Nov 4, 2009 at 11:20 AM, Ismael Juma wrote:
>>> Maybe this could be an additional repository (e.g. scala-extensions) in
>>> the scala incubator started by Miles:
>>>
>>> http://github.com/scala-incubator/
>>
>> Actually, EPFL is welcome to take this account and it's associated repository.
>>
> Actually, I don't think EPFL should be doing that. I'd much prefer
> another organization to run this, to spread the load. I see EPFL's
> roie more as a relay for distributing the library than as someone
> organizing it.

OK, so are you endorsing that Scala Incubator Google group and
repository as the hub for this kind of thing? If not, what non-EPFL
organization do you have in mind?

Cheers,

Miles

Curiously, GWT has a GWT "incubator", used to hold changes that are
meant for GWT proper but that didn't yet achieve consensus from the
general group. I don't know how closely it maps, but the goal sounds
the same. One difference, I grant, is that the GWT incubator must
coexist with the main part of GWT. Thus, it can't include patches to
the core classes.

So, with those caveats, it's worth considering that the GWT incubator
hasn't worked out as was hoped. The part that worked is that it has
allowed code to progress that has turned out to be quite popular. If
you want a good experience with GWT, you must grab the incubator, too,
or you'll be missing out on a lot of library goodies. To skip ahead
of the story some, let me note that it is surviving even though the
current team members are fully committed to retiring it. The code in
there is just too useful.

The most troubling problem the GWT incubator has had, though, is
getting changes migrated into the core system. It might be that Scala
does better here, in which case it will work fine after all. What I
see with GWT, though, is a couple of problems. First, everyone has
better ways to spend their time than moving code from one library to
another, so nobody is eager to take on those tasks. Second, as soon
as the issue is raised, the people who initially opposed the feature
being a core feature step right back up with the same objections they
had the first time. In theory, people should be backing down once
there is proven experience with the feature, but in practice I see
people being pretty pig-headed. Perhaps the Scala group is more
enlightened and data-driven.

After all of this experience, the newer theory is that GWT will try
hosting the projects individually rather than lumping them into a big
incubator. We still don't have a story about getting those projects
into the main system, but one could imagine either we or a third party
lumping together a certain set of projects and designating them the
official ones.

As one other data point, Smalltalk code loaders routinely allow
packages to add methods to preexisting classes. This is an experiment
rarely repeated, and even NewSpeak, which takes so many other bits of
lost art from Smalltalk, does not include it. Nonetheless, I think it
works better than many expect. It sometimes happens that packages add
conflicting extensions, which is what people fear. However, it's not
a big deal in practice. There are numerous other ways that packages
can conflict, and this one is both uncommon and is often detectable by
the package loading tool. So if there really is a desire to have
experimental extensions to the core libraries -- things as pervasive
as software transactional memory -- it might be worth exploring
package-combining tool. It would take as input a bunch of Scala
packages, including extensions to the core libraries, and output a new
version

Okay, that's the data. Regarding theory, I only toss out that I don't
have a feel for what kinds of changes would both require a change to
the core library, but would be practical to have in an external
library. To me the existing mechanisms seem pretty good. The most
painful lack to me is a more approachable version of scala-tools.
Currently, if you make a Scala library, it's hard to get it to anyone
unless they use Maven. I would think a version of it could be made
that is not based on Maven, at least not from a user's perspective.
The main issue would be finding someone to maintain the repository.
Such a person would need to kick out the packages that are permanently
broken, and would ideally need to cut an occasional release of the
distribution.

Lex

Lex,

Lots of non-Maven tools can use Maven repositories. Notably, Ivy, Buildr, and sbt.

--j

On Mon, Nov 9, 2009 at 9:56 AM, Lex Spoon <lex@lexspoon.org> wrote:

Curiously, GWT has a GWT "incubator", used to hold changes that are meant for GWT proper but that didn't yet achieve consensus from the general group.  I don't know how closely it maps, but the goal sounds the same.  One difference, I grant, is that the GWT incubator must coexist with the main part of GWT.  Thus, it can't include patches to the core classes.

So, with those caveats, it's worth considering that the GWT incubator hasn't worked out as was hoped.  The part that worked is that it has allowed code to progress that has turned out to be quite popular.  If you want a good experience with GWT, you must grab the incubator, too, or you'll be missing out on a lot of library goodies.  To skip ahead of the story some, let me note that it is surviving even though the current team members are fully committed to retiring it.  The code in there is just too useful.

The most troubling problem the GWT incubator has had, though, is getting changes migrated into the core system.  It might be that Scala does better here, in which case it will work fine after all.  What I see with GWT, though, is a couple of problems.  First, everyone has better ways to spend their time than moving code from one library to another, so nobody is eager to take on those tasks.  Second, as soon as the issue is raised, the people who initially opposed the feature being a core feature step right back up with the same objections they had the first time.  In theory, people should be backing down once there is proven experience with the feature, but in practice I see people being pretty pig-headed.  Perhaps the Scala group is more enlightened and data-driven.

After all of this experience, the newer theory is that GWT will try hosting the projects individually rather than lumping them into a big incubator.  We still don't have a story about getting those projects into the main system, but one could imagine either we or a third party lumping together a certain set of projects and designating them the official ones.

As one other data point, Smalltalk code loaders routinely allow packages to add methods to preexisting classes.  This is an experiment rarely repeated, and even NewSpeak, which takes so many other bits of lost art from Smalltalk, does not include it.  Nonetheless, I think it works better than many expect.  It sometimes happens that packages add conflicting extensions, which is what people fear.  However, it's not a big deal in practice.  There are numerous other ways that packages can conflict, and this one is both uncommon and is often detectable by the package loading tool.  So if there really is a desire to have experimental extensions to the core libraries -- things as pervasive as software transactional memory -- it might be worth exploring package-combining tool.  It would take as input a bunch of Scala packages, including extensions to the core libraries, and output a new version

Okay, that's the data.  Regarding theory, I only toss out that I don't have a feel for what kinds of changes would both require a change to the core library, but would be practical to have in an external library.  To me the existing mechanisms seem pretty good.  The most painful lack to me is a more approachable version of scala-tools.  Currently, if you make a Scala library, it's hard to get it to anyone unless they use Maven.  I would think a version of it could be made that is not based on Maven, at least not from a user's perspective.  The main issue would be finding someone to maintain the repository.  Such a person would need to kick out the packages that are permanently broken, and would ideally need to cut an occasional release of the distribution.


Lex

I personally feel that having separate projects might make things easier for migrating into Scala core as well.  I also think whatever is chosen should have some method of "self-improvement" or process refinement, so that fixes can be made later for whatever mistakes we find we've made.


- Josh

On Mon, Nov 9, 2009 at 1:11 PM, Jorge Ortiz <jorge.ortiz@gmail.com> wrote:

Lex,

Lots of non-Maven tools can use Maven repositories. Notably, Ivy, Buildr, and sbt.

--j

On Mon, Nov 9, 2009 at 9:56 AM, Lex Spoon <lex@lexspoon.org> wrote:

Curiously, GWT has a GWT "incubator", used to hold changes that are meant for GWT proper but that didn't yet achieve consensus from the general group.  I don't know how closely it maps, but the goal sounds the same.  One difference, I grant, is that the GWT incubator must coexist with the main part of GWT.  Thus, it can't include patches to the core classes.

So, with those caveats, it's worth considering that the GWT incubator hasn't worked out as was hoped.  The part that worked is that it has allowed code to progress that has turned out to be quite popular.  If you want a good experience with GWT, you must grab the incubator, too, or you'll be missing out on a lot of library goodies.  To skip ahead of the story some, let me note that it is surviving even though the current team members are fully committed to retiring it.  The code in there is just too useful.

The most troubling problem the GWT incubator has had, though, is getting changes migrated into the core system.  It might be that Scala does better here, in which case it will work fine after all.  What I see with GWT, though, is a couple of problems.  First, everyone has better ways to spend their time than moving code from one library to another, so nobody is eager to take on those tasks.  Second, as soon as the issue is raised, the people who initially opposed the feature being a core feature step right back up with the same objections they had the first time.  In theory, people should be backing down once there is proven experience with the feature, but in practice I see people being pretty pig-headed.  Perhaps the Scala group is more enlightened and data-driven.

After all of this experience, the newer theory is that GWT will try hosting the projects individually rather than lumping them into a big incubator.  We still don't have a story about getting those projects into the main system, but one could imagine either we or a third party lumping together a certain set of projects and designating them the official ones.

As one other data point, Smalltalk code loaders routinely allow packages to add methods to preexisting classes.  This is an experiment rarely repeated, and even NewSpeak, which takes so many other bits of lost art from Smalltalk, does not include it.  Nonetheless, I think it works better than many expect.  It sometimes happens that packages add conflicting extensions, which is what people fear.  However, it's not a big deal in practice.  There are numerous other ways that packages can conflict, and this one is both uncommon and is often detectable by the package loading tool.  So if there really is a desire to have experimental extensions to the core libraries -- things as pervasive as software transactional memory -- it might be worth exploring package-combining tool.  It would take as input a bunch of Scala packages, including extensions to the core libraries, and output a new version

Okay, that's the data.  Regarding theory, I only toss out that I don't have a feel for what kinds of changes would both require a change to the core library, but would be practical to have in an external library.  To me the existing mechanisms seem pretty good.  The most painful lack to me is a more approachable version of scala-tools.  Currently, if you make a Scala library, it's hard to get it to anyone unless they use Maven.  I would think a version of it could be made that is not based on Maven, at least not from a user's perspective.  The main issue would be finding someone to maintain the repository.  Such a person would need to kick out the packages that are permanently broken, and would ideally need to cut an occasional release of the distribution.


Lex

Hi Lex,

Thanks for sharing your experience. The points you raise are certainly
should be watched out for. In particular, the person(s) who care about
extensions should also be part of the trunk committer team, both to
ease migration and to avoid the rejection effect you have been seeing.

As to one project or several, I think both have their places. Work
might well start as several projects. Once it lands in extensions, it
will probably be scrutinized more widely, which is good. Also a
coherent trunk extension is important for users because they will then
have the assurance that pieces fit together (or are at least intended
to).

Cheers

On Nov 9, 2009, at 1:11 PM, Jorge Ortiz wrote:
> Lots of non-Maven tools can use Maven repositories. Notably, Ivy,
> Buildr, and sbt.

Fair enough, but quite a few people don't use any of these. It's a
large hurdle to ask someone to install one of these tools before they
can get access to a library.

Lex

What alternative are you suggesting?   It's actually somewhat trivial to use the maven-ant-tasks or ivy to automatically download the dependencies you need and then ignore them in the future.  You can still download the libraries from the maven repository as needed, as well.   I honestly don't see a huge hurdle for people to use a maven-formatted repository as I think the cost of using ivy/maven is about the same as the cost of downloading an individual library.  Could you elaborate on what these "quite a few people" do, and what/how you'd like to see this libraries distributed? 

- Josh




On Tue, Nov 10, 2009 at 3:19 PM, Lex Spoon <lex@lexspoon.org> wrote:

On Nov 9, 2009, at 1:11 PM, Jorge Ortiz wrote:

Lots of non-Maven tools can use Maven repositories. Notably, Ivy, Buildr, and sbt.

Fair enough, but quite a few people don't use any of these.  It's a large hurdle to ask someone to install one of these tools before they can get access to a library.

Lex

<30961e500911041114o7f5eca6apfb0cc0464dbf9e2a@mail.gmail.com> <9461d7d00911041137w82e422m541cc7b224031384@mail.gmail.com> <30961e500911041209h3dd204bbk867fbe373c30adf1@mail.gmail.com> <4D5B3F2B-358B-496F-A7BC-6C9CD15BD224@lexspoon.org> <22a410d00911091011u696015bbkc452400fccda2bb2@mail.gmail.com> <55b774930911101229p179ce1fdl1588b2817bc39c0b@mail.gmail.com> MIME-Version: 1.0 --_23526b8c-2dce-4a33-a02f-c4bf6c1ceb74_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you are mandating the use of some technology like Maven in order to down= load a library JAR and its dependencies=2C then I will not be using it=3B I= shouldn't have to learn some irrelevant orthogonal technology just to get = my hands on a library. The model chosen by spring is far better - a distrib= ution with bundled dependency JARs and a readme.txt file. Chris Date: Tue=2C 10 Nov 2009 15:29:18 -0500 Subject: Re: [scala-internals] Time for a new Scala extensions repository? From: joshua.suereth@gmail.com To: lex@lexspoon.org CC: jorge.ortiz@gmail.com=3B miles@milessabin.com=3B martin.odersky@epfl.ch= =3B mlists@juma.me.uk=3B scala-internals@listes.epfl.ch What alternative are you suggesting? It's actually somewhat trivial to us= e the maven-ant-tasks or ivy to automatically download the dependencies you= need and then ignore them in the future. You can still download the libra= ries from the maven repository as needed=2C as well. I honestly don't see= a huge hurdle for people to use a maven-formatted repository as I think th= e cost of using ivy/maven is about the same as the cost of downloading an i= ndividual library. Could you elaborate on what these "quite a few people" = do=2C and what/how you'd like to see this libraries distributed? =20 - Josh On Tue=2C Nov 10=2C 2009 at 3:19 PM=2C Lex Spoon wrote: On Nov 9=2C 2009=2C at 1:11 PM=2C Jorge Ortiz wrote: Lots of non-Maven tools can use Maven repositories. Notably=2C Ivy=2C Build= r=2C and sbt. Fair enough=2C but quite a few people don't use any of these. It's a large= hurdle to ask someone to install one of these tools before they can get ac= cess to a library. Lex =20 _________________________________________________________________ View your other email accounts from your Hotmail inbox. Add them now. http://clk.atdmt.com/UKM/go/186394592/direct/01/= --_23526b8c-2dce-4a33-a02f-c4bf6c1ceb74_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you are mandating the use of some technology like Maven in order to down= load a library JAR and its dependencies=2C then I will not be using it=3B I= shouldn't have to learn some irrelevant orthogonal technology just to get = my hands on a library. The model chosen by spring is far better - a distrib= ution with bundled dependency JARs and a readme.txt file.

Chris
<= br>Date: Tue=2C 10 Nov 2009 15:29:18 -0500
Subje= ct: Re: [scala-internals] Time for a new Scala extensions repository?
Fr= om: joshua.suereth@gmail.com
To: lex@lexspoon.org
CC: jorge.ortiz@gma= il.com=3B miles@milessabin.com=3B martin.odersky@epfl.ch=3B mlists@juma.me.= uk=3B scala-internals@listes.epfl.ch

What alternative are you sugges= ting?&nbsp=3B&nbsp=3B It's actually somewhat trivial to use the maven-ant-t= asks or ivy to automatically download the dependencies you need and then ig= nore them in the future.&nbsp=3B You can still download the libraries from = the maven repository as needed=2C as well.&nbsp=3B&nbsp=3B I honestly don't= see a huge hurdle for people to use a maven-formatted repository as I thin= k the cost of using ivy/maven is about the same as the cost of downloading = an individual library.&nbsp=3B Could you elaborate on what these "quite a f= ew people" do=2C and what/how you'd like to see this libraries distributed?= &nbsp=3B

- Josh




On Tue=2C Nov 1= 0=2C 2009 at 3:19 PM=2C Lex Spoon &lt=3Blex@lexspoon.org&gt=3B wrote:

On Nov 9=2C 2009=2C at 1:11 PM=2C Jorge Ortiz wrote:

Lots of non-Maven tools can use Maven repositories. Notably=2C Ivy=2C Build= r=2C and sbt.

Fair enough=2C but quite a few people don't use any of these. &nbsp=3BIt's = a large hurdle to ask someone to install one of these tools before they can= get access to a library.

Lex

View your other email= accounts from your Hotmail inbox. Add them now. = --_23526b8c-2dce-4a33-a02f-c4bf6c1ceb74_--

"better" in this context is highly subjective...

On Tue, Nov 10, 2009 at 10:03 PM, christopher marshall
wrote:
> If you are mandating the use of some technology like Maven in order to
> download a library JAR and its dependencies, then I will not be using it; I
> shouldn't have to learn some irrelevant orthogonal technology just to get my
> hands on a library. The model chosen by spring is far better - a
> distribution with bundled dependency JARs and a readme.txt file.
>
> Chris
>
> ________________________________
> Date: Tue, 10 Nov 2009 15:29:18 -0500
> Subject: Re: [scala-internals] Time for a new Scala extensions repository?
> From: joshua.suereth@gmail.com
> To: lex@lexspoon.org
> CC: jorge.ortiz@gmail.com; miles@milessabin.com; martin.odersky@epfl.ch;
> mlists@juma.me.uk; scala-internals@listes.epfl.ch
>
> What alternative are you suggesting?   It's actually somewhat trivial to use
> the maven-ant-tasks or ivy to automatically download the dependencies you
> need and then ignore them in the future.  You can still download the
> libraries from the maven repository as needed, as well.   I honestly don't
> see a huge hurdle for people to use a maven-formatted repository as I think
> the cost of using ivy/maven is about the same as the cost of downloading an
> individual library.  Could you elaborate on what these "quite a few people"
> do, and what/how you'd like to see this libraries distributed?
>
> - Josh
>
>
>
>
> On Tue, Nov 10, 2009 at 3:19 PM, Lex Spoon wrote:
>
> On Nov 9, 2009, at 1:11 PM, Jorge Ortiz wrote:
>
> Lots of non-Maven tools can use Maven repositories. Notably, Ivy, Buildr,
> and sbt.
>
> Fair enough, but quite a few people don't use any of these.  It's a large
> hurdle to ask someone to install one of these tools before they can get
> access to a library.
>
> Lex
>
>
>
> ________________________________
> View your other email accounts from your Hotmail inbox. Add them now.

No one is "mandating" anything. Maven has a convention for how to name and version jars and how to place them in folders and on http servers. This convention is brain-dead simple. It's also been adopted by enough other Java-land tools that I would call it a de-facto standard.

It's not rocket science and it's not fascism. But 1) enough people are using it, 2) it's already useful enough, and 3) it's easy enough to implement that it doesn't seem like a major hardship to ask new tools to follow the convention.

--j

On Tue, Nov 10, 2009 at 2:03 PM, christopher marshall <oxbow_lakes@hotmail.com> wrote:

If you are mandating the use of some technology like Maven in order to download a library JAR and its dependencies, then I will not be using it; I shouldn't have to learn some irrelevant orthogonal technology just to get my hands on a library. The model chosen by spring is far better - a distribution with bundled dependency JARs and a readme.txt file.

Chris

Date: Tue, 10 Nov 2009 15:29:18 -0500
Subject: Re: [scala-internals] Time for a new Scala extensions repository?
From: joshua.suereth@gmail.com
To: lex@lexspoon.org
CC: jorge.ortiz@gmail.com; miles@milessabin.com; martin.odersky@epfl.ch; mlists@juma.me.uk; scala-internals@listes.epfl.ch

What alternative are you suggesting?   It's actually somewhat trivial to use the maven-ant-tasks or ivy to automatically download the dependencies you need and then ignore them in the future.  You can still download the libraries from the maven repository as needed, as well.   I honestly don't see a huge hurdle for people to use a maven-formatted repository as I think the cost of using ivy/maven is about the same as the cost of downloading an individual library.  Could you elaborate on what these "quite a few people" do, and what/how you'd like to see this libraries distributed? 

- Josh




On Tue, Nov 10, 2009 at 3:19 PM, Lex Spoon <lex@lexspoon.org> wrote:

On Nov 9, 2009, at 1:11 PM, Jorge Ortiz wrote:

Lots of non-Maven tools can use Maven repositories. Notably, Ivy, Buildr, and sbt.

Fair enough, but quite a few people don't use any of these.  It's a large hurdle to ask someone to install one of these tools before they can get access to a library.

Lex

View your other email accounts from your Hotmail inbox. Add them now.

As with any operation that loses metadata, it's actually very trivial
to take a maven deployment and produce a zip containing the jar with
deps. Simply use the maven assembly plugin.

On the other hand, taking such a zip and then building appropriate
maven metadata involves extra manual effort. This is unavoidable for
those of us already operating within a Maven ecosystem.

For this reason, my vote falls squarely on the side of making Maven
the authoritative distribution mechanism.

On Tue, Nov 10, 2009 at 10:51 PM, Jorge Ortiz wrote:
> No one is "mandating" anything. Maven has a convention for how to name and
> version jars and how to place them in folders and on http servers. This
> convention is brain-dead simple. It's also been adopted by enough other
> Java-land tools that I would call it a de-facto standard.
>
> It's not rocket science and it's not fascism. But 1) enough people are using
> it, 2) it's already useful enough, and 3) it's easy enough to implement that
> it doesn't seem like a major hardship to ask new tools to follow the
> convention.
>
> --j
>
> On Tue, Nov 10, 2009 at 2:03 PM, christopher marshall
> wrote:
>>
>> If you are mandating the use of some technology like Maven in order to
>> download a library JAR and its dependencies, then I will not be using it; I
>> shouldn't have to learn some irrelevant orthogonal technology just to get my
>> hands on a library. The model chosen by spring is far better - a
>> distribution with bundled dependency JARs and a readme.txt file.
>>
>> Chris
>>
>> ________________________________
>> Date: Tue, 10 Nov 2009 15:29:18 -0500
>> Subject: Re: [scala-internals] Time for a new Scala extensions repository?
>> From: joshua.suereth@gmail.com
>> To: lex@lexspoon.org
>> CC: jorge.ortiz@gmail.com; miles@milessabin.com; martin.odersky@epfl.ch;
>> mlists@juma.me.uk; scala-internals@listes.epfl.ch
>>
>> What alternative are you suggesting?   It's actually somewhat trivial to
>> use the maven-ant-tasks or ivy to automatically download the dependencies
>> you need and then ignore them in the future.  You can still download the
>> libraries from the maven repository as needed, as well.   I honestly don't
>> see a huge hurdle for people to use a maven-formatted repository as I think
>> the cost of using ivy/maven is about the same as the cost of downloading an
>> individual library.  Could you elaborate on what these "quite a few people"
>> do, and what/how you'd like to see this libraries distributed?
>>
>> - Josh
>>
>>
>>
>>
>> On Tue, Nov 10, 2009 at 3:19 PM, Lex Spoon wrote:
>>
>> On Nov 9, 2009, at 1:11 PM, Jorge Ortiz wrote:
>>
>> Lots of non-Maven tools can use Maven repositories. Notably, Ivy, Buildr,
>> and sbt.
>>
>> Fair enough, but quite a few people don't use any of these.  It's a large
>> hurdle to ask someone to install one of these tools before they can get
>> access to a library.
>>
>> Lex
>>
>>
>>
>> ________________________________
>> View your other email accounts from your Hotmail inbox. Add them now.
>

If you'd rather download libraries the way spring works, I'm sure that could be supported.  However spring *also* supports maven repositories (it has several actually).   Spring is the main reason I learned maven, actually.   The only key here is that maven repositories are supported (for those using automated dependency management), not that they're the only way.  Github supports a file-release mechanism that could give you what you want.

I'm not sure why there is so much aversion/backlash to maven-repo automatic-dependency management.  Windows Update manager does this for you... YUM does this, apt-get does this....  Why are we adverse to seeing this in our build systems?   That's a discussion for another time.

- Josh


On Tue, Nov 10, 2009 at 5:03 PM, christopher marshall <oxbow_lakes@hotmail.com> wrote:

If you are mandating the use of some technology like Maven in order to download a library JAR and its dependencies, then I will not be using it; I shouldn't have to learn some irrelevant orthogonal technology just to get my hands on a library. The model chosen by spring is far better - a distribution with bundled dependency JARs and a readme.txt file.

Chris

Date: Tue, 10 Nov 2009 15:29:18 -0500
Subject: Re: [scala-internals] Time for a new Scala extensions repository?
From: joshua.suereth@gmail.com
To: lex@lexspoon.org
CC: jorge.ortiz@gmail.com; miles@milessabin.com; martin.odersky@epfl.ch; mlists@juma.me.uk; scala-internals@listes.epfl.ch

What alternative are you suggesting?   It's actually somewhat trivial to use the maven-ant-tasks or ivy to automatically download the dependencies you need and then ignore them in the future.  You can still download the libraries from the maven repository as needed, as well.   I honestly don't see a huge hurdle for people to use a maven-formatted repository as I think the cost of using ivy/maven is about the same as the cost of downloading an individual library.  Could you elaborate on what these "quite a few people" do, and what/how you'd like to see this libraries distributed? 

- Josh




On Tue, Nov 10, 2009 at 3:19 PM, Lex Spoon <lex@lexspoon.org> wrote:

On Nov 9, 2009, at 1:11 PM, Jorge Ortiz wrote:

Lots of non-Maven tools can use Maven repositories. Notably, Ivy, Buildr, and sbt.

Fair enough, but quite a few people don't use any of these.  It's a large hurdle to ask someone to install one of these tools before they can get access to a library.

Lex

View your other email accounts from your Hotmail inbox. Add them now.

Maybe I've got this wrong but I thought you were saying that: in order to discover the dependencies of a scala extensions library, I need to use Maven.

I can only speak from my own experience - Maven is NOT a de-facto standard. Pretty much anyone I know avoids it like the plague, either because they got fed up with getting cryptic error messages trying to do simple stuff in their builds or because they got majorly burnt in the Maven1->2 debacle.

Why not have the Maven build which you use generate a nice README which just lists the dependent JARs/versions for a given extensions library. You (and anyone who wants to) gets to use Maven and I get my nice list of required JARs.

Date: Tue, 10 Nov 2009 14:51:08 -0800
Subject: Re: [scala-internals] Time for a new Scala extensions repository?
From: jorge.ortiz@gmail.com
To: oxbow_lakes@hotmail.com
CC: joshua.suereth@gmail.com; lex@lexspoon.org; miles@milessabin.com; martin.odersky@epfl.ch; mlists@juma.me.uk; scala-internals@listes.epfl.ch

No one is "mandating" anything. Maven has a convention for how to name and version jars and how to place them in folders and on http servers. This convention is brain-dead simple. It's also been adopted by enough other Java-land tools that I would call it a de-facto standard.

It's not rocket science and it's not fascism. But 1) enough people are using it, 2) it's already useful enough, and 3) it's easy enough to implement that it doesn't seem like a major hardship to ask new tools to follow the convention.

--j

On Tue, Nov 10, 2009 at 2:03 PM, christopher marshall <oxbow_lakes@hotmail.com> wrote:

If you are mandating the use of some technology like Maven in order to download a library JAR and its dependencies, then I will not be using it; I shouldn't have to learn some irrelevant orthogonal technology just to get my hands on a library. The model chosen by spring is far better - a distribution with bundled dependency JARs and a readme.txt file.

Chris

Date: Tue, 10 Nov 2009 15:29:18 -0500
Subject: Re: [scala-internals] Time for a new Scala extensions repository?
From: joshua.suereth@gmail.com
To: lex@lexspoon.org
CC: jorge.ortiz@gmail.com; miles@milessabin.com; martin.odersky@epfl.ch; mlists@juma.me.uk; scala-internals@listes.epfl.ch

What alternative are you suggesting?   It's actually somewhat trivial to use the maven-ant-tasks or ivy to automatically download the dependencies you need and then ignore them in the future.  You can still download the libraries from the maven repository as needed, as well.   I honestly don't see a huge hurdle for people to use a maven-formatted repository as I think the cost of using ivy/maven is about the same as the cost of downloading an individual library.  Could you elaborate on what these "quite a few people" do, and what/how you'd like to see this libraries distributed? 

- Josh




On Tue, Nov 10, 2009 at 3:19 PM, Lex Spoon <lex@lexspoon.org> wrote:

On Nov 9, 2009, at 1:11 PM, Jorge Ortiz wrote:

Lots of non-Maven tools can use Maven repositories. Notably, Ivy, Buildr, and sbt.

Fair enough, but quite a few people don't use any of these.  It's a large hurdle to ask someone to install one of these tools before they can get access to a library.

Lex

View your other email accounts from your Hotmail inbox. Add them now.

View your other email accounts from your Hotmail inbox. Add them now.

On Wed, Nov 11, 2009 at 10:28 AM, christopher marshall
wrote:
> Maybe I've got this wrong but I thought you were saying that: in order to
> discover the dependencies of a scala extensions library, I need to use
> Maven.
>
> I can only speak from my own experience - Maven is NOT a de-facto standard.

Although maven-as-a-build-tool may not be a de-facto standard, I'm
pretty sure that maven-as-a-repository is...

> Pretty much anyone I know avoids it like the plague, either because they got
> fed up with getting cryptic error messages trying to do simple stuff in
> their builds or because they got majorly burnt in the Maven1->2 debacle.

I agree, Maven 1 way pretty weak, and you have my full sympathy if
experiences there have put you off for life. But Maven 2 truly is a
superior beast, and well worth your time to look at again.

> Why not have the Maven build which you use generate a nice README which just
> lists the dependent JARs/versions for a given extensions library. You (and
> anyone who wants to) gets to use Maven and I get my nice list of required
> JARs.
>

I guess the quick answer is that this requires human effort to read,
and to then find and download said jars.
Being inherently lazy in the manner of all good programmers, I prefer
to let the computer do as much of that work as possible.

> ________________________________
> Date: Tue, 10 Nov 2009 14:51:08 -0800
> Subject: Re: [scala-internals] Time for a new Scala extensions repository?
> From: jorge.ortiz@gmail.com
> To: oxbow_lakes@hotmail.com
> CC: joshua.suereth@gmail.com; lex@lexspoon.org; miles@milessabin.com;
> martin.odersky@epfl.ch; mlists@juma.me.uk; scala-internals@listes.epfl.ch
>
> No one is "mandating" anything. Maven has a convention for how to name and
> version jars and how to place them in folders and on http servers. This
> convention is brain-dead simple. It's also been adopted by enough other
> Java-land tools that I would call it a de-facto standard.
>
> It's not rocket science and it's not fascism. But 1) enough people are using
> it, 2) it's already useful enough, and 3) it's easy enough to implement that
> it doesn't seem like a major hardship to ask new tools to follow the
> convention.
>
> --j
>
> On Tue, Nov 10, 2009 at 2:03 PM, christopher marshall
> wrote:
>
> If you are mandating the use of some technology like Maven in order to
> download a library JAR and its dependencies, then I will not be using it; I
> shouldn't have to learn some irrelevant orthogonal technology just to get my
> hands on a library. The model chosen by spring is far better - a
> distribution with bundled dependency JARs and a readme.txt file.
>
> Chris
>
> ________________________________
> Date: Tue, 10 Nov 2009 15:29:18 -0500
> Subject: Re: [scala-internals] Time for a new Scala extensions repository?
> From: joshua.suereth@gmail.com
> To: lex@lexspoon.org
> CC: jorge.ortiz@gmail.com; miles@milessabin.com; martin.odersky@epfl.ch;
> mlists@juma.me.uk; scala-internals@listes.epfl.ch
>
> What alternative are you suggesting?   It's actually somewhat trivial to use
> the maven-ant-tasks or ivy to automatically download the dependencies you
> need and then ignore them in the future.  You can still download the
> libraries from the maven repository as needed, as well.   I honestly don't
> see a huge hurdle for people to use a maven-formatted repository as I think
> the cost of using ivy/maven is about the same as the cost of downloading an
> individual library.  Could you elaborate on what these "quite a few people"
> do, and what/how you'd like to see this libraries distributed?
>
> - Josh
>
>
>
>
> On Tue, Nov 10, 2009 at 3:19 PM, Lex Spoon wrote:
>
> On Nov 9, 2009, at 1:11 PM, Jorge Ortiz wrote:
>
> Lots of non-Maven tools can use Maven repositories. Notably, Ivy, Buildr,
> and sbt.
>
> Fair enough, but quite a few people don't use any of these.  It's a large
> hurdle to ask someone to install one of these tools before they can get
> access to a library.
>
> Lex
>
>
>
> ________________________________
> View your other email accounts from your Hotmail inbox. Add them now.
>
> ________________________________
> View your other email accounts from your Hotmail inbox. Add them now.

Perhaps this just calls for a tool that effectively runs mvn dependencies:tree on arbitrary packages from arbitrary maven repositories.  It could be written as a web site, except that I bet mischievous folks could abuse it to get the web server to run arbitrary code.

2009/11/11 Kevin Wright <kev.lee.wright@googlemail.com>

On Wed, Nov 11, 2009 at 10:28 AM, christopher marshall
<oxbow_lakes@hotmail.com> wrote:
> Maybe I've got this wrong but I thought you were saying that: in order to
> discover the dependencies of a scala extensions library, I need to use
> Maven.
>
> I can only speak from my own experience - Maven is NOT a de-facto standard.

Although maven-as-a-build-tool may not be a de-facto standard, I'm
pretty sure that maven-as-a-repository is...


> Pretty much anyone I know avoids it like the plague, either because they got
> fed up with getting cryptic error messages trying to do simple stuff in
> their builds or because they got majorly burnt in the Maven1->2 debacle.

I agree, Maven 1 way pretty weak, and you have my full sympathy if
experiences there have put you off for life.  But Maven 2 truly is a
superior beast, and well worth your time to look at again.


> Why not have the Maven build which you use generate a nice README which just
> lists the dependent JARs/versions for a given extensions library. You (and
> anyone who wants to) gets to use Maven and I get my nice list of required
> JARs.
>

I guess the quick answer is that this requires human effort to read,
and to then find and download said jars.
Being inherently lazy in the manner of all good programmers, I prefer
to let the computer do as much of that work as possible.


> ________________________________
> Date: Tue, 10 Nov 2009 14:51:08 -0800
> Subject: Re: [scala-internals] Time for a new Scala extensions repository?
> From: jorge.ortiz@gmail.com
> To: oxbow_lakes@hotmail.com
> CC: joshua.suereth@gmail.com; lex@lexspoon.org; miles@milessabin.com;
> martin.odersky@epfl.ch; mlists@juma.me.uk; scala-internals@listes.epfl.ch
>
> No one is "mandating" anything. Maven has a convention for how to name and
> version jars and how to place them in folders and on http servers. This
> convention is brain-dead simple. It's also been adopted by enough other
> Java-land tools that I would call it a de-facto standard.
>
> It's not rocket science and it's not fascism. But 1) enough people are using
> it, 2) it's already useful enough, and 3) it's easy enough to implement that
> it doesn't seem like a major hardship to ask new tools to follow the
> convention.
>
> --j
>
> On Tue, Nov 10, 2009 at 2:03 PM, christopher marshall
> <oxbow_lakes@hotmail.com> wrote:
>
> If you are mandating the use of some technology like Maven in order to
> download a library JAR and its dependencies, then I will not be using it; I
> shouldn't have to learn some irrelevant orthogonal technology just to get my
> hands on a library. The model chosen by spring is far better - a
> distribution with bundled dependency JARs and a readme.txt file.
>
> Chris
>
> ________________________________
> Date: Tue, 10 Nov 2009 15:29:18 -0500
> Subject: Re: [scala-internals] Time for a new Scala extensions repository?
> From: joshua.suereth@gmail.com
> To: lex@lexspoon.org
> CC: jorge.ortiz@gmail.com; miles@milessabin.com; martin.odersky@epfl.ch;
> mlists@juma.me.uk; scala-internals@listes.epfl.ch
>
> What alternative are you suggesting?   It's actually somewhat trivial to use
> the maven-ant-tasks or ivy to automatically download the dependencies you
> need and then ignore them in the future.  You can still download the
> libraries from the maven repository as needed, as well.   I honestly don't
> see a huge hurdle for people to use a maven-formatted repository as I think
> the cost of using ivy/maven is about the same as the cost of downloading an
> individual library.  Could you elaborate on what these "quite a few people"
> do, and what/how you'd like to see this libraries distributed?
>
> - Josh
>
>
>
>
> On Tue, Nov 10, 2009 at 3:19 PM, Lex Spoon <lex@lexspoon.org> wrote:
>
> On Nov 9, 2009, at 1:11 PM, Jorge Ortiz wrote:
>
> Lots of non-Maven tools can use Maven repositories. Notably, Ivy, Buildr,
> and sbt.
>
> Fair enough, but quite a few people don't use any of these.  It's a large
> hurdle to ask someone to install one of these tools before they can get
> access to a library.
>
> Lex
>
>
>
> ________________________________
> View your other email accounts from your Hotmail inbox. Add them now.
>
> ________________________________
> View your other email accounts from your Hotmail inbox. Add them now.

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@gmail.com
Google Wave: ricky.clarkson@googlewave.com

the maven assembly plugin:

http://maven.apache.org/plugins/maven-assembly-plugin/

has a pre-defined configuration for jar-with-dependencies

http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.ht...

As for generating that list? It's just a directory listing of the
assembled dependencies...

On Wed, Nov 11, 2009 at 10:46 AM, Ricky Clarkson
wrote:
> Perhaps this just calls for a tool that effectively runs mvn
> dependencies:tree on arbitrary packages from arbitrary maven repositories.
> It could be written as a web site, except that I bet mischievous folks could
> abuse it to get the web server to run arbitrary code.
>
> 2009/11/11 Kevin Wright
>>
>> On Wed, Nov 11, 2009 at 10:28 AM, christopher marshall
>> wrote:
>> > Maybe I've got this wrong but I thought you were saying that: in order
>> > to
>> > discover the dependencies of a scala extensions library, I need to use
>> > Maven.
>> >
>> > I can only speak from my own experience - Maven is NOT a de-facto
>> > standard.
>>
>> Although maven-as-a-build-tool may not be a de-facto standard, I'm
>> pretty sure that maven-as-a-repository is...
>>
>>
>> > Pretty much anyone I know avoids it like the plague, either because they
>> > got
>> > fed up with getting cryptic error messages trying to do simple stuff in
>> > their builds or because they got majorly burnt in the Maven1->2 debacle.
>>
>> I agree, Maven 1 way pretty weak, and you have my full sympathy if
>> experiences there have put you off for life.  But Maven 2 truly is a
>> superior beast, and well worth your time to look at again.
>>
>>
>> > Why not have the Maven build which you use generate a nice README which
>> > just
>> > lists the dependent JARs/versions for a given extensions library. You
>> > (and
>> > anyone who wants to) gets to use Maven and I get my nice list of
>> > required
>> > JARs.
>> >
>>
>> I guess the quick answer is that this requires human effort to read,
>> and to then find and download said jars.
>> Being inherently lazy in the manner of all good programmers, I prefer
>> to let the computer do as much of that work as possible.
>>
>>
>> > ________________________________
>> > Date: Tue, 10 Nov 2009 14:51:08 -0800
>> > Subject: Re: [scala-internals] Time for a new Scala extensions
>> > repository?
>> > From: jorge.ortiz@gmail.com
>> > To: oxbow_lakes@hotmail.com
>> > CC: joshua.suereth@gmail.com; lex@lexspoon.org; miles@milessabin.com;
>> > martin.odersky@epfl.ch; mlists@juma.me.uk;
>> > scala-internals@listes.epfl.ch
>> >
>> > No one is "mandating" anything. Maven has a convention for how to name
>> > and
>> > version jars and how to place them in folders and on http servers. This
>> > convention is brain-dead simple. It's also been adopted by enough other
>> > Java-land tools that I would call it a de-facto standard.
>> >
>> > It's not rocket science and it's not fascism. But 1) enough people are
>> > using
>> > it, 2) it's already useful enough, and 3) it's easy enough to implement
>> > that
>> > it doesn't seem like a major hardship to ask new tools to follow the
>> > convention.
>> >
>> > --j
>> >
>> > On Tue, Nov 10, 2009 at 2:03 PM, christopher marshall
>> > wrote:
>> >
>> > If you are mandating the use of some technology like Maven in order to
>> > download a library JAR and its dependencies, then I will not be using
>> > it; I
>> > shouldn't have to learn some irrelevant orthogonal technology just to
>> > get my
>> > hands on a library. The model chosen by spring is far better - a
>> > distribution with bundled dependency JARs and a readme.txt file.
>> >
>> > Chris
>> >
>> > ________________________________
>> > Date: Tue, 10 Nov 2009 15:29:18 -0500
>> > Subject: Re: [scala-internals] Time for a new Scala extensions
>> > repository?
>> > From: joshua.suereth@gmail.com
>> > To: lex@lexspoon.org
>> > CC: jorge.ortiz@gmail.com; miles@milessabin.com; martin.odersky@epfl.ch;
>> > mlists@juma.me.uk; scala-internals@listes.epfl.ch
>> >
>> > What alternative are you suggesting?   It's actually somewhat trivial to
>> > use
>> > the maven-ant-tasks or ivy to automatically download the dependencies
>> > you
>> > need and then ignore them in the future.  You can still download the
>> > libraries from the maven repository as needed, as well.   I honestly
>> > don't
>> > see a huge hurdle for people to use a maven-formatted repository as I
>> > think
>> > the cost of using ivy/maven is about the same as the cost of downloading
>> > an
>> > individual library.  Could you elaborate on what these "quite a few
>> > people"
>> > do, and what/how you'd like to see this libraries distributed?
>> >
>> > - Josh
>> >
>> >
>> >
>> >
>> > On Tue, Nov 10, 2009 at 3:19 PM, Lex Spoon wrote:
>> >
>> > On Nov 9, 2009, at 1:11 PM, Jorge Ortiz wrote:
>> >
>> > Lots of non-Maven tools can use Maven repositories. Notably, Ivy,
>> > Buildr,
>> > and sbt.
>> >
>> > Fair enough, but quite a few people don't use any of these.  It's a
>> > large
>> > hurdle to ask someone to install one of these tools before they can get
>> > access to a library.
>> >
>> > Lex
>> >
>> >
>> >
>> > ________________________________
>> > View your other email accounts from your Hotmail inbox. Add them now.
>> >
>> > ________________________________
>> > View your other email accounts from your Hotmail inbox. Add them now.
>
>
>
> --
> Ricky Clarkson
> Java and Scala Programmer, AD Holdings
> +44 1565 770804
> Skype: ricky_clarkson
> Google Talk: ricky.clarkson@gmail.com
> Google Wave: ricky.clarkson@googlewave.com
>

Let's clarify then:
A maven repository does not require the use of maven.  Ant, SBT, and others can pull artifacts just fine.
A maven repository is merely the style with which you make libraries available such that dependencies can be shared between them, and metadata is included.
I agree maven can be painful, but maven2 has come a long way.  Also, SBT makes more sense for serious scala projects.
- Josh

Sent from my iPhone
On Nov 11, 2009, at 5:28 AM, christopher marshall <oxbow_lakes@hotmail.com> wrote:

Maybe I've got this wrong but I thought you were saying that: in order to discover the dependencies of a scala extensions library, I need to use Maven.

I can only speak from my own experience - Maven is NOT a de-facto standard. Pretty much anyone I know avoids it like the plague, either because they got fed up with getting cryptic error messages trying to do simple stuff in their builds or because they got majorly burnt in the Maven1->2 debacle.

Why not have the Maven build which you use generate a nice README which just lists the dependent JARs/versions for a given extensions library. You (and anyone who wants to) gets to use Maven and I get my nice list of required JARs.

Date: Tue, 10 Nov 2009 14:51:08 -0800
Subject: Re: [scala-internals] Time for a new Scala extensions repository?
From: (jorge [dot] ortiz [at] gmail [dot] com
To: (oxbow_lakes [at] hotmail [dot] com
CC: joshua.suereth@gmail.com; lex@lexspoon.org; miles@milessabin.com; martin.odersky@epfl.ch; mlists@juma.me.uk; (scala-internals [at] listes [dot] epfl [dot] ch

No one is "mandating" anything. Maven has a convention for how to name and version jars and how to place them in folders and on http servers. This convention is brain-dead simple. It's also been adopted by enough other Java-land tools that I would call it a de-facto standard.

It's not rocket science and it's not fascism. But 1) enough people are using it, 2) it's already useful enough, and 3) it's easy enough to implement that it doesn't seem like a major hardship to ask new tools to follow the convention.

--j

On Tue, Nov 10, 2009 at 2:03 PM, christopher marshall < (oxbow_lakes [at] hotmail [dot] com> wrote:

If you are mandating the use of some technology like Maven in order to download a library JAR and its dependencies, then I will not be using it; I shouldn't have to learn some irrelevant orthogonal technology just to get my hands on a library. The model chosen by spring is far better - a distribution with bundled dependency JARs and a readme.txt file.

Chris

Date: Tue, 10 Nov 2009 15:29:18 -0500
Subject: Re: [scala-internals] Time for a new Scala extensions repository?
From: (joshua [dot] suereth [at] gmail [dot] com
To: (lex [at] lexspoon [dot] org
CC: (jorge [dot] ortiz [at] gmail [dot] com; (miles [at] milessabin [dot] com; (martin [dot] odersky [at] epfl [dot] ch; (mlists [at] juma [dot] me [dot] uk; (scala-internals [at] listes [dot] epfl [dot] ch

What alternative are you suggesting?   It's actually somewhat trivial to use the maven-ant-tasks or ivy to automatically download the dependencies you need and then ignore them in the future.  You can still download the libraries from the maven repository as needed, as well.   I honestly don't see a huge hurdle for people to use a maven-formatted repository as I think the cost of using ivy/maven is about the same as the cost of downloading an individual library.  Could you elaborate on what these "quite a few people" do, and what/how you'd like to see this libraries distributed? 

- Josh




On Tue, Nov 10, 2009 at 3:19 PM, Lex Spoon < (lex [at] lexspoon [dot] org> wrote:

On Nov 9, 2009, at 1:11 PM, Jorge Ortiz wrote:

Lots of non-Maven tools can use Maven repositories. Notably, Ivy, Buildr, and sbt.

Fair enough, but quite a few people don't use any of these.  It's a large hurdle to ask someone to install one of these tools before they can get access to a library.

Lex

View your other email accounts from your Hotmail inbox. Add them now.

View your other email accounts from your Hotmail inbox. Add them now.

On Nov 10, 2009, at 5:03 PM, christopher marshall wrote:

If you are mandating the use of some technology like Maven in order to download a library JAR and its dependencies, then I will not be using it; I shouldn't have to learn some irrelevant orthogonal technology just to get my hands on a library. The model chosen by spring is far better - a distribution with bundled dependency JARs and a readme.txt file.

Yes.  There's a real disconnect here.  I can't speak for every tool in the list that was given earlier, but Maven at least is decidedly non-trivial to get set up with.    Yet, people who use it regularly don't seem to believe it.
The alternative I would suggest would be something based on a web site.  You go to the web site and can get a list of packages available.  Click on a package, and you can get a readme, a link to the package's home page, the jar to download, and a list of the dependencies you need.  Ideally, yes, you could also download all the transitive dependencies, too, with one click.  This could all be driven by a cron job that scans a Maven repository.

Lex

http://nexus.scala-tools.org/

I think it's in the plans to provide that kind of functionality in nexus, but we don't have the "pro" version.


- Josh

On Thu, Nov 12, 2009 at 3:33 PM, Lex Spoon <lex@lexspoon.org> wrote:

On Nov 10, 2009, at 5:03 PM, christopher marshall wrote:

If you are mandating the use of some technology like Maven in order to download a library JAR and its dependencies, then I will not be using it; I shouldn't have to learn some irrelevant orthogonal technology just to get my hands on a library. The model chosen by spring is far better - a distribution with bundled dependency JARs and a readme.txt file.

Yes.  There's a real disconnect here.  I can't speak for every tool in the list that was given earlier, but Maven at least is decidedly non-trivial to get set up with.    Yet, people who use it regularly don't seem to believe it.
The alternative I would suggest would be something based on a web site.  You go to the web site and can get a list of packages available.  Click on a package, and you can get a readme, a link to the package's home page, the jar to download, and a list of the dependencies you need.  Ideally, yes, you could also download all the transitive dependencies, too, with one click.  This could all be driven by a cron job that scans a Maven repository.

Lex

You can configure a maven build to generate a secondary artefact and
deploy to any maven repo, nexus pro not required :)

I guess a bigger problem here is when building with ant. Given that,
a better idea might be a second XXX-with-dependencies maven project,
using maven:assembly and with a zip file as the primary artefact type.

On Thu, Nov 12, 2009 at 9:13 PM, Josh Suereth wrote:
> http://nexus.scala-tools.org/
>
> I think it's in the plans to provide that kind of functionality in nexus,
> but we don't have the "pro" version.
>
>
> - Josh
>
> On Thu, Nov 12, 2009 at 3:33 PM, Lex Spoon wrote:
>>
>> On Nov 10, 2009, at 5:03 PM, christopher marshall wrote:
>>
>> If you are mandating the use of some technology like Maven in order to
>> download a library JAR and its dependencies, then I will not be using it; I
>> shouldn't have to learn some irrelevant orthogonal technology just to get my
>> hands on a library. The model chosen by spring is far better - a
>> distribution with bundled dependency JARs and a readme.txt file.
>>
>> Yes.  There's a real disconnect here.  I can't speak for every tool in the
>> list that was given earlier, but Maven at least is decidedly non-trivial to
>> get set up with.    Yet, people who use it regularly don't seem to believe
>> it.
>> The alternative I would suggest would be something based on a web site.
>>  You go to the web site and can get a list of packages available.  Click on
>> a package, and you can get a readme, a link to the package's home page, the
>> jar to download, and a list of the dependencies you need.  Ideally, yes, you
>> could also download all the transitive dependencies, too, with one click.
>>  This could all be driven by a cron job that scans a Maven repository.
>>
>> Lex
>
>

On Fri, Nov 13, 2009 at 7:33 AM, Lex Spoon wrote:
> On Nov 10, 2009, at 5:03 PM, christopher marshall wrote:
>
> If you are mandating the use of some technology like Maven in order to
> download a library JAR and its dependencies, then I will not be using it; I
> shouldn't have to learn some irrelevant orthogonal technology just to get my
> hands on a library. The model chosen by spring is far better - a
> distribution with bundled dependency JARs and a readme.txt file.
>
> The alternative I would suggest would be something based on a web site.  You
> go to the web site and can get a list of packages available.  Click on a
> package, and you can get a readme, a link to the package's home page, the
> jar to download, and a list of the dependencies you need.  Ideally, yes, you
> could also download all the transitive dependencies, too, with one click.
>  This could all be driven by a cron job that scans a Maven repository.

Maven repos are websites and you can get a list of all packages
available using a web browser.

The POM xml file, also on the site, basically contains the information
you describe above. Admittedly, it is optimised for computer-, not
human-, consumption, but it is human-readable, and that's a fair
default as computers do and certainly will in future do more library
downloading than humans.

As has been mentioned, what is not readily available, and would be
very useful, is a way for any user, to convert a POM into an archive
file containing the associated artefact and all its dependencies. I
think the ideal architecture would be as a Java webstart GUI
application. Ie, the building of the archive is done on the users
machine and with their bandwidth and resources. Thats gets around the
resourcing issues Ricky mentioned earlier that would beset a
cloud-based version of the tool.

Ideally, a link to launch such an application could be included in
Maven itself and be made available for any standard maven repo.

-Ben