Thank you Jesse!

This issue blocks our P1-regression - I have to update priority...

2a - in this case Run in Debugger, Step Into & Run to Cursor actions
should be disabled - they have no context for debugging.

2b - there are several solutions for this usecase:
1. Run to Cursor Action can be disabled in this case.
2. We can pup up some dialog with info. that user tries to debug
project which is not current.
3. Just start debugging.

I prefer 2.

BTW. I do not understand why this usecase can not be detected, if
there is getMainProject property.

In my opinion we need getMainProject () method for Attach to VM too.
Run in Debugger starts debugging for some concrete project (Main
Project). And Attach should be consistent with this UI concept.
Otherwise there can occurre some duplicity problems (= two files for
one class name). This can block debugging of JSPs for example - they
use one index.jsp class for all applications.

Other example. If some external provider would like to integrate
profiler to new build system, she need this method too. Main project
should be some intergation point for module writers, I think.

I fully support the idea that projects api should be as small as
possible, but I think that we should not hide such important UI concept.

Re. 2b: I doubt you can detect this because there is no reliable way
to tell whether a given source file is going to be loaded by a given
(main) project. If you knew the execution classpath for the main
project (currently not possible), you could use SFBQ and see if the
source file is on it, I suppose.



Please be more specific about what you need for Attach to VM to work
correctly. Give a concrete example for each use case of what you would
like the debugger to do and why the current APIs do not let you. (Are
you saying that the debugger does not know which index.jsp it is
debugging? If so, surely the debugger is going to make a lot of
mistakes.) May be better to open a separate issue for A.t.VM unless
the usage is really analogous to S.I. and R.t.C., which seems doubtful.

Petr has suggested that rather than exposing the main project as such,
we could expose a factory for creating main-project-sensitive actions.
For example, you could provide enablement logic and a performer for
R.t.C. and get an Action back; in pseudocode:

  boolean enable(Project mainProject) {
    return debuggerAlreadyRunning ||
        hasActionProviderWithCommand(mainProject, "debug");
  }
  void perform(Project mainProject) {
      if (!debuggerAlreadyRunning) {
          runCommandInActionProvider(mainProject, "debug");
      }
      setTemporaryBreakpoint();
      continue();
  }

However this hardly does a good job of abstracting from the main
project UI, so while it may certainly be useful I am not sure it is a
replacement for a getMainProject method.

2b: Aha - I understand. I have not realized that I can not get
classpath or sourcepath directly from project. Thats pity! 
OK. But I can start debugging and detect this situation later.

Attach to VM:
Its simple. Debugger needs some sourcepath / classpath. And if
debugger is started from Attach to VM, it need sourcepath too. One
solution is to use some global one. But this is not correct. We should
use sourcepath defined by Main Project.
Solution:
1) we can add some ~ Project.getClassPath. And I will start debugging
in attach mode manually.
2) we can rewrite Atach to VM action to some ""main project
sensitive"" and create a new ant task for attaching - with some
parameters, something like:
AttachToVMAction extends ProjectSensitiveAction {
  void perform(Project mainProject) {
      Lookup l = new AttachDialog ();
      // l contains params for attach action like port number,
transport, host
      actionProvider = mainProject.lookup (ActionProvider.class);
      actionPrivider.invokeAction ("connect", l);
  }


I think that both solutions (exposing getMainProject, and providing
some main project sensitive actions) are OK for debugger.

I'm still not convinced you need anything other than the global source
path for A.t.VM. If the user started the process themselves anyway,
how do you know what application they started? Could be anything.
Might be the main project as such (if they just lacked a way to start
it from an Ant script for whatever reason), might be some other
project with a main() method, might be some tests, might be something
else entirely that somehow uses some code you are working on. You have
no way of knowing what it is they're running, really.

You can use the runtime code source from the target VM and find out
exactly which classes they are loading; if they are on the local
machine and are direct build products of some project (open or not),
and have not been copied to some other location, you can find the
right sources. Up to you whether you consider this technique usable;
it does seem to work (acc. to David K.) but performance might not be
great, at least in its current untuned state.

If you use the global source path, that should work fine in most cases
where the debugged process does in fact somehow correspond to the main
project, under the assumption that the subprojects are open (they are
by default); could fail in border cases where other open projects have
different versions of classes you are debugging. (Of course this and
many other things also failed in NB 3.x so it is not a regression.)

Summary from my perspective: for A.t.VM you are basically guessing
what the user is working with; getting a source path from the main
project (assuming this were possible - currently not) would give you
one guess; using the global source path would give you another guess.
The global source path is probably going to as accurate in most cases,
more accurate in some cases, less accurate in some cases.

One important consideration (IMHO) is that A.t.VM is the *only* way
you can debug things which are not fully covered by the project
system, and it is valuable to keep this ability. If Start in Debugger
does not fit your needs for whatever reason, you can always make sure
that the sources you want to work with are open - somehow - start the
process manually however is appropriate, and connect to it. While you
*could* make a main-project-sensitive action for A.t.VM, it would be
senseless, since Start in Debugger already covers this functionality
in a better way (typically with <jpdastart>); the whole point of
A.t.VM is that the project type you are working with does not already
provide a usable way to launch the process and attach the debugger to
it, so you want to start it some other way (maybe in a complex server
container, etc.) and attach to the VM once it is running.

You can also use the <jpdaconnect> Ant task to connect to a remote VM
using an explicit sourcepath and begin debugging, even if you have no
projects at all (much less a main project). This lets power users set
up Ant scripts to control launching of the debugger exactly the way
they want it, regardless of what functionality our project types provide.

The minimalistic API for creating project sensitive and main project
sensitive action was added into projectuiapi module. The debuuger
should test whether this API is enough to implement all the dedired
actions

closing