Package name does not correspond to file path

I'm having trouble getting my head around the new module paradigm. What I was expecting was the modules would replace the multiple project files that were maintained for IntelliJ 3.0. However, it isn't as straightforward as that.

The project that I'm working one has the following (much pared-down)directory structure:

c:/myco/src/com/myco/util
c:/myco/src/com/myco/engine
c:/myco/src/com/myco/manager
c:/myco/javaout/class/com/myco/util
c:/myco/javaout/class/com/myco/engine
c:/myco/javaout/class/com/myco/manager

With IntelliJ 3.0, each src leaf directory had an ipr and iws file, in other words, each subdirectory was a project. As a result, in the above example, we had Util, Engine and Manager projects. This worked well, because, in general, a single developer is/was responsible for a single sub-project.

I would expect that, with Aurora, we would have one module per sub-project directory and the modules would correspond to the 3.0 projects. However, I'm having some difficulty setting this up properly.

If, for example, I define the Util module as:
Content: c:/myco/src
Source Folder: ./com/myco/util
Output path: c:/myco/javaout/class
the background code analysis on each java file complains that "Package name 'com.myco.util' does not correspond to file path ''" and, in the Project tab, the whole src directory is explorable.

If I define the Util module as per the following:
Content: c:/myco/src/com/myco/util
Source Folder: ./
Output path: c:/myco/javaout/class/com/myco/util
The second problem is resolved but I get the same problem with the the background code analysis.

The only way that I've found to get this to work correctly is to use the Exclude path liberally :(
Content: c:/myco/src
Source Folder ./
Output path: c:/myco/javaout/class
Exclude path: c:/myco/src/com/myco/engine
Exclude Path: c:/myco/src/com/myco/manager

This is okay when you've only got a few paths to exclude, however, the 'real' project has considerably more source directories than this example shows. This means that there is considerably more set up required for each sub-project, if this is the only way to accomplish what I want.

I've got to believe that there's something I'm missing.... Please!

12 comments

I'm pretty sure you want the Content for each module to be c:/myco, the source path to be src, and the output path to be javaout/class. After that, you are going to have to reorganize your source directory structure or use exclude as you said.

0

If it were me, I'd split 'em into different content paths. If it's worth having the functionality in different modules, it's probably worth putting 'em in different root directories.

--Dave

0

First of all, thanks for your quick replies. I do appreciate the help.

Up until the time I received your replies, I was sure that I was being stupid and missing something entirely - it certainly wouldn't have been the first time :)

But if what you're saying is correct, this means that Aurora is requiring me to change a directory structure (and, believe me, this is no small task) that worked fine in 3.0 and has worked fine with another IDE (JBuilder). Given that the rest of this product is excellent, I can't believe that I have to do this. Please, tell me I'm wrong!

If I'm not, am I correct in thinking that the optimum solution (without reorganizing the directory structure) would be to get rid of the idea of subprojects altogether and have one project file maintain all the source files in the project? This is a project with approximately 2000 java files, (500Kloc), and 500 jsps (150kloc). This is not an attractive proposition (but probably more acceptable than reorganizing the directory structure).

As another alternative to reorganizing the directory structure, I originally thought I'd be able to use many exclude paths to do what I want (yuck), however, I'm no longer certain that that alternative is feasible. The reason for this is the test directories. I have the following:

c:/myco/src/com/myco/util
c:/myco/src/com/myco/util/test <-- test directory for util sub project

Since the test directory is a sub directory of the subproject directory, how can I define the Test Folder? I can't specify it as c:/myco/src/com/myco/util/test as I'll get the same problem that originated this thread: "Package name does not match file path''".

Finally, if I were to reorganize the source tree (something that an IDE should not force me to do!) would the correct organization be the following?

c:/myco/util/src/com/myco/util
c:/myco/engine/src/com/myco/engine
c:/myco/manager/src/com/myco/manager
c:/myco/util/testsrc/com/myco/util
c:/myco/engine/testsrc/com/myco/engine
c:/myco/manager/testsrc/com/myco/manager

So that I could do the following for the Util project:
Content: c:/myco/util
Source Path: c:/myco/util/src
Output Path: c:/myco/util/javaout/class
Test Folder: c:/myco/util/testsrc

Again, thanks for all of your help.

0

Caveat 1) I'm not a JetBrains employees (you can tell by the lack of an IDEA icon by my name), so don't take anything I say as gospel.

Caveat 2) The modules system is still in flux, so even if the answers I gave are correct, they might still change.

The directory organization you describe (separate roots for each module, a separate src and testsrc directory under that, and no excludes) is what I do, and what I would strongly suggest to anyone starting a new project. Very clean, very simple, tests and sources separated, (which makes searches and inspections more powerful, but still allows tests and source put in the same package, enabling testing of package-private functionality), and it fits neatly into the module structure and most modern VCS's. Upon reflection, I probably wouldn't recommend it for a large project set up as you describe. Too much work (moving 2500 files is not trivial in any production VCS), not enough payoff. Given what you say, a one-module solution is probably as good as you're going to do.

0

Thanks again for the quick reply.

Given that this new module paradigm (assuming it doesn't change) is going to cause severe problems with the directory structure in use in our project, I would expect it to cause similar problems in others.

Am I the only one experiencing this? Is the directory structure that we're using that weird?

I believe that this is a bug. Anyone else?

0

Personally I think your project's path setup is "bad." I think just like IDEA encourages proper naming syntax and code style in other areas (though most others are configurable), it is encouraging good directory structure, and I think that's a good thing.

0

Thanks for replying.

Yes, you may think it is 'bad' (and obviously Idea developers do, too) but this is only recently. Remember, Ariadne had no problem with it. And, I'm not so sure it is bad - the only problem I've experienced this directory structure is with IntelliJ 4.0.

And, it isn't just encouraging its new structure, it is enforcing it.

Although I don't want to get into a religious war, I'm not so sure it is 'bad'. The directory structure is for a single weblogic application (obviously a large one), and can be viewed as a single project. However, since it is so large it has been split, logically and physically, into multiple sub-projects. The module paradigm of Aurora encourages these sub-projects to be treated as stand alone projects (which they are, in some respects but on other respects, they're not).

I think that some more thought should go into this module paradigm so that working with large projects that have a number of constituent parts does not result in an unwieldy project. (Although I'm afraid I might be too late in raising my concerns.)

Unfortunately, I don't have any suggestions as to how to fix this problem, I just know that what I have now won't work very well for our project. Which is a darn shame - I'm really looking forward to HotSwap.

0

I agree that maybe this should be an option, but on the other hand, I used to have what are definitely separate things (tests, library code, demo code) in the same source folder (as you do), and I find things are easier for me now that IDEA encouraged me to split these up with each as a separate module and content dir. It's easier to maintain ant build files, easier to make backup copies of only the code I want to back up, and I think it helps me to mentally separate the three.

0

On 2003/11/04 23:45, David Macklem wrote:

Unfortunately, I don't have any suggestions as to how to fix this
problem, I just know that what I have now won't work very well for
our project. Which is a darn shame - I'm really looking forward to
HotSwap.


You should at least report this as a bug. How else would Jetbrains know
this is really a problem for you? And please post a link to it here, so
people with the same problem can vote for it.

Regards,
Bas

0

Hmm, I wouldn't say that it is enforcing the directory structure. You can still use multiple projects, as you did under Ariadna. The only thing you lose in going to Aurora is the "Multiple Output Directory" option (insert Hani complaint here), which it doesn't look like you were using in your Ariadna multi-project setup.

Were I you, I would post a feature request for more flexibility around "excludes" and test paths, so that you could go with your "excludes" solution. That would certainly be a reasonable solution. Alternatively, some way of turning off the "Package name does not correspond to file path" errors might do the trick, and also seems reasonable.

--Dave

0

Well, okay, enforcing might be too strong a word... :)

With Ariadne, the setup of each of the subprojects was straightforward, in fact since relative paths were used the ipr files were all the same.

With Aurora, the ipr files will remain the same, however, the iml files will all be different because each subproject needs to exclude all other subprojects. And, if a new subproject is ever added, all iml files will need to change.

Given how good the rest of this product is, I'm prepared to live with it. However, you're right, making this behaviour optional or configurable would be a good thing.

0

Please sign in to leave a comment.