Thanks for the reply. Let me describe why it is a problem. I want to
completely replace the classes which were defined in Project A's
configPrivate directory with a new version.
Since I have a hierarchy of projects I want to incrementally add
functionality without having to modify code in the framework projects.
The framework project loads most of the configuration files, say Hibernate
configuration, Log4j configuartion, Spring configuration, etc. However,
the framework projects obviously do not know about all the classes which
are going to be implemented in the downstream projects.
So, the solution is to have a configPrivate which contains the copy of the
"base" configuration and each project will have to replace these handful
of configuration files.
Take Hibernate for an example, you can only use a single hibernate.cfg.xml
file to configure all the mappings. So unless I implement a new
hibernate.cfg.xml file in each project I would have to use some XSL file
to combine the contents of the snippets of hibernate.cfg.xml either at
design or runtime.
Same goes for log4j, as each project adds more classes, the log4j file
should be updated, but not the one back in Project A.
In other cases, even leaving multiple files with the same name around on
the classpath is problematic, for example Spring's
SingletonBeanFactoryLocator will load ALL instances of beanRefFactory.xml,
so if I want to redefine an alias using an extended version of a framework
class, now I am stuck.
The point is, for running unit tests in Project A I need to have some
files which are ONLY used for setting up the unit tests and not shared
with other projects. I see your point about the non-export functionality
only applying to compilation, but I think it is a mistake to not propogate
that to runtime as well. Just the fact that the "Run" window allows me to
add only the exportable folders manually (though not by default) seems to
indicate someone thought this was how it was supposed to work.