Adrian Crum wrote: > --- 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 calfinal 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?
Separate calls to javac, which can make some classes of compile errors hide without explicitly doing a clean. > >>> 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? Sure. > >> 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? org.ofbiz.base.converters.ConverterLoader contains org.ofbiz.base.converters.test.TestCase$ConverterThatDoesSomethingBrokenDuringLoadingSoThatItCanBeTested A filename pattern will not detect the line that resides in the above file. > >> 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. I've got it working locally, for base. Will be applying it to the other components that have test classes. Currently, it'll only save about 145k of compressed bytecode data(based on the size of the jars). But that will probably increase as more source-level tests are added. We might always want to consider splitting ofbiz-component.xml, splitting screen/form/script resources, basically move out everything that is only used when tests are being run, and don't make it available at all during normal runs.
