-
-
Notifications
You must be signed in to change notification settings - Fork 351
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
alternative fix bug #921 Duplicity in package-info.java when templates are used #934
alternative fix bug #921 Duplicity in package-info.java when templates are used #934
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is a good and creative solution. And again mostly backward compatible, congrats. See my two comments.
InputType FILES = FileCompilerConfig.INSTANCE; | ||
InputType CTTYPES = FactoryCompilerConfig.INSTANCE; | ||
|
||
void initializeCompiler(JDTBatchCompiler compiler); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
add javadoc:
/** responsible for setting the parameters of JDTBatchCompiler, must call setCompilationUnits() */
this.compilationUnits = compilationUnits; | ||
} | ||
|
||
public void setInputFiles(List<SpoonFile> files) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I propose that this method moves to FileCompilerConfig. And FileCompilerConfig would be responsible for calling setCompilationUnits().
@@ -154,7 +146,7 @@ public void testNewInstance() throws Exception { | |||
} | |||
|
|||
} | |||
|
|||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is better to remove instead of commenting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no problem to remove it, but I am not author. So @monperrus should agree that we will really get rid of these tests without any replacement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since your architecture is mostly backward compatible, it seems that only minor changes will enable us to keep those tests passing. can you give it a try?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will give it a try, but I would prefer if you merge my changes first, because then I can create another PRs too, related to compiler this evening. Otherwise I can fix only test and cannot do more until it is merged. Because of conflicts ...
ce552dd
to
47bd7d5
Compare
It is variant which uses non abstract JDTBatchCompiler
47bd7d5
to
6750a71
Compare
I have added comment and moved the method as suggested. I have also rebased to master |
@monperrus Hi Martin, here is the alternative PR for #932 as you suggested.
It is variant, which uses non abstract
JDTBatchCompiler
.FactoryCompiler
andFileCompiler
does not inherit fromJDTBatchCompiler
and they were renamed toFactoryCompilerConfig
andFileCompilerConfig
, because they are now used to configure theJDTBatchCompiler
.CompilationTest
file and folder filtering tests are commented for now. There is no support for filtering by overwriting ofcreateBatchCompiler
. I suggest to discuss how to implement it later.ExtendedStringLiteralTest
was updated. It should be OK.InputType
was changed fromenum
tointerface
. The change is compiler compatible so source code of the clients does not have to be changed. Just recompiled. Implementation of theInputType
can configureJDTBatchCompiler
before the compilation is started.So we have standard defaults, but now they can extend and use different configurations if needed. I use it internally instead of InputType.UNIT, I am using