Github user mattf-horton commented on a diff in the pull request:
https://github.com/apache/metron/pull/607#discussion_r129718460
--- Diff:
metron-interface/metron-rest/src/main/java/org/apache/metron/rest/service/impl/StormStatusServiceImpl.java
---
@@ -17,10 +17,7 @@
*/
package org.apache.metron.rest.service.impl;
-import org.apache.metron.rest.model.TopologyResponse;
-import org.apache.metron.rest.model.TopologyStatus;
-import org.apache.metron.rest.model.TopologyStatusCode;
-import org.apache.metron.rest.model.TopologySummary;
+import org.apache.metron.rest.model.*;
--- End diff --
@merrimanr , heh, you made me go look this up!
As far as I can see, our coding standards, both
[here](https://cwiki.apache.org/confluence/display/METRON/Development+Guidelines#DevelopmentGuidelines-2.2CodeStyle)
and [here](http://www.oracle.com/technetwork/java/codeconvtoc-136057.html) are
silent on this topic.
There is a good discussion of the pros and cons
[here](https://stackoverflow.com/questions/147454/why-is-using-a-wild-card-with-a-java-import-statement-bad).
Despite the latter being a fairly old article, google did not show me any more
recent definitive policy statements.
I must admit that I think the "wildcard imports are evil" side have
slightly more weight in the argument, yet I personally find long lists of
explicit imports annoying and appreciate IntelliJ's default settings (more than
5 imports of the same package collapses to wildcard). Can you provide cites
that support your assertion regarding "most coding standards"?
If you are so moved, you might bring this up on the mailing list, perhaps
providing the citations above, and propose a vote to modify the Coding Style.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
