[hibernate-dev] ORM build - IDE imports

[Sanne Grinovero]

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 <steve at hibernate.org> wrote:
> 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?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev