I've looked at our commons testing again, and personally I'm not sure if we need most of the stuff anyway :)
Let's have a look at the packages: 1. o.a.s.adapter.internal Helper stuff if you're using adapter managers. If this has some common interest we could move this to the sling testing module. 2. o.a.s.c.testing.integration Some http stuff which is only of interest for integration testing. Doesn't really hurt, but there is rarely interest in plain junit tests. 3. o.a.s.c.testing.jcr Some Mock classes for JCR and the RepositoryUtil - I think this class is great for doing JCR based tests - however I think this is something Jackrabbit should provide us! In addition we currently have a dependency to Sling API here, so we have to split it anyway. 4. o.a.s.c.testing.osgi Just mocks for some OSGi interfaces - I see no need for these as mock libs like jmock or easymock can be used instead. 5. o.a.s.c.testing.sling Mocks for some sling apis - again, I see no need for explicit mock classes. 6. o.a.s.c.testing.util A single class with a single String method that replaces "\n" with a dot. Don't think that this is of general use - it is only used in the jst bundle atm, so we should rather move it there. As a conclusion I think we don't need a commons testing module, given the fact that jackrabbit would provide us a repository util class that can easily be used for testing - I think this makes sense to be provided by Jackrabbit for all possible clients of Jackrabbit not just sling. The relevant stuff dealing with Sling specific test helpers can then be moved into the new module. Carsten -- Carsten Ziegeler cziege...@apache.org
