--- On Sat, 4/17/10, Adam Heath <[email protected]> wrote: > Adam Heath wrote: > > Adrian Crum wrote: > >> Right now the test classes are included in each > component's jar file. It seems to me it might save on memory > or the target server's disk space if the test classes were > left out of the component's final jar file. > >> > >> Maybe have a folder structure something like: > >> > >> component > >> src > >> main > >> org > >> ofbiz > >> > etc... > >> test > >> org > >> ofbiz > >> > etc... > >> > >> The main branch is for the deployment jar and the > test branch is only for test classes. The end result would > be you could have a separate build for the test classes that > wouldn't put them in the final jar. Another advantage is the > test classes can be in the same package as the classes they > test. (The current setup is a pain in that respect.) > > > > There is no reason to move the source for the > tests. If fact, that is > > actually a bad thing to do.
Why? > > Just use an appropriate pattern to put them into a > separate jar. Like have the build target exclude the test classes by using a file name pattern match? > > However, then the startup code needs to handle loading > the correct > > jars. I've thought about this myself. > > This is complicated if any classes in foo-test.jar are > registered in > META-INF/services, while normal classes are also so > registered. Can't each src branch have its own META-INF folder? > Also, if a test class is registed as some normal interface, > the name > of the file in META-INF/services will not match the > *.test.* pattern. Huh? Could you gave an example please? > If we want to keep a single src directory(which is what I > prefer), > then src/META-INF/services has to go. In its place, > <jar>'s nested > <service> element will have to be used. I know it works because that's how Commons is set up. I haven't run into any problems so far.
