Hi André - There's no reason not to use pax-runner, in fact pax-exam (used in our tests) bases on pax-runner, beware that for having felix in a sufficiently new version you need a snapshot version. starting with
trunk/org.apache.clerezza.parent/org.apache.clerezza.platform.launcher.tdb$ pax-run.sh --platform=equinox pom.xml ../org.apache.clerezza.platform.launcher.storageless.parent/pom.xml leads to an error as pax-run seems not to support variables in versions. - What's the default way of distribution equinox based applications? I think if we have such a distro it should be as close to the expectations of equinox/eclipse users as possible. - Does the fact that you're trying to do a launcher mean that all of clerezza runs with equinox? Cheers, reto On Sat, May 15, 2010 at 2:55 AM, André Dietisheim <[email protected]> wrote: > Hi! > > I'm currently trying to run clerezza on equinox. My goal is to run clerezza > and org.eclipse.emf.cdo on the same osgi runtime. > Unfortunately it's not as easy as it sounds. > > 1.) Attempt > My first attempt was to keep everything in place but just swap the launcher > code in one of the launchers (tdb, sesame, storageless, etc.). OSGI R4.2 > defined an official way to start osgi runtimes. The launcher code would look > similar to this: > > FrameworkFactory factory = > (Class.forName(getFrameworkFactoryClassName()).newInstance()); > Framework framework = factory.newFramework(configProps); > framework.init(); > framework.start(); > System.err.printf("Starting osgi runtime '%s'\n", > framework.getSymbolicName()); > > getFrameworkFactoryClassName() exists in 2 flawors: > > return "org.eclipse.osgi.launch.EquinoxFactory"; > > or > > return "org.apache.felix.framework.FrameworkFactory"; > > > Doing this, I got a Main, that could launch felix without any flaws, but > equinox threw exceptions very early: > > java.lang.NullPointerException > at org.eclipse.osgi.baseadaptor.BaseAdaptor.initializeStorage > (BaseAdaptor.java:121) > at org.eclipse.osgi.framework.internal.core.Framework.initialize > (Framework.java:185) > at org.eclipse.osgi.framework.internal.core.Framework.<init> > (Framework.java:157) > ... > > I tried to fix this situation (obviously something's wrong with the bundle > cache or configuration area) by setting the various osgi configuration > settings. Unfortunately nothing helps. I stepped through the code and saw > that equinox has a pluggable storage architecture and cant find it's hooked > storage suppliers. > -> My current guess is that equinox can't run if it's being inlined like the > clerezza does with felix. To my understanding this approach's practical but > not pretty legal anyhow (felix's Apache licenced, Equinox Eclipse Public > licenced. Mixing both in one archive does not ensure the code and licence > borders). > > 2.) Not inlined, start as referenced jar > My second attempt was to keep the equinox jar untouched and reference it in > launchers manifest: > > Manifest-Version: 1.0 > ... > Class-Path: osgi-3.5.2.R35x_v20100126.jar > ... > > Unfortunately, this approach doesn't work either. Equinox starts, gets a bit > further and spits exceptions later uphill. It complains when it tries to > install the system bundles: > > java.lang.NullPointerException > at java.io.File.<init>(File.java:305) > at > org.eclipse.osgi.internal.baseadaptor.BaseStorage.getBundleContent(BaseStorage.java:656) > at > org.eclipse.osgi.internal.baseadaptor.BaseStorage.createBundleFile(BaseStorage.java:665) > at > org.eclipse.osgi.baseadaptor.BaseAdaptor.createBundleFile(BaseAdaptor.java:466) > at org.eclipse.osgi.baseadaptor.BaseData.getBundleFile(BaseData.java:394) > .... > > Once again, things look storage related. I stepped through the code and > searched the mailing-list > > -> My current guess is that you cannot launch equinox this way either. > > 3.) Fat jar > There are several tools out there that allow you to embed code and jar into > an outer jar. The most prominent one's here: > http://www.ibm.com/developerworks/java/library/j-onejar/ > These tools even exist with maven bundles. I tried a few of them and > stumbled mostly on duplicate entries in the resulting jar. The same happend > with the assembly:assembly goal (there's a bug in the current version) > Furthermore, many post note that class access gets pretty slow with this > approach. > > -> Doesn't work either. > > > I wonder how pax-runner handles the launch. What's the reason not to use > pax-runner anyhow? > > Any hints, comments suggestions? > > Cheers > André >
