You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Ioannis Canellos <io...@gmail.com> on 2011/10/13 00:57:59 UTC
Re: feature names are potentially ambiguous?
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
*
Re: feature names are potentially ambiguous?
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday, October 13, 2011 1:57:59 AM Ioannis Canellos wrote:
> Though I liked the idea of symbolic-name like features a lot, I somehow do
> not like the result.
I agree. I really don't like it either. I'd much prefer something
shorter, but still unique:
karaf-config
karaf-war
karaf-http
etc....
Still points at karaf, but is relatively small and doesn't clutter things up
terribly. The whole "org.apache." part is terribly redundant. But that's
my opinion. :-)
Dan
>
> 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.feat
> ures.standard.ssh,org.apache.karaf.features.standard.management,org.apache.k
> araf.features.standard.config,org.apache.karaf.features.standard.ssh,org.apa
> che.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</featur
> e> <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 :)
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: feature names are potentially ambiguous?
Posted by David Jencks <da...@yahoo.com>.
I think a lot of the readability issues can be addressed by formatting, certainly its easy to put each feature name and repo name on a new line for (a).
I think any solution has to allow every project using karaf to have it's own features named framework, standard, enterprise, spring,, obr.....
I think that being able to trace a feature back to the project it came from using its name is really valuable.
So I'd concentrate on presentation improvements.
thanks
david jencks
On Oct 12, 2011, at 3:57 PM, 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 :)
> --
> *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
> *
Re: feature names are potentially ambiguous?
Posted by Ioannis Canellos <io...@gmail.com>.
>> *I think this is why people have pretty much universally adopted FQN for
bundle symbolic names, and I think the same reasoning applies here.*
Yes, you are right on this. However, there are quite a few differences
between feature names and symbolic names that I think we should take into
consideration:
a) Symbolic names have to be unique.
b) You don't use symbolic names to provision your bundles
(install,uninstall, start & stop). For that purpose you use the bundle id.
I don't disagree that FQN is the perfect solution in order to distinguish
features. I am just saying that its not very friendly to the user.
*>> We're planning to release them for karaf 3, IIUC you want to name them
things like aries-jndi version 3.0.0. Next week aries creates a similar
feature and calls it aries-jndi version 3.0.0, and we pack it up in a
feature repository we distribute. How do I know which feature I'm getting?*
I must say this concern is valid and we do need to provide a clean solution
for this. Here's what I am thinking:
This case doesn't apply to all features, but to just some of the features. I
feel that applying a naming policy to ALL features just to be able to
resolve possible ambiguities that apply to some of the features is not the
way to go. Especially, when the naming policy generates clutter and is
somehow more difficult to use.
So, I would like to propose that we use the repository id in order to
resolve these ambiguities as we already do with versions. For example:
If we have the same feature for multiple versions we can do something like:
features:install <name>/version. We could do something like:
features:install <repo-id>/<name> or features:install <repo-id>/<name>
/<version>.
What do you think?
--
*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
*
Re: feature names are potentially ambiguous?
Posted by David Jencks <da...@yahoo.com>.
On Oct 14, 2011, at 12:52 AM, Ioannis Canellos wrote:
>>
>> 2. Any feature distributed by a project needs to have that projects name in
>> the feature name. To take the aries-jndi example, if karaf names a feature
>> aries-jndi, and aries wants to publish a jndi feature themselves, what can
>> they call it? I think karaf has to use "karaf-aries-jndi" and aries gets
>> "aries-jndi".
>
>
> imho, if aries shipped a feature, the way to go would be to reuse that
> feature in Karaf and don't ship a different feature ourselves.
I don't understand your thinking. IIUC we already have a few features that contain only aries bundles. We're planning to release them for karaf 3, IIUC you want to name them things like aries-jndi version 3.0.0. Next week aries creates a similar feature and calls it aries-jndi version 3.0.0, and we pack it up in a feature repository we distribute. How do I know which feature I'm getting? I think this is why people have pretty much universally adopted FQN for bundle symbolic names, and I think the same reasoning applies here.
BTW, I suggested the longer names when I started running into exactly this problem between karaf and geronimo features.
thanks
david jencks
>
>
>> Of course one solution is to use a fully qualified name, and I don't think
>> they are really any more complicated than these partly-qualified names,
>> which is why I think we should keep them.
>
>
> It's not about being complicated (though I think it can create some
> confusion). It's about keeping things small and avoiding too much clutter.
>
> --
> *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
> *
Re: feature names are potentially ambiguous?
Posted by Ioannis Canellos <io...@gmail.com>.
>
> 2. Any feature distributed by a project needs to have that projects name in
> the feature name. To take the aries-jndi example, if karaf names a feature
> aries-jndi, and aries wants to publish a jndi feature themselves, what can
> they call it? I think karaf has to use "karaf-aries-jndi" and aries gets
> "aries-jndi".
imho, if aries shipped a feature, the way to go would be to reuse that
feature in Karaf and don't ship a different feature ourselves.
> Of course one solution is to use a fully qualified name, and I don't think
> they are really any more complicated than these partly-qualified names,
> which is why I think we should keep them.
It's not about being complicated (though I think it can create some
confusion). It's about keeping things small and avoiding too much clutter.
--
*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
*
Re: feature names are potentially ambiguous?
Posted by David Jencks <da...@yahoo.com>.
I don't understand your question. I was trying to say 2 completely separate things:
1. I think but don't know that the subsystem spec expects that subsystem names are like bsns. If this is true it might be a good idea to line up karaf feature names for future compatibility with subsystems.
2. Any feature distributed by a project needs to have that projects name in the feature name. To take the aries-jndi example, if karaf names a feature aries-jndi, and aries wants to publish a jndi feature themselves, what can they call it? I think karaf has to use "karaf-aries-jndi" and aries gets "aries-jndi". Of course one solution is to use a fully qualified name, and I don't think they are really any more complicated than these partly-qualified names, which is why I think we should keep them.
thanks
david jencks
On Oct 13, 2011, at 9:14 AM, Jean-Baptiste Onofré wrote:
> Hi David,
>
> just to understand, is it not a Geronimo usage (I didn't take a look of that in Geronimo) ?
>
> I'm not sure that sub-systems will help.
>
> On 10/13/2011 06:04 PM, David Jencks wrote:
>>
>> On Oct 13, 2011, at 8:55 AM, Ioannis Canellos wrote:
>>
>>> Hi David,
>>>
>>> The fact that the features you mentioned are provided by the Karaf doesn't
>>> mean that we need to prefix them with karaf.
>>> For example we can only use the project that implements those features and
>>> end up with something like this:
>>>
>>> aries-jndi
>>> aries-tx
>>> spring-tx
>>> camel-jpa
>>> karaf-webconsole
>>>
>>> wdyt?
>>
>> Absolutely not. If geronimo wants to use a different selection of bundles for an aries-jndi feature it should be able to without any difference in naming convention.
>>
>> I'd check the subsystem spec to see what they plan to use. The sample subsystems I've seen all use a bsn-like name.
>>
>> thanks
>> david jencks
>>
>>>
>>> --
>>> *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
>>> *
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: feature names are potentially ambiguous?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi David,
just to understand, is it not a Geronimo usage (I didn't take a look of
that in Geronimo) ?
I'm not sure that sub-systems will help.
On 10/13/2011 06:04 PM, David Jencks wrote:
>
> On Oct 13, 2011, at 8:55 AM, Ioannis Canellos wrote:
>
>> Hi David,
>>
>> The fact that the features you mentioned are provided by the Karaf doesn't
>> mean that we need to prefix them with karaf.
>> For example we can only use the project that implements those features and
>> end up with something like this:
>>
>> aries-jndi
>> aries-tx
>> spring-tx
>> camel-jpa
>> karaf-webconsole
>>
>> wdyt?
>
> Absolutely not. If geronimo wants to use a different selection of bundles for an aries-jndi feature it should be able to without any difference in naming convention.
>
> I'd check the subsystem spec to see what they plan to use. The sample subsystems I've seen all use a bsn-like name.
>
> thanks
> david jencks
>
>>
>> --
>> *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
>> *
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: feature names are potentially ambiguous?
Posted by mikevan <mv...@comcast.net>.
I checked they subsystem spec before I made my entry. In the spec, their
example uses a period-delimited name. However, the spec does not mandate
that usage.
David Jencks wrote:
>
> On Oct 13, 2011, at 8:55 AM, Ioannis Canellos wrote:
>
>> Hi David,
>>
>> The fact that the features you mentioned are provided by the Karaf
>> doesn't
>> mean that we need to prefix them with karaf.
>> For example we can only use the project that implements those features
>> and
>> end up with something like this:
>>
>> aries-jndi
>> aries-tx
>> spring-tx
>> camel-jpa
>> karaf-webconsole
>>
>> wdyt?
>
> Absolutely not. If geronimo wants to use a different selection of bundles
> for an aries-jndi feature it should be able to without any difference in
> naming convention.
>
> I'd check the subsystem spec to see what they plan to use. The sample
> subsystems I've seen all use a bsn-like name.
>
> thanks
> david jencks
>
>>
>> --
>> *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
NCI, Inc.
Atraxia Technologes
--
View this message in context: http://karaf.922171.n3.nabble.com/feature-names-are-potentially-ambiguous-tp3263950p3420297.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: feature names are potentially ambiguous?
Posted by David Jencks <da...@yahoo.com>.
On Oct 13, 2011, at 8:55 AM, Ioannis Canellos wrote:
> Hi David,
>
> The fact that the features you mentioned are provided by the Karaf doesn't
> mean that we need to prefix them with karaf.
> For example we can only use the project that implements those features and
> end up with something like this:
>
> aries-jndi
> aries-tx
> spring-tx
> camel-jpa
> karaf-webconsole
>
> wdyt?
Absolutely not. If geronimo wants to use a different selection of bundles for an aries-jndi feature it should be able to without any difference in naming convention.
I'd check the subsystem spec to see what they plan to use. The sample subsystems I've seen all use a bsn-like name.
thanks
david jencks
>
> --
> *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
> *
Re: feature names are potentially ambiguous?
Posted by Ioannis Canellos <io...@gmail.com>.
Hi David,
The fact that the features you mentioned are provided by the Karaf doesn't
mean that we need to prefix them with karaf.
For example we can only use the project that implements those features and
end up with something like this:
aries-jndi
aries-tx
spring-tx
camel-jpa
karaf-webconsole
wdyt?
--
*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
*
Re: feature names are potentially ambiguous?
Posted by David Jencks <da...@yahoo.com>.
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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: feature names are potentially ambiguous?
Posted by Andreas Pieber <an...@gmail.com>.
+1/-1 from my side; I've no problem with the new feature names, but it's
also OK for me to use the old structure.
Kind regards,
Andreas
On Thu, Oct 13, 2011 at 14:07, Achim Nierbeck <bc...@googlemail.com>wrote:
> +1 for reverting to a more user-friendly naming, I kinda like the "project
> shortname"-"feature" syntax like karaf-obr or the like
>
> regards, Achim
>
> 2011/10/13 Ioannis Canellos <io...@gmail.com>
>
> > >
> > > 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).
> > >
> >
> > Yes, I agree on that and I think that Daniel mentioned that as a naming
> > convention.
> > --
> > *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
> > *
> >
>
>
>
> --
> --
> *Achim Nierbeck*
>
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
>
Re: feature names are potentially ambiguous?
Posted by Achim Nierbeck <bc...@googlemail.com>.
+1 for reverting to a more user-friendly naming, I kinda like the "project
shortname"-"feature" syntax like karaf-obr or the like
regards, Achim
2011/10/13 Ioannis Canellos <io...@gmail.com>
> >
> > 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).
> >
>
> Yes, I agree on that and I think that Daniel mentioned that as a naming
> convention.
> --
> *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
> *
>
--
--
*Achim Nierbeck*
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Re: feature names are potentially ambiguous?
Posted by Ioannis Canellos <io...@gmail.com>.
>
> 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).
>
Yes, I agree on that and I think that Daniel mentioned that as a naming
convention.
--
*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
*
Re: feature names are potentially ambiguous?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: feature names are potentially ambiguous?
Posted by mikevan <mv...@comcast.net>.
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.