groovy

Incorrect manifests for OSGi usage

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.5.6, 1.6-beta-1
  • Fix Version/s: 1.5.7, 1.6-beta-2
  • Component/s: None
  • Labels:
    None
  • Environment:
    OSGi (Equinox)
  • Number of attachments :
    1

Description

Current manifests (1.6beta2 and 1.5.7 snapshots) can have RESOLVED status in Equinox.

But attempting to evaluate a script is not working.

See: http://groups.google.com/group/spring-osgi/t/19f28da27e50ae24?hl=en

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Hendy Irawan added a comment -

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.

...

Show
Hendy Irawan added a comment - 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. ...
Hide
Permalink
Alin Dreghiciu added a comment -

The problem is related to the missing imports for at least this packages (the list is based on S2AP artifact):

javax.management
javax.sql
javax.swing
javax.swing.border
javax.swing.event
javax.swing.plaf
javax.swing.plaf.metal
javax.swing.table
javax.swing.text
javax.swing.undo
javax.xml.parsers
javax.xml.transform
javax.xml.transform.dom
javax.xml.transform.stream
org.w3c.dom
org.xml.sax
org.xml.sax.ext
org.xml.sax.helpers

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.
The Equinox story can be found here: http://wiki.eclipse.org/index.php/Equinox_Boot_Delegation

So, a quick fix is to add the above packages to the list of exported packages.
A better long term fix is to use Peter Kriens bnd: http://www.aqute.biz/Code/Bnd, tool that will generate the correct imports.

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

Show
Alin Dreghiciu added a comment - The problem is related to the missing imports for at least this packages (the list is based on S2AP artifact): javax.management javax.sql javax.swing javax.swing.border javax.swing.event javax.swing.plaf javax.swing.plaf.metal javax.swing.table javax.swing.text javax.swing.undo javax.xml.parsers javax.xml.transform javax.xml.transform.dom javax.xml.transform.stream org.w3c.dom org.xml.sax org.xml.sax.ext org.xml.sax.helpers 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. The Equinox story can be found here: http://wiki.eclipse.org/index.php/Equinox_Boot_Delegation So, a quick fix is to add the above packages to the list of exported packages. A better long term fix is to use Peter Kriens bnd: http://www.aqute.biz/Code/Bnd , tool that will generate the correct imports. 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
Hide
Permalink
Hendy Irawan added a comment -

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)

Show
Hendy Irawan added a comment - 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)
Hide
Permalink
blackdrag blackdrag added a comment -

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

Show
blackdrag blackdrag added a comment - 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
Hide
Permalink
Hendy Irawan added a comment -

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.

Show
Hendy Irawan added a comment - 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.
Hide
Permalink
Hendy Irawan added a comment -

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.

Show
Hendy Irawan added a comment - 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.
Hide
Permalink
blackdrag blackdrag added a comment -

having two different version schemes for the jar and for OSGi can be error prone. So it is not a good way.

Show
blackdrag blackdrag added a comment - having two different version schemes for the jar and for OSGi can be error prone. So it is not a good way.
Hide
Permalink
Hendy Irawan added a comment -

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.

Show
Hendy Irawan added a comment - 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.
Hide
Permalink
Hendy Irawan added a comment -

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
initial@reference:file:org.codehaus.groovy_1.6.0.beta-2-SNAPSHOT.jar/ [3]
Id=3, Status=ACTIVE Data Root=/x/equinox/org.eclipse.osgi/bundles/3/data
No registered services.
No services in use.
Exported packages
groovy.inspect; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.inspect.swingui; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.io; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.lang; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.mock; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.mock.interceptor; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.model; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.security; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.servlet; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.sql; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.swing; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.swing.binding; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.swing.factory; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.swing.impl; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.text; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.time; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.ui; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.ui.icons; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.ui.text; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.ui.view; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.util; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.util.slurpersupport; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.xml; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.xml.dom; version="1.6.0.beta-2-SNAPSHOT"[exported]
groovy.xml.streamingmarkupsupport; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.ant; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.antlr; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.antlr.java; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.antlr.parser; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.antlr.treewalker; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.ast; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.ast.expr; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.ast.stmt; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.binding; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.bsf; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.classgen; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.control; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.control.io; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.control.messages; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.groovydoc; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.reflection; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.runtime; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.runtime.metaclass; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.runtime.typehandling; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.runtime.wrappers; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.syntax; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.tools; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.tools.groovydoc; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.tools.javac; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.tools.shell; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.tools.shell.commands; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.tools.shell.util; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.tools.xml; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.vmplugin; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.vmplugin.v4; version="1.6.0.beta-2-SNAPSHOT"[exported]
org.codehaus.groovy.vmplugin.v5; version="1.6.0.beta-2-SNAPSHOT"[exported]
Imported packages
antlr; version="2.7.7"<initial@reference:file:com.springsource.antlr_2.7.7.jar/ [18]>
antlr.collections; version="2.7.7"<initial@reference:file:com.springsource.antlr_2.7.7.jar/ [18]>
antlr.collections.impl; version="2.7.7"<initial@reference:file:com.springsource.antlr_2.7.7.jar/ [18]>
antlr.debug.misc; version="2.7.7"<initial@reference:file:com.springsource.antlr_2.7.7.jar/ [18]>
org.objectweb.asm; version="2.2.0"<initial@reference:file:com.springsource.org.objectweb.asm_2.2.0.jar/ [23]>
javax.management; version="0.0.0"<System Bundle [0]>
javax.sql; version="0.0.0"<System Bundle [0]>
javax.swing; version="0.0.0"<System Bundle [0]>
javax.swing.border; version="0.0.0"<System Bundle [0]>
javax.swing.event; version="0.0.0"<System Bundle [0]>
javax.swing.plaf; version="0.0.0"<System Bundle [0]>
javax.swing.plaf.metal; version="0.0.0"<System Bundle [0]>
javax.swing.table; version="0.0.0"<System Bundle [0]>
javax.swing.text; version="0.0.0"<System Bundle [0]>
javax.swing.undo; version="0.0.0"<System Bundle [0]>
javax.xml.parsers; version="0.0.0"<System Bundle [0]>
javax.xml.transform; version="0.0.0"<System Bundle [0]>
javax.xml.transform.dom; version="0.0.0"<System Bundle [0]>
javax.xml.transform.stream; version="0.0.0"<System Bundle [0]>
org.w3c.dom; version="0.0.0"<System Bundle [0]>
org.xml.sax; version="0.0.0"<System Bundle [0]>
org.xml.sax.ext; version="0.0.0"<System Bundle [0]>
org.xml.sax.helpers; version="0.0.0"<System Bundle [0]>
No fragment bundles
Named class space
org.codehaus.groovy; bundle-version="1.6.0.beta-2-SNAPSHOT"[provided]
No required bundles

Show
Hendy Irawan added a comment - 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 initial@reference: file:org.codehaus.groovy_1.6.0.beta-2-SNAPSHOT.jar/ [3] Id=3, Status=ACTIVE Data Root=/x/equinox/org.eclipse.osgi/bundles/3/data No registered services. No services in use. Exported packages groovy.inspect; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.inspect.swingui; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.io; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.lang; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.mock; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.mock.interceptor; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.model; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.security; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.servlet; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.sql; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.swing; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.swing.binding; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.swing.factory; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.swing.impl; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.text; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.time; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.ui; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.ui.icons; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.ui.text; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.ui.view; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.util; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.util.slurpersupport; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.xml; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.xml.dom; version="1.6.0.beta-2-SNAPSHOT" [exported] groovy.xml.streamingmarkupsupport; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.ant; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.antlr; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.antlr.java; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.antlr.parser; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.antlr.treewalker; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.ast; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.ast.expr; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.ast.stmt; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.binding; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.bsf; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.classgen; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.control; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.control.io; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.control.messages; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.groovydoc; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.reflection; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.runtime; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.runtime.metaclass; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.runtime.typehandling; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.runtime.wrappers; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.syntax; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.tools; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.tools.groovydoc; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.tools.javac; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.tools.shell; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.tools.shell.commands; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.tools.shell.util; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.tools.xml; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.vmplugin; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.vmplugin.v4; version="1.6.0.beta-2-SNAPSHOT" [exported] org.codehaus.groovy.vmplugin.v5; version="1.6.0.beta-2-SNAPSHOT" [exported] Imported packages antlr; version="2.7.7"<initial@reference: file:com.springsource.antlr_2.7.7.jar/ [18] > antlr.collections; version="2.7.7"<initial@reference: file:com.springsource.antlr_2.7.7.jar/ [18] > antlr.collections.impl; version="2.7.7"<initial@reference: file:com.springsource.antlr_2.7.7.jar/ [18] > antlr.debug.misc; version="2.7.7"<initial@reference: file:com.springsource.antlr_2.7.7.jar/ [18] > org.objectweb.asm; version="2.2.0"<initial@reference: file:com.springsource.org.objectweb.asm_2.2.0.jar/ [23] > javax.management; version="0.0.0"<System Bundle [0] > javax.sql; version="0.0.0"<System Bundle [0] > javax.swing; version="0.0.0"<System Bundle [0] > javax.swing.border; version="0.0.0"<System Bundle [0] > javax.swing.event; version="0.0.0"<System Bundle [0] > javax.swing.plaf; version="0.0.0"<System Bundle [0] > javax.swing.plaf.metal; version="0.0.0"<System Bundle [0] > javax.swing.table; version="0.0.0"<System Bundle [0] > javax.swing.text; version="0.0.0"<System Bundle [0] > javax.swing.undo; version="0.0.0"<System Bundle [0] > javax.xml.parsers; version="0.0.0"<System Bundle [0] > javax.xml.transform; version="0.0.0"<System Bundle [0] > javax.xml.transform.dom; version="0.0.0"<System Bundle [0] > javax.xml.transform.stream; version="0.0.0"<System Bundle [0] > org.w3c.dom; version="0.0.0"<System Bundle [0] > org.xml.sax; version="0.0.0"<System Bundle [0] > org.xml.sax.ext; version="0.0.0"<System Bundle [0] > org.xml.sax.helpers; version="0.0.0"<System Bundle [0] > No fragment bundles Named class space org.codehaus.groovy; bundle-version="1.6.0.beta-2-SNAPSHOT" [provided] No required bundles
Hide
Permalink
Hendy Irawan added a comment -

Patch for build.xml to make it work with OSGi out of the box.

Show
Hendy Irawan added a comment - Patch for build.xml to make it work with OSGi out of the box.
Hide
Permalink
Hendy Irawan added a comment -

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:

http://www.aqute.biz/Code/Bnd

Show
Hendy Irawan added a comment - 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: http://www.aqute.biz/Code/Bnd
Hide
Permalink
Hendy Irawan added a comment -

Related to: GROOVY-2863, GROOVY-2502

Show
Hendy Irawan added a comment - Related to: GROOVY-2863 , GROOVY-2502
Hide
Permalink
Paul King added a comment -

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.

Show
Paul King added a comment - 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.
Hide
Permalink
Hendy Irawan added a comment -

Amazing work Paul!

osgi> STARTING test.groovyosgi
Below should print Hello World from Groovy... but instead, bundle cannot start, starting bundle will give error.
Hello World from Groovy!

osgi> ss

Framework is launched.

id State Bundle
0 ACTIVE org.eclipse.osgi_3.3.2.R33x_v20080105
1 ACTIVE org.eclipse.osgi.util_3.1.200.v20070605
2 ACTIVE org.eclipse.osgi.services_3.1.200.v20070605
3 ACTIVE test.groovyosgi_1.0.0.SNAPSHOT
4 ACTIVE osgi.core_4.1.0.build-200702212030
5 ACTIVE org.ops4j.pax.logging.pax-logging-api_1.2.0.SNAPSHOT
6 ACTIVE org.ops4j.pax.logging.pax-logging-service_1.2.0.SNAPSHOT
7 ACTIVE com.springsource.antlr_2.7.7
8 ACTIVE com.springsource.org.objectweb.asm.util_2.2.0
9 ACTIVE com.springsource.org.objectweb.asm.tree.attrs_2.2.0
10 ACTIVE com.springsource.org.objectweb.asm.tree.analysis_2.2.0
11 ACTIVE com.springsource.org.objectweb.asm.tree_2.2.0
12 ACTIVE com.springsource.org.objectweb.asm_2.2.0
13 ACTIVE groovy-1.5.7-SNAPSHOT_1.5.7.SNAPSHOT

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

Show
Hendy Irawan added a comment - Amazing work Paul! osgi> STARTING test.groovyosgi Below should print Hello World from Groovy... but instead, bundle cannot start, starting bundle will give error. Hello World from Groovy! osgi> ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.3.2.R33x_v20080105 1 ACTIVE org.eclipse.osgi.util_3.1.200.v20070605 2 ACTIVE org.eclipse.osgi.services_3.1.200.v20070605 3 ACTIVE test.groovyosgi_1.0.0.SNAPSHOT 4 ACTIVE osgi.core_4.1.0.build-200702212030 5 ACTIVE org.ops4j.pax.logging.pax-logging-api_1.2.0.SNAPSHOT 6 ACTIVE org.ops4j.pax.logging.pax-logging-service_1.2.0.SNAPSHOT 7 ACTIVE com.springsource.antlr_2.7.7 8 ACTIVE com.springsource.org.objectweb.asm.util_2.2.0 9 ACTIVE com.springsource.org.objectweb.asm.tree.attrs_2.2.0 10 ACTIVE com.springsource.org.objectweb.asm.tree.analysis_2.2.0 11 ACTIVE com.springsource.org.objectweb.asm.tree_2.2.0 12 ACTIVE com.springsource.org.objectweb.asm_2.2.0 13 ACTIVE groovy-1.5.7-SNAPSHOT_1.5.7.SNAPSHOT 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
Hide
Permalink
Paul King added a comment - - edited

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.
Also, is there any easy way for me to check these myself?

Show
Paul King added a comment - - edited 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. Also, is there any easy way for me to check these myself?
Hide
Permalink
Hendy Irawan added a comment -

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). But a quick register allows full read-write access to that SVN.

Show
Hendy Irawan added a comment - 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 ). But a quick register allows full read-write access to that SVN.
Hide
Permalink
Paul King added a comment - - edited

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>
Show
Paul King added a comment - - edited 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>
Hide
Permalink
Paul King added a comment -

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.
Show
Paul King added a comment - 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.
Hide
Permalink
Hendy Irawan added a comment -

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.

Show
Hendy Irawan added a comment - 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.
Hide
Permalink
Paul King added a comment -

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.

Show
Paul King added a comment - 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.
Hide
Permalink
Hendy Irawan added a comment -

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

Show
Hendy Irawan added a comment - 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).
Hide
Permalink
Paul King added a comment -

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.

Show
Paul King added a comment - 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.
Hide
Permalink
Paul King added a comment -

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>
Show
Paul King added a comment - 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>
Hide
Permalink
Paul King added a comment -

... 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
Show
Paul King added a comment - ... 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
Hide
Permalink
Paul King added a comment -

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.

Show
Paul King added a comment - 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.
Hide
Permalink
Hendy Irawan added a comment -

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

Show
Hendy Irawan added a comment - 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

People

  • Assignee:
    Paul King
    Reporter:
    Hendy Irawan
Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: