GSOC 2012

[Hubert Plociniczak]

Hi all,

we have participated in Google Summer of Code for 2 consecutive years
now and soon Google will be accepting applications for the 2012 edition.
GSOC 2010 (http://www.scala-lang.org/gsoc2010) and 2011
(http://www.scala-lang.org/gsoc2010) brought us some interesting
development from the students and we would be more than happy to have
more of that this year.

Therefore we are asking for suggestions on any interesting projects that
you would like see in the Scala ecosystem. This can include simple
ideas, short abstracts, anything that could lead to a 3 months project
(full-time) and which is related to Scala.

If you are a student then feel free to tell us about the things you
would like to work on. If you would like to mentor a Scala project in
gsoc you can contact me directly.

Thanks,
hubert

[Rodrigo Cano]

As someone once pointed out, something that is needed for scala to become more mainstream is good support in all major IDEs. Right now, the one lacking most is NetBeans (IDEA and Eclipse have an active team of developers behind), so my idea (the only thing I can contribute now) is that someone grab ENSIME (the excellent result from a previous GSOC) and integrate it with NetBeans. I think the pros of this approach are quite evident, but to state what I'm thinking:

* Projects managed with ENSIME could be opened by more than one IDE granting same features (that I'm aware of: Emacs, NetBeans, Jedit), that would allow programmers to work with the IDE they like most.

* All of these IDEs will improve as ENSIME improves reducing workload on IDE to features integration.
* The more integrations of ENSIME are made, the easier it becomes for further integrations, propagating it.

And maybe someday something like, an ENSIME server managing the project, and multiple IDEs connected to it working over the same project seen changes made by others as soon as possible? (probably crazy, and not useful in the end :-) )

Thanks.

[Rodrigo Cano]

s/seen/seeing/

[Chapin, Peter @ VTC]

A GSOC project related to NetBeans support would be excellent. If there is any value to it, I second this idea. I’m a NetBeans user but I’ve basically switched to IntelliJ for my Scala development because the Scala support is more actively evolving there.

 

Peter

[virtualeyes]

How about template-engine support?

Neither IntelliJ nor Scala-IDE provide any support whatsoever for
Scalate, Play 2.0 template-engine, etc. Such a massive gaping hole in
functionality, one wonders what the silence is about.

GSOC'ing that project out the door for the masses would complete the
Scala web stack loop, IMO (short of strongly typed JS, but only M$ has
been able to pull that off with Visual Studio).

2cents


On Feb 22, 6:33 pm, "Chapin, Peter @ VTC" <PCha...@vtc.vsc.edu>
wrote:

> A GSOC project related to NetBeans support would be excellent. If there is any value to it, I second this idea. I’m a NetBeans user but I’ve basically switched to IntelliJ for my Scala development because the Scala support is more actively evolving there.
>
> Peter
>
> From: scala-l...@googlegroups.com [mailto:scala-l...@googlegroups.com] On Behalf Of Rodrigo Cano
> Sent: Wednesday, February 22, 2012 12:30
> To: scala-l...@googlegroups.com
> Subject: Re: [scala-language] GSOC 2012
>
> As someone once pointed out, something that is needed for scala to become more mainstream is good support in all major IDEs. Right now, the one lacking most is NetBeans (IDEA and Eclipse have an active team of developers behind), so my idea (the only thing I can contribute now) is that someone grab ENSIME (the excellent result from a previous GSOC) and integrate it with NetBeans. I think the pros of this approach are quite evident, but to state what I'm thinking:
>
> * Projects managed with ENSIME could be opened by more than one IDE granting same features (that I'm aware of: Emacs, NetBeans, Jedit), that would allow programmers to work with the IDE they like most.
> * All of these IDEs will improve as ENSIME improves reducing workload on IDE to features integration.
> * The more integrations of ENSIME are made, the easier it becomes for further integrations, propagating it.
>
> And maybe someday something like, an ENSIME server managing the project, and multiple IDEs connected to it working over the same project seen changes made by others as soon as possible? (probably crazy, and not useful in the end :-) )
>
> Thanks.
>

[Donald McLean]

The folks at JetBrains (originally IntelliJ) devote quite a bit of
their resources based on user votes. If you would like to see
something get some attention then you need to find (or submit) a
request and get people to vote for it.

[virtualeyes]

Scalate support has been an open issue with IntelliJ for 2 years.

Today I discovered that by the summer or with IntelliJ 12 they may
have initial Scalate support in place.

For Eclipse there is simply nothing.

I posted on Scala-IDE User group re: putting Scalate on the road map.
Probably not high priority, but for web devel, no template-engine IDE
support is T-ough going...

[Donald McLean]

In one of the JetBrains forums somebody complained about an issue that
had been open for 7 years. The response was basically that it had been
assigned a low priority because nobody had voted for it.

[Donald McLean]

If it looks so ugly, shouldn't you be providing feedback to the
JetBrains folks in the form of filed issues, comments on issues and
votes on issues? Cosmetic changes are often the easiest to implement.

Just a thought.

Donald

On Wed, Feb 22, 2012 at 6:02 PM, virtualeyes <sit...@gmail.com> wrote:
>
> On Linux IntelliJ looks like a dog's breakfast, however, so I may be
> waiting another 5 years for an Eclipse-Scalate plugin.

[Johannes Rudolph]

On Thu, Feb 23, 2012 at 4:00 PM, Donald McLean <dmcl...@gmail.com> wrote:
> If it looks so ugly, shouldn't you be providing feedback to the
> JetBrains folks in the form of filed issues, comments on issues and
> votes on issues? Cosmetic changes are often the easiest to implement.

Not when it comes to Linux + GUI + Gtk + OpenJdk etc. The situation
maybe getting even worse with the sun jvm not being officially
supported in ubuntu any more. Unfortunately, it seems there's little
they can do on their side. Reporting and voting is still needed of
course to get some pressure behind solving those issues one way or
another.

--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

[Hubert Plociniczak]

On 02/22/2012 06:29 PM, Rodrigo Cano wrote:

As someone once pointed out, something that is needed for scala to become more mainstream is good support in all major IDEs. Right now, the one lacking most is NetBeans (IDEA and Eclipse have an active team of developers behind), so my idea (the only thing I can contribute now) is that someone grab ENSIME (the excellent result from a previous GSOC) and integrate it with NetBeans. I think the pros of this approach are quite evident, but to state what I'm thinking:

* Projects managed with ENSIME could be opened by more than one IDE granting same features (that I'm aware of: Emacs, NetBeans, Jedit), that would allow programmers to work with the IDE they like most.

* All of these IDEs will improve as ENSIME improves reducing workload on IDE to features integration.
* The more integrations of ENSIME are made, the easier it becomes for further integrations, propagating it.

ENSIME relies on the presentation compiler which is also the basis for the scala-ide. The advantage from using presentation compiler directly afaik is having another layer of abstraction and basically treating it like a standalone server running in the background.

I agree that even better ENSIME support would be nice but the only problem is that we don't have anyone who has enough expertise to mentor it (unless Aemon has time for that). Similar mentoring problem would be with NetBeans. Of course if there is a student who knows that part very well and does not need much guidance in this particular field, then the problem is somehow reduced.

And maybe someday something like, an ENSIME server managing the project, and multiple IDEs connected to it working over the same project seen changes made by others as soon as possible? (probably crazy, and not useful in the end :-) )

I'm afraid this is a bit too much for gsoc but the idea is appealing.

[Johannes Rudolph]

On Thu, Feb 23, 2012 at 4:16 PM, Hubert Plociniczak
<hubert.pl...@epfl.ch> wrote:
> On 02/22/2012 06:29 PM, Rodrigo Cano wrote:
> ENSIME relies on the presentation compiler which is also the basis for the
> scala-ide. The advantage from using presentation compiler directly afaik is
> having another layer of abstraction and basically treating it like a
> standalone server running in the background.

Isn't the important thing here to provide a well-designed and
-maintained API for the presentation compiler? I played with the
thought of basing stuff on ensime as well but I don't think it's
sustainable to base another piece of software on a semi-fluid
abstraction layer (ensime) which is build on a semi-fluid undocumented
compiler API (presentation compiler).

[Ismael Juma]

On Thu, Feb 23, 2012 at 3:16 PM, Johannes Rudolph <johannes...@googlemail.com> wrote:

Not when it comes to Linux + GUI + Gtk + OpenJdk etc. The situation

maybe getting even worse with the sun jvm not being officially
supported in ubuntu any more. Unfortunately, it seems there's little
they can do on their side. Reporting and voting is still needed of
course to get some pressure behind solving those issues one way or
another.

This is not exactly true. IDEA 11 looks much better on Linux as they fixed a ton of issues with both Nimbus on Linux and the GTK+ Look and Feel.

Personally, I think IDEA 11 looks decent on Linux. Much better than a couple of years ago anyway.

Best,

Ismael

[Johannes Rudolph]

Yes, maybe I was too harsh. I mean that's the setup I'm using as well
and it's mostly ok. But I've got again font rendering regressions
since the last version and proper anti-aliased, native font support in
the editor is still not there depending on which font you want to use.
And things are even worse using openjdk (which isn't supported by
IDEA).

[Ismael Juma]

On Thu, Feb 23, 2012 at 4:22 PM, Johannes Rudolph <johannes...@googlemail.com> wrote:

Yes, maybe I was too harsh. I mean that's the setup I'm using as well

and it's mostly ok. But I've got again font rendering regressions
since the last version and proper anti-aliased, native font support in
the editor is still not there depending on which font you want to use.

That is true, the font that you use can make a big difference in how good or bad things look in the editor. Also, if you use KDE, you need to pass specific anti-aliasing settings to the Java launcher while things are done automatically for Gnome.

 

And things are even worse using openjdk (which isn't supported by
IDEA).

OpenJDK is an interesting case because the anti-aliasing looks close to native (which makes sense since it relies on FreeType), but there are (or were last time I looked) lots of visual artifacts.

Best,

Ismael

[virtualeyes]

I'll have to check again, pre-11 IntelliJ was a gruesome sight on
Fedora. It may sound petty, but the look of your IDE, the application
you spend a significant portion of your life interacting with, makes a
difference.

I literally felt ill, but that's just me.

Eclipse looks great on Linux. Maybe IntelliJ has come up with the
right mix as you say, Ismael.

Anyway, as I said re: GSOC, general IDE support for Scala is pretty
awesome (I am more than satisfied with Scala-IDE); IDE support for
Scala template-engines, however, is non-existent.

Obviously not a high priority issue, otherwise Scala template-engines
would already be supported in one way or another. Maybe Scala
developers are generally speaking not using the language for web
development?? Scalate has been out for what 3 years or more? A shame,
another awesome creation by James Strachan, but this one gets no love
(yet).

Patience grasshopper...

On Feb 23, 5:11 pm, Ismael Juma <ism...@juma.me.uk> wrote:
> On Thu, Feb 23, 2012 at 3:16 PM, Johannes Rudolph <
>

[Ismael Juma]

On Thu, Feb 23, 2012 at 4:31 PM, virtualeyes <sit...@gmail.com> wrote:

I'll have to check again, pre-11 IntelliJ was a gruesome sight on
Fedora.  It may sound petty, but the look of your IDE, the application
you spend a significant portion of your life interacting with, makes a
difference.

I use Fedora too. 

Eclipse looks great on Linux.  Maybe IntelliJ has come up with the
right mix as you say, Ismael.

Make sure to experiment with the appearance settings. Try the various look and feels and experiment with the font to see if you find something that works for you.

Best,

Ismael

[Donald McLean]

Do you have an issue number that people can vote on?

Donald

[Alex Cruise]

FWIW, I use IDEA on Fedora 16.  

Running IDEA under Sun JDK7 has basically perfect text rendering--including for typefaces like Consolas and Segoe that are completely reliant on subpixel hinting.  But OpenJDK 1.6.0 has often been pretty terrible in the past; haven't tried it recently.

And just because Ubuntu doesn't include SunJDK in their default package system anymore doesn't mean you can't run it; it's just a little more work to get updates.

-0xe1a

[virtualeyes]

IntelliJ folks said they'll have some form of Scalate support
hopefully by the summer.

Don't have the thread handy, James Strachan posted a request 2 years
ago on JetBrains' site, where I cannot recall.

Of course, I'm plenty content with Scala-IDE, just praying for an
Eclipse Scalate plugin to come along. Has to happen at some point,
Scalate is too good.

[virtualeyes]

Fedora 16, you must be a KDE user.

Gnome 3 on Fedora 15 created an uprising of sorts last I checked.
Apparently multi-monitor support is somewhat bass ackwards among other
annoyances.

Camping out here on Fedora 14 for the time being, will have to make
the leap at some point...

[Tomáš Heřman]

What about ensime support for Sublime text? I think it could be really useful, although i'm not sure it's "glorious" or large enough for GSoC. I would love to work on it, though, as i have been using emacs with ensime for some time now. Writing sublime plugin is quite simple (just a python script with api to controll the editor itself) so not much mentoring would be needed on that part.

[Jorge Ortiz]

There would be several people at foursquare who would be excited to use ENSIME with Sublime.

2012/2/24 Tomáš Heřman <tomas....@gmail.com>

[Paul Phillips]

On Fri, Feb 24, 2012 at 7:21 AM, Jorge Ortiz <jorge...@gmail.com> wrote:
> There would be several people at foursquare who would be excited to use
> ENSIME with Sublime.

Maybe some compiler developers too.

[Daniel Sobral]

On Fri, Feb 24, 2012 at 13:21, Jorge Ortiz <jorge...@gmail.com> wrote:
> There would be several people at foursquare who would be excited to use
> ENSIME with Sublime.

Doesn't the existing plugin(*) work?

(*) https://github.com/casualjim/sublime-ensime

>
>
> 2012/2/24 Tomáš Heřman <tomas....@gmail.com>
>>
>> What about ensime support for Sublime text? I think it could be really
>> useful, although i'm not sure it's "glorious" or large enough for GSoC. I
>> would love to work on it, though, as i have been using emacs with ensime for
>> some time now. Writing sublime plugin is quite simple (just a python script
>> with api to controll the editor itself) so not much mentoring would be
>> needed on that part.
>
>

--
Daniel C. Sobral

I travel to the future all the time.

[Tomas Herman]

There is 1 opened issue and it says it doesnt and the author doesn't have time to work on it.

[Tomáš Heřman]

Another idea i had was maybe some sort of visualization of akka actor networks and the message flow between the actors. I think it might be quite useful for debugging and learning how actors work. With that said, i have no idea how hard would something like that be to implement. But maybe someone reading this list would know. I guess i would need to hook somewhere into akka's guts and listen on the events like actor creation and message routing. Do you guys think that idea is any good?

[√iktor Ҡlang]

2012/2/26 Tomáš Heřman <tomas....@gmail.com>

Another idea i had was maybe some sort of visualization of akka actor networks and the message flow between the actors. I think it might be quite useful for debugging and learning how actors work. With that said, i have no idea how hard would something like that be to implement. But maybe someone reading this list would know. I guess i would need to hook somewhere into akka's guts and listen on the events like actor creation and message routing. Do you guys think that idea is any good?

It'd be fairly simple, just create a VisualizingDispatcher that requires external stimuli to do any work (think "next"-button or similar), hook into register and deregister to show/hide actors. Render Actors according to their hierarchy structure (trees are simple), then wrap mailboxes into a VisualizingMailbox, so enqueue and dequeue events are published to the renderer.

WDYT?

Cheers,

√

 

On Wednesday, February 22, 2012 5:35:43 PM UTC+1, Hubert Plociniczak wrote:

Hi all,

we have participated in Google Summer of Code for 2 consecutive years
now and soon Google will be accepting applications for the 2012 edition.
GSOC 2010 (http://www.scala-lang.org/gsoc2010) and 2011
(http://www.scala-lang.org/gsoc2010) brought us some interesting
development from the students and we would be more than happy to have
more of that this year.

Therefore we are asking for suggestions on any interesting projects that
you would like see in the Scala ecosystem. This can include simple
ideas, short abstracts, anything that could lead to a 3 months project
(full-time) and which is related to Scala.

If you are a student then feel free to tell us about the things you
would like to work on. If you would like to mentor a Scala project in
gsoc you can contact me directly.

Thanks,
hubert

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Klaus Havelund]

What kind of visualization software would you use for this?

Klaus Havelund

2012/2/26 √iktor Ҡlang <viktor...@gmail.com>

[√iktor Ҡlang]

On Sun, Feb 26, 2012 at 4:36 PM, Klaus Havelund <have...@gmail.com> wrote:

What kind of visualization software would you use for this?

I'd definitely tinker with SPDE: http://spde.technically.us/Spde.html

[Klaus Havelund]

SPDE sounds very useful indeed and is possibly the right tool for the task. 

Another option would be to use GraphViz dot format:

  http://www.graphviz.org/

However, GraphViz is static: you have to generate a new dot file for each change in the graph. That can work, however, and the dot notation is extremely well designed. 

HTML5 is a third candidate but I do not have any opinions on this.

Klaus

2012/2/26 √iktor Ҡlang <viktor...@gmail.com>

[John Nilsson]

I would even consider Kojo if going with processing
Br
John

[Tomas Herman]

Thanks for the feedback guys. What do you think of practicality of such tool? I think it would be really good learning and perhaps even debugging tool of done correctly, but you are probably way smarter than me so you might feel different :) The processing library seems like a really good tool for such thing.

[Klaus Havelund]

I definitely think it is a good idea!

Klaus

[Tomáš Heřman]

Another idea i had was some sort of library which would implement common utilities found in unix for script writing. Im not sure how much is scala/java used on desktop these days, but i wrote an app for desktop and creating an installer for windows is PITA, because there is no python, ruby and no shell any reasonable scripting language. So i thought it might be cute to write a scala library that would implement common utilities (obviously, some would need to be less powerful) that are used in shell scripts (wget, ls, mv, scp, grep .... etc) so that a programmer could write install script in them, compile it into jar and be done with it. I think it should be possible to write that library in such fashion that the scripts would work for all platforms.

I think it should be possible to also create a wrappers for unix tools in such fashion that the utils written eventually be me would be able to work with the built in ones and other way around. And make the common ones easier to use from scala. But again, i'm not sure how useful this would be. Another use case could be writing of normal scripts for deploys or whatever. We would gain all the goodness of scala stdlib for free (collections, parser combiantors etc) as well as possibility of extending your scripts with any jvm library avalible.

The not so great feature would be rather long startup time of scripts, but that could be fixed with nailgun[1], if it works well with scala. I haven't tried that, though, but i don't see why it wouldn't work.

Please let me know what you guys think!

Regards,
Tomas

[1] http://www.martiansoftware.com/nailgun/

[Stefan Zeiger]

On 2012-03-05 16:07, Tomáš Heřman wrote:
> Another idea i had was some sort of library which would implement
> common utilities found in unix for script writing. Im not sure how
> much is scala/java used on desktop these days, but i wrote an app for
> desktop and creating an installer for windows is PITA, because there
> is no python, ruby and no shell any reasonable scripting language.

Some custom scripting stuff does not make an installer. You really want
a proper msi package on Windows, and you can do that from Scala thanks
to https://github.com/jsuereth/sbt-extras

-sz

[Stefan Wagner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 22.02.2012 17:35, schrieb Hubert Plociniczak:

> Therefore we are asking for suggestions on any interesting projects that
> you would like see in the Scala ecosystem. This can include simple
> ideas, short abstracts, anything that could lead to a 3 months project
> (full-time) and which is related to Scala.

I recently saw this interesting video, "Inventing on Principle", about
instant feedback while programming JavaScript on vimeo
https://vimeo.com/36579366 by Bret Victor. I thought Scala with its
functional features could be a language which is well suited for such an
programming interface.

- --

Tsch���--->...Stefan
- ---------------------------
Don't visit my homepage at:
http://home.arcor-online.net/hirnstrom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9eGjcACgkQQeATqGpDnRpUZgCaAo0vy0xD0QksJY5UN7yfA1NX
v9wAn35F1PFGPqV76hcZrpocLtAf8qyV
=9h4s
-----END PGP SIGNATURE-----

[Michael Schmitz]

Wouldn't graphviz place a dependency on binaries? Or is there a
library on the JVM that compiles DOT format to images?

Peace. Michael

[Sciss]

a Scala wrapper around or part-rewrite of Prefuse ( http://prefuse.org/ ) would be fantastic. It comes with a very nice dynamic physical modelling layout, suitable for visualising dynamic graphs.

i could imagine the whole table data structure could be removed in favour of scala's built in collections, leaving only the presentation layer to be re-written or wrapped.

best, -sciss-

[Hubert Plociniczak]

We have internally a proposal for a project that would provide prefuse
for scala. "just" porting it to scala is not really such a big deal
(well you have to handle lack of generics but that's hardly a problem).
ideally we would port it to scala and use the reactive framework for
that. the latter is a bit tricky.

hubert

[Sciss]

sounds great.

yes, what I mean is, although the code is quite clean and high quality, it is full of java idiomatic stuff, including the missing type safety for graphs ('generics'). the table types are really low level java, assuming all sorts of performance optimisations, like pool sharing, array copying etc. i would guess that you can reduce the code size to 10% alone by giving up those alleged optimisations in favour of using scala-collections instead. it might be a bit slower, but much more readable, and probably thread safe operations can be defined (currently you need to perform some stuff on the EDT, other stuff needs to gain a lock on the visualization, temporarily pause the animator, etc.).

also you can spare the reinvented wheel of functional types, like Predicate, almost all of which you can do straight away with Scala's functions and closures.

best, -sciss-

[Rex Kerr]

On Mon, Mar 12, 2012 at 1:21 PM, Sciss <con...@sciss.de> wrote:

sounds great.

yes, what I mean is, although the code is quite clean and high quality, it is full of java idiomatic stuff, including the missing type safety for graphs ('generics'). the table types are really low level java, assuming all sorts of performance optimisations, like pool sharing, array copying etc. i would guess that you can reduce the code size to 10% alone by giving up those alleged optimisations in favour of using scala-collections instead.

It's almost always a bad bet to throw away stable, working, highly-optimized code and replace it with "10% of the code" that has no "alleged optimizations".  Chances are, the optimized code was optimized for a reason, and you're much better off wrapping the solution than rerolling your own.

Especially with a language that excels at wrapping like Scala does.

  --Rex

[nafg]

In the case of prefuse, I agree the ideal thing would be to write something from scratch, in idiomatic scala. Wrapping it would not give much benefit over using it directly.

 

  --Rex

[Tomáš Heřman]

I hope I'm not getting too annoying, but I had another idea: i think it might be useful to have a tool that would generate XML Schema for given set of case classes. It should be easy enough to generate some basic XML Schema constraints from basic classes and then i could write DSL that would make it easier to write the more advanced constraints. I think it would be quite nice feature, considering that the type safety is one of the main features of Scala and using json never felt quite right to me.

It could also be used as kind of always up to date documentation for web services, as there are tools for xml schema -> human readable documentation transformation.

[Alex Cruise]

2012/3/15 Tomáš Heřman <tomas....@gmail.com>

I hope I'm not getting too annoying, but I had another idea: i think it might be useful to have a tool that would generate XML Schema for given set of case classes. It should be easy enough to generate some basic XML Schema constraints from basic classes and then i could write DSL that would make it easier to write the more advanced constraints. I think it would be quite nice feature, considering that the type safety is one of the main features of Scala and using json never felt quite right to me.

It could also be used as kind of always up to date documentation for web services, as there are tools for xml schema -> human readable documentation transformation.

Unfortunately I'm not aware of any tool that will generate XML Schema from Scala case classes--other than JAXB, which will make a  big mess of annotations in your model code.

However, http://scalaxb.org/ will go the other way, generating Scala case classes from an XSD.

-0xe1a

[Tomas Herman]

No what i had in mind was that i would write the tool :). It should be quite easy to implement basic constraints, when your xml elements have no attributes...we could just represent following: 

  case class A(field1: String)

  case class B(fieldA: A)

 as

  <B> <fieldA> <A> <field1> "hi" </field1> </A> </fieldA> <B>

It would be a little trickier if we wanted to represent some fields like attributes, but im sure it would be possible to find reasonable solution. Maybe mark fields that are supposed to be attributes with annotation, or specify it via DSL

[Alex Cruise]

On Thu, Mar 15, 2012 at 11:02 AM, Tomas Herman <tomas....@gmail.com> wrote:

... It should be quite easy ...

I say this way too often too. ;)

Anyway, I'd suggest that trying to add this to scalaxb would be the most productive approach. :)

https://github.com/eed3si9n/scalaxb/issues/22

-0xe1a

[Naftoli Gugenheim]

lift-json can serialize case classes to xml.