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.
I have installed NB 4.1 Q-build (200501161900) with Mobility pack. Yesterday (January 17th) I have updated NB through Update Center and now I cannot neither open nor create new J2ME projects
there is no q-build 200501161900. The latest q-build is nb-200501071427 and mob-20050106 both published 10th January at netbeans.org Please, provide more info - -what build of netbeans are you using ? -what build of mobility pack did you installed to this netbeans -what did you updated through UC (what modules) -does the current installation work with clean userdir ? (use --userdir <directory> command line switch) *closing as incomplete
Created attachment 19747 [details] Startup error message
Sorry for incomplete report - I'm using nb-200501071427 and mob-20050106 (latest q-build) - Yesterday I have updated all modules that I found on UC (Development update center). Now IDE says (on caption bar) that its build is 200501161900 - I have installed the modules for all users, but when I run the IDE with clean userdir, there is a warning window, which contents I have attached.
that isn't j2me problem, there's something that caused that some modules are disabled and the functionality is lost(some dependencies?). Because there isn't simply way how to uninstall the modules from IDE the simpliest way for you will be install the nb+mob again because your installation dir is broken now :( Your project should not be affected! You can open them in newly installed IDE again. We are sorry for inconvinience. Please be carefull with update center next time... Reassigning to update center content and cc'ing autoupdate client.
Created attachment 19756 [details] log of all messages after update
cc'ing Honza
Hmm, this is unfortunate, but we're in the middle of the development cycle. There's no guarantee the current content of the Dev update center will be compatible with development builds several weeks old. The log files indicate that some of the modules failed to start due to unsatisfied dependencies on the editor module. There were some structural changes made to the editor modules recently and some of these changes might have introduced incompatibilities with older modules depending on editor. Due to other dependencies on disabled modules, whole module clusters may be disabled. In this case, most of the Web Apps, J2EE and J2ME features have been disabled due to unsatisfied dependencies. Cc'ing Mila, if he sees any way to prevent this particular case from occurring.
Yes, this is probably related to the editor split - issue 51486. As I've discovered that I need to change certain things incompatibly during the split, I had to increase the major module version from org.netbeans.modules.editor/2 to org.netbeans.modules.editor/3. The split was done according to the proposal in the mentioned issue. Not sure what exactly is the problem in this particular issue but generally the module system allows to not depend on a single major version of a module which could resolve the problem here unless the real functional dependency was on one of the extracted mime-types editor supports.
Looks like issue with autoupdate, not nbbuild. I'm sorry in case I'm wrong, so reassign it to correct component or if this belongs to nbbuild clarify plesase what is wrong in nbbuild.
This is not an issue with AutoUpdate. Mila, when you did the editor split, you probably had to update dependencies in modules that declare implementation dependency on editor. Right? It turns out that it is also necessary to increment the spec version numbers in those modules. Without doing so, there is no way for the dependent modules to get published on the Dev update center and become available for auto updating. The result is that the users get the new version of the editor, but they don't get the dependent modules with updated dependencies. Those module then fail to star during IDE startup. Sorry if you were not aware of this rule. However, the problem probably still persists and you're in the best position to fix it, because you know which implementation dependencies you had to update.
Yes, I'll do it ASAP.
I've went through the Editor split issue 51486 and I've increased spec. versions in the following manifest files: properties/manifest-syntax.mf tasklist/version.properties for tasklist/editor/manifest.mf which uses variable tasklist/version.properties for tasklist/javaparser/manifest.mf which uses variable web/jspsyntax/manifest.mf websvc/registry/manifest.mf xml/spec-vers.properties for xml/css/manifest.mf which uses variable; this change also covered xml/text-edit/manifest.mf
Created attachment 20208 [details] Diff of the spec. versions increasing
Fixed in trunk: Checking in properties/syntax/manifest.mf; /cvs/properties/syntax/manifest.mf,v <-- manifest.mf new revision: 1.2; previous revision: 1.1 done Processing log script arguments... More commits to come... Checking in tasklist/version.properties; /cvs/tasklist/version.properties,v <-- version.properties new revision: 1.74; previous revision: 1.73 done Processing log script arguments... More commits to come... Checking in web/jspsyntax/manifest.mf; /cvs/web/jspsyntax/manifest.mf,v <-- manifest.mf new revision: 1.27; previous revision: 1.26 done Processing log script arguments... More commits to come... Checking in websvc/registry/manifest.mf; /cvs/websvc/registry/manifest.mf,v <-- manifest.mf new revision: 1.5; previous revision: 1.4 done Processing log script arguments... More commits to come... Checking in xml/spec-vers.properties; /cvs/xml/spec-vers.properties,v <-- spec-vers.properties new revision: 1.31; previous revision: 1.30 done
Verified.