You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@yahoo.com> on 2010/04/17 18:07:39 UTC
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
Posted by Robert Morley <rm...@emforium.com>.
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 <ad...@yahoo.com> wrote:
> Thanks for the link. I missed that thread.
>
> -Adrian
>
> --- On Sat, 4/17/10, Erwan de FERRIERES <erwan.de-
> ferrieres@nereide.fr> wrote:
>
>> From: Erwan de FERRIERES <er...@nereide.fr>
>> Subject: Re: Excluding test classes from deployed Jars
>> To: dev@ofbiz.apache.org
>> 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
Posted by Adrian Crum <ad...@yahoo.com>.
Thanks for the link. I missed that thread.
-Adrian
--- On Sat, 4/17/10, Erwan de FERRIERES <er...@nereide.fr> wrote:
> From: Erwan de FERRIERES <er...@nereide.fr>
> Subject: Re: Excluding test classes from deployed Jars
> To: dev@ofbiz.apache.org
> 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
Posted by Erwan de FERRIERES <er...@nereide.fr>.
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
Posted by Adam Heath <do...@brainfood.com>.
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.
Re: Excluding test classes from deployed Jars
Posted by Adrian Crum <ad...@hlmksw.com>.
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
Posted by Robert Morley <rm...@emforium.com>.
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
Posted by Adam Heath <do...@brainfood.com>.
Adrian Crum wrote:
> --- On Sat, 4/17/10, Adam Heath <do...@brainfood.com> 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
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Sat, 4/17/10, Adam Heath <do...@brainfood.com> 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
Posted by Adam Heath <do...@brainfood.com>.
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
Posted by Adam Heath <do...@brainfood.com>.
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
Posted by Marc Morin <ma...@emforium.com>.
Separating out the test from the code is a recognized well established pattern for java development. I like it.
----- "Adrian Crum" <ad...@yahoo.com> 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