Bug 219696 - Import Plugins with Source overrides compiler settings in build.properties and .settings packaged with source
Summary: Import Plugins with Source overrides compiler settings in build.properties an...
Status: RESOLVED FIXED
Alias: None
Product: PDE
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.4   Edit
Hardware: PC Linux-GTK
: P3 normal (vote)
Target Milestone: 3.4 M6   Edit
Assignee: Curtis Windatt CLA
QA Contact:
URL:
Whiteboard:
Keywords: contributed
Depends on:
Blocks: 194733 217921
  Show dependency tree
 
Reported: 2008-02-20 18:06 EST by Martin Oberhuber CLA
Modified: 2008-03-07 09:34 EST (History)
3 users (show)

See Also:


Attachments
Patch (11.32 KB, patch)
2008-02-25 14:32 EST, Curtis Windatt CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Oberhuber CLA 2008-02-20 18:06:47 EST
I have a project that compiles against J2SE-1.4 Execution Environment with the "assert" keyword enabled. Because the default settings for J2SE-1.4 EE are source compatibility=1.3 and class compatibility=1.2, these settings are overridden in my project:

build.properties:
javacSource = 1.4
javacTarget = 1.4

.settings/org.eclipse.jdt.core.prefs:
org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.4
org.eclipse.jdt.core.compiler.compliance=1.4
org.eclipse.jdt.core.compiler.problem.assertIdentifier=error
org.eclipse.jdt.core.compiler.source=1.4

I would like these settings be available for downstream consumers who import the plugin with source folders out of an SDK. Therefore, build.properties and .settings/ are included in the source build.

The crazy thing is that when I Import the plugin from an SDK with Source Folders, my build.properties and .settings files are retained (as I see from comments in those files), but the settings related to the target platform and compiler compatibility are overridden!

As a result, the imported project does not compiel, because "assert" is not found as a keyword. I found the problem in 3.4M5, though I'm pretty sure it was in 3.3.x already.

For reference, my plugin can be found at
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.tm.rse/tests/org.eclipse.rse.tests/?root=DSDP_Project
Comment 1 Chris Aniszczyk CLA 2008-02-21 10:34:58 EST
Curtis if you have time on your plate, feel free to look at this. If not, I will early next week.

I hear Martin may be a PDE fan, we have to take care of our fans ;)
Comment 2 Curtis Windatt CLA 2008-02-22 11:01:37 EST
I'll try looking at this.  Martin, do can you attach the bundle you are trying to import?  I tried downloading the target management SDK, but the test bundle you linked to isn't in it.
Comment 3 Martin Oberhuber CLA 2008-02-22 11:06:47 EST
The test bundle is in the RSE-tests-3.0M5.zip download: to try out the scenario, you'll need 
    eclipse-SDK-3.0M5-win32.zip
    RSE-SDK-3.0M5.zip
    RSE-tests-3.0M5.zip
RSE downloads are at
http://www.eclipse.org/downloads/download.php?file=/dsdp/tm/downloads/drops/S-3.0M5-200802181400/RSE-SDK-3.0M5.zip
http://www.eclipse.org/downloads/download.php?file=/dsdp/tm/downloads/drops/S-3.0M5-200802181400/RSE-tests-3.0M5.zip
respectively.

Comment 4 Curtis Windatt CLA 2008-02-22 13:16:05 EST
I tracked down where the change is taking place.  When creating the project's classpath the classpath computer sets compliance options.  See ClasspathComputer#setComplianceOptions().  The method clears out any existing options and replaces them with the defaults for the execution environment.

I assume for most cases we want to recreate the options from the ee.  So the solution would be to make a special case where when importing, compliance options are only set if they don't already exist.

Chris, Brian, any ideas?  I can't say I know much about how the classpath should work.
Comment 5 Martin Oberhuber CLA 2008-02-22 13:23:17 EST
Hm... one thing I've been pondering in this respect is whether it would make sense to specify a new execution environment like
   J2SE-1.4-with-assert
then the EE could override the classpath.

I'm not really sure about this "solution", though, and I think I'd agree that in the case where a classpath is already set in the sources that we're importing that should be honored.
Comment 6 Martin Oberhuber CLA 2008-02-22 13:34:28 EST
Since the Eclipse Foundation Search is now a google custom serach, you could this link (which is essentially generated from the current search as well):

http://www.google.com/cse?cx=017941334893793413703%3Asqfrdtd112s&q=jarProcessor&sa=Search

Note that it does not contain too many ads, only on top of the result list. You can use the same for a web search:

http://www.google.com/custom?q=jarProcessor

No links at all in this case, but also not that many controls.

Not really being able to count the matches is the other problem. You'd have to actually perform the search in advance, and parse the results. Maybe the Google APIs allow adding a &something to the URL to support an output format which only returns the approximate number of matches - I don't know.
Comment 7 Curtis Windatt CLA 2008-02-25 14:32:25 EST
Created attachment 90676 [details]
Patch

This patch changes the ClasspathComputer to allow a classpath to be generated without overriding existing compliance settings.
Comment 8 Chris Aniszczyk CLA 2008-03-06 11:31:56 EST
Looking at this now.
Comment 9 Chris Aniszczyk CLA 2008-03-06 14:33:13 EST
Thanks Curtis!

I'm always scared to touch ClasspathComputer but this patch works great in my testing. Hopefully this will please Martin and co
Comment 10 Martin Oberhuber CLA 2008-03-07 07:42:09 EST
Thanks Chris and Curtis! Can you let me know when I can get an I-build to verify?
Comment 11 Chris Aniszczyk CLA 2008-03-07 09:34:26 EST
> 20080307