On 16/01/2008, Richard S. Hall <[EMAIL PROTECTED]> wrote: > > It seems that some of these issues are arguments against Apache process, > so I am not sure what to say about that.
horses for courses ;) there's no ideal process for every situation and the lightweight process at ops4j is very encouraging at times - but it also has its downsides compared to the Apache process. Further, I am not really certain about what is being said here. This > thread seems to imply that if we did "rm -rf framework" in our trunk > directory, then it would be possible for our bundles to be seen as > framework independent and good OSGi citizens. However, since one of our > subprojects happens to be a framework implementation, then all of our > subprojects are tainted and seen as "Felix-only"? Is that right? +1 for portable bundles... I've been really frustrated at times when I want to mix certain compendium services, only to find there's no framework that can support certain mixes of Equinox, Knopflerfish and Felix bundles If so, then why would anyone want to work on OSGi-related subprojects at > Felix? By this perception, they would be ideologically limiting their > audience. I would hope that this isn't the case or if it was it could be > corrected. > > I would think that if a Felix PMC member felt that we were not doing a > good enough job promoting the use of our subprojects on other > frameworks, that he would try to propose ways to remedy that situation, > not encourage. sounds like we need a testing harness (one that supports automation?) For example, perhaps it would be worthwhile for us to create some sort > of standard template/table/graphic for each subproject documentation > page to clearly inform users whether it is applicable to other > frameworks and/or whether it has been tested on other frameworks. > Further, I think we could go as far as setting up or documenting > mechanisms that make it possible to automatically test our subprojects > on other frameworks. > > Clearly, not everything need be or can be developed at Felix, but the > implication that we might as well accept that Felix bundles will only be > used by Felix users seems awfully counter to all of the concepts for > which OSGi stands. definitely - I think we also need to push forward on OBR, as for me this really emphasizes the mix'n'match aspect of OSGi, which is so useful. -> richard > > Alin Dreghiciu wrote: > > Beside Niclas points there are some additional facts related to OPS4J: > > * it's open participation meaning that virtually anybody can > > contribute. No need for patches. > > * release process. we tend to release often. > > > > Alin > > > > On Jan 13, 2008 1:05 PM, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > > > >> On Thursday 10 January 2008 23:09, Richard S. Hall wrote: > >> > >>> There is no attempt by any of our sub-projects to specifically tie > >>> themselves to the Felix framework as far as I am aware. I think we > want > >>> all of our work to be interoperable where possible, so I think this is > a > >>> non-issue. > >>> > >> Yes, that is a good goal and I salute that. In general, we are more > often than > >> not met with positive comments when trying to resolve cross-platform > issues. > >> > >> But, I was thinking more "mentality-wise". People who use KF, first go > and > >> check the KF's set of bundles, the Equinox-based folks will search the > >> Eclipse site first... and so on. > >> Why is that? Because the KF developed bundles are tested on KF only, > the > >> Eclipse stuff is practically only tested on Equinox and so forth. This > sends > >> the signal that it is a "safer bet" to choose from within the same > community. > >> It's all in our heads! > >> > >> At OPS4J we *try* to ensure that everything gets tested on all the > frameworks > >> we claim to support. And with Pax Runner, we try to force all the > frameworks > >> into a configuration that is as close to each other as possible... > >> > >> End of the day, I think we want to remain "un-associated" with a > framework, > >> and a strong cross-framework interoperability focus. I think it will > benefit > >> us all. > >> > >> > >> Cheers > >> -- > >> Niclas Hedhman, Software Developer > >> > >> I live here; http://tinyurl.com/2qq9er > >> I work here; http://tinyurl.com/2ymelc > >> I relax here; http://tinyurl.com/2cgsug > >> > >> > -- Cheers, Stuart
