Closed GoogleCodeExporter closed 9 years ago
Sorry - won't fix this.
The issue arises in two areas - in base MBG, we do not support these types of
imports (on demand imports) in the DOM. In the Java merger there is some basic
support for on demand imports, but it is not robust enough to handle all use
cases. The use cases can get complex for this I think it could lead to
unpredictable results.
Additionally, I don't think this is such a great practice (on demand imports).
Most Java style guide recommend against using these types of imports anyway.
Original comment by jeffgbut...@gmail.com
on 16 Jul 2012 at 2:58
I understand, but sometimes isn't possible to know what classes I need to
import. So I need this kind of imports (on demand imports). Remember one thing,
this occurs will merging existing code, so was the programmers choice to add
that kind of imports. The Package JavaFileMerger shouldn't change the
programmers custom code.
Anyway, I already solve the problem, I add this line
newId.setOnDemand(newImport.isOnDemand());
on method getMergedSource.
The code looks like:
...
// reconcile the imports
List<ImportDeclaration> newImports = getNewImports(cu.imports(), newJavaFileVisitor);
for (ImportDeclaration newImport : newImports) {
Name name = ast.newName(newImport.getName().getFullyQualifiedName());
ImportDeclaration newId = ast.newImportDeclaration();
newId.setName(name);
newId.setOnDemand(newImport.isOnDemand());
cu.imports().add(newId);
}
...
Original comment by Kin...@gmail.com
on 16 Jul 2012 at 3:25
Cool - I'm glad you've fixed it for your use case. That's the beauty of open
source!
Original comment by jeffgbut...@gmail.com
on 16 Jul 2012 at 3:29
Give it a try with the new version of the plugin. It might work as I added
code like your example for other purposes.
Original comment by jeffgbut...@gmail.com
on 16 Jul 2012 at 8:04
Original issue reported on code.google.com by
Kin...@gmail.com
on 27 Mar 2012 at 9:49