[hibernate-dev] Project layout
Steve Ebersole
steve at hibernate.org
Thu Jun 17 09:33:10 EDT 2010
No, you define your dependencies in the gradle build files (using for of
an ivy syntax afaiu). Gradle will transfer that information to the pom
it *generates* as part of the "upload" (deploy) process.
And, yes, as Hardy mentioned as of the moment you need to do `gradle
idea` from command line to generate the IntelliJ project (ala `mvn
idea:idea`).
On Thu, 2010-06-17 at 14:52 +0200, Emmanuel Bernard 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 at hibernate.org
> >>> http://hibernate.org
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >
> > --
> > Steve Ebersole <steve at hibernate.org>
> > http://hibernate.org
> >
>
--
Steve Ebersole <steve at hibernate.org>
http://hibernate.org
More information about the hibernate-dev
mailing list