I know I'm outvoted, but -1.
Please be sure that every name you choose has karaf in it somewhere for the
features from karaf. For instance the karaf feature setting up aries jndi
needs both karaf and aries in the name, e.g. karaf-aries-jndi, karaf-spring-*
Since the feature names all have "feature" as one of the segments I think the
chance of confusing them with package names is small.
I think the same argument can be made about bundle symbolic names, but long
names there are pretty standard.
david jencks
On Oct 13, 2011, at 4:53 AM, Jean-Baptiste Onofré wrote:
> 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
