Community
Participate
Working Groups
JDT added the ability in the batch compiler to specify that some warnings should instead be errors (bug 280784). PDE/Build will add support for specifying errors in the build.properties, support already exists for warnings. If a project has project specific settings for warning/error levels, we should synchronize these to the build.properties file.
Ankur - I arbitrarily assigned this to M3. You can decide if it fits with you M3 or M4 work better.
Adding a new group named 'Compilers' on the Main PDE Pref page. It will contain a new pref "Show problems for synchronizing compiler settings in build.properties." (need help with the text) When enabled the build.properties will get problems when the javacWarning and javacErrors entries for all libs does not reflect correct values. Correct values means whereever the compiler flag value is not matching default value for that warning/err option. However, am not sure if there is a compiler flag corresponding to each warning option.
1) Do we need a preference for this? Is someone specifically requesting it? 2) If we have to add another preference, can we instead build it into the compilers page? The general PDE pref page already has a lot of independent one-off preferences.
(In reply to comment #3) > 1) Do we need a preference for this? Is someone specifically requesting it? https://bugs.eclipse.org/bugs/show_bug.cgi?id=291559#c3 > 2) If we have to add another preference, can we instead build it into the > compilers page? The general PDE pref page already has a lot of independent > one-off preferences. I wanted the same but the compilers pref page is tabbed one (plugins, schema, features and update sites). I could not match this new pref correctly to any of these tabs. Should I create a new tab?
(In reply to comment #4) > I wanted the same but the compilers pref page is tabbed one (plugins, schema, > features and update sites). I could not match this new pref correctly to any of > these tabs. Should I create a new tab? Under the General twisty on the Plug-ins tab there is already one dealing with build.properties. This setting definitely belongs on that page. A new tab would be good if you are planning on adding other more granular build.properties settings (I thought there was a bug out for this, but I don't see it). If it is only going to be 2 or even 3 settings, another twisty under the plug-ins tab might be more appropriate.
sounds good to me. i will add a new 'Build' section (twisty) on the plugins tab. The build.properties pref will move out from general section and get into this one with the new warning pref (is the pref text ok?). A new tab or not, we can decide whenever we fix Bug #291559.
The two options should probably be General Problems AND Java compiler settings They can be simpler because they'll be under a new twisty/header called "build.properties".
Created attachment 165473 [details] Proposed patch for the compiler This patch lets the compiler use a properties file that contains specific compiler options. With this we can guarantee a 1:1 mapping between JavaCore options and compiler options. This prevents from adding more warning tokens inside the batch compiler command line options.
So here is what I think we are proposing: JDT: Apply Olivier's patch so batch compiler can read pref file (-properties <file>) PDE Build: Support a new build property that get's passed to the batch compiler PDE UI: New configurable build error "Synchronize build.properties with project specific compiler options" Quickfix that would add the (relative?) location of org.eclipse.jdt.core.prefs to the build.properties. What about compliance options? Will the batch compiler read the compliance options from the properties file? Or do we need to specify javacSource, javacTarget, assertIdentifier level and enumIdentifier level? Will the Eclipse compiler die if both javacWarn and -properties are set? If yes, than having both should be an error marker. Would other compilers die if the Eclipse specific -properties argument is passed?
(In reply to comment #9) > JDT: Apply Olivier's patch so batch compiler can read pref file (-properties > <file>) I'll release only if this is done in the end. > What about compliance options? Will the batch compiler read the compliance > options from the properties file? Or do we need to specify javacSource, > javacTarget, assertIdentifier level and enumIdentifier level? The jdt.core pref file contains the project specific compliance, source,... I can filter that file to use only the warnings options. This is easy. > Will the Eclipse compiler die if both javacWarn and -properties are set? If If properties are passed last to the compiler, they win! > yes, than having both should be an error marker. Would other compilers die if > the Eclipse specific -properties argument is passed? No since the compilerarg is "protected" with the Eclipse compiler name. So other compilers simply ignore that argument.
Created attachment 165495 [details] patch to pde.build Here is a proposed change to pde/build. Bundles specify "javacWarnings.projectSettings" in their build.properties javacWarnings.projectSettings=true or javacWarnings.projectSettings=.settings/org.custom.compiler.prefs If the value is "true", we look for ".settings/org.eclipse.jdt.core.prefs", otherwise the value is a relative path to the preference file to use. (This would be for bundles taking advantage of bug 303960) The patch currently adds the -properties argument into the javacCompiler.<library>.args files, which as Olivier mentioned are protected by a compiler adapter property when passed to the javac task. I think it would be good to restrict this to just the warnings rather than other compiler settings. We can revisit the other things in 3.7.
(In reply to comment #11) > Bundles specify "javacWarnings.projectSettings" in their build.properties Note that there is a small problem with this choice of property name, there is also the "javacWarnings.<library>" properties. If we use ".projectSettings" this means nobody can have a library with that name. A library with that name would definitely be an edge case, I kind of doubt anyone does that.
(In reply to comment #11) > I think it would be good to restrict this to just the warnings rather than > other compiler settings. We can revisit the other things in 3.7. PDE UI will then need a way to determine when the property should be added. If the project has any specific java settings, all of them are listed. We don't know if a compiler warning has changed or something else. Also, if there are project specific compliance settings, we set some warning levels as well as other build properties. If the user has modified their compliance settings, should they set javacWarnings or javacWarnings.projectSettings. What if both compliance options and other compiler options were modified?
I will filter the .settings file from jdt.core to make sure it is setting only the warnings options. Patch to follow.
Created attachment 165570 [details] Proposed fix New patch that filters the option to set only the warnings options from the properties file.
(In reply to comment #15) > New patch that filters the option to set only the warnings options from the > properties file. Is there a way that PDE can find out if a java project has modified the warning options? (and not just some other project specific compiler setting)
Not easily. The filtering should not take too long so I would say that if you have a preference file for the jdt.core bundle, it should be used as a potential properties file.
(In reply to comment #17) > Not easily. > The filtering should not take too long so I would say that if you have a > preference file for the jdt.core bundle, it should be used as a potential > properties file. I was assuming that we would just pass in the preference file for jdt.core. It's unfortunate that all PDE UI will be able to do is see that you have some project specific settings set, put up a warning and suggest that the jdt properties file be added to the build.properties. Also, Andrew, do you think we need PMC approval for any of these changes? I don't know whether modifying the set of build properties is an api change.
JDT's behaviour seems to be that it will write out all the compiler warning preferences if any have changed from the default. You could look in the file for a known warning property to see the they are there. As for PMC/API, I'm not really sure, Darin what do you think?
(In reply to comment #19) > As for PMC/API, I'm not really sure, Darin what do you think? I'm not sure if there is a precedence to follow here in the land of PDE build... However, adding a new PDE build property feels like an API change to me. We should likely get API approval for this once we are all happy with the solution.
Created attachment 165606 [details] PDE UI fix Still rough around the edges, but provides build errors and some quick fixes for compliance/compiler options.
I spoke with John (A). He does not consider this an API addition that needs approval. The only place this appears is in the doc for the new property (and most doc work has not been done yet). It's an optional new property and does not involve Java APIs. So, we can proceed.
I released the patch for JDT/Core including doc update in doc.isv.
Created attachment 165630 [details] update pde/build This is the patch I am going to release for PDE/Build. The argument is passed with an ant <compilerarg> element using ${basedir} so that we don't need to worry about absolute paths. Curtis, the property has changed: IBuildPropertiesConstants#PROPERTY_PROJECT_SETTINGS = "javacProjectSettings" In future releases we could potentially use this for other compiler settings. Also, I wanted to avoid the conflict mentioned in comment #12
I have released the pde.build change. If the "javacProjectSettings=true" property is used without the jdt.core changes, then the compilation will fail with the unknown argument. Note for people using custom compiler adapters, this -properties argument will currently be be passed to your compiler adapter if you have "compilerAdapter.useArgFile=true".
I've released the PDE UI fix. The errors/quickfixes need a little more polish.
Almost every project will have two new warnings: * The 'javacProjectSettings' build entry should be set when there are project specific compiler settings * There is no 'javacWarnings..' build entry and the project has Java compliance preferences set build.properties Perhaps these should be 'Ignore' by default? Do we want each Eclipse bundle to be compiled with project specific settings or the same across the SDK?
(In reply to comment #27) > Almost every project will have two new warnings: > * The 'javacProjectSettings' build entry should be set when there are project > specific compiler settings We should set this to ignore by default as many bundles do have warnings when using project specific settings. We don't want to have a lot of bundles with warnings during the build. > * There is no 'javacWarnings..' build entry and the project has Java compliance > preferences set build.properties Not sure I understand this one. > Perhaps these should be 'Ignore' by default? Do we want each Eclipse bundle to > be compiled with project specific settings or the same across the SDK? Each project should always have project specific settings.
(In reply to comment #27) > Almost every project will have two new warnings: > > * The 'javacProjectSettings' build entry should be set when there are project > specific compiler settings I would suggest that if "javacWarnings.<library>" is set, then we don't need to warn about javacProjectSettings because the user presumably has already set the warnings he wants for nightly builds, even if they are different from the project settings.
(In reply to comment #29) > I would suggest that if "javacWarnings.<library>" is set, then we don't need to > warn about javacProjectSettings because the user presumably has already set the > warnings he wants for nightly builds, even if they are different from the > project settings. They are controlled by two different severities on the PDE build preference page. If you have both severities at warning and have java compliance options set, you will get warnings to add both javacWarnings and javacProjectSettings. I think this is reasonable because the severities can be controlled independently.
There seems to be a bug here, I get a problem indicating I should add javacWarnings. when the project compliance settings are default for 1.4. For example, when I check out org.eclipse.debug.core: Description Resource Path Location Type There is no 'javacWarnings..' build entry and the project has Java compliance preferences set build.properties /org.eclipse.debug.core line 1 Plug-in Problem
After switching to N20100421-2000 all my build.properties have TWO warnings: - The 'javacProjectSettings' build entry should be set when there are project specific compiler settings - There is no 'javacWarnings..' build entry and the project has Java compliance preferences set Is this expected?
(In reply to comment #32) > After switching to N20100421-2000 all my build.properties have TWO warnings: > - The 'javacProjectSettings' build entry should be set when there are project > specific compiler settings > - There is no 'javacWarnings..' build entry and the project has Java compliance > preferences set > Is this expected? No. This is being fixed currently.
I have released some changes to HEAD to fix the unecessary compliance warnings, support flexible bundle root, fix bug 310142. I still need to update the text on the pde compilers page, do some more granular checking against compliance default settings, and update the tests. (In reply to comment #32) > After switching to N20100421-2000 all my build.properties have TWO warnings: > - The 'javacProjectSettings' build entry should be set when there are project > specific compiler settings > - There is no 'javacWarnings..' build entry and the project has Java compliance > preferences set > > Is this expected? There will still be a situation where both warnings will be shown. If you have both severities set to warn (default for compiler settings is now IGNORE) and you have custom compliance settings (assert or enum severities are non-default) and custom compiler settings (java project options has a value for a compile problem severity).
Committed the last of my changes to HEAD. Marking as FIXED. Thanks Olivier and Andrew for helping get these last minute changes in.
*** Bug 169740 has been marked as a duplicate of this bug. ***
*** Bug 151966 has been marked as a duplicate of this bug. ***
