Bug 300767

Comment 1 jian wang 2010-01-26 01:05:12 EST

Created attachment 157214 [details]
project properties

Comment 2 jian wang 2010-01-26 01:06:04 EST

Created attachment 157215 [details]
error image

Comment 3 jian wang 2010-01-26 01:09:58 EST

Created attachment 157216 [details]
project properties

Comment 4 jian wang 2010-01-26 01:15:12 EST

Created attachment 157217 [details]
project properties

Comment 5 Stephan Herrmann 2010-01-26 08:55:11 EST

I don't understand why it would be a good idea to have two classes
of the same name within the project. Could you explain your use case
a little more?

Even if the compiler could handle this, when running the application
all classes will be put on a linear classpath and only one class
will actually be visible to the JVM. Wouldn't you want to be alerted,
that one of your classes will never be used at runtime?

Do you have specific reasons not to split the project into two?

Comment 6 jian wang 2010-01-28 21:14:41 EST

(In reply to comment #5)
> I don't understand why it would be a good idea to have two classes
> of the same name within the project. Could you explain your use case
> a little more?
> 
> Even if the compiler could handle this, when running the application
> all classes will be put on a linear classpath and only one class
> will actually be visible to the JVM. Wouldn't you want to be alerted,
> that one of your classes will never be used at runtime?
> 
> Do you have specific reasons not to split the project into two?

Thanks for your feedback.

When I run some test code, I will use this function.
In some special cases, I need to replace some classes in SRC folder with SAME classes in TEST folder for convenience. I thought this function can help me to do this.

Besides, I'm not sure if I have understood the real function of 'allow output folders for source folders'. I don't know when I will use this function except this issue. Because most of source folders are dependent each other in real project. So we must output compiled classes into the same folder.

At last, since we can output compiled classes into different folders. Every outputing folders are independent build&runtime directory. So I think we can put SAME classes in different source folders.

Thanks a lot.

Comment 7 Stephan Herrmann 2010-01-30 16:16:20 EST

(In reply to comment #6)

There are several open issues where people wish that source folders
within the same project should be more independent:
 * bug 87215 for different compiler settings
 * bug 105372 for different classpaths
 * bug 267128 seems to call for some explicit dependency management
   (to detect and avoid cycles)
 etc.
In all answers from the JDT/Core team that I found they say that this 
would require a major reworking of the plugin (which is true). 
Due to lack of resources nothing in this direction has been started.

However, for your use cases I'd see sufficient alternatives:

If you want to temporarily switch variants of a class this might
be something that your version control can do better than the IDE
(just start a "testing" branch and switch back and forth or s.t. like)

In all other cases I would strongly suggest to use different projects.
Different projects can of course define classes of the same name.
And you could simply include/exclude a project in a launch in order
to select variants.

As to what different output folders are good for: I guess people 
usually do this when they want to build separate jars.
If this options seems confusing I'd suggest to just forget about it :)

Comment 8 Eclipse Genie 2020-05-15 13:20:39 EDT

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. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. 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.