This will create the idea project files. Same as 'mvn idea:idea' before
the days
Idea had built-in support for maven.
On Thu, 17 Jun 2010 14:52:53 +0200, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
I thought gradle kept the pom dependency information as is but
I'm wrong
it seems :)
My question is:
Once checked out of svn, what do I need to do to get the project ready
to work in IntelliJ / Eclipse (lib deps declaration, test config etc)?
Today, with the pom.xml, it's a two page wizard and I'm good to go,
including running tests and all.
On 17 juin 2010, at 14:45, Steve Ebersole wrote:
> On Thu, 2010-06-17 at 14:37 +0200, Emmanuel Bernard wrote:
>> How much manual change is required in the IDE configuration for that?
>> Assuming we start with a pom.xml import?
> I do not understand the questions. Do you mean "manual change" to the
> IntelliJ project after it is created/opened? There is no pom.xml so how
> would we start with it for an import?
>
>>
>> On 17 juin 2010, at 14:28, Steve Ebersole wrote:
>>
>>> On the branch using Gradle for builds I started working on folding
>>> together hibernate-core, hibernate-testing and hibernate-testsuite.
>>> Gradle makes this very flexible and without further
>>> considerations I would simply define a total of 4 sourceSets in the
>>> hibernate-core project:
>>> 1) src/main
>>> 2) src/test
>>> 3) src/testing
>>> 4) src/intgTest
>>>
>>> Gradle would let me define the compilation output directory for each
>>> sourceSet and we'd be on our way.
>>>
>>> But of course we want this easily workable in IDEs. IntelliJ
>>> for example would not like the fact that we would need to define a
>>> total of 4 different compilation output directories for a single
>>> project (what IntelliJ calls module). So we need to find the
>>> balance that works best in command line as well as IntelliJ and
>>> Eclipse.
>>>
>>> I've put together a few proposals based on knowing what will work in
>>> IntelliJ and talking to Max and Hans.
>>>
>>> 1) As far as we can tell the above would actually work. In
>>> IntelliJ we'd split the project into 2 modules. There was some
>>> drawback to this in Eclipse as well though the details escape me atm
>>> (max?).
>>>
>>> 2) Only fold hibernate-testsuite back into hibernate-core and leave
>>> hibernate-testing separate. This creates a semi-circular
>>> dependency but Gradle and IntelliJ can deal with it because the
>>> nature of the deps is limited in such a way that hibernate-testing
>>> would depend on classes from hibernate-core and hibernate-core would
>>> depend on hibernate-testing for it's test-classes. No clue if
>>> this would work in Eclipse.
>>>
>>> 3) Another thing to consider is whether hibernate-testing still needs
>>> to be deployed on it's own. We did this as a convenience so
>>> that users could use it in their own project tests. To be
>>> honest I have no idea how much use it gets in that way. If the
>>> answer here is no then the problem becomes a little simpler in that
>>> we could just compile the hibernate-testing classes would just be
>>> part of hibernate-core/src/test/java and would get compiled along
>>> with the test classes into test-classes. Gradle itself has this
>>> set up so we have a template we could easily follow for this
>>> approach. Worst case we could use this approach and still build
>>> the additional hibernate-testing jar for upload using include/exclude
>>> definitions to get the correct classes into the jar.
>>>
>>> All things considered I think I prefer (2) or (3) as the solution to
>>> implement. One concern I had with them that I need to verify
>>> works is compiling unit tests and intg tests into the same output
>>> directory and whether separate test tasks could really work there.
>>> Also I need to decide whether that really matters.
>>>
>>> Thoughts?
>>>
>>> -- Sent from my Palm Pre
>>> 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
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev