This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
[ BUILD # : bb64f2315e89 ] [ JDK VERSION : 1.6.31 ] When I start the IDE with a clean user folder and import the settings from previous version, 7.1 in my case, the Libraries UI is clean. If I starte without importing it, everything is okey.
Created attachment 117827 [details] Log file, since startinf the IDE from the first time, importing the settings and plugins
It is not a problem at importing settings as I was suspecting. The problem lays at libraries itself. I have imported the settings with 201203260401 build (which has libraries listed at Libraries view) and so used the same user folder to start the build 20120404-bb64f2315e89 and the Libraries view is empty.
*** Bug 210758 has been marked as a duplicate of this bug. ***
It has impact at several aspects of the IDE, as far as I can see even the pallets which depends on installed libraries are not created.
*** Bug 210753 has been marked as a duplicate of this bug. ***
Maybe due to abcea64f592c? But a fault there should at worst cause build.properties to be stale. (BTW startup time could perhaps be reduced by removing LibrariesModule and making J2SELibraryTypeProvider.libraryCreated be run in response to an AntLogger session starting. Would avoid doing unnecessary work unless and until an Ant build is run.) b26da80bbf57 could possibly be related, though that should only affect logging of problems after they occur, not actually cause them. Diagnostics requested of users in bug #210753 comment #4 (which stefan79 misinterpreted as a proposed workaround) may still be necessary, unless someone knows how to reproduce this problem from scratch. Also running with -J-Dorg.netbeans.modules.project.libraries.level=FINER may be helpful.
Created attachment 117904 [details] Sample user dir User dir imported using NetBeans 7.2 201203260401, which is working as expected.
Created attachment 117905 [details] Log file running with NetBeans IDE 201204040400 I imported the settings using the build 201203260401 and I can see all the libraries as expected. If I run the build 201204040400 with the same user dir, no libraries is listed. I am attaching here too the log as you requested and I hope you can reproduce it.
OK, I can reproduce on the attached userdir by clearing var/cache/ and running 20120405-6201e63eb175 on it: FINE [org.netbeans.modules.project.libraries.LibrariesStorage]: Cannot load library from file org-netbeans-api-project-libraries/Libraries/junit.xml in Default System, reason: Cannot create library: junit of unknown type: j2se After restarting the IDE everything is fine. So that should be enough to track down the problem.
Committed a hotfix in core-main #e06437c73d59, reverting @OnStart to ModuleInstall.restored. Leaving open to figure out exactly what was wrong with using @OnStart here. Apparently at the time it was run, Lookups.forPath("org-netbeans-api-project-libraries/LibraryTypeProviders").lookupResult(LibraryTypeProvider.class) does not find org-netbeans-api-project-libraries/LibraryTypeProviders/j2se_library_provider.instance.
Created attachment 117907 [details] Diagnostic patch This patch also fixes the problem for standard libraries produced by java.j2seplatform (ServerLibraryTypeProvider in j2eeserver, and presumably ME libraries etc., remain broken) by using @ServiceProvider rather than layer-based registration. This indicates that @OnStart tasks are being run before layer lookup is available.
Created attachment 117908 [details] Possible patch Delays processing of @OnStart until after layers have been loaded, and correspondingly reverts the hotfix in project.libraries.
The patch from comment #12 seems good to me. It makes sense to call @OnStart handlers after layers are loaded.
Integrated into 'main-golden', will be available in build *201204060400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/e06437c73d59 User: Jesse Glick <jglick@netbeans.org> Log: #210716 hotfix: reverting project.libraries portion of abcea64f592c.
The patch in comment #12 would delay initialization of @OnStart modules significantly - the goal was to run it parallel to initialization of OSGi. I am not sure what exactly is happening, but is not this a race condition in project.libraries? If they start to read system file system and it is empty, later they will get a notification about change. project.libraries should be ready for changes. So where is the problem?
(In reply to comment #15) > the goal was to run it parallel to initialization of OSGi. If @OnStart is run before layers are available then there will be plenty of other cases where it is not a replacement for ModuleInstall. > If they start to read system file system and it is empty, > later they will get a notification about change. No, I checked that. LibraryTypeRegistry was already listening to the Lookup.Result. But even if you ignore the L.R, and call Lookups.forPath(...).allInstances() from scratch, the result is empty long after the IDE has started - something in core apparently caches the layerless result and never refreshes it.
You are right, calling the code before layers are ready is dangerous. Accepted as ergonomics#4278d973f335. In case of huge OSGi applications, this code will still run sooner than any BundleActivator.start (invoked from NetigsoFramework.startFramework at the end of ModuleManager.enable). Thus the @OnStart and BundleActivator.start will run in parallel, which will be good.
Integrated into 'main-golden', will be available in build *201204260400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/4278d973f335 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #210716: Accepting Jesse's patch to process @OnStart after layers being ready
v. Build 20120426-967ea4bd79b3