Home » Modeling » EMF » code formatting problem
| code formatting problem [message #424895] |
Mon, 10 November 2008 10:36  |
 Sven Krause
Messages: 64
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
--------------060400020202080004090204
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Hi,
I'm not sure if the problem has been already discussed, but I didn't
found such a topic:
we realized that the javadoc comment at a generated class appears as:
/*
* blabla <!-- begin-user-doc --> <!-- end-user-doc -->
*
* @generated
*/
public final class MyPlugin extends EMFPlugin {
instead of
*/***
* blabla <!-- begin-user-doc --> <!-- end-user-doc -->
*
* @generated
*/
public final class MyPlugin extends EMFPlugin {
, but only, if the "Code Formatting" is set. What results that the
"genereted" annotation will not be considered on regeneration. Is this a
known bug, or could somewhere estimate the reason?
Sven
--------------060400020202080004090204
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
I'm not sure if the problem has been already discussed, but I didn't
found such a topic:<br>
<br>
we realized that the javadoc comment at a generated class appears as:<br>
<br>
<address>/*</address>
<address> * blabla <!-- begin-user-doc --> <!-- end-user-doc
--></address>
<address> * </address>
<address> * @generated</address>
<address> */</address>
<address>public final class MyPlugin extends EMFPlugin {</address>
<br>
instead of<br>
<br>
<address><font color="#ff6666"><b>/**</b></font></address>
<address> * blabla <!-- begin-user-doc --> <!-- end-user-doc
--></address>
<address> * </address>
<address> * @generated</address>
<address> */</address>
<address>public final class MyPlugin extends EMFPlugin {<br>
<br>
</address>
, but only, if the "Code Formatting" is set. What results that the
"genereted" annotation will not be considered on regeneration. Is this
a known bug, or could somewhere estimate the reason?<br>
<br>
Sven<br>
<br>
</body>
</html>
--------------060400020202080004090204--
|
|
|
| Re: code formatting problem [message #424896 is a reply to message #424895] |
Mon, 10 November 2008 10:43  |
Sven Krause
Messages: 64
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
--------------030304020705020307050503
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sven Krause wrote:
> Hi,
>
> I'm not sure if the problem has been already discussed, but I didn't
> found such a topic:
>
> we realized that the javadoc comment at a generated class appears as:
>
> /*
>
> * blabla <!-- begin-user-doc --> <!-- end-user-doc -->
>
> *
>
> * @generated
>
> */
>
> public final class MyPlugin extends EMFPlugin {
>
>
> instead of
>
> */***
>
> * blabla <!-- begin-user-doc --> <!-- end-user-doc -->
>
> *
>
> * @generated
>
> */
>
> public final class MyPlugin extends EMFPlugin {
>
> , but only, if the "Code Formatting" is set. What results that the
> "genereted" annotation will not be considered on regeneration. Is this
> a known bug, or could somewhere estimate the reason?
>
> Sven
>
Sorry forget to mention that dynamic templates are set either, but no
custom template for the effected class(es) must exist to reproduce the
issue.
Sven
--------------030304020705020307050503
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Sven Krause wrote:
<blockquote cite="mid:gf92qm$kck$1@build.eclipse.org" type="cite">Hi,<br>
<br>
I'm not sure if the problem has been already discussed, but I didn't
found such a topic:<br>
<br>
we realized that the javadoc comment at a generated class appears as:<br>
<br>
<address>/*</address>
<address> * blabla <!-- begin-user-doc --> <!-- end-user-doc
--></address>
<address> * </address>
<address> * @generated</address>
<address> */</address>
<address>public final class MyPlugin extends EMFPlugin {</address>
<br>
instead of<br>
<br>
<address><font color="#ff6666"><b>/**</b></font></address>
<address> * blabla <!-- begin-user-doc --> <!-- end-user-doc
--></address>
<address> * </address>
<address> * @generated</address>
<address> */</address>
<address>public final class MyPlugin extends EMFPlugin {<br>
<br>
</address>
, but only, if the "Code Formatting" is set. What results that the
"genereted" annotation will not be considered on regeneration. Is this
a known bug, or could somewhere estimate the reason?<br>
<br>
Sven<br>
<br>
</blockquote>
Sorry forget to mention that dynamic templates are set either, but no
custom template for the effected class(es) must exist to reproduce the
issue.<br>
<br>
Sven<br>
</body>
</html>
--------------030304020705020307050503--
|
|
|
| Re: code formatting problem [message #424898 is a reply to message #424896] |
Mon, 10 November 2008 10:55 |
Sven Krause
Messages: 64
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
--------------030308050503060401070806
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sven Krause wrote:
> Sven Krause wrote:
>> Hi,
>>
>> I'm not sure if the problem has been already discussed, but I didn't
>> found such a topic:
>>
>> we realized that the javadoc comment at a generated class appears as:
>>
>> /*
>>
>> * blabla <!-- begin-user-doc --> <!-- end-user-doc -->
>>
>> *
>>
>> * @generated
>>
>> */
>>
>> public final class MyPlugin extends EMFPlugin {
>>
>>
>> instead of
>>
>> */***
>>
>> * blabla <!-- begin-user-doc --> <!-- end-user-doc -->
>>
>> *
>>
>> * @generated
>>
>> */
>>
>> public final class MyPlugin extends EMFPlugin {
>>
>> , but only, if the "Code Formatting" is set. What results that the
>> "genereted" annotation will not be considered on regeneration. Is
>> this a known bug, or could somewhere estimate the reason?
>>
>> Sven
>>
> Sorry forget to mention that dynamic templates are set either, but no
> custom template for the effected class(es) must exist to reproduce the
> issue.
>
> Sven
Its me again :-)
The option state "Enable header comment formatting" from the code style
is involved too.
--------------030308050503060401070806
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Sven Krause wrote:
<blockquote cite="mid:gf9382$p00$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Sven Krause wrote:
<blockquote cite="mid:gf92qm$kck$1@build.eclipse.org" type="cite">Hi,<br>
<br>
I'm not sure if the problem has been already discussed, but I didn't
found such a topic:<br>
<br>
we realized that the javadoc comment at a generated class appears as:<br>
<br>
<address>/*</address>
<address> * blabla <!-- begin-user-doc --> <!--
end-user-doc
--></address>
<address> * </address>
<address> * @generated</address>
<address> */</address>
<address>public final class MyPlugin extends EMFPlugin {</address>
<br>
instead of<br>
<br>
<address><font color="#ff6666"><b>/**</b></font></address>
<address> * blabla <!-- begin-user-doc --> <!--
end-user-doc
--></address>
<address> * </address>
<address> * @generated</address>
<address> */</address>
<address>public final class MyPlugin extends EMFPlugin {<br>
<br>
</address>
, but only, if the "Code Formatting" is set. What results that the
"genereted" annotation will not be considered on regeneration. Is this
a known bug, or could somewhere estimate the reason?<br>
<br>
Sven<br>
<br>
</blockquote>
Sorry forget to mention that dynamic templates are set either, but no
custom template for the effected class(es) must exist to reproduce the
issue.<br>
<br>
Sven<br>
</blockquote>
Its me again :-)<br>
The option state "Enable header comment formatting" from the code style
is involved too.<br>
</body>
</html>
--------------030308050503060401070806--
|
|
|
| Re: code formatting problem [message #424900 is a reply to message #424898] |
Mon, 10 November 2008 11:30 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------010008080507030100040606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sven,
Yes, this is a JDT formatting issue. We just invoke the formatter with
whatever options are applicable for the project or workspace. It
shouldn't change a Javadoc comment into a non-Javadoc one though. That
sounds like a bug...
Sven Krause wrote:
> Sven Krause wrote:
>> Sven Krause wrote:
>>> Hi,
>>>
>>> I'm not sure if the problem has been already discussed, but I didn't
>>> found such a topic:
>>>
>>> we realized that the javadoc comment at a generated class appears as:
>>>
>>> /*
>>>
>>> * blabla <!-- begin-user-doc --> <!-- end-user-doc -->
>>>
>>> *
>>>
>>> * @generated
>>>
>>> */
>>>
>>> public final class MyPlugin extends EMFPlugin {
>>>
>>>
>>> instead of
>>>
>>> */***
>>>
>>> * blabla <!-- begin-user-doc --> <!-- end-user-doc -->
>>>
>>> *
>>>
>>> * @generated
>>>
>>> */
>>>
>>> public final class MyPlugin extends EMFPlugin {
>>>
>>> , but only, if the "Code Formatting" is set. What results that the
>>> "genereted" annotation will not be considered on regeneration. Is
>>> this a known bug, or could somewhere estimate the reason?
>>>
>>> Sven
>>>
>> Sorry forget to mention that dynamic templates are set either, but no
>> custom template for the effected class(es) must exist to reproduce
>> the issue.
>>
>> Sven
> Its me again :-)
> The option state "Enable header comment formatting" from the code
> style is involved too.
--------------010008080507030100040606
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Sven,<br>
<br>
Yes, this is a JDT formatting issue. We just invoke the formatter with
whatever options are applicable for the project or workspace. It
shouldn't change a Javadoc comment into a non-Javadoc one though. That
sounds like a bug...<br>
<br>
<br>
Sven Krause wrote:
<blockquote cite="mid:gf93vt$vo7$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Sven Krause wrote:
<blockquote cite="mid:gf9382$p00$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
Sven Krause wrote:
<blockquote cite="mid:gf92qm$kck$1@build.eclipse.org" type="cite">Hi,<br>
<br>
I'm not sure if the problem has been already discussed, but I didn't
found such a topic:<br>
<br>
we realized that the javadoc comment at a generated class appears as:<br>
<br>
<address>/*</address>
<address> * blabla <!-- begin-user-doc --> <!--
end-user-doc
--></address>
<address> * </address>
<address> * @generated</address>
<address> */</address>
<address>public final class MyPlugin extends EMFPlugin {</address>
<br>
instead of<br>
<br>
<address><font color="#ff6666"><b>/**</b></font></address>
<address> * blabla <!-- begin-user-doc --> <!--
end-user-doc
--></address>
<address> * </address>
<address> * @generated</address>
<address> */</address>
<address>public final class MyPlugin extends EMFPlugin {<br>
<br>
</address>
, but only, if the "Code Formatting" is set. What results that the
"genereted" annotation will not be considered on regeneration. Is this
a known bug, or could somewhere estimate the reason?<br>
<br>
Sven<br>
<br>
</blockquote>
Sorry forget to mention that dynamic templates are set either, but no
custom template for the effected class(es) must exist to reproduce the
issue.<br>
<br>
Sven<br>
</blockquote>
Its me again :-)<br>
The option state "Enable header comment formatting" from the code style
is involved too.<br>
</blockquote>
</body>
</html>
--------------010008080507030100040606--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: code formatting problem [message #424903 is a reply to message #424900] |
Mon, 10 November 2008 12:39 |
Sven Krause
Messages: 64
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
--------------080607040805000909080701
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Ed Merks wrote:
> Sven,
>
> Yes, this is a JDT formatting issue. We just invoke the formatter
> with whatever options are applicable for the project or workspace. It
> shouldn't change a Javadoc comment into a non-Javadoc one though.
> That sounds like a bug...
>
The problem is, that the wrong formatting happens only, when invoked
during the code generator. Activating the code formatter within an java
editor or via the package explorer ends does not suppress the jdoc star.
So I assume the problem is not located within JDT only ?! Could you
guide me to the point, where the code formatter is invoked, so that I
may try to locate the issue reason?
Sven
--------------080607040805000909080701
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ed Merks wrote:
<blockquote cite="mid:gf9604$2j2$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Sven,<br>
<br>
Yes, this is a JDT formatting issue. We just invoke the formatter with
whatever options are applicable for the project or workspace. It
shouldn't change a Javadoc comment into a non-Javadoc one though. That
sounds like a bug...<br>
<br>
</blockquote>
The problem is, that the wrong formatting happens only, when invoked
during the code generator. Activating the code formatter within an java
editor or via the package explorer ends does not suppress the jdoc
star. So I assume the problem is not located within JDT only ?! Could
you guide me to the point, where the code formatter is invoked, so that
I may try to locate the issue reason?<br>
<br>
Sven<br>
</body>
</html>
--------------080607040805000909080701--
|
|
|
| Re: code formatting problem [message #424906 is a reply to message #424903] |
Mon, 10 November 2008 13:05 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------080606090204030305050001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sven,
In AbstractGeneratorAdapter.generateJava you'll find
// Create a code formatter for this compilation unit, if needed.
//
Object codeFormatter =
getGenerator().getOptions().codeFormatting ?
createCodeFormatter(getGenerator().getOptions().codeFormatte rOptions,
targetFile) : null;
and then later in that method, you'll see it gets called:
newContents =
formatCode(jMerger.getTargetCompilationUnitContents(), codeFormatter);
It will be good to see where the "*" goes missing...
Sven Krause wrote:
> Ed Merks wrote:
>> Sven,
>>
>> Yes, this is a JDT formatting issue. We just invoke the formatter
>> with whatever options are applicable for the project or workspace.
>> It shouldn't change a Javadoc comment into a non-Javadoc one though.
>> That sounds like a bug...
>>
> The problem is, that the wrong formatting happens only, when invoked
> during the code generator. Activating the code formatter within an
> java editor or via the package explorer ends does not suppress the
> jdoc star. So I assume the problem is not located within JDT only ?!
> Could you guide me to the point, where the code formatter is invoked,
> so that I may try to locate the issue reason?
>
> Sven
--------------080606090204030305050001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Sven,<br>
<br>
In AbstractGeneratorAdapter.generateJava you'll find <br>
<br>
// Create a code formatter for this compilation unit, if
needed.<br>
//<br>
Object codeFormatter =
getGenerator().getOptions().codeFormatting ?<br>
createCodeFormatter(getGenerator().getOptions().codeFormatte rOptions,
targetFile) : null;<br>
<br>
and then later in that method, you'll see it gets called:<br>
<br>
newContents =
formatCode(jMerger.getTargetCompilationUnitContents(), codeFormatter);<br>
<br>
It will be good to see where the "*" goes missing...<br>
<br>
<br>
Sven Krause wrote:
<blockquote cite="mid:gf9a2a$83q$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Ed Merks wrote:
<blockquote cite="mid:gf9604$2j2$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
Sven,<br>
<br>
Yes, this is a JDT formatting issue. We just invoke the formatter with
whatever options are applicable for the project or workspace. It
shouldn't change a Javadoc comment into a non-Javadoc one though. That
sounds like a bug...<br>
<br>
</blockquote>
The problem is, that the wrong formatting happens only, when invoked
during the code generator. Activating the code formatter within an java
editor or via the package explorer ends does not suppress the jdoc
star. So I assume the problem is not located within JDT only ?! Could
you guide me to the point, where the code formatter is invoked, so that
I may try to locate the issue reason?<br>
<br>
Sven<br>
</blockquote>
</body>
</html>
--------------080606090204030305050001--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: code formatting problem [message #424945 is a reply to message #424906] |
Tue, 11 November 2008 13:52 |
Sven Krause
Messages: 64
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
--------------010301060600050806070804
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Ed Merks wrote:
> Sven,
>
> In AbstractGeneratorAdapter.generateJava you'll find
>
> // Create a code formatter for this compilation unit, if needed.
> //
> Object codeFormatter =
> getGenerator().getOptions().codeFormatting ?
>
> createCodeFormatter(getGenerator().getOptions().codeFormatte rOptions,
> targetFile) : null;
>
> and then later in that method, you'll see it gets called:
>
> newContents =
> formatCode(jMerger.getTargetCompilationUnitContents(), codeFormatter);
>
> It will be good to see where the "*" goes missing...
Hi Ed,
I guess, I found the location, but I'm not able to fix the issue. JDT
interprets the code style property
"org.eclipse.jdt.core.formatter.comment.format_header" twice: one to
determine if the header (text before "package" line) shall be formatted
and second determining if javadoc comment or block comment is to apply.
I have now glue why it behaves different when invoked from JDT and when
invoked from EMF. I can only guess that its due to in memory parsing vs.
file parsing. So I turned the header formatting of as workaround for me.
The decision how to generate is made within
org.eclipse.jdt.internal.formatter.Scribe.includesJavadocCom ments() and
executed at: org.eclipse.jdt.internal.formatter.Scribe line 1873.
Sven
>
>
> Sven Krause wrote:
>> Ed Merks wrote:
>>> Sven,
>>>
>>> Yes, this is a JDT formatting issue. We just invoke the formatter
>>> with whatever options are applicable for the project or workspace.
>>> It shouldn't change a Javadoc comment into a non-Javadoc one
>>> though. That sounds like a bug...
>>>
>> The problem is, that the wrong formatting happens only, when invoked
>> during the code generator. Activating the code formatter within an
>> java editor or via the package explorer ends does not suppress the
>> jdoc star. So I assume the problem is not located within JDT only ?!
>> Could you guide me to the point, where the code formatter is invoked,
>> so that I may try to locate the issue reason?
>>
>> Sven
--------------010301060600050806070804
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Ed Merks wrote:
<blockquote cite="mid:gf9bic$68j$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
Sven,<br>
<br>
In AbstractGeneratorAdapter.generateJava you'll find <br>
<br>
// Create a code formatter for this compilation unit, if
needed.<br>
//<br>
Object codeFormatter =
getGenerator().getOptions().codeFormatting ?<br>
createCodeFormatter(getGenerator().getOptions().codeFormatte rOptions,
targetFile) : null;<br>
<br>
and then later in that method, you'll see it gets called:<br>
<br>
newContents =
formatCode(jMerger.getTargetCompilationUnitContents(), codeFormatter);<br>
<br>
It will be good to see where the "*" goes missing...<br>
</blockquote>
<br>
Hi Ed,<br>
<br>
I guess, I found the location, but I'm not able to fix the issue. JDT
interprets the code style property
"org.eclipse.jdt.core.formatter.comment.format_header" twice: one to
determine if the header (text before "package" line) shall be formatted
and second determining if javadoc comment or block comment is to apply.
I have now glue why it behaves different when invoked from JDT and when
invoked from EMF. I can only guess that its due to in memory parsing
vs. file parsing. So I turned the header formatting of as workaround
for me.<br>
<br>
The decision how to generate is made within
org.eclipse.jdt.internal.formatter.Scribe.includesJavadocCom ments() and
executed at: org.eclipse.jdt.internal.formatter.Scribe line 1873.<br>
<br>
Sven<br>
<blockquote cite="mid:gf9bic$68j$1@build.eclipse.org" type="cite"><br>
<br>
Sven Krause wrote:
<blockquote cite="mid:gf9a2a$83q$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
Ed Merks wrote:
<blockquote cite="mid:gf9604$2j2$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
Sven,<br>
<br>
Yes, this is a JDT formatting issue. We just invoke the formatter with
whatever options are applicable for the project or workspace. It
shouldn't change a Javadoc comment into a non-Javadoc one though. That
sounds like a bug...<br>
<br>
</blockquote>
The problem is, that the wrong formatting happens only, when invoked
during the code generator. Activating the code formatter within an java
editor or via the package explorer ends does not suppress the jdoc
star. So I assume the problem is not located within JDT only ?! Could
you guide me to the point, where the code formatter is invoked, so that
I may try to locate the issue reason?<br>
<br>
Sven<br>
</blockquote>
</blockquote>
<br>
</body>
</html>
--------------010301060600050806070804--
|
|
|
| Re: code formatting problem [message #424955 is a reply to message #424945] |
Tue, 11 November 2008 15:52 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------020906060402040809060200
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sven,
Maybe you should open a bugzilla with details to reproduce the problem,
e.g., a small project with the formatter settings that lead to a
problem. Then I can investigate and transfer it to JDT if necessary.
Sven Krause wrote:
> Ed Merks wrote:
>> Sven,
>>
>> In AbstractGeneratorAdapter.generateJava you'll find
>>
>> // Create a code formatter for this compilation unit, if
>> needed.
>> //
>> Object codeFormatter =
>> getGenerator().getOptions().codeFormatting ?
>>
>> createCodeFormatter(getGenerator().getOptions().codeFormatte rOptions,
>> targetFile) : null;
>>
>> and then later in that method, you'll see it gets called:
>>
>> newContents =
>> formatCode(jMerger.getTargetCompilationUnitContents(), codeFormatter);
>>
>> It will be good to see where the "*" goes missing...
>
> Hi Ed,
>
> I guess, I found the location, but I'm not able to fix the issue. JDT
> interprets the code style property
> "org.eclipse.jdt.core.formatter.comment.format_header" twice: one to
> determine if the header (text before "package" line) shall be
> formatted and second determining if javadoc comment or block comment
> is to apply. I have now glue why it behaves different when invoked
> from JDT and when invoked from EMF. I can only guess that its due to
> in memory parsing vs. file parsing. So I turned the header formatting
> of as workaround for me.
>
> The decision how to generate is made within
> org.eclipse.jdt.internal.formatter.Scribe.includesJavadocCom ments()
> and executed at: org.eclipse.jdt.internal.formatter.Scribe line 1873.
>
> Sven
>>
>>
>> Sven Krause wrote:
>>> Ed Merks wrote:
>>>> Sven,
>>>>
>>>> Yes, this is a JDT formatting issue. We just invoke the formatter
>>>> with whatever options are applicable for the project or workspace.
>>>> It shouldn't change a Javadoc comment into a non-Javadoc one
>>>> though. That sounds like a bug...
>>>>
>>> The problem is, that the wrong formatting happens only, when invoked
>>> during the code generator. Activating the code formatter within an
>>> java editor or via the package explorer ends does not suppress the
>>> jdoc star. So I assume the problem is not located within JDT only
>>> ?! Could you guide me to the point, where the code formatter is
>>> invoked, so that I may try to locate the issue reason?
>>>
>>> Sven
>
--------------020906060402040809060200
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Sven,<br>
<br>
Maybe you should open a bugzilla with details to reproduce the problem,
e.g., a small project with the formatter settings that lead to a
problem. Then I can investigate and transfer it to JDT if necessary.<br>
<br>
<br>
Sven Krause wrote:
<blockquote cite="mid:gfc2mq$t87$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
Ed Merks wrote:
<blockquote cite="mid:gf9bic$68j$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
Sven,<br>
<br>
In AbstractGeneratorAdapter.generateJava you'll find <br>
<br>
// Create a code formatter for this compilation unit, if
needed.<br>
//<br>
Object codeFormatter =
getGenerator().getOptions().codeFormatting ?<br>
createCodeFormatter(getGenerator().getOptions().codeFormatte rOptions,
targetFile) : null;<br>
<br>
and then later in that method, you'll see it gets called:<br>
<br>
newContents =
formatCode(jMerger.getTargetCompilationUnitContents(), codeFormatter);<br>
<br>
It will be good to see where the "*" goes missing...<br>
</blockquote>
<br>
Hi Ed,<br>
<br>
I guess, I found the location, but I'm not able to fix the issue. JDT
interprets the code style property
"org.eclipse.jdt.core.formatter.comment.format_header" twice: one to
determine if the header (text before "package" line) shall be formatted
and second determining if javadoc comment or block comment is to apply.
I have now glue why it behaves different when invoked from JDT and when
invoked from EMF. I can only guess that its due to in memory parsing
vs. file parsing. So I turned the header formatting of as workaround
for me.<br>
<br>
The decision how to generate is made within
org.eclipse.jdt.internal.formatter.Scribe.includesJavadocCom ments() and
executed at: org.eclipse.jdt.internal.formatter.Scribe line 1873.<br>
<br>
Sven<br>
<blockquote cite="mid:gf9bic$68j$1@build.eclipse.org" type="cite"><br>
<br>
Sven Krause wrote:
<blockquote cite="mid:gf9a2a$83q$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
Ed Merks wrote:
<blockquote cite="mid:gf9604$2j2$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
Sven,<br>
<br>
Yes, this is a JDT formatting issue. We just invoke the formatter with
whatever options are applicable for the project or workspace. It
shouldn't change a Javadoc comment into a non-Javadoc one though. That
sounds like a bug...<br>
<br>
</blockquote>
The problem is, that the wrong formatting happens only, when invoked
during the code generator. Activating the code formatter within an java
editor or via the package explorer ends does not suppress the jdoc
star. So I assume the problem is not located within JDT only ?! Could
you guide me to the point, where the code formatter is invoked, so that
I may try to locate the issue reason?<br>
<br>
Sven<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</body>
</html>
--------------020906060402040809060200--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Sat Apr 20 00:22:25 GMT 2024
Powered by FUDForum. Page generated in 0.03599 seconds |
] 
Search
Help
Register
Login
Home
