"Facilitate OSGi developer, framework independent" So, what I mean is that our tools should make OSGi developer daily life much easier through all phases: 1. startup: How do I start an OSGi project? We have Pax Construct that answer that. 2. build: I find myself doing repeating jobs. Packages, like in Pax Swissbox 3. deploy: Well, Pax Runner. Make it suitable not only for development but also for production use. e.g. ServiceMix4 goes OSGi. Shouldn't be nice for them to allow users to pick the runtime framework? 4. testing: Nothing here. And we should, as also Stuart is saying. And here we can do a lot as testing support can span a lot of areas: mocks, in framework testing, TCK like, scripting... 5. debugging: we have Pax Logger and Pax Reflector. We can put some more effort in Pax Reflector as a mean to explore state of osgi framework both while development and production. e.g. something goes wrong, bring up pax reflector and explore. Go step by step, search,... And we should have an appealing user interface. 6. runtime: once the framework is tarted can we control it remotely? Peter N started an interesting project here...
Second :), I think we should focus on useful bundles: * service implementations: as Pax Logger and Pax Web framework independent. Here we will face framework competition so we should have added vales in them. What about Initial Provisioning? can we do something there? * agents: like configuration admin agents, security, resource processors for Deployment Admin and so on. But, it will not be enough to just have nice/good implementations. In my view we should also have: * good documentation: what it is, how does it help, how to use it, easy startup, ... * popularize them: let people know that this tools exist. Blogs, conferences (stuart will present Pax at EclipseCon), can we et an article on TSS/InfoQ? Something like that :) Alin On Feb 5, 2008 10:49 PM, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > Gang, I want to invite everyone to clash their heads together and > start dreaming up what Pax should eventually become. What direction? > What other components? What focus? What is the holy grail of OSGi > interoperability? Call it a brain dump. I want ideas flowing, because > we need to step up the ambition by a few notches. We are slowly > becoming recognized for our framework independabilty (although we > favor Felix a little bit), so what's next? There are 80 people on this > list, so if everyone just pitch one idea, we get more than plenty. -- > Cheers, Niclas > > -- > Sent from Gmail for mobile | mobile.google.com > > _______________________________________________ > general mailing list > general@lists.ops4j.org > http://lists.ops4j.org/mailman/listinfo/general > _______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
