<div dir="ltr"><div><div><div>Hey Max,<br><br></div><div>Glad you are getting involved. Sorry this email is a bit late, the holidays took their toll.<br></div><div><br></div><div><b>Goals of F2:</b><br><br></div><div>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.<br>
<br>That's it, in a nutshell.<br></div>
<br><b>Startup time<br></b></div>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.<br>
<br></div>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:<br>
<br><span style="font-family:courier new,monospace">sharkbook:core lbaxter$ time forge --batchMode<br>
real 0m0.640s<br>user 0m0.573s<br>sys 0m0.090s</span><br><br><div><div><div><p></p><p><b>How to keep forge addons uptodate/in-sync to keep working together:</b></p><p>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.<br>
</p><p><b>Support a "multi-step wizard" approach for one and combined forge commands:</b></p><p>Yup - <a href="https://github.com/forge/core/blob/2.0/ui/impl/src/test/java/org/jboss/forge/ui/impl/MockNewProjectCommand.java#L78" target="_blank">https://github.com/forge/core/blob/2.0/ui/impl/src/test/java/org/jboss/forge/ui/impl/MockNewProjectCommand.java#L78</a></p>
<p>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.)<br>
</p><p><b>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</b>:</p><p>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.<br>
</p><div class="gmail_extra">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.<br>
<br></div><div class="gmail_extra">~Lincoln<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 20, 2012 at 6:56 AM, Max Rydahl Andersen <span dir="ltr"><<a href="mailto:max.andersen@redhat.com" target="_blank">max.andersen@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br>
On 20 Dec 2012, at 11:47, Max Rydahl Andersen <<a href="mailto:max.andersen@redhat.com" target="_blank">max.andersen@redhat.com</a>> wrote:<br>
<br>
> 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<br>
> 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<br>
> 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<br>
> instead of requiring a full running Forge to make it work ?<br>
<br>
</div>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<br>
and just rely on already loaded and ready project information inside Eclipse ?<br>
<br>
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<br>
just a one-off thus not necessary to do.<br>
<br>
WDYT ?<br>
<div><div><br>
/max<br>
<br>
<br>
<br>
_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>"Simpler is better."
</div></div></div></div></div>