Re: [gmf-dev] Abandon Javadoc generation for GMF Tooling?

["Philipp W. Kutter | Montages AG" <kutter@xxxxxxxxxxxx>]

I hope this decision excludes all Classes that are generated from a standard ECore model using standard ECore templates.

Any reflection of ECore models as Interfaces/Classes should reflect the ECore model in its form as JavaDoc comments.

(It may be there are no such classes in GMF Tooling, but I expect that at least the classes corresponding to the three PIM metamodel concepts are like this..)

Regards, Philipp

On 07.12.2012 16:37, Michael Golubev wrote:

Hello,

Then I'm in favor of removing Javadoc profiles from GMF Tooling and skip Javadoc generation.

+1 from me. 

It also should reduce the size of the workspace at hudson, I guess.

Regards,
Michael

On Fri, Dec 7, 2012 at 4:16 PM, Mickael Istria <mistria@xxxxxxxxxx> wrote:

Hi all,

Status:
* GMF Tooling produces Javadoc
* Producing Javadoc for GMF Tooling makes build annoying (need to run "mvn install -P!javadoc" before)
* GMF Tooling ships source features

JDT shows Javadoc when source bundles are available. It does not actually use Javadoc in such case, but shows Javadoc as it appears in relevant source available for this class. So it seems like such effort to produce Javadoc does not add extra-value in IDE on providing Source features.
Then I'm in favor of removing Javadoc profiles from GMF Tooling and skip Javadoc generation.

WDYT?

On a side note, I think that GMF-Tooling feature should require (not include) the GMF Runtime SDK that ships sources for GMF Runtime.

-