I'm +1 on disallowing wildcards altogether.
On Thu, Oct 1, 2015 at 6:22 PM, Chandni Singh
wrote:
> Please note the standard checkstyle configurations of sun and google
> completely avoid wildcard imports and the rationale is :
>
>
> Rationale: Importing all classes from a package or static membe
Please note the standard checkstyle configurations of sun and google
completely avoid wildcard imports and the rationale is :
Rationale: Importing all classes from a package or static members from a
class leads to tight coupling between packages or classes and might lead to
problems when a new ve
Currently with checkstyle we cannot validate that a wildcard import was
inserted only if the count is greater than a specified number.
However in the settings we provide we can specify this number only for
regular imports not static imports.
I think it should be 10, i.e., if class count is great
Chandni,
What's the policy of using wildcards?
David
On Thu, Oct 1, 2015 at 5:25 PM, Chandni Singh
wrote:
> Yes we do.
>
> On Thu, Oct 1, 2015 at 4:57 PM, Siyuan Hua wrote:
>
> > Do we allow wildcard import?
> >
> > On Wed, Sep 30, 2015 at 10:37 PM, Priyanka Gugale <
> > priya...@datatorrent.
Yes we do.
On Thu, Oct 1, 2015 at 4:57 PM, Siyuan Hua wrote:
> Do we allow wildcard import?
>
> On Wed, Sep 30, 2015 at 10:37 PM, Priyanka Gugale <
> priya...@datatorrent.com>
> wrote:
>
> > Mine also +1 for single commit for import order changes.
> > Doing this there will be clear distinction o
Do we allow wildcard import?
On Wed, Sep 30, 2015 at 10:37 PM, Priyanka Gugale
wrote:
> Mine also +1 for single commit for import order changes.
> Doing this there will be clear distinction of changes made for formatting
> (import order change) and actual code change.
>
> On Thu, Oct 1, 2015 at
Mine also +1 for single commit for import order changes.
Doing this there will be clear distinction of changes made for formatting
(import order change) and actual code change.
On Thu, Oct 1, 2015 at 9:07 AM, Vlad Rozov wrote:
> +1 to change import order in one single commit as Jenkins CI. The l
+1 to change import order in one single commit as Jenkins CI. The less
violations we have in the build the easier is to find a new one
introduced and resolve it. It will be also less confusing for new
developers to use the right import order.
Thank you,
Vlad
On 9/30/15 12:29, Chandni Singh w
I can fix them but that should be a different change and the user to which
that change is attributed should be either jenkins/ci.
On Wed, Sep 30, 2015 at 12:07 PM, Vlad Rozov
wrote:
> How many import order violations exist now in Apex-core and Apex-malhar?
> Is there a way to fix them as one sin
How many import order violations exist now in Apex-core and Apex-malhar?
Is there a way to fix them as one single batch using maven plugin or IDE
auto format?
Thank you,
Vlad
On 9/30/15 07:19, Chandni Singh wrote:
Actually keeping static imports at the bottom didn't increase rather
decreased
This looks great.
On Wednesday, September 30, 2015, Chandni Singh
wrote:
> Yes. So I think we need to change the import order so that they each IDE
> can support it.
>
> New order:
>
> all java/javax imports
>
> org.* imports
>
> org.apache.* imports
>
> com.*
>
> com.datatorrent.* imports
>
> *
Yes. So I think we need to change the import order so that they each IDE
can support it.
New order:
all java/javax imports
org.* imports
org.apache.* imports
com.*
com.datatorrent.* imports
* imports
all static imports
I will update APEX-174.
On Wed, Sep 30, 2015 at 4:38 AM, Thomas Weise
Actually keeping static imports at the bottom didn't increase rather
decreased the existing violation in Apex-core.
We have not followed any consistent style so far so this is the result of
that. As and when a person touches a file they can correct the import order.
Chandni
On Wed, Sep 30, 2015
No, there are few classes in Apex-cor and Apex-malhar
e.g. StreamPersistanceTests, PojoUtilsTest etc. Even for Ingestion we used
to keep static imports on top.
We might have to change them once we add these templates.
-Priyanka
On Wed, Sep 30, 2015 at 5:08 PM, Thomas Weise
wrote:
> Is it a bina
Is it a binary file? If so, it does not belong into this repo.
On Wed, Sep 30, 2015 at 2:31 AM, Chandni Singh
wrote:
> Pramod,
>
> Please advise.
>
> Chandni
>
> On Tue, Sep 29, 2015 at 10:47 PM, Chandni Singh
> wrote:
>
> > Tim fixed the plugin. We can add the nbm file at the same location whe
Now many classes in our code base has highest priority to static imports
(i.e. all static imports at top).
It should be fine to move them to bottom, but it's good to keep all static
imports together.
+1 for proposed order.
-Priyanka
On Wed, Sep 30, 2015 at 12:01 PM, Chandni Singh
wrote:
> Pra
Pramod,
Please advise.
Chandni
On Tue, Sep 29, 2015 at 10:47 PM, Chandni Singh
wrote:
> Tim fixed the plugin. We can add the nbm file at the same location where
> we add the configuration for netbeans.
> The readme will let the users know that they need to install this version
> of Organize Im
Tim fixed the plugin. We can add the nbm file at the same location where we
add the configuration for netbeans.
The readme will let the users know that they need to install this version
of Organize Imports.
Chandni
On Tue, Sep 29, 2015 at 6:51 PM, David Yan wrote:
> I think it's important to ha
I think it's important to have all 3 major IDE's to support whatever we
determine to be the import order.
David
On Sep 29, 2015 6:42 PM, "Chandni Singh" wrote:
> Hi,
>
> Looks like Netbeans- Organize Imports plugin doesn't let unmatched imports
> to be in between different groups.
>
> It will on
Hi,
Looks like Netbeans- Organize Imports plugin doesn't let unmatched imports
to be in between different groups.
It will only place at the bottom. The plugin has no way of specifying
unmatched imports.
Do we need to reconsider the import order when one of the IDEs doesn't
provide such basic fun
+1!
On Sep 29, 2015 10:41 AM, "Thomas Weise" wrote:
> Excellent!
>
> --
> sent from mobile
> On Sep 29, 2015 1:20 PM, "Chandni Singh" wrote:
>
> > Thomas,
> >
> > I am creating configurations for intellij, eclipse and netbeans so that
> > will take care of setting the right import order (APEX-15
Excellent!
--
sent from mobile
On Sep 29, 2015 1:20 PM, "Chandni Singh" wrote:
> Thomas,
>
> I am creating configurations for intellij, eclipse and netbeans so that
> will take care of setting the right import order (APEX-151).
>
> Chandni
>
>
> On Tue, Sep 29, 2015 at 8:43 AM, Thomas Weise
> w
Thomas,
I am creating configurations for intellij, eclipse and netbeans so that
will take care of setting the right import order (APEX-151).
Chandni
On Tue, Sep 29, 2015 at 8:43 AM, Thomas Weise
wrote:
> My top criteria is automation in the IDE(s). Don't want to fiddle with
> imports manually
My top criteria is automation in the IDE(s). Don't want to fiddle with
imports manually to keep checkstyle happy.
Thomas
On Tue, Sep 29, 2015 at 10:46 AM, Pramod Immaneni
wrote:
> I would go with * imports after com.* otherwise the other points you
> mention are fine. I agree with the point th
Sorry there was an error in the previous import order. From the responses I
think below is what everyone agrees with.
all java/javax imports
org.* imports
org.apache.* imports
com.*
* imports
com.datatorrent.* imports
all static imports
Please note: if com.datatorrent.* imports are not at
+1
On Tue, Sep 29, 2015 at 8:43 AM, Chandni Singh
wrote:
> Sorry there was an error in the previous import order. From the responses I
> think below is what everyone agrees with.
>
> all java/javax imports
>
> org.* imports
>
> org.apache.* imports
>
> com.*
>
> * imports
>
> com.datatorrent.* i
Either way for * imports is fine (alphabetical order I presume). Static
imports at the bottom is also okay if that's what is possible in certain
IDEs.
--
Chetan
On Tuesday, September 29, 2015, Pramod Immaneni
wrote:
> I would go with * imports after com.* otherwise the other points you
> menti
I would go with * imports after com.* otherwise the other points you
mention are fine. I agree with the point that it is not possible to bunch
static with their groups in IntelliJ, if it did it would be great. I prefer
them at the bottom.
Thanks
On Tue, Sep 29, 2015 at 6:49 AM, Chandni Singh
wr
I see a difference between your suggestion and Chetan's import order.
com.datatorrent.* is always the lowest one and I think static imports are
not at the bottom in Chetan's. Static imports for each group are present
below that group. His order is something like:
com.* imports
org.* imports
or
I prefer the following order which I borrowed from Chetan a while back
all java/javax imports
com.* imports
org.* imports
org.apache.* imports
com.datatorrent.* imports
* imports
all static imports
The rationale is as you go down the list you have more control/flexibility
on names for what
Hi All,
If you have issues with the current import order, please respond to this
thread.
I don't have any strong opinions on the order of static and 3rd party
library imports because I seldom refer to imports and to me in this case
only consistency is of utmost importance.
If ordering of imports
Hi,
Following is the import order:
The import order is following:
all static imports
all java/javax imports
org.* imports
com.* imports
* imports
com.datatorrent.* imports
Each group is lexicographically sorted and separated by an empty line.
Please configure your IDEs to do so.
I am work
32 matches
Mail list logo
