|
Sort Order:
The problem is related to the missing imports for at least this packages (the list is based on S2AP artifact): javax.management I think that there is also a bunch of optional packages that are not imported. Analyzing the MANIFEST.MF, it seems to me that is created and tested within eclipse and that's the reason why it is working within equinox even without imports for javax, org.w3c, org.xml packages. And it works because by default equinox doe not work in standard mode, meaning that will delegate to system class loader for any package, when by standard they should delegate only for java.* packages. So, a quick fix is to add the above packages to the list of exported packages. If you guys want to test a standard equinox or any other osgi frameworks as Felix or Knopflerfish and you are using Eclipse you may wanna try Pax Cursor: http://wiki.ops4j.org/confluence/x/0QBN
Jochen Theodorou made changes - 02/Jun/08 07:47 AM
Jochen, is this already in snapshot so I can test it? BTW, groovy needs to export packages with proper version numbers too. i.e. Export-Package: ...., groovy.lang;version="1.5.7" for 1.6: Export-Package: ...., groovy.lang;version="1.6.0.beta-2" This is done for all exported packages, and taking into consideration the major.minor.micro.qualifier OSGi spec. (only qualifier can have alphanumeric characters) I would have closed the issue then...btw, why is the OSGi spec that unflexible that you have to use a certain version naming convention? The debain packaging system for example is much more flexible here The version naming is used by versions in the manifest, not applicable for the JAR name itself or Maven artifact, for example. So the version naming syntax is only imposed on things that are OSGi-related, not the ones that are outside OSGi spec. I'm unaware of the "why"s, you should ask the OSGi community if you're interested in authoritative answer. But my assumption is, (1) it was designed to make it easy and correct to calculate version ranges (i.e. "[1.5.0,2.0)"), (2) to make it as flexible as possible while keeping OSGi runtime for embedded devices doable (i.e. having acceptable performance). Besides, the version naming used in the (OSGi) manifest does not limit in any way to the actual version name used (i.e. JAR name, Maven artifact etc.). i.e you can still use versions like 2.4.0.RC5, but this kind of version is not distinguishable from 2.4.0.RELEASE, apart from specifying a strict version dependency. There are too numerous ways to define version ranges for alphanumeric versions (i.e. alpha, beta, gamma, release candidate, etc.) and for understandable reason. Peter Kriens also talks about OSGi version numbering (vs. JSR 277) here: http://www.osgi.org/blog/2006/10/jsr-277-review.html ___ quoted ___ Well, the paper document I have reviewed is heavily covered with my marker and I could continue for more pages. However, it is too much for this blog. Well, ok, last complaint: the syntax for version ranges, it is too tempting to leave it alone (though it is not that important). The industry more or less has standardized on versions with a major, micro, minor number and a string qualifier. JSR 277 adds an update number that is between minor and qualifier (Maybe one day someone can explain to me why we need all those number while the only thing that is signaled is a change that is backward compatible or not, but developers seem to like to have all those numbers). However, I have no problem adding another number beneath minor. I do have a problem with a version range syntax that is obtuse and non-standard. Intervals have a mathematical notation that is easy to understand. Parentheses are non-inclusive and brackets are inclusive. The interval 1 < x <= 5 is therefore represented as (1,5]. [2.3,5.1) indicates any version that is more or equal to 2.0 and less than 5.1. Simple, elegant, has been around since Pythagoras. Choosing this notation for the OSGi specifications was a no-brainer. Now, let us take a look at what JSR 277 brewed. They use the same terminals as regular expressions, but they have a very different meaning. A partial version can be suffixed with a + (anything later) or a * (anything with the same prefix). So if you say 1+ you mean [1,∞) or 1. 1* is [1,2). The JSR uses square brackets to fix the first positions while floating the last. For example, 1.[2.3+] is [1.2.3, ∞) and 1.[2.3*] is [1.2.3,1.2.4). The JSR 277 syntax has no easy formulation for the not uncommon case [1,5). The only way to express this is with concatenation of version ranges: 1*;2*;3*;4*. Ok, enough about this strange syntax. having two different version schemes for the jar and for OSGi can be error prone. So it is not a good way. Also the newest article: http://www.osgi.org/blog/2008/05/is-9903520300447984150353281023-too.html I really wouldn't let this to be a debate on versioning schemes. Let's go back to Groovy and its OSGi manifest. Currently Groovy's OSGi manifest does not export any package version number, and that is error prone when compared to if the packages' version numbers are specified. This mainly interests OSGi developers, so regular Java developers are not affected in any way. I've some changes to make Groovy work under OSGi. I'll propose a patch soon. Hopefully can be accepted by the Groovy developers. osgi> b 3 Patch for build.xml to make it work with OSGi out of the box.
Hendy Irawan made changes - 02/Jun/08 10:43 AM
Patch is attached. BTW, I noticed that in build.xml: <!-- TODO: investigate whether we can generate package list not hard-code it --> This is what Bnd does, and as a plus, you get OSGi-compliant JAR/bundle: Related to:
Paul King made changes - 08/Jun/08 07:31 AM
Can you have a look at the 1.5.7.SNAPSHOT artifact here: http://snapshots.repository.codehaus.org/org/codehaus/groovy/groovy/1.5.7-SNAPSHOT/ It was created using bnd with the following bnd file: version= ${groovyBundleVersion}
-nouses= true
Export-Package= *;version=${version}
Import-Package= antlr, org.objectweb.asm, *;resolution:=optional
I haven't looked at groovy-all, groovy-all-minimal or 1.6 yet. Amazing work Paul! osgi> STARTING test.groovyosgi osgi> ss Framework is launched. id State Bundle Yep, it works as advertised Test project is here: https://scm.ops4j.org/repos/ops4j/laboratory/users/ceefour/test.groovyosgi I hope the fix is also for 1.6.beta Any chance you can recheck the 1.5.7-SNAPSHOT groovy artefact (it may have changed slightly) and also the groovy-all and groovy-all-minimal artefacts here: http://snapshots.repository.codehaus.org/org/codehaus/groovy I'll then port to 1.6. Yes, there is a very easy way. Just check out this project: https://scm.ops4j.org/repos/ops4j/laboratory/users/ceefour/test.groovyosgi and do mvn install pax:provision Editing the pom.xml (and doing mvn -U clean install) will allow you to switch Groovy snapshot versions easily. PS: I'm not sure if OPS4J uses a guest account for SVN read-only access (see http://wiki.ops4j.org/confluence/display/ops4j/Open+Participation+Software+for+Java This is now working for the 1.5.7 and 1.6.0-beta-2 standard snapshots. It also works for the 1.6 groovy-all-jdk14 snapshot artifact but not the groovy-jdk14 artifact. I presume it is due to unresolved dependencies, e.g.: Missing imported package com.thoughtworks.xstream_0.0.0. Missing imported package edu.emory.mathcs.backport.java.util_0.0.0. Missing imported package edu.emory.mathcs.backport.java.util.concurrent_0.0.0. Missing imported package edu.emory.mathcs.backport.java.util.concurrent.atomic_0.0.0. Missing imported package edu.emory.mathcs.backport.java.util.concurrent.locks_0.0.0. Missing imported package groovy.runtime.metaclass_0.0.0. Missing imported package javax.servlet_0.0.0. Missing imported package javax.servlet.http_0.0.0. Missing imported package javax.servlet.jsp_0.0.0. Missing imported package jline_0.0.0. Missing imported package junit.framework_0.0.0. Missing imported package junit.textui_0.0.0. Missing imported package net.sf.retrotranslator.runtime.java.lang_0.0.0. Missing imported package net.sf.retrotranslator.runtime.java.lang.annotation_0.0.0. Missing imported package net.sf.retrotranslator.runtime.java.lang.reflect_0.0.0. Missing imported package net.sf.retrotranslator.runtime.java.net_0.0.0. Missing imported package net.sf.retrotranslator.runtime.java.util_0.0.0. Missing imported package org.apache.bsf_0.0.0. Missing imported package org.apache.bsf.util_0.0.0. Missing imported package org.apache.commons.cli_0.0.0. Missing imported package org.apache.tools.ant_0.0.0. Missing imported package org.apache.tools.ant.helper_0.0.0. Missing imported package org.apache.tools.ant.input_0.0.0. Missing imported package org.apache.tools.ant.taskdefs_0.0.0. Missing imported package org.apache.tools.ant.types_0.0.0. Missing imported package org.apache.tools.ant.util_0.0.0. Most of these are optional dependencies but I am not sure whether net.sf.retrotranslator.runtime and edu.emory.mathcs.backport.java.util.concurrent are required. This is using: <dependency> <groupId>org.codehaus.groovy</groupId> <artifactId>groovy-jdk14</artifactId> <version>1.6-beta-2-SNAPSHOT</version> </dependency> When using groovy-all-jdk14 it seems to start up but also has missing dependencies: Missing imported package com.thoughtworks.xstream_0.0.0. Missing imported package groovy.runtime.metaclass_0.0.0. Missing imported package groovyjarjarasm.asm.tree.analysis_0.0.0. Missing imported package groovyjarjarasm.asm.util_0.0.0. Missing imported package javax.servlet_0.0.0. Missing imported package javax.servlet.http_0.0.0. Missing imported package javax.servlet.jsp_0.0.0. Missing imported package jline_0.0.0. Missing imported package junit.framework_0.0.0. Missing imported package junit.textui_0.0.0. Missing imported package net.sf.retrotranslator.runtime.java.lang.annotation_0.0.0. Missing imported package org.apache.bsf_0.0.0. Missing imported package org.apache.bsf.util_0.0.0. Missing imported package org.apache.commons.cli_0.0.0. Missing imported package org.apache.commons.lang_0.0.0. Missing imported package org.apache.tools.ant_0.0.0. Missing imported package org.apache.tools.ant.helper_0.0.0. Missing imported package org.apache.tools.ant.input_0.0.0. Missing imported package org.apache.tools.ant.taskdefs_0.0.0. Missing imported package org.apache.tools.ant.types_0.0.0. Missing imported package org.apache.tools.ant.util_0.0.0. Missing imported package sun.misc_0.0.0. Thanks a lot Paul. I'd speculate that marking dependencies as optional are fine for typical cases. i.e. if you can run simple Groovy Hello World without that package, then it should be optional. The application developer should care about the optional packages used by Groovy, if he/she decide it's necessary for his use case. So what you are saying is OSGi is not going to know about the pom which indicates that for instance net.sf.retrotranslator.runtime is a required dependency instead I need to ensure that an OSGi compatible artifact exists for that dependency? In other words, probably this issue can be closed. Someone can use the groovy-all-jdk14 artifact if they don't want more work to do but if they don't want that and choose the groovy-jdk14 artifact then the work is on them to provide that themselves. What I meant is if Groovy runs fine without that package, then that package should be marked as optional. I'm not sure from all these packages, which are required and which are optional (to Groovy). OSGi has a way to mark a package for either case. For example: Import-Package: net.sf.retrotranslator.runtime, javax.servlet;resolution:=optional means that javax.servlet is optional and net.sf.retrotranslator.runtime is not optional. A required dependency that is not satisfied will prevent the bundle to get to "RESOLVED" state. That's the runtime issue, now about the POM. mvn pax:provision / Pax-Runner does not automatically install the dependencies of a depended POM (i.e. transitive dependencies). If it were the case, I'd simply depend on Groovy, and Groovy will bring in asm, antlr, etc. Having the project POM depended on Groovy will compile the project with Groovy and all its transitive dependencies. However, at OSGi runtime when launching using mvn-pax-provision/Pax-Runner, only the direct dependencies are installed, not the transitive ones. The rationale for this is understandable, but can be inconvenient and slightly confusing at first. This is why that in the project POM, I manually specify the dependencies to asm, antlr, etc. so they will be launched by pax-provision. To Groovy packager though, this should not be their issue, it's application developer's issue. Traditional Java has no way of specifying which packages should be in the classpath, you'll only get a runtime ClassNotFoundException. OSGi provides a way of bundles specifying which packages it will need (required), or may use (optional). But it does not specify where it will find these required dependencies if the application developer does not install them at runtime. This is one way of saying that it's modular. The Groovy developer can specify the packages it require, but not mandate the exact artifact (or implementation) that the application developer will use. A typical situation is a dependency to commons-logging, which resides in org.apache.commons.logging package. At runtime, we don't need to install commons-logging itself, but can use e.g. pax-logging-api, which satisfies this dependency just fine. Although the dependent library may not know about pax-logging-api. Rereading thoroughly your statement, it seems that your conclusion is correct. A way to supply dependencies directly is to package the dependencies within the bundle (perhaps this is what the groovy-all-jdk14 does??) however in most cases an open external dependency is recommended, as it leaves the "wiring" to the application developer (which they should, or they can use tools like Eclipse PDE that can find matching bundles that satisfy dependencies for them). I added net.sf.retrotranslator.runtime.java.lang as a required Import-Package to the groovy-jdk14 artifact. This forces OSGi application developers to provide that dependency in a bundle if they make use of that version of the Groovy bundle. To test this, I added the following dependencies to the Pax Runner example: <dependency> <groupId>backport-util-concurrent</groupId> <artifactId>backport-util-concurrent</artifactId> <version>3.1-bundle</version> </dependency> <dependency> <groupId>net.sf.retrotranslator</groupId> <artifactId>retrotranslator-runtime</artifactId> <version>1.2.4-bundle</version> </dependency> ... and created the relevant bundles using bnd with the following bnd property files: retrotranslator-runtime.bnd -nouses= true Export-Package= *;version=1.2.4 Import-Package= edu.emory.mathcs.backport.java.util.concurrent.locks, *;resolution:=optional Bundle-Version: 1.2.4 backport-util.concurrent.bnd -nouses= true Export-Package= *;version=3.1 Import-Package= !sun.misc, *;resolution:=optional Bundle-Version: 3.1 This now starts up and runs fine. Doing a diag on the groovy-jdk14 bundle reveals the following unresolved dependencies: Missing imported package com.thoughtworks.xstream_0.0.0. Missing imported package groovy.runtime.metaclass_0.0.0. Missing imported package javax.servlet_0.0.0. Missing imported package javax.servlet.http_0.0.0. Missing imported package javax.servlet.jsp_0.0.0. Missing imported package jline_0.0.0. Missing imported package junit.framework_0.0.0. Missing imported package junit.textui_0.0.0. Missing imported package org.apache.bsf_0.0.0. Missing imported package org.apache.bsf.util_0.0.0. Missing imported package org.apache.commons.cli_0.0.0. Missing imported package org.apache.tools.ant_0.0.0. Missing imported package org.apache.tools.ant.helper_0.0.0. Missing imported package org.apache.tools.ant.input_0.0.0. Missing imported package org.apache.tools.ant.taskdefs_0.0.0. Missing imported package org.apache.tools.ant.types_0.0.0. Missing imported package org.apache.tools.ant.util_0.0.0. All these look bar one look like the optional dependencies. I am not sure why groovy.runtime.metaclass is there. In any case, I think we can close the issue now. If the groovy.runtime.metaclass package turns out to be a problem, we can create a new specific issue for that. Thanks a lot Paul. I suggested this issue, but you actually investigated it to the very end Don't even know that much Bnd syntaxes
Paul King made changes - 12/Jun/08 03:20 PM
Paul King made changes - 12/Oct/08 08:46 AM
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bug
Closed
Major
Incorrect manifests for OSGi usage
Snippet:
__________________
I need help debugging what should be a straightforward OSGi classloading
problem, running Groovy in OSGi.
The stuff is here:
https://scm.ops4j.org/repos/ops4j/laboratory/users/ceefour/test.groov
...
mvn install pax:provision will run the application. mvn pax:eclipse will
also be working to generate Eclipse projects.
The offending line is so simple:
new GroovyShell().evaluate("println 'Hello World from Groovy!';");
Which should just run the groovy script, but it can't.
Please help me diagnose this problem, you may commit directly to that lab if
you wish (it's OPS4J anyway).
I think it will involve a change in Groovy's manifests, please inform. I
want to get this fixed so upcoming Groovy (1.5.7 and 1.6 release) can
flawlessly be used inside OSGi.
Note that I use Groovy snapshot because that's the only version that has
)
proper resolvable OSGi manifests out-of-the-box (see:
http://jira.codehaus.org/browse/GROOVY-2863
A side note is that Groovy 1.5.1 artifact available from SpringSource
Enterprise Bundle Repository can work just fine when used as a replacement
dependency. I'm hoping that someone can "backport" i.e. contribute that
positive change back to Groovy itself, so there'd be no need to wrap it just
to make it work with OSGi.
...