Did we decide which way it will be compatible? I'm a little concerned
that implementing something that can use OSGi modules is a far bigger
task that implementing something that OSGi can use. If we are going
for total compatibility it seems like we should just use OSGi.
Personally I wanted something in Java that was simpler and cleaner
that OSGi-users could leverage if they wanted. But I'm coming at this
from the we-need-something-like-maven/gem/ivy camp.
The vast majority of people that are going to use this system will
have never heard of OSGI nor care about any of their more subtle
features and just want an easy way to leverage the vast amount of
libraries available (virtually all of them are not OSGi modules today
but are jar files in maven repositories). We shouldn't be specing out
some sort of uber container but rather a simple way to tie code to its
dependencies.
I strongly suggest KISS applies to our effort. I write this knowing
that the committee seems to be heavily in favor of this alternate view
that we implement the kitchen sink.
Sam
On Apr 25, 2008, at 1:57 PM, Richard S. Hall wrote:
Bryan Atsatt wrote:
Richard S. Hall wrote:
Gordon Hirsch wrote:
1. Map its dependency declarations into a standard runtime
representation.
2. Support a standard search model over its stored modules,
using the runtime dependency expressions.
3. Map its stored module data into a standard runtime
representation that can be returned by the search.
One challenge lies in defining the "standard runtime
representations" and "standard search model" in a universal
enough way to encompass OSGi and other module systems. This
implies embracing concepts (in these standard representations and
search model) that were not universally liked by the EG early on.
(Split packages and package-level import/export come to mind.)
Package-level import/export seem like a must, but I still don't
see split packages as a necessity.
Strongly agreed on import-by-package, and that ModuleDefinition
requires a method to enumerate exported packages (and probably an
exportsPackage(String packageName) method to enable an efficient
Query).
On the split package front, however, it seems a little fuzzy to me.
If an OSGi implementation of 277 is also going to remain OSGi Rx
compliant, it will still need to support split packages, right? If
so, don't we need to surface this fact at the 277 level? Perhaps
that is as simple as acknowledging that Module.getImportedModules()
may return more than one instance that exports a given package.
That all depends on if the 277 API is a subset of OSGi functionality
or equal to it, I suppose.
-> richard
// Bryan
