[hibernate-dev] ORM build - IDE imports

Steve Ebersole steve at hibernate.org
Sat Nov 8 11:30:04 EST 2014


I have been thinking of ways to make importing ORM into IDE more
transparent.  My thinking is from the IntelliJ pov and the specific issues
I have run into there.  I wanted to run my thoughts past y'all to see if
they helped with Eclipse and/or other IDEs.

-----

The main thing I see is trouble with the generated-src dir.  IntelliJ
automatically "excludes" the build directory which is actually perfect,
generally speaking.  However, we put generated-src under the build dir so
it gets excluded by extension as well.  That's why after import we need to
adjust excluded dirs and source dirs.  My suggestion here is to move
generated-src out from under the build dir, making it on level with src and
target.  So we'd have:

{projectRoot}
    +- generated-src
    +- src
    \- target

generated-src and target would both be directories that are created by the
build and are git-ignored.  The point being that IntelliJ would still
exclude target as the main build dir, but generated-src is no longer under
that dir and would not be excluded.  In my experience the import marks the
generated source dirs properly other than them being transitively excluded.

----

A related issue is the execution of source generators.  This has already
been partially been addressed.  Today we have a split between:
1) source generators that generate sources required at compile time (antlr,
jaxb, jpa-metamodel-gen, etc)
2) source generators that generate sources required at run time (currently
only logging).

There is also a concern here between AP-based generators and non-AP-based
generators.  And unfortunately they split across the compile/run time
requirement.  I am not really sure of an ideal solution here.  And the
situation is compounded by the fact that IntelliJ won't let us apply
annotation processors to its compile process because of the
hibernate-testing module circularity :(

To be honest I think I'd alter jpa-metamodel-gen to not be AP-based as the
best-case scenario.  But that is not likely to happen soon.  And coupled
with the fact of the IntelliJ limitation due to hibernate-testing
circularity, I am not sure it would practically help.

It seems to me the only real option currently is to expect a full compile
prior to import.

Better suggestions?

----

Speaking of the hibernate-testing circularity, I do still want to get rid
of that.  Currently I have been waiting on Gradle adding support for
publishing multiple artifacts from a project (module).  The idea being that
we'd fold the source from hibernate-testing into hibernate-core and have
hibernate-core produce and publish both artifacts.  Currently Gradle only
supports a single publication from a project.  So the hang up really is
publishing hibernate-testing to nexus.  I think we all agreed last time
this was discussed that publishing hibernate-testing to nexus was important
enough to hold off on.  Do I remember that correctly?  Is that still the
situation?


More information about the hibernate-dev mailing list