9:07 p.m.
Sorry for the delay; I had hoped to respond by the end of yesterday.
I read over the reported issue and its comments. I totally agree this is a common problem
that needs a clean solution.
Since I'm not a Forge user yet, I'm going to dump out my context for how I'm
thinking about Forge. It's mostly formed based on my previous encounters with
RAD/4GL/Productivity tools. Please take issue with anything I'm saying that's not
true of Forge!
<brain-dump>
Before answering your question, I'd like to explain my perspective. At its core, I
believe Forge is another try at creating a fourth-generation language. Tools like VB 6,
Delphi's VCL, and Oracle Forms looked really promising. I remember talk that the
world's need for programmers was coming to an end and power-users would be able to
create and maintain their own apps by purchasing generic components and snapping them
together in something more like a layout/wiring tool than a code editor. Java took a crack
at this too: the JavaBeans specification was originally intended as a basis for creating a
zero-programming drag'n'drop authoring tool for Java GUIs.
All of these things more or less failed to catch on. I believe the reason is that although
these tools demoed really well, they fell flat when the time came to get signoff from
project stakeholders: you can push back on business requirements all you want, but
there's still going to be a cartload of completely loopy requirements left over that
you simply can't achieve with the components available for your 4GL. Then you go from
"rapid application development" to "elaborate series of workarounds."
The project is suddenly way behind schedule, the project sponsors are disappointed with
the results, and the code ends up completely unmaintainable.
I think these RAD/4GL tools are a tremendous help in phases 1-4 of the following software
project lifecycle I've just invented: :)
1. Project file layout, build tool setup (scaffolding)
2. Technology demo
3. Proof-of-concept application
4. Introduction of unit & functional tests
5. Satisfying business requirements
6. Production support (correctness, stability & performance fixes; regression tests)
I think once you hit phase 5, stuff that's "not invented here" starts to get
in your way, and coding direct solutions to the business requirements at hand (i.e. the
ones that have been dumped on you despite your protestations) is the fastest and most
maintainable way forward.
For me, Forge fits into this world view really well. Perfectly, almost. Step 1 in my
made-up product lifecycle is actually a lot of work, it provides no visible business
value, and mistakes made here plague the project forever. Even if it's easy to
rearrange the project and redo the build, it seems like a monumental task once you're
in phase 5 or 6. Maven actually helps us a lot here by prescribing a project layout
that's flexible enough to accommodate new facets and resources in the future. Forge
makes it even easier to do the Right Thing at this stage.
At phase 2, Forge really shines. This is as far as a Forge demo would go in a tradeshow
booth, a live technical session, or a screencast. Clearly, Forge has this nailed.
At phase 3, I think Forge still has quite a bit of utility. Here, the programmer has a
fair bit of leeway in low-level design decisions and will be able to extract maximum value
from the Forge plugins.
Again at phase 4, I'd hope for Forge to be a huge help in introducing tests to a
project. There can be a lot of "figuring out" in this stage that just burns time
and provides no value.
But once we reach phase 5, Forge is going to start providing diminishing returns. If a
business requirement is at odds with what Forge can provide, it needs to be able to get
out of the way and let the development team take over. It's great that Forge is
extensible, but at this phase in a project, the team's time will be better spent
implementing direct solutions to the oddball requirements. Developing tooling that's
got near-zero chance of being useful outside the project isn't really a great idea.
I'm not sure how Forge might be useful for an app that's in production. The
lasting benefits from having a properly set up project will still be there. That's
good. Maybe Forge would be a good way to create skeletons for new regression tests. And to
add in tools like Arquillian. Or to create JMX beans for monitoring trouble areas in the
app.
I hope I'm not underselling the point of Forge here. I've heard you say "I
hate code generators" on many occasions. I take this to mean that you don't see
Forge as a "generate and abandon" tool. But I think there's just going to be
a point where the business requirements get in the way and (part of) the code ends up too
gnarly for anything to understand by pattern recognition.
I think the best way of dealing with this is to make the transition from "completely
comprehensible to Forge" to "kind of mysterious to Forge" as painless as
possible. Explicit markings to help Forge not trip over customized stuff would probably be
okay.
</brain-dump>
Thanks for indulging me. I hope I'm not way off the mark. If so, let me know. :)
I think it's inevitable that projects using JPA will have some sort of custom
EntityManager by the time they get into production. Sometimes, Entities created with or
adopted by Forge will have to belong to the custom EntityManager; other times they
won't. Taking all this into account, I'd lean toward qualifying everything Forge
cares about with some sort of @Forge annotation. It would be nice if Forge could at least
attempt to understand other entities too, with failures being nonfatal and free of side
effects! I'm not sure how or if that would work, of course.
Hope that helps. Sorry for the lengthy response.
-Jonathan
----- Original Message -----
From: "Lincoln Baxter" <lbaxter(a)redhat.com>
To: "Jonathan Fuerth" <jfuerth(a)redhat.com>
Cc: "Xavier Coulon" <xcoulon(a)redhat.com>, "Rodney Russ"
<rruss(a)redhat.com>, forge-dev(a)lists.jboss.org
Sent: Monday, November 28, 2011 11:38:50 AM
Subject: Re: JPA review on Forge reverse engineering
Great! First-question:
https://issues.jboss.org/browse/FORGE-372
Is this a good idea? (I have an opinion, but want to hear others.)
~Lincoln
----- Original Message -----
From: "Jonathan Fuerth" <jfuerth(a)redhat.com>
To: "Rodney Russ" <rruss(a)redhat.com>
Cc: "Lincoln Baxter" <lbaxter(a)redhat.com>, "Xavier Coulon"
<xcoulon(a)redhat.com>
Sent: Tuesday, November 22, 2011 2:13:06 PM
Subject: Re: JPA review on Forge reverse engineering
I have loads of Java-and-SQL experience and a bit of Hibernate from way-back-when.
I've only played briefly with JPA (in the context of a Google App Engine project in my
spare time.)
I'd be happy to discuss stuff with Lincoln if he'd like my input from this
perspective!
-Jonathan
----- Original Message -----
From: "Rodney Russ" <rruss(a)redhat.com>
To: "Jonathan Fuerth" <jfuerth(a)redhat.com>, "Xavier Coulon"
<xcoulon(a)redhat.com>
Cc: "Lincoln Baxter" <lbaxter(a)redhat.com>
Sent: Monday, November 14, 2011 3:55:51 PM
Subject: JPA review on Forge reverse engineering
Hey Jonathan and Xavier,
I'm pinging you guys because Lincoln is looking for someone with practical (pragmatic)
JPA experience from the real world. You guys are the last ones on the team to come from
developer shops and have the best chance at still being able to think like a developer.
:)
Do you guys have enough JPA experience that you could work with Lincoln on reviewing what
the reverse engineering functionality in Forge provides?
Thanks,
Rodney