Hi, On Fri, Jul 22, 2011 at 5:24 AM, Christopher Coco <cac...@gmail.com> wrote:
> I'm wondering if anyone has picked up this thread: > > > http://old.nabble.com/buildr-pre-compile-JSP-for-war--td17109370.html#a17109370 Not that I am aware of. It's more than 3 years old, but Buildr still seems to be lacking this > functionality. I wrote a JSP pre-compiler specific for my company, but would > be willing to try to abstract it. Again, being new to Ruby and Buildr, I'm > trying to figure out the best way to integrate this functionality. It's java > specific, and I had thought that a c ouple of possibilities could be to > a.) extend the java compiler functionality (though jsp compilation seems > like a stretch here), > b.) to extend the WAR packaging functionality (where I'm leaning), > c.) separate it completely like the scala plugin (make this is more > robust?), > d.) or even just drop it in as an add-on (not sure the pros/cons). > > I'm looking for some views or opinions on a best approach. Any thoughts? > My approach has always bee d) where possible - it allows you to rapidly evolve the plugin and share it between all the different projects that use it. It also makes it easy to write tests and validate it easily. If the plugin gets general enough and well tested enough you can always donate it back to this project. This is the approach I took with various plugins. For example [1] is a plugin I developed outside as an extension that eventually folded back into buildr while [2] is something that I never get around to cleaning up. You will notice that many of the extensions I have made actually call out to ant tasks or directly call command line apps. I think this is a perfectly reasonable way to approach things. [1] https://github.com/realityforge/buildr-bnd [2] https://github.com/realityforge/buildr-ipojo -- Cheers, Peter Donald
