Bug 91131 - Project dependencies are not resolved properly on CVS checkout in Eclispe 3.1
Summary: Project dependencies are not resolved properly on CVS checkout in Eclispe 3.1
Status: RESOLVED FIXED
Alias: None
Product: AJDT
Classification: Tools
Component: UI (show other bugs)
Version: 1.2.0 M2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 1.3.0   Edit
Assignee: Helen Beeken CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 73435
Blocks:
  Show dependency tree
 
Reported: 2005-04-12 10:09 EDT by Sian January CLA
Modified: 2005-08-03 11:42 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sian January CLA 2005-04-12 10:09:40 EDT
When two projects, one with a dependency on the other are checked out from CVS 
AJDT needs to ensure that the dependencies are resolved properly and the 
projects build successfuly.  This support is broken on Eclipse 3.1.  To 
reproduce check out the org.eclipse.contributions.visualiser and 
org.eclispe.contributions.visualiser.tests projects from the AJDT project and 
rebuild the Visualiser project by clicking the build button.
Comment 1 Helen Beeken CLA 2005-04-12 11:02:52 EDT
This was the workaround for bug 73435. In it, we get the preferences using:

    JavaProject jp = (JavaProject)JavaCore.create(dependingProject);
    String[] names = jp.getPreferences().propertyNames();

In 3.1 M6, the call "jp.getPreferences()" is deprecated and doesn't actually 
do anything. Instead, you're advised to use the new API. 

Since this is just a workaround, and should be fixed properly by bug 73435 
(which is all to do with creating a meaningfull state.dat file) I'm therefore 
marking this as depends on bug 73435 rather than splitting the code and 
providign another workaround for M6 - the release notes mention this 
limitation.
Comment 2 Helen Beeken CLA 2005-08-02 04:34:02 EDT
I'm unable to reproduce this bug with the latest AJDT and Eclipse 3.1 final.
This is because there is a check:

  String[] names = jp.getPreferences().propertyNames();
  if (names.length == 0 && !setWorkbenchPref) {
        // change the setting....
  }...

that is executed on Eclipse 3.1 since names.length == 0 that consequently
changes the settings.

Now we have split the codebase though, there is the issue of the deprecated API
which specifically advises you to address it as it will be removed soon.
Therefore, I will use this bug to track that. 

If you see the problem again, please mention it in this bug.

Thanks, Helen
Comment 3 Helen Beeken CLA 2005-08-02 05:53:54 EDT
The failing scenario is as follows:

- AJ project using workspace settings
- Java project (depending on AJ project) using project settings
- workspace settings = don't abort if there are classpath problems
- java projects project settings = abort if there are classpath problems

At this point the java project has the failure message "cannot rebuild until
prerequisite project has been built" (as expected). Building the AJ project by
pressing the build button does not fix this. In other words, it doesn't change
the  java projects project settings. This works on Eclipse 3.0 because if the
java project is using project settings then 

  jp.getPreferences().propertyNames().length > 0, 

whereas if it's using workspace settings then 

  jp.getPreferences().propertyNames().length == 0.

In the case of 3.1, due to the use of the deprecated API, we always get 

  jp.getPreferences().propertyNames().length == 0

and so the project specific setting is never updated.
Comment 4 Helen Beeken CLA 2005-08-03 11:42:21 EDT
The fix was to use IEclipsePreferences instead - see
AJBuilder.udpateJavaCompilerPreferences(..) for fix and "Project Dependencies
Script.txt" for the updated manual test (has to be manual because involves
checking out projects from CVS.

The fix has been integrated and can be found in build:

BUILD COMPLETE -  build.34
Date of build: 08/03/2005 15:06:22
Time to build: 25 minutes 40 seconds
Last changed: 08/03/2005 14:39:09