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.
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 all details.
Created attachment 31097 [details] Proposed patch
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 persistance. 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 entirely impractical. 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: http://deadlock.nbextras.org/job/prj_configs_49636/ws/nbbuild/build/javadoc/org-netbeans-modules-projectapi/org/netbeans/spi/project/ProjectConfigurationProvider.html
Better Javadoc link: http://deadlock.nbextras.org/job/prj_configs_49636/lastSuccessfulBuild/artifact/nbbuild/build/javadoc/org-netbeans-modules-projectapi/org/netbeans/spi/project/ProjectConfigurationProvider.html
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.