Done. Still improving but mostly there.

My comment about "fully running forge" was about not having to run Forge inside eclipse since that brings a whole slew of other problems with it.

For this jira my concern is not about memory/performance/startup etc. thats a separate topic which I put on forge-dev so i'll leave that out of this part about UI interaction.

This one is about how we avoid having Eclipse users to have to relate to things like absolute paths, keep entering data that eclipse can already provide good defaults for and how to combine commands.

The wizard UI api looks interesting, but would like to see an example of how it would be used to fully grok it.

I'm not sure what you mean by "build a menu" and "generate metadata for eclipse to use to build its menu" - the wizard API talks about wizards which aren't menus ? And looking at the API its dynamic (understandably) so the wizard can't be generated/deduced before actually having the input data to know which pages to show etc.

In order to alleviate the startup cost of Forge just to build a menu, this new API could easily be consumed by an addon that generates metadata for Eclipse to use to build its menu. This addon could be run periodically (or after addon installation/removal) if you really want to go that route, but I think you'll find that the startup time of Forge 2.0 is minimal, and we continue to improve it.

My biggest gripe/concern with the current Forge approach is that it is all very "(re)action based".

i.e. plugins seem to follow the pattern of "ask user question 1,2,3,4 (based of the cmd annotations)", do something - realize something was not possible to ask about via cmd annotations "ask user question 2,3,4", do something, "ask user some more questions", do things.

This is all great in a cmd-line world but really really hard for newbie users to grok (IMO) and when you actually have to do or combine multiple forge level operations things becomes really hard from an IDE user perspective - i.e. IDE users expect to be able to just press Cancel in a multi-step wizard and not see any change in his project from that, also when driving from the IDE, we'll need to be able to call out to Forge and query for the possible values etc. (something the current 'single

Is this issue about solving/improving this challenge or "just" about providing an UI on top of the existing "cmd line/reaction pattern" ?

Things to consider here is how forge can provide rich enough info to have "Browse.." buttons work for file/resource, database resource selection, etc.
And how a multistep wizard could be created outlining pages needed to provide the questions ...and in a way that does not require fully running forge inside something like Eclipse.

Of course we can provide some convenience APIs on top of this as well, but we need something core and low-level to provide the kind of abstraction necessary. I'm not saying my suggestion is the answer, but it's got to be something that really provides a strong type-safe view of how to interact with the user data.

We're trying to design the next Plugin API - as we call it in Forge 1. So we need a programming model that lets people declare interactions in a manner that is agnostic of the UI it will eventually be presented in.

public interface Interaction
{
   public String getName(); 
   public Set<Rule> getRules();
   public Set<Input> getInputs();
   public PreparedInteraction prepare(PopulatedInput... inputs);
}

public interface PopulatedInput<T>
{
   public T getValue();
}

public interface PreparedInteraction
{
   public void perform();
}

This is just an example initial interface. My idea here is that each interaction has a name (possibly something we can move to an Annotation instead, but just thinking out loud.) Each interaction also has a set of inputs. This would be every possible input that could ever be required to run the plugin. The rules would then be used to specify which inputs to show or not show, and in what order. The inputs become populated as their values are filled in by the UI/Rules, and then those populated inputs are passed to the prepare() method, which returns an object ready to perform() the given interaction.

I know this is a bit rough around the edges, but it's an idea. We should probably look at some other frameworks out there and see what other people have done, and try to take some of what works and adapt it for Forge.

It would be nice to have a common API with could be used to provide some tips to the UI Engine (SWT in case of Eclipse, Swing in IntelliJ and Shell) on how to ask for parameters for a specific command. In Shell, we can do that by prompting the user for each necessary parameter (unless it is explicitly set). In an UI, they would be probably be rendered as text fields.

What we need is a domain model that fit in this proposal and also allowing some extra features, like input validation, mutually exclusive command options (as described in FORGE-297). As typesafe, I meant to allow the use of a Javabean to store the input for a specific parameter or group of parameters.

Can you please elaborate it more ??? I would like to understand your thinking.