>>
>> In terms of these other concerns, how about someone actually try
>> importing it and see if there are real, actual issues rather than us
>> discussing esoteric possibilities that there could maybe be some
>> more-or-less catastrophic problem importing them into eclipse ;)
>
> I'll see if I
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
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
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
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
26 matches
Mail list logo
