On Fri, 18 Jun 2010 18:01:02 +0200, Andersen Max
wrote:
>> All I was asking about was paths and how they relate to Eclipse since I
>> have no clue. You asked questions outside my initial query and I was
>> simply trying to answer those for you.
>>
>> In terms of these other concerns, how about
Would it be acceptable to refactor it and use it only internally (no
pulishing).
Or maybe make a new start? Make 'testing' obsolete, refactor the current
code and
call it 'testutil' or 'testing2' (or whatever).
--Hardy
On Fri, 18 Jun 2010 17:11:21 +0200, Steve Ebersole
wrote:
> That does
Its all in this mailing list. But the relevant information is to use
the latest version of Gradle. Feel free to try out the Gradle Wrapper
stuff I discussed before on list as well and you wont even have to
install Gradle. You'd just `cd` to the root of the checkout of the
"gradle2" branch and ru
>
>> If I want to enable lets say the FindBugs plugin or some Antlr plugin
>> then it will overwritten by these shot-and-forget generation.
>
> In the IntelliJ plugin the idea is merging of information. IntelliJ
> config files are all XML. So if the Gradle plugin does not understand a
> certai
On Fri, 2010-06-18 at 17:25 +0200, Andersen Max wrote:
> On Jun 18, 2010, at 17:10, Steve Ebersole wrote:
>
> > How does it not work with Hibernate though? I mean at the end of the
> > day, Hibernate is not that complicated of a project structure. Yes
> > there are some peculiarities with regard
How does it not work with Hibernate though? I mean at the end of the
day, Hibernate is not that complicated of a project structure. Yes
there are some peculiarities with regards to mixed jdks and some other
stuff, but that is not the sort of things you previously discussed as
lacking in the gradl
On Jun 18, 2010, at 17:10, Steve Ebersole wrote:
> How does it not work with Hibernate though? I mean at the end of the
> day, Hibernate is not that complicated of a project structure. Yes
> there are some peculiarities with regards to mixed jdks and some other
> stuff, but that is not the sort
testsuite depends on core. In dependency-speak it is a dependent. For
example, if you reverse it:
`cd testsuite`
`gradle test`
Gradle does in fact know to try and build core first because of the
dependency.
It does have some support for building dependents as well but I have not
played with it.
On Jun 18, 2010, at 17:05, Steve Ebersole wrote:
> On Fri, 2010-06-18 at 16:26 +0200, Andersen Max wrote:
>> I'm still confused why these things are to be mixed together and not just
>> separated out so the IDE's classpath/scopes
>> matches the compile scopes (seems like neither Eclipse, intelli
That does not fly with me.
If an artifact is published it is public. Truth be told we have no clue
who uses this artifact.
And a published artifact mandates a certain level of backwards
compatibility.
On Fri, 2010-06-18 at 16:47 +0200, Hardy Ferentschik wrote:
> On Fri, 18 Jun 2010 16:21:57 +
On Fri, 2010-06-18 at 16:26 +0200, Andersen Max wrote:
> I'm still confused why these things are to be mixed together and not just
> separated out so the IDE's classpath/scopes
> matches the compile scopes (seems like neither Eclipse, intellij nor netbeans
> would be able to mimic
> what is being
Wrt running in eclipse most likely the errors are related to "expected
failures" which our junit extensions handle automatically when run from
the build. In IntelliJ I enable that as well so that I do not see the
"false negatives". There is a system property you need to set in order
for that to h
On Fri, 18 Jun 2010 16:21:57 +0200, Steve Ebersole
wrote:
> hibernate-testing is a published artifact. It currently defines classes
> in the org.hibernate.test package. Why is changing this any different
> than say changing the package of org.hibernate.Session to
> org.hibernate.something.Ses
On Jun 18, 2010, at 16:26, Andersen Max wrote:
> I'm still confused why these things are to be mixed together and not just
> separated out so the IDE's classpath/scopes
> matches the compile scopes (seems like neither Eclipse, intellij nor netbeans
> would be able to mimic
> what is being attem
aren't hibernate-testing artifact sensible in the sense of creating dialects
externally from hibernate base ?
/max
On Jun 18, 2010, at 16:21, Steve Ebersole wrote:
> hibernate-testing is a published artifact. It currently defines classes
> in the org.hibernate.test package. Why is changing th
I'm still confused why these things are to be mixed together and not just
separated out so the IDE's classpath/scopes
matches the compile scopes (seems like neither Eclipse, intellij nor netbeans
would be able to mimic
what is being attempted in Gradle?)
Anyway, eclipse can have multiple output
hibernate-testing is a published artifact. It currently defines classes
in the org.hibernate.test package. Why is changing this any different
than say changing the package of org.hibernate.Session to
org.hibernate.something.Session?
And if there is a difference in your mind, then I'd argue you
Is this really an issue and this not be solved by some package/class
renaming.
Why cannot all tests live under org/hibernate/test and all testing util
classes
under org/hibernate/testing. Filtering is in this case straight forward
and if you
want to extend testing util classes you need to kno
18 matches
Mail list logo
