[hibernate-dev] Project layout

[Hardy Ferentschik]

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 at 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 at 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 at 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?
>> >>
>> >>
>> >
>>
>