Hi Thomas,
You seem to have spend a lot of time analysing what the OSGi plugin
need to do in terms of ivy configurations.
I intend to push the osgi plugin to the next level. So far only fixed
the version handling, which wasn't fully spec compliant, and replaced
it with a version that doesn't use the impossible to follow regexps.
I know OSGi pretty well, but both Gradle and Ivy are new territories,
so perhaps we could get this working together.
As for the configurations, I need to look at this from 'the other way'
than your explanation in GRADLE-1107.
I see the following class/packages references appearing in OSGi;
- Direct provisioning, i.e. java.* classes that the framework exposes
in the execution environment. [1]
- Bootclasspath, i.e. the framework is patched to expose additionally
classes directly. [2]
- Package will be imported.
- Execution Environment packages will be exported by the framework. [3]
- All other packages are provided by other bundles. [4]
- Packages are internal to the bundle
- The classes in the bundle jar, either from Bundle-ClassPath not
being set or have a '.' (slash?) in it. [4]
- From embedded jars which are also listed in Bundle-ClassPath. [5]
- Bundle-ClassPath can be 'extended' via Fragments
- Fragments inherit the classpath of the host bundle. [6]
- The host bundle can be unresolvable without fragment(s). [7]
- Require-Bundle (?). I have never worked with it, and don't know if
it affects classpath calculations. [8]
- Split-Packages; special import case, which I am not sure how it
will affect things...[9]
Hope you can confirm or extend if I missed something;
[1] I think this can be ignored for the discussion on configurations.
[2] I suspect that this will require the ability to exclude a
dependency completely.
[3] BND will generate the correct Import-Package. But I think we need
to worry about both the case that the exported EE is 'invalid' for
certain packages and must be substituted for an independent
implementation, which I may want to embed [5], AND the case where the
EE exposes packages that are available but not in the compile
environment (case in hand org.osgi.core), i.e. need the 'provided'
concept.
[4] We need to Import packages that we use EXPLICITLY, but not its
dependencies. So, from a compile point of view, the compile path must
not be transitive (not sure if it is in Gradle).
[5] You wrote in GRADLE-1107 "runtime extends compile, Dependencies
declared under this configuration will be embedded into the OSGi
bundle". It doesn't sound right at all, unless you intend to redefine
what the configurations mean. Now, I kind of oppose that since one of
the projects I work on, Qi4j (http://www.qi4j.org) we need to produce
jars, ivy and maven poms that are useful for stand-alone apps as well.
So I don't see how 'runtime' can get a new meaning.
[6] This seems to suggest that each Fragment needs its own
configuration, which inherits from its host bundle. That in turn means
that we need to resolve the "symbolicName" -> "artifact", even if that
is not within the same project.
[7] This also seems to suggest that we need a mechanism to exclude
artifacts from embedding.
[8][9] Need to investigate.
To summarize some requirements I think I have;
- Specifiy (adding/subtracting) the classpath for;
- compile
- test
- BND
- Bundle-ClassPath
- As much convention as possible.
- Remain compatible with Maven.
- Allow projects to be correct for both OSGi and other environments
at the same time. One option here is to build a separate artifact for
the bundle. For the Maven compatibility req, this would either be via
separate artifactId or perhaps via classifier (-source, -javadocs are
classifiers already, but that is actually quite fine, since they are
intended for dev).
- Capture output from BND, and allow user to set what constitutes
build failure.
It is a non-trivial topic and I think we need to get going if Hans
promise of "it will be addressed for 1.0" will hold true.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/24svnvk
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
