2:28 p.m.
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(a)hibernate.org
http://hibernate.org
2:37 p.m.
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-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(a)hibernate.org
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
2:45 p.m.
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(a)hibernate.org
> http://hibernate.org
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
2:52 p.m.
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(a)hibernate.org
>> http://hibernate.org
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
2:56 p.m.
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
<emmanuel(a)hibernate.org> 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(a)hibernate.org
>>> http://hibernate.org
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
> --
> Steve Ebersole <steve(a)hibernate.org>
> http://hibernate.org
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3:33 p.m.
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(a)hibernate.org
>>> http://hibernate.org
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
> --
> Steve Ebersole <steve(a)hibernate.org>
> http://hibernate.org
>
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
7:44 p.m.
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 this is such a big deal, TBH. See caveat #1
below. Anyway I said effectively because you could do it with
includes/excludes as I mentioned before; but I am not a huge fan of
that.
2) Do we care whether src/testing compiles into the same directory as
where ever we end up compiling src/intgTest? The implication here is
that it is effectively not possible to then create a jar from just those
classes/ See caveat #2 below. Again, I said effectively here because
we can use includes/excludes here as well to achieve.
Caveats:
1) Gradle's build has a similar set up. What they do is to define the 2
sourceSets and have each compile to its own directory. In the IntelliJ
they tell it to use the same directory (a third one) for both.
2) Gradle plans to make sourceSets sensitive to the outputs they
explicitly contributed to the output dirs. Essentially the
includes/excludes become baked into the sourceSets themselves. In fact
Hans said they already know this information today and that it is just a
matter of applying it when you ask the sourceSet for its classes, etc.
On Thu, 2010-06-17 at 08:33 -0500, Steve Ebersole wrote:
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(a)hibernate.org
> >>> http://hibernate.org
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >
> > --
> > Steve Ebersole <steve(a)hibernate.org>
> > http://hibernate.org
> >
>
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
4:26 p.m.
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 directories, but only one classpath so you would
probably
be able to get things to compile or code complete in eclipse that won't compile in the
Gradle build but if that is not a concern
then things should be fine.
btw. Its really a shame core will no longer be easy to import into Eclipse.
It's back to the "everyone attempts their best in creating an eclipse
config" from the old Ant days ;(
/max
On Jun 17, 2010, at 19:44, Steve Ebersole wrote:
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 this is such a big deal, TBH. See caveat #1
below. Anyway I said effectively because you could do it with
includes/excludes as I mentioned before; but I am not a huge fan of
that.
2) Do we care whether src/testing compiles into the same directory as
where ever we end up compiling src/intgTest? The implication here is
that it is effectively not possible to then create a jar from just those
classes/ See caveat #2 below. Again, I said effectively here because
we can use includes/excludes here as well to achieve.
Caveats:
1) Gradle's build has a similar set up. What they do is to define the 2
sourceSets and have each compile to its own directory. In the IntelliJ
they tell it to use the same directory (a third one) for both.
2) Gradle plans to make sourceSets sensitive to the outputs they
explicitly contributed to the output dirs. Essentially the
includes/excludes become baked into the sourceSets themselves. In fact
Hans said they already know this information today and that it is just a
matter of applying it when you ask the sourceSet for its classes, etc.
On Thu, 2010-06-17 at 08:33 -0500, Steve Ebersole wrote:
> 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(a)hibernate.org
>>>>> http://hibernate.org
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>> --
>>> Steve Ebersole <steve(a)hibernate.org>
>>> http://hibernate.org
>>>
>>
>
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:40 p.m.
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 attempted in Gradle?)
Anyway, eclipse can have multiple output directories, but only one classpath so you would
probably
be able to get things to compile or code complete in eclipse that won't compile in
the Gradle build but if that is not a concern
then things should be fine.
btw. Its really a shame core will no longer be easy to import into Eclipse.
It's back to the "everyone attempts their best in creating an eclipse
config" from the old Ant days ;(
note, I haven't checked the last gradle eclipse stuff but last time it was *very*
basic.
But just wanted to point that out in case someone comes back and tell me they improved
it greatly in some recent release ;)
/max
5:10 p.m.
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 gradle eclipse plugin. Before you had mentioned enabling
"features" inside the eclipse project. What special features are we
using here?
To me in IntelliJ, that would equate to things like we are producing a
war and want container integration enabled. But we dont have that in
Hibernate
Or we are writing some groovy stuff and want the Groovy facet enabled.
Again, none of that here.
So I am totally lost what you mean here. Or are you just talking about
in general and there is no specific issue in importing Hibernate into
eclipse?
On Fri, 2010-06-18 at 16:40 +0200, Andersen Max wrote:
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 attempted in Gradle?)
>
> Anyway, eclipse can have multiple output directories, but only one classpath so you
would probably
> be able to get things to compile or code complete in eclipse that won't compile
in the Gradle build but if that is not a concern
> then things should be fine.
>
> btw. Its really a shame core will no longer be easy to import into Eclipse.
> It's back to the "everyone attempts their best in creating an eclipse
config" from the old Ant days ;(
note, I haven't checked the last gradle eclipse stuff but last time it was *very*
basic.
But just wanted to point that out in case someone comes back and tell me they improved
it greatly in some recent release ;)
/max
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
5:25 p.m.
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 of things you previously discussed as
lacking in the gradle eclipse plugin.
hmm...that is an example of the challenges with things not separated out.
note, for hibernate core this is probably fine in the IDE.
Before you had mentioned enabling
"features" inside the eclipse project. What special features are we
using here?
If I want to enable lets say the FindBugs plugin or some Antlr plugin
then it will overwritten by these shot-and-forget generation.
To me in IntelliJ, that would equate to things like we are producing
a
war and want container integration enabled. But we dont have that in
Hibernate
no, I know.
Or we are writing some groovy stuff and want the Groovy facet enabled.
Again, none of that here.
I thought the gradle scripts were groovy so sounds rather relevant here does it not ?
So I am totally lost what you mean here. Or are you just talking
about
in general and there is no specific issue in importing Hibernate into
eclipse?
Its certianly something you probably can live without and those using the IDE for more
than a java compiler and fancy editor its fine.
It is though a step backwards - but I agree its a smaller step backwards
than the step forward you hope to go with using Gradle instead of mvn.
/max
On Fri, 2010-06-18 at 16:40 +0200, Andersen Max wrote:
> 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 attempted in Gradle?)
>>
>> Anyway, eclipse can have multiple output directories, but only one classpath so
you would probably
>> be able to get things to compile or code complete in eclipse that won't
compile in the Gradle build but if that is not a concern
>> then things should be fine.
>>
>> btw. Its really a shame core will no longer be easy to import into Eclipse.
>> It's back to the "everyone attempts their best in creating an eclipse
config" from the old Ant days ;(
>
> note, I haven't checked the last gradle eclipse stuff but last time it was *very*
basic.
>
> But just wanted to point that out in case someone comes back and tell me they
improved
> it greatly in some recent release ;)
>
> /max
>
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
5:47 p.m.
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 regards to mixed jdks and some other
> stuff, but that is not the sort of things you previously discussed as
> lacking in the gradle eclipse plugin.
hmm...that is an example of the challenges with things not separated out.
note, for hibernate core this is probably fine in the IDE.
I do not follow this at all. Mixed JDKs *are* all isolated to projects.
So they are separated out. Nothing in that respect changes from what we
have today. Does it work in Eclipse today? If so, then in that respect
it will work in Eclipse here too.
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
certain stanza it does not touch it. If Eclipse does not do that, well,
not sure what to tell you.
I thought the gradle scripts were groovy so sounds rather relevant
here does it not ?
I am giving examples. Sheesh :)
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 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 ;)
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
6:01 p.m.
> 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
certain stanza it does not touch it. If Eclipse does not do that, well,
not sure what to tell you.
eclipses data is xml too (some properties) - if they've updated gradle to do merges
instead it will probably
work too.
> I thought the gradle scripts were groovy so sounds rather
relevant here does it not ?
I am giving examples. Sheesh :)
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 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 find time during some boring JBW session next week :))
Is there a page outlining which version of Gradle etc. I should minum be trying this with
?
Or is it all in this mail thread?
/max
6:14 p.m.
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 run `./gradlew eclipse`. Or if you wish to install
Gradle, use the lastest 0.9-preview-3 as of today, and run `gradle
eclipse` instead.
On Fri, 2010-06-18 at 18:01 +0200, Andersen Max wrote:
>
>> 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
> certain stanza it does not touch it. If Eclipse does not do that, well,
> not sure what to tell you.
eclipses data is xml too (some properties) - if they've updated gradle to do merges
instead it will probably
work too.
>> I thought the gradle scripts were groovy so sounds rather relevant here does it
not ?
>
> I am giving examples. Sheesh :)
>
> 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 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 find time during some boring JBW session next week :))
Is there a page outlining which version of Gradle etc. I should minum be trying this with
?
Or is it all in this mail thread?
/max
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
6:15 p.m.
On Fri, 18 Jun 2010 18:01:02 +0200, Andersen Max <max.andersen(a)redhat.com>
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 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 find time during some boring JBW session next week :))
Is there a page outlining which version of Gradle etc. I should minum be
trying this with ?
Or is it all in this mail thread?
You should use the latest gradle version - 0.9-preview2
Checkout the gradle branch
(https://svn.jboss.org/repos/hibernate/core/branches/gradle2)
and run 'gradle build'
There is a 'gradle idea' for generating the idea project files. I would
assume there is
the equivalent of 'gradle eclipse'
There were some discussions around the gradle build during the last couple
of weeks on
the mailing list.
In case you haven't seen, Steve summarized "why gradle' under
http://community.jboss.org/wiki/Gradlewhy
10:45 a.m.
>
> 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 find time during some boring JBW session next week :))
Just to let you know I simply haven't had time to try this out ;(
I am though moving hibernate tools to proper svn location (about time, eh ? :)
and in that move updating to use Maven (or at least trying to) - since
the divergence of different dependencies/API of hibernate 3.x is starting
to be hard to handle with just ant ;)
yes, I know - it's about time.
/max
5:05 p.m.
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 attempted in Gradle?)
Consider:
`cd core`
`mvn install` <- works ok, the *unit* tests passed
`cd ../testsuite`
`mvn test` <- well shoot, now we have failures.
Sure would have been nice if the hibernate-core installation could have
failed, huh? ;)
Anyway, eclipse can have multiple output directories, but only one classpath so you would
probably
be able to get things to compile or code complete in eclipse that won't compile in
the Gradle build but if that is not a concern
then things should be fine.
btw. Its really a shame core will no longer be easy to import into Eclipse.
It's back to the "everyone attempts their best in creating an eclipse
config" from the old Ant days ;(
`gradle eclipse`
Why is that "everyone attempts their best in creating an eclipse
config"?
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
5:21 p.m.
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, intellij nor netbeans would
be able to mimic
> what is being attempted in Gradle?)
Consider:
`cd core`
`mvn install` <- works ok, the *unit* tests passed
`cd ../testsuite`
`mvn test` <- well shoot, now we have failures.
Sure would have been nice if the hibernate-core installation could have
failed, huh? ;)
I thought Gradle had knowledge about these dependencies so the above aren't needed
even in multimodules ?
i.e. doesn't Gradle have something similar to mvn -am or mvn shell which know how to
build the "reactor" (maven's term, I
assume Gradle uses another one - in eclipse its just the project build dependencies)
> Anyway, eclipse can have multiple output directories, but only
one classpath so you would probably
> be able to get things to compile or code complete in eclipse that won't compile
in the Gradle build but if that is not a concern
> then things should be fine.
>
> btw. Its really a shame core will no longer be easy to import into Eclipse.
> It's back to the "everyone attempts their best in creating an eclipse
config" from the old Ant days ;(
`gradle eclipse`
Why is that "everyone attempts their best in creating an eclipse
config"?
Last time I used it launch configs were broken and the jdk it referred to were wrong
and if I enable some facets on the config gradle eclipse overwrites those settings.
mvn eclipse:eclipse or mvn idea:idea (name check) has the exact same problems - hence why
I always tell people to *not* use it
but use the IDE integration which can handle these things without overwriting you setup
;)
/max
5:25 p.m.
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. Like for example, does it build (and install) core and
*then* try to build the dependents? If so you have the same problem.
On Fri, 2010-06-18 at 17:21 +0200, Andersen Max wrote:
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, intellij nor netbeans
would be able to mimic
>> what is being attempted in Gradle?)
>
> Consider:
> `cd core`
> `mvn install` <- works ok, the *unit* tests passed
> `cd ../testsuite`
> `mvn test` <- well shoot, now we have failures.
>
> Sure would have been nice if the hibernate-core installation could have
> failed, huh? ;)
I thought Gradle had knowledge about these dependencies so the above aren't needed
even in multimodules ?
i.e. doesn't Gradle have something similar to mvn -am or mvn shell which know how to
build the "reactor" (maven's term, I
assume Gradle uses another one - in eclipse its just the project build dependencies)
>> Anyway, eclipse can have multiple output directories, but only one classpath so
you would probably
>> be able to get things to compile or code complete in eclipse that won't
compile in the Gradle build but if that is not a concern
>> then things should be fine.
>>
>> btw. Its really a shame core will no longer be easy to import into Eclipse.
>> It's back to the "everyone attempts their best in creating an eclipse
config" from the old Ant days ;(
>
> `gradle eclipse`
>
> Why is that "everyone attempts their best in creating an eclipse
> config"?
Last time I used it launch configs were broken and the jdk it referred to were wrong
and if I enable some facets on the config gradle eclipse overwrites those settings.
mvn eclipse:eclipse or mvn idea:idea (name check) has the exact same problems - hence why
I always tell people to *not* use it
but use the IDE integration which can handle these things without overwriting you setup
;)
/max
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
2:43 p.m.
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.
--Hardy
On Thu, 17 Jun 2010 14:28:25 +0200, Steve Ebersole <steve(a)hibernate.org>
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(a)hibernate.org
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
7:53 p.m.
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 testing would look like:
org/hibernate/junit/**
org/hibernate/test/annotations/**
org/hibernate/test/cache/**
org/hibernate/test/tm/**
(lets forget the "org/hibernate/test/annotations/**" pattern and the
fact that we also want to merge hibernate-annotations and its test suite
using this package in here as well for the moment).
What happens when we want to add a unit test for some cache related
class and we use the org.hibernate.test.cache package for the test too?
What happens when we want to add some testing support classes related to
in container testing with arquillian and add a new
org.hibernate.test.arquillian package in src/testing/java? Who gets to
remember these and update them accordingly?
I am just being very honest about my memory. It sucks and I guarantee I
will forget to update these includes/excludes appropriately. In my
opinion I use a build tool so that I don't have to remember these little
details.
On Thu, 2010-06-17 at 14:43 +0200, Hardy Ferentschik wrote:
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.
--Hardy
On Thu, 17 Jun 2010 14:28:25 +0200, Steve Ebersole <steve(a)hibernate.org>
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(a)hibernate.org
> http://hibernate.org
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
2:36 p.m.
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 know anyways where to
place them or
at least you should have thought about it. Besides, how often will the
testing
classes change.
Nicest of course would be the built-in gradle support you mentioned.
--Hardy
On Thu, 17 Jun 2010 19:53:29 +0200, Steve Ebersole <steve(a)hibernate.org>
wrote:
What happens when we want to add a unit test for some cache related
class and we use the org.hibernate.test.cache package for the test too?
What happens when we want to add some testing support classes related to
in container testing with arquillian and add a new
org.hibernate.test.arquillian package in src/testing/java? Who gets to
remember these and update them accordingly?
4:21 p.m.
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 do not
think hibernate-testing is "important" enough to publish which was one
of my exact questions before because it means some of this becomes far
easier to deal with.
On Fri, 2010-06-18 at 14:36 +0200, Hardy Ferentschik wrote:
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 know anyways where to
place them or
at least you should have thought about it. Besides, how often will the
testing
classes change.
Nicest of course would be the built-in gradle support you mentioned.
--Hardy
On Thu, 17 Jun 2010 19:53:29 +0200, Steve Ebersole <steve(a)hibernate.org>
wrote:
> What happens when we want to add a unit test for some cache related
> class and we use the org.hibernate.test.cache package for the test too?
> What happens when we want to add some testing support classes related to
> in container testing with arquillian and add a new
> org.hibernate.test.arquillian package in src/testing/java? Who gets to
> remember these and update them accordingly?
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
4:28 p.m.
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 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 do not
think hibernate-testing is "important" enough to publish which was one
of my exact questions before because it means some of this becomes far
easier to deal with.
On Fri, 2010-06-18 at 14:36 +0200, Hardy Ferentschik wrote:
> 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 know anyways where to
> place them or
> at least you should have thought about it. Besides, how often will the
> testing
> classes change.
>
> Nicest of course would be the built-in gradle support you mentioned.
>
> --Hardy
>
> On Thu, 17 Jun 2010 19:53:29 +0200, Steve Ebersole <steve(a)hibernate.org>
> wrote:
>
>> What happens when we want to add a unit test for some cache related
>> class and we use the org.hibernate.test.cache package for the test too?
>> What happens when we want to add some testing support classes related to
>> in container testing with arquillian and add a new
>> org.hibernate.test.arquillian package in src/testing/java? Who gets to
>> remember these and update them accordingly?
>
>
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:47 p.m.
On Fri, 18 Jun 2010 16:21:57 +0200, Steve Ebersole <steve(a)hibernate.org>
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.Session?
Personally I have no problem renaming classes in the testing artifact.
IMO there is a difference between changing something in the testing classes
compared to changing runtime package/class names.
And if there is a difference in your mind, then I'd argue you do
not
think hibernate-testing is "important" enough to publish which was one
of my exact questions before because it means some of this becomes far
easier to deal with.
I don't think there is much use of this artifact publicly. For us it
is important to share a common testing setup between modules. For example,
EM is a consumer of the testing artifact.
Should there be a testing artifact with base classes for writing tests -
yes.
Does this testing artifact needs to be published into the maven repo - not
sure.
On Fri, 2010-06-18 at 14:36 +0200, Hardy Ferentschik wrote:
> 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 know anyways where to
> place them or
> at least you should have thought about it. Besides, how often will the
> testing
> classes change.
>
> Nicest of course would be the built-in gradle support you mentioned.
>
> --Hardy
>
> On Thu, 17 Jun 2010 19:53:29 +0200, Steve Ebersole <steve(a)hibernate.org>
> wrote:
>
> > What happens when we want to add a unit test for some cache related
> > class and we use the org.hibernate.test.cache package for the test
> too?
> > What happens when we want to add some testing support classes related
> to
> > in container testing with arquillian and add a new
> > org.hibernate.test.arquillian package in src/testing/java? Who gets
> to
> > remember these and update them accordingly?
>
>
5:11 p.m.
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 +0200, Steve Ebersole
<steve(a)hibernate.org>
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.Session?
Personally I have no problem renaming classes in the testing artifact.
IMO there is a difference between changing something in the testing classes
compared to changing runtime package/class names.
> And if there is a difference in your mind, then I'd argue you do not
> think hibernate-testing is "important" enough to publish which was one
> of my exact questions before because it means some of this becomes far
> easier to deal with.
I don't think there is much use of this artifact publicly. For us it
is important to share a common testing setup between modules. For example,
EM is a consumer of the testing artifact.
Should there be a testing artifact with base classes for writing tests -
yes.
Does this testing artifact needs to be published into the maven repo - not
sure.
> On Fri, 2010-06-18 at 14:36 +0200, Hardy Ferentschik wrote:
>> 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 know anyways where to
>> place them or
>> at least you should have thought about it. Besides, how often will the
>> testing
>> classes change.
>>
>> Nicest of course would be the built-in gradle support you mentioned.
>>
>> --Hardy
>>
>> On Thu, 17 Jun 2010 19:53:29 +0200, Steve Ebersole <steve(a)hibernate.org>
>> wrote:
>>
>> > What happens when we want to add a unit test for some cache related
>> > class and we use the org.hibernate.test.cache package for the test
>> too?
>> > What happens when we want to add some testing support classes related
>> to
>> > in container testing with arquillian and add a new
>> > org.hibernate.test.arquillian package in src/testing/java? Who gets
>> to
>> > remember these and update them accordingly?
>>
>>
>
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
6:15 p.m.
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 <steve(a)hibernate.org>
wrote:
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 +0200, Steve Ebersole <steve(a)hibernate.org>
> 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.Session?
>
> Personally I have no problem renaming classes in the testing artifact.
> IMO there is a difference between changing something in the testing
> classes
> compared to changing runtime package/class names.
>
>
> > And if there is a difference in your mind, then I'd argue you do not
> > think hibernate-testing is "important" enough to publish which was
one
> > of my exact questions before because it means some of this becomes far
> > easier to deal with.
>
> I don't think there is much use of this artifact publicly. For us it
> is important to share a common testing setup between modules. For
> example,
> EM is a consumer of the testing artifact.
>
> Should there be a testing artifact with base classes for writing tests -
> yes.
> Does this testing artifact needs to be published into the maven repo -
> not
> sure.
>
>
> > On Fri, 2010-06-18 at 14:36 +0200, Hardy Ferentschik wrote:
> >> 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 know anyways where to
> >> place them or
> >> at least you should have thought about it. Besides, how often will
> the
> >> testing
> >> classes change.
> >>
> >> Nicest of course would be the built-in gradle support you mentioned.
> >>
> >> --Hardy
> >>
> >> On Thu, 17 Jun 2010 19:53:29 +0200, Steve Ebersole
> <steve(a)hibernate.org>
> >> wrote:
> >>
> >> > What happens when we want to add a unit test for some cache related
> >> > class and we use the org.hibernate.test.cache package for the test
> >> too?
> >> > What happens when we want to add some testing support classes
> related
> >> to
> >> > in container testing with arquillian and add a new
> >> > org.hibernate.test.arquillian package in src/testing/java? Who
> gets
> >> to
> >> > remember these and update them accordingly?
> >>
> >>
> >
>
5306
days inactive
5328
days old
26 comments
4 participants
participants (4)
-
Andersen Max -
Emmanuel Bernard -
Hardy Ferentschik -
Steve Ebersole