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.html > 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
signature.asc
Description: Digital signature
_______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
