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.

Bug 75155 - "C/C++ Native Developement" module has hardcoded manifest
Summary: "C/C++ Native Developement" module has hardcoded manifest
Status: VERIFIED FIXED
Alias: None
Product: cnd
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: _ gordonp
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-18 13:50 UTC by Vladimir Voskresensky
Modified: 2007-11-06 22:06 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Voskresensky 2006-04-18 13:50:37 UTC 
manifest for "C/C++ Native Developement" module is not generated by NB's build
harness, it's hardcoded. This cause some maintaince problems, i.e. after update
Properties->Libraries dependencies module could fail on startup, because
manifest doens't contain new dependency. Module "C/C++ Native Developement"
should be updated to be "fair" NB5 Module Project
Comment 1 _ gordonp 2006-08-11 01:27:20 UTC 
I'll look into it. But it may need to stay that way if there is no
other way of ordering DataLoaders.

DataLoader ordering is needed because of issues like:

    o Need to recognise Makefile.c (or cc or h) as a C/C++ file
      rather than as a Makefile
    o Makefile could also be an executable, so we check if its an executable
      before checking if its data for "make"
Comment 2 Vladimir Voskresensky 2006-08-11 08:25:57 UTC 
I agree about importance of loaders sequence.
But at least the following should be autogenerated
OpenIDE-Module-Module-Dependencies: org.netbeans.modules.editor/3 > 1.26.1.1, 
    org.netbeans.modules.editor.fold/1 > 1.5.1, 
    org.netbeans.modules.editor.lib/1 > 1.9.1.1, 
    org.openide.actions > 6.5.1, 
    org.openide.awt > 6.7.1, 
    org.openide.dialogs > 6.5.1, 
    org.openide.execution > 1.8.1, 
    org.openide.explorer > 6.5.1, 
    org.openide.filesystems > 6.4.1, 
    org.openide.io > 1.9.1, 
    org.openide.loaders > 5.9.1, 
    org.openide.modules > 6.5.1, 
    org.openide.nodes > 6.7.1, 
    org.openide.options > 6.4.1, 
    org.openide.src > 1.8.1, 
    org.openide.text > 6.9.1, 
    org.openide.util > 6.8.1, 
    org.openide.windows > 6.5.1
OpenIDE-Module-Public-Packages: org.netbeans.modules.cnd.**

And following is obsolete:
Name: org/netbeans/modules/cnd/loaders/HDataLoader.class
OpenIDE-Module-Class: Loader
Install-After: com.sun.forte.developer.ipe.loaders.VisuSrcObject

Name: org/netbeans/modules/cnd/loaders/CCFSrcLoader.class
OpenIDE-Module-Class: Loader
Install-After: com.sun.forte.developer.ipe.loaders.VisuSrcObject
Comment 3 _ gordonp 2006-08-11 15:21:49 UTC 
We're agreed about the dependencies (they should not be specified).

As for the X-Designer loader dependencies, its not black-and-white.
The best solution is probably to move them to the xdplugin module
rather than leave them hear. Back when I wrote the original cpp module,
loader dependencies in netbeans didn't work well and I only got them
to work with all loader dependencies in a single module.

That may have changed by now (netbeans is *much* more reliable today:-)
and most likely this is no longer necessary. But Sun Studio IDE will
still need the dependency (as will the xdplugin module which should be
public sourced), so it will need to be in some module.
Comment 4 _ gordonp 2007-02-06 16:06:25 UTC 
Raising priority. This will make mergine releaes551 changes to the trunk
easier.
Comment 5 _ gordonp 2007-02-08 00:37:43 UTC 
Fixed for cnd core and qnavigator.
Comment 6 _ gordonp 2007-02-08 00:40:22 UTC 
Fixed for cnd core and qnavigator.
Comment 7 _ gordonp 2007-11-06 22:06:39 UTC 
Verified