Community
Participate
Working Groups
Eclipse has support for multiple sourcepaths in a project, but only ONE output directory. The IDEA ide has a nice feature called "Multiple outputs" which make it possible to define a default output directory, and a output directory for each defined sourcepath - a very flexibile solution! It would make it much easier to use Eclipse on large project that has a multi-level directory structure with multiple classes directories.
Good suggestion indeed.
We will add this onto the "inflexible project structure" issue (posted on newsgroup/eclipse-dev mailing list). Though, this is a pure JDT limitation (as opposed to some other issues debated on the project structure).
Max - can you describe a typical use case where this feature is important ?
A typical usecase: Our project structure is as follows Project A/ Project A/build.xml Project A/modules Project A/modules/build.xml Project A/modules/mod1 Project A/modules/mod1/build.xml Project A/modules/mod1/src Project A/modules/mod1/build/classes Project A/modules/mod2 Project A/modules/mod2/build.xml Project A/modules/mod2/src Project A/modules/mod2/build/classes Each module follows a common structure. A project has several modules and each of them have their seperate src and classes dir. And each module are often compiled into a jar file with their own META-INF directory, with for example ejb.xml, web.xml, manifest etc. With eclipse we are forced to have one big classes directory and suddenly we have to collect the .class files from the "one big directory" instead of just jar'ing them together with *.class in an ant task. A solution would be to define an eclipse project for each module, but then we are prevented from accessing the possible files and directories in Project A and Project A/modules (e.g. their build.xml which responsible is to handle cross-module concerns, like building them in the right order etc.) So the project for each module is not an option - and besides it kind of "breaks" our concept of a project. By having (optional!) seperate output dirs we could much easier utilize eclipse on- the-fly compiled classes because they will already be present in the classes directory and ANT would just say: "Hey, you allready have compiled, so I just go on without doing my more expensive compile" :) Does it make sense ?
Just another comment... One or more of the modules might have more then one src directory. e.g. auto-generated src that is placed in our mod1/build/autosrc which should go to the same output dir as mod1/src. So, it is not just a 1-1 to mapping....
Understood. Now, if you were able to add source folders from other projects, you could use projects to describe modules. With projects you could also have a different classpath per module. However this would require to compile the shared sources more than once (i.e. once per project where it would be used).
Yes. But if I understand your intention correctly then I would need to define a project for each submodule and that would maybe for some situations be great, but in our situation this seems like overkill. I would rather suggest that each project could have several src outputs (as I want :) and secondarily make project references other projects resources.
We want to allow you to setup your project the way you want, so you should be able to use one or several projects, based on what you need (and not what Eclipse tolerates, like currently it does).
Great - and when will this be available ? Tommorrow ? :) (JUST KIDDING!)
We'd like to put some for 2.1 (as much as doesn't break existing APIs), and the rest after that. Currently we are trying to figure how to put as much as possible in 2.1.
Note that this is not only a problem for large and/or complicated projects. We have the problem in Eclipse! For example, anyone developing a plugin which contributes Ant tasks (e.g, Resources, JDT core, ...). The Ant tasks should be in a separate jar at runtime as they are loaded by the Ant classloader, not the plugin classloader. Since JDT has only one output folder, the plugin and Ant classes get comingled. If you are selfhosting (e.g., running with -dev bin) then the wrong classloader will be used to load some of the classes. Having multiple output dirs would solve this quite nicely.
Same applies to Java Debug which deploys 2 jars (jdi+debug).
APIs will be released for 2.1-M3.
Can be marked as fixed once we have testcases assessing the correct behavior.
Tests are now verifying that the builder successfully supports multiple output folders. Any number of source folders can share an output folder.
Verified.
