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 <st...@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 <st...@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 >> <st...@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? >> >> >> >> >> > >> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
