Re: new whiteboard experiment, OSGi style
Brian M Dube wrote: > David Crossley wrote: > > Brian M Dube wrote: > > > > > > Great, thanks. I'll gladly expand the documentation based on any > > > questions. > > > > Perhaps some very high-level scenarios. > > > > Does this mean that components such as > > Apache Cocoon blocks, e.g. Cocoon3 components > > and Apache Sling, Apache Jackrabbit > > can be readily utilised? > > Good question. > > The Apache Cocoon blocks, as currently shipped with Apache Forrest, > are not ready to drop into an OSGi environment. It looks like this is > also the case with Cocoon3, but that is only a guess based on the > website content and not the code. I recall there being lots of discussion about OSGi in the height of the Cocoon-2 days. Not saying that we should hold on to Cocoon, rather that i presume OSGi enables us to utilise components from various providers. Also the prior Cocoon work would provide some good background information. A quick search to find some Cocoon starting points: [osgi] Initial code http://s.apache.org/t4 http://wiki.apache.org/cocoon/osgi OSGi integration : make Cocoon (blocks) OSGi driven https://issues.apache.org/jira/browse/COCOON/component/12311920 I do not know how far those efforts progressed. Then recently: Cocoon 3: the three sisters as OSGi bundles? http://s.apache.org/yI -David > It is possible to "wrap" a jar, which adds the manifest headers > necessary for OSGi. One scenario is to wrap each block along with all > its dependencies, possibly duplicating dependencies in each wrapped > block. Another scenario is to wrap each block as is and supply the > dependencies as individual bundles. But either way, the dependencies > have to be provided somehow. It's not as easy as having them on the > classpath in the non-OSGi sense. > > For other OSGi-based projects, such as Apache Sling, absolutely. The > details depend on how they've set up their bundles (services? custom > manifest headers?), but in the end it's OSGi and there would be a way > to use it. > > I should state that I'm no authority on OSGi. I'm learning as I go > here. > > -Brian
buildbot success in ASF Buildbot on forrest-trunk
The Buildbot has detected a restored build on builder forrest-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/forrest-trunk/builds/394 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: isis_ubuntu Build Reason: scheduler Build Source Stamp: [branch forrest/trunk] 1098202 Blamelist: bdube Build succeeded! sincerely, -The Buildbot
buildbot failure in ASF Buildbot on forrest-trunk
The Buildbot has detected a new failure on builder forrest-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/forrest-trunk/builds/393 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: isis_ubuntu Build Reason: scheduler Build Source Stamp: [branch forrest/trunk] 1098200 Blamelist: bdube BUILD FAILED: failed svn sincerely, -The Buildbot
Re: git-svn and svn properties (Re: svn commit: r1096401)
On Tue, Apr 26, 2011 at 03:59:44PM +1000, David Crossley wrote: > Brian M Dube wrote: > > > Author: bdube > > > Date: Mon Apr 25 02:56:52 2011 > > > New Revision: 1096401 > > > > > > URL: http://svn.apache.org/viewvc?rev=1096401&view=rev > > > Log: > > > Follow r1096394 (git-svn) with svn:ignore and svn:eol-style > > > > Does anyone know a better way? > > The "infrastructure-dev" mail list is for > discussion of future tools etc. Various topics > releated to git are happening. > > http://apache.org/dev/infra-mail.html Ah, from that discussion I learned that git-svn is supposed to use and respect the configuration settings of my svn installation. I found that my settings had lost the additions from http://www.apache.org/dev/svn-eol-style.txt at some point. I've added these again and I'll see how it goes the next time I commit with new files. -Brian
Re: new whiteboard experiment, OSGi style
On Sat, Apr 30, 2011 at 04:26:42PM +1000, David Crossley wrote: > Brian M Dube wrote: > > > > Great, thanks. I'll gladly expand the documentation based on any > > questions. > > Perhaps some very high-level scenarios. > > Does this mean that components such as > Apache Cocoon blocks, e.g. Cocoon3 components > and Apache Sling, Apache Jackrabbit > can be readily utilised? Good question. The Apache Cocoon blocks, as currently shipped with Apache Forrest, are not ready to drop into an OSGi environment. It looks like this is also the case with Cocoon3, but that is only a guess based on the website content and not the code. It is possible to "wrap" a jar, which adds the manifest headers necessary for OSGi. One scenario is to wrap each block along with all its dependencies, possibly duplicating dependencies in each wrapped block. Another scenario is to wrap each block as is and supply the dependencies as individual bundles. But either way, the dependencies have to be provided somehow. It's not as easy as having them on the classpath in the non-OSGi sense. For other OSGi-based projects, such as Apache Sling, absolutely. The details depend on how they've set up their bundles (services? custom manifest headers?), but in the end it's OSGi and there would be a way to use it. I should state that I'm no authority on OSGi. I'm learning as I go here. -Brian
