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.
This would be really, really useful for people using the NB Platform. Make an AU center that contains _all_ the modules in CVS. That way, if I want to build something on the platform, and use, say XML support, I can download the platform, connect to AU, and pull in the XML modules and anything they depend on, in order to create the basis for my module suite.
Agreed, this is needed for new apisupport. And we ought to do it retroactively for the NB 4.1 AU center, and in the future for all new releases.
*** Issue 60402 has been marked as a duplicate of this issue. ***
For 4.2 release this is probably already accomplished by Development Update Center. For 4.1 release I have NBM package from original FCS build, which could be published on Update Center within a few hours. The only obstacles in the route are of organizational sort. To publish those module, I need to know: - which Update Center will carry those modules (or i.e. create new Update Center) - folder structure and location of respective NBMs
The Dev AU does indeed seem to have everything. (There is apparently no download for the Dev Platform, so it is hard to confirm that it works.) Re. which AU center to use for 4.1 - I presume the IDE modules can simply be placed on the regular "stable" AU center, since they should be harmless (invisible) for IDE users. Obviously it would need to be tested to make sure we don't accidentally screw anyone up. Re. file locations and so on for 4.1 - I guess this is at the discretion of the AU maintainer. Aren't there some conventions here?
> The Dev AU does indeed seem to have everything. (There is apparently no download > for the Dev Platform, so it is hard to confirm that it works.) Ruda, any particular reason why Dev builds of the Platform are not being published.
Jesse & Jan, I agree, that Dev Platform downloads are not well visible from the download page, but they're there, you just have to look somewhere else. - Go to <http://www.netbeans.org/downloads/index.html> - scroll down the page to section "NetBeans Platform" - click on "Development Builds of Upcoming Releases" - choose you preferences and click "next" button Another point of view to "No downloads for platform" could be, that Platform product could be w/o Update Centers defined. Update Centers are probably defined as part of NB branding in nbX.Y cluster, which is not present in Platform builds. Re. file location. It's about "module groups" like "Infrastructure" is module group for the Eclipse importer. Someone must tell RE where each NBM belongs, otherwise those NBMs may end up as siblings under root node. This could be eventually acceptable in a number of NBMs < 10.
True, though the list shows e.g. "NetBeans IDE 4.2 daily build 200506221800", which is incorrect. If you actually click "Next" then you see e.g. "NetBeans Plaftorm archive" which is correct (though a typo). But if you click "NetBeans Platform" (link under "Downloads" in left margin), which I think would be the most obvious place to go (since it is visible immediately without scrolling right after you click "Downloads" from the home page), you get only NB 4.1 choices. Re. lack of an AU center defined in the platform binary: yes, this is a problem, and we may need to correct it. Re. module groups: what's wrong with the OpenIDE-Module-Display-Category? Isn't this what the update center is always supposed to use anyway?
Jesse, re. OpenIDE-Module-Display-Category: this manifest key is already used for generating module groups on Development Update Center. The weak point is that sometimes marketing and/or other guys have an opinion to put respective module to show it somewhat differently. Let me reformulate the statement "folder structure and location of respective NBMs". Better statement could be "we have to agree on NBM module group assignment process". If we would agree on reusing information from manifest key OpenIDE-Module-Display-Category, like it's done for Development Update Center, then I'm fine with that. re. typo "NetBeans IDE 4.2 daily build 200506221800" - unfortunately it's not a typo :-(. It's archiutectural limitation of actual production build system and downloads database structure. RE's production build system produces and publishes two products as one build. The database structure allows one record in 'build' table may cover files for several products. The string 'NetBeans IDE 4.2 daily build 200506221800' is being automaticaly put during publishing phase into the 'build' table. What I can influence is that substring " IDE" will stop appearing there. Other options are: a) update download process flow and downloads DB structure, b) finalize productization of NetBeans Platform on RE side by different build schedules for IDE and Platform products and thus different publishing models
Just use OpenIDE-Module-Display-Category unless specifically requested otherwise. (Really I think that changes should *always* be made in OIDE-M-D-C, never only for AU.) The typo I was referring to was "Plaftorm".
I've fixed the typo, reloading page may require forced reload. Re. 4.1 Stable UC, I'll forward this publishing request to appropriate audience
From discussion we had, this upgrade scenario is not planned for 4.1 Platform release. If you want to reopen, change target milestone to "TBD".
Agreed. Not to be supported for 4.1. Need to plan for 4.2.
That's fine, but why change to WONTFIX instead of targeting for 4.2?
Rich, in such a case it would be a promise, which I cannot give (for various reasons). Current combination of component, subcomponent and target milestone doesn't allow me anything else than WONTFIX.
The discussion on dev@apisupport around this issue concluded with the realization that this is pretty necessary for folks to build on the platform. Doesn't setting this to RESOLVED take it off the table completely? What about targeting TBD?
Rich, category nbbuild/update centre content is managed by release engineering and serves just as job queue for changing Update Center Content. After discussing the issue within Sun, I found it goes far behind RE compentency and requires commitment from several teams. Feel free to file new issue against ide module and let it dispatched to folks who care of product planning.
*** Issue 61607 has been marked as a duplicate of this issue. ***