On Wednesday, March 16, 2011, at 11:09 am, Sanne Grinovero wrote:
> On Wednesday, March 16, 2011, at 10:15 am, Sanne Grinovero
wrote:
>> Hello,
>> I really wanted to merge my super-trivial patch using the new JUnit4
>> capabilities, but I'm having some issues in building core.
>>
>> 1)IntelliJ
>> (after solving the OOM issues with the annotation processor)
>> It doesn't find the ANTLR generated files, hence I can't run my test
>> as it has a compile failure.
>
> Same thing with the older Maven builds. You have to manually run the
> antlr generation task. You could set that up to run on build, but
> personally I prefer to run that stuff manaully when needed. Up to you.
>
> By the way, same in eclipse.
Thanks didn't know it needed a manual step. Actually in eclipse it was
generated automatically by triggering Maven's ANTLR plugin, and I expected
IDEA to have something similar.
I might have backed off from IDEA quickly returning to command line /
Eclipse alternatives as I'm not comfortable with it's interface yet.
In
IntelliJ (no clue about eclipse) that is true depending on the tasks you
tell it to run on (re)import if using the Maven project imprt stuff. You
could tell IntelliJ to run a certain Maven goal or phase before compilation of
a module, but thats what I never ever set up as it made compiling in the IDE
painfully slow for the 80% case. If I changed the Antlr grammars I just
manually reran the Antlr generation tools.
Btw, if you like that model you can do the same with IntelliJ + Gradle using
either "external tools" or the Gradle UI plugin.
>> 2)Eclipse
>> the configuration files generated by gradle are totally wrong, but I
>> could fix them by hand.
>> Now Eclipse refuses to compile the project as there's a circular
>> dependency: the testsuite from hibernate-core depends on the
>> hibernate-testing module, which in turn depends on hibernate-core.
>
> This was intentional. Both gradle and intellij can handle this. I asked
> max and he said that such a set up was in some way workable.
>
> I dont understand what is so foreign about this "circularity". Look at
> it at the task level. You compile hibernate-core/src/main; you compile
> hibernate- testing/src/main; you compile hibernate-core/src/test. Yes
> there is "circularity" if you look strictly at this in terms of modules.
> But in terms of tasks and source sets there is not.
Yes that seems a resonable plan if you look at it as being three modules.
But eclipse is having a different concept, if will join the classpath
of test and main of each project, so it creates a two way dependency
and then bails out with critical complaints.
I guess IDEA is much smarted but it still provides a warning.
>> Reopening in IntelliJ to figure out why it seemed to almost work there:
>> In fact, it's showing a warning about circular dependencies, but
>> somehow it can work around it.
>
> Make sure the dep in hibernate-core on hibernate-testing is "Compile"
> scope.
I didn't change any code, this is the master state as opened in Idea
after "./gradlew idea"
>> 3) Command line
>> ./gradlew clean build
>>
>> Gets me 100 compile errors, related to the usage of @Override in the
>> generated code, I guess Gradle could also somehow could workaround the
>> dependency circularity but didn't set the compiler to Java6
>
>> compatibility:
> Are you running gradle with Java 6?
Can't get that wrong as I don't have Java5 on my disk.
thanks you for the ideas, setting up antlr in IDEA is good enough for now.
Sanne
> ---
> Steve Ebersole <steve(a)hibernate.org>
>
http://hibernate.org
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org