| Organizing test code.. [message #549775] |
Tue, 27 July 2010 18:19  |
Eclipse User |
|
|
|
Folks,
In my Java application, I need to create a project "LibCommon" that contains code sharable across other projects.
Let's say my root workspace is d:\Dev. LibCommon can be organized as follows:
1. Create a project "LibCommon" at d:\Dev\LibCommon.
2. Source code goes to d:\Dev\LibCommon\src directory.
3. JUnit test code goes to d:\Dev\LibCommon\test directory.
4. Output (.class files) go to d:\Dev\LibCommon\bin directory.
5. For the main application project, use LibCommon as the project dependency.
This seems to be the prevalent practice. However, I am confused on setting up inter-project dependencies.
1. How do I set the project dependency such that
a) LibCommon.jar gets produced.
b) MainApp consumes LibCommon.jar.
c) JUnit test code consumes LibCommon.jar
2. Which directory should LibCommon.jar be produced in? Is common practice to create a staging area, perhaps at d:\Dev\StagingArea?
3. Although the test code as well as the actual code are part of a single project, I do not wish to include test code in LibCommon.jar. Ultimately, LibCommon.jar is part of customer shipment and there is no point in including test code in LibCommon.jar. How can I achieve this?
Thank you in advance for your help.
Regards,
Peter
|
|
|
| Re: Organizing test code.. [message #549786 is a reply to message #549775] |
Tue, 27 July 2010 19:23  |
| Eclipse User |
|
|
|
On 2010.07.27 16:19, Peter wrote:
> Folks,
>
> In my Java application, I need to create a project "LibCommon" that
> contains code sharable across other projects.
>
> Let's say my root workspace is d:\Dev. LibCommon can be organized as
> follows:
>
> 1. Create a project "LibCommon" at d:\Dev\LibCommon.
> 2. Source code goes to d:\Dev\LibCommon\src directory.
> 3. JUnit test code goes to d:\Dev\LibCommon\test directory.
> 4. Output (.class files) go to d:\Dev\LibCommon\bin directory.
> 5. For the main application project, use LibCommon as the project
> dependency.
>
> This seems to be the prevalent practice. However, I am confused on
> setting up inter-project dependencies.
>
> 1. How do I set the project dependency such that
> a) LibCommon.jar gets produced.
> b) MainApp consumes LibCommon.jar.
> c) JUnit test code consumes LibCommon.jar
>
> 2. Which directory should LibCommon.jar be produced in? Is common
> practice to create a staging area, perhaps at d:\Dev\StagingArea?
>
> 3. Although the test code as well as the actual code are part of a
> single project, I do not wish to include test code in LibCommon.jar.
> Ultimately, LibCommon.jar is part of customer shipment and there is no
> point in including test code in LibCommon.jar. How can I achieve this?
>
> Thank you in advance for your help.
>
> Regards,
> Peter
>
When you export a JAR representing the project, which you can do by hand
or via ant script, you do not include the test source subfolder. Because
of this, you do not need to worry about which projects have test code,
they can all have it, and none of it will roll into the project JAR
unless you specifically try to do it.
When you write your ant script (sorry, I'm not a Maven guy yet), you
write it so that it builds your (library) project and dumps a copy of
the resulting JAR into a lib subdirectory of each consuming project
(unless that project is a Dynamic Web Project in which case it's the
WebContent/WEB-INF/lib subdirectory).
This is the way I do it. There may be a better way. Maybe someone else
will chime in to say so.
Russ
|
|
|
|
| Re: Organizing test code.. [message #549925 is a reply to message #549799] |
Wed, 28 July 2010 09:37 |
| Eclipse User |
|
|
|
On 7/27/2010 7:19 PM, Peter wrote:
> Russ,
>
> Thank you for your help.
>
> Coming from Windows background, I keep on thinking of DLL projects and
> EXE projects and how EXE projects are dependent on DLL projects. I
> started to associate jar files with DLLs.
>
> After reading your post a couple of times, it appears to me that, under
> Java, a jar file has no meaning when it comes to developing and
> debugging. Jar file may mean something only from final deployment
> perspective.
>
> Is this right? Can I safely ignore jar files and any related issues
> until I plan for final deployment? Or, do I need to plan for it during
> design/development?
>
> Regards,
> Peter
I probably don't understand what's behind this question; I'm a Linux and
not a Windows guy. Surely it's analogous? When you deploy a Java
application, there is a class path off of which it accesses needed
resources. Deployment is gathering all of those things together.
Between parentheses, the JAR file can contain all sorts of thing besides
class files and specific resources (including properties and other
files, images, yada, yada, yada). It can also contain source and/or
Javadoc which you would wire up inside Eclipse for use in writing code
(hovering over an identifier and learning about it, ctrl-space bar to
get suggestions as you type, etc.).
Russ
|
|
|
Powered by
FUDForum. Page generated in 0.09705 seconds
Home