Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 319790

Summary:

build.properties warning does not disappear after fixing BREE/buildpath

Product:

[Eclipse Project] PDE

Reporter:

Darin Wright <darin.eclipse>

Component:

Assignee:

Curtis Windatt <curtis.windatt.public>

Status:

VERIFIED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

ankur_sharma, curtis.windatt.public, daniel_megert

Version:

3.7

Flags:

daniel_megert: review+

Target Milestone:

3.7 M6

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
Fix	daniel_megert: review+

Description Darin Wright

2010-07-13 16:44:18 EDT

Steps:

* Open the MANIFEST.MF of a bundle that has a BREE of J2SE-1.4
* Change the BREE to J2SE-1.5
* A warning appears in the build.properties since the build path/compliance settings are still 1.4

"There is no 'jre.compilation.profile' build entry and the project has Java compliance preferences set"

* Modify the build path to use 1.5 (or press the "Update the classpath settings" link in the Manifest editor).

Even after the build path is updated, the warning does not disappear. However, making a whitespace edit in the build.properties file makes the warning go away.

Comment 1 Ankur Sharma

2010-07-14 04:33:52 EDT

The problem won't go until the build is triggered. And unfortunately modifying classpath doesn't triggers the build.

Comment 2 Darin Wright

2010-07-14 09:53:26 EDT

I think a build is triggered, it just doesn't trigger the PDE builder in this case?

Comment 3 Curtis Windatt

2011-02-01 16:54:02 EST

Created attachment 188095 [details]
Fix

Comment 4 Curtis Windatt

2011-02-01 16:58:02 EST

Dani, can you spare a bit of time to review this fix?

The change is simple enough.  If the builder sees that class files have changed (in this case because the classpath was changed) we normally run the manifest and plugin.xml validators.  The fix also runs the build.properties validator.  

I don't know if there is a more limited case we can test for.  Since we only care that the java classpath changed maybe we can check for the .classpath file changing?

Comment 5 Dani Megert

2011-02-02 09:46:58 EST

The fix looks good to me but we should also update the trace message:

... - rebuild manifest files"); //$NON-NLS-1$ //$NON-NLS-2$
==>
... - rebuild manifest and properties files"); //$NON-NLS-1$ //$NON-NLS-2$

Comment 6 Curtis Windatt

2011-02-02 11:45:08 EST

Fixed in HEAD

Comment 7 Curtis Windatt

2011-03-09 14:30:51 EST

Verified in I20110307-2110