Hey Max,

Glad you are getting involved. Sorry this email is a bit late, the holidays took their toll.

Goals of F2:

In short, everything you just asked about. We are creating a modular addon system which uses maven as a primary distribution system and repository. Focusing on minimal startup time and best performance. Targeting all major IDEs as a host runtime - Forge addons will run in Eclipse, IntelliJ, NetBeans, and on the Command Line, bringing Forge'd tools to more developers than ever, and increasing the reach of other JBoss projects and open-source technology tooling that has never been possible before.

That's it, in a nutshell.

Startup time
In F2, startup time is currently 2 seconds for a chain of about 5 addons. This will be reduced farther when we implement "ClassLoader Only" addons. Meaning no container is started, but the addon is simply loaded as a Module for classloading purposes. One of the goals of F2 is on-demand or "only when necesary" addon loading/starting, so this should stay pretty low. It's not where we want it to be yet, but we will make sure it stays low.

It takes about .7 seconds on my machine on average just to do ClassLoading if you are using batchMode with 0 addons installed (run until addons are done and exit, in this case instantly). This is already a big improvement over F1:

sharkbook:core lbaxter$ time forge --batchMode
real    0m0.640s
user    0m0.573s
sys     0m0.090s

How to keep forge addons uptodate/in-sync to keep working together:

Not exactly sure what you mean here, but this is something we are still talking about. Right now we are using hard version numbers in POMs to ensure build stability, but I have been playing with the idea of actually using the thing nobody ever uses in Maven (version ranges) - now, before you try to kill me, I'm aware of the downsides, but am weighing the benefits since in a modular environment things are a bit different. We aren't really building JARs when we're building addons. We're building addons that happen to have a JAR or more. So thoughts are welcome on this.

Support a "multi-step wizard" approach for one and combined forge commands:

Yup - https://github.com/forge/core/blob/2.0/ui/impl/src/test/java/org/jboss/forge/ui/impl/MockNewProjectCommand.java#L78

Would love your feedback on this API. And the Command Abstraction API as a whole. Note that this is just the developer facing API, there must be a corresponding implementation for the given GUI (Shell, Eclipse, Netbeans, Etc.)

How to not have too many hard requirements of the sequence or if possibly any need of Forge setup commands to use Forge to simply generate code:

If you want a plugin/addon that generates code without doing inspection, there's nothing in the way of this. Forge 2.0 caters very well to this scheme as well, since startup time is so fast and addons are extremely modular, you'll barely even notice a delay. To make things even better, we are playing with a mode where forge only loads addons requested by the specified command, then shuts down. This would mean you should be able to run Forge from the command line, and load only the addons necessary for the requested execution, or start Forge from the IDE, and have it load only the addons necessary to execute on the given wizard inputs.

No blockers here, and in fact, I think you are right that we need to go more in this direction. Forge 1 is not really capable of delivering this, which is why we are taking this into account from the start in F2.


On Thu, Dec 20, 2012 at 6:56 AM, Max Rydahl Andersen <max.andersen@redhat.com> wrote:

On 20 Dec 2012, at 11:47, Max Rydahl Andersen <max.andersen@redhat.com> wrote:

> The primary usecase for Forge from my POV is being able to reuse scaffolding and code generation as a replacement of Seam Gen functionality we have in Eclipse and
> right now Forge is not there yet and I fear it won't be there within the next 1-2 months where we actually need to make progress on scaffolding and generation for things like
> HTML5 and more. I'm wondering if we need to readjust our approach to how we use forge and its addons - maybe the "old" approach of sharing code/templates is a better one
> instead of requiring a full running Forge to make it work ?

One approach I had in mind here is if like Forge (at least in theory?) could be made to support Gradle and the plugins would still work - could we get Forge to grok Eclipse Projects natively
and just rely on already loaded and ready project information inside Eclipse ?

Things like dependency management would have to be delegated to the real maven or gradle or whatever in play here but I think in majority of cases for code generation this step is
just a one-off thus not necessary to do.



forge-dev mailing list

Lincoln Baxter, III
"Simpler is better."