On Wed, Feb 2, 2011 at 1: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. > Trashcan is a harsh term but works usually to makes the point for "common-***" libraries sometimes ;) > > *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! > Yes will do so. > > *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? > Will also put this into a single "article" but just a few more concrete examples: - Imagine a fictive (for example: dutch) company (for example FM) that wants to start over with OSGi, but needs to use existing infrastructre. So the requirement is to can it into a WAR "bootstrapping" component. Gouken is a library that replaces this. Either totally providing a pre-made war assembly that has everything inside already, comes in different management agent flavours (say one contains the MA for a real Apache ACE, another one uses FileInstall .e.g) But those pre-made assemblies (WAR,EAR,APK,BeanstalkWAR, GAE-WAR etc.) are just the next step. Its more crucial to see that the Gouken API introduces to types "Vault" [1] and "VaultAgent" [2] that are conceptually above the rough OSGi launcher API and limit the only means of user control (user=user of gouken api!) to what "Management Agent" you actually install. So, you could call it a "managed osgi framework" on that side. To me, the meaning of a "Management Agent" role+type should be part of the OSGi API + Specification. Gouken development depends on Pax Repository development - thats why i put this project into this List, its one of the first use cases of Pax Repo. To me its also an evolution to Pax Runner because it takes the whole "bootstrapping OSGi" to a higher, more integrated level. Some words on Gouken - its really artificial. Currently it could better be called "Pax Vault" (see the main types in [1] and [2]. About the "Plugin" thing i mentioned, well yes, there are ideas to sit on top of the core gouken api and bake more specific code-level integration layers. So, now we have this heavily simplified embedding principle. I can also think of an embedding case where the goal for OSGi is to enable loading/unloading/adding some sort of extra functionality in a legacy system at runtime. You can do the work manually but there might be chance to provide a solution for 70% of the usecases of such a plugin system. Why i see this in the Gouken scope ? Because those plugins are presumably not full blown OSGi components with activators and such. More a classic "jar" that is being enriched at runtime (extender pattern). This integrated work on many ends (embedding into legacy system, wire up the points of injection, have some pre-canned plugin format that people can use without knowing too much of OSGi). Hint: This whole thing is not about trying to hide OSGi from the developer. Its more about making OSGi more compatible with existing systems and more engaging to "just use it" because the bottom layer (integration work, wiring up the classloader delegation when embedding) has been done already for you. I know many OSGi starters are also afraid of "amount of small grained bundles" in my system. Having a managed environment where the words Bundles and low level things like "bundlecontext" is not part of the initial provisioning is a good thing in my opinion. Its up to the management agent to abstract that "single bundles" view to a more service oriented view after the "system" is up and running. Thats where ACE plugs in hopefully ;) I just see those command-line starters a thing of the past. It should be simple to have your "vault" regardless how it is deployed and initially provisioned. Hopefully that sheds some light into the initial motivation and not confuses too much. Toni [1] https://github.com/tonit/gouken/blob/master/gouken-api/src/main/java/com/okidokiteam/gouken/Vault.java [2] https://github.com/tonit/gouken/blob/master/gouken-api/src/main/java/com/okidokiteam/gouken/VaultAgent.java > > > 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 > > -- *Toni Menzel - http://www.okidokiteam.com*
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
