felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Fwd: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
Date Tue, 01 Sep 2009 16:42:35 GMT
On 9/1/09 12:23, Guillaume Nodet wrote:
> On Tue, Sep 1, 2009 at 18:15, Richard S. Hall<heavy@ungoverned.org>  wrote:
>> For me personally, I have no problem with referring to things as Apache
>> iPOJO, etc. I was under the [apparently mistaken] impression that we could
>> not do this, because it implied it was a TLP. So, we could change all of
>> those names in one swoop and I would be fine with that.
>> As far as coming up with a name for the framework subproject, I don't have
>> an issue with that either. Maybe it has been long enough now that we could
>> go back to using Oscar. ;-) Technically, its name now is Framework, but this
>> may be too generic, e.g., Apache Framework.
> Yeah, "Apache Framework"  would be a very bad name imho.  In the recent
> past, the ASF tend to use project names that are not technology names.
> Apache WebServices is a really good example of a bad name, and that's for
> this very reason that the ASF now try to find non technology related names.
> Oscar would be fine, though I think to ease removing the confusion, it would
> be better to rename the TLP itself if ever possible.

I don't think I would actually want to reuse Oscar...it would probably 
make more sense to come up with something similar to Felix.

I don't agree about renaming the TLP. There are so many examples of 
similar situations. I cannot believe we are truly in a unique situation 

    * "Apache" typically means the HTTP Server project, but it also
      refers to the foundation and all of its independent projects.
    * "Eclipse" typically means the IDE, but there is also a runtime and
      foundation with independent projects.

Acting like this isn't normal or something that is too confusing to ever 
resolve seems a bit preposterous.

-> richard

>> ->  richard
>> On 9/1/09 12:10, Guillaume Nodet wrote:
>>> Forwarding an exerpt of one of my answer to Richard reply.
>>> I really think it's worth discussing it anyway.
>>> Most of the TLP I know about that have subprojects usually refer to those
>>> subprojects as Apache Foo and not Apache Bar Foo.
>>> So this would mean Apache iPojo and not Apache Felix iPojo, ditto for
>>> other
>>> subprojects.
>>> I also think the "branding" problem should be addressed (if possible) by
>>> renaming either the framework or the TLP.  It looks to me that renaming
>>> the
>>> TLP (even if I think would better) might be more difficult to achieve from
>>> an infra pov, but I may be wrong (I know there are some tools for
>>> migrating
>>> mailing lists and such, so it might not be so difficult).
>>> I'd like to hear other's thoughts.
>>> ---------- Forwarded message ----------
>>> From: Guillaume Nodet<gnodet@gmail.com>
>>> Date: Tue, Sep 1, 2009 at 17:45
>>> Subject: Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
>>> To: general@incubator.apache.org
>>> The problem I have with Felix is really a branding problem.  While *we*
>>> (as
>>> developers) very well know that all the subprojects of Felix are not tied
>>> to
>>> the Felix Framework itself, it's really difficult to spread this word
>>> around
>>> to non techies.  The name Felix is often associated to the OSGi framework
>>> implementation itself, and it's kinda hard to remove this tie unless
>>> either
>>> the project or the framework change its name to something else.  For
>>> example, the framework could be referred to as Apache Foo and other
>>> subprojects as Apache iPojo or Apache Karaf.  I think it would help
>>> removing
>>> this tie.   The other way around is possible too, rename the project to
>>> something else, and keep Apache Felix as referring to the framework itself
>>> (which might be even better, but slightly more difficult to actually
>>> achieve).  I'm not sure there is a very easy way, but dev@felix.a.o would
>>> a
>>> better place to discuss that.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message