incubator-odf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Tilton <>
Subject Re: ODF Command Line Tools -- Request for community feedback
Date Tue, 29 May 2012 17:08:12 GMT

On Mon, May 28, 2012 at 2:21 PM, Rob Weir <> wrote:
> On Thu, May 24, 2012 at 1:04 PM, Noah Tilton <> wrote:
>> Hello Rob et al.,
> Hi -- sorry for the delayed response.  I was away from the office last week.
>> Here is a proof-of-concept showing how one can use the ODF Toolkit with jruby:
> Cool.  Adding odf-dev to this email as well as odf-users
>> the relevant files are the README and the ruby code in ./lib.  If you
>> have jruby in your path, you should be able to run
>> % jruby lib/oclt.rb
>> And see that there is a file created in /tmp.
> I cloned the repository and I get an error:
> ~/odf-command-line-tools$ jruby lib/oclt.rb
> lib/oclt.rb:3: cannot load Java class
> org.odftoolkit.simple.TextDocument (NameError)
> I'm not familiar with JRuby.  Do you know whether it works with Maven?
>  That might help with dependency management,  Just specify the ODF
> Toolkit as a dependency and it will be downloaded automatically and
> added to the classpath.  Maven is the best thing that happened to Java
> since garbage collection.

Thanks for the tip, I'll see if I can get it built with Maven and push
a new version.

>> My plan is to start building out the OCLT project as an internal DSL
>> using jruby.  I think ruby is a good compromise as it integrates
>> nicely with the JVM and all of the existing Java code that is part of
>> the ODF Toolkit.  Ruby's syntax lends itself well to DSLs because of
>> its "minimally intrusive" syntax, and a number of language features
>> make it a natural choice.  I know ruby already, and it seems to be
>> popular in the scripting community.
>> If you have any questions/concerns about this approach or would like
>> me to spend more time in the feedback/research phase then please let
>> me know; otherwise it's off to the races.
> This sounds like a reasonable approach.  Thanks for the effort you
> made to solicit feedback on the requirements.   I'm hoping if you take
> a "release early and often" approach you can get more feedback as you
> go.
> You likely have greater understanding of Ruby than I do, so going down
> this path means my mentoring will mainly be on the ODF and ODF Toolkit
> side.  I'm OK with that if you are.

Yes, that is OK with me.  I think discussing with you how best to
model the existing API classes in a scripting language would also be
useful, no matter what we end up using.

> We should probably also agree on platform and version requirements.
> JRuby 1.5?   1.6?  1.7 preview?    I assume we should run on Windows /
> Mac / Linux.  Any other version considerations?  For example, does
> JRuby pre-req a JDK version?

Jruby 1.7.0.preview1 release (newest release) dropped support for 1.5
and is now 1.6+, which is still behind the latest JDK major version.
I'm OK with targeting a legacy JDK/jruby but we're likely to lose some
bug fixes and performance updates.  And exactly /which/ legacy JDK to
support, and which legacy version of Jruby to use seems like an
arbitrary choice.  Naturally, as a developer my preference is to stay
bleeding edge and let the chips fall where they may.

Rony and Fernando made some illuminating points about this in another
thread showing both sides of the debate.  Although I thought Jruby
would be a good choice for reasons enumerated previously, I'm not
wedded to the idea and I'm glad people are speaking up now rather than
a month from now.  It's going to be hard to make everyone happy but I
think ruby has a lot going for it and I've yet to hear other concrete

If Jruby turns out to be "too new" we might want to consider Groovy.
It has a ruby-like syntax which will make for a clean DSL.  I will
also appreciate the chance to learn it.


View raw message