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,
Vlad
//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 <chin...@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 <t...@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
