felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Package naming (was Re: [VOTE] Please pick a name for this project)
Date Thu, 18 Aug 2005 13:15:48 GMT
Sylvain Wallez wrote:

> Richard S. Hall wrote:


>> Option #1:
>>    org.apache.osgi.framework
>>    org.apache.osgi.bundle
>>    org.apache.osgi.service
>>    ...
>> Option #2:
>>    org.apache.felix
>>    org.apache.osgi.bundle
>>    org.apache.osgi.service
> And Option #3:
> org.apache.felix.framework
> org.apache.felix.bundle
> org.apache.felix.service
> org.apache.felix.other_subproject
> This is the standard policy throughout the ASF with very few exceptions,

This is not a correct statement.  There is no definative policy with 
respect to package name enforcement at the ASF.  Everyone is presuming 
this but this is a convention that a portion, a subset of the java 
projects at the ASF, have followed out of some consensus.

Question is who is to decide this standard?  Is this the right forum?

It may very well be the right forum due to the importance of this 
project with respect to cross project interop that an OSGi project at 
the ASF brings forth.  However we will loose our focus here if we try to 
define ASF policies here. 

This is a very important project in the sense that it could unit several 
projects and lead to a means to combine the efforts of several ASF Java 
projects.  So yes package naming is important.  However not all projects 
are represented here.

> the biggest one being AFAICS... ahem... the Directory project which 
> uses a lot of org.apache.* packages: asn1, ldap, authx, naming, etc.

Yep this is true we do not follow this convention at Directory and don't 
feel that we should have to.  Some of the reasons for our package naming 
decisions stem from the fact that we were fromed from several projects 
coming together like naming and the ldap server effort.  Also we 
understand that some projects don't belong in directory even though they 
started there.  Take the ASN.1 libraries which can be used by several 
protocols.  Eventually we can see this library moving off to a commons 
or elsewhere.

Regardless of the intent we have not had an issue with package name 
conflicts.  There is no reason for us to get ahead of ourselves and 
impose restrictions if there are no problems.  When we have a problem we 
can refactor the package names to find a solution.  Time is better spent 
confronting the problems we do have in front of us.  We have that 
agility and there is no reason to worry or excessivley plan ahead.  It 
is highly unlikely that we're going to have a package name conflict with 

> If we want to avoid name clashes in applications using several Apache 
> products and considering how fast the ASF is growing, projects should 
> put all their classes in the org.apache.{project-name} package.
Good that you're thinking about this but really how many conflicts have 
you had to deal with till now.  Let's encounter the problem first before 
we devise a solution for it.  Furthermore, this convention needs to be 
galvanized officially as a standard before it's mandated across java 
based effforts or upon unsuspecting incubator podlings.  I have not seen 
the ASF make any formal statment regarding package naming schemes. 
Perhaps its time for one to be made to spare us the confusion.

> Packdage names should not be about the technology the classes they 
> contain rely on, nor the specification they implement, but about the 
> project and community that writes these classes and cares about them. 
> Using another policy is IMO an open door to name clashes and doesn't 
> follow the ASF principle that community is more important than the code.
You see I like this statement and it makes sense in encapsulating 
namespace branches based on the origins of packages.  All I'm saying is 
we need a formal body to decide these matters at the ASF for java based 
projects.  Although very appealing this does not account for every 
concern associated with package name selection.  There might be some 
value in having package names express more than their origins.  This is 
a classic problem where people have to decide how to branch a namespace 
and a formal body is required to decide this matter.  The OID namespace 
for example is one that had similar issues.

> And if doing the renaming is an issue now that the code is in SVN, I 
> volunteer for doing the change ;-)

Thanks for volunteering but let's do this right instead of turning felix 
into a project yoyo.  If we do this let's do it once and for all with 
everyone in agreement.  Let's not get too far ahead of our selves here.  
I'm not sure any changes need to happen immediately. 

Let's just start focusing on the community and the technology so some 
fresh air can waft through this project as opposed to these bike 
shedding discussions.  Let's put this on the back burner and look 
towards a larger ASF panel that has representatives from all PMCs to 
make the final call on a package naming standard *NOT* just a 
recommended convention people can decide to follow or ignore.

Let's not tax this community with a greater ASF concern.   Let's be 
proactive though.  Can you work with me to setup some panel of PMC 
members where we can galvanize a policy?  Some kind of java specific 
panel at the ASF.  Hopefully we can come up with something definative 
together where all TLPs and their projects authoring java code can 
conform to an official ASF standard.


View raw message