apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vlad Rozov <v.ro...@datatorrent.com>
Subject Re: Java packages: legacy -> org.apache.apex
Date Mon, 27 Feb 2017 22:28:07 GMT
Let's not be confused with open source == ASF, it is not. Not all open 
source projects are part of Apache. Majority of Apache projects do use 
"org.apache." package names.

Thank you,


//On 2/27/17 10:24, Sanjay Pujare wrote:
> +1 for bullet 1 assuming new code implies brand new classes (since it
> doesn't involve any backward compatibility issues). We can always review
> contributor PRs to make sure new code is added with new package naming
> guidelines.
> But for 2 and 3 I have a question/comment: is there even a need to do it?
> There is lots of open source code with package names like com.google.* and
> com.sun.* etc and as far as I know there are no moves afoot to rename these
> packages. The renaming itself doesn't add any new functionality or
> technical capabilities but introduces instability in Apex code as well as
> user code. Just a thought...
> On Mon, Feb 27, 2017 at 8:23 AM, Chinmay Kolhatkar <chinmay@datatorrent.com>
> wrote:
>> Thomas,
>> I agree with you that we need this migration to be done but I have a
>> different opinion on how to execute this.
>> I think if we do this in phases as described above, users might end up in
>> more confusion.
>> For doing this migration, I think it should follow these steps:
>> 1. Whether for operator library or core components, we should announce
>> widely on dev and users mailing list that "...such change is going to
>> happen in next release"
>> 2 Take up the work all at once and not phase it.
>> Thanks,
>> Chinmay.
>> On Mon, Feb 27, 2017 at 9:09 PM, Thomas Weise <thw@apache.org> wrote:
>>> Hi,
>>> This topic has come up on several PRs and I think it warrants a broader
>>> discussion.
>>> At the time of incubation, the decision was to defer change of Java
>>> packages from com.datatorrent to org.apache.apex till next major release
>> to
>>> ensure backward compatibility for users.
>>> Unfortunately that has lead to some confusion, as contributors continue
>> to
>>> add new code under legacy packages.
>>> It is also a wider issue that examples for using Apex continue to refer
>> to
>>> com.datatorrent packages, nearly one year after graduation. More and more
>>> user code is being built on top of something that needs to change, the
>> can
>>> is being kicked down the road and users will face more changes later.
>>> I would like to propose the following:
>>> 1. All new code has to be submitted under org.apache.apex packages
>>> 2. Not all code is under backward compatibility restriction and in those
>>> cases we can rename the packages right away. Examples: buffer server,
>>> engine, demos/examples, benchmarks
>>> 3. Discuss when the core API and operators can be changed. For operators
>> we
>>> have a bit more freedom to do changes before a major release as most of
>>> them are marked @Evolving and users have the ability to continue using
>>> prior version of Malhar with newer engine due to engine backward
>>> compatibility guarantee.
>>> Thanks,
>>> Thomas

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