[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[jdt-core-dev] RE: jdt-core-dev digest, Vol 1 #157 - 2 msgs
|
Philippe,
Thanks for the response, yeah I can see why the handling of different dirs
to packages would be computationally expensive, we have got around 150
classes in our application core so would hate the added slowdown involved in
handling this.
I think we're going to go the way of
Project/src/java/core/com/SSMB/cfmapps/repository/...
Project/src/java/test/com/SSMB/cfmapps/repository/...
This will actually work well because we also use Ant, so our build.xml can
handle the 'Don't put JUnit on class path for Production/Release build' kind
of issues, infact we can compile the Project/src/java/test into a test.jar,
and the Project/src/java/core into ourapp.jar, using this dir structure will
give us a lot more control.
We'll probably also write something (unless anyone here already knows of a
tool) that will give us a coverage report of classes in
Project/src/java/test to Project/src/java/core, that gives us details of
ratio of tests/implementation, untested classes, etc.
Anyway, thanks for the input, I'm going to "Make it so" right now :D
Gary
-----Original Message-----
From: jdt-core-dev-request@xxxxxxxxxxx
[mailto:jdt-core-dev-request@xxxxxxxxxxx]
Sent: Friday, 7 February 2003 4:00 AM
To: jdt-core-dev@xxxxxxxxxxx
Subject: jdt-core-dev digest, Vol 1 #157 - 2 msgs
Send jdt-core-dev mailing list submissions to
jdt-core-dev@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
or, via email, send a message with subject or body 'help' to
jdt-core-dev-request@xxxxxxxxxxx
You can reach the person managing the list at
jdt-core-dev-admin@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of jdt-core-dev digest..."
Today's Topics:
1. Java packages and directory structure (Frost, Gary [IT])
2. Re: Java packages and directory structure (Philippe P Mulet)
--__--__--
Message: 1
From: "Frost, Gary [IT]" <Gary.Frost@xxxxxxxxxxx>
To: "'jdt-core-dev@xxxxxxxxxxx'" <jdt-core-dev@xxxxxxxxxxx>,
"'jdt-dev@xxxxxxxxxxx'" <jdt-dev@xxxxxxxxxxx>
Date: Thu, 6 Feb 2003 16:48:53 +1100
Subject: [jdt-core-dev] Java packages and directory structure
Reply-To: jdt-core-dev@xxxxxxxxxxx
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
--__--__--
Message: 2
Subject: Re: [jdt-core-dev] Java packages and directory structure
To: jdt-core-dev@xxxxxxxxxxx
From: "Philippe P Mulet" <philippe_mulet@xxxxxxxxxx>
Date: Thu, 6 Feb 2003 11:35:14 +0100
Reply-To: jdt-core-dev@xxxxxxxxxxx
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
--__--__--
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
End of jdt-core-dev Digest
