Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-dev] org.eclipse.jdt.core.compiler.problem.invalidJavadoc=error settings in platform code

Christoph,

Yes, of course if something is missing locally it will default to the global.  As an aside, for Oomph I developed, but never completed, support for managing project-specific preferences such that they are not a complete nightmare to maintain.  I.e., one could specify that a specific project act as a profile for managing the project-specific preference and that these be propagated to other projects automatically when changed.  You would get errors for any preference that is not properly managed.  But it's too much work and likely not enough users to justify the work...

In any case, with regard to these preferences, the global defaults are like this aren't they?

I.e., when I push Restore Defaults, it stays this way, so I think these are the defaults.  If you have them different, did you change it?  Did you maybe record this change as suggested previously?  Or maybe these aren't the global defaults?

The setup could set the global preferences, but note that there are many setups and which would need to set this preference changed from the default and which don't?

So my sense is that would be better to fix the project specific preferences.  The projects that want errors should of course have fixed them all by now.  The projects with errors that should not be errors should either be set to warning (which will 99% for sure be ignored) or to error and then fix all the errors.

Regards,
Ed


On 20.08.2021 05:33, Christoph Läubrich wrote:

forget about my last message, I think in this case it is actually the

org.eclipse.jdt.core.compiler.problem.missingJavadocTagDescription=return_tag

(Missing Tags Description)

and

org.eclipse.jdt.core.compiler.problem.missingJavadocTagsMethodTypeParameters=disabled

(Validate Tag arguments)

that are missing in the prefs and thus taken from the global defaults.

so what should be done here? Should I complete the project local prefs? Or could this be done with adjusting the oompf setup (so I don't need to change 60+ files)? Are these settings "correct" as they obviously hide a lot of mailformed javadoc?


Am 19.08.21 um 09:54 schrieb Ed Merks:

Christoph,

Comments below.

On 19.08.2021 09:03, Christoph Läubrich wrote:
Hi Ed,

I used the oompf setup and regularly do "Search For Updates" and "Perform Setup Tasks" is this the right way to keep up to date?
The latter is more correct.  E.g., it would take into account any changes to the setup that might introduce new requirements that would not be picked up simply by updating existing requirements.

As an example the bundle 'org.eclipse.equinox.p2.artifact.repository' without the change in settings I get an error in ChecksumUtilities:

Description    Resource    Path    Location    Type
Javadoc: Description expected after this reference ChecksumUtilities.java /org.eclipse.equinox.p2.artifact.repository/src/org/eclipse/equinox/internal/p2/artifact/processors/checksum line 39    Java Problem

The quickfix suggest me to configure problem severity where the "Malformed Javadoc comments" are set to "Error", if i turn this into "warning" the marker change to warning, so I assume this is the relevant setting here.

That's strange though because I don't see errors for that file at that line:


And the project specific preferences say this:

While the global ones say this:

If I recall correctly if for any specific preference it's not present in the *.prefs, that one will default to the global one.

Nothing here appears to validate the @param nor to care that there is a missing comment even if it did...

Regards,
Ed


Maybe there needs something to be configured on the preferences as well?


Am 19.08.21 um 07:32 schrieb Ed Merks:
Christoph,

I have the entire SDK in a workspace without errors:

This is of course using the Oomph setups for these projects.

https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning

Perhaps you're doing something differently from others?  What's an example of an error that you see?

If I break some Javadoc in a project with this set to error, it does result in an error:


Regards,
Ed


On 18.08.2021 19:28, Christoph Läubrich wrote:
One thing I always wonder, most projects in platform use a project specific setting

org.eclipse.jdt.core.compiler.problem.invalidJavadoc=error

but with this settings enabled there are hundreds of errors and the workspace is nearly unusable.

So my first task is always to change the error to warning to at least get a valid build.

I can understand that one want to have valid javadoc, but enabling this and not fixing the errors seems strange to me. So how is this to be handeled? I really don't like to change/reset settings each time I pull the changes from the repo...
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev

_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev

_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev

_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev

_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev

Back to the top