Fully agree on Marcel's comments. On Wed, Feb 2, 2011 at 8:22 AM, Marcel Offermans <[email protected]> wrote: > My 2 cents (comments inline)... > On 2 Feb 2011, at 1:05 , Toni Menzel wrote: > > Pax Tinybundles > This is just the divorce of the Pax-Swissbox-Tinybundles component from the > Swissbox Project. > Reasons: > 1. Tinybundles is growing - had a fork in Exam 2 for a while. Also it always > felt more like a standalone thing than a "part of a swiss box". > 2. Release independence from Swissbox (shorter cycles) > 3. I (personally) prefer more specific projects over "trashcan"-like > common-components with unknown content of everything. > > I'm in favor of releasing this separately, as I've had several use cases in > the past where I just needed TinyBundles. I also like the argument about not > creating "umbrella" (or "trashcan" as Toni calls them) projects. > > Pax Repository [1] > Currently sits in my Github repo, was made for Pax Exam2 and another > internal project. > That will need a lot more writeup - but in essence it is: > - The API friendly cousin of Pax URL. Makes programming against "resources" > from "somewhere" cleaner. > - Perfect (in my initial usecase) for initial provisioning of systems that > can consume resources at runtime (OSGi is a good example, consider an > embedded OSGi Framework that needs to be initially provisioned with some > management agent. After that, that agent takes over.) > > Sounds promising. Looking forward to more writeup! > > Gouken [2] > Also sits partially in my Github repo. Some parts need OSS clearance, but it > should be a no brainer. It is basically a embedded container that we call > "Vault" (think of an OSGi container, but not limited to it) for all kinds of > environments (classic WAR projects, possibly Android APKs, tailored versions > for GAE etc.). > This "container" can be fed with different management agents upon startup. > All communication after that "initial provisioning" then happens over that > agent (Which can be a full blown thing like Apache ACE or just a local > FileInstall based implementation. Its crucial to know that Gouken defines a > simplified view on OSGi, so that its entirely managed without mentioning the > terms OSGi, Bundle or BundleContext. > The current use case is to provide a drop-in library for legacy systems > (EARs,WARs) in a way that Plugin-Functionality can be implemented without > radically pulling everything over to OSGi at once. > Granted, this needs a bigger writeup - but it should be enough to tease the > idea. > > Please do extend this description a bit. From what you're saying now I > understand Gouken is a container, more simple to deal with than "plain OSGi" > and you can drop in different types of plugins. It help with migrating > non-modular applications, so is its main use case? > > Not sure if it should be under the Pax Umbrella or not because its not > inherently bound to OSGi only. In this projects its an implementation > detail. > > No opinion about that. > Greetings, Marcel > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general > >
-- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/24svnvk I relax here; http://tinyurl.com/2cgsug _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
