Discussions

News: Raven 1.2: Build Java with JRuby

  1. Raven 1.2: Build Java with JRuby (19 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 adds support for JRuby 0.9.1 and JUnit test cases. 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 is available both as a gem or prepackaged in JRuby. Unzip, set the JRuby home and run. And starting JUnit tests is as simple as: junit 'run_tests' => 'compile' Check it out at http://raven.rubyforge.org/. More on http://mriou.wordpress.com

    Threaded Messages (19)

  2. What is it Raven gives me over ANT or Maven? If the answer is that it's written in Ruby... why would any of us care? -- maybe this is just an attempt to drum up some activity on tss in the slow tech news week before christmas. --
  3. It takes a lot of time and a lot of XML to get a build working with Ant. As for Maven it takes a lot of time to keep it working over time (at least with Maven2). The point of Raven isn't to be written in Ruby, it's to be built on top of Rake, a very nice build system. It's purely script which is much better than XML and allows you to write and maintain you build with far less pain (and time). You might be interested by the following article for more info about Rake: http://www.martinfowler.com/articles/rake.html (I have nothing to do with Martin Fowler, it's just a nicely written article.)
  4. It takes a lot of time and a lot of XML to get a build working with Ant.
    Depends on what type of a build your designing. If it's relatively standard and straight forward and doesn't require a lot of conditionals, logic, etc..., I'd say it's pretty fast.
    As for Maven it takes a lot of time to keep it working over time (at least with Maven2).
    Please explain? I've used Maven 2 on most projects in the last year + and have yet to run into any issues. It's less flexible than ant say, for highly customized builds, but I'd argue that we should waste our time on highly customizing builds for 90% of projects we work on and can greatly benefit form a standardized build structure. We can argue that war and ear archive are bad because they follow a strict packaging convention in that case. I think maven 2 rocks personally.
    The point of Raven isn't to be written in Ruby, it's to be built on top of Rake, a very nice build system. It's purely script which is much better than XML
    How is it better than XML? It's not a buld specific DSL per say. The only thing it does better than XML is allows you to actually program logic and conditionals into your build process. I'd argue that we should instead extend ant to allow embedding of scripts like jruby/jython, etc... instead of creating a completely scriptable system. XML is there to describe the build, scripting language should be there to fill in the gaps of things you can't easily describe. I don't see any benefit of a 100% scriptable build system over XML. In that case, I can just use a perl script and customize everything I want. Ilya
  5. Typo...
    but I'd argue that we should waste our time on highly customizing builds for 90% of projects we work on and can greatly benefit form a standardized build structure.
    I meant we shouldn't waste our time...
  6. It takes a lot of time and a lot of XML to get a build working with Ant.
    Huh? For an average Java programmer building working buildfile (compile, clean, package etc) takes, from my experience no more than 5 minutes. Add to this EXCELLENT IDE support with syntax highlighting, code completion, documentation, parameter hints, code snippets and even debugging makes Ant pretty convenient tool. So please don't spread informations like above. Especialy talking about half-baked, unknown, unsuported writen in different language tool like Raven. Does it have support for convenient creation of EARs at least? Artur
  7. What is it Raven gives me over ANT or Maven?

    If the answer is that it's written in Ruby... why would any of us care?
    Experience has shown that you need a scripting language with all control flow constructs for building complex systems (dozen of times I needed them). Declarative and functional aspects of Ant are simply not enough. Although there are third-party tasks for condition (if-then-elsif-else, choose-when...) and iteration, it's a pain using them with all that XML syntax.
  8. What is it Raven gives me over ANT or Maven?

    If the answer is that it's written in Ruby... why would any of us care?


    Experience has shown that you need a scripting language with all control flow constructs for building complex systems (dozen of times I needed them). Declarative and functional aspects of Ant are simply not enough. Although there are third-party tasks for condition (if-then-elsif-else, choose-when...) and iteration, it's a pain using them with all that XML syntax.
    Agree, and it's also a pain describing things that should be by nature declarative using a scripting language. Though we need a mix of both. We should be able to hook into the ANT APIs and have support for scripting right within the ant build file, or by referencing some external script, though ant should be able to pass it's control flow onto those scripts for that particular scope. Ilya
  9. I've seen similar approaches (using Perl instead of Ruby) and IMHO , it just ends up a mess. People supporting the system have to know Java *and* the 2nd language. If your build is so complicated that you need to power of a full blown scripting language, then perhaps you need to look again at your project structure. The Java community should focus on improving ANT / Maven (which does have many drawbacks), rather than use a solution , while good for it's niche (e.g. if you're already using Ruby / JRuby in your application) is going to hinder rather than help in most situations. Paul , Technology in Plain English
  10. I've seen similar approaches (using Perl instead of Ruby) and IMHO , it just ends up a mess.
    Yes, but simulating control flow constructs with targets/dependencies/if/unless with modest expressions available in Ant could lead too to real mess.
    If your build is so complicated that you need to power of a full blown scripting language, then perhaps you need to look again at your project structure.
    I believe this is wrong. There are number of common cases when you need control flow constructs in build scripts (condition, iteration, exception handling), even in moderate complex projects: - deploying to different environments needs condition. Something is deployed to UAT, something not, etc... - when deploying for the first time to the environment you do different things then when upgrading environment (for example you may need to stop your system before upgrading environment) - you may need try-catch-finally construct to to clean-up when build fails (for example to undo incrementation of build number) People with more experience in writing build scripts can sure give you more examples. It's the fact of life: you need more powerful control flow/exception handling/variables and expressions in build scripts then you have it with Ant. I saw couple of times extraordinary complex Ant builds that could be much simpler if Ant were more powerful. Maybe retrofitting Ant with scripting language is not a good idea, but Ant sure is passing it's zenith, we need another (more expressive) build tool, but with all the goodies of existing Ant tasks.
  11. Re: Raven 1.2: Build Java with JRuby[ Go to top ]

    Raven could have been the silver bullet for building projects if the learning of a new language was not required. Anyway, congrats on your work.
  12. Beanshell *rulez*[ Go to top ]

    IMHO there is no need for any Ant replacement. You can easily extend Ant with a scripting language like Beanshell without the need to compile anything or mess with your Ant classpath. I blogged about it here: http://ptrthomas.wordpress.com/2006/12/18/how-to-shutdown-hsqldb-from-ant/
  13. Re: Beanshell *rulez*[ Go to top ]

    Also, Ant properties and expressions need to be more powerful. These are much better in NAnt (functions, custom functions, etc), but still not perfect. Maybe standard EL could be used?
  14. Re: Beanshell *rulez*[ Go to top ]

    IMHO there is no need for any Ant replacement. You can easily extend Ant with a scripting language like Beanshell without the need to compile anything or mess with your Ant classpath.

    I blogged about it here:

    http://ptrthomas.wordpress.com/2006/12/18/how-to-shutdown-hsqldb-from-ant/
    This is no different than using an exec task and executing some shell script, or any other interpreter with a script file. I think what's needed is a tighter integration, where besides being able to execute arbitrary scripts/commands, you can actually execute an interpreted snippet within ant's runtime with the access to it's properties/APIs. Ilya
  15. Re: Beanshell *rulez*[ Go to top ]

    This is no different than using an exec task and executing some shell script, or any other interpreter with a script file.
    Well, just for argument's sake, I updated the post showing how you can have the script inline - within the Ant file itself. http://ptrthomas.wordpress.com/2006/12/18/how-to-shutdown-hsqldb-from-ant/ It is a bit of a hack but it works. Apologies for linking back to my blog, but I was not sure about XML escaping over here. My main point is that there is no need to learn a new language.
    I think what's needed is a tighter integration, where besides being able to execute arbitrary scripts/commands, you can actually execute an interpreted snippet within ant's runtime with the access to it's properties/APIs.
    I do agree, we should improve Ant rather than try to go after other languages.
  16. Re: Beanshell *rulez*[ Go to top ]

    IMHO there is no need for any Ant replacement. You can easily extend Ant with a scripting language like Beanshell without the need to compile anything or mess with your Ant classpath.

    I blogged about it here:

    http://ptrthomas.wordpress.com/2006/12/18/how-to-shutdown-hsqldb-from-ant/


    This is no different than using an exec task and executing some shell script, or any other interpreter with a script file.

    I think what's needed is a tighter integration, where besides being able to execute arbitrary scripts/commands, you can actually execute an interpreted snippet within ant's runtime with the access to it's properties/APIs.

    Ilya
    There is such an effort under way. It's called Gant (Groovy Ant). I've tried it with couple of prototype build scripts and I like it! http://groovy.codehaus.org/Gant Regards, Dmitriy.
  17. Re: Beanshell *rulez*[ Go to top ]



    There is such an effort under way. It's called Gant (Groovy Ant). I've tried it with couple of prototype build scripts and I like it!

    http://groovy.codehaus.org/Gant

    Regards,
    Dmitriy.
    That actually sounds interesting. By looking at it, it still seems as it's taking you away from XML. I don't think XML is bad. It's very readable in many instances, plus you get out of the box completion, validation, etc... support with most IDEs. The issue comes when XML is used as a DSL. I think a mix of Ant XML and some scripting (or any) language is needed. Basically it's about extending ant and allowing for some custom script task that has access to some Ant runtime interface. Or actually, a better approach would be to allow some sort of an AOP facility for tasks. So each task that's already there, can be extended with some scripting functionality using AOP. So say, ... task specific configs... And each task, might be able to provide other pointcuts that are custom for a task. So a task execute can be a template method pattern, that allows to inject some custom code anywhere within it. This is just off the top of my head, I'm sure it can be designed in a more robust way. But such a system would allow to easier extend current tasks, without having to write custom tasks each time something is needed that is not supported by available libraries. Ilya Sterin
  18. Re: Beanshell *rulez*[ Go to top ]

    "By looking at it, it still seems as it's taking you away from XML." That's the point....this is a good thing. XML wasn't designed to be a scripting language... Try doing iterations or if-then conditions with XML . You can do it, but it's awfully painful. Writing your own custum tasks is a pain compared to just utilizing a scripting language.
  19. Re: Beanshell *rulez*[ Go to top ]

    I retract my comment after reading your reply again :)
  20. XML as script is bad..[ Go to top ]

    It is a hell of a lot harder to have good AntXML files for large J2EE (200k+ loc) projects then small apps.. AntXML works great when its just some simple declared targets but when the files grow and you start to have alot of imported AntXML files and dependencies and conditionals then you tend to get a mess.. I have done some testing with BeanShell and Groovy with Ant and it works excelent.. BeanShell and Groovy are so tightly integrated with java and the languages are very java like so i think there is a smaller step to learn those then to learn AntXML. Also learning a scripting language is not a burden but a lot of fun. XML is not good as a scripting language.. It was not designed to be used that way.. that is why AntXML (when used advanced) and XSLT suck bigtime.. Ant's tasks are however great so a combination of a powerfull but readable scripting language (that is easy to learn for java programmers) we have a winning combination.