Re: Sbaz & artifact versioning

If you're talking about packaging things for the jvm, I don't see why the "package management portion of maven" (now called mercurial) is insufficient.  I do realize that if you want to distribute more than jar files that wind up on the classpath, you run into issues, so an alternative for .NET is required (I forget how NMaven worked).

Anyway, from what I can tell, sbaz is trying to buy the power of a linux package (like rpm or deb) with the cross-platform-ness of java.  I know I personally don't use it,  because I'm using maven heavily at work, and it just makes sense to continue to do so with scala.  Also, people understand maven at work, and adding scala is trivial.  Teaching people sbaz would be another layer of things to learn before scala is accepted. 

I'm interested to see what folks who don't use the maven repositories/packages do for managing their scala versions.

-Josh

On Fri, Feb 20, 2009 at 7:39 PM, pi song <pi.songs@gmail.com> wrote:

Ruby has gems and python has eggs. At the end of the day when the language grows, you will at some point need a package manager anyway.  Maven is a good candidate but it is too specific to java packages. 
I just wonder why sbaz is not being used. Possibly because there ain't so many scala packages available yet?

Pi Song

On Sat, Feb 21, 2009 at 1:08 AM, Chris Twiner <chris.twiner@gmail.com> wrote:

I'd also recommend Ivy for pure dependency management.

On Fri, Feb 20, 2009 at 2:46 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:
> James Matlik was doing some work into sbaz.  I  know he left a lot of design
> notes/possible enhancements here:
> http://code.google.com/p/esmi/wiki/SbazDesignNotes.  I haven't been as
> helpful as I originally intended with sbaz, but I'm unsure where it stand
> currently.  James would be the best person at this point (or Lex Spoon).
>
>
> As an aside, if you want artifact versioning and transitive package
> dependencies... there's always the maven-ecosystem (if not maven itself)!
>
> -Josh
>
> On Fri, Feb 20, 2009 at 8:27 AM, Ricky Clarkson <ricky.clarkson@gmail.com>
> wrote:
>>
>> Perhaps I'm jumping to conclusions, but it seems to me that sbaz is pretty
>> much unused.
>>
>> 2009/2/20 pi song <pi.songs@gmail.com>
>>>
>>> Hi,
>>> Does sbaz support artifact versioning? How about transitive package
>>> dependencies?
>>> Pi Song
>
>

Then scala is being treated as an extension of Java rather than being itself (which is true in practice)

On Sat, Feb 21, 2009 at 11:59 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:

If you're talking about packaging things for the jvm, I don't see why the "package management portion of maven" (now called mercurial) is insufficient.  I do realize that if you want to distribute more than jar files that wind up on the classpath, you run into issues, so an alternative for .NET is required (I forget how NMaven worked).

Anyway, from what I can tell, sbaz is trying to buy the power of a linux package (like rpm or deb) with the cross-platform-ness of java.  I know I personally don't use it,  because I'm using maven heavily at work, and it just makes sense to continue to do so with scala.  Also, people understand maven at work, and adding scala is trivial.  Teaching people sbaz would be another layer of things to learn before scala is accepted. 

I'm interested to see what folks who don't use the maven repositories/packages do for managing their scala versions.

-Josh

On Fri, Feb 20, 2009 at 7:39 PM, pi song <pi.songs@gmail.com> wrote:

Ruby has gems and python has eggs. At the end of the day when the language grows, you will at some point need a package manager anyway.  Maven is a good candidate but it is too specific to java packages. 
I just wonder why sbaz is not being used. Possibly because there ain't so many scala packages available yet?

Pi Song

On Sat, Feb 21, 2009 at 1:08 AM, Chris Twiner <chris.twiner@gmail.com> wrote:

I'd also recommend Ivy for pure dependency management.

On Fri, Feb 20, 2009 at 2:46 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:
> James Matlik was doing some work into sbaz.  I  know he left a lot of design
> notes/possible enhancements here:
> http://code.google.com/p/esmi/wiki/SbazDesignNotes.  I haven't been as
> helpful as I originally intended with sbaz, but I'm unsure where it stand
> currently.  James would be the best person at this point (or Lex Spoon).
>
>
> As an aside, if you want artifact versioning and transitive package
> dependencies... there's always the maven-ecosystem (if not maven itself)!
>
> -Josh
>
> On Fri, Feb 20, 2009 at 8:27 AM, Ricky Clarkson <ricky.clarkson@gmail.com>
> wrote:
>>
>> Perhaps I'm jumping to conclusions, but it seems to me that sbaz is pretty
>> much unused.
>>
>> 2009/2/20 pi song <pi.songs@gmail.com>
>>>
>>> Hi,
>>> Does sbaz support artifact versioning? How about transitive package
>>> dependencies?
>>> Pi Song
>
>

I don't see it as an extension of java, more as a member of the JVM.  I see maven packaging being kept up-to-date with JVM packaging standards (hopefully when project-jigsaw is complete).

I believe as Scala lives in many worlds, It might be ok to be "all things to all people" in the short term.  Scala is still its own beast, but it lets the JVM handle matters of packaging and runtime-visibilities (classpaths).   If this were to change, then of course, maven would no longer be suitable.  However, I think it would also be a lot of work on EPFL's part to make that happen, especially after they spent a lot of time *ensuring* tight integration with Java (on the JVM).  I think perhaps scala is taking the approach where it integrates tightly with existing infrastructure until it has enough sway to define what that infrastructure should be.

Also, this discussion should probably be moved to scala-debate.   Are you a member of that list as well?

-Josh

On Fri, Feb 20, 2009 at 8:09 PM, pi song <pi.songs@gmail.com> wrote:

Then scala is being treated as an extension of Java rather than being itself (which is true in practice)

On Sat, Feb 21, 2009 at 11:59 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:

If you're talking about packaging things for the jvm, I don't see why the "package management portion of maven" (now called mercurial) is insufficient.  I do realize that if you want to distribute more than jar files that wind up on the classpath, you run into issues, so an alternative for .NET is required (I forget how NMaven worked).

Anyway, from what I can tell, sbaz is trying to buy the power of a linux package (like rpm or deb) with the cross-platform-ness of java.  I know I personally don't use it,  because I'm using maven heavily at work, and it just makes sense to continue to do so with scala.  Also, people understand maven at work, and adding scala is trivial.  Teaching people sbaz would be another layer of things to learn before scala is accepted. 

I'm interested to see what folks who don't use the maven repositories/packages do for managing their scala versions.

-Josh

On Fri, Feb 20, 2009 at 7:39 PM, pi song <pi.songs@gmail.com> wrote:

Ruby has gems and python has eggs. At the end of the day when the language grows, you will at some point need a package manager anyway.  Maven is a good candidate but it is too specific to java packages. 
I just wonder why sbaz is not being used. Possibly because there ain't so many scala packages available yet?

Pi Song

On Sat, Feb 21, 2009 at 1:08 AM, Chris Twiner <chris.twiner@gmail.com> wrote:

I'd also recommend Ivy for pure dependency management.

On Fri, Feb 20, 2009 at 2:46 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:
> James Matlik was doing some work into sbaz.  I  know he left a lot of design
> notes/possible enhancements here:
> http://code.google.com/p/esmi/wiki/SbazDesignNotes.  I haven't been as
> helpful as I originally intended with sbaz, but I'm unsure where it stand
> currently.  James would be the best person at this point (or Lex Spoon).
>
>
> As an aside, if you want artifact versioning and transitive package
> dependencies... there's always the maven-ecosystem (if not maven itself)!
>
> -Josh
>
> On Fri, Feb 20, 2009 at 8:27 AM, Ricky Clarkson <ricky.clarkson@gmail.com>
> wrote:
>>
>> Perhaps I'm jumping to conclusions, but it seems to me that sbaz is pretty
>> much unused.
>>
>> 2009/2/20 pi song <pi.songs@gmail.com>
>>>
>>> Hi,
>>> Does sbaz support artifact versioning? How about transitive package
>>> dependencies?
>>> Pi Song
>
>

That sounds right. BTW,  here is a forward to scala-debate just in case other people want to share opinions. The topic is "Does scala deserve its own infrastructure like build tools, package manager, etc.. ?"

Pi Song

On Sat, Feb 21, 2009 at 1:11 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

I don't see it as an extension of java, more as a member of the JVM.  I see maven packaging being kept up-to-date with JVM packaging standards (hopefully when project-jigsaw is complete).

I believe as Scala lives in many worlds, It might be ok to be "all things to all people" in the short term.  Scala is still its own beast, but it lets the JVM handle matters of packaging and runtime-visibilities (classpaths).   If this were to change, then of course, maven would no longer be suitable.  However, I think it would also be a lot of work on EPFL's part to make that happen, especially after they spent a lot of time *ensuring* tight integration with Java (on the JVM).  I think perhaps scala is taking the approach where it integrates tightly with existing infrastructure until it has enough sway to define what that infrastructure should be.

Also, this discussion should probably be moved to scala-debate.   Are you a member of that list as well?

-Josh

On Fri, Feb 20, 2009 at 8:09 PM, pi song <pi.songs@gmail.com> wrote:

Then scala is being treated as an extension of Java rather than being itself (which is true in practice)

On Sat, Feb 21, 2009 at 11:59 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:

If you're talking about packaging things for the jvm, I don't see why the "package management portion of maven" (now called mercurial) is insufficient.  I do realize that if you want to distribute more than jar files that wind up on the classpath, you run into issues, so an alternative for .NET is required (I forget how NMaven worked).

Anyway, from what I can tell, sbaz is trying to buy the power of a linux package (like rpm or deb) with the cross-platform-ness of java.  I know I personally don't use it,  because I'm using maven heavily at work, and it just makes sense to continue to do so with scala.  Also, people understand maven at work, and adding scala is trivial.  Teaching people sbaz would be another layer of things to learn before scala is accepted. 

I'm interested to see what folks who don't use the maven repositories/packages do for managing their scala versions.

-Josh

On Fri, Feb 20, 2009 at 7:39 PM, pi song <pi.songs@gmail.com> wrote:

Ruby has gems and python has eggs. At the end of the day when the language grows, you will at some point need a package manager anyway.  Maven is a good candidate but it is too specific to java packages. 
I just wonder why sbaz is not being used. Possibly because there ain't so many scala packages available yet?

Pi Song

On Sat, Feb 21, 2009 at 1:08 AM, Chris Twiner <chris.twiner@gmail.com> wrote:

I'd also recommend Ivy for pure dependency management.

On Fri, Feb 20, 2009 at 2:46 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:
> James Matlik was doing some work into sbaz.  I  know he left a lot of design
> notes/possible enhancements here:
> http://code.google.com/p/esmi/wiki/SbazDesignNotes.  I haven't been as
> helpful as I originally intended with sbaz, but I'm unsure where it stand
> currently.  James would be the best person at this point (or Lex Spoon).
>
>
> As an aside, if you want artifact versioning and transitive package
> dependencies... there's always the maven-ecosystem (if not maven itself)!
>
> -Josh
>
> On Fri, Feb 20, 2009 at 8:27 AM, Ricky Clarkson <ricky.clarkson@gmail.com>
> wrote:
>>
>> Perhaps I'm jumping to conclusions, but it seems to me that sbaz is pretty
>> much unused.
>>
>> 2009/2/20 pi song <pi.songs@gmail.com>
>>>
>>> Hi,
>>> Does sbaz support artifact versioning? How about transitive package
>>> dependencies?
>>> Pi Song
>
>

pi song wrote:
> Ruby has gems and python has eggs. At the end of the day when the
> language grows, you will at some point need a package manager anyway.
> Maven is a good candidate but it is too specific to java packages.
"Languages" dont need package managers - ecosystems of *compatible
software* need package managers. In the past, languages tended to be
less interoperable with other languages, so language <=> ecosystem, but
no longer. The rise and rise of both the JVM and .NET shows that there
is tremendous value in agreeing upon precise standards for the runtime
execution, packaging and metadata formats of software.

We have a reasonable, extensible and widely used packaging for the JVM,
called the Jar file. OSGi (which converts Jar to a Bundle and declares
dependencies simply by including metadata in the Jar's manifest)
demonstrates how the Jar format can be usefully extended in practice.

You mention that Ruby has Gems, but even Ruby is being assimilated into
the JVM-Borg. In the last 8 months or so, Ive worked on a commercial
project involving Rails on JRuby on Tomcat on the JVM. So it uses a
slightly awkward mixture of Gem- and Jar- packaged components/libraries.
It would have been neater if we'd had one consistent packaging format.
>
> I just wonder why sbaz is not being used. Possibly because there ain't
> so many scala packages available yet?
IMHO, it because there's systems already available many people find more
Familiar, Better or more Compatible: Jars for packaging, Maven for
develop-time management of projects, versioning and dependencies, and
OSGi for run-time management of versioning and dependencies. While far
from perfect, these already enable a vast number of component -producers
and -consumers across the JVM ecosystem to share and reuse software.

-Ben

Unfortunately, shortly after assuming the sbaz maintainer role, events at work led to less free time for me to spend on sbaz and Scala in general.  I have, however, filled many a commute to and from work thinking about the direction sbaz should take.

I am struggling with the fact that there are so many other established tools that target the same problem domain as sbaz, which Ben has pointed out well.  Maven strongly satisfies the needs of developers (despite my personal aversion to it), and there is clearly momentum in the Scala community behind it.  For distributing end products, I do not know how well Maven works or how wide spread it is used for such a task.  OSGi (and tools built on top of it) satisfies this task nicely due to the strong version management and support for zero/minimal down time updates.

For sbaz to be of much value, it has to provide something the other existing solutions don't already do well.  We've talked about adding features to sbaz to support Maven repositories, which I still believe to be a good idea (or more accurately, any URL accessible archive).  I just don't think it makes sense to target the same use cases that Maven does so well.  This is particularly true when their approaches to dependency resolution differ (sbaz generally tries to get the most recent version while Maven tries to accurately version all dependencies).  Given the present "fragility" of Scala code, in regard to implementing traits across dependencies, I've considered deploying source packages that are compiled and optionally tested on install, which could then be used to build the binary package universe.  But, this approach requires dedicated package maintainers, which leads to stale/orphaned packages and high maintenance overhead.  This also flies in the face of Maven repository compatibility.

As mentioned earlier, sbaz strives to mimic the open source package management tools like apt, so it doesn't assume the deployed packages align to any specific technology, unlike Maven and OSGi.  It is feasible that sbaz could be used to deploy and upgrade entire web environments.  It could include Apache, JBoss, optional packages of WARs for selection, environment specific configurations (dev, QA, Prod, etc.), even the database, schema, test data, and so on.  The same is true for desktop applications, and if the install has been configured well, uninstalling would consist of simply deleting the sbaz working directory.  This has been where my thoughts of sbaz have been turning recently.  It could provide a slick mechanism for distributing non-trivial examples (e.g. different flavors of lift deployments including integration with legacy JEE complexities, sandbox environments for experimental code...) with no more requirements than a full Scala distribution install and a few console commands.

Unfortunately, I do not use Scala or sbaz in my day to day work.  It is more a hobby and exercise in self growth, and is prioritized as such.  I stepped up as the sbaz maintainer because I was interested in contributing and no one else volunteered.  I'm hoping that in the next few months I'll be able to get back to this and have something to show for it.


On Sat, Feb 21, 2009 at 6:14 AM, Ben Hutchison <ben@playscapegames.com> wrote:

pi song wrote:

Ruby has gems and python has eggs. At the end of the day when the language grows, you will at some point need a package manager anyway.  Maven is a good candidate but it is too specific to java packages.

"Languages" dont need package managers - ecosystems of *compatible software* need package managers. In the past, languages tended to be less interoperable with other languages, so language <=> ecosystem, but no longer. The rise and rise of both the JVM and .NET shows that there is tremendous value in agreeing upon precise standards for the runtime execution, packaging and metadata formats of software.

We have a reasonable, extensible and widely used packaging for the JVM, called the Jar file. OSGi (which converts Jar to a Bundle and declares dependencies simply by including metadata in the Jar's manifest) demonstrates how the Jar format can be usefully extended in practice.

You mention that Ruby has Gems, but even Ruby is being assimilated into the JVM-Borg. In the last 8 months or so, Ive worked on a commercial project involving Rails on JRuby on Tomcat on the JVM. So it uses a slightly awkward mixture of Gem- and Jar- packaged components/libraries. It would have been neater if we'd had one consistent packaging format.

I just wonder why sbaz is not being used. Possibly because there ain't so many scala packages available yet?

IMHO, it because there's systems already available many people find more Familiar, Better or more Compatible: Jars for packaging, Maven for develop-time management of projects, versioning and dependencies, and OSGi for run-time management of versioning and dependencies. While far from perfect, these already enable a vast number of component -producers and -consumers across the JVM ecosystem to share and reuse software.

-Ben