Community
Participate
Working Groups
3.1 RC1 1. Add a user library 'TEST' with 1 jar 2. Export all preferences 3. New workspace 4. Import the saved preferences Observe: the user library 'TEST' is recreated but it has no jar
While fixing bug 88719, martin said that Import/Export for User Libraries do not use JDT/Core code... => Move to JDT/UI
Martin, can you please comment. I thought user libraries use JDT/Core code ?
There are two different import/exports: - On the user library page you can import/export one or a selection of libraries. This is all jdt.ui and uses a own xml file format - On File -> Export -> Preferences you can export all preferences. In 3.0 this included all user libararies as (jdt.core) persists them in the preference store, similar to the classpath variables. The code that listens to the preference change and updates the internal user library store is all in jdt.core. Jerome, I assume you referred to the second import/export.
Looking at comment 0, it seems correct that it's the second import/export which is used => so I agree it's for me...
I can reproduce it only if Java perspective has not been opened. As soon as, Java perspective is opened, if I redo the import, then user library has its jar correctly set... I guess this is normal behavior as Java model is not initialized until JDT/Core plugin has not been started and so listeners are not activated... OK to close?
But when the Java model finally initializes, wouldn't it read the preferences and get the new library and its JAR?
This is already the case... You do not need to perform import again after having opened Java perspective. Following scenario prove that listener is well activated when Java model starts: 1) Open new workspace (Do not open Java perspective!) 2) In Resources perspective, import preferences with user Library 'TEST' 3) Look at User Library in Java>Build path>User Libraries preferences page => TEST has no jar defined 4) Open Java perspective 5) Look at User Library in Java>Build path>User Libraries preferences page => TEST has 1 jar defined
That still looks like a bug: In step 3, the User library page uses jdt.core functionality (JavaCore.getUserLibraryNames()) to get all the library names. This should activate the jdt.core plugin and return correct result. I suggest to reopen.
ok to reopen. I'll have a look later to see what exactly happen there...
...but post 3.1
My feeling is that this points to a deeper problem with container initialization. The first call seems to return no child entries even if it should.
I have a fix for this bug...
Created attachment 22712 [details] Proposed fix
+1 for RC2
Created attachment 22719 [details] Proposed fix (put back method comment)
Fixed and released in HEAD. Note that implemented patch is only a hack as JavaModelManager does not expect to receive JavaProject which does not have a Java nature. We need to figure out how JDT can handle User Libraries informations more properly than using a dummy project. I'll open bugs to follow-up future work in this area... [jdt-core internal] Change done in JavaModelManager.initializeAllContainers(...) No test case currently added, but all existing ones pass (of course)
I've opened 2 bugs for work about dummy project removal: bug 99208: JDT/Core work to provide API methods to get/store user librairies info bug 99210: JDT/UI work to remove dummy project usage when 99208 will be fixed
Verified in I20050609-1605.
*** Bug 73099 has been marked as a duplicate of this bug. ***
Verified with I20050610-0010
