I like the idea of hyphenated feature names that are more descriptive. I am
not a fan period-delimited names that are similar in appearance to package
names. The latter naming convention would lead to confusion among
developers new to Karaf.
"Hey Joe, I can't find this package anywhere."
"Bob, its not a package, its a feature."
"... huh? it looks like a package, are you sure."
"Yep"
"Wow, that's too confusing. Karaf is hard, and I'm don't like hard stuff.
Lets use Tomcat instead"
"Meh, I used Tomcat 10 years ago, I can deal with it."
iocanel 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 :)
> --
> *Ioannis Canellos*
> *
> FuseSource <http://fusesource.com>
>
> **
> Blog: http://iocanel.blogspot.com
> **
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/> Committer
> Apache Gora <http://incubator.apache.org/gora/> Committer
> *
>
-----
Mike Van
Mike Van's Open Source Technologies Blog
--
View this message in context:
http://karaf.922171.n3.nabble.com/feature-names-are-potentially-ambiguous-tp3263950p3417458.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
