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

Bug 184020

Summary:	Removing a non-existent package reference in bundle MF forces rebuild of everything
Product:	[Eclipse Project] JDT	Reporter:	Ritchie Schacher <schacher>
Component:	Core	Assignee:	JDT-Core-Inbox <jdt-core-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	kent_johnson, philippe_mulet
Version:	3.3
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:	stalebug

Description Ritchie Schacher

2007-04-25 10:21:13 EDT

Build ID: I20070209-1006

Steps To Reproduce:
1. I moved stuff out of a package, and deleted the package.  Rebuilt the workspace.

2.  Everything compiled cleanly, but I had an error in the bundle MF containing the package because it did not exist.

3.  Removed the bogus reference, saved the manifest file, and rebuilt.  This bundle was at the bottom of the food chain; the IDE rebuilt every project, and it took a while.


More information:

Comment 1 Jerome Lanneluc

2007-05-04 09:49:17 EDT

Was the error in the Export-Package: section of the MF ? If this is the case, the full rebuild is expected since you removed a package from your bundle, access rules on dependent projects have changed, and only a full build can find out if the code is broken by access rules.

Comment 2 Ritchie Schacher

2007-05-04 10:24:59 EDT

Yes, I believe it was export-package that had the bogus reference.

Comment 3 Jerome Lanneluc

2007-05-04 10:57:40 EDT

Thanks Ritchie. 

Renaming a package would be another scenario where this could happen. Indeed this would also cause the MF to be changed, and access rules on dependent projects to be changed. Thus you would get a full build if you renamed a package.

So it looks like we should consider access rule separately from classpath change.

One idea is to detect access rules that represent a package restriction (they are of the form "org/eclipse/jdt/core/*", i.e. words that are slash separated and ending with a star). Having the package name, we could find out if there is a reference to this package using the build state. Then we could only incrementally build the project if it is affected by the package change.

This is a major change in the Java builder, and we would target this for 3.4.

Kent, what do you think ?

Comment 4 Kent Johnson

2007-05-04 11:02:52 EDT

If there is a way we can tell that the package is empty (no types or subpackages) then we could ignore any add/removes.

Comment 5 Philipe Mulet

2007-05-04 11:23:51 EDT

Wouldn't it cause some potential import reference errors ? Checking for existing dependencies in the build state feels a safer approach.

Looking in the future, we probably want to be more resilient to access rule changes on the buildpath, since they are far more frequent than addition/removal of entries.

Comment 6 Jerome Lanneluc

2008-05-02 07:07:55 EDT

We ran out of time for 3.4

Comment 7 Eclipse Genie

2020-04-30 12:50:55 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.