Re: debugging w/o projects [was: File menu gone ?]
Ivan Soleimanipour <[email protected]> Mon, 12 May 2003 14:49:17 -0700 (PDT)
| Newsgroups | gmane.comp.java.netbeans.modules.projects.devel |
|---|---|
| Message-ID | <[email protected]> |
> >> > >>>This is related to the File issue in the sense that editing files > >>>isn't the only thing that one might want to do outside of the world of > >>>projects. Maybe one conclusion from this might be that debuggercore > >>>should be able to be configured so it worls if there are no projects? > >>> > Do you mean no projects module, or no opened project instance? I mean w/o projects module. > > > > >But you want build "components" that are _less_ coupled, not > >_more_ entangled. > > > >I still maintain that the debugger should define a "bag" of stuff > >that projects keeps for it. The projects framework should > >not have to know what's in that bag. The debugger should > >be able to work with a given bag w/o access to a project. > > > > I do not want to duplicate all stuff with project logis and storing of > project properties. Its HARD task for me. I understand your proposal, > but I think that some dummy project will be easier to implement. > I'm aiming this more at project designers not debuggercore. A project target needs to be able to specify arbitrary settings aand store arbitrary state for an arbitrary number of tools. It cannot do this by having intimate knowledge of every tool. _Some_ black-boxing is neccessary. So I imagine that there is a scheme that allows each tool to delclare what sort of state it want to save or be associate with what element of projevt (whole project, target and so on). This would be a in a form of a "contract" from the projects module which says, "if you want this and that state saved or kept track of, put it in such a kind of data structure and register it thusly". As you switch projects these settings will be multiplexed between tools. In effect I"m suggesting that projects API shuld have two parts, a "contract" like the above and the rest of the project machinery. debuggercore, or any other "tool" will have to compile and link in with the "contract" but it should work even if the project machinery isn't there. If you can succeed in this then it means you have better designed projects system based on loose coupling.