[hibernate-dev] ORM build - IDE imports

[Gunnar Morling]

Hi,

2014-11-08 17:30 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> 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.
>

Having dirs with generated sources under "target" is a common situation, so
I'm surprised that it isn't handled smoothly by the IntelliJ/Gradle combo.

In Eclipse/Maven generated source dirs under "target" are automatically
added as source folder upon import of a Maven project. For most (Maven)
plug-ins generating sources this works out of the box, for others one can
explicitly add the source source folder in the Maven POM so it will be
recognized during IDE import.

Maybe a similar approach exists for Gradle?

----
>
> 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?
>

Removing the circularity would be great, it seems to be the cause of some
of the issues. It'd also give a better experience for Eclipse users as this
is reported as an error during import (which then can be suppressed).

For Hibernate OGM we don't have a dependency to hibernate-testing, so we
wouldn't need it to be in Nexus.

--Gunnar



> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>