Re: [hibernate-dev] ORM build - IDE imports

On Mon, Nov 10, 2014 at 7:26 AM, Hardy Ferentschik <hardy(a)hibernate.org&gt; wrote: > Hi, > > > > > To be honest I think I'd alter jpa-metamodel-gen to not be AP-based > as > > > the > > > > best-case scenario. > > > > > > Not sure what you mean? Are you referring to the actual annotation > > > processor module > > > or do you mean that you want to statically check in the generated meta > > > model classes > > > needed for our tests in the hibernate-core/hibernate-entitymanager > module? > > > I assume > > > the latter. Again, not a big fan. > > > > > > > No, I actually mean the former. Probably as an alternative to the > AP-based > > generation, I think a non-AP solution would be good > > Interesting. For me the metamodel generation is a classic example for using > an annotation processor. > I think that's true *if* the compilation unit producing the metamodel is not also the one consuming it. For example a CRM project that produces and bundles a JPA static metamodel of its domain model for developer use. However, in cases where we try to both produce and consume the static metamodel from the same compilation unit as we do in our usages. I think about the whole point of AP, and as a user especially this static metamodel. So I am writing code in which I am relying on this static metamodel for type-safety, but I cannot even do that as the static metamodel types dont even exist. Until I introduce some unnatural (imo) step into the development process: develop, then compile so that I can develop some more. > > After having talked > > to David a few times about this, I believe annotation processing is not > the > > proper way to be generating these classes > > What would be the right way then in your opinion? > Well again I am pointing out the appropriateness of each. I think the AP approach makes sense in certain cases. Just that our case within the Hibernate build is not one of these. I think a tool leveraging source code reading/analysis > > > annotation processors that generate code that is then needed to compile > > Not sure. IMO the annotation processor is designed for exactly that. In > fact if you > run the processor as part of the main compilation it does generation and > compilation > in the same build phase. I don't see the bad mojo here. > I consider it bad mojo because I load it up into the IDE and see red all over the place. Yes I realize we have the same with Antlr and/or JAXB. But I can completely rationalize running a source code generation *tool* here. I have a hard time making that rationalization for running the compiler in order to see if my code will compile due to sources that are not there :) > > > > It seems to me the only real option currently is to expect a full > compile > > > > prior to import. > > > > > > Right. Something I would recommend anyways. > I fully understand about needing/recommending some task prior to importing. Specifically a source-generation task. I just don't think I am alone in not immediately assuming/grokking a full compilation as the source-generation task. > > > > Dunno here. Often my initial touch point with a project is to check out > > the code and import it into the IDE. And I think that I am not unusual > in > > that sense, so I think there is a ton of value in that working smoothly. > > Sure, there is value in making it work smoothly. However, I prefer to > start the > command line build first after checking out the code. > I am not so sure that is the norm. For sure it is not generally what I do at least. Projects tend to have such widely differing build assumptions and requirements. When you first check it out, how do you know what command line to do? _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev