Would permit project types to easily show a
standard GUI for using configurations (run
profiles and the like).
See issue #49636.
I would like to submit the new API for review. See the linked-to proposal for
Created attachment 31097 [details]
MK1: Is the active configuration meant to be persisted across IDE sessions?
MK2: Is it meant to be shareable or on per-user basis?
MK3: getActiveConfiguration() is meant to always return a profile. What happens
to the case (in j2se project) with the default values for Run project in project
customizer? are these supposed to be turned into a profile? Will the Run project
UI then act as editor for this default profile?
more general notes:
MK4: it seems to be fairly generic and I don't see a problem in implementing the
API in non-standard project types (eg. in maven), however I'd like to point out
that the major usecase seems to be "run project" profiles and with the given API
it's probably the only possible usecase. -> there's only one instance of
provider in lookup and only one profile can be the active one at a time. I think
this fact should be communicated to the project type providers to keep the UI
consistent across the IDE.
(by stating that in the documentation or by renaming the interfaces)
Re. MK1 & MK2: yes, the choice of configuration is persisted per-user, in
nbproject/private/config.properties. The definition of the configurations can
mix sharable and per-user settings. See the URL for details on format.
Re. MK3: a j2seproject always has a <default> null profile. See the URL for details.
Re. MK4: yes, only one configuration can be active per project (at least as far
as this SPI is concerned). This does not necessarily restrict configurations to
being used only for run settings, though it does discourage orthogonal mixing of
configuration types since only kind of configuration can be selected using the
global UI. Java ME projects already use configurations to control both build and
run settings at once (not to mention the editor's appearance, etc.). See the URL
for details and discussion. Could you explain more how you would expect the
documentation to be changed to make this clear, or what is wrong with the
current interface names in this regard? Also, what (if anything) would you
consider using the SPI for in Maven projects?
Ok, sorry I have not to read the doc you referenced. I've learned to ignore
anything above the comments section (a bad habit of mine)
here is the URL: http://projects.netbeans.org/nonav/buildsys/configurations.html
Re documentation: the design document should be referenced from the javadoc for
ConfirationProvider or from the changes document.
The setActiveConfiguration() method should point out the expected level of
The interfaces rename idea can be disregarded. I thought the configs are to be
used exclusively for run profiling.
re MK4 maven - maven (at least the 2.x series) has the orthogonal profiles
implemented. These profiles can bound to OS, JDK, System properties etc. or
explicitly triggered. They can influence any part of the build lifecycle, adding
build steps, adding dependencies etc. That's something that cannot be modelled
by this UI/API. My thinking was along the lines of limiting the scope of
functionality to the scope provided in the default j2se/web/.. projects to get
the same UI feel.
Re. Javadoc: good points, thanks, will do.
Re. Maven: first, as far as this SPI is concerned you need only deal with those
configuration types which are user-selectable. Maven will anyway apply the right
settings for the current OS, JDK, etc. So for the user-selectable configuration
types, we have three choices:
OrthoCfgTypes-1. Directly support orthogonal config types in the SPI. I am
hesitant to do this because the GUI would get more complicated and we don't
really need it for other project types that I know of. I could experiment with
it if it would really be valuable for someone.
OrthoCfgTypes-2. For a given Maven project, pick at most one type of config to
make selectable using the global GUI. But permit others to be selected e.g. from
the project's context menu or properties dialog.
OrthoCfgTypes-2a. You could even make the PCP impl for the Maven project just
show the configs of the type which was last changed by the full GUI. So as soon
as you e.g. pick your compiler config (debug? release? instrumented?) you would
see all compiler configs for the project listed in the combo box. If you later
on changed your run config you would see all run configs listed. Would satisfy
the basic problem, but UI might be just too weird.
OrthoCfgTypes-3. If there are not so many configs, and only a few _combinations_
are often used, you could show the cross product or some subset the user picks
in the Properties dialog.
As I mentioned on a recent nbdev post what Eclipse calls Configurations are
a very different beast. (This is independent of whether their choice
of the word Configuration was a good idea :-)
Traditionally configurations (as in configuration management) had to do with
building activities and inasmuch as Projects produce artifacts and are
oriented towards synthesis associating Configurations with projects as
this proposal does makes sense.
However, Eclipse didn't do this. Why?
What Eclipse configurations capture is attributes having to do with running
things, not building them. The Motivation for this proposal also talk about
cmdline arguments and running.
As such strong association with projects doesn't make
sense and Eclipse Configurations are orthogonal.
In CND we call them RunProfiles.
In Eclipse they capture cmdline arguments, environment variables, choice of
engines etc. They are named and refer to (rather than owned by) an
executable artifact (project or individual class, or external executable).
As is usually the case with orthognality IMO the Eclipse usage of RunProfiles
is more flexible.
It looks fine. Besides name changes, it is basically the same API as the one we
are currently using. We got it from the Mobility team.
I have two issues:
Please don't use generics yet. We have a copy of the sources in CND so it works
with NB5.0 and NB5.5 and it is still a requirement that we compile CND with 4.1.
Why show the configurations in the combo box in alphabetical order? It should be
up to the implementer to sort them (or not), and the IDE should just show them
in the listed order. I'm not sure we (CND) want to show them in alphabetical order.
Y01 May I ask about threading policy of the interface? Can it fire and update
its values in any threads? I have not read javadoc, but I found no mention
about these problems anywhere in the docs or this issue.
Re. generics - the code under review is intended for NB 6.0 which will require
JDK 5. If you plan to maintain a private copy of the API in the CND module, you
can erase generic type signatures if you want to. Anyway your code compiled
against your private API will not interoperate against the new public API unless
you do some weird tricks with java.lang.reflect.Proxy.
Re. alphabetization - this is already the case. j2seproject sorts its configs.
projectui displays them as they come.
Y01 threading policy - probably needs definition in Javadoc and perhaps some
impl work. I am on vacation next week but I will look at it after that.
Y01 solved in branch. Javadoc mandates use of ProjectManager.mutex, impl does it.
I'd prefer that runtime configurations be completely separate from projects. I
have runtime configurations that are specific to different types of applications
and have very generic properties. I'd like to be able to augment that generic
configuration with per project configuration such as 'run in directory' and 'jvm
arguments' as we have available now. I'd also like to have the ability to use
properties substitution into the configuration values.
greggwon: what you are talking about would probably be better handled via
freeform projects and some Ant scripting of your choice. Out of scope for this
RFE, I think.
No Jesse, freeform projets and creative ant scripting won't do.
I'd like to insist that separation of concerns of building (synthesis)
and running (anlysis, since lots of running is under analytical tools like
debuggers and performance analyzers) be given serious considereation.
Right now if I want to run my app with one set of input and then
with another set of input, it's extremely awkward. Under Eclipse and
Sun Workshop one can create a named "runprofile" independent of
build-related stuff and easily switch between them.
Using build configurations to manage alternative run scenarios won't do.
In the native environment build configurations span a 3-5 dimensional space,
spanning OS, architecture, compiler/ABI and debug level. It's
already hard to manage and adding a run-scenario dimension is IMO
I appreciate that this discussion might be outside the scope of
this immediate rfe, but it needs to happen somewhere.
ivan: you can already implement separate build and run configurations in any
project type, with no special support. This issue is about a *shared and global*
UI for managing per-project configurations. There is not a strong use case for
build configurations for Java SE projects, ME projects have configs that apply
to build and run, EE projects probably would be similar to either SE or ME, and
last I checked CND projects are using the same single-dimensional configuration
system that ME projects use. If and when several major project types decide they
need >1 independent dimension of configurations, then it would make sense to
extend this SPI in the obvious ways to support a shared global UI displaying
multiple configuration dimensions. But right now it looks unnecessary.
I added a new SPI method,
boolean configurationsAffectAction(String command);
Javadoc available here:
Better Javadoc link:
I would like to conclude this review by Friday Sep 08 if there are not
objections to it by then. Will attach running patch for reference.
Created attachment 33484 [details]
Currently proposed patch
See issue #49636 for commit log.