CODEWITHSUNDEEP
javaumlenterprise-architect
weima
weima

Reputation: 4902

Enterprise Architect Java Code Generation File import

I am trying to generate Java code from EA UML Class Diagram. I define two classes and they have a Composition Relation ship.

say, class A contains a List of class B.

I am able to set the default collection class to List in the Code Generation Dialog Box and it correctly generates the code as:

class B {
 public List<B> m_B;
};

But i am not able to get to generate the import statement automatically. like below:

import java.util.List;
class B {
 public List<B> m_B;
};

I know there is a section in the Code Generation Dialog Box where i can specify the complete import statement, but i have many classes and i would like EA to automatically generate the import statements.

I fiddled with the Code Templates also but i could not get it to import anything other than hard coded import statements in the Code Templates.

the macros

importPackagePath
importClassName

seem to be empty.

Can anyone help me to modify the code template to figure out the imports to be done?

Thanks,

Regards,

Vimal

Upvotes: 4

Views: 2924

Answers (1)

Uffe
Uffe

Reputation: 10504

I think you should steer clear of the code generation templates. The problem here is that the handling of collection classes goes outside the normal code generation. If a class has a member whose type is a class in another package, EA generates correct import statements - but only if the classes are present in the model, which the collecion classes aren't.

There are three ways to get around this:

1) Accept that the generated code is broken.

Generate the code, then open it up in an IDE (NetBeans, Eclipse or whatever you're using) and let it take an educated guess at adding the correct import statements.

This is quick and easy, but you'll need to check the results. There is also a risk: if your "B" class imports a package which contains a "List" class, the compiler won't complain but the referenced "List" class isn't the one from java.util, which means you're not getting the code you thought you did.

2) Model the collection classes.

Create a package "java" with a child "util" and a template class "List", then change the model so that instead of a 0..* relationship to B, A has a "1" relationship to this "List" type (not B), but instantiated with type B. The correct relationship for this would be template binding.

On way of modelling the collection classes is to import rt.jar into your project. This takes a looong time though, and make sure you disable automatic diagram generation or you might run out of memory. But you will then have all utility classes imported once and for all.

If you want to be on the safe side, remove the collection classes from the Java options (Tools - Options - Source Code Engineering - Java), so EA doesn't try to use them. But if you change all the relationships, EA won't use the configured collection classes.

This results in the most correct model, and also solves the problem of how to refer to other utility classes (eg Calendar), but can be a lot of work if you've got a large model without the collection classes.

3) Use fully-qualified names for the collection classes.

In the Java options, instead of List<#TYPE#> enter java.util.List<#TYPE#>. The Java compiler doesn't need import statements if the types are referred to by their fully-qualified names.

This is extremely quick and easy, and the generated code is correct. Downside is that the code gets a bit bulkier.

If you only need the collection classes to work, I'd go with this. If you want to refer to other common utility classes, I'd say import rt.jar and rework the model.

Upvotes: 7

Related Questions