Community
Participate
Working Groups
Build 20030214 When setting classpath as follow: - project P - two subfolders 'bin' and 'bin2' - project is its own source folder, with custom output 'bin2' - 'bin' is default output folder - add unit P/X.java - build --> observe that bin2 is containing 'bin' subfolder in the end. <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" output="bin2" path=""/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="output" path="bin"/> </classpath>
Why is it possible when the project is the ONLY source folder to set an output folder but leave a default output folder? Its completely useless. Only specific source folders should be able to change their output folder from the default... not projects acting as the only source folder. This is a configuration bug.
I don't think this is. I could be on my way to create another source folder using default output and not yet there with autobuild in progress.
That doesn't make any sense. If you're going to add another source folder, then you're removing the project as a source folder... so why are you first changing the project's output folder? Its not too much of a restriction to say that the default output folder must match the output folder of the project at all times.
I could imagine a scenario where I want to put some files on my runtime path in a separate bucket from this one source folder. I would tell the builder not to clean my output folders, and use the default one to put some contents inside. I don't think we should make such a scenario illegal, simply because it exhibits a bug in our code. Same thing would apply to empty source folders etc...
It goes along the fact we support prj==src and bin folder, simply src is supplied with some custom output folder. This shouldn't be forbidden, though I agree it isn't very useful. Do we have this one bug only, or are other cases with sibling output folders also causing grief ?
Can't I set the following classpath ? Project P is a source folder (excludes src subfolder) --> output to bin2 +- src/ source folder (nested) +- bin (default output) +- bin2
And I don't think you should try to justify a configuration bug into something else with one made-up example after another. There is no logical explanation for having 2 output folders in a project when it acts as the only source folder. Go ahead and add a library folder... or another folder which you then exclude from the classpath. Either way it still doesn't make sense to allow users to set a separate output folder for the project, when its acting as the only source folder. Even in the case with another source folder (& exclusion filters), does it not make more sense to say the project's output folder is always the default output folder? Are we not helping the user out by simplifying the configuration setup?
There is a problem with nested source folders (& exclusion filters) when the project is also a source folder. The builder does not skip ALL output folders when walking the project. It only skips the matching output folder for the project. The UI currently adds the source folder to the exclusion list but its output folder is not added. I'll look into a fix for this... but I think we should still enforce a requirement that the project's output folder is always the default output folder.
With respect to our spec, this is not a configuration bug. We could change our specs to make this scenario illegal, if we have strong motivations to do so. To cover a bug isn't a valid excuse to me. I agree my original example did not make sense as a toy example, however it simply exhibits a bug. A project acting as a source folder is just another source folder on the classpath, it doesn't have to be exclusively bound to the project output folder. If so, it should simply not be allowed to carry any custom output folder (this would make this situation very clear). I don't see why we would make such a limitation though, given it is theorically not needed. My other example with nested source folders shows that we can setup a project in such a way and not have unused output folders in our hands. Once we understand this bug, don't we have more valid scenarii in which this would also occur ?
Fixed the problem with walking the project's output folder as if its a package... but found a problem with the project's properties dialog. If you define a project to result in the following classpath using the dialog: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="" output="bin2" excluding="src/"/> <classpathentry kind="src" path="src" output="bin3"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="output" path="bin"/> </classpath> Then the bin folder is created by the dialog even though the builder never needs it & will never create it if it doesn't exist. Also edit the .classpath file by moving the last line up a line. Why are their errors detected when the "output" folder line is not the last line of the .classpath file, but no errors are detected when it is the last line?
What you don't seem to realize is that the project is the only source folder which MUST contain its own output folder (irrelevant whether its a linked folder or not). No other source folder is allowed to contain its output folder, which must still be contained by the project. So right away, the project acting as a source folder is different. Its not much of a stretch then to say that the project's default output folder == its output folder.
Comment #10 looks like our bug, we should not report an error. I suspect we only expect the default output to be the last entry in the xml classpath; will investigate. Wrt #11, I agree that the nesting output inside proj==src mode is special, but multiple output folders should still be honoured anyway IMO. Just to understand the argument, is it hard to solve on your end, that it requires we make such a limitation ?
Pb described in #10 is fixed in HEAD. Indeed we did not reposition the output folder correctly, and got mistaken into thinking it was a lib folder during further analysis. Fixed in latest.
There is no doubt that when the project is also a source folder, the builder has to look for more than the project's specified output folder (which it currently doesn't)... the problem is when the 'default output folder' is not used by any of the source folders (including the project). In this case, the builder doesn't know or care about the 'default output folder' because no one is using it, nor will it create it if it doesn't exist. And as a result, the builder doesn't have a link to the default output folder. All the other specified output folders are easy to skip over since the NameEnvironment knows about them. Is everyone else, who walks the project (as a source folder), skipping ALL the specified output folders? Or do they also treat them as packages? Should we add all the output folders to the exclusion filters of the project, just like the other source folders?
We have a similar issue in the JavaModel (bug 32041), but we don't know yet if it is the same cause. Jerome is investigating. Doesn't the name environment know about the default output folder ? How could it miss it ? The fact it is unreachable is weird, I could imagine an explicit empty source folder with a custom output, wouldn't it be somewhat similar ?
Now that every source folder 'knows' its output folder, the NameEnvironment has no reason to hold onto the default output folder, nor create it if it doesn't exist. The default output folder is only needed if a source folder doesn't define its own, otherwise there is no call that ever needs to walk it explicitly. So the question is: why do we not simply the configuration problem by saying the first source folder defines the default output folder? Doesn't matter whether its a project or a user defined source folder. Users will not understand what it means to have their only source folder specify an output folder AND yet still have a 'default' one. The builder will never create the 'default' one AND will never put any .class files in it.
Released changes to the builder that look for nested source folders & their corresponding output folders, as well as the default output folder, when walking the project as a source folder. Searching is still broken. IndexAllProject still walks inside output folders looking for .java files.
Closing, search got fixed as well (see comment in 32041). Fixed
Verified.
