 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / Tools / September 2004How to ignore Eclipse package check?
I am working on an existing product whose package structure is not the same as the directory structure. When we load those file in Eclipse 3.0, we got tons of error messages complain about the declared package does not match expected package. We don't want to reorganize the files, and we know the compilation from outside-Eclipse works fine. Is there anyway to turn off the Eclipse check for that? I think that should just be warning, instead of error. Thanks. > We don't want to reorganize the files, and we know the compilation > from outside-Eclipse works fine. Is there anyway to turn off the > Eclipse check for that? You need to set your source root at the right location, the same as where you run the "outside" build. If the structure works from somewhere then you need to teach Eclipse that. You need to setup Project | Properties | Source tab correctly. FWIW, Java defines that paths and packages coorespond not Eclipse, os you can't tell it to stop looking. Can you be more specific and show us a path to a file and the package that it is in? Also tell us from which dir you build from? -Paul Thanks for reply. The problem here is not only the root directory, but also the subdirectory is not correct. Say have two file: package com.abc.func; public class A{} package com.abc.func.subfunc1; public class B{} Both A.java and B.java are saved in ../src/com/abc/func directory. And there is a lot of class file like B.java. And since I am new to the product, don't want to do surgery to the file structure. Just wondering whether Eclipse could ignore the file structure problem. Thanks. > > We don't want to reorganize the files, and we know the compilation > > from outside-Eclipse works fine. Is there anyway to turn off the [quoted text clipped - 13 lines] > > -Paul Paul, At Friday 17 September 2004 13:55 in comp.lang.java.softwaretools P.Hill wrote: > ... > > FWIW, Java defines that paths and packages coorespond not Eclipse, > os you can't tell it to stop looking. The Java language specification says no such thing. It's an arbitrary convention imposed by all Sun Java compilers prior to 1.4.2_02 and Jikes 1.20. I know of one IDE (Metrowerks CodeWarrior) that goes back to (I'm guessing from memroy) 1998 or 1999, maybe, that does not demand that there be any particular relationship between directory names and package names. > ... > > -Paul Randall Schulz > Paul, > [quoted text clipped - 12 lines] > there be any particular relationship between directory names and package > names. Even though it's a convention followed by the overwhelming number of IDE's AFAIK. And IMHO it has proven good from a practical point of view, so I'd recommend to move source files so the directory structure matches the package structure. Kind regards robert > does not demand that > there be any particular relationship between directory names and package > names. (1) There has to some mapping on each platform, the dir to package is the one picked by directory oriented machines. (2) FWIW, the problem here is that the _source_ is in a different place, not the classes. But in Eclipse which is where this tread started, the OP might try turning off "Abort build on build path errors." under Project | Properties | Java Compiler (use Project Settings) | Build Path and see if that has any effect. -Paul At Monday 20 September 2004 11:42 in comp.lang.java.softwaretools P.Hill wrote: > > does not demand that >> there be any particular relationship between directory names and >> package names. > > (1) There has to some mapping on each platform, the dir to package is > the one picked by directory oriented machines. I'm not sure what you think is needed. The language specification _does_ demand that each source file whose class(es) are not to be placed into the so-called default (a better term would be "anonymous") package have a package declaration. That's all that's needed. If there are duplicate class names in different packages (something that should not be prohibited, to be sure), then something must be done to avoid clashes, and putting source files into different directories is the obvious solution. However, I think it should be up to project designers and developers to decide how to arrange their source files and not something that's imposed by an arbitrary conflation of a program's physical and logical structures. The Java designers also foresaw the case (or simply recognized the practice) in which source code did not reside in ordinary source files at all and was instead managed by an IDE (Visual Age comes to mind). > ... > > -Paul Randall Schulz > I'm not sure what you think is needed. This is a different question than what the spec. requires. > If there are duplicate > class names in different packages (something that should not be > prohibited, to be sure), then something must be done to avoid clashes, > and putting source files into different directories is the obvious > solution. Yes, in C and C++ you can put the generated files in arbitrary directories and have the source files in arbitrary directories. In Java there is some mapping required to keep a.b.MyClass separate from MyClass, separate from a.MyClass etc. On systems which use directories for storing packages this mapping is 1 package name to 1 directory. This is useful and very practical extra imposed rule that is mentioned in the standard with loopholes for those who want to use some other mappings. As you point out other mappings are possible and exist including VisualAge and Jar files which both have there own internal structures that don't coorespond the the underlying OS directory structure. Eclipse in it's default install imposes additional organization on the input. It can still deal with duplicate source for the same packaged class, but it wants packages to coorespond to the mapping it has choosen. Since it is using directories and files, it wants the same package->dir mapping that it uses for the output mapping. So how can you then have two of the same class? You can have many source directory trees, not all packages need be in all trees. Problem solved. > However, I think it should be up to project designers and developers to > decide how to arrange their source files and not something that's imposed > by an arbitrary conflation of a program's physical and logical > structures. We'll see how long such extra levels of arbitrariness are seen as virtue. I would call putting a.b.c.MyClass in a/b/c/foobar/MyClass.java as 'arbitrary conflation' while I see enforcing output and input to have a physical layout which cooresponds to the logical organization as sensible, practical and rational organization. YMMV. What this discussion doesn't answer is whether Eclipse can turn off this input file package -> directory mapping rule, it only suggests why it is sensible to start with input and output following the same scheme. > The Java designers also foresaw the case (or simply recognized the > practice) When they designd it they were the only ones using Oak, so they weren't "recognizing any practice." -Paul At Tuesday 21 September 2004 09:41 in comp.lang.java.softwaretools P.Hill wrote: > ... > [quoted text clipped - 3 lines] > When they designd it they were the only ones using Oak, so they weren't > "recognizing any practice." I believe Visual Age for C++ pre-dated it's Java counterpart. By "recognizing [a] practice", I was thinking of that IDE as well as expecting there could be others of which I am unaware. > -Paul Randall Schulz > > does not demand that > [quoted text clipped - 15 lines] > > -Paul Could you just comment the package statement and use a Eclipse <default package>? They do not require package statements. The files will be kept right under the project name dir folder. Or maybe I should go back and reread this thread..  SignatureThanks in Advance... IchBin __________________________________________________________________________ 'Laughter is inner jogging' - Norman Cousins, editor and author (1915-1990) Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.