Bugzilla – Full Text Bug Listing
| Summary: | Eclipse complains with an “Type already defined” error even when the output folder is different for those classes | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Bogdan Butnaru <bogdanb> |
| Component: | Core | Assignee: | Jay Arthanareeswaran <jarthana> |
| Status: | NEW --- | QA Contact: | |
| Severity: | minor | ||
| Priority: | P3 | CC: | amj87.iitr, gautier.desaintmartinlacaze, markus.kell.r, millebi.subscriptions, novanic, Olivier_Thomann, satyam.kandula, shivapratakota |
| Version: | 3.8 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | stalebug | ||
|
Description
Bogdan Butnaru
Jay, can you please follow up? Thanks! Interesting problem! I must admit we don't have the infrastructure to provide what you want. It's not just about compiling the files into the corresponding output folders. There are other situations where we would want to resolve a reference to the right class. I don't know if it would be alright for other components to know the classpath, exclusion pattern etc. (In reply to comment #2) > Interesting problem! I must admit we don't have the infrastructure to provide > what you want. It's not just about compiling the files into the corresponding > output folders. There are other situations where we would want to resolve a > reference to the right class. I don't know if it would be alright for other > components to know the classpath, exclusion pattern etc. Satyam, what do you think? Bug 224708 is in similar lines as this one. A fundamental property of JDT projects is that there's exactly one classpath per project and hence a type can only be defined once per project. Changing that basic assumption would be a huge paradigm shift. At run time, you also have to decide which class is on the classpath. I don't think we should support scenarios at compile time that are not supported at run time. As you've already realized, you should set up separate projects for the different scenarios, maybe with linked source folders if you need to compile all scenarios in the same workspace. I agree with the comments mentioned above, with one caveat. There is a case where a JDT project could have multiple source folders for different purposes and would normally (e.g. Gradle, Maven, Ant, etc...) generate separate JAR files that would then be assembled/deployed for different reasons. This implies that when the output folders are different, the contents should be considered separate and self-contained. I would expect that in most cases this scenario would be used like 'test code' flag, but not in all aspects. I would suggest that when there is a separate output folder, that the classpath within the project would follow a sequence of some sort (even random for a first attempt) where the "main" classpath is first and then the separate folders are added as if they were separate JARs. Obviously, it would be almost impossible to reference from Main->Separate(s) where there could be duplicates, but from Separate->Main would be reasonable and possible. I've only seen this case where there are different levels of testers (Unit, Integration, etc...) all testing the base code in different ways; but the option of having multiple implementations for different cases that the usage is controlled by the assembly also makes sense. It would be almost impossible to test the options completely via the GUI, but since it's a rare enough case it shouldn't matter that developers would have to handle the actual execution externally from the code generation/compile. Just a thought. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |