Niclas Hedhman <[EMAIL PROTECTED]> wrote on 05/31/2006 12:30:41 AM:
> On Tuesday 30 May 2006 23:16, Jeff McAffer wrote:
> > As pointed out above, we can certainly look at supporting '-' in the
JAR
> > file name. The only place we care is in some of the boot code that
needs
> > to search for bundles. We try to avoid doing this at all costs and
are
> > generally successful but given that our version numbers change very
> > frequently (every build) some level of searching at boot time seems
> > unavoidable.
>
> Yep, I happened to have investigated the scanning for the use in
osgi.bundles
> property, as it took me quite a while to figure out a problem a few
months
> ago with the dash character... ;o)
Side note but Equinox does handle bundles with arbitrary filenames if you
spec the actual filename. The typical use of the osgi.bundles property
involves just spec'ing the bundle symbolic name. For example,
osgi.bundles=org.eclipse.core.runtime
In this case, as a convenience, the framework searches for jars that have
the form org.eclipse.core.runtime_x.y.z.q.jar etc. If it finds several of
those it chooses the one with the highest version number. This is stictly
a convenience and is intended for managing bootstrap bundles. If however
you spec something like
osgi.bundles=scr-1.0.2.jar
then the framework will not search and will load the given JAR with
whatever chars you want in the filename.
> > This works well as long as you have a repo (local or remote) structure
> > that includes groupids. When shipping a product (either on the media
or
> > on the provisioning server) you may not have this level of control and
> > maintaining this structure complicates management agents. The crux of
the
> > problem is that the bundle jar itself is not standalone since its name
is
> > not unique. The JAR is only unique in a context (i.e., group).
>
> I understand your point, but I have no particular reason to neither
> endorse it
> nor condemn it. There are arguments in both directions.
> Eclipse's solution is only one of many possible paths, and I hope you
agree
> that Eclipse is a bit of overkill to be required for OSGi development in
> general.
I'm assuming that by "Eclipse being overkill" you mean the Eclipse
filenaming scheme outlined earlier? I actually believe that the Eclipes
approach is demanded precisely for "general" OSGi development. For very
specific small scale OSGi development you will never have more than one
log-1.0.0.jar so sure, use simple names. As soon as you start using OSGi
to its full potential (i.e., as a framework for dynamically composing
independently developed components) you get naming collisions. Assuming
that consumers/provisioning agents/repo managers/... will/should/must
physically organize their bundles to avoid these collisions puts the
burden on the many to save some effort by the few (developers).
Without exception, every time I have taken a shortcut like this I have
come to regret it.
> I have made a Maven compatible product in the past, named Transit, which
> allowed for protocol based retrieval and local caching of artifacts,
with a
> format of;
>
> artifact:jar:[group]/[artifact]#[version]
>
> Transit allows for many "repository hosts" and each such host has a
"Layout",
> which could be maven1, maven2 or eclipse. And to obtain the content one
just
> do the;
> new URL( "artifact:jar:log4j/log4j#1.2.8" ).openStream();
>
> In that perspective, "files" didn't exist from the developers
perspective,
> only the artifacts, and whether the structure is flat or not became
totally
> irrelevant.
> So, therefor, I am somewhat less inclined to "play along" with the
statement
> that "flat" == "easiest". "flat" just brings a different set of issues,
and
> then a subjective priority has to take place of which issues are better
than
> others.
Yup this is a nice abstraction. As a point of interest, how does the
layout get inferred from the information given above? That is, how is it
known that "artifact:jar:log4j/log4j#1.2.8" is a Maven repo path?
The issue I'm trying to raise is the unfortunate situation where choices
made at development time (e.g., use short names for the artifact) impact
how people actually ship their bundle-based products/offerings. For
exmaple, if you use short names in the Maven repo and when you get things
out of the repo they come with short names then you are obliged to layout
those bundles (in your product, provisioning server, ...) in some related
form to avoid collisions. In effect, you have to ship part of the
development setup. If you happen to have 3 or 4 different sources for
bundles that go into your product (OBR, Felix Commons, Equinox, ...) then
you may end up shipping several different layouts.
To avoid this you can rename or reconfigure artifacts as they come out of
the related repos. This is the extraction application you mentioned
earlier. This can work but then you have the added confusion of having
the same thing with multiple names, issues of duplication (the same thing
from different sources might map to different names), figuring out, given
a mapped name, what the original was, ...
I keep coming back to the Java package name analogy. Java needed a
simple, robust naming scheme for classes. Since domain names are
universally understood, globally managed and unambiguous they make a fine
choice.
Anyway, I've likely said the same thing more than enough times now...
Jeff
