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&gt; To: "Jonathan Fuerth" <jfuerth(a)redhat.com&gt; Cc: "Xavier Coulon" <xcoulon(a)redhat.com&gt;, "Rodney Russ" <rruss(a)redhat.com&gt;, 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&gt; To: "Rodney Russ" <rruss(a)redhat.com&gt; Cc: "Lincoln Baxter" <lbaxter(a)redhat.com&gt;, "Xavier Coulon" <xcoulon(a)redhat.com&gt; 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&gt; To: "Jonathan Fuerth" <jfuerth(a)redhat.com&gt;, "Xavier Coulon" <xcoulon(a)redhat.com&gt; Cc: "Lincoln Baxter" <lbaxter(a)redhat.com&gt; 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