1 Reply Latest reply: Nov 11, 2010 6:40 AM by David Bosschaert RSS

Provide installer support for AS7

Thomas Diesler Master

David says




I think things were a little different in the AS6. In AS6 we always  shipped as a loosely coupled addon (our jars were put in a deployment  folder), whereas in AS7 we are part of the distribution (we are in the  modules tree). Let's say the as integration layer needs to change due to  a change in AS itself. That means that just replacing jboss-as-osgi.jar  is not enough. It may require additional AS jars to be replaced as  well. Effectively you might end up patching the whole of AS instead of  just the OSGi component, and I think patching AS as a whole is an  entirely different topic.

>> This methodology ensures that we provide backward compatible  artefacts that are QAed against the latest stable AS. There should be no  manual steps required by the user to get the latest jbosgi release  installed in the last stable AS. <<

I think this may be impossible to do (but correct me if I'm wrong).  Let's say there is a change in jboss-modules that we have to react to in  OSGi. This would mean that our OSGi distribution will only work in AS  versions that also contain this change.

What I think we can do is have automated runs that check a particular  version of our components with the accompanying version of AS.
So we have an installer that installs the version of our examples in  AS7.0.0.Alpha1 and tests that they work with that. Additional the  installer can install the version of our examples that work  AS7.0.0.Alpha2-SNAPSHOT in that and test those. Having a single set of  artefacts that work in both would only work if the underlying AS  infrastructure is very stable, and I don't think we have hit that point  yet.


Its not different to AS6 only the location of the framework and its dependencies changes (deployers == modules conceptually).

Ideally, we would not patch any AS7 jars. For the upcoming Beta10 release however, the jboss-as-osgi integration layer that is part of Alpha1 cannot be used with the standalone deployment client. Not fixing this, means no XService support for Alpha1.


We do the QA based on what the installer puts in the target container. This verifies AS consistency and installer content, at least for the OSGi subsystem.


Backward compatible changes that are taken from the Alpha1 tag can be applied IMHO. Especially if they are as trivial as they are now. What particular commit are you concerned about?

  • 1. Re: Provide installer support for AS7
    David Bosschaert Expert

    Well what I think is different is that jboss-as-osgi.jar is part of the jboss-as build and versioned as part of it. Where previously the AS6 integration was a component that was versioned and released separately from AS6. Taking one piece of a newer, unreleased build of AS7 and dropping it into a previous release of AS7 just doesn't feel safe to me. As that newer jboss-as-osgi.jar isn't officially released, the only option we have is to take a SNAPSHOT jar which means we lose reproducability, unless we decide to version and release jboss-as-osgi separately from the rest of the AS build (which I'm not advocating).


    I would have a lesser issue with patching things in /modules/org/jboss/osgi/... such as the framework.jar as at least these modules follow a their own release cycle and the installer (which is part of a release) can apply released versions of those rather than snapshots...