Incompatible framework dependencies

[thomas.diesler]

Folks,

these dependencies currently prevent the scheduled Beta5 release on 01-Dec-2009

 <version.jboss.classloading>2.0.8-SNAPSHOT</version.jboss.classloading>
 <version.jboss.deployers>2.0.9-SNAPSHOT</version.jboss.deployers>
 <version.jboss.kernel>2.2.0-SNAPSHOT</version.jboss.kernel>

With the current setup, framework can only use dependencies that are compatible with what is installed in the supported target containers. Appart fom API compatibility, the functional compatibility criteria is that the enterprise examples run in the matrix of supported target containers. We should not lightheartedly drop support for a target container, which requiring an incompatible dependency does. In case of the upcoming Beta5 release, it must run on 6.0.0.M1 - otherwise the release would not be meaningful.

I realize that framework trunk needs to work with possibly newer SNAPSHOT versions than are installed in the supported target containers. As a consequence we might need to decouple the MC Framework from JBoss OSGi again and move it out of the reactor to projects/runtime/framework/trunk where it originally came from.

The downside of this is that the framework independent integration tests (i.e. examples, functional) are not available for trunk anymore, which was the original motivation to make framework a reactor project.

If framework should stay a reactor project we cannot update the above mentioned dependencies in an uncoordinated way. Compatible updates are ok for as long as the enterprise examples run in all supported target containers.

[alesj]

these dependencies currently prevent the scheduled Beta5 release on 01-Dec-2009

You shouldn't cut release from trunk,
you should do it on a stable branch, which doesn't have such changes.

I know we said we'll include service-mix into this release,
but the changes are too big to be easily ported to AS in the last minute,
hence it will have to wait for AS 6.0.M2.

The downside of this is that the framework independent integration tests (i.e. examples, functional) are not available for trunk anymore, which was the original motivation to make framework a reactor project.

If framework should stay a reactor project we cannot update the above mentioned dependencies in an uncoordinated way. Compatible updates are ok for as long as the enterprise examples run in all supported target containers.

Either OSGi facade trunk needs a dedicated AS build / instance (or trunk directly),
or those enterprise tests only make sense for stable branches.
* http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266979#4266979

[thomas.diesler]

After a long discussion with Ales, we decided to cut the Beta5 release from a framework branch that uses compatible dependencies

The location of that branch is as you might guess

https://svn.jboss.org/repos/jbossas/projects/jboss-osgi/projects/runtime/framework/branches/1.0.0.Alpha2

This effectively renders the reactor/framework stale with respect to the overall jbosgi/trunk build.

Perhaps, at this point I should explain again what a "reactor project" is ...

It is the home of fast moving jbosgi projects that want to participate in the overall jbosgi build and be part of the framework and container independent test matrix. Reactor projects are part of the installer and are QAed by the Hudson environment on different frameworks and target containers.

Reactor projects cannot introduce dependencies that are not available in the supported target containers. Eventually, every reactor project will start its own lifecycle in jboss-osgi/projects when it becomes stable enough. Every project you see in jboss-osgi/projects (there are currently a little under 20 of them) has once started in the reactor and was an integral part of the jbosgi build.

It seems that framework has crossed that bridge of introducing incompatible dependencies and needs to have a trunk version which is independent of the overall jbosgi build. A framework/trunk version also seems to be needed to make fast progress.

The situation now is that framework still uses the reactor svn location, but is not part of the reactor build.

As a consequence, I suggest to move framework to its natural location again (i.e. projects/runtime/framework/trunk) since its life as reactor project has ended.

[alesj]

As a consequence, I suggest to move framework to its natural location again (i.e. projects/runtime/framework/trunk) since its life as reactor project has ended.

Argh, not the moving again.

I'm for it if Adrian also agrees,
and you 110% promise you will never ever move it again. ;-)

[thomas.diesler]

It's really not such a big deal if you understand the difference between reactor and standalone project. If framework would have started in the reactor (as it should have) than this would be the first move.

[thomas.diesler]

I'm ready for the Beta5 release, which will hopefully be tagged today.

As a consequence, I suggest to move framework to its natural location again (i.e. projects/runtime/framework/trunk) since its life as reactor project has ended.

Please use

svn switch https://svn.jboss.org/repos/jbossas/projects/jboss-osgi/projects/runtime/framework/trunk

after the Beta5 announcement.

[thomas.diesler]

The framework/trunk location is now active

[ascheerer]

Hello,

the framework should be referenced by a relative location within the reactor to work with the anonymous svn:

svnm134@PC00295:~/proj/jboss-osgi$ svn propget svn:externals trunk/reactor/
^/projects/jboss-osgi/projects/runtime/framework/trunk framework

Bye

Andi

[thomas.diesler]

Merci, this should work now

http://subversion.tigris.org/svn_1.5_releasenotes.html#externals