I think the best way to do this would be to include a pom.xml that generates the default Manifest in the widget template. Then the final step before uploading becomes just use maven to build the jar instead of zipping.
On Fri, Aug 03, 2012 at 01:50:43PM -0700, Carl Hall wrote:
> To be an OSGi bundle, the artifact needs to be a jar (zip file) and
> contain OSGi headers in META-INF/MANIFEST.MF. 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.
> If the widget bundle doesn't require any new server elements, a general
> manifest can be used, but once server elements are required, the manifest
> will have to be custom to the widget. If the widget also bundles those
> server elements, we can generate the manifest quite easily with a maven
> build.
> On Fri, Aug 3, 2012 at 3:58 AM, Nicolaas Matthijs
> <[1][email protected]> wrote:
>
> 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
> <[2][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][3]http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html
> 2�[2][4]http://ace.apache.org/
>
> On Wed, Jan 18, 2012 at 11:38 AM, D. Stuart Freeman
> <[3][5][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][6][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][7][email protected]
>
> _______________________________________________
> oae-dev mailing list
> [6][8][email protected]
> [7][9]http://collab.sakaiproject.org/mailman/listinfo/oae-dev
>
> --
> D. Stuart Freeman
> Georgia Institute of Technology
>
> References
>
> Visible links
> 1.
>
> [10]http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html
> 2. [11]http://ace.apache.org/
> 3. mailto:[12][email protected]
> 4. mailto:[13][email protected]
> 5. mailto:[14][email protected]
> 6. mailto:[15][email protected]
> 7. [16]http://collab.sakaiproject.org/mailman/listinfo/oae-dev
>
> _______________________________________________
> oae-dev mailing list
> [17][email protected]
> [18]http://collab.sakaiproject.org/mailman/listinfo/oae-dev
>
> --
> D. Stuart Freeman
> Georgia Institute of Technology
>
> _______________________________________________
> oae-dev mailing list
> [19][email protected]
> [20]http://collab.sakaiproject.org/mailman/listinfo/oae-dev
>
> _______________________________________________
> oae-dev mailing list
> [21][email protected]
> [22]http://collab.sakaiproject.org/mailman/listinfo/oae-dev
>
> References
>
> Visible links
> 1. mailto:[email protected]
> 2. mailto:[email protected]
> 3. http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html
> 4. http://ace.apache.org/
> 5. mailto:[email protected]
> 6. mailto:[email protected]
> 7. mailto:[email protected]
> 8. mailto:[email protected]
> 9. http://collab.sakaiproject.org/mailman/listinfo/oae-dev
> 10. http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html
> 11. http://ace.apache.org/
> 12. mailto:[email protected]
> 13. mailto:[email protected]
> 14. mailto:[email protected]
> 15. mailto:[email protected]
> 16. http://collab.sakaiproject.org/mailman/listinfo/oae-dev
> 17. mailto:[email protected]
> 18. http://collab.sakaiproject.org/mailman/listinfo/oae-dev
> 19. mailto:[email protected]
> 20. http://collab.sakaiproject.org/mailman/listinfo/oae-dev
> 21. mailto:[email protected]
> 22. 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
