I just tried to import it in Eclipse. Compiling it once from the command line upfront helped to reduce the errors.. but I still have 10, and while I suspect one of them relates to a bug in Eclipse's not-so-smart handling of generics, the others to me look like it shouldn't compile so I'm going to need some hand-holding on each of them.
Some examples: EnhancerTask class not found: seems to be a groovy class. Do I need to setup the project as Groovy, or get some Groovy SDK installed as well? package-info.java sources in the jpamodelgen module seem to be in the wrong package - or they are missing the package declaration. They also have the wrong license header (JBoss instead of Hibernate, Apache instead of LGPL). Code snippet "CoreMatchers.<Object>notNullValue()" doesn't compile as the method is not generic. Apparently IDEA and javac consider this acceptable, but Eclipse won't. May I remove the generics usage? I've sent a PR proposal here which includes a second problem with generics: https://github.com/hibernate/hibernate-orm/pull/843 Sanne On 10 November 2014 14:48, Steve Ebersole <st...@hibernate.org> wrote: > On Mon, Nov 10, 2014 at 7:26 AM, Hardy Ferentschik <ha...@hibernate.org> > 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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
