Re: projects ui recommendations

 > the working assumption when we decided to move resources and output to 
 > the customizer is that having the information around persistently in the 
 > explorer doesn't add much value for the amount of additional clutter it 
 > adds to the explorer. having the ability to drag and drop outputs from 
 > one project into the resources of another is a useful thing but even 
 > with very interconnected projects this activities is limited in 
 > frequency. as with most setup activities they aren't likely to be an 
 > ongoing, many time a day task (the kinds of things where drag and drop 
 > offer the most in user aid).

Hmm...perhaps not for Netbeans, but again, I think that, in S1S,
because of the way we map J2EE artifacts (including web modules) to NB
Projects and J2EE references to resource/output relationships,
visualizing these relationships might be rather more important than in
the NB IDE itself. Moreover, as I think Svata is getting at, there is
a visualization component here as well. When editing complex J2EE
applications -- or even just a complex web application --
understanding context in a top-down way at a glance is going to be a
big help to figuring out which artifacts relate to which other
artifacts. By their nature it is easier to get lost in a complex
distributed application spread over multiple projects than in a single
web or Java project.

However I can understand the desire to not try to solve too many
problems with the same view. A separate "dependency viewer tab could
work out fine, as long as the use cases are addressed in a way that
will make sense to the user. You suggest that coming up with a
dependency viewer might be an SE ("the edition formerly known as EE")
issue to deal with. This is possible, but is implicitly a shift
between the two versions of the UI specification -- in the previous
version we had regarded dependency visualization as the province of
the Explorer. I think we can agree that what would be worst is to have
two incompatible dependency visualization solutions: even without EJB
modules applications built with Netbeans using the web module can
easily have complex library dependencies, so I'm not sure this is
really an SE-only issue.

 > to address the ee issue it should be possible (though i don't know if it 
 > makes sense to do so) to have many of the inter dependencies setup via a 
 > template.

I don't think templates will work here, since interdependencies will
be added as projects develop, just as they do in the course of
netbeans module development.

 > >- I confess I've never been crazy about the idea of an active
 > >  project. For SE the "product" corresponding (at least in our current
 > >  discussions) to the project group that holds the component projects
 > >  (web module, ejb module, etc.) is, I think, to the user the "active
 > >  project". For example if Netbeans itself were implemented with the
 > >  project system, each module would presumably be a Netbeans project
 > >  -- yet I would consider that I'm working on the "Sequoia project",
 > >  not the "jwd project".
 > >
 > >  This was one of the reasons I suggested earlier that there be a
 > >  versionable scope that holds projects together that is a top-level
 > >  singleton in the IDE...not necessary an outer project, but something
 > >  like a Visual Studio "Solution", WebSphere "Enterprise Application"
 > >  or WebLogic Workship "Application". Forcing this outer scope would
 > >  make adding new projects to the group much cleaner, I think, and I
 > >  don't think this would take away any functionality, though some
 > >  tasks would necessarily be accomplished differently.
 > >
 > 
 > your objection to the concept of active project seems more a disguised 
 > request for a vs 'Solution' like feature.

My goal is to raise the visibility of the required use cases to
determine if the suggested solution -- using project groups -- can
adaquately address the use cases, and if not, see if there is a middle
ground that can be reached which doesn't invent something wholly new
but that is sufficient for this release cycle. I believe that project
groups can address some of the most important issues -- having a file
I can open and close that represents a consistent set of projects from
a versioned base, for example -- but I have lingering concerns about
usability. The main issue to my mind is the amount of rope we give
users.  As currently proposed project groups can be used well or
badly. For example user A can just as easily create projects whose
dependencies go outside their group as inside. In this case user B has
a tougher time tracking everything down and assuring themself that
they have a the same set of projects open as user A. I believe it is
worthwhile to impose a few constraints on project groups to make
harder to use them badly.

I guess this boils down to a "negative use case": things I shouldn't
do should be possible, but not as easy as the "right" thing.

 > that being so, there is 
 > still a need for an 'Active' project as a mechanism to run the desired 
 > project when working on several at a time. i think one part of your 
 > concern is the term active bcs it doesn't have an obvious sense for the 
 > user (active typically being the thing currently being worked on). we've 
 > recognized this and have come up with several other suggestions -i think 
 > the current term edging toward the front is 'Startup Project'. this 
 > certainly has more sense in the project group use as well as being more 
 > distinguishable as a special state than the 'Active Project' moniker 
 > conveyed.

Yes, this is more clear. "Active" suggested "selected" to me, which,
if it really worked that way, could get really confusing if people
said "Execute" and the system derived "active project" from the UI
focus. "Startup project" sounds better, though I suspect some users
will think that this is a project that get executed when the IDE
"starts up".

Thanks for the clarification,

Peter