tags:

views:

169

answers:

4

Hi, I'd like to create a folder under a package in Eclipse... The purpose of this folder is merely for organizational purposes. Meaning, I don't want it to be another package. Every time I try to add a folder under a package, it just creates a package instead. I'd like to have the following structure:

project/src/package1/someClass.java
project/src/package1/someFOLDER/anotherClass.java
project/src/package1/package2/anotherFOLDER/oneOtherClass.java

Is it possible to do this without adding a package? I come from a .NET/C# and C++ background... here I'd just add a folder and the reference to that class would be updated in the project.

How can I just add an organizational folder in eclipse? Thanks

+5  A: 

Actually, folders are packages in Java so your question doesn't really make any sense in a Java context.

The term 'package' might be misleading... a package is definitely not the same as an assembly in .NET. You can think of 'package' more as a namespace, which in the Java world happens to be determined by the directory path.

For non-source files, you can create a new folder outside of your source folder, it will then be treated just like any other folder and not a package.

Martin
But then the external folder won't be considered part of the package? How on earth do people organize large projects?
Polaris878
packages are folders that contain source code. non-source code doesn't go in the package folder, it can go elsewhere.
matt b
"package", in a Java context, does *not* mean "deployable/distributable package"
matt b
A: 

Well packages ARE folders.

If you want Eclipse to not build the contents of the package/folder, right-click on the project, select Properties, and under Java > Build Path edit the inclusion/exclusion filters.

matt b
+2  A: 

If you're creating the folders to separate classes for organizational purposes, but still want them to be in the same package for access purposes, you can create multiple source folders and have them build into the same location. So, the folder hierarchy will look slightly different:

project/concern1_src/package1/someClass.java
project/concern2_src/package1/anotherClass.java
project/concern3_src/package1/package2/oneOtherClass.java

As I said, all three source folders can build into the same target directory. Or they can build into different target directories, if you like. The separate source folders will also carry over to the Package Explorer.

Rob Heiser
Note that the path within the source folders ("package1") still has to reflect the Java package declaration. So I am not sure if this approach will work too well from an organizational standpoint. It could be used to split between "public src" and "implementation src", but other kinds of splits would be difficult, especially if the "concerns" are different from package to package. One thing it does is put the parent folder into a completely different filesystem hierarchy than the subfolder, which seems a step backwards, actually.
Thilo
I was answering based on my guess about what the organizational purpose might be. The requirement was that a certain number of classes had to have package private access. In Java, that implies they either have to be in the same directory, or in a mirrored directory structure. The other hint was in a comment the inquirer made to another answer; in essence it was undesirable to have to look at 25-30 class files at the same time. In the end, my guess is that using Eclipse and Java more will lead to different ideas about how to navigate through the code.
Rob Heiser
"my guess is that using Eclipse and Java more will lead to different ideas about how to navigate through the code": That is the correct answer.
Thilo
+2  A: 

WTF are you supposed to do when you need multiple classes to be package private in a large project? Just look at your 25-30 class files all in the same directory?

That is a problem with Java's package system. Every package is a directory, and sub-packages are just different packages (no special visibility rules).

The most coarse visibility level is package-private, so that, yes, you have to lump your 25-30 files into the same package to avoid universally public visibility.

OSGi addresses this issue by introducing bundles, which can choose to not make packages visible to the outside. This gives you "project-private" packages.

Update: Also, you can reduce the number of files by putting related classes into the same source file. Only public classes need to have their own source file (I do prefer to have one file per class, though, public or not).

Thilo