David, I have no objections and I actually prefer the x.y.z-SNAPSHOT version scheme.
Andreas On Tue, Jan 27, 2009 at 19:22, David Illsley <davidills...@gmail.com> wrote: > I've found some time to look at properly OSGI-ifying Axiom. The > approach I've prototyped uses OSGI Declarative Services (available in > at least Apache Felix, Equinox and Knopflerfish) and means that the > runtime jars have no Java dependencies on OSGI. The one aspect which > does intrude is the versioning of SNAPSHOT releases. Because OSGI > bundles can't have a Bundle-Version: SNAPSHOT, we'd need to move to a > version like 1.2.9-SNAPSHOT. I don't see this as being a massive deal, > but worthy of consultation. If there are no objections I'll commit my > prototype in a couple of days. > > David > > On Mon, Jan 5, 2009 at 6:09 PM, Andreas Veithen > <andreas.veit...@gmail.com> wrote: >> Your proposed solution sounds good. Since release 1.2.8 is imminent >> and I was planning to do some other changes to OMAbstractFactory which >> might actually simplify the problem, I propose to work on this for >> release 1.2.9. I will open a JIRA issue to track this. >> >> Andreas >> >> On Mon, Jan 5, 2009 at 18:56, David Illsley <davidills...@gmail.com> wrote: >>> I suspect the implementation bundles should register the factories as >>> OSGI services and the api bundle should access the implementation >>> through the service. The difficulty here is avoiding a runtime >>> dependency on OSGI framework classes, but I think that should be >>> doable using an injection approach where the api bundle activator >>> injects a non-OSGI class into the OMAbstractFactory if OSGI services >>> are in use. >>> Unfortunately I don't have the time to have a go at this over the next >>> couple of days, otherwise I'd have a go - it looks interesting. >>> David >>> >>> On Sun, Jan 4, 2009 at 4:33 PM, Andreas Veithen >>> <andreas.veit...@gmail.com> wrote: >>>> In trunk, there is an additional (optional) import for >>>> org.apache.axiom.soap.impl.llom.soap12, but soap11 is still missing. >>>> Now, all this doesn't seem to follow best practices: the API should >>>> not be aware of its implementations (except maybe for the default >>>> implementation). Any suggestions how this should be handled correctly >>>> in an OSGi environment? >>>> >>>> Andreas >>>> >>>> On Fri, Jan 2, 2009 at 22:19, Mike Edwards >>>> <mike.edwards.inglen...@gmail.com> wrote: >>>>> Folks, >>>>> >>>>> I am writing as a developer on the Apache Tuscany project. >>>>> >>>>> We are building a version of Tuscany that runs on OSGi - and we use AXIOM >>>>> in >>>>> our codebase. >>>>> >>>>> We're experiencing some problems associated with running AXIOM under OSGi >>>>> and I'm hoping that you will be able to help us fix those problems. >>>>> >>>>> We're using the axiom-api jar (version 1.2.7) and we run into some >>>>> problems >>>>> when code inside this jar tries to load classes from axiom.impl jar. The >>>>> axiom-api manifest does declare SOME dependencies on packages inside >>>>> axiom-impl, but it seems as if it needs to declare some more. We ran into >>>>> the following classes being loaded from axiom-api: >>>>> >>>>> 1) SOAP11Factory >>>>> >>>>> org.apache.axiom.soap.impl.llom.soap11.SOAP11Factory (axiom-impl) >>>>> >>>>> 2) SOAP12Factory >>>>> >>>>> org.apache.axiom.soap.impl.llom.soap12.SOAP12Factory (axiom-impl) >>>>> >>>>> >>>>> ... both from OMAbstractFactory class >>>>> >>>>> Does the manifest for axiom-api need to contain both of these packages as >>>>> imports? >>>>> I note that the axiom-impl manifest does export both of them. >>>>> >>>>> I patched the axiom-api manifest on my system by adding imports for those >>>>> 2 >>>>> packages and things seem to work just fine. >>>>> >>>>> >>>>> Many thanks, >>>>> >>>>> Yours, Mike. >>>>> >>>> >>> >> >
