[forge-dev] On the topic of the impedance mismatch between Forge and IDE's

[Lincoln Baxter, III]

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.

~Lincoln

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

>
> On 20 Dec 2012, at 11:47, Max Rydahl Andersen <max.andersen at 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.
>
> WDYT ?
>
> /max
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130107/21bc2771/attachment-0001.html