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?
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
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
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
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. ***