1 Reply Latest reply on Nov 11, 2010 6:40 AM by bosschaert

Provide installer support for AS7

thomas.diesler Nov 11, 2010 6:06 AM

David says

https://jira.jboss.org/browse/JBOSGI-393

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

bosschaert Nov 11, 2010 6:40 AM (in response to thomas.diesler)

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...
Actions