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 > >>> st...@hibernate.org > >>> http://hibernate.org > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev@lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > > > -- > > Steve Ebersole <st...@hibernate.org> > > http://hibernate.org > > > -- Steve Ebersole <st...@hibernate.org> http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
