Home

News: Raven 1.1: Build Java with Ruby

  1. Raven 1.1: Build Java with Ruby (38 messages)

    Raven is a build system that leverages Ruby tools (namely Rake and Gems) to let you build Java projects easily. It provides a way to handle dependencies, specific Rake tasks for Java, all based on Ruby. This release introduces simple tools to install your dependencies directly. Why base your build system on Rake and Ruby Gems? For one thing, Rake is a very simple build system; it uses domain specific tasks; it's based in Ruby, a script language, rather than using Java in a way Java wasn't necessarily meant for. Ruby Gems is a packaging system, a bit like yum, CPAN or apt-get. It conveniently handles package installation, update and removal. Here is what Raven will allow you to do:
    • Your jar files are wrapped in a Ruby Gem (a package). You can then start manage your java jar library just like a Gem library. Tools are provided to convert a Maven jar repository to a Gem repository (both local on your machine or on a public server) or to directly install packages.
    • Your dependencies are declared in a Rakefile. You basically say which Gems you need (and so which jars will be included in your classpath) for building. When building, if some Gems are missing, they are automatically installed in your local Gem repository, just like Maven.
    • Raven gives you a small library of Rake tasks that you can use to compile your java classes, build a jar file, build a war file, produce javadoc, wrap the jar you built in a Gem, etc.
    • This effectively gives you everything you need to build Java projects, using Gems for dependencies management and Rake for scripts.
    This latest release introduces simple package installation: raven install httpclient raven install -g xstream xstream:1.2 raven install --all -g axis2 Check it out here: http://raven.rubyforge.org/

    Threaded Messages (38)

  2. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    Does this tool connect to a Gem server? Could this tool connect to a Maven repository instead?
  3. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    It connects to a Maven server. As mentioned in the post, jars are wrapped in a Gem. So the jars published by Maven repositories are the ones actually used. There's just an index that lists all theses jars to make them searchable. Once found they're downloaded from the Maven repository, wrapped and installed. Nothing to setup (ibiblio and central are already there). For more information check: http://mriou.wordpress.com/2006/11/03/raven-11-building-more-java-with-ruby/ http://raven.rubyforge.org/use.html#install
  4. I have written a brief comparison of some of the alternatives in my blog: Raven, JRake and AntBuilder
  5. Benefits[ Go to top ]

    Ok, as usual, any open source software that comes around and fills some specific niche and/or competes with others is welcomed. Though I always like the know the benefits. Can you please explain the benefits of using Raven over Maven 2. I understand the ability to extend tasks using Ruby, but what else? Ilya
  6. Re: Benefits[ Go to top ]

    What about scripting for a starter? Did you ever get a problem that didn't quite "fit" into Maven2's dogma? Wrote a plugin? How painful was that? Just copying a single file needs a plugin if it doesn't fit in the default directory structure. You have a schema used in 2 modules? Too bad, you'll need a module with just a single schema file in it. IMHO being able to write simple scripts when you need to do simple things should be the basis of any build system. So I guess that's the biggest differentiation you're looking for. And by the way, how many lines of XML to get started? Raven also benefits from Gem and Rake, two very good tools in Ruby. The first one gives you a *real* package system. Like RPMs, or debian packages. You can list, install, uninstall in a single command. Check for duplicates. All that good stuff. Using Raven, you'll get rid of what we dubbed "the Maven uncertainty principle". The source of it being mostly snapshot releases and plugins. And the combination of both being the worst. So Raven doesn't do anything special with snapshots. And that's a feature. Another thing: Raven doesn't break if a repository is down. It just tells you that it isn't there and that's all. And it will check if other repositories also have what you're looking for. The search for a given dependency is done using regular expressions matching, so it's far less verbose to install a dependency or declare it for your build. So that's a lot of details but altogether, it makes your life much easier and leaves you more time to do something else. I'm not saying Raven is the silver bullet, there are still many things to implement to be as good as can be, but it's already a good alternative I think.
  7. simply execute an ant task fer the right phase, son! Sheesh!
  8. How many lines of XML to configure the antrun plugin? About 16. Plus the bugs of the antrun plugin.
  9. Neat tool[ Go to top ]

    Will be checking it out. We do more python than ruby for our scripting, but really interesting tool.
  10. Re: Neat tool[ Go to top ]

    We do more python than ruby for our scripting, but really interesting tool.
    Does looking at Ruby code remins anyone of Perl? If we had to pick up another language for scripting (actually dynamic typing) needs, then why not some with better easier syntax? How did Ruby become so popular in last couple of years, when Python/TCL/ML/Haskell/(even)Lisp/Scheme have been around for similar or much longer timeframes and have had much wider developer base (of course Perl continues to have the widest developer base as far as these 'other' languages are concerned)? How did Ruby get this momentu despite its pathetic run-time performance (compared to others in the list)? I know its an off-topic question - but I am interested to learn ths bit of history.
  11. Re: Neat tool[ Go to top ]

    Does looking at Ruby code remins anyone of Perl? If we had to pick up another language for scripting (actually dynamic typing) needs, then why not some with better easier syntax? How did Ruby become so popular in last couple of years, when Python/TCL/ML/Haskell/(even)Lisp/Scheme have been around for similar or much longer timeframes and have had much wider developer base (of course Perl continues to have the widest developer base as far as these 'other' languages are concerned)? How did Ruby get this momentu despite its pathetic run-time performance (compared to others in the list)? I know its an off-topic question - but I am interested to learn ths bit of history.
    You said out loud what I've been wondering silently. Why indeed? I think Python is much better than Ruby, personally. But, like you, I'm interested in knowing what phenomenon made Ruby so popular. I'm not interested in any kind of programming language flame war. So please, information only :-)
  12. Re: Neat tool[ Go to top ]

    How did Ruby become so popular in last couple of years, when Python/TCL/ML/Haskell/(even)Lisp/Scheme have been around for similar or much longer timeframes and have had much wider developer base (of course Perl continues to have the widest developer base as far as these 'other' languages are concerned)? How did Ruby get this momentu despite its pathetic run-time performance (compared to others in the list)? I know its an off-topic question - but I am interested to learn ths bit of history.
    It's the "killer app" phenomenon: Ruby on Rails made it vastly easier to set up basic database-driven web sites. Ruby was pretty obscure until Rails hit the scene.
  13. Re: Benefits[ Go to top ]

    I have to admit that I find it hard to get attracted by Ruby's syntax. But I have to say that I like the idea to use script language to do a simple thing that doesn't quite fit (as mentioned) in the build process. That's why we've created plugins, to extend a common behaviour. I'll be checking Raven out.
  14. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    Well, even if a dsl (or ruby, python, whatever) makes some specific task easier, there is a definite advantage to have *everything* done in the same language. Java for programming, and XML for configuration, build files, etc, covers basically everything needed for building enterprise apps. Even if some areas can be simplified by introducing "something else", the advantage would have to be monumental for me to introduce another "knowledge dependency". My 2 cents.
  15. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    Even if some areas can be simplified by introducing "something else", the advantage would have to be monumental for me to introduce another "knowledge dependency".

    My 2 cents.
    It is not just knowledge dependency, it is dependency on software outside of the typical Java + IDE installs, so more to set up and maintain especially if you are working on multiple platforms (as I do). If a scripting system is preferred (and there can certainly be advantages over the XML approach in this situation) it would seem to me to make more sense to use an approach that runs on the JVM and can currently be integrated with Java IDEs, like http://groovy.codehaus.org/Gant Even given that it may well be possible to run Raven on JRuby, it seems more appropriate to use a scripting language designed from the start to run on the JVM, and with a close-to-Java syntax.
  16. Nice to use scripting but ...[ Go to top ]

    OK, i would pick a "normal" scripting language over anything written in XML, but i think this is the wrong direction. Why we are remaking the same old mistake again, simply changing the implementation language ? Wouldn't be nice to have an higher level way to describe an application build, instead of just working at the assembler level ? Something like being able to describe what a module is (for my application), what a deliverable is, what a release is, etc etc ? No, no product to sell, no even the time to start my own open source project on it :-< .. Maurizio De Cecco http://jroller.com/page/dececco.
  17. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    Say it takes you a day to learn how to use a new tool which can save you many days of work later on because it's a better fit for what you're trying to do. You'd still ignore it just because it's not in the "right" language?
  18. Say it takes you a day to learn how to use a new tool which can save you many days of work later on because it's a better fit for what you're trying to do. You'd still ignore it just because it's not in the "right" language?
    It's not really that easy. You say, "Say it takes you a day..." Who is "you"? If that's the singular "you", then fine. But it rarely is the singular "you". Most of us work in a team. Introducing a new language (full blown or smaller DSL) has a learning curve. And introducing it to the build cycle is smack dab in the middle of the critical path of development. I am not saying that this makes Raven a good or bad fit. In my team, we use Maven 2. And I admit, it has it's share of pain points. We recently created some Ruby scripts for SQL script generation and we call these scripts from Ant. It was too hard to find a way to shoehorn this functionality into our build using Maven. While it was probably possible to do within Maven's structure, the ad hoc Ant+Ruby approach was just easier. That said, we have very little Ruby experience on the team, so there was some time spent getting everybody up to speed on how to execute/update the scripts. So it was not without cost. One thing developing in Java (or Ruby or other OSS-friendly languages) gives us is tool choice. But you can only go so far with the best-of-breed approach in tool selection. Eventually you can end up with too many tools that "fit just right" for their respective job where the sum of the parts is less than the whole. Sometimes we need to sacrifice selecting the ideal solution for each job for a little homogeneity.
  19. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    Say it takes you a day to learn how to use a new tool which can save you many days of work later on because it's a better fit for what you're trying to do. You'd still ignore it just because it's not in the "right" language?
    You didn't reply to my post but I think you are responding to it. I don't work in a vacuum. Bring in a new tool affects many other people on my team. It's irresponsible and selfish to not consider the impact of having to support two tools that solve the same problems. I have not yet actually introduced Python into our tools set formally and if there is no corresponding tool to Rake in Python, then I may reconsider using Python and persue Ruby. So, will anyone with a *helpful* answer to my question please respond?
  20. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    The python equivalent of Rake appears to be Scons. The other thing that made me rethink Python lately was that the Jython project seems to be fairly stalled. I know there was a new grant to get it moving again but the Jython page has no news since 2005. Now Sun is paying people to work on JRuby. That makes me think that Ruby may be the more promising way to go but JRuby is still not finished (by it's version number.) The perlisms in Ruby bother me but I read somewhere that it's being moved away from that kind of sloppiness now.
  21. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    Actually I was replying to John Brand (the thread interface doesn't help much). I had no helpful answer to your original question and that's why I didn't reply to it :) As for the "working in a vacuum" part, my short (probably too short) answer was with a "you" meaning every single person on your team. Another point is that knowing Java doesn't bring you much in learning how to use Maven. So if you start a new project I think that learning Raven is much easier than learning Maven (but obviously I'm biased). You don't need much knowledge of Ruby for it.
  22. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    Actually I was replying to John Brand (the thread interface doesn't help much).
    I apologize, the answer was adjacent and made sense in the context of my post. I should just assume that you replied to the post you meant to reply to (although, a quote in your reply would help.)
    I had no helpful answer to your original question and that's why I didn't reply to it :)

    As for the "working in a vacuum" part, my short (probably too short) answer was with a "you" meaning every single person on your team.
    My team is filled with RPG and COBOL programmers. Java is crazy new technology to them. It makes me chuckle to think about trying to sell them Python or Ruby. Not that I won't. It'll just be later. Also, given that the primary platform at this time is the AS400, Java is very doable but Python and Ruby are not. JRuby and Jython could work, though.
    Another point is that knowing Java doesn't bring you much in learning how to use Maven. So if you start a new project I think that learning Raven is much easier than learning Maven (but obviously I'm biased). You don't need much knowledge of Ruby for it.
    I've never really been sold on Maven. I think I just don't have a need for what it does. I kind of jumped in this discussion because using a scripting language instead of ant XML files is an attractibve option and a good way to introduce scripting languages.
  23. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    I kind of jumped in this discussion because using a scripting language instead of ant XML files is an attractibve option and a good way to introduce scripting languages.
    I dont know, I have used MQSC and wasadmin tcl extensively, and I cant really see that there is much advantage in scripting for configuration compared to a xml config file with schema validation etc. Maybe I am just so used to them that they dont bother mer anymore, but I am always surprised that people think of them as such a problem.
  24. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    I kind of jumped in this discussion because using a scripting language instead of ant XML files is an attractibve option and a good way to introduce scripting languages.


    I dont know, I have used MQSC and wasadmin tcl extensively, and I cant really see that there is much advantage in scripting for configuration compared to a xml config file with schema validation etc.

    Maybe I am just so used to them that they dont bother mer anymore, but I am always surprised that people think of them as such a problem.
    I used to be quite fluent in the ant language. I've not had to do much with it for a few years and now when I look at it I just think that I don't want to eat that elephant again. As far as I am concerned the schema validation is pretty useless as I've never had a serious issue with the syntax. The point here is that XML in Ant is being used as a framework for creating a DSL and it's not really good at that. I read somewhere that the original author of Ant even made a mea culpa for using xml. If I can find the quote I'll post it.
  25. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    "...just ask James Duncan Davidson, the original creator of Ant, who later came to admit that 1. He originally chose to use XML as the format for Ant scripts because he didn't want to write a parser, and 2. He really regrets it and apologizes to the Java community at large for it." http://blogs.tedneward.com/2005/08/22/When+Do+You+Use+XML+Again.aspx
  26. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    "...just ask James Duncan Davidson, the original creator of Ant, who later came to admit that

    1. He originally chose to use XML as the format for Ant scripts because he didn't want to write a parser, and
    2. He really regrets it and apologizes to the Java community at large for it."

    http://blogs.tedneward.com/2005/08/22/When+Do+You+Use+XML+Again.aspx
    OK, I guess JDD should know, so if he says that xml was wrong for ant, then I guess hes right. I would have believed that xml was one of the principal reasons for why ant was as quickly and as widelly adopted as *the* java build system once upon a time, but I guess not. Anyhow, he doesnt have to apologize to me, because I sure havent suffered, even though I have used ant quite a lot in the past.
  27. Re: Raven 1.1: Build Java with Ruby[ Go to top ]


    I would have believed that xml was one of the principal reasons for why ant was as quickly and as widelly adopted as *the* java build system once upon a time, but I guess not.
    Technologies become de facto standard for a variety of reasons, the principal one usually being that there is a big void that needs to be filled. The sad thing about this is that whenever a product takes the world by storm because it's filling a unique need, there is a high likeliness that this tool will not be of very high quality (JUnit comes to mind as another example of this phenomenon :-)). Personally, I don't feel that the XML persona of ant gets in my way that much, but its lack of dynamicity certainly does (I want if/then/else, while and inheritance!). -- Cedric
  28. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    JUnit comes to mind as another example of this phenomenon :-)

    --
    Cedric
    Nice unbiased comment. LOL.
  29. JUnit comes to mind as another example of this phenomenon :-)


    --
    Cedric


    Nice unbiased comment. LOL.
    Biased or not, it's undoubtedly true.
  30. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    Personally, I don't feel that the XML persona of ant gets in my way that much, but its lack of dynamicity certainly does (I want if/then/else, while and inheritance!).
    Use XSLT to transform the build.xml. Extra points for initiating the transformation from ant. =)
  31. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    "...just ask James Duncan Davidson, the original creator of Ant, who later came to admit that

    1. He originally chose to use XML as the format for Ant scripts because he didn't want to write a parser, and
    2. He really regrets it and apologizes to the Java community at large for it."

    http://blogs.tedneward.com/2005/08/22/When+Do+You+Use+XML+Again.aspx
    I am afraid I still don't get the considerable and, it seems, increasing hostility towards XML. Better XML than an increasing range of potentially incomprehensible DSLs. Sure, you can write meaningless stuff in XML, but at least you can validate, parse and transform it, and pretty much guarantee that it will be readable in future. Those who complain too vigorously about XML should be forced to deal with the results of those who have actually gone ahead and written their own data parsers; only perhaps with somewhat out-of-date documentation, and with the parser written in a language or dialect that is no longer used. I have had too much experience of that to support the DIY approach.
  32. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    I am afraid I still don't get the considerable and, it seems, increasing hostility towards XML.
    I'm not hostile towards it. I actually have used XML quite extensively and along the way, I figured out that there are things it is good for and things it is not so good for. It's a good way to specify data. It's a bad platform for writing code.
    Better XML than an increasing range of potentially incomprehensible DSLs.
    I don't want a DSL either. I want a tool that makes use of a well-worn scripting language like Python or Ruby. Happily such tools already exist.
    Sure, you can write meaningless stuff in XML, but at least you can validate, parse and transform it, and pretty much guarantee that it will be readable in future.
    If it's not readable now, how will it be readable in the future? ;)
    Those who complain too vigorously about XML should be forced to deal with the results of those who have actually gone ahead and written their own data parsers; only perhaps with somewhat out-of-date documentation, and with the parser written in a language or dialect that is no longer used. I have had too much experience of that to support the DIY approach.
    I agree with you but where I stand, the XML approach is hardly better than the DIY approach. Yeah, you don't have to write your own parser but that only gets you so far. One thing I've thought about is a simplified syntax that's structurally equivalent to the way that most people use XML that can easily be transformed into XML and therefore making use of all the tools that exist for it. Perhaps more than one such syntax could be defined. Then we might have our cake and eat it too.
  33. One thing I've thought about is a simplified syntax that's structurally equivalent to the way that most people use XML that can easily be transformed into XML and therefore making use of all the tools that exist for it. Perhaps more than one such syntax could be defined. Then we might have our cake and eat it too.
    Check out YAML: http://www.yaml.org
  34. One thing I've thought about is a simplified syntax that's structurally equivalent to the way that most people use XML that can easily be transformed into XML and therefore making use of all the tools that exist for it. Perhaps more than one such syntax could be defined. Then we might have our cake and eat it too.


    Check out YAML:

    http://www.yaml.org
    Damn, that's pretty much exactly what I was thinking. Too slow I guess (with some filled in blanks of course).
  35. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    Damn, that's pretty much exactly what I was thinking. Too slow I guess (with some filled in blanks of course).
    Actually, it's not exactly. It's a separate spec. I was more thinking of a pseudo XML. According to the spec: "Newcomers to YAML often search for its correlation to the eXtensible Markup Language (XML). While the two languages may actually compete in several application domains, there is no direct correlation between them." Not that YAML isn't great. I just have a ton of tools at hand that work with XML. Anyway, what I was thinking would look similar to YAML, i.e. with indention that is syntactically significant ala Python.
  36. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    I am afraid I still don't get the considerable and, it seems, increasing hostility towards XML.


    I'm not hostile towards it.
    Sorry, didn't mean to indicate you were. I was responding to the link, and vaguely commenting in general, and somewhat off-topic.
    I actually have used XML quite extensively and along the way, I figured out that there are things it is good for and things it is not so good for.

    It's a good way to specify data.
    It's a bad platform for writing code.
    Absolutely. But I find things like build 'scripts' ambiguous, as they combine features of configuration data and code.

    Sure, you can write meaningless stuff in XML, but at least you can validate, parse and transform it, and pretty much guarantee that it will be readable in future.


    If it's not readable now, how will it be readable in the future? ;) Ah - by 'readable' I mean easily parsable and transformable: machine-readable.
  37. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    But I find things like build 'scripts' ambiguous, as they combine features of configuration data and code.
    I can see your point. And ant does a good job at what it was designed to do. I just want something a little more powerful and easier to customize. I also find maintaining ant files to be a pain, although a good editor would help.
    Ah - by 'readable' I mean easily parsable and transformable: machine-readable.
    It was a poor attempt at a joke. It didn't really merit a response. I pretty much knew what you meant. I can't pass up an oppurtunity to get a cheap shot in. This is the year 2006.
  38. Re: Raven 1.1: Build Java with Ruby[ Go to top ]

    Say it takes you a day to learn how to use a new tool which can save you many days of work later on because it's a better fit for what you're trying to do. You'd still ignore it just because it's not in the "right" language?
    I guess others have already said this, but for me the big deal isnt me, today. During a 10-20 year product cycle, 30-50 developers might be involved in a particular software product. If I picked Java, I did so because I believed that the language has a chance to "last that long". Thats a risk, and I am unlikely to increase it by betting on one more language. It has nothing to do with "right" or "wrong" language.
  39. Pant? Pake? Paven?[ Go to top ]

    Does anyone know of similar tools that use Python instead? I'm tired of Ant 'scripting' and I already kind of know Python. Ruby has failed to excite me, though conceptually it seems very similar to Python. I'd like to keep the number of languages in our environment down to a minimum, though.