Contrib bundles.
We (Sakai Kernel Development Team), are starting to create a number of OSGi bundles and services as extensions to Sling. They are all A2 licensed (why would you choose anything else :)). Without wanting to bloat the Sling code base unnecessarily, is there interest in code contributions to Sling?, or at least co-ordination to avoid duplication. (and stupid mistakes on our part) Current development tree is on github at http://github.com/ieb/open-experiments/tree/master , its only been going a few weeks. Most of the bundles of interest use the scr plugin. Some of the Sling committers are lurking on our mailing list but I thought it would be appropriate to mention it here to show real interest on our part. Ian
Re: Contrib bundles.
Hi Ian, On Fri, Apr 17, 2009 at 10:10 AM, Ian Boston wrote: > We (Sakai Kernel Development Team), are starting to create a number of OSGi > bundles and services as extensions to Sling. They are all A2 licensed (why > would you choose anything else :)). Without wanting to bloat the Sling code > base unnecessarily, is there interest in code contributions to Sling?, or at > least co-ordination to avoid duplication. (and stupid mistakes on our part)... I think we're particularly interested in contributions that are of general interest - JAX-RS, Guice integration, XML-related tools, those things stand out after having a quick look at your github stuff. Such contributions should be sustainable for the Sling project. Simple enough modules that we're confident we can maintain ourselves can be fine, and good automated tests also help a lot in making code sustainable. I think the best would be sustained contributions from the Sakai people, that might lead us to make some of the Sakai committers Sling committers as well, following the usual merit-driven procedure of course. Given that you are already a committer on Shindig, I won't need months before pushing to make you a committer once I see good stuff here...but the final decision is in the hands of the Sling PPMC and Incubator PMC of course. We are willing to expand the Sling community, and having more ties between Sakai and Sling makes a lot of sense IMHO, as we discussed at ApacheCon (FYI Sling folks, some people from the Sakai team were around and we had good informal discussions about possible synergies). Right now, the best might be for you guys to suggest some modules that could be contributed to Sling, and we can take if from there. -Bertrand
Re: Contrib bundles.
We (Sakai Kernel Development Team), are starting to create a number of OSGi bundles and services as extensions to Sling. Can you describe what the functionality of these are and what the Sakai project aim to do? I had a look at http://groups.google.com/group/sakai-kernel/web/why-what-how-k2 and it's a bit vague, but it seems to be some sort of community software? -- Torgeir Veimo torg...@pobox.com
Re: Contrib bundles.
Bertrand, I will get some time dedicated to better unit tests. I suspect initially the lower lever modules like the ones you have mentioned are going to be better targets as they have fewer external bindings. I will let you know when bundles stabilize, and have > 90% test coverage. Personally I would be interested in a role within Sling, but only based on relevant merit and an ability to dedicate time to make a appropriate and continued contribution. Ian On 17 Apr 2009, at 10:10, Bertrand Delacretaz wrote: Hi Ian, On Fri, Apr 17, 2009 at 10:10 AM, Ian Boston wrote: We (Sakai Kernel Development Team), are starting to create a number of OSGi bundles and services as extensions to Sling. They are all A2 licensed (why would you choose anything else :)). Without wanting to bloat the Sling code base unnecessarily, is there interest in code contributions to Sling?, or at least co-ordination to avoid duplication. (and stupid mistakes on our part)... I think we're particularly interested in contributions that are of general interest - JAX-RS, Guice integration, XML-related tools, those things stand out after having a quick look at your github stuff. Such contributions should be sustainable for the Sling project. Simple enough modules that we're confident we can maintain ourselves can be fine, and good automated tests also help a lot in making code sustainable. I think the best would be sustained contributions from the Sakai people, that might lead us to make some of the Sakai committers Sling committers as well, following the usual merit-driven procedure of course. Given that you are already a committer on Shindig, I won't need months before pushing to make you a committer once I see good stuff here...but the final decision is in the hands of the Sling PPMC and Incubator PMC of course. We are willing to expand the Sling community, and having more ties between Sakai and Sling makes a lot of sense IMHO, as we discussed at ApacheCon (FYI Sling folks, some people from the Sakai team were around and we had good informal discussions about possible synergies). Right now, the best might be for you guys to suggest some modules that could be contributed to Sling, and we can take if from there. -Bertrand
Re: Contrib bundles.
Hi Ian, Ian Boston schrieb: > Bertrand, > I will get some time dedicated to better unit tests. I suspect initially > the lower lever modules like the ones you have mentioned are going to be > better targets as they have fewer external bindings. I will let you know > when bundles stabilize, and have > 90% test coverage. Personally I would > be interested in a role within Sling, but only based on relevant merit > and an ability to dedicate time to make a appropriate and continued > contribution. Personally, I think, if you (or others) could commit to maintain the contributions, they need not be perfect at the time of contribution ;-) And "a role within Sling" is generally a natural consequence of maintaining the contributed stuff ;-) Regards Felix > Ian > On 17 Apr 2009, at 10:10, Bertrand Delacretaz wrote: > >> Hi Ian, >> >> On Fri, Apr 17, 2009 at 10:10 AM, Ian Boston wrote: >>> We (Sakai Kernel Development Team), are starting to create a number >>> of OSGi >>> bundles and services as extensions to Sling. They are all A2 licensed >>> (why >>> would you choose anything else :)). Without wanting to bloat the >>> Sling code >>> base unnecessarily, is there interest in code contributions to >>> Sling?, or at >>> least co-ordination to avoid duplication. (and stupid mistakes on our >>> part)... >> >> I think we're particularly interested in contributions that are of >> general interest - JAX-RS, Guice integration, XML-related tools, those >> things stand out after having a quick look at your github stuff. >> >> Such contributions should be sustainable for the Sling project. Simple >> enough modules that we're confident we can maintain ourselves can be >> fine, and good automated tests also help a lot in making code >> sustainable. >> >> I think the best would be sustained contributions from the Sakai >> people, that might lead us to make some of the Sakai committers Sling >> committers as well, following the usual merit-driven procedure of >> course. Given that you are already a committer on Shindig, I won't >> need months before pushing to make you a committer once I see good >> stuff here...but the final decision is in the hands of the Sling PPMC >> and Incubator PMC of course. >> >> We are willing to expand the Sling community, and having more ties >> between Sakai and Sling makes a lot of sense IMHO, as we discussed at >> ApacheCon (FYI Sling folks, some people from the Sakai team were >> around and we had good informal discussions about possible synergies). >> >> Right now, the best might be for you guys to suggest some modules that >> could be contributed to Sling, and we can take if from there. >> >> -Bertrand > >
Re: Contrib bundles.
Yes, sorry, the why-what-how-k2 has been rewritten many times. I will try and give a brief description. Sakai addresses collaboration in Teaching, Learning and Research mainly in higher educational institutions and is in production at about 160 institutions world wide. University of Cambridge for whome I work runs a version[1] supporting student teaching and research group collaboration as well as societies and colleges. The code base is open source, licensed under the Educational Community License 2 a derivation of the A2 license, with copyright held by the Sakai Foundation (a 503c not for profit org) About 18 months ago, we realized that the way in which we were developing applications for this environment and the way in which we thought about collaboration information was wrong. The 'everything is content model' that Day have talked about and is embedded in Sling is a much closer fit for the use cases of the sakai community. The existing content system we had in Sakai2 [2] was limited and not capable of supporting the model. We tried, unsuccessfully to replace it with Jackrabbit, and so we decided to re-write the 1.8M lines of code into a much smaller, faster, lighter version. We looked as Sling 8 months ago, at a time when we thought we needed to pull in much of the old code base, and sorting out the dependencies in OSGi killed us, so we wrote our own OSGi light component manager[3]. About 4 months ago we negotiated a completely clean code base with the community and hence we have been able to re-consider Sling. We started porting the code in [3] to Sling about 3 weeks ago and are finding that although we have some areas of unique functionality. If we think hard enough about the use case we have been finding that most of the functionality is already covered in another form in Sling. We are also finding that the code in [3] has good separation and hence may of the components are dropping in as simple bundles. The bundles that I have mentioned as possible contributions are ones that don't appear to exist in Sling already, cover a use case we have and are generic enough to be of general use. Like the very simple guice bundle and the jax-rs servlet bundle. There may be others like the memory bundle that provides a configured and scopeable (request, thread, jvm instance, cluster invalidated, cluster replicated) cache manager (based on ehcache) Hope that helps, and wasn't too long, happy to answer more questions on or off list. Ian [1] https://camtools.caret.cam.ac.uk. [2] http://www.ohloh.net/p/sakai [3] http://www.ohloh.net/p/sakai-kernel On 17 Apr 2009, at 10:22, Torgeir Veimo wrote: We (Sakai Kernel Development Team), are starting to create a number of OSGi bundles and services as extensions to Sling. Can you describe what the functionality of these are and what the Sakai project aim to do? I had a look at http://groups.google.com/group/sakai-kernel/web/why-what-how-k2 and it's a bit vague, but it seems to be some sort of community software? -- Torgeir Veimo torg...@pobox.com
Re: Contrib bundles.
Myself and my coworker work on Sakai and are also interested in contributing to Sling where needed. As things come up, we'll do our best to submit patches and such. As more of Sakai is ported to Sling, I'm sure our contributions will increase. On Fri, Apr 17, 2009 at 04:10, Ian Boston wrote: > We (Sakai Kernel Development Team), are starting to create a number of OSGi > bundles and services as extensions to Sling. They are all A2 licensed (why > would you choose anything else :)). Without wanting to bloat the Sling code > base unnecessarily, is there interest in code contributions to Sling?, or at > least co-ordination to avoid duplication. (and stupid mistakes on our part) > > Current development tree is on github at > http://github.com/ieb/open-experiments/tree/master, its only been going a > few weeks. Most of the bundles of interest use the scr plugin. Some of the > Sling committers are lurking on our mailing list but I thought it would be > appropriate to mention it here to show real interest on our part. > > Ian >
