Hi, I'll echo Craig's needs. The --execute=jar option would be nice, but I'd still like to be able to distribute my app as a small jar + directory full of bundles so that my users can see what's being run, add bundles as needed, and generally get a sense of how to tweak things. I'm sure most of this can be accomplished with a maven assembly, but having Pax-Runner configure the osgi provisioning would be great.
thanks, Mike On Wed, Jul 16, 2008 at 10:20 AM, Craig Walls <[EMAIL PROTECTED]> wrote: > > 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 > [email protected] > http://lists.ops4j.org/mailman/listinfo/general > -- ____________________________________________________________ Michael Smoot, Ph.D. Bioengineering Department tel: 858-822-4756 University of California San Diego
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
