Maybe...maybe not. When you run the JAR resulting from "--execute=jar" (using "java -jar myapp.jar") will you still be able to interact with the framework, installing, updating, stopping, and starting bundles?
Also, I'd rather this come in the form of a Maven plugin or Pax Construct script so that I can make it part of my build process. I suppose that I could build everything as I do now and then as a last step use Pax Runner with "--execute=jar" to produce the big JAR file... In any event, it sounds like you've got a good idea going, regardless of whether it meets my needs or not. Once it's in place, I'll take a look and see if it fits what I'm trying to do. In the meantime, I may still explore a Maven-ish or Pax Construct script to do what I'm talking about. Toni Menzel wrote: > hey guys, > > the reason why paxbucket stopped for awhile was - among implementing > paxdrone ;-) - was that the this is a first class citizen of paxrunner. > After mingling with alin about that he agreed. > Since i have some more insight into paxrunner now i might now have a > completely different idea about doing it and probably will do that later. > Here is the main idea: > 1.) have an extra option on paxrunner like "--execute=now|jar|remote" > where > "now" is the current behaviour and will spawn a new process (new vm > after paxrunner finished all preparing work) > "jar" or "bucket" is what we/you want from paxbucket > "remote" is a different beast but came up recently: why not execute > that on a different machine. of cause additional configuration is > necessary.. but could be interesting. > > 2.) so for the "jar" option paxrunner would, instead of spawning the > new process just zip everything into a jar and add a Main-Class header > to the manifest where the main class is part of what paxrunner knows > anyway. > From here it looks quite promissing. The only thing you won't have > (when comparing to paxbucket) is the "keep working on the framework, > add bundles, remove bundles and then export it afterwards". > But this is not really necessary and can be sacrified for simplicity. > > From here i think its a small thing. @Craig: wdyt ? Will that cover > your needs. If so, we will add this to jira asap. > Then we might have a solution (from my side) by the weekend - cause i > currently have something on my plate. > > /Toni > > > On 16.07.2008, at 16:51, Craig Walls wrote: > >> >> Yes...that's similar to what I have in mind. The only thing is that >> it sounds like Pax Bucket would result in the OSGi-ness of the >> application being lost at runtime...can I still stop, start, update, >> or otherwise manipulate my bundles at runtime or would I have to >> redeploy the whole distribution again to do updates? What if I have >> "plugin" bundles? Could I add those to a Pax Bucket-ized application >> after the bucket has been initially deployed without giving the >> customer a whole new bucket? >> >> What I'm looking for is something that just packages up Pax Runner, >> the framework, and all of the application bundles (and their >> dependencies) in a single distribution, along with a script or >> something that kicks off everything. It's a one-time distribution >> convenience. After that, I still want to be able to interact with the >> framework to be able to manipulate bundles. >> >> Nonetheless, I like Toni's thinking on this. I may have to look into >> it further. >> >> >> Stuart McCulloch wrote: >>> 2008/7/16 Craig Walls <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>: >>> >>> >>> Here's a crazy question for you...and maybe a suggestion for Pax >>> Construct... >>> >>> I like how pax-provision uses Pax Runner to automatically kick off >>> the container with my bundles in place. Great stuff. (Unless I'm >>> missing something), it draws those bundles from my Maven >>> repository...which is great for development-time running of my >>> app. But let's say that I'm ready to deploy my app to production >>> or to a customer and I want to package up all of my bundles (and >>> their dependencies) along with a Pax Runner provisioning file that >>> pulls the bundles from a directory or perhaps a ZIP file. In other >>> words, I want a Pax Construct script that pulls all of the >>> dependencies out of a Maven repo, places them in a directory >>> somewhere along with a script to kick off Pax Runner, and either a >>> provisioning file that points to all of the "local" bundles or a >>> scan-dir: in the script that points to a ZIP file containing the >>> bundles. And then...it'd be really cool if the script also zipped >>> all of that up into a distribution file (or files...zip, .tar.gz, >>> etc) for distribution to my customers. >>> >>> I know that one of the cool things about OSGi is that I can do >>> updates of my app a bundle at a time, so such a distribution may >>> have limited use once the app is running. But for the first-time >>> install, it'd be nice to have a ZIP file with everything I need in >>> it along with a script to kick off the OSGi framework. >>> >>> Before you say anything, yes I know that OPS4J is open and I could >>> contribute such a thing myself. And I might do that. But before I >>> do, I wanted to throw it past you and see what you think. And to >>> see if maybe there's already something that I've overlooked that >>> does that kind of thing. >>> >>> >>> ah, this sounds a lot like a lab project Toni was working on recently: >>> >>> http://wiki.ops4j.org/confluence/display/ops4j/Pax+Bucket >>> >>> basically it's a set of bundles that watch what you deploy and >>> assembles >>> everything up (including the framework) inside a single runnable jar >>> with no >>> external dependencies >>> >>> it's still work-in-progress, but very promising (for the reasons you >>> give above) >>> >>> Stuart McCulloch wrote: >>> >>> 2008/7/12 Craig Walls <[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]>>>: >>> >>> >>> >>> Stuart, >>> >>> >>> Hi Craig >>> We've exchanged a few e-mails on the Felix >>> mailing list, but I >>> wanted to formally introduce myself off-list. I'm Craig >>> Walls, the >>> author of Manning's /Spring in Action/, Spring fanatic, OSGi >>> fanatic, and all-around computer nerd. >>> >>> >>> ah yes, I liked your blog post about Pax-Runner >>> >>> Actually, I'm doing a lot of OSGi-related work lately, both >>> in my >>> day job and in off-job hours. In fact, I'm doing a bit of >>> writing >>> about OSGi...I'm not ready to share a lot of details on >>> that, but >>> you'll hear about it soon. >>> >>> >>> excellent - always good to hear people writing about OSGi, >>> will look forward to hearing more in the future! >>> I just wanted to say that your name has crossed >>> my path several >>> times in the past couple of weeks, specifically with regard >>> to the >>> Maven bundle plugin and with Pax Construct. And I gotta >>> tell you >>> that I'm now officially a HUGE fan of Pax Construct. Very >>> very >>> nice work! It gives a very Ruby-on-Rails feel to working >>> with bundles. >>> >>> >>> thanks, like a lot of code it started off as a simple tool to >>> help me write some in-house OSGi tutorials >>> and just snowballed from there - btw it's very much "JIRA" >>> driven, so if you want a new feature please >>> suggest it on JIRA ( or feel free to go in and hack the code >>> yourself, that's the OPS4J philosophy :) >>> >>> Anyhow, I thought I'd introduce myself and add you to my >>> network. >>> >>> Craig >>> >>> >>> -- Cheers, Stuart >>> >>> >>> >>> >>> >>> -- >>> Cheers, Stuart > _______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
