Refactor some feature gen variables#520
Conversation
Co-authored-by-AI: IBM Bob 1.0.2 Signed-off-by: Paul Gooderham <turkeyonmarblerye@gmail.com>
turkeylurkey
force-pushed
the
refactor-feature-gen
branch
from
65f5f51 to
de7373a
Compare
| import java.util.Set; | ||
|
|
||
| public abstract class BinaryScannerUtil { | ||
| public abstract class FeatureGenUtil { |
There was a problem hiding this comment.
I just want to think through this name change a bit. We are looking to consolidate the common code for GenerateFeaturesMojo.java and GenerateFeaturesTask.groovy. I assume the likely name for the class/file that contains the common code would be GenerateFeaturesUtil. If that is the case, we would have GenerateFeaturesUtil and FeatureGenUtil. I think it would be hard to differentiate the meaning of those file names. Should we use something like FeatureGenDriverUtil, FeatureGenJarUtil, or FeatureGeneratorUtil to show a clear distinction?
There was a problem hiding this comment.
since we have the method runFeatureGenerator() I think FeatureGeneratorUtil is the best choice.
Co-authored-by-AI: IBM Bob 1.0.3 Signed-off-by: Paul Gooderham <turkeyonmarblerye@gmail.com>
| // 6. IllegalTargetCombinationException means that the EE level and the MP level are not compatible. | ||
| Throwable scannerException = ite.getCause(); | ||
| if (scannerException.getClass().getName().equals(PROVIDED_FEATURE_EXCEPTION)) { | ||
| Throwable featureGenException = ite.getCause(); |
There was a problem hiding this comment.
suggestion to change to generatorException
Signed-off-by: Paul Gooderham <turkeyonmarblerye@gmail.com>
2 participants
Embrace the feature gen.