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
