Excluding test classes from deployed Jars
Locked
Excluding test classes from deployed Jars
 
|
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.) What do you think? -Adrian |
Re: Excluding test classes from deployed Jars
|
|
the nightly build is compiled and used for testers.
so that might limit some testers. ========================= BJ Freeman http://bjfreeman.elance.com Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93> Specialtymarket.com <http://www.specialtymarket.com/> Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man <http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro> Adrian Crum sent the following on 4/17/2010 9:07 AM: > 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.) > > What do you think? > > -Adrian > > > > > |
Re: Excluding test classes from deployed Jars
|
|
In reply to this post by Adrian Crum-2
Separating out the test from the code is a recognized well established pattern for java development. I like it.
----- "Adrian Crum" <[hidden email]> 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.) > > What do you think? > > -Adrian |
Re: Excluding test classes from deployed Jars
|
In reply to this post by Adrian Crum-2
Yes, this vould be great ! we've already been speaking on doing this in this thread.
But I don't think it's needed to create a main dir, just adding a test dir under src is enough. http://n4.nabble.com/Renaming-of-java-junit-tests-td1755800.html#a1774188 |
Re: Excluding test classes from deployed Jars
|
|
Thanks for the link. I missed that thread.
-Adrian --- On Sat, 4/17/10, Erwan de FERRIERES <[hidden email]> wrote: > From: Erwan de FERRIERES <[hidden email]> > Subject: Re: Excluding test classes from deployed Jars > To: [hidden email] > Date: Saturday, April 17, 2010, 9:30 AM > > Yes, this vould be great ! we've already been speaking on > doing this in this > thread. > But I don't think it's needed to create a main dir, just > adding a test dir > under src is enough. > > http://n4.nabble.com/Renaming-of-java-junit-tests-td1755800.html#a1774188 > -- > View this message in context: http://n4.nabble.com/Excluding-test-classes-from-deployed-Jars-tp2014236p2014256.html > Sent from the OFBiz - Dev mailing list archive at > Nabble.com. > |
Re: Excluding test classes from deployed Jars
|
|
As per that thread, I was planning on doing this in conjunction with
renaming some of the tests. Shall I proceed? Bob On 2010-04-17, at 12:48 PM, Adrian Crum <[hidden email]> wrote: > Thanks for the link. I missed that thread. > > -Adrian > > --- On Sat, 4/17/10, Erwan de FERRIERES <erwan.de- > [hidden email]> wrote: > >> From: Erwan de FERRIERES <[hidden email]> >> Subject: Re: Excluding test classes from deployed Jars >> To: [hidden email] >> Date: Saturday, April 17, 2010, 9:30 AM >> >> Yes, this vould be great ! we've already been speaking on >> doing this in this >> thread. >> But I don't think it's needed to create a main dir, just >> adding a test dir >> under src is enough. >> >> http://n4.nabble.com/Renaming-of-java-junit-tests-td1755800.html#a1774188 >> -- >> View this message in context: http://n4.nabble.com/Excluding-test-classes-from-deployed-Jars-tp2014236p2014256.html >> Sent from the OFBiz - Dev mailing list archive at >> Nabble.com. >> > > > |
Re: Excluding test classes from deployed Jars
|
|
In reply to this post by Adrian Crum-2
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. Just use an appropriate pattern to put them into a separate jar. However, then the startup code needs to handle loading the correct jars. I've thought about this myself. |
Re: Excluding test classes from deployed Jars
|
|
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. > > Just use an appropriate pattern to put them into a separate jar. > 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. 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. 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. |
Re: Excluding test classes from deployed Jars
|
|
--- On Sat, 4/17/10, Adam Heath <[hidden email]> 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. |
Re: Excluding test classes from deployed Jars
|
|
Adrian Crum wrote:
> --- On Sat, 4/17/10, Adam Heath <[hidden email]> 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. |
Re: Excluding test classes from deployed Jars
|
|
On Apr 17, 2010, at 6:18 PM, Adam Heath wrote:
> 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. > Did we get closure on separating out the test and product artifacts in the src folder? It seems to me that separation would be a good thing as you have alluded to in your last paragraph. As for concerns with build dependencies, I would have thought that it would be standard practice for any (reasonable sized) change to go through a series of "clean-all", "run-install", "run-tests" before doing the commit. Certainly as the bulk of unit tests increase, it will have to be become standard practice to avoid failing builds. |
Re: Excluding test classes from deployed Jars
|
|
Robert Morley wrote:
> On Apr 17, 2010, at 6:18 PM, Adam Heath wrote: > >> 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. >> > > Did we get closure on separating out the test and product artifacts in > the src folder? It seems to me that separation would be a good thing as > you have alluded to in your last paragraph. As for concerns with build > dependencies, I would have thought that it would be standard practice > for any (reasonable sized) change to go through a series of "clean-all", > "run-install", "run-tests" before doing the commit. Certainly as the > bulk of unit tests increase, it will have to be become standard practice > to avoid failing builds. As far as I can tell, there is still some disagreement on how it should be done. Adam committed some stuff over the weekend - which I haven't looked at yet. -Adrian |
Re: Excluding test classes from deployed Jars
|
|
Adrian Crum wrote:
> Robert Morley wrote: >> On Apr 17, 2010, at 6:18 PM, Adam Heath wrote: >> >>> 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. >>> >> >> Did we get closure on separating out the test and product artifacts in >> the src folder? It seems to me that separation would be a good thing >> as you have alluded to in your last paragraph. As for concerns with >> build dependencies, I would have thought that it would be standard >> practice for any (reasonable sized) change to go through a series of >> "clean-all", "run-install", "run-tests" before doing the commit. >> Certainly as the bulk of unit tests increase, it will have to be >> become standard practice to avoid failing builds. > > As far as I can tell, there is still some disagreement on how it should > be done. Adam committed some stuff over the weekend - which I haven't > looked at yet. For every component that had classes in some test folder, there is now a foo-test.jar in build/lib. The existing ofbiz-component.xml classpath entries will still end up reading both jars, because it has a wildcard that fetches all jars in that folder. It'd be nice if the startup system would only load foo-test.jar when running tests, but that would take a bit more effort. At the very least, its now possible to create a full system deployment, using zip/deb/whatever, that doesn't even include the files that are only useful for testing purposes. ps: except that it's not, because at the very least entityengine.xml includes test database definitions. And ofbiz-component.xml also includes those test definitions. |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |