Jeff McAffer wrote:
This approach puts a heavy burden on bundle consumers. Perhaps at
development time people are manually managing bundles and have an
opportunity to define a "felix" or "eclipse" directory. Personally I do
alot of this kind of bundle pushing and suspect it would be bothersome and
error prone to have to manage the origin of bundles on an individual
basis.
Beyond that, the approach is very problematic for products. When you ship
a product you want to put all the bundles (i.e., JARs) in one spot and
have them installed. Whether that is on a provisioning server (may or may
not be Maven or OBR), a CD, a zip or directly on the user's machine.
Having to sort them according to origin would be somewhat less than
optimal.
I understand that in your workflows and usecases you do not handle JARs
directly. In pretty much all of the usecases I have seen (Eclipse ones
and plain OSGi ones) there reasons that people need or want to handle the
JARs. Again, whether it is in the final deployment, on the install media,
on the provisioning server, ... at some point in the lifecycle of a bundle
the JAR will come in contact with other bundle JARs from other sources --
naming collisions are therefore not just possible but likely. Prefixing
the JAR name with "felix" or "eclipse" or, ... would certainly help.
Personally I would vote for the fully qualified domain name for the same
reasons Java developers use FQDNs for package names. It is simple and
guaranteed best practice. This is deceptively important. The rest of the
community (and not just the Apache community) is going to follow what you
do here. Having an approach that is simple ("use the same model you use
for picking package names") is powerful.
Interestingly enough, I just spent some time poking about the M2 repo on
ibiblio. If Felix were to adopt the FQDN approach for its libs, it
appears that we would be the only project in Apache doing so. On the
other hand, it does seem to be a semi-standard practice to prefix with
the project name, e.g., "felix-".
So, apparently everyone else but Eclipse is doing it incorrectly. ;-)
In truth, I can live with the long JAR file names. However, I would like
to get rid of the long names in the repository. Yet however, I am told
that the directory name should really match the artifactId for Maven.
Yet another however, if we change the artifactId then the name of the
JAR file gets shorten. Thus, we have to live with really long directory
names in the repo, which is the only thing I would like to change. :-o
-> richard
Since most people in your shoes will be using OBR, perhaps the OBR client
can be enhanced to allow for shortcuts etc. For example if you do a *src*
search and get 4 numbered results, perhaps you can then say "install 3" to
get the third result installed? That way you don't have to type any of
the URL *or* the jar name. Everyone wins.
Jeff
"Richard S. Hall" <[EMAIL PROTECTED]>
05/29/2006 04:39 AM
Please respond to
[email protected]
To
[email protected]
cc
Subject
Re: [Maven Plugin] Additional fixes...
I agree that this is the issue, however, if you are caching Felix
bundles, you could just as easily create a "felix" directory in your
cache of bundles so that you know where they come from. Which is
essentially what maven does in its repo for all of its cached JAR files...
I am afraid that this is one of those situations where there is not a
single solution that solves every concern.
-> richard
Manuel Santillan wrote:
It's cumbersome to deal with long names (as well as long URLs). However,
having FQDN'd bundles may avoid some problems; e.g.,is this
agent-1.0.0.jar mine or someone else's? URLs do not completely solve the
problem, as some people (including myself) cache the bundles to avoid
network problems, so that URL!=UID. That's why we follow the equinox's
${symbolic-name}-${version}.jar with FQDN sym-names approach.
Just an opinion, though :-)
Cheers,
Manuel
