incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Nauroth <>
Subject Re: apache package naming convention
Date Mon, 10 Aug 2015 16:55:35 GMT
Consideration of end user impact is a great point, and perhaps the most
important consideration.  In the case of DataFu, others have brought up
that the rename would be a backwards-incompatible change that breaks all
existing client scripts that use DataFu, and going forward such a change
would cause extra low-value typing in a scripting language that's targeted
to serving non-programmers.  I think this makes a compelling argument for
preserving the existing names in DataFu.  For another project where the
package names are entirely an implementation detail and not user-facing,
doing the rename is not likely to cause impact.

Thanks for bringing up the topic, Matt.

--Chris Nauroth

On 8/10/15, 2:22 AM, "Stian Soiland-Reyes" <> wrote:

>I think you should consider the impact and potential gain on a
>per-project basis, and agree this within the podling. I don't think we
>can prescribe one way or the other for every project.
>Changing the package name can for Java developers be a bit of an
>identity thing and help to level the playing field if a strong
>commercial actor is still involved. Removing
>com.proprietarycompany.projectname can be more important than removing
>a neutral org.projectname.
>A more user-fronting project (e.g. a GUI or self-contained server)
>face less impact on renaming than a project with many compile-bindings
>outside the project (e.g. Hadoop).
>For the Taverna incubator (which can't be reliably placed on such an
>axis with a GUI+server and many external plugins), we decided that as
>we were moving to Apache at the same time as we were getting ready for
>3.0 with a different plugin system anyway, then this was a good time
>(and perhaps the only time) to do package rename.
>But for our project, which had numerous git repositories, Maven
>modules and OSGi configurations (and was due some refactoring), a Java
>package rename and restructuring was a bit more work than a quick sed
>and folder move, and left the codebase in non-compilable flux for
>several months and took away focus from community building.
>On the other hand, this was a good exercise for engaging the whole of
>the PPMC in taking responsibility for all of the code base - for our
>project we had a history of divide-and-conquer responsibilities, but
>once we had agreed on the new structure, then several committers could
>help in getting the code back in shape. Deciding on the code base
>structure "by committee" in the open rather than through a visionary
>"dictatorship" is quite a bit of overhead, but also helps build a
>common understanding and buy-in of how the project should be.
>For an early project like the Commons RDF incubator, package rename
>was done in a day and had minimal impact. Here we didn't do any
>structural changes except splitting out a new module. I think keeping
>the change lightweight is the best option if possible.
>As Andy pointed out, for a mature project like Jena (with third-party
>bindings) you might consider to hold off package rename until the next
>major release, which could be years down the line. You can still use
>the org.apache.* packages for new stuff, and if you have a clear
>api/impl split, also gradually move impl modules under org.apache.
>On 10 August 2015 at 02:28, Roman Shaposhnik <> wrote:
>> Thank you all for the feedback. This is super helpful!
>> One question that I still have is this: do we have a bias
>> for suggesting package rename or any package name
>> can remain in place?
>> Thanks,
>> Roman.
>> On Sat, Aug 8, 2015 at 2:25 AM, Andy Seaborne <> wrote:
>>> Hi,
>>> Jena graduated 2012 with old namespaces under com.hp.hpl.jena, and some
>>> under org.openjena, with an intention to change at the first major
>>> update.  As new packages came along, they went into org.apache.jena
>>>but the
>>> user facing packages remained where they were.
>>> We released Jena 3.0.0 last month, so 3 years. That major release was
>>> coupled to another incompatible change (RDF 1.1 semantics) so 3.x
>>> wasn't just to do the packages, package renaming waited until a
>>> point.
>>> Our users have data with (RDF) namespaces under old names - we are not
>>> planning on changing that at all.  (A general issue for all linked
>>> I don't see it as an issue for graduation if the project has
>>>considered the
>>> matter.
>>>         Andy
>>> On 07/08/15 23:16, Matthew Hayes wrote:
>>>> Hi all,
>>>> Roman Shaposhnik suggested I open a discussion on the following topic:
>>>> For Apache DataFu, all of the Java classes are declared in a datafu.*
>>>> namespace.  This has been the naming convention since the DataFu
>>>> started in 2010.  Since DataFu became part of the Apache incubation
>>>> process, the topic has come up of moving all of the classes into a
>>>> org.apache.datafu.* namespace.  This was first discussed in January
>>>> (see DATAFU-7) and most recently again in the past couple weeks.  The
>>>> consensus at the time last year was that it would be a huge pain for
>>>> and not worth the cost.  It would break any script out there currently
>>>> using DataFu.  Also Jakob Homan and Russell Journey pointed out that
>>>> is just a convention and not all Apache projects follow it.  Since we
>>>> would
>>>> like DataFu to graduate sometime soon it would be good to clarify
>>>>what the
>>>> requirements are on package naming conventions before we do a release.
>>>> Thoughts?
>>>> Thanks,
>>>> Matt
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
>Stian Soiland-Reyes
>Apache Taverna (incubating), Apache Commons RDF (incubating)
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message