Would it be possible to mock up an example as to how a widget would look like as an OSGi bundle? We've got some widgets in our widget library that are stand-alone (e.g. ToDo widget) and widgets that require a back-end bundle (e.g. Zotero widget), and it's probably worth seeing how both of those would look like when wrapped as an OSGi bundle.
As easy widget development is a strong goal of the project, I'd hate to complicate things because of this. I'm assuming wrapping widgets up into OSGi bundles will be a huge win for deployers, but not as much for widget developers. Would automatic wrapping of widgets into OSGi bundles when downloaded from the Widget Library be an option as well? Thanks, Nicolaas On 24 Jul 2012, at 21:04, Erik Froese wrote: > +1 for using the OSGi OBR repository > > Its definitely worth it. You could even have widgets that list certain > backend bundles as dependencies and have everything download and > install. > > Erik > > On Tue, Jul 24, 2012 at 3:43 PM, D. Stuart Freeman > <[email protected]> wrote: >> AFAIK we aren't yet distributing widgets as OSGi bundles, but it >> wouldn't >> be a huge change to get there (other than compiling all the existing >> widgets, I think there are 12 so far). >> >> It could simplify some aspects of the widget upload process, for >> instance >> you wouldn't have to specify the version in a web form if the >> widget library >> unpacked the manifest and read the version out. >> >> On Tue, Jul 24, 2012 at 09:27:09AM -0700, Carl Hall wrote: >>> I was wondering where this ended up. Are those working on the >>> widget >>> store/library using OSGi bundles or was that scrapped? I'd hate >>> to ignore >>> all of the infrastructure already available[1][2] for this in >>> lieu of >>> writing it ourselves. >>> Apache Rave also has a widget store but that may not make sense >>> to use at >>> this point given where our own widget store development is. >>> 1�[1]http://felix.apache.org/site/apache-felix-osgi-bundle-repository.ht >>> ml >>> 2�[2]http://ace.apache.org/ >>> >>> On Wed, Jan 18, 2012 at 11:38 AM, D. Stuart Freeman >>> <[3][email protected]> wrote: >>> >>> On Wed, Jan 18, 2012 at 02:13:37PM -0500, Carl Hall wrote: >>>> � �@Daniel, I think automating this for widget devs is a must. >>>> There >>> are some >>>> � �fields that a user will want to add (Bundle-Name, >>> Bundle-Descriptions, >>>> � �etc) but nothing that a placeholder can be used. >>> >>> I think we could automatically fill those in with the SDK widget >>> generator, as it prompts the user for a widget name and >>> description that >>> get put into some widget json. Just piggy back on that and use >>> the same >>> values for the manifest. >>>> >>>> � �@Nico, a prime example of this is in >>>> � �${3akai-ux}/target/classes/META-INF/MANIFEST.MF. This file >>>> is >>> generated by >>>> � �maven during the 3akai-ux build. The difference for a >>>> widget vs. >>> the whole >>>> � �ux is that the Sling-Initial-Content header would be much >>>> simpler. >>>> >>>> � �On Wed, Jan 18, 2012 at 9:09 AM, N. Matthijs >>>> � �<[1][4][email protected]> wrote: >>>> >>>> � � �Hi Carl, >>>> >>>> � � �I think this is a great idea. Giving institutions the >>>> ability to >>>> � � �download a >>>> � � �widget from the Library and just throw it in their >>>> Felix console >>> sounds >>>> � � �like a great way to get started. I'm not terribly >>>> worried about >>> the >>>> � � �manifest >>>> � � �file as we could automatically generate that in the >>>> Widget >>> generator. >>>> � � �Of course, if Daniel's suggestion around adding the >>>> manifest file >>>> � � �automatically (when missing) upon upload is possible, >>>> that would >>>> � � �be even better. >>>> >>>> � � �Could you mock up a widget that contains this manifest >>>> file so we >>>> � � �can see how this would look like? >>>> � � �> There has already been significant work done to >>>> bolster the >>> content in >>>> � � �> OBRs[2][3] and distribution frameworks based on >>>> OBR[4]. If you >>> check >>>> � � �> the console on an OAE server, you'll find an "OSGi >>>> Repository" >>> tab. >>>> � � �This >>>> � � �> is how any widget store (firewalled/institutionally >>>> managed, >>> fully >>>> � � �public, >>>> � � �> etc) could show up on servers. The community managed >>>> store >>> would >>>> � � �> continue with it's web UI but could also get for free >>>> an >>> in-server >>>> � � �client >>>> � � �> to add widgets and other bundles directly to the >>>> server(s). >>> OBRs can >>>> � � �> also resolve dependencies, so the server and UI could >>>> be >>> developed >>>> � � �> modularly and package management is done by the the >>>> OBR. There >>> is >>>> � � �> a spec being worked out for the OBR6]. >>>> >>>> � � �This sounds like a very exciting prospect as well. I'd >>>> love us to >>>> � � �explore >>>> � � �this for the second step in this Widget Library story. >>>> >>>> � � �Thanks! >>>> � � �Nicolaas >>>> >>>> References >>>> >>>> � �Visible links >>>> � �1. mailto:[5][email protected] >>> >>>> _______________________________________________ >>>> oae-dev mailing list >>>> [6][email protected] >>>> [7]http://collab.sakaiproject.org/mailman/listinfo/oae-dev >>> >>> -- >>> D. Stuart Freeman >>> Georgia Institute of Technology >>> >>> References >>> >>> Visible links >>> 1. http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html >>> 2. http://ace.apache.org/ >>> 3. mailto:[email protected] >>> 4. mailto:[email protected] >>> 5. mailto:[email protected] >>> 6. mailto:[email protected] >>> 7. http://collab.sakaiproject.org/mailman/listinfo/oae-dev >> >>> _______________________________________________ >>> oae-dev mailing list >>> [email protected] >>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev >> >> >> -- >> D. Stuart Freeman >> Georgia Institute of Technology >> >> _______________________________________________ >> oae-dev mailing list >> [email protected] >> http://collab.sakaiproject.org/mailman/listinfo/oae-dev >> > _______________________________________________ > oae-dev mailing list > [email protected] > http://collab.sakaiproject.org/mailman/listinfo/oae-dev _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
