Re: More OSGi progress
I tried to follow the steps that Rex provided, somehow I ran into a build
failure when mvn install framework in the final step. Then I tried mvn clean
install -Dmaven.test.skip=true, still no luck.
Here is the error msg I noticed, any workaround to bypass the exception?
Thanks in advance.
Jeff C
[INFO]
[INFO] Building Geronimo Build Support :: Plugin
[INFO]task-segment: [install]
[INFO]
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [groovy:generateStubs {execution: default}]
[WARN] Failed to load provider from:
org.codehaus.groovy.maven.runtime.loader.defaultproviderloa...@31103110
java.lang.NullPointerException
org.codehaus.groovy.maven.runtime.loader.DefaultProviderLoader.findProviders(DefaultProviderLoader.java:67)
org.codehaus.groovy.maven.runtime.loader.DefaultProviderLoader.load(DefaultProviderLoader.java:45)
org.codehaus.groovy.maven.runtime.loader.DefaultProviderSelector.load(DefaultProviderSelector.java:192)
org.codehaus.groovy.maven.runtime.loader.DefaultProviderSelector.discover(DefaultProviderSelector.java:154)
org.codehaus.groovy.maven.runtime.loader.DefaultProviderSelector.register(DefaultProviderSelector.java:98)
org.codehaus.groovy.maven.runtime.loader.DefaultProviderSelector.select(DefaultProviderSelector.java:47)
org.codehaus.groovy.maven.runtime.loader.DefaultProviderManager.select(DefaultProviderManager.java:91)
org.codehaus.groovy.maven.plugin.ProviderMojoSupport.provider(ProviderMojoSupport.java:107)
org.codehaus.groovy.maven.plugin.ComponentMojoSupport.doExecute(ComponentMojoSupport.java:58)
org.codehaus.groovy.maven.plugin.MojoSupport.execute(MojoSupport.java:69)
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
java.lang.reflect.Method.invoke(Method.java:599)
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
org.codehaus.classworlds.Launcher.main(Launcher.java:375)
..
[ERROR] BUILD FAILURE
[INFO]
[INFO] Dependencies have changed:
Added dependencies are saved here:
/home/jeffchi/Geronimo/SourceCode/sandbox/framework/configs/geronimo-gbean-deployer-bootstrap/src/main/history/dependencies.added.xml
Tree listing is saved here:
/home/jeffchi/Geronimo/SourceCode/sandbox/framework/configs/geronimo-gbean-deployer-bootstrap/src/main/history/treeListing.xml
Delete
/home/jeffchi/Geronimo/SourceCode/sandbox/framework/configs/geronimo-gbean-deployer-bootstrap/src/main/history/dependencies.xml
if you are happy with the dependency changes.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 3 minutes 18 seconds
[INFO] Finished at: Fri Oct 16 10:56:00 CST 2009
[INFO] Final Memory: 201M/387M
[INFO]
On Thu, Oct 15, 2009 at 4:53 PM, Rex Wang rwo...@gmail.com wrote:
I just built dj's sandbox framework successfully, here is my footprint.
Hope this helps for the following guys, and also thanks for the clues above!
my env:
windowxp
maven2.2.1
jdk6
sandbox rev825381
checkout sandbox ramework
ps: modify pom.xml(xmlbeans denp: 2.4.0_2-SNAPSHOT - 2.4.0_3-SNAPSHOT)
checkout servicemix
ps:
add djencks patch to xstream-1.3/pom.xml
build root pom.xml
build:
Re: More OSGi progress
I just built dj's sandbox framework successfully, here is my footprint. Hope
this helps for the following guys, and also thanks for the clues above!
my env:
windowxp
maven2.2.1
jdk6
sandbox rev825381
checkout sandbox ramework
ps: modify pom.xml(xmlbeans denp: 2.4.0_2-SNAPSHOT - 2.4.0_3-SNAPSHOT)
checkout servicemix
ps:
add djencks patch to xstream-1.3/pom.xml
build root pom.xml
build: jaxb-impl-2.1.6, xmlbeans-2.4.0, woodstox-3.2.8, jline-0.9.94
copy the G-trunk root pom.xml to the parent dir of this sandbox frameowrk
build geronimo bundles
ps: plexus-utils pom.xml (version-1.4.5_1-SNAPSHOT ), build it before
plexus achiver and logging
checkout karaf from felix trunk and bunld it
checkout org.osgi.core/foundation/compendium and build them sequentially.
then, build the sandbox framework.
HTH.
-Rex
2009/10/13 Rick McGuire rick...@gmail.com
Time to start a new thread, I think. I'm getting further now. The
framework builds, but I'm getting errors trying to build the configs. I get
an IOException attempting to build the J2EE System config (see below). The
file in question is
java.io.IOException: Referenced file does not exist:
C:\jencks\g\framework\confi
gs\j2ee-system\target\repository\org\apache\geronimo\framework\j2ee-system\3.0-S
NAPSHOT\j2ee-system-3.0-SNAPSHOT.car
which actually does exist. Strangely, this does not kill the build, but it
then dies trying to build the rmi-naming config with a similar error trying
to load the rmi-naming car file. This one does kill the build. Both
exceptions occur when starting the Felix framework, but I'm not sure where
the reference to that file is coming from. Any suggestions on where I might
start debugging this problem?
Rick
[INFO] [car:update-pluginlist]
[INFO]
[INFO] Building Geronimo Framework, Configs :: J2EE System
[INFO]task-segment: [install]
[INFO]
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] skip non existing resourceDirectory
C:\jencks\g\framework\configs\j2ee-sy
stem\src\main\filtered-resources
[INFO] Copying 3 resources
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated:
C:\jencks\g\framework\configs\j2ee-system\target\work\plan.xml
[INFO] [car:verify-no-dependency-change]
[INFO] [car:prepare-metadata]
[INFO] [car:package]
[INFO] Packaging module configuration:
C:\jencks\g\framework\configs\j2ee-system
\target\work\plan.xml
ERROR: Error creating archive. (java.io.IOException: Referenced file does
not ex
ist:
C:\jencks\g\framework\configs\j2ee-system\target\repository\org\apache\gero
nimo\framework\j2ee-system\3.0-SNAPSHOT\j2ee-system-3.0-SNAPSHOT.car)
java.io.IOException: Referenced file does not exist:
C:\jencks\g\framework\confi
gs\j2ee-system\target\repository\org\apache\geronimo\framework\j2ee-system\3.0-S
NAPSHOT\j2ee-system-3.0-SNAPSHOT.car
at
org.apache.felix.framework.cache.BundleArchive.createRevisionFromLoca
tion(BundleArchive.java:994)
at
org.apache.felix.framework.cache.BundleArchive.revise(BundleArchive.j
ava:631)
at
org.apache.felix.framework.cache.BundleArchive.init(BundleArchive.j
ava:206)
at
org.apache.felix.framework.cache.BundleCache.getArchives(BundleCache.
java:149)
at org.apache.felix.framework.Felix.init(Felix.java:558)
at org.apache.felix.framework.Felix.start(Felix.java:683)
at
org.apache.geronimo.mavenplugins.car.AbstractCarMojo.getFramework(Abs
tractCarMojo.java:771)
at
org.apache.geronimo.mavenplugins.car.PackageMojo.createKernel(Package
Mojo.java:360)
at
org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage(Package
Mojo.java:294)
at
org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.
java:234)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:453)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:500)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:479)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:331)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:292)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:142)
at
Re: More OSGi progress
I found an interesting thing on my local machine, while I run mvn install in
the framework directory, an error below occured
[INFO]
[INFO] Building Geronimo Assemblies :: Karaf Boilerplate Framework
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting file set:
D:\geronimo-all\osgisandbox\framework\configs\karaf-framework\target
(included: [**], excluded: [])
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [antrun:run {execution: create-prop}]
[INFO] Executing tasks
[taskdef] Could not load definitions from resource
net/sf/antcontrib/antcontrib.properties. It could not be found.
[echo] Maven version: 3.0-SNAPSHOT
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] An Ant BuildException has occured: Problem: failed to create task or
type propertyregex
Cause: The name is undefined.
Action: Check the spelling.
Action: Check that any custom tasks/types have been declared.
Action: Check that any presetdef/macrodef declarations have taken place.
But if I build karaf-framework individually, it is built successfully, not
sure whether it is caused by my local environment.
Anthing question is about the default repository, I remembered that David
has opened a JIRA for the hard coded location for system. But in the
latest code, it is changed back like System.getProperty(DEFAULT_REPO,
system);, so the configuration in the config.properties is not read, so
the karaf failed to start :-(
2009/10/13 Jarek Gawor jga...@gmail.com
Btw, I've been using Maven 2.0.10 to build the framework but I'm
getting better results with 2.2.1.
Jarek
On Mon, Oct 12, 2009 at 8:49 PM, Jarek Gawor jga...@gmail.com wrote:
Once I fixed my manifest problem I ran into this problem as well. But
somehow I bypassed it by building the config modules individually...
Then I ran into the problem that Ivan reported. I think I just fixed
that problem as well and got a little bit further.
Jarek
On Mon, Oct 12, 2009 at 3:11 PM, Rick McGuire rick...@gmail.com wrote:
Time to start a new thread, I think. I'm getting further now. The
framework builds, but I'm getting errors trying to build the configs. I
get
an IOException attempting to build the J2EE System config (see below).
The
file in question is
java.io.IOException: Referenced file does not exist:
C:\jencks\g\framework\confi
gs\j2ee-system\target\repository\org\apache\geronimo\framework\j2ee-system\3.0-S
NAPSHOT\j2ee-system-3.0-SNAPSHOT.car
which actually does exist. Strangely, this does not kill the build, but
it
then dies trying to build the rmi-naming config with a similar error
trying
to load the rmi-naming car file. This one does kill the build. Both
exceptions occur when starting the Felix framework, but I'm not sure
where
the reference to that file is coming from. Any suggestions on where I
might
start debugging this problem?
Rick
[INFO] [car:update-pluginlist]
[INFO]
[INFO] Building Geronimo Framework, Configs :: J2EE System
[INFO]task-segment: [install]
[INFO]
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] skip non existing resourceDirectory
C:\jencks\g\framework\configs\j2ee-sy
stem\src\main\filtered-resources
[INFO] Copying 3 resources
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated:
C:\jencks\g\framework\configs\j2ee-system\target\work\plan.xml
[INFO] [car:verify-no-dependency-change]
[INFO] [car:prepare-metadata]
[INFO] [car:package]
[INFO] Packaging module configuration:
C:\jencks\g\framework\configs\j2ee-system
\target\work\plan.xml
ERROR: Error creating archive. (java.io.IOException: Referenced file
does
not ex
ist:
C:\jencks\g\framework\configs\j2ee-system\target\repository\org\apache\gero
nimo\framework\j2ee-system\3.0-SNAPSHOT\j2ee-system-3.0-SNAPSHOT.car)
java.io.IOException: Referenced file does not exist:
C:\jencks\g\framework\confi
gs\j2ee-system\target\repository\org\apache\geronimo\framework\j2ee-system\3.0-S
NAPSHOT\j2ee-system-3.0-SNAPSHOT.car
at
org.apache.felix.framework.cache.BundleArchive.createRevisionFromLoca
tion(BundleArchive.java:994)
at
Re: More OSGi progress
I'm making a little progress. If I do an mvn clean in the configs
directory before starting any build, I get past the RMI naming problem.
This gets me to the same error that Ivan is seeing when building the
Karaf Boilerplate Framework. If I change into the geronimo-assemblies
dir and build, everything builds cleanly, but then I'm stuck at that
point point. Any attempt to build anything else runs into the
rmi-naming build problem all over. I've tried all sorts of
combinations of partial build, and I either get the error building the
configs, or the error building the assemblies.
Rick
Ivan wrote:
I found an interesting thing on my local machine, while I run mvn
install in the framework directory, an error below occured
[INFO]
[INFO] Building Geronimo Assemblies :: Karaf Boilerplate Framework
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting file set:
D:\geronimo-all\osgisandbox\framework\configs\karaf-framework\target
(included: [**], excluded: [])
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [antrun:run {execution: create-prop}]
[INFO] Executing tasks
[taskdef] Could not load definitions from resource
net/sf/antcontrib/antcontrib.properties. It could not be found.
[echo] Maven version: 3.0-SNAPSHOT
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] An Ant BuildException has occured: Problem: failed to create
task or type propertyregex
Cause: The name is undefined.
Action: Check the spelling.
Action: Check that any custom tasks/types have been declared.
Action: Check that any presetdef/macrodef declarations have taken
place.
But if I build karaf-framework individually, it is built successfully,
not sure whether it is caused by my local environment.
Anthing question is about the default repository, I remembered that
David has opened a JIRA for the hard coded location for system. But
in the latest code, it is changed back like
System.getProperty(DEFAULT_REPO, system);, so the configuration in
the config.properties is not read, so the karaf failed to start :-(
2009/10/13 Jarek Gawor jga...@gmail.com mailto:jga...@gmail.com
Btw, I've been using Maven 2.0.10 to build the framework but I'm
getting better results with 2.2.1.
Jarek
On Mon, Oct 12, 2009 at 8:49 PM, Jarek Gawor jga...@gmail.com
mailto:jga...@gmail.com wrote:
Once I fixed my manifest problem I ran into this problem as
well. But
somehow I bypassed it by building the config modules individually...
Then I ran into the problem that Ivan reported. I think I just fixed
that problem as well and got a little bit further.
Jarek
On Mon, Oct 12, 2009 at 3:11 PM, Rick McGuire rick...@gmail.com
mailto:rick...@gmail.com wrote:
Time to start a new thread, I think. I'm getting further now. The
framework builds, but I'm getting errors trying to build the
configs. I get
an IOException attempting to build the J2EE System config (see
below). The
file in question is
java.io.IOException: Referenced file does not exist:
C:\jencks\g\framework\confi
gs\j2ee-system\target\repository\org\apache\geronimo\framework\j2ee-system\3.0-S
NAPSHOT\j2ee-system-3.0-SNAPSHOT.car
which actually does exist. Strangely, this does not kill the
build, but it
then dies trying to build the rmi-naming config with a similar
error trying
to load the rmi-naming car file. This one does kill the build.
Both
exceptions occur when starting the Felix framework, but I'm not
sure where
the reference to that file is coming from. Any suggestions on
where I might
start debugging this problem?
Rick
[INFO] [car:update-pluginlist]
[INFO]
[INFO] Building Geronimo Framework, Configs :: J2EE System
[INFO]task-segment: [install]
[INFO]
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] skip non existing resourceDirectory
C:\jencks\g\framework\configs\j2ee-sy
stem\src\main\filtered-resources
[INFO] Copying 3 resources
[INFO] [car:validate-configuration]
Re: More OSGi progress
Ivan,
That build problem disappeared for me once I upgraded to Maven 2.2.1.
For the Karaf system dir issue, I just created a system soft link to
the repository dir. And with that I was able to start the framework
assembly. With some tweaks to startup.properties file I fixed some
osgi resolution problems but then I got stuck on some Geronimo
specific error trying to load some parent car module.
Jarek
On Tue, Oct 13, 2009 at 5:45 AM, Ivan xhh...@gmail.com wrote:
I found an interesting thing on my local machine, while I run mvn install in
the framework directory, an error below occured
[INFO]
[INFO] Building Geronimo Assemblies :: Karaf Boilerplate Framework
[INFO] task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting file set:
D:\geronimo-all\osgisandbox\framework\configs\karaf-framework\target
(included: [**], excluded: [])
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [antrun:run {execution: create-prop}]
[INFO] Executing tasks
[taskdef] Could not load definitions from resource
net/sf/antcontrib/antcontrib.properties. It could not be found.
[echo] Maven version: 3.0-SNAPSHOT
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] An Ant BuildException has occured: Problem: failed to create task or
type propertyregex
Cause: The name is undefined.
Action: Check the spelling.
Action: Check that any custom tasks/types have been declared.
Action: Check that any presetdef/macrodef declarations have taken place.
But if I build karaf-framework individually, it is built successfully, not
sure whether it is caused by my local environment.
Anthing question is about the default repository, I remembered that David
has opened a JIRA for the hard coded location for system. But in the
latest code, it is changed back like System.getProperty(DEFAULT_REPO,
system);, so the configuration in the config.properties is not read, so
the karaf failed to start :-(
2009/10/13 Jarek Gawor jga...@gmail.com
Btw, I've been using Maven 2.0.10 to build the framework but I'm
getting better results with 2.2.1.
Jarek
On Mon, Oct 12, 2009 at 8:49 PM, Jarek Gawor jga...@gmail.com wrote:
Once I fixed my manifest problem I ran into this problem as well. But
somehow I bypassed it by building the config modules individually...
Then I ran into the problem that Ivan reported. I think I just fixed
that problem as well and got a little bit further.
Jarek
On Mon, Oct 12, 2009 at 3:11 PM, Rick McGuire rick...@gmail.com wrote:
Time to start a new thread, I think. I'm getting further now. The
framework builds, but I'm getting errors trying to build the configs.
I get
an IOException attempting to build the J2EE System config (see below).
The
file in question is
java.io.IOException: Referenced file does not exist:
C:\jencks\g\framework\confi
gs\j2ee-system\target\repository\org\apache\geronimo\framework\j2ee-system\3.0-S
NAPSHOT\j2ee-system-3.0-SNAPSHOT.car
which actually does exist. Strangely, this does not kill the build,
but it
then dies trying to build the rmi-naming config with a similar error
trying
to load the rmi-naming car file. This one does kill the build. Both
exceptions occur when starting the Felix framework, but I'm not sure
where
the reference to that file is coming from. Any suggestions on where I
might
start debugging this problem?
Rick
[INFO] [car:update-pluginlist]
[INFO]
[INFO] Building Geronimo Framework, Configs :: J2EE System
[INFO] task-segment: [install]
[INFO]
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] skip non existing resourceDirectory
C:\jencks\g\framework\configs\j2ee-sy
stem\src\main\filtered-resources
[INFO] Copying 3 resources
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated:
C:\jencks\g\framework\configs\j2ee-system\target\work\plan.xml
[INFO] [car:verify-no-dependency-change]
[INFO] [car:prepare-metadata]
[INFO] [car:package]
[INFO] Packaging module configuration:
C:\jencks\g\framework\configs\j2ee-system
\target\work\plan.xml
ERROR: Error creating archive. (java.io.IOException: Referenced file
Re: osgi progress
Ivan wrote: After building many 3-rd parties libries locally, I got the same error that Jarek found, luckily, it seems that the error INFO [DeploymentContext] The Strict Manifest Classpath is not the root cause, after setting karaf.home property, the build process could continue , But, I got another error below, still try to find why ... What does the karaf.home property need to be set to and where do you set it? Rick 17:33:56,218 WARN [DependencyManager] Could not start bundle: org.apache.geronimo.framework.geronimo-jmx-remoting [68] org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.geronimo.framework.geronimo-jmx-remoting [68]: package; (package=org.apache.xbean.naming) at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3263) at org.apache.felix.framework.Felix.startBundle(Felix.java:1597) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902) at org.apache.geronimo.system.configuration.DependencyManager.installed(DependencyManager.java:97) at org.apache.geronimo.system.configuration.DependencyManager.bundleChanged(DependencyManager.java:70) at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:800) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:728) at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:610) at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:3576) at org.apache.felix.framework.Felix.installBundle(Felix.java:2478) at org.apache.felix.framework.Felix.installBundle(Felix.java:2277) at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:130) at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:108) at org.apache.geronimo.deployment.DeploymentContext.createTempConfiguration(DeploymentContext.java:208) at org.apache.geronimo.deployment.DeploymentContext.initializeConfiguration(DeploymentContext.java:174) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:249) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:209) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:257) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:854) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:245) at org.apache.geronimo.mavenplugins.car.PackageMojo.invokeDeployer(PackageMojo.java:517) at org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage(PackageMojo.java:337) at org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:234) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at
Re: osgi progress
David Jencks wrote: I only have a minute so can't address anything in detail right now. Most of the servicemix bundle dependencies can probably be on released versions. I went for speed and used the ones from my checked out servicemix trunk in case I needed to patch them. I don't think we need the geronimo plexus bundles I set up -- although we do need to find some solution for accessing the code or not using it at all. What are the testsuite errors you get? It would be useful to find out if they are windows specific. Similarly it would be great to find out if anyone else can build on a non-windows system :-) I took a little deeper look at the deployment test case errors I'm getting. The root cause of the failure is this exception: Caused by: java.lang.IllegalArgumentException: id must be in the form [groupId]/[artifactId]/[version]/[type] : C:\jencks\g\framework\modules\geronimo-deployment\target\deployTest at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:61) at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:51) at org.apache.geronimo.kernel.osgi.MockBundleContext.installBundle(MockBundleContext.java:106) at org.apache.geronimo.deployment.DeploymentContext.createTempConfiguration(DeploymentContext.java:208) ... 28 more Since this is failing just calling bundleContext.installBundle() in the MockBundleContext code, I suspect I'm not running under karaf. Have I missed some setup step somewhere? Rick thanks david jencks On Oct 9, 2009, at 4:55 AM, Rick McGuire wrote: David Jencks wrote: I changed the url scheme so we always use pax maven urls for everything in the geronimo repository, and now I can get, with some work, all the plugin bundles to start as bundles. However they mostly don't start as plugins (i.e., no gbeans start). I haven't figured out why yet. How to get it to run: build This one word is starting to remind me of the famous Sydney Harris cartoon: http://www.sciencecartoonsplus.com/pages/gallery.php I've had a few issues getting this to build, so I thought I'd capture the notes here for the benefit of others. Some of these we can fix in the build, others are things that need to be accounted for before building. A major problem is getting all of the dependencies into your maven repository so the build can work. 1) servicemix bundles. In addition to the patch that David provided, you need to checkout and build the servicemix bundles from: https://svn.apache.org/repos/asf/servicemix/smx4/bundles/trunk Unfortunately, the root pom for servicemix does not build all of the subprojects. Many of the ones that are skipped are required by Geronimo and need to be built individually. This list includes: jaxb-impl-2.1.6 xmlbeans-2.4.0 (NOTE: this builds 2.4.0_3-SNAPSHOT, but the dependency is currently 2.4.0_2-SNAPSHOT. The Geronimo pom needs to be adjusted). woodstox-3.2.8 jline-0.9.94 The framework builds additional bundlized versions of dependencies, but at the moment, they are not included in the build. The subprojects are located in framework/bundles, but there's no root pom that builds all of these, so each subproject needs to be built individually. There are some dependencies between these subprojects. For example, plexus-archiver depends on plexus-utils, so plexus-utils needs to be built first. Unfortunately, plexus-utils is building version 1.5.15_1-SNAPSHOT, and plexus-archiver has a dependency on 1.4.5_-SNAPSHOT. plexus-utils exports a 1.4.5 level of the packages, so I'm guessing this was intended to be 1.4.5_1-SNAPSHOT, so the POM needs adjusting. Once I've done the steps above, I get some test failures in geronimo-kernel. If I try to build with tests turned off, then I get the following failure: 1) org.apache.geronimo.framework:geronimo-kernel:jar:tests:3.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.framework -Dartifac tId=geronimo-kernel -Dversion=3.0-SNAPSHOT -Dclassifier=tests -Dpackaging=jar -D file=/path/to/file most likely the result of the test failures. The test failures don't make much sense to me, but this might be a Windows-specific problem with normalizing URLs. If I comment out the assertions that are failing, I'm able to get geronimo-kernel to build, but get test failures in other projects. Now, however, disabling the tests appears to work. This gets me to errors with the dependency history checks because in the change to the xmlbeans dependency. This requires deleting all of the history files to continue on. Ok, once I get past all of that, I get a whole series of errors that I don't know how to get around. I'm pretty much stuck here, but I'll go back and look at the geronimo-kernel test failures and see if I can figure out what's going on there. Here are the
Re: osgi progress
On Oct 12, 2009, at 5:36 AM, Rick McGuire wrote: David Jencks wrote: I only have a minute so can't address anything in detail right now. Most of the servicemix bundle dependencies can probably be on released versions. I went for speed and used the ones from my checked out servicemix trunk in case I needed to patch them. I don't think we need the geronimo plexus bundles I set up -- although we do need to find some solution for accessing the code or not using it at all. What are the testsuite errors you get? It would be useful to find out if they are windows specific. Similarly it would be great to find out if anyone else can build on a non-windows system :-) I took a little deeper look at the deployment test case errors I'm getting. The root cause of the failure is this exception: Caused by: java.lang.IllegalArgumentException: id must be in the form [groupId]/[artifactId]/[version]/[type] : C:\jencks\g\framework \modules\geronimo-deployment\target\deployTest at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java: 61) at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java: 51) at org .apache .geronimo .kernel.osgi.MockBundleContext.installBundle(MockBundleContext.java: 106) at org .apache .geronimo .deployment .DeploymentContext.createTempConfiguration(DeploymentContext.java:208) ... 28 more Since this is failing just calling bundleContext.installBundle() in the MockBundleContext code, I suspect I'm not running under karaf. Have I missed some setup step somewhere? Karaf is not used during the build: the car-maven-plugin fires up felix and attempts to let all the classes known to the maven plugin be exposed from the felix framework. I don't see why this error would be occurring but another task I think I forgot to mention would be using the ops4j maven urls in the build to load bundles rather than the file system locations I'm constructing. This might sidestep the problem you are seeing. I really don't understand how you could get it and me not see it thanks david jencks Rick thanks david jencks On Oct 9, 2009, at 4:55 AM, Rick McGuire wrote: David Jencks wrote: I changed the url scheme so we always use pax maven urls for everything in the geronimo repository, and now I can get, with some work, all the plugin bundles to start as bundles. However they mostly don't start as plugins (i.e., no gbeans start). I haven't figured out why yet. How to get it to run: build This one word is starting to remind me of the famous Sydney Harris cartoon: http://www.sciencecartoonsplus.com/pages/gallery.php I've had a few issues getting this to build, so I thought I'd capture the notes here for the benefit of others. Some of these we can fix in the build, others are things that need to be accounted for before building. A major problem is getting all of the dependencies into your maven repository so the build can work. 1) servicemix bundles. In addition to the patch that David provided, you need to checkout and build the servicemix bundles from: https://svn.apache.org/repos/asf/servicemix/smx4/bundles/trunk Unfortunately, the root pom for servicemix does not build all of the subprojects. Many of the ones that are skipped are required by Geronimo and need to be built individually. This list includes: jaxb-impl-2.1.6 xmlbeans-2.4.0 (NOTE: this builds 2.4.0_3-SNAPSHOT, but the dependency is currently 2.4.0_2-SNAPSHOT. The Geronimo pom needs to be adjusted). woodstox-3.2.8 jline-0.9.94 The framework builds additional bundlized versions of dependencies, but at the moment, they are not included in the build. The subprojects are located in framework/bundles, but there's no root pom that builds all of these, so each subproject needs to be built individually. There are some dependencies between these subprojects. For example, plexus-archiver depends on plexus-utils, so plexus-utils needs to be built first. Unfortunately, plexus-utils is building version 1.5.15_1-SNAPSHOT, and plexus-archiver has a dependency on 1.4.5_-SNAPSHOT. plexus- utils exports a 1.4.5 level of the packages, so I'm guessing this was intended to be 1.4.5_1-SNAPSHOT, so the POM needs adjusting. Once I've done the steps above, I get some test failures in geronimo-kernel. If I try to build with tests turned off, then I get the following failure: 1) org.apache.geronimo.framework:geronimo-kernel:jar:tests:3.0- SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file - DgroupId=org.apache.geronimo.framework -Dartifac tId=geronimo-kernel -Dversion=3.0-SNAPSHOT -Dclassifier=tests - Dpackaging=jar -D file=/path/to/file most likely the result of the test failures. The test failures don't make much sense to me, but this might be a Windows-specific
Re: osgi progress
I think this particular problem is caused by running on windows. In MockBundleContext just before this line I manipulate the location to remove cruft from the beginning. I think we need to add some more tests to remove windows specific cruft. Since I don't have a windows machine I'm not sure how to find out exactly what needs to be changed debugging and finding out what is in the locations map should provide a big hint. thanks david jencks On Oct 12, 2009, at 5:36 AM, Rick McGuire wrote: David Jencks wrote: I only have a minute so can't address anything in detail right now. Most of the servicemix bundle dependencies can probably be on released versions. I went for speed and used the ones from my checked out servicemix trunk in case I needed to patch them. I don't think we need the geronimo plexus bundles I set up -- although we do need to find some solution for accessing the code or not using it at all. What are the testsuite errors you get? It would be useful to find out if they are windows specific. Similarly it would be great to find out if anyone else can build on a non-windows system :-) I took a little deeper look at the deployment test case errors I'm getting. The root cause of the failure is this exception: Caused by: java.lang.IllegalArgumentException: id must be in the form [groupId]/[artifactId]/[version]/[type] : C:\jencks\g\framework \modules\geronimo-deployment\target\deployTest at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java: 61) at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java: 51) at org .apache .geronimo .kernel.osgi.MockBundleContext.installBundle(MockBundleContext.java: 106) at org .apache .geronimo .deployment .DeploymentContext.createTempConfiguration(DeploymentContext.java:208) ... 28 more Since this is failing just calling bundleContext.installBundle() in the MockBundleContext code, I suspect I'm not running under karaf. Have I missed some setup step somewhere? Rick thanks david jencks On Oct 9, 2009, at 4:55 AM, Rick McGuire wrote: David Jencks wrote: I changed the url scheme so we always use pax maven urls for everything in the geronimo repository, and now I can get, with some work, all the plugin bundles to start as bundles. However they mostly don't start as plugins (i.e., no gbeans start). I haven't figured out why yet. How to get it to run: build This one word is starting to remind me of the famous Sydney Harris cartoon: http://www.sciencecartoonsplus.com/pages/gallery.php I've had a few issues getting this to build, so I thought I'd capture the notes here for the benefit of others. Some of these we can fix in the build, others are things that need to be accounted for before building. A major problem is getting all of the dependencies into your maven repository so the build can work. 1) servicemix bundles. In addition to the patch that David provided, you need to checkout and build the servicemix bundles from: https://svn.apache.org/repos/asf/servicemix/smx4/bundles/trunk Unfortunately, the root pom for servicemix does not build all of the subprojects. Many of the ones that are skipped are required by Geronimo and need to be built individually. This list includes: jaxb-impl-2.1.6 xmlbeans-2.4.0 (NOTE: this builds 2.4.0_3-SNAPSHOT, but the dependency is currently 2.4.0_2-SNAPSHOT. The Geronimo pom needs to be adjusted). woodstox-3.2.8 jline-0.9.94 The framework builds additional bundlized versions of dependencies, but at the moment, they are not included in the build. The subprojects are located in framework/bundles, but there's no root pom that builds all of these, so each subproject needs to be built individually. There are some dependencies between these subprojects. For example, plexus-archiver depends on plexus-utils, so plexus-utils needs to be built first. Unfortunately, plexus-utils is building version 1.5.15_1-SNAPSHOT, and plexus-archiver has a dependency on 1.4.5_-SNAPSHOT. plexus- utils exports a 1.4.5 level of the packages, so I'm guessing this was intended to be 1.4.5_1-SNAPSHOT, so the POM needs adjusting. Once I've done the steps above, I get some test failures in geronimo-kernel. If I try to build with tests turned off, then I get the following failure: 1) org.apache.geronimo.framework:geronimo-kernel:jar:tests:3.0- SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file - DgroupId=org.apache.geronimo.framework -Dartifac tId=geronimo-kernel -Dversion=3.0-SNAPSHOT -Dclassifier=tests - Dpackaging=jar -D file=/path/to/file most likely the result of the test failures. The test failures don't make much sense to me, but this might be a Windows-specific problem with normalizing URLs. If I comment out the assertions that are
Re: osgi progress
David Jencks wrote: I think this particular problem is caused by running on windows. In MockBundleContext just before this line I manipulate the location to remove cruft from the beginning. I think we need to add some more tests to remove windows specific cruft. Since I don't have a windows machine I'm not sure how to find out exactly what needs to be changed debugging and finding out what is in the locations map should provide a big hint. Ok, I was just in the process of doing that very debugging. Rick thanks david jencks On Oct 12, 2009, at 5:36 AM, Rick McGuire wrote: David Jencks wrote: I only have a minute so can't address anything in detail right now. Most of the servicemix bundle dependencies can probably be on released versions. I went for speed and used the ones from my checked out servicemix trunk in case I needed to patch them. I don't think we need the geronimo plexus bundles I set up -- although we do need to find some solution for accessing the code or not using it at all. What are the testsuite errors you get? It would be useful to find out if they are windows specific. Similarly it would be great to find out if anyone else can build on a non-windows system :-) I took a little deeper look at the deployment test case errors I'm getting. The root cause of the failure is this exception: Caused by: java.lang.IllegalArgumentException: id must be in the form [groupId]/[artifactId]/[version]/[type] : C:\jencks\g\framework\modules\geronimo-deployment\target\deployTest at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:61) at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:51) at org.apache.geronimo.kernel.osgi.MockBundleContext.installBundle(MockBundleContext.java:106) at org.apache.geronimo.deployment.DeploymentContext.createTempConfiguration(DeploymentContext.java:208) ... 28 more Since this is failing just calling bundleContext.installBundle() in the MockBundleContext code, I suspect I'm not running under karaf. Have I missed some setup step somewhere? Rick thanks david jencks On Oct 9, 2009, at 4:55 AM, Rick McGuire wrote: David Jencks wrote: I changed the url scheme so we always use pax maven urls for everything in the geronimo repository, and now I can get, with some work, all the plugin bundles to start as bundles. However they mostly don't start as plugins (i.e., no gbeans start). I haven't figured out why yet. How to get it to run: build This one word is starting to remind me of the famous Sydney Harris cartoon: http://www.sciencecartoonsplus.com/pages/gallery.php I've had a few issues getting this to build, so I thought I'd capture the notes here for the benefit of others. Some of these we can fix in the build, others are things that need to be accounted for before building. A major problem is getting all of the dependencies into your maven repository so the build can work. 1) servicemix bundles. In addition to the patch that David provided, you need to checkout and build the servicemix bundles from: https://svn.apache.org/repos/asf/servicemix/smx4/bundles/trunk Unfortunately, the root pom for servicemix does not build all of the subprojects. Many of the ones that are skipped are required by Geronimo and need to be built individually. This list includes: jaxb-impl-2.1.6 xmlbeans-2.4.0 (NOTE: this builds 2.4.0_3-SNAPSHOT, but the dependency is currently 2.4.0_2-SNAPSHOT. The Geronimo pom needs to be adjusted). woodstox-3.2.8 jline-0.9.94 The framework builds additional bundlized versions of dependencies, but at the moment, they are not included in the build. The subprojects are located in framework/bundles, but there's no root pom that builds all of these, so each subproject needs to be built individually. There are some dependencies between these subprojects. For example, plexus-archiver depends on plexus-utils, so plexus-utils needs to be built first. Unfortunately, plexus-utils is building version 1.5.15_1-SNAPSHOT, and plexus-archiver has a dependency on 1.4.5_-SNAPSHOT. plexus-utils exports a 1.4.5 level of the packages, so I'm guessing this was intended to be 1.4.5_1-SNAPSHOT, so the POM needs adjusting. Once I've done the steps above, I get some test failures in geronimo-kernel. If I try to build with tests turned off, then I get the following failure: 1) org.apache.geronimo.framework:geronimo-kernel:jar:tests:3.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.framework -Dartifac tId=geronimo-kernel -Dversion=3.0-SNAPSHOT -Dclassifier=tests -Dpackaging=jar -D file=/path/to/file most likely the result of the test failures. The test failures don't make much sense to me, but this might be a Windows-specific problem with normalizing URLs. If I comment out the
Re: osgi progress
David Jencks wrote: I think this particular problem is caused by running on windows. In MockBundleContext just before this line I manipulate the location to remove cruft from the beginning. I think we need to add some more tests to remove windows specific cruft. Since I don't have a windows machine I'm not sure how to find out exactly what needs to be changed debugging and finding out what is in the locations map should provide a big hint. Ok, I've checked in a fix for this. The setup code for the test was assuming that dir.getAbsolutePath().substring(1) would just chop off the root dir delimiter. On Windows, that cut off the drive letter, resulting in a location of :\yada\yada\ getting stored in location. The MockBundleContext install() was correctly using C:\yada\yada\..., and not finding it. The deployment tests now run cleanly, on to the next problem :-) Rick thanks david jencks On Oct 12, 2009, at 5:36 AM, Rick McGuire wrote: David Jencks wrote: I only have a minute so can't address anything in detail right now. Most of the servicemix bundle dependencies can probably be on released versions. I went for speed and used the ones from my checked out servicemix trunk in case I needed to patch them. I don't think we need the geronimo plexus bundles I set up -- although we do need to find some solution for accessing the code or not using it at all. What are the testsuite errors you get? It would be useful to find out if they are windows specific. Similarly it would be great to find out if anyone else can build on a non-windows system :-) I took a little deeper look at the deployment test case errors I'm getting. The root cause of the failure is this exception: Caused by: java.lang.IllegalArgumentException: id must be in the form [groupId]/[artifactId]/[version]/[type] : C:\jencks\g\framework\modules\geronimo-deployment\target\deployTest at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:61) at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:51) at org.apache.geronimo.kernel.osgi.MockBundleContext.installBundle(MockBundleContext.java:106) at org.apache.geronimo.deployment.DeploymentContext.createTempConfiguration(DeploymentContext.java:208) ... 28 more Since this is failing just calling bundleContext.installBundle() in the MockBundleContext code, I suspect I'm not running under karaf. Have I missed some setup step somewhere? Rick thanks david jencks On Oct 9, 2009, at 4:55 AM, Rick McGuire wrote: David Jencks wrote: I changed the url scheme so we always use pax maven urls for everything in the geronimo repository, and now I can get, with some work, all the plugin bundles to start as bundles. However they mostly don't start as plugins (i.e., no gbeans start). I haven't figured out why yet. How to get it to run: build This one word is starting to remind me of the famous Sydney Harris cartoon: http://www.sciencecartoonsplus.com/pages/gallery.php I've had a few issues getting this to build, so I thought I'd capture the notes here for the benefit of others. Some of these we can fix in the build, others are things that need to be accounted for before building. A major problem is getting all of the dependencies into your maven repository so the build can work. 1) servicemix bundles. In addition to the patch that David provided, you need to checkout and build the servicemix bundles from: https://svn.apache.org/repos/asf/servicemix/smx4/bundles/trunk Unfortunately, the root pom for servicemix does not build all of the subprojects. Many of the ones that are skipped are required by Geronimo and need to be built individually. This list includes: jaxb-impl-2.1.6 xmlbeans-2.4.0 (NOTE: this builds 2.4.0_3-SNAPSHOT, but the dependency is currently 2.4.0_2-SNAPSHOT. The Geronimo pom needs to be adjusted). woodstox-3.2.8 jline-0.9.94 The framework builds additional bundlized versions of dependencies, but at the moment, they are not included in the build. The subprojects are located in framework/bundles, but there's no root pom that builds all of these, so each subproject needs to be built individually. There are some dependencies between these subprojects. For example, plexus-archiver depends on plexus-utils, so plexus-utils needs to be built first. Unfortunately, plexus-utils is building version 1.5.15_1-SNAPSHOT, and plexus-archiver has a dependency on 1.4.5_-SNAPSHOT. plexus-utils exports a 1.4.5 level of the packages, so I'm guessing this was intended to be 1.4.5_1-SNAPSHOT, so the POM needs adjusting. Once I've done the steps above, I get some test failures in geronimo-kernel. If I try to build with tests turned off, then I get the following failure: 1) org.apache.geronimo.framework:geronimo-kernel:jar:tests:3.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the
More OSGi progress
Time to start a new thread, I think. I'm getting further now. The
framework builds, but I'm getting errors trying to build the configs. I
get an IOException attempting to build the J2EE System config (see
below). The file in question is
java.io.IOException: Referenced file does not exist:
C:\jencks\g\framework\confi
gs\j2ee-system\target\repository\org\apache\geronimo\framework\j2ee-system\3.0-S
NAPSHOT\j2ee-system-3.0-SNAPSHOT.car
which actually does exist. Strangely, this does not kill the build, but
it then dies trying to build the rmi-naming config with a similar error
trying to load the rmi-naming car file. This one does kill the build.
Both exceptions occur when starting the Felix framework, but I'm not
sure where the reference to that file is coming from. Any suggestions
on where I might start debugging this problem?
Rick
[INFO] [car:update-pluginlist]
[INFO]
[INFO] Building Geronimo Framework, Configs :: J2EE System
[INFO]task-segment: [install]
[INFO]
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] skip non existing resourceDirectory
C:\jencks\g\framework\configs\j2ee-sy
stem\src\main\filtered-resources
[INFO] Copying 3 resources
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated:
C:\jencks\g\framework\configs\j2ee-system\target\work\plan.xml
[INFO] [car:verify-no-dependency-change]
[INFO] [car:prepare-metadata]
[INFO] [car:package]
[INFO] Packaging module configuration:
C:\jencks\g\framework\configs\j2ee-system
\target\work\plan.xml
ERROR: Error creating archive. (java.io.IOException: Referenced file
does not ex
ist:
C:\jencks\g\framework\configs\j2ee-system\target\repository\org\apache\gero
nimo\framework\j2ee-system\3.0-SNAPSHOT\j2ee-system-3.0-SNAPSHOT.car)
java.io.IOException: Referenced file does not exist:
C:\jencks\g\framework\confi
gs\j2ee-system\target\repository\org\apache\geronimo\framework\j2ee-system\3.0-S
NAPSHOT\j2ee-system-3.0-SNAPSHOT.car
at
org.apache.felix.framework.cache.BundleArchive.createRevisionFromLoca
tion(BundleArchive.java:994)
at
org.apache.felix.framework.cache.BundleArchive.revise(BundleArchive.j
ava:631)
at
org.apache.felix.framework.cache.BundleArchive.init(BundleArchive.j
ava:206)
at
org.apache.felix.framework.cache.BundleCache.getArchives(BundleCache.
java:149)
at org.apache.felix.framework.Felix.init(Felix.java:558)
at org.apache.felix.framework.Felix.start(Felix.java:683)
at
org.apache.geronimo.mavenplugins.car.AbstractCarMojo.getFramework(Abs
tractCarMojo.java:771)
at
org.apache.geronimo.mavenplugins.car.PackageMojo.createKernel(Package
Mojo.java:360)
at
org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage(Package
Mojo.java:294)
at
org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.
java:234)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:453)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:500)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:479)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:331)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:292)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
ERROR: Error starting
reference:file://c:\.m2\repository\org\apache\geronimo\fra
Re: More OSGi progress
Once I fixed my manifest problem I ran into this problem as well. But
somehow I bypassed it by building the config modules individually...
Then I ran into the problem that Ivan reported. I think I just fixed
that problem as well and got a little bit further.
Jarek
On Mon, Oct 12, 2009 at 3:11 PM, Rick McGuire rick...@gmail.com wrote:
Time to start a new thread, I think. I'm getting further now. The
framework builds, but I'm getting errors trying to build the configs. I get
an IOException attempting to build the J2EE System config (see below). The
file in question is
java.io.IOException: Referenced file does not exist:
C:\jencks\g\framework\confi
gs\j2ee-system\target\repository\org\apache\geronimo\framework\j2ee-system\3.0-S
NAPSHOT\j2ee-system-3.0-SNAPSHOT.car
which actually does exist. Strangely, this does not kill the build, but it
then dies trying to build the rmi-naming config with a similar error trying
to load the rmi-naming car file. This one does kill the build. Both
exceptions occur when starting the Felix framework, but I'm not sure where
the reference to that file is coming from. Any suggestions on where I might
start debugging this problem?
Rick
[INFO] [car:update-pluginlist]
[INFO]
[INFO] Building Geronimo Framework, Configs :: J2EE System
[INFO] task-segment: [install]
[INFO]
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] skip non existing resourceDirectory
C:\jencks\g\framework\configs\j2ee-sy
stem\src\main\filtered-resources
[INFO] Copying 3 resources
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated:
C:\jencks\g\framework\configs\j2ee-system\target\work\plan.xml
[INFO] [car:verify-no-dependency-change]
[INFO] [car:prepare-metadata]
[INFO] [car:package]
[INFO] Packaging module configuration:
C:\jencks\g\framework\configs\j2ee-system
\target\work\plan.xml
ERROR: Error creating archive. (java.io.IOException: Referenced file does
not ex
ist:
C:\jencks\g\framework\configs\j2ee-system\target\repository\org\apache\gero
nimo\framework\j2ee-system\3.0-SNAPSHOT\j2ee-system-3.0-SNAPSHOT.car)
java.io.IOException: Referenced file does not exist:
C:\jencks\g\framework\confi
gs\j2ee-system\target\repository\org\apache\geronimo\framework\j2ee-system\3.0-S
NAPSHOT\j2ee-system-3.0-SNAPSHOT.car
at
org.apache.felix.framework.cache.BundleArchive.createRevisionFromLoca
tion(BundleArchive.java:994)
at
org.apache.felix.framework.cache.BundleArchive.revise(BundleArchive.j
ava:631)
at
org.apache.felix.framework.cache.BundleArchive.init(BundleArchive.j
ava:206)
at
org.apache.felix.framework.cache.BundleCache.getArchives(BundleCache.
java:149)
at org.apache.felix.framework.Felix.init(Felix.java:558)
at org.apache.felix.framework.Felix.start(Felix.java:683)
at
org.apache.geronimo.mavenplugins.car.AbstractCarMojo.getFramework(Abs
tractCarMojo.java:771)
at
org.apache.geronimo.mavenplugins.car.PackageMojo.createKernel(Package
Mojo.java:360)
at
org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage(Package
Mojo.java:294)
at
org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.
java:234)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:453)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:500)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:479)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:331)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:292)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
Re: More OSGi progress
Btw, I've been using Maven 2.0.10 to build the framework but I'm
getting better results with 2.2.1.
Jarek
On Mon, Oct 12, 2009 at 8:49 PM, Jarek Gawor jga...@gmail.com wrote:
Once I fixed my manifest problem I ran into this problem as well. But
somehow I bypassed it by building the config modules individually...
Then I ran into the problem that Ivan reported. I think I just fixed
that problem as well and got a little bit further.
Jarek
On Mon, Oct 12, 2009 at 3:11 PM, Rick McGuire rick...@gmail.com wrote:
Time to start a new thread, I think. I'm getting further now. The
framework builds, but I'm getting errors trying to build the configs. I get
an IOException attempting to build the J2EE System config (see below). The
file in question is
java.io.IOException: Referenced file does not exist:
C:\jencks\g\framework\confi
gs\j2ee-system\target\repository\org\apache\geronimo\framework\j2ee-system\3.0-S
NAPSHOT\j2ee-system-3.0-SNAPSHOT.car
which actually does exist. Strangely, this does not kill the build, but it
then dies trying to build the rmi-naming config with a similar error trying
to load the rmi-naming car file. This one does kill the build. Both
exceptions occur when starting the Felix framework, but I'm not sure where
the reference to that file is coming from. Any suggestions on where I might
start debugging this problem?
Rick
[INFO] [car:update-pluginlist]
[INFO]
[INFO] Building Geronimo Framework, Configs :: J2EE System
[INFO] task-segment: [install]
[INFO]
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] skip non existing resourceDirectory
C:\jencks\g\framework\configs\j2ee-sy
stem\src\main\filtered-resources
[INFO] Copying 3 resources
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated:
C:\jencks\g\framework\configs\j2ee-system\target\work\plan.xml
[INFO] [car:verify-no-dependency-change]
[INFO] [car:prepare-metadata]
[INFO] [car:package]
[INFO] Packaging module configuration:
C:\jencks\g\framework\configs\j2ee-system
\target\work\plan.xml
ERROR: Error creating archive. (java.io.IOException: Referenced file does
not ex
ist:
C:\jencks\g\framework\configs\j2ee-system\target\repository\org\apache\gero
nimo\framework\j2ee-system\3.0-SNAPSHOT\j2ee-system-3.0-SNAPSHOT.car)
java.io.IOException: Referenced file does not exist:
C:\jencks\g\framework\confi
gs\j2ee-system\target\repository\org\apache\geronimo\framework\j2ee-system\3.0-S
NAPSHOT\j2ee-system-3.0-SNAPSHOT.car
at
org.apache.felix.framework.cache.BundleArchive.createRevisionFromLoca
tion(BundleArchive.java:994)
at
org.apache.felix.framework.cache.BundleArchive.revise(BundleArchive.j
ava:631)
at
org.apache.felix.framework.cache.BundleArchive.init(BundleArchive.j
ava:206)
at
org.apache.felix.framework.cache.BundleCache.getArchives(BundleCache.
java:149)
at org.apache.felix.framework.Felix.init(Felix.java:558)
at org.apache.felix.framework.Felix.start(Felix.java:683)
at
org.apache.geronimo.mavenplugins.car.AbstractCarMojo.getFramework(Abs
tractCarMojo.java:771)
at
org.apache.geronimo.mavenplugins.car.PackageMojo.createKernel(Package
Mojo.java:360)
at
org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage(Package
Mojo.java:294)
at
org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.
java:234)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:453)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:500)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:479)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:331)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:292)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
Re: osgi progress
David Jencks wrote:
I changed the url scheme so we always use pax maven urls for
everything in the geronimo repository, and now I can get, with some
work, all the plugin bundles to start as bundles. However they mostly
don't start as plugins (i.e., no gbeans start). I haven't figured out
why yet.
How to get it to run:
build
This one word is starting to remind me of the famous Sydney Harris cartoon:
http://www.sciencecartoonsplus.com/pages/gallery.php
I've had a few issues getting this to build, so I thought I'd capture
the notes here for the benefit of others. Some of these we can fix in
the build, others are things that need to be accounted for before
building. A major problem is getting all of the dependencies into your
maven repository so the build can work.
1) servicemix bundles. In addition to the patch that David provided,
you need to checkout and build the servicemix bundles from:
https://svn.apache.org/repos/asf/servicemix/smx4/bundles/trunk
Unfortunately, the root pom for servicemix does not build all of the
subprojects. Many of the ones that are skipped are required by Geronimo
and need to be built individually. This list includes:
jaxb-impl-2.1.6
xmlbeans-2.4.0 (NOTE: this builds 2.4.0_3-SNAPSHOT, but the dependency
is currently 2.4.0_2-SNAPSHOT. The Geronimo pom needs to be adjusted).
woodstox-3.2.8
jline-0.9.94
The framework builds additional bundlized versions of dependencies, but
at the moment, they are not included in the build. The subprojects are
located in framework/bundles, but there's no root pom that builds all of
these, so each subproject needs to be built individually. There are
some dependencies between these subprojects. For example,
plexus-archiver depends on plexus-utils, so plexus-utils needs to be
built first. Unfortunately, plexus-utils is building version
1.5.15_1-SNAPSHOT, and plexus-archiver has a dependency on
1.4.5_-SNAPSHOT. plexus-utils exports a 1.4.5 level of the packages, so
I'm guessing this was intended to be 1.4.5_1-SNAPSHOT, so the POM needs
adjusting.
Once I've done the steps above, I get some test failures in
geronimo-kernel. If I try to build with tests turned off, then I get
the following failure:
1) org.apache.geronimo.framework:geronimo-kernel:jar:tests:3.0-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.geronimo.framework
-Dartifac
tId=geronimo-kernel -Dversion=3.0-SNAPSHOT -Dclassifier=tests
-Dpackaging=jar -D
file=/path/to/file
most likely the result of the test failures. The test failures don't
make much sense to me, but this might be a Windows-specific problem with
normalizing URLs. If I comment out the assertions that are failing, I'm
able to get geronimo-kernel to build, but get test failures in other
projects. Now, however, disabling the tests appears to work.
This gets me to errors with the dependency history checks because in the
change to the xmlbeans dependency. This requires deleting all of the
history files to continue on.
Ok, once I get past all of that, I get a whole series of errors that I
don't know how to get around. I'm pretty much stuck here, but I'll go
back and look at the geronimo-kernel test failures and see if I can
figure out what's going on there. Here are the errors I see:
[INFO] [car:update-pluginlist]
[INFO]
[INFO] Building Geronimo Framework, Configs :: Plugin Management
[INFO]task-segment: [install]
[INFO]
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [dependency:unpack {execution: default}]
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] skip non existing resourceDirectory
C:\jencks\g\framework\configs\plugin\
src\main\filtered-resources
[INFO] Copying 3 resources
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated: C:\jencks\g\framework\configs\plugin\target\work\plan.xml
[INFO] [car:verify-no-dependency-change]
[INFO] [car:prepare-metadata]
[INFO] [car:package]
[INFO] Packaging module configuration:
C:\jencks\g\framework\configs\plugin\targ
et\work\plan.xml
ERROR: Error creating archive. (java.io.IOException: Referenced file
does not ex
ist:
C:\jencks\g\framework\configs\plugin\target\repository\org\apache\geronimo\
framework\plugin\3.0-SNAPSHOT\plugin-3.0-SNAPSHOT.car)
java.io.IOException: Referenced file does not exist:
C:\jencks\g\framework\confi
gs\plugin\target\repository\org\apache\geronimo\framework\plugin\3.0-SNAPSHOT\pl
ugin-3.0-SNAPSHOT.car
at
org.apache.felix.framework.cache.BundleArchive.createRevisionFromLoca
Re: osgi progress
I only have a minute so can't address anything in detail right now.
Most of the servicemix bundle dependencies can probably be on released
versions. I went for speed and used the ones from my checked out
servicemix trunk in case I needed to patch them.
I don't think we need the geronimo plexus bundles I set up -- although
we do need to find some solution for accessing the code or not using
it at all.
What are the testsuite errors you get? It would be useful to find out
if they are windows specific. Similarly it would be great to find out
if anyone else can build on a non-windows system :-)
thanks
david jencks
On Oct 9, 2009, at 4:55 AM, Rick McGuire wrote:
David Jencks wrote:
I changed the url scheme so we always use pax maven urls for
everything in the geronimo repository, and now I can get, with some
work, all the plugin bundles to start as bundles. However they
mostly don't start as plugins (i.e., no gbeans start). I haven't
figured out why yet.
How to get it to run:
build
This one word is starting to remind me of the famous Sydney Harris
cartoon:
http://www.sciencecartoonsplus.com/pages/gallery.php
I've had a few issues getting this to build, so I thought I'd
capture the notes here for the benefit of others. Some of these we
can fix in the build, others are things that need to be accounted
for before building. A major problem is getting all of the
dependencies into your maven repository so the build can work.
1) servicemix bundles. In addition to the patch that David
provided, you need to checkout and build the servicemix bundles from:
https://svn.apache.org/repos/asf/servicemix/smx4/bundles/trunk
Unfortunately, the root pom for servicemix does not build all of the
subprojects. Many of the ones that are skipped are required by
Geronimo and need to be built individually. This list includes:
jaxb-impl-2.1.6
xmlbeans-2.4.0 (NOTE: this builds 2.4.0_3-SNAPSHOT, but the
dependency is currently 2.4.0_2-SNAPSHOT. The Geronimo pom needs to
be adjusted).
woodstox-3.2.8
jline-0.9.94
The framework builds additional bundlized versions of dependencies,
but at the moment, they are not included in the build. The
subprojects are located in framework/bundles, but there's no root
pom that builds all of these, so each subproject needs to be built
individually. There are some dependencies between these
subprojects. For example, plexus-archiver depends on plexus-utils,
so plexus-utils needs to be built first. Unfortunately, plexus-
utils is building version 1.5.15_1-SNAPSHOT, and plexus-archiver has
a dependency on 1.4.5_-SNAPSHOT. plexus-utils exports a 1.4.5 level
of the packages, so I'm guessing this was intended to be 1.4.5_1-
SNAPSHOT, so the POM needs adjusting.
Once I've done the steps above, I get some test failures in geronimo-
kernel. If I try to build with tests turned off, then I get the
following failure:
1) org.apache.geronimo.framework:geronimo-kernel:jar:tests:3.0-
SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.geronimo.framework
-Dartifac
tId=geronimo-kernel -Dversion=3.0-SNAPSHOT -Dclassifier=tests -
Dpackaging=jar -D
file=/path/to/file
most likely the result of the test failures. The test failures
don't make much sense to me, but this might be a Windows-specific
problem with normalizing URLs. If I comment out the assertions that
are failing, I'm able to get geronimo-kernel to build, but get test
failures in other projects. Now, however, disabling the tests
appears to work.
This gets me to errors with the dependency history checks because in
the change to the xmlbeans dependency. This requires deleting all
of the history files to continue on.
Ok, once I get past all of that, I get a whole series of errors that
I don't know how to get around. I'm pretty much stuck here, but
I'll go back and look at the geronimo-kernel test failures and see
if I can figure out what's going on there. Here are the errors I see:
[INFO] [car:update-pluginlist]
[INFO]
[INFO] Building Geronimo Framework, Configs :: Plugin Management
[INFO]task-segment: [install]
[INFO]
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [dependency:unpack {execution: default}]
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] skip non existing resourceDirectory C:\jencks\g\framework
\configs\plugin\
src\main\filtered-resources
[INFO] Copying 3 resources
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated:
Re: osgi progress
David Jencks wrote:
I only have a minute so can't address anything in detail right now.
Most of the servicemix bundle dependencies can probably be on released
versions. I went for speed and used the ones from my checked out
servicemix trunk in case I needed to patch them.
I don't think we need the geronimo plexus bundles I set up -- although
we do need to find some solution for accessing the code or not using
it at all.
What are the testsuite errors you get? It would be useful to find out
if they are windows specific. Similarly it would be great to find out
if anyone else can build on a non-windows system :-)
I checked in a fix for the geronimo-kernel error. There was a
difference between the test in trunk and the one in your sandbox. Using
the trunk version made the problem go away. Now I'm getting as far as
the deployer tests, which seem to be having problems with the deployment
config ids. I haven't gotten very far with trying to sort those out yet.
Rick
thanks
david jencks
On Oct 9, 2009, at 4:55 AM, Rick McGuire wrote:
David Jencks wrote:
I changed the url scheme so we always use pax maven urls for
everything in the geronimo repository, and now I can get, with some
work, all the plugin bundles to start as bundles. However they
mostly don't start as plugins (i.e., no gbeans start). I haven't
figured out why yet.
How to get it to run:
build
This one word is starting to remind me of the famous Sydney Harris
cartoon:
http://www.sciencecartoonsplus.com/pages/gallery.php
I've had a few issues getting this to build, so I thought I'd capture
the notes here for the benefit of others. Some of these we can fix
in the build, others are things that need to be accounted for before
building. A major problem is getting all of the dependencies into
your maven repository so the build can work.
1) servicemix bundles. In addition to the patch that David
provided, you need to checkout and build the servicemix bundles from:
https://svn.apache.org/repos/asf/servicemix/smx4/bundles/trunk
Unfortunately, the root pom for servicemix does not build all of the
subprojects. Many of the ones that are skipped are required by
Geronimo and need to be built individually. This list includes:
jaxb-impl-2.1.6
xmlbeans-2.4.0 (NOTE: this builds 2.4.0_3-SNAPSHOT, but the
dependency is currently 2.4.0_2-SNAPSHOT. The Geronimo pom needs to
be adjusted).
woodstox-3.2.8
jline-0.9.94
The framework builds additional bundlized versions of dependencies,
but at the moment, they are not included in the build. The
subprojects are located in framework/bundles, but there's no root pom
that builds all of these, so each subproject needs to be built
individually. There are some dependencies between these
subprojects. For example, plexus-archiver depends on plexus-utils,
so plexus-utils needs to be built first. Unfortunately, plexus-utils
is building version 1.5.15_1-SNAPSHOT, and plexus-archiver has a
dependency on 1.4.5_-SNAPSHOT. plexus-utils exports a 1.4.5 level of
the packages, so I'm guessing this was intended to be
1.4.5_1-SNAPSHOT, so the POM needs adjusting.
Once I've done the steps above, I get some test failures in
geronimo-kernel. If I try to build with tests turned off, then I get
the following failure:
1) org.apache.geronimo.framework:geronimo-kernel:jar:tests:3.0-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.geronimo.framework
-Dartifac
tId=geronimo-kernel -Dversion=3.0-SNAPSHOT -Dclassifier=tests
-Dpackaging=jar -D
file=/path/to/file
most likely the result of the test failures. The test failures
don't make much sense to me, but this might be a Windows-specific
problem with normalizing URLs. If I comment out the assertions that
are failing, I'm able to get geronimo-kernel to build, but get test
failures in other projects. Now, however, disabling the tests
appears to work.
This gets me to errors with the dependency history checks because in
the change to the xmlbeans dependency. This requires deleting all of
the history files to continue on.
Ok, once I get past all of that, I get a whole series of errors that
I don't know how to get around. I'm pretty much stuck here, but I'll
go back and look at the geronimo-kernel test failures and see if I
can figure out what's going on there. Here are the errors I see:
[INFO] [car:update-pluginlist]
[INFO]
[INFO] Building Geronimo Framework, Configs :: Plugin Management
[INFO]task-segment: [install]
[INFO]
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [dependency:unpack {execution: default}]
[INFO]
Re: osgi progress
I don't know if that's the same problem that Rick is seeing but I'm getting the following error while building geronimo-gbean-deployer-bootstrap car: ... [INFO] [car:package] Packaging module configuration: /home/gawor/development/geronimo/osgi/framework/configs/geronimo-gbean-deployer-bootstrap/target/work/plan.xml 01:08:11,663 INFO [DeploymentContext] The Strict Manifest Classpath processing mode is in effect. This option can be altered by specifying -DXorg.apache.geronimo.deployment.LenientMFCP=true|false Specify =true for more lenient processing such as ignoring missing jars and references that are not spec compliant. java.io.FileNotFoundException: /home/gawor/development/geronimo/osgi/framework/configs/geronimo-gbean-deployer-bootstrap/target/META-INF/MANIFEST.MF (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at org.apache.felix.framework.util.SecureAction.getFileInputStream(SecureAction.java:414) at org.apache.felix.framework.cache.DirectoryRevision.getManifestHeader(DirectoryRevision.java:78) at org.apache.felix.framework.BundleImpl.createModule(BundleImpl.java:1110) at org.apache.felix.framework.BundleImpl.init(BundleImpl.java:79) at org.apache.felix.framework.Felix.installBundle(Felix.java:2372) at org.apache.felix.framework.Felix.installBundle(Felix.java:2277) at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:130) at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:108) at org.apache.geronimo.deployment.DeploymentContext.createTempConfiguration(DeploymentContext.java:208) ... Jarek On Fri, Oct 9, 2009 at 2:25 PM, Rick McGuire rick...@gmail.com wrote: David Jencks wrote: I only have a minute so can't address anything in detail right now. Most of the servicemix bundle dependencies can probably be on released versions. I went for speed and used the ones from my checked out servicemix trunk in case I needed to patch them. I don't think we need the geronimo plexus bundles I set up -- although we do need to find some solution for accessing the code or not using it at all. What are the testsuite errors you get? It would be useful to find out if they are windows specific. Similarly it would be great to find out if anyone else can build on a non-windows system :-) I checked in a fix for the geronimo-kernel error. There was a difference between the test in trunk and the one in your sandbox. Using the trunk version made the problem go away. Now I'm getting as far as the deployer tests, which seem to be having problems with the deployment config ids. I haven't gotten very far with trying to sort those out yet. Rick thanks david jencks On Oct 9, 2009, at 4:55 AM, Rick McGuire wrote: David Jencks wrote: I changed the url scheme so we always use pax maven urls for everything in the geronimo repository, and now I can get, with some work, all the plugin bundles to start as bundles. However they mostly don't start as plugins (i.e., no gbeans start). I haven't figured out why yet. How to get it to run: build This one word is starting to remind me of the famous Sydney Harris cartoon: http://www.sciencecartoonsplus.com/pages/gallery.php I've had a few issues getting this to build, so I thought I'd capture the notes here for the benefit of others. Some of these we can fix in the build, others are things that need to be accounted for before building. A major problem is getting all of the dependencies into your maven repository so the build can work. 1) servicemix bundles. In addition to the patch that David provided, you need to checkout and build the servicemix bundles from: https://svn.apache.org/repos/asf/servicemix/smx4/bundles/trunk Unfortunately, the root pom for servicemix does not build all of the subprojects. Many of the ones that are skipped are required by Geronimo and need to be built individually. This list includes: jaxb-impl-2.1.6 xmlbeans-2.4.0 (NOTE: this builds 2.4.0_3-SNAPSHOT, but the dependency is currently 2.4.0_2-SNAPSHOT. The Geronimo pom needs to be adjusted). woodstox-3.2.8 jline-0.9.94 The framework builds additional bundlized versions of dependencies, but at the moment, they are not included in the build. The subprojects are located in framework/bundles, but there's no root pom that builds all of these, so each subproject needs to be built individually. There are some dependencies between these subprojects. For example, plexus-archiver depends on plexus-utils, so plexus-utils needs to be built first. Unfortunately, plexus-utils is building version 1.5.15_1-SNAPSHOT, and plexus-archiver has a dependency on 1.4.5_-SNAPSHOT. plexus-utils exports a 1.4.5 level of the packages, so I'm guessing this was intended to be 1.4.5_1-SNAPSHOT, so the POM needs
Re: osgi progress
I changed the url scheme so we always use pax maven urls for
everything in the geronimo repository, and now I can get, with some
work, all the plugin bundles to start as bundles. However they mostly
don't start as plugins (i.e., no gbeans start). I haven't figured out
why yet.
How to get it to run:
build
unpack the assembly (geronimo-framework) and start it as before
The first start, it hangs for me, I think it's still trying to permute
through some large space of possiblitiles. However, killling the
server and restarting doesn't have this problem.
You can then run osgi:list to see which plugins didn't get activated,
and run osgi:start on them.
Looking at config.xml, they all get load=false added.
I think the next step might be to start writing some gogo commands to
operate on the ConfigurationManager. This looks fairly straightforward.
Other stuff that needs to happen:
- figure out how to use pax logging and what we need to remove so we
don't interfere. I think when g. logging starts up it effectively
shuts off all logging.
- Clean up dependencies so we aren't installing a lot of stuff we
don't want, like un-osgi-ified versions of jaxb impl, stax-api, asm,
etc etc etc.
- Clean up generation of geronimo-plugin.xml metadata so it isn't
nested. I added the nesting for one-classloader-per-jar and it needs
to be removed again.
- Figure out how to get the DependencyManager to not try to install
bundles that are already installed. I guess we can get the location
of each installed bundle from the bundle context and compare with the
mvn url string we'd use for installing the new bundle.
- lots and lots of code cleanup.
If anyone wants to take a look at any of these, that would be great.
I'm going to be mostly offline thursday through sunday but will try to
answer any questions that may come up.
thanks
david jencks
On Oct 5, 2009, at 12:08 PM, David Jencks wrote:
I've made some progress with the osgi sandbox. I now have 2
geronimo plugins starting in karaf. I'm not entirely sure what is
happening next, but I think that felix is searching 2 ^^ 50 or more
comibinations for a consistent class space for the 3rd plugin.
I'm going to try equinox next.
I've checked in the current state of my work. If you want to build
it...
you need to build karaf from trunk.
You need to apply this patch to https://svn.apache.org/repos/asf/servicemix/smx4/bundles/trunk/xstream-1.3
and build it:
Index: pom.xml
===
--- pom.xml (revision 821959)
+++ pom.xml (working copy)
@@ -46,14 +46,14 @@
!com.thoughtworks.xstream*,
!sun.misc*,
!sun.reflect*,
-javax.xml.stream*;version=[1.0.1,2),
+javax.xml.stream*;version=[1.0,2),
net.sf.cglib*;resolution:=optional;version=[2.1.3,3),
nu.xom;resolution:=optional;version=[1.1,2),
org.codehaus.jettison*;resolution:=optional;version=[1,2),
org.dom4j*;resolution:=optional;version=[1.6.1,2),
org.jdom*;resolution:=optional;version=[1,2),
org.joda.time*;resolution:=optional;version=[0.9,1),
-org.xmlpull*;version=[1.1.3,2),
+org.xmlpull*;version=[1.1,2),
*
/servicemix.osgi.import.pkg
servicemix.osgi.failoktrue/servicemix.osgi.failok
@@ -65,7 +65,18 @@
artifactId${pkgArtifactId}/artifactId
version${pkgVersion}/version
optionaltrue/optional
+exclusions
+exclusion
+groupIdxpp3/groupId
+artifactIdxpp3/artifactId
+/exclusion
+/exclusions
/dependency
+dependency
+groupIdorg.apache.servicemix.bundles/groupId
+artifactIdorg.apache.servicemix.bundles.xpp3/
artifactId
+version1.1.4c_2-SNAPSHOT/version
+/dependency
/dependencies
build
You need to build all the bundles in the checkout.
With luck you should then be able to build the framework project.
To start, in assemblies/geronimo-framework/target
tar xzf geronimo-framework-3.0-SNAPSHOT-bin.tar.gz ;chmod u+x
geronimo-framework-3.0-SNAPSHOT/bin/karaf
./geronimo-framework-3.0-SNAPSHOT/bin/karaf
thanks
david jencks
osgi progress
I've made some progress with the osgi sandbox. I now have 2 geronimo
plugins starting in karaf. I'm not entirely sure what is happening
next, but I think that felix is searching 2 ^^ 50 or more
comibinations for a consistent class space for the 3rd plugin.
I'm going to try equinox next.
I've checked in the current state of my work. If you want to build
it...
you need to build karaf from trunk.
You need to apply this patch to https://svn.apache.org/repos/asf/servicemix/smx4/bundles/trunk/xstream-1.3
and build it:
Index: pom.xml
===
--- pom.xml (revision 821959)
+++ pom.xml (working copy)
@@ -46,14 +46,14 @@
!com.thoughtworks.xstream*,
!sun.misc*,
!sun.reflect*,
-javax.xml.stream*;version=[1.0.1,2),
+javax.xml.stream*;version=[1.0,2),
net.sf.cglib*;resolution:=optional;version=[2.1.3,3),
nu.xom;resolution:=optional;version=[1.1,2),
org.codehaus.jettison*;resolution:=optional;version=[1,2),
org.dom4j*;resolution:=optional;version=[1.6.1,2),
org.jdom*;resolution:=optional;version=[1,2),
org.joda.time*;resolution:=optional;version=[0.9,1),
-org.xmlpull*;version=[1.1.3,2),
+org.xmlpull*;version=[1.1,2),
*
/servicemix.osgi.import.pkg
servicemix.osgi.failoktrue/servicemix.osgi.failok
@@ -65,7 +65,18 @@
artifactId${pkgArtifactId}/artifactId
version${pkgVersion}/version
optionaltrue/optional
+exclusions
+exclusion
+groupIdxpp3/groupId
+artifactIdxpp3/artifactId
+/exclusion
+/exclusions
/dependency
+dependency
+groupIdorg.apache.servicemix.bundles/groupId
+artifactIdorg.apache.servicemix.bundles.xpp3/artifactId
+version1.1.4c_2-SNAPSHOT/version
+/dependency
/dependencies
build
You need to build all the bundles in the checkout.
With luck you should then be able to build the framework project.
To start, in assemblies/geronimo-framework/target
tar xzf geronimo-framework-3.0-SNAPSHOT-bin.tar.gz ;chmod u+x geronimo-
framework-3.0-SNAPSHOT/bin/karaf
./geronimo-framework-3.0-SNAPSHOT/bin/karaf
thanks
david jencks
Re: OSGI progress
I've been looking into how to create an RFC 66 implementation that can deploy to whatever the Geronimo-hosted web container happens to be. One issue that seems to keep popping up is crossing the bridge between GBeans and OSGi. A lot (ok, all really) that deal with the server runtime and configuration are GBean instances. Some of these GBeans will occasionally need a BundleContext to perform OSGi operations. It would appear that we'd need to have an mechanism to allow a GBean to be injected with a Bundle and/or BundleContext for its hosting configuration. Rick David Jencks wrote: On Sep 22, 2009, at 10:50 PM, Ivan wrote: After reading some code changes of the geronimo-kenel in the sanbox, I found that we keep the Geronimo kenel as an OSGI service, and each Configuration ( or a bundle) will search it and start the configuration as we do in the past while starting. There's a difference in lifecycles between osgi bundles and geronimo configurations. OSGI: bundles can be installed, in which case the classes are not available, or started, in which case the classes are all available and the bundle activator has been started. AFAICT there is no other built in no-really-start-it state beyond started. There might be more less-started states I'm not aware of. Geronimo: A Configuration is a gbean. You can't get much usefaul data out of it until its started. Once it is started the classes are available and you can find out what services (gbeans) are in the configuration and look at their attributes. There's a further state of all gbeans started. The configuration manager treats these states as loaded and started So far it seems to work to do something similar in the osgi environment but it doesn't really fit very well yet. I'm not sure where we will end up with this. I have a feeling that, if we do that, Geronimo is still a part of OSGI env, could we make the Geronimo is an OSGI env? I don't understand what you are asking here. In the sandbox, geronimo plugins are running in an osgi enviroment, and all the classes are loaded from osgi bundles. Could you explain more what you are asking about? Could we publish GBeans as OSGI service via a ConfigurationActivator, or though a GBean-OSGI adapter ? I'm pretty sure we could, but I'd like to get more stuff working before we decide if its a good idea. IIUC blueprint doesn't publish every blueprint bean as an osgi service, but only ones you configure to be published. I suspect we may want to, similarly, only publish some gbeans as osgi services. My current approach is to try to modify the existing geronimo architecture relatively little where possible to get it to run in osgi, respecting osgi architecture. So, I am trying to get stuff working with the kernel as an osgi service, get the deployers working, etc etc. I think after we have done this we will have a much better idea what other work we want to try. For instance, we might not need a kernel at all: possibly gbeans can just be osgi services with a few extra attributes. thanks david jencks Thanks ! 2009/9/22 Rex Wang rwo...@gmail.com mailto:rwo...@gmail.com Yes! hope for detail sharing :-) -Rex 2009/9/22 Jack Cai greensi...@gmail.com mailto:greensi...@gmail.com David, that's exciting work! It'll be great if you can share some more details. There are a few puzzles that flow around my mind - * Are we just taking OSGi framework in as another plug-in to let it host OSGi applications? Or, vice-versa, we are converting Geronimo into an OSGi application? * If the latter case, will GBean go away? * If yes, how much code changes are required? I'd say a lot ... -Jack On Tue, Sep 22, 2009 at 8:25 AM, David Jencks david_jen...@yahoo.com mailto:david_jen...@yahoo.com wrote: Over the weekend I got my sandbox osgi framework to build and generate all the plugins as osgi bundles. This involves running some of the geronimo server on osgi/felix inside maven. The dependency management system seems to work OK at least for starting bundles. I also started doing a little bit of code cleanup. I think the next step will be to get the framework server running in standalone karaf or felix. Hopefully this will be no harder than getting it running in embedded felix in maven. thanks david jencks -- Ivan
Re: OSGI progress
I was just looking at David's framework code and it looks like there is already a way to inject a bundle or bundleContext into a gbean. It works just like injecting the kernel or classLoader attributes. I'm just looking at the code at this point so I don't really know if it works right or not. Jarek On Wed, Sep 30, 2009 at 1:47 PM, Rick McGuire rick...@gmail.com wrote: I've been looking into how to create an RFC 66 implementation that can deploy to whatever the Geronimo-hosted web container happens to be. One issue that seems to keep popping up is crossing the bridge between GBeans and OSGi. A lot (ok, all really) that deal with the server runtime and configuration are GBean instances. Some of these GBeans will occasionally need a BundleContext to perform OSGi operations. It would appear that we'd need to have an mechanism to allow a GBean to be injected with a Bundle and/or BundleContext for its hosting configuration. Rick
Re: OSGI progress
On Sep 30, 2009, at 10:47 AM, Rick McGuire wrote: I've been looking into how to create an RFC 66 implementation that can deploy to whatever the Geronimo-hosted web container happens to be. One issue that seems to keep popping up is crossing the bridge between GBeans and OSGi. A lot (ok, all really) that deal with the server runtime and configuration are GBean instances. Some of these GBeans will occasionally need a BundleContext to perform OSGi operations. It would appear that we'd need to have an mechanism to allow a GBean to be injected with a Bundle and/or BundleContext for its hosting configuration. That's implemented and appears to be working in my osgi sandbox. One of the tasks I envision once the g. framework actually boots up inside karaf is converting all the gbeans that use the magic classloader attribute to use bundle context instead. Currently I'm fighting with a classcast exception deep in plexus that I managed to avoid a couple weeks ago but its popped up again. There are a lot of jars that need to be bundleized and a bunch of problems in the servicemix bundleizations I may be making some progress however. thanks david jencks Rick David Jencks wrote: On Sep 22, 2009, at 10:50 PM, Ivan wrote: After reading some code changes of the geronimo-kenel in the sanbox, I found that we keep the Geronimo kenel as an OSGI service, and each Configuration ( or a bundle) will search it and start the configuration as we do in the past while starting. There's a difference in lifecycles between osgi bundles and geronimo configurations. OSGI: bundles can be installed, in which case the classes are not available, or started, in which case the classes are all available and the bundle activator has been started. AFAICT there is no other built in no-really-start-it state beyond started. There might be more less-started states I'm not aware of. Geronimo: A Configuration is a gbean. You can't get much usefaul data out of it until its started. Once it is started the classes are available and you can find out what services (gbeans) are in the configuration and look at their attributes. There's a further state of all gbeans started. The configuration manager treats these states as loaded and started So far it seems to work to do something similar in the osgi environment but it doesn't really fit very well yet. I'm not sure where we will end up with this. I have a feeling that, if we do that, Geronimo is still a part of OSGI env, could we make the Geronimo is an OSGI env? I don't understand what you are asking here. In the sandbox, geronimo plugins are running in an osgi enviroment, and all the classes are loaded from osgi bundles. Could you explain more what you are asking about? Could we publish GBeans as OSGI service via a ConfigurationActivator, or though a GBean-OSGI adapter ? I'm pretty sure we could, but I'd like to get more stuff working before we decide if its a good idea. IIUC blueprint doesn't publish every blueprint bean as an osgi service, but only ones you configure to be published. I suspect we may want to, similarly, only publish some gbeans as osgi services. My current approach is to try to modify the existing geronimo architecture relatively little where possible to get it to run in osgi, respecting osgi architecture. So, I am trying to get stuff working with the kernel as an osgi service, get the deployers working, etc etc. I think after we have done this we will have a much better idea what other work we want to try. For instance, we might not need a kernel at all: possibly gbeans can just be osgi services with a few extra attributes. thanks david jencks Thanks ! 2009/9/22 Rex Wang rwo...@gmail.com mailto:rwo...@gmail.com Yes! hope for detail sharing :-) -Rex 2009/9/22 Jack Cai greensi...@gmail.com mailto:greensi...@gmail.com David, that's exciting work! It'll be great if you can share some more details. There are a few puzzles that flow around my mind - * Are we just taking OSGi framework in as another plug-in to let it host OSGi applications? Or, vice-versa, we are converting Geronimo into an OSGi application? * If the latter case, will GBean go away? * If yes, how much code changes are required? I'd say a lot ... -Jack On Tue, Sep 22, 2009 at 8:25 AM, David Jencks david_jen...@yahoo.com mailto:david_jen...@yahoo.com wrote: Over the weekend I got my sandbox osgi framework to build and generate all the plugins as osgi bundles. This involves running some of the geronimo server on osgi/felix inside maven. The dependency management system seems to work OK at least for starting bundles. I also started doing a little bit of code cleanup. I think the next step will be
Re: OSGI progress
I learned OSGi while implementing Felix. Was a good place to start. The Felix docs wasn't that good in introducing OSGi (at the time at least) and consisted mostly of example tutorials on implementing the basic OSGi models, though a little bit of logical thought with them got me into starting an OSGi based application in little under an hour. Further, try reading the docs on the OSGi alliance web site. IIRC there were some OSGi introductions that weren't as involved as the spec itself, which helped clear up some questions I had during this development. You could give these a try. Quintin Beukes On Wed, Sep 23, 2009 at 11:39 PM, Jay D. McHugh jaydmch...@gmail.com wrote: So it sounds like I can't put off learning OSGi anymore :) Does anyone have suggested resources (books, websites, or tutorials) that they found useful? Thanks in advance, Jay David Jencks wrote: Over the weekend I got my sandbox osgi framework to build and generate all the plugins as osgi bundles. This involves running some of the geronimo server on osgi/felix inside maven. The dependency management system seems to work OK at least for starting bundles. I also started doing a little bit of code cleanup. I think the next step will be to get the framework server running in standalone karaf or felix. Hopefully this will be no harder than getting it running in embedded felix in maven. thanks david jencks
Re: OSGI progress
On Sep 22, 2009, at 10:50 PM, Ivan wrote: After reading some code changes of the geronimo-kenel in the sanbox, I found that we keep the Geronimo kenel as an OSGI service, and each Configuration ( or a bundle) will search it and start the configuration as we do in the past while starting. There's a difference in lifecycles between osgi bundles and geronimo configurations. OSGI: bundles can be installed, in which case the classes are not available, or started, in which case the classes are all available and the bundle activator has been started. AFAICT there is no other built in no- really-start-it state beyond started. There might be more less- started states I'm not aware of. Geronimo: A Configuration is a gbean. You can't get much usefaul data out of it until its started. Once it is started the classes are available and you can find out what services (gbeans) are in the configuration and look at their attributes. There's a further state of all gbeans started. The configuration manager treats these states as loaded and started So far it seems to work to do something similar in the osgi environment but it doesn't really fit very well yet. I'm not sure where we will end up with this. I have a feeling that, if we do that, Geronimo is still a part of OSGI env, could we make the Geronimo is an OSGI env? I don't understand what you are asking here. In the sandbox, geronimo plugins are running in an osgi enviroment, and all the classes are loaded from osgi bundles. Could you explain more what you are asking about? Could we publish GBeans as OSGI service via a ConfigurationActivator, or though a GBean-OSGI adapter ? I'm pretty sure we could, but I'd like to get more stuff working before we decide if its a good idea. IIUC blueprint doesn't publish every blueprint bean as an osgi service, but only ones you configure to be published. I suspect we may want to, similarly, only publish some gbeans as osgi services. My current approach is to try to modify the existing geronimo architecture relatively little where possible to get it to run in osgi, respecting osgi architecture. So, I am trying to get stuff working with the kernel as an osgi service, get the deployers working, etc etc. I think after we have done this we will have a much better idea what other work we want to try. For instance, we might not need a kernel at all: possibly gbeans can just be osgi services with a few extra attributes. thanks david jencks Thanks ! 2009/9/22 Rex Wang rwo...@gmail.com Yes! hope for detail sharing :-) -Rex 2009/9/22 Jack Cai greensi...@gmail.com David, that's exciting work! It'll be great if you can share some more details. There are a few puzzles that flow around my mind - * Are we just taking OSGi framework in as another plug-in to let it host OSGi applications? Or, vice-versa, we are converting Geronimo into an OSGi application? * If the latter case, will GBean go away? * If yes, how much code changes are required? I'd say a lot ... -Jack On Tue, Sep 22, 2009 at 8:25 AM, David Jencks david_jen...@yahoo.com wrote: Over the weekend I got my sandbox osgi framework to build and generate all the plugins as osgi bundles. This involves running some of the geronimo server on osgi/felix inside maven. The dependency management system seems to work OK at least for starting bundles. I also started doing a little bit of code cleanup. I think the next step will be to get the framework server running in standalone karaf or felix. Hopefully this will be no harder than getting it running in embedded felix in maven. thanks david jencks -- Ivan
Re: OSGI progress
On Wed, Sep 23, 2009 at 08:25, David Jencks david_jen...@yahoo.com wrote: On Sep 22, 2009, at 10:50 PM, Ivan wrote: After reading some code changes of the geronimo-kenel in the sanbox, I found that we keep the Geronimo kenel as an OSGI service, and each Configuration ( or a bundle) will search it and start the configuration as we do in the past while starting. There's a difference in lifecycles between osgi bundles and geronimo configurations. OSGI: bundles can be installed, in which case the classes are not available, or started, in which case the classes are all available and the bundle activator has been started. AFAICT there is no other built in no-really-start-it state beyond started. There might be more less-started states I'm not aware of. OSGi has the following states for bundles: * Installed * Resolved * Started Resolved means the classes are available and Started means the activator has been started. Of course, we have Started Resolved. But Resolved might be what you were looking for. Geronimo: A Configuration is a gbean. You can't get much usefaul data out of it until its started. Once it is started the classes are available and you can find out what services (gbeans) are in the configuration and look at their attributes. There's a further state of all gbeans started. The configuration manager treats these states as loaded and started So far it seems to work to do something similar in the osgi environment but it doesn't really fit very well yet. I'm not sure where we will end up with this. I have a feeling that, if we do that, Geronimo is still a part of OSGI env, could we make the Geronimo is an OSGI env? I don't understand what you are asking here. In the sandbox, geronimo plugins are running in an osgi enviroment, and all the classes are loaded from osgi bundles. Could you explain more what you are asking about? Could we publish GBeans as OSGI service via a ConfigurationActivator, or though a GBean-OSGI adapter ? I'm pretty sure we could, but I'd like to get more stuff working before we decide if its a good idea. IIUC blueprint doesn't publish every blueprint bean as an osgi service, but only ones you configure to be published. I suspect we may want to, similarly, only publish some gbeans as osgi services. My current approach is to try to modify the existing geronimo architecture relatively little where possible to get it to run in osgi, respecting osgi architecture. So, I am trying to get stuff working with the kernel as an osgi service, get the deployers working, etc etc. I think after we have done this we will have a much better idea what other work we want to try. For instance, we might not need a kernel at all: possibly gbeans can just be osgi services with a few extra attributes. thanks david jencks Thanks ! 2009/9/22 Rex Wang rwo...@gmail.com Yes! hope for detail sharing :-) -Rex 2009/9/22 Jack Cai greensi...@gmail.com David, that's exciting work! It'll be great if you can share some more details. There are a few puzzles that flow around my mind - * Are we just taking OSGi framework in as another plug-in to let it host OSGi applications? Or, vice-versa, we are converting Geronimo into an OSGi application? * If the latter case, will GBean go away? * If yes, how much code changes are required? I'd say a lot ... -Jack On Tue, Sep 22, 2009 at 8:25 AM, David Jencks david_jen...@yahoo.com wrote: Over the weekend I got my sandbox osgi framework to build and generate all the plugins as osgi bundles. This involves running some of the geronimo server on osgi/felix inside maven. The dependency management system seems to work OK at least for starting bundles. I also started doing a little bit of code cleanup. I think the next step will be to get the framework server running in standalone karaf or felix. Hopefully this will be no harder than getting it running in embedded felix in maven. thanks david jencks -- Ivan -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: OSGI progress
2009/9/23 David Jencks david_jen...@yahoo.com On Sep 22, 2009, at 10:50 PM, Ivan wrote: After reading some code changes of the geronimo-kenel in the sanbox, I found that we keep the Geronimo kenel as an OSGI service, and each Configuration ( or a bundle) will search it and start the configuration as we do in the past while starting. There's a difference in lifecycles between osgi bundles and geronimo configurations. OSGI: bundles can be installed, in which case the classes are not available, or started, in which case the classes are all available and the bundle activator has been started. AFAICT there is no other built in no-really-start-it state beyond started. There might be more less-started states I'm not aware of. Geronimo: A Configuration is a gbean. You can't get much usefaul data out of it until its started. Once it is started the classes are available and you can find out what services (gbeans) are in the configuration and look at their attributes. There's a further state of all gbeans started. The configuration manager treats these states as loaded and started So far it seems to work to do something similar in the osgi environment but it doesn't really fit very well yet. I'm not sure where we will end up with this. I have not considered the detailed implmentation, by intuition, the Configuration in the old Geronimo Arch is a bundle in OSGI, while starting the bundle, the bundleActivator will start all the gbean defintions it has. I know that Configuration is only a gbean, even if it is in running state, it does not mean that all the sub gbeans are in the running state, maybe, as Guillanume said, we could think that the resolved state means that the Configuration GBean itself has been successfully in the running state. I have a feeling that, if we do that, Geronimo is still a part of OSGI env, could we make the Geronimo is an OSGI env? I don't understand what you are asking here. In the sandbox, geronimo plugins are running in an osgi enviroment, and all the classes are loaded from osgi bundles. Could you explain more what you are asking about? What I mean is that, currently, Geronimo kernel is running in the OSGI environment, and all those GBeans are running in the kernel. I would like to see that the OSGI is Geronimo kernel. As you said in the comments below, we might not need a kernel at all :-) Could we publish GBeans as OSGI service via a ConfigurationActivator, or though a GBean-OSGI adapter ? I'm pretty sure we could, but I'd like to get more stuff working before we decide if its a good idea. IIUC blueprint doesn't publish every blueprint bean as an osgi service, but only ones you configure to be published. I suspect we may want to, similarly, only publish some gbeans as osgi services. My current approach is to try to modify the existing geronimo architecture relatively little where possible to get it to run in osgi, respecting osgi architecture. So, I am trying to get stuff working with the kernel as an osgi service, get the deployers working, etc etc. I think after we have done this we will have a much better idea what other work we want to try. For instance, we might not need a kernel at all: possibly gbeans can just be osgi services with a few extra attributes. thanks david jencks Thanks ! 2009/9/22 Rex Wang rwo...@gmail.com Yes! hope for detail sharing :-) -Rex 2009/9/22 Jack Cai greensi...@gmail.com David, that's exciting work! It'll be great if you can share some more details. There are a few puzzles that flow around my mind - * Are we just taking OSGi framework in as another plug-in to let it host OSGi applications? Or, vice-versa, we are converting Geronimo into an OSGi application? * If the latter case, will GBean go away? * If yes, how much code changes are required? I'd say a lot ... -Jack On Tue, Sep 22, 2009 at 8:25 AM, David Jencks david_jen...@yahoo.comwrote: Over the weekend I got my sandbox osgi framework to build and generate all the plugins as osgi bundles. This involves running some of the geronimo server on osgi/felix inside maven. The dependency management system seems to work OK at least for starting bundles. I also started doing a little bit of code cleanup. I think the next step will be to get the framework server running in standalone karaf or felix. Hopefully this will be no harder than getting it running in embedded felix in maven. thanks david jencks -- Ivan -- Ivan
Re: OSGI progress
2009/9/23 Ivan xhh...@gmail.com 2009/9/23 David Jencks david_jen...@yahoo.com On Sep 22, 2009, at 10:50 PM, Ivan wrote: After reading some code changes of the geronimo-kenel in the sanbox, I found that we keep the Geronimo kenel as an OSGI service, and each Configuration ( or a bundle) will search it and start the configuration as we do in the past while starting. There's a difference in lifecycles between osgi bundles and geronimo configurations. OSGI: bundles can be installed, in which case the classes are not available, or started, in which case the classes are all available and the bundle activator has been started. AFAICT there is no other built in no-really-start-it state beyond started. There might be more less-started states I'm not aware of. Geronimo: A Configuration is a gbean. You can't get much usefaul data out of it until its started. Once it is started the classes are available and you can find out what services (gbeans) are in the configuration and look at their attributes. There's a further state of all gbeans started. The configuration manager treats these states as loaded and started So far it seems to work to do something similar in the osgi environment but it doesn't really fit very well yet. I'm not sure where we will end up with this. I have not considered the detailed implmentation, by intuition, the Configuration in the old Geronimo Arch is a bundle in OSGI, while starting the bundle, the bundleActivator will start all the gbean defintions it has. I know that Configuration is only a gbean, even if it is in running state, it does not mean that all the sub gbeans are in the running state, maybe, as Guillanume said, we could think that the resolved state means that the Configuration GBean itself has been successfully in the running state. The Installed/Resolved/Started is the states of a bundle, not a specific java bean. You can not re-define what resolved mean in your design. I have a feeling that, if we do that, Geronimo is still a part of OSGI env, could we make the Geronimo is an OSGI env? I don't understand what you are asking here. In the sandbox, geronimo plugins are running in an osgi enviroment, and all the classes are loaded from osgi bundles. Could you explain more what you are asking about? What I mean is that, currently, Geronimo kernel is running in the OSGI environment, and all those GBeans are running in the kernel. I would like to see that the OSGI is Geronimo kernel. As you said in the comments below, we might not need a kernel at all :-) Yes. I hope so. -Rex Could we publish GBeans as OSGI service via a ConfigurationActivator, or though a GBean-OSGI adapter ? I'm pretty sure we could, but I'd like to get more stuff working before we decide if its a good idea. IIUC blueprint doesn't publish every blueprint bean as an osgi service, but only ones you configure to be published. I suspect we may want to, similarly, only publish some gbeans as osgi services. My current approach is to try to modify the existing geronimo architecture relatively little where possible to get it to run in osgi, respecting osgi architecture. So, I am trying to get stuff working with the kernel as an osgi service, get the deployers working, etc etc. I think after we have done this we will have a much better idea what other work we want to try. For instance, we might not need a kernel at all: possibly gbeans can just be osgi services with a few extra attributes. thanks david jencks Thanks ! 2009/9/22 Rex Wang rwo...@gmail.com Yes! hope for detail sharing :-) -Rex 2009/9/22 Jack Cai greensi...@gmail.com David, that's exciting work! It'll be great if you can share some more details. There are a few puzzles that flow around my mind - * Are we just taking OSGi framework in as another plug-in to let it host OSGi applications? Or, vice-versa, we are converting Geronimo into an OSGi application? * If the latter case, will GBean go away? * If yes, how much code changes are required? I'd say a lot ... -Jack On Tue, Sep 22, 2009 at 8:25 AM, David Jencks david_jen...@yahoo.comwrote: Over the weekend I got my sandbox osgi framework to build and generate all the plugins as osgi bundles. This involves running some of the geronimo server on osgi/felix inside maven. The dependency management system seems to work OK at least for starting bundles. I also started doing a little bit of code cleanup. I think the next step will be to get the framework server running in standalone karaf or felix. Hopefully this will be no harder than getting it running in embedded felix in maven. thanks david jencks -- Ivan -- Ivan
Re: OSGI progress
What I mean is that, currently, Geronimo kernel is running in the OSGI environment, and all those GBeans are running in the kernel. I would like to see that the OSGI is Geronimo kernel. As you said in the comments below, we might not need a kernel at all :-) Yes. I hope so. I'm trying to follow what you guys are saying, because it sounds very interesting. I might be misunderstanding what the Geronimo Kernel is exactly. If I understand this correctly, ie. the kernel provides services, won't it make it difficult to then replace the kernel? If the kernel is a bundle, it can be uninstalled/reinstalled, and provide it's services? Similar to other OSGi environments, ex. Eclipse IDE. The OSGi environment loads the IDE core as a bundle. Eclipse IDE core isn't the OSGi. The actual OSGi in OSGi implementations is merely the engine for managing/loading/activating bundles and services, and if you keep to the spec should be nothing more than this? Q
Re: OSGI progress
2009/9/23 Rex Wang rwo...@gmail.com 2009/9/23 Ivan xhh...@gmail.com 2009/9/23 David Jencks david_jen...@yahoo.com On Sep 22, 2009, at 10:50 PM, Ivan wrote: After reading some code changes of the geronimo-kenel in the sanbox, I found that we keep the Geronimo kenel as an OSGI service, and each Configuration ( or a bundle) will search it and start the configuration as we do in the past while starting. There's a difference in lifecycles between osgi bundles and geronimo configurations. OSGI: bundles can be installed, in which case the classes are not available, or started, in which case the classes are all available and the bundle activator has been started. AFAICT there is no other built in no-really-start-it state beyond started. There might be more less-started states I'm not aware of. Geronimo: A Configuration is a gbean. You can't get much usefaul data out of it until its started. Once it is started the classes are available and you can find out what services (gbeans) are in the configuration and look at their attributes. There's a further state of all gbeans started. The configuration manager treats these states as loaded and started So far it seems to work to do something similar in the osgi environment but it doesn't really fit very well yet. I'm not sure where we will end up with this. I have not considered the detailed implmentation, by intuition, the Configuration in the old Geronimo Arch is a bundle in OSGI, while starting the bundle, the bundleActivator will start all the gbean defintions it has. I know that Configuration is only a gbean, even if it is in running state, it does not mean that all the sub gbeans are in the running state, maybe, as Guillanume said, we could think that the resolved state means that the Configuration GBean itself has been successfully in the running state. The Installed/Resolved/Started is the states of a bundle, not a specific java bean. You can not re-define what resolved mean in your design. I do not mean to redefine the resolved status, as David said, Geronimo and OSGI's lifecycle have a slight difference, we may need to do some mapping between them Just releaize that the resolve is an internal process of the OSGI framework, no way to do a Configuration GBean start :-( I have a feeling that, if we do that, Geronimo is still a part of OSGI env, could we make the Geronimo is an OSGI env? I don't understand what you are asking here. In the sandbox, geronimo plugins are running in an osgi enviroment, and all the classes are loaded from osgi bundles. Could you explain more what you are asking about? What I mean is that, currently, Geronimo kernel is running in the OSGI environment, and all those GBeans are running in the kernel. I would like to see that the OSGI is Geronimo kernel. As you said in the comments below, we might not need a kernel at all :-) Yes. I hope so. -Rex Could we publish GBeans as OSGI service via a ConfigurationActivator, or though a GBean-OSGI adapter ? I'm pretty sure we could, but I'd like to get more stuff working before we decide if its a good idea. IIUC blueprint doesn't publish every blueprint bean as an osgi service, but only ones you configure to be published. I suspect we may want to, similarly, only publish some gbeans as osgi services. My current approach is to try to modify the existing geronimo architecture relatively little where possible to get it to run in osgi, respecting osgi architecture. So, I am trying to get stuff working with the kernel as an osgi service, get the deployers working, etc etc. I think after we have done this we will have a much better idea what other work we want to try. For instance, we might not need a kernel at all: possibly gbeans can just be osgi services with a few extra attributes. thanks david jencks Thanks ! 2009/9/22 Rex Wang rwo...@gmail.com Yes! hope for detail sharing :-) -Rex 2009/9/22 Jack Cai greensi...@gmail.com David, that's exciting work! It'll be great if you can share some more details. There are a few puzzles that flow around my mind - * Are we just taking OSGi framework in as another plug-in to let it host OSGi applications? Or, vice-versa, we are converting Geronimo into an OSGi application? * If the latter case, will GBean go away? * If yes, how much code changes are required? I'd say a lot ... -Jack On Tue, Sep 22, 2009 at 8:25 AM, David Jencks david_jen...@yahoo.comwrote: Over the weekend I got my sandbox osgi framework to build and generate all the plugins as osgi bundles. This involves running some of the geronimo server on osgi/felix inside maven. The dependency management system seems to work OK at least for starting bundles. I also started doing a little bit of code cleanup. I think the next step will be to get the framework server running in standalone karaf or felix. Hopefully this will be no harder
Re: OSGI progress
2009/9/23 Quintin Beukes quin...@skywalk.co.za What I mean is that, currently, Geronimo kernel is running in the OSGI environment, and all those GBeans are running in the kernel. I would like to see that the OSGI is Geronimo kernel. As you said in the comments below, we might not need a kernel at all :-) Yes. I hope so. I'm trying to follow what you guys are saying, because it sounds very interesting. I might be misunderstanding what the Geronimo Kernel is exactly. If I understand this correctly, ie. the kernel provides services, won't it make it difficult to then replace the kernel? If the kernel is a bundle, it can be uninstalled/reinstalled, and provide it's services? Similar to other OSGi environments, ex. Eclipse IDE. The OSGi environment loads the IDE core as a bundle. Eclipse IDE core isn't the OSGi. The actual OSGi in OSGi implementations is merely the engine for managing/loading/activating bundles and services, and if you keep to the spec should be nothing more than this? AFAIK, Eclipse only using OSGi framework to do the classloading, however that is only one of the feature OSGi can provide. (Maybe there are some improves in the new eclipse release.) From my point of view, ideally, Future Geronimo will be a bunch of extenders of OSGi framework(such as web container extender, blueprint extender..). Deploying a war is actually to deploy a web bundle into OSGi framework. If we have enough extenders on our hand, which implement the whole Java EE features, then we can claim that geronimo comply the Java EE spec. However, currently, OSGi EEG is still busy on making RFCs and RIs, so there is not enough parts to assemble a Java EE server for us. Then that might be the stuffs we are working on, that is, we are try to build an appliation(geronimo kernel) based on OSGi framework which can provide a pipeline to the external world, such as openejb *Above is just my personal view* -Rex Q
Re: OSGI progress
David Jencks wrote: On Sep 22, 2009, at 10:50 PM, Ivan wrote: After reading some code changes of the geronimo-kenel in the sanbox, I found that we keep the Geronimo kenel as an OSGI service, and each Configuration ( or a bundle) will search it and start the configuration as we do in the past while starting. There's a difference in lifecycles between osgi bundles and geronimo configurations. OSGI: bundles can be installed, in which case the classes are not available, or started, in which case the classes are all available and the bundle activator has been started. AFAICT there is no other built in no-really-start-it state beyond started. There might be more less-started states I'm not aware of. The extender model sort or introduces an additional state (or at least the Blueprint extender does). After STARTED state, the extender kicks in and processes metadata in the bundle and performs additional actions. The completion point is when the BlueprintContainer service is published to the service registry. At that point, the bundle state is complete. Something similar might make sense for a configuration, where a ConfigurationContainer service is published to the registry that would allow additional configuration operations to be performed. Geronimo: A Configuration is a gbean. You can't get much usefaul data out of it until its started. Once it is started the classes are available and you can find out what services (gbeans) are in the configuration and look at their attributes. There's a further state of all gbeans started. The configuration manager treats these states as loaded and started Again, this maps fairly well to the model used by Blueprint extender. The Configuration gbean could be published to the registry once it reaches the all gbeans started state. So far it seems to work to do something similar in the osgi environment but it doesn't really fit very well yet. I'm not sure where we will end up with this. I have a feeling that, if we do that, Geronimo is still a part of OSGI env, could we make the Geronimo is an OSGI env? I don't understand what you are asking here. In the sandbox, geronimo plugins are running in an osgi enviroment, and all the classes are loaded from osgi bundles. Could you explain more what you are asking about? Could we publish GBeans as OSGI service via a ConfigurationActivator, or though a GBean-OSGI adapter ? I'm pretty sure we could, but I'd like to get more stuff working before we decide if its a good idea. IIUC blueprint doesn't publish every blueprint bean as an osgi service, but only ones you configure to be published. I suspect we may want to, similarly, only publish some gbeans as osgi services. Your understanding is correct. Only the explicitly identified beans are published as services. I suspect this would likely make sense within a configuration context as well. My current approach is to try to modify the existing geronimo architecture relatively little where possible to get it to run in osgi, respecting osgi architecture. So, I am trying to get stuff working with the kernel as an osgi service, get the deployers working, etc etc. I think after we have done this we will have a much better idea what other work we want to try. For instance, we might not need a kernel at all: possibly gbeans can just be osgi services with a few extra attributes. thanks david jencks Thanks ! 2009/9/22 Rex Wang rwo...@gmail.com mailto:rwo...@gmail.com Yes! hope for detail sharing :-) -Rex 2009/9/22 Jack Cai greensi...@gmail.com mailto:greensi...@gmail.com David, that's exciting work! It'll be great if you can share some more details. There are a few puzzles that flow around my mind - * Are we just taking OSGi framework in as another plug-in to let it host OSGi applications? Or, vice-versa, we are converting Geronimo into an OSGi application? * If the latter case, will GBean go away? * If yes, how much code changes are required? I'd say a lot ... -Jack On Tue, Sep 22, 2009 at 8:25 AM, David Jencks david_jen...@yahoo.com mailto:david_jen...@yahoo.com wrote: Over the weekend I got my sandbox osgi framework to build and generate all the plugins as osgi bundles. This involves running some of the geronimo server on osgi/felix inside maven. The dependency management system seems to work OK at least for starting bundles. I also started doing a little bit of code cleanup. I think the next step will be to get the framework server running in standalone karaf or felix. Hopefully this will be no harder than getting it running in embedded felix in maven. thanks david jencks -- Ivan
Re: OSGI progress
On Sep 23, 2009, at 3:35 AM, Rick McGuire wrote: David Jencks wrote: On Sep 22, 2009, at 10:50 PM, Ivan wrote: After reading some code changes of the geronimo-kenel in the sanbox, I found that we keep the Geronimo kenel as an OSGI service, and each Configuration ( or a bundle) will search it and start the configuration as we do in the past while starting. There's a difference in lifecycles between osgi bundles and geronimo configurations. OSGI: bundles can be installed, in which case the classes are not available, or started, in which case the classes are all available and the bundle activator has been started. AFAICT there is no other built in no-really-start-it state beyond started. There might be more less-started states I'm not aware of. The extender model sort or introduces an additional state (or at least the Blueprint extender does). After STARTED state, the extender kicks in and processes metadata in the bundle and performs additional actions. The completion point is when the BlueprintContainer service is published to the service registry. At that point, the bundle state is complete. Something similar might make sense for a configuration, where a ConfigurationContainer service is published to the registry that would allow additional configuration operations to be performed. I think people have outlined two options here. I don't know if either of them would actually work well in practice: 1. map the resolved bundle state to classes available + gbean metadata available, and the started bundle state to all the gbeans started. I _think_ a bundle listener is notified when a bundle is resolved, we could write a bundle listener to look up and register the gbean metadata in the kernel. This is now done in the ConfigurationActivator. The ConfigurationActivator start would then start all the gbeans. Alternatively we could use a bundle listener to start all the gbeans. 2. map the started bundle state to classes available and gbean metadata available, but gbeans not started and have a further state of gbeans started under the control of something else, perhaps similar to the blueprint extender. This is closer to what I've implemented so far. The real reason we have these two configuration staties is that we generally need access to the gbean metadata in order to deploy javaee applications to make sure the gbean references will be satisfied at runtime (there's also some further use for j2ca connector metadata, but we miight be able to find an alternate way to deal with this). We don't want to force you to start up a whole server with opening all the server ports just to build a plugin for a web app. So far I think this is a useful capability so I'd like to try to find a way to implement it in osgi. Alternatively we could abandon the idea of building plugins for javaee apps that are predeployed apps that should just work and go to more of a find the problems at runtime model. We won't be able to tell how well this stuff works until we get to making the deployers work in osgi. The stuff in framework doesn't really have enough contact with the outside world through server ports to show up problems with any of these approaches. thanks david jencks Geronimo: A Configuration is a gbean. You can't get much usefaul data out of it until its started. Once it is started the classes are available and you can find out what services (gbeans) are in the configuration and look at their attributes. There's a further state of all gbeans started. The configuration manager treats these states as loaded and started Again, this maps fairly well to the model used by Blueprint extender. The Configuration gbean could be published to the registry once it reaches the all gbeans started state. So far it seems to work to do something similar in the osgi environment but it doesn't really fit very well yet. I'm not sure where we will end up with this. I have a feeling that, if we do that, Geronimo is still a part of OSGI env, could we make the Geronimo is an OSGI env? I don't understand what you are asking here. In the sandbox, geronimo plugins are running in an osgi enviroment, and all the classes are loaded from osgi bundles. Could you explain more what you are asking about? Could we publish GBeans as OSGI service via a ConfigurationActivator, or though a GBean-OSGI adapter ? I'm pretty sure we could, but I'd like to get more stuff working before we decide if its a good idea. IIUC blueprint doesn't publish every blueprint bean as an osgi service, but only ones you configure to be published. I suspect we may want to, similarly, only publish some gbeans as osgi services. Your understanding is correct. Only the explicitly identified beans are published as services. I suspect this would likely make sense within a configuration context as well. My
Re: OSGI progress
So it sounds like I can't put off learning OSGi anymore :) Does anyone have suggested resources (books, websites, or tutorials) that they found useful? Thanks in advance, Jay David Jencks wrote: Over the weekend I got my sandbox osgi framework to build and generate all the plugins as osgi bundles. This involves running some of the geronimo server on osgi/felix inside maven. The dependency management system seems to work OK at least for starting bundles. I also started doing a little bit of code cleanup. I think the next step will be to get the framework server running in standalone karaf or felix. Hopefully this will be no harder than getting it running in embedded felix in maven. thanks david jencks
Re: OSGI progress
David, that's exciting work! It'll be great if you can share some more details. There are a few puzzles that flow around my mind - * Are we just taking OSGi framework in as another plug-in to let it host OSGi applications? Or, vice-versa, we are converting Geronimo into an OSGi application? * If the latter case, will GBean go away? * If yes, how much code changes are required? I'd say a lot ... -Jack On Tue, Sep 22, 2009 at 8:25 AM, David Jencks david_jen...@yahoo.comwrote: Over the weekend I got my sandbox osgi framework to build and generate all the plugins as osgi bundles. This involves running some of the geronimo server on osgi/felix inside maven. The dependency management system seems to work OK at least for starting bundles. I also started doing a little bit of code cleanup. I think the next step will be to get the framework server running in standalone karaf or felix. Hopefully this will be no harder than getting it running in embedded felix in maven. thanks david jencks
Re: OSGI progress
Yes! hope for detail sharing :-) -Rex 2009/9/22 Jack Cai greensi...@gmail.com David, that's exciting work! It'll be great if you can share some more details. There are a few puzzles that flow around my mind - * Are we just taking OSGi framework in as another plug-in to let it host OSGi applications? Or, vice-versa, we are converting Geronimo into an OSGi application? * If the latter case, will GBean go away? * If yes, how much code changes are required? I'd say a lot ... -Jack On Tue, Sep 22, 2009 at 8:25 AM, David Jencks david_jen...@yahoo.comwrote: Over the weekend I got my sandbox osgi framework to build and generate all the plugins as osgi bundles. This involves running some of the geronimo server on osgi/felix inside maven. The dependency management system seems to work OK at least for starting bundles. I also started doing a little bit of code cleanup. I think the next step will be to get the framework server running in standalone karaf or felix. Hopefully this will be no harder than getting it running in embedded felix in maven. thanks david jencks
Re: OSGI progress
After reading some code changes of the geronimo-kenel in the sanbox, I found that we keep the Geronimo kenel as an OSGI service, and each Configuration ( or a bundle) will search it and start the configuration as we do in the past while starting. I have a feeling that, if we do that, Geronimo is still a part of OSGI env, could we make the Geronimo is an OSGI env? Could we publish GBeans as OSGI service via a ConfigurationActivator, or though a GBean-OSGI adapter ? Thanks ! 2009/9/22 Rex Wang rwo...@gmail.com Yes! hope for detail sharing :-) -Rex 2009/9/22 Jack Cai greensi...@gmail.com David, that's exciting work! It'll be great if you can share some more details. There are a few puzzles that flow around my mind - * Are we just taking OSGi framework in as another plug-in to let it host OSGi applications? Or, vice-versa, we are converting Geronimo into an OSGi application? * If the latter case, will GBean go away? * If yes, how much code changes are required? I'd say a lot ... -Jack On Tue, Sep 22, 2009 at 8:25 AM, David Jencks david_jen...@yahoo.comwrote: Over the weekend I got my sandbox osgi framework to build and generate all the plugins as osgi bundles. This involves running some of the geronimo server on osgi/felix inside maven. The dependency management system seems to work OK at least for starting bundles. I also started doing a little bit of code cleanup. I think the next step will be to get the framework server running in standalone karaf or felix. Hopefully this will be no harder than getting it running in embedded felix in maven. thanks david jencks -- Ivan
OSGI progress
Over the weekend I got my sandbox osgi framework to build and generate all the plugins as osgi bundles. This involves running some of the geronimo server on osgi/felix inside maven. The dependency management system seems to work OK at least for starting bundles. I also started doing a little bit of code cleanup. I think the next step will be to get the framework server running in standalone karaf or felix. Hopefully this will be no harder than getting it running in embedded felix in maven. thanks david jencks
osgi progress
I've made some headway in my sandbox osgi framework. I now have pretty much all the modules building as bundles and have the car-maven- plugin working enough to build several plugins. I'm a bit stuck on a classloading problem in which a bundle appears to be able to load a class but not an interface it implements, in the same bundle (both classes are imported and exported). The car-maven-plugin works by starting a felix framework inside maven and deploying bits of geronimo into it. In order to share classes between maven and felix the framework has to export quite a few classes that in a real server would be loaded from geronimo bundles. I think the next step may be to work on getting the bundles that do compile to run inside karaf or possibly felix. Apparently there are some tools to help diagnose classloading problems. With luck I may have some kind of geronimo framework server running in karak sometime next week. Assuming that we agree to move this code into trunk, at this point I think there will be a lot of work that can be done more in parallel on the plugins part of geronimo. Basically we have to go through all the geronimo code and -- turn the jars into bundles and make sure they build -- determine the not-yet-bundle dependencies and either convince the source project to bundleize them or repackage them as bundles -- set up the bundle plugin more precisely with package versions and correct imports -- modify the gbeans to use Bundle or BundleContext instead of classloader -- get the plugins to compile -- remove unnecessary plugins such as classloader plugins At this point we'll be able to see just how hard it is to deploy an ee app as one or more bundles. The framework stuff will also need more work including -- removing unnecessary code such as a lot of the old classloaders -- clarifying the separation between dependency management and bundle lifecycle. -- deciding whether to use a BundleActivator approach to start geronimo plugins or whether to use a blueprint service-like extender bundle listener. Currently I'm using a BundleActivator approach which makes it difficult to communicate from one started bundle to another. -- deciding whether to keep the kernel as a gbean registry or just register all gbeans in the service registry as services. thanks david jencks
Re: osgi progress
David Jencks wrote: I've made some headway in my sandbox osgi framework. I now have pretty much all the modules building as bundles and have the car-maven-plugin working enough to build several plugins. I'm a bit stuck on a classloading problem in which a bundle appears to be able to load a class but not an interface it implements, in the same bundle (both classes are imported and exported). David, just a thought here. Is it possible that the classloading issue is not with the interface class, but rather a superclass that the interface class depends on? It could be a problem with a missing import for that class. Rick The car-maven-plugin works by starting a felix framework inside maven and deploying bits of geronimo into it. In order to share classes between maven and felix the framework has to export quite a few classes that in a real server would be loaded from geronimo bundles. I think the next step may be to work on getting the bundles that do compile to run inside karaf or possibly felix. Apparently there are some tools to help diagnose classloading problems. With luck I may have some kind of geronimo framework server running in karak sometime next week. Assuming that we agree to move this code into trunk, at this point I think there will be a lot of work that can be done more in parallel on the plugins part of geronimo. Basically we have to go through all the geronimo code and -- turn the jars into bundles and make sure they build -- determine the not-yet-bundle dependencies and either convince the source project to bundleize them or repackage them as bundles -- set up the bundle plugin more precisely with package versions and correct imports -- modify the gbeans to use Bundle or BundleContext instead of classloader -- get the plugins to compile -- remove unnecessary plugins such as classloader plugins At this point we'll be able to see just how hard it is to deploy an ee app as one or more bundles. The framework stuff will also need more work including -- removing unnecessary code such as a lot of the old classloaders -- clarifying the separation between dependency management and bundle lifecycle. -- deciding whether to use a BundleActivator approach to start geronimo plugins or whether to use a blueprint service-like extender bundle listener. Currently I'm using a BundleActivator approach which makes it difficult to communicate from one started bundle to another. -- deciding whether to keep the kernel as a gbean registry or just register all gbeans in the service registry as services. thanks david jencks
