To me it has nothing to do with convention. My concern is the
maintenance of that. We have this issue somewhat today as well in the
Maven build with building release bundles. Its a matter of remembering
to add/subtract from these include/exclude lists. For example, today
the includes for testin
So I think it really comes down to the answer to 2 questions:
1) Do we care whether src/test and src/intgTest compile into the same
directory? The implication there is that you would effectively not be
able to set up two different test tasks to run unit and integration
tests separately. Not sure
I've not see the exception raised by PostgreSQL though my name got truncated
for a while ;)
On 17 juin 2010, at 16:40, Steve Ebersole wrote:
> It seems like you got this "minro db" list based on the overrides of
> this method. Keep in mind that this list does not seem accurate. It
> sure seems
It seems like you got this "minro db" list based on the overrides of
this method. Keep in mind that this list does not seem accurate. It
sure seems like postgresql and db2 fall into this category as well
unless i am misunderstand the test failure discussion here.
Like I said there is another opt
There are two things at stake here.
DDLWithoutCallbackTest was initially designed to check that the event listener
validation is ignored. Hence the catch
(javax.validation.ConstraintViolationException) {fail();}
What I forgot is that the test my still fails due to a database constraint
error :
Last milestone build before 4.1.0.Final - http://in.relation.to/15886.lace
Time to think about new features for post 4.1 :)
--Hardy
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
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
The idea is to use the gradle idea plugin
> gradle idea
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
wrote:
> I thought gradle kept the pom dependency information
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
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 i
I opt for class filtering. We can fold testing back into src/test.
As you are saying we can then create an additional testing jar using class
in- and excludes.
I've done this before in another project using ant and it worked just fine.
Of course a true conventionalist will crucify me for that.
-
How much manual change is required in the IDE configuration for that? Assuming
we start with a pom.xml 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-testsui
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) s
The 3.5.3-Final release is available for use. See
http://in.relation.to/Bloggers/Hibernate353FinalRelease for details.
Enjoy!
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
14 matches
Mail list logo
