Start Nb 6.7 RC2 full download with a fresh user dir. First thing you want to do is setup Maven options.
Goto to the miscellaneous options tab: no maven entries there...
P2: the ergonomics system is far from being ready... jRuby mess, very long (way too long Java EE activation) and now
the automatic module enablement does not work via preferences browsing...
Created attachment 83412 [details]
see images from the complete NB 6.7 preferences after fresh start
Created attachment 83413 [details]
same ui after IDE usage
P2 because it is a regression compared to previous Nb version, due to a poorly architected feature which is not solving
the core issue of bad startup performance.
Created attachment 83416 [details]
second image with correct type so that you can see it
Not a module system issue. Ergonomics feature is implemented separately. Not sure if Options dialog is supposed to be
stubbed out in this way or not.
Options dialog is not considered important entry point. Can you be more specific on the actual workflow you are using?
Why the first thing in the IDE shall be configuration of maven? Ludo, if you, instead of spitting fire, describe here
some real usecase, your inquiry may have receive more attention, than it can in current state.
For me it was simple. I started NetBeans. I wanted to use it to build GlassFish.
I knew GlassFish needed maven options set. I looked for maven options before
even opening the GlassFish project.
This might not be an issue for people starting a new project with maven, but when
importing an existing project that uses maven, why would I necessarily open the
project before setting the options?
I see, thanks. However this means that you are quite familiar with behaviour of NetBeans and you can find your way out
Looking at the issue from newcomer (NetBeans, Maven or Glassfish) perspective, it is unlikely to expect the developer
to know that Glassfish needs some special maven settings (btw. what is that setting? A path to maven installation?).
It is more likely that such developer opens the project and then finds out something is broken. Maybe we need to
improve user experience along this path rather then tell everyone to start in Tools/Options.
Tools/Options does not sound like a appropriately good out of box experience to me.
the 600k actives Nb users are familiar with NetBeans and know about Nb 6.5x behaviour.
Regressing from 6.x IDEs is not a good thing to do and this is clearly a UI and user experience regression.
Not having a known way of enable UI screens in a Full download of Nb is more than a P4 bug.
Moving back to P2:
I would appreciate if you ask either the waiver team or and the HIE group about the current behavior and appropriate bug
I understand you are the main designer of this "ergonomics" "load on demand" feature, but as such you might not be the
best person to decide on what is good or not good or not important in term of ease of use and HIE decisions.
The behavior does not only affect Maven. Same effect for ANT, GUI designer, Java Debugger (YEP debugger is optional on
demand?!!!on a Java IDE !!!), Profiler.
This is on my settings. Who knows, maybe other modules are affected, but because I did not use them in my current build,
I cannot even see if these modules are there or not via the Preferences UI.
I'm not familiar with NetBeans at all. I had to ask Ludo for help when I couldn't
figure out how to set the maven options. He said "it's right there on the preferences".
Well, I was sure I had checked the preferences and it wasn't there. I went back to
check again, just to prove him wrong, and like magic there it was! Completely confusing.
Ludo, the HIE team can confirm that Tools/Options were not seen high priority entrypoints for 6.7.
Bill, Ludo, I am still not sure about your usecase. Why the user needs to start with configuring Tools/Options, what
is so broken on Glassfish maven projects that this is necessary?
well, the obvious problem with ergonomics is that changes ui in non-obvious ways. One of the items in the Maven's tools
options is setting of external maven. There are good reasons why you might go there and set a certain version there.
Like that your project doesn't build properly with previous version of maven or some of the plugins require it.
So imagine the project (or any other documentation source for that matter) publishes the following guidelines:
Install latest netbeans
Install maven 2.2-RC1
In netbeans's Tools/Options, point to the maven installations's base directory to build with that version.
However with Ergonomics you have to point out that *if* people use the full version of Netbeans, they have to open a
maven project first, or otherwise the options dialog panel is missing. And actually you can open just about any java
project to have maven option appear.
I would argue that a lot of people will not notice this subtle ordering problem and will give advice without the
ergonomics clause, resulting in splitting the usebase in 2 groups (like Ludo and Shannon) that randomly pick one or
another step first and get different results. Additionally the first group (Ludo) has hard time believing the other
group (Shannon) that the dialog is not there for them.
> Why the user needs to start with configuring Tools/Options, what
is so broken on Glassfish maven projects that this is necessary?
Nothing is broken. GlassFish just needs more than the default amount
of memory. Plus, I like to use private repositories for each project
rather than a central repository for all projects.
I knew I needed to configure these things before I even started.
It's not that I *had* to configure them first. It's just what I
happened to do. I found it very confusing that there was no properties
panel for maven.
I see. Thanks Bill.
During the first round of ergonomics, we (HIE team + engineering) tried to identify all possible UI entry-points and
mimic the full IDE. This effort, as far as I remembered, failed due to the fact that the amount of work needed to
implement them all would be immense.
In the second round of ergonomics efforts, we've taken a different approach - more similar to e.g. Visual Studio, where
only functionality relevant to the current context is enabled. Together with Jarda's team, we've identified key UI
entry-points, which enable certain functionality, and prioritized them.
What this issue is essentially about is whether options should be one of these UI entry-points. Of course having them as
an entry point is nice-to-have and won't hurt anyone, but I understand the discussion here as whether it affects
significant number of users to be worth spending implementation effort on it.
I have no strong opinion about this, but I tend to think "no", for the following reasons:
1) In typical-user scenario, this problem will not be experienced as maven functionality would be enabled when the
userdir is imported.
2) Users expect things to work well out-of-the-box. Configuration should not be needed for majority of users and is
typically accessed when something does not work as expected. At this point all maven functionality is enabled as the
project is open.
So this issue can be encountered by (I'm aware of certain level of simplification):
A) Users who are instructed to configure something AND at the same time are new to netbeans (~did not import their
userdir) AND did download one of the distributions with FoD. Quite easy to handle in tutorials, out-of-our control in
other minor cases.
B) Users who know their tool well, have special needs, know that they need to setup the tool to support them (and also
know how/where to do that) AND are new to NetBeans, i.e. have not a userdir from the previous version. Does not sound
like very likely combination.
Both A and B are rare combinations (despite that most of us probably belong to group B - but we're not the ones the IDE
is designed for).
I'm not saying this won't affect anyone. I'm just saying is that it will probably affect *very few* people and we should
consider the benefit/cost ratio. This really is not a common use-case. IMHO not worth it.
It could be made even less likely (but not entirely eliminated) by disabling options until a first NB bundle is enabled.
Thanks Ondra for your assessment. Configuration shall not be an entry point (for majority of users). I am keeping this
issue open, but for the near future we rather concentrate on making the IDE work and work out of the box rather than
creating this additional entry point.