Call for maintainers

[Wille Faler]

Hi,

This e-mail has been a long time coming - and apologies for my absence from this list as of late, I have been swamped with other work.

I started Bowler about 2 years ago as a means to delve deeper into Scala by writing something a little bit more re-usable. My Scala skills have come on in leaps and bounds since, partly thanks to the problems I had to solve with Bowler, and partly due to client work I've also done in that time.

However, Bowler has unfortunately not kept up - many early design decisions hold it back, such as the pervasive use of classes instead of traits, call it naivety and the fact that at the time, I didn't know a fraction of what I've learned over the last two years about Scala.

There are also quite a few "Java smells" in the code that I am not entirely happy with.

Combined with a lack of time on my behalf means that I am looking to someone (if anyone is interested) to take over the reigns of Bowler, should they want to, otherwise I fear that it will go relatively unsupported, as I have neither the time nor motivation given some of my early naive decisions that I've later come to regret. Bowler has been a great learning experience, but unfortunately I have not been able to keep the framework up-to-date with my learning.

That being said, I think Scala has two main styles that can be used:

- a "better Java"

- a "Haskell light for the JVM"

For those looking for a Scala web framework that falls into the "Better Java" camp, I think Bowler is still a valid choice. And I'm still relatively proud of the opinionated style of Bowler, such as the ideas around being Resource oriented in rendering rather than trying to fork off rendering of JSON and HTML views into different versions/branches. 

Furthermore, despite its warts and design decisions I'm less happy with with the benefit of hindsight, new knowledge and experience, Bowler is a pretty mature framework, it does what it says on the tin and has very few defects that I'm aware of. If you can navigate around its warts (which you can quite easily), it still has a lot of miles in it.

Personally, I've migrated over the last two years towards the Functional Programming style of Scala, and Bowler simply doesn't sit very well in it, and the warts are too many for me. If I were to use a framework personally today, I'd be inclined to use Unfiltered with Lift JSON and Scalate, or possibly Play2 (which I'm not too familiar with).

I will not be making any further releases of Bowler and I will not make any major effort to bring it up to Scala 2.10, but if someone would like to take over the reigns and fork it, nothing would make me happier - after all I have easily spent several hundred hours of free labour on it, and would like to see at least the applications out there using it survive for as long as possible.

Kind Regards

Wille Faler

[Scott Morrison]

Hi Wille,

I'd been suspecting this was on the horizon!

Any chance that you could update/correct the build instructions on the main page? If I were actually able to compile from source I'd probably put in the effort to get it running on 2.10, at least.

best,
scott

[Ross A. Baker]

Bowler is built on an old version of Scalatra. I don't personally use Bowler, but Scalatra remains under active development. We on the Scalatra team are happy to help if anyone wants to upgrade the base or discuss any Bowlerisms that make sense being pushed down.

[Wille Faler]

What problems are you having? You need sbt 0.7.x, so the newer sbt versions won't work.

[Wille Faler]

Second that, Scalatra is probably a fairly pain-free migration path as Bowler is basically Scalatra + Scalate + Lift-JSON with some glue in between.

[Scott Morrison]

Ah, okay, I'd thought that later versions of sbt automatically dropped back to the older versions as needed (and when I try to build my sbt does say it's doing this), but I'll try building directly under 0.7.

Best,
scott

[Ross A. Baker]

https://github.com/paulp/sbt-extras is designed to detect and download
the necessary sbt version, and works from 0.7 through the present.

--
Ross A. Baker
ba...@alumni.indiana.edu
Indianapolis, IN, USA

[Wille Faler]

Hi,

Answers inline below:

On 14 Sep 2012, at 12:25, Robin Green <gre...@gmail.com> wrote:

Hi Wille,

I would like to enthusiastically volunteer, as I'm actively using Bowler at work! I have encountered some minor issues which I'd like to fix, and I have some other ideas for enhancements. If I were the new maintainer, I think I'd generally keep compatibility for future 0.x releases, and look into maybe redesigning it / closer integration with Scalatra in a possible 1.x release series.

A few questions:

1. How would we handle publishing changes to the bowlerframework.org website? I could take over the web hosting if that's the most convenient way to do it.

It's currently hosted on Github with my DNS pointing the domain to my Github account. I could just repoint the domain to your account or server when you want to take it over.

2. Do I need any permissions to publish the jar files etc.? I'm not familiar with publishing to oss.sonatype.org.
   

You probably need to sign up for a sonatype account - I haven't been able to publish for a couple of months, think my keys expired, so I guess it's a case of redoing it, and let me know if Sonatype say anything about someone else already posting to org.bowlerframework and we can try to transfer the permissions from me.

3. Some of the issues I've found are actually issues in recursivity-commons. I guess I could just fork that on github. Anything else I would need in terms of permissions, to publish that without needing to go through you - or do you want to remain maintainer of recursivity-commons?

Don't particularly want to keep maintaining it - the best solution is probably in the medium term to fork it, repackage to org.bowlerframework.commons and fold it into Bowler as a sub-project.

If there's any interest from anyone else in helping officially maintain Bowler and/or recursivity-commons, one option would be to set up a github organisation and add all the volunteers as members of that.

I'd be happy with that. I'm obviously pressed for time, but I don't want to leave users in a lurch, so I can pitch in from time to time if someone can offload the bulk of maintenance from me.

Looking forward to your reply,
Robin

[Mrityunjay Kant]

It was not a surprise but I would like to thank you for all the effort you've put into making Bowler. It surely helped me get off to a good start developing REST api's while learning scala itself. We've been using Bowler for some time now and found it to be very stable and bug free (although I do agree about some warts being present!). Thanks a ton once again.

~Mrityunjay

[Scott Morrison]

No, the build instructions really seem to be incorrect. When I try to "publish-local" in recursivity-commons (using sbt 0.7.7), I get the following compile error:

epli:recursivity-commons scott$ sbt-0.7.7 publish-local

Getting net.java.dev.jna jna 3.2.3 ...

:: retrieving :: org.scala-tools.sbt#boot-app

confs: [default]

1 artifacts copied, 0 already retrieved (838kB/15ms)

Getting Scala 2.7.7 ...

:: retrieving :: org.scala-tools.sbt#boot-scala

confs: [default]

2 artifacts copied, 0 already retrieved (9911kB/22ms)

Getting org.scala-tools.sbt sbt_2.7.7 0.7.7 ...

:: retrieving :: org.scala-tools.sbt#boot-app

confs: [default]

17 artifacts copied, 0 already retrieved (4379kB/57ms)

[info] Recompiling project definition...

[info]  Source analysis: 0 new/modified, 1 indirectly invalidated, 0 removed.

[warn] Credentials file /Users/scott/.ivy2/.credentials does not exist

Getting Scala 2.9.0 ...

:: retrieving :: org.scala-tools.sbt#boot-scala

confs: [default]

4 artifacts copied, 0 already retrieved (20442kB/105ms)

[info] Building project recursivity-commons 0.6 against Scala 2.9.0

[info]    using CommonsProject with sbt 0.7.7 and Scala 2.7.7

[info] 

[info] == compile ==

[info]   Source analysis: 43 new/modified, 0 indirectly invalidated, 0 removed.

[info] Compiling main sources...

[error] /Users/scott/scratch/recursivity-commons/src/main/scala/com/recursivity/commons/bean/scalap/ScalaSigParser.scala:3: object scalap is not a member of package tools

[error] import scala.tools.scalap.scalax.rules.scalasig._

[error]                    ^

[error] one error found

[info] == compile ==

[info] 

[info] == package-src ==

[info] Packaging ./target/scala_2.9.0/recursivity-commons_2.9.0-0.6-sources.jar ...

[info] Packaging complete.

[info] == package-src ==

[error] Error running compile: Compilation failed

[info] 

[info] Total time: 9 s, completed Sep 15, 2012 5:12:36 PM

[info] 

[info] Total session time: 12 s, completed Sep 15, 2012 5:12:36 PM

[error] Error during build.

best regards,

Scott Morrison

[Scott Morrison]

And if I just skip trying to compile recursivity-commons, and run sbt update in the main Bowler directory, I get:

epli:Bowler scott$ sbt-0.7.7 update

[warn] Credentials file /Users/scott/.ivy2/.credentials does not exist

[info] Building project parent 0.6 against Scala 2.9.1

[info]    using BowlerParentProject with sbt 0.7.5 and Scala 2.7.7

[info] 

[info] == core / update ==

[error] Server access Error: Operation timed out url=http://repo.fusesource.com/nexus/content/repositories/snapshots/net/liftweb/lift-json-ext_2.9.1/2.4/lift-json-ext_2.9.1-2.4.pom

[error] Server access Error: Operation timed out url=http://repo.fusesource.com/nexus/content/repositories/snapshots/net/liftweb/lift-json-ext_2.9.1/2.4/lift-json-ext_2.9.1-2.4.jar

Does this work for anyone else?

best,

Scott Morrison

[Wille Faler]

Thanks for the kind words. I still maintain a couple of production applications built on Bowler myself, so any pain in the framework, I would (and have in some cases) felt myself! :)

You live and you learn..

[Wille Faler]

Hi,

For the first recursivity-commons issue: you may have to manually put the appropriate scalap.jar file (it should be in your lib directory of your Scala install dir), as I'm not sure this is actually available in any repo anymore.

As for the Lift-json issue, not sure where lift-json is hosted of the top of my head, or if that particular version of lift-json is still available.

The Scala community is unfortunately notorious for removing old artifacts from repos it seems. :(