Hi Ioannis,
I second you on that.
I agreed to use a full qualified feature name, but I don't like the
result as well.
FYI, to avoid to loose users, I created features name aliases.
I think we should revert the name (I will do it if all are agree). If,
as David said, some feature name are ambiguous (for instance jndi), I
have no problem to change to more descriptive name (for instance,
aries-jndi-service or whatever).
+1 to revert the feature full qualified name usage (I will take care of
that).
Regards
JB
On 10/13/2011 12:57 AM, Ioannis Canellos wrote:
Though I liked the idea of symbolic-name like features a lot, I somehow do
not like the result.
What I do not like is that a lot of things have become unreadable and the
new feature names require way more effort to use.
Some examples:
*a) org.apache.karaf.features.cfg*
featuresBoot=org.apache.karaf.features.standard.config,org.apache.karaf.features.standard.ssh,org.apache.karaf.features.standard.management,org.apache.karaf.features.standard.config,org.apache.karaf.features.standard.ssh,org.apache.karaf.features.standard.management,org.apache.karaf.features.standard.
This has become somehow unreadable. There are a lot of dots and commas and
you can easily spot where a feature name starts and where it ends. This is a
bit painfull to read.
*b) The package like format doesn't suit well to our code completion*
If I want to install the war feature, I have to press<TAB> for code
completion* 4* times:
o (choices are obr and org)
org. (choice are ops4j and apache)
org.apache.karaf.features (choices are standard and enterprise)
org.apache.karaf.features.standard (lot of choices)
Moreover the hints on each code completion are too long that I need to put
extra effort to understand my possible choices.
*b) The output of the features:list is somehow unreadable*
Really long lines which actually all repeat the same information.
I actually have to maximize my terminal to be able to read it.
*
*
*d) A feature descriptor*
<feature name="org.apache.karaf.features.standard.spring.dm.web"
description="Spring DM Web support" version="${spring.osgi.version}"
resolver="(obr)">
<feature version="${spring.osgi.version}">
org.apache.karaf.features.standard.spring.dm</feature>
<feature
version="[2.5.6,4)">org.apache.karaf.features.standard.spring.web</feature>
<feature
version="${project.version}">org.apache.karaf.features.standard.http</feature>
<bundle
start-level="30">mvn:org.springframework.osgi/spring-osgi-web/${spring.osgi.version}</bundle>
</feature>
*e) The new naming increases entropy.*
I am not sure If I expressed that right, so I will use an example. In the
karaf context when someone used to see the following string *camel-jms *he
could directly correlate the string to a feature (or an artifactId).
With the new naming the string *org.apache.camel.jms *can be anything: a) a
package name, b) a symbolic name, c) a groupId/artifactId d) a repository id
(standard repository ids are now using the same naming).
Feature elements look a lot like bundle elements and its not that friendly
to read.
The main goal of this email is point to share my concern about the
user-friendliness of the "symbolic-name like features".
I would like to hear your views first, before start thinking of
alternatives.
Thanks for having the patience to go through all of it :)
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
