I would need to investigate the code a bit to find where the java command forks. Probably annoying enough that we should file a bug for this...
For the second part: https://github.com/intalio/wapama/blob/master/Buildfile https://github.com/atoulme/logBot/blob/master/Buildfile Both examples show complex zips of distribs created based on package(:zip). Antoine On Wed, Jul 27, 2011 at 19:29, Ian Nowland <[email protected]> wrote: > I've got a buildr/jetty/jersey setup I've been playing around with (that > took an annoyingly long time to get configured) which is working pretty > much > as I would like it to, except for that the process seems to kick off on > it's > own, meaning I can't see console output and I have to kill -9 it whenever I > want it to stop. I'm setting it off with a pretty typical: > > task :run => :compile do > puts('Starting up with classpath ' + compile.dependencies.to_s + " " > + [compile.target.to_s].to_s) > Java::Commands.java('launcher. > MyServer', :classpath => compile.dependencies + [compile.target.to_s]) > end > > And then in launcer.MyServer.scala > > object MyServer { > > def main(args: Array[String]) { > > > System.out.println("Starting up server") > > val server = new Server(8080) > val connector = new SelectChannelConnector() > server.addConnector(connector) > > val holder:ServletHolder = new ServletHolder(classOf[ServletContainer]) > > > holder.setInitParameter("com.sun.jersey.config.property.resourceConfigClass", > > "com.sun.jersey.api.core.PackagesResourceConfig") > holder.setInitParameter("com.sun.jersey.config.property.packages", > "com.sample") > val context = new ServletContextHandler(server, "/", > ServletContextHandler.SESSIONS) > context.addServlet(holder, "/*") > server.start > server.join > } > } > > > When I 'buildr run', while things seem to start up fine, I never see the > "Starting up server" line. When I kill the buildr:run with a ctrl-c, as I > mentioned before, the server stays alive. > > What's a more manageable way to launch the process? > > For bonus points, the documentation is a little sparse on suggestions for > how to package my code into something a bit more publishable/distributable > (which I realize is really a general problem that applies to all build > tools...still, it'd be nice). Are there any suggestions for how to tie a > bow > around this system, or is the best thing to do really just to jar it up, > with a script that does a java -jar? > > Thanks, > > Ian >
