I'm liking the sound of this... <expected drupal analogy> Drupal has had an issue with its module repo where modules weren't able to express dependencies/versions in reliable ways and it would be good to avoid that mess. </expected drupal analogy>
= nate On Tue, Jul 24, 2012 at 1:04 PM, Erik Froese <[email protected]> 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.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 > > > > _______________________________________________ > > 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
