[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] Java packages and directory structure
|
The reason why JDT doesn't like this layout, is that compilation units are
no longer located at guessable locations (i.e. directory structure match
package statement). Thus our tools would need to draw a map of all the
files, parse them to find out what their package is, this would have a huge
performance hit.
Usually people argue that javac doesn't care, and thus we should do so.
Actually, if you use our batch compiler (through Ant adapter), it won't
care either. The reason for this is that if the compiler doesn't need to
find files, it will be happy with arbitrary source locations. So in brief,
if you pass all files to find on the command line of the tool, then yes it
will work. However, if you put the test units on the classpath, and not on
the command line, then javac (and our batch compiler) would fail to
discover them in unpredictable locations.
Have you considered using different source folders instead ? A source
folder is just a folder containing sources (organized under package
directory structure) and placed on a project build path. A project can make
use of as many source folders as it needs. For instance, when we develop
JDT/Core, we use 7 source folders (compiler, dom, model, ...) to be
organize our development effort.
Also, note that Eclipse supports package fragments: i.e. different source
folders with same packages in them. Thus the following would work fine:
Project
+- product
| +- com.SSMB.cfmapps.repository
+- tests
+- com.SSMB.cfmapps.repository
(in 2.1 builds, you could even nest the 'test/' source folder inside
'product/' if it made more sense to you. Also, you can associate a
different output folder per source folder, this means you could have your
test classfiles generated in a different spot than your product ones).
One more thing, given JUnit tests have some requirements in term of
classpath, why don't you simply define a test project containing them all,
which would prereq your product project ? By doing so, you would not
pollute your product project with JUnit on its classpath (assuming it is
not needed there), since developpers may simply start using it without
knowing it is forbidden.
|---------+------------------------------>
| | "Frost, Gary [IT]" |
| | <Gary.Frost@xxxxxxx|
| | m.au> |
| | Sent by: |
| | jdt-core-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 02/06/2003 06:48 AM|
| | Please respond to |
| | jdt-core-dev |
| | |
|---------+------------------------------>
>-----------------------------------------------------------------------------------------------------------------------------------|
| |
| To: "'jdt-core-dev@xxxxxxxxxxx'" <jdt-core-dev@xxxxxxxxxxx>, "'jdt-dev@xxxxxxxxxxx'" <jdt-dev@xxxxxxxxxxx> |
| cc: |
| Subject: [jdt-core-dev] Java packages and directory structure |
| |
>-----------------------------------------------------------------------------------------------------------------------------------|
We have recently switch over to using Eclipse in our team (after I
downloaded it at home for quick evaluation, and soon realised that the tool
rocks :)
However we have come across a bit of a stumbling block WRT package name vs
directory names.
We use JUnit tests throughout our system, and have adopted quite a standard
approach to the source organisation of the Unit Tests.
Given a package:
com.SSMB.cfmapps.repository
With an (interface) Repository.java and (class) SimpleRepository.java and
RepositoryFactory.java (all have package decleration "package
com.SSMB.cfmapps.repository")
We wish to create 2 unit test classes
SimpleRepositoryTest.java and RepositoryFactoryTest.java
And while we want the unit tests to live in the package
com.SSMB.cmfapps.repository (along side the interface and 2 classes), we
want to keep the source in a different directory (a subdirectory called
test).
I.e.
${project.src}/com/SSMB/cfmapps/repository/test/SimpleRepositoryTest.java
*But* the package for these test classes should not be
com.SSMB.cfmapps.repository.test, just com.SSMB.cfmapps.repository. I.e.
the source lives in a separate directory, but the compiled classes live in
the same package as the classes they are testing! This makes it nice and
easy to track Unit Test coverage and navigate/run unit tests relative to
the
given class, but also easy for us to ignore the /test directories when
building for deployment to production servers.
Eclipse (like a few other IDE's) seems to dislike this idea, it keeps
erroring/warning claiming "The declared package does not the expected
package com.SSMB.cfmapps.repository.test"
Is there anyway for us to turn this off, and ideally using pattern
matching,
e.g. Ignore directory/package name mismatch = "**/test" so that any java
file that lives in a directory tree ending in '/test' should be ignored for
package-directory checking.
Either way, the net result we expect is that the project should compile
without problems in this situation, and that after compilation we should be
able to browse to ${project.src}/com/SSB/cfmapps/repository and find
Repository.class
RepositoryFactory.class
RepositoryFactoryTest.class
SimpleRepository.class
SimpleRepositoryTest.class
Thanks for any help in advance, and I will say it again "Eclipse & JDT
rock"
:D
Gary
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
