[hibernate-dev] ORM build - IDE imports

[Steve Ebersole]

On Mon, Nov 10, 2014 at 7:26 AM, Hardy Ferentschik <hardy at 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?