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 [email protected] http://lists.ops4j.org/mailman/listinfo/general
