Community
Participate
Working Groups
If the command-line specifies both a -classpath entry and a .lst file with a -classpath entry, the .lst file entry seems to replace rather than supplement the command-line entry. I expect options to be cumulative. See tests/bugs/options/classpath
Upgrading to P2 because merging config files and options is going to be common for libraries and ant -- I find myself doing it all the time. I'm also nervous that we haven't explored this area at all, so I'd like to at least explore whether there's a systematic problem with merging the command line with multiple config files. E.g., this might be the problem seen by Chris Orvitz.
Whether or not it is desirable, this is implemented as originally specified (".lst" file options shadow those passed on the command line"). I've updated the severity to "enhancement". Also, today is the day of the preview and I can not accept any more P2s for the 1.1.1rc1 release. We should get around to implementing this soon. But I'd like to know more about the behavior that you want. First of all, can you detail the use case for why you can't put your entire classpath into the ".lst" file? Are the similar uses for the other options? Also, what else should be merged (e.g. if source files are passed to both, are the lists merged)? What dominates (e.g. if an option in the ".lst" file conflicts with one on the command line)?
If/since it won't be fixed, the workaround is to put the command-line into a .lst file, or to extract any -classpath entries from all .lst files. I understand that it's a P3 for now, but I'm not sure this is how it used to work. Was this bug introduced with the -classpath workaround for the eclipse batch compiler bug? As for motivation, consider base applications defined by .lst files and aspect sets defined by .lst files, each with their own required libraries. Then consider an Ant task or command-line or test case that assembles these with other ad-hoc aspects as part of exploring the ad-hoc aspects. What you're suggesting is that once you use a .lst file to contain a -classpath entry, then you can't use command line or test case or ant script. As for the spec (bug) and the larger issue of merging options, the semantics are standard (merge in order) and conflict detection can be prioritized to focus on core options: output dir or jar, classpath, aspectpath, injars, source files and source roots, and spec levels (target, compliance, source).
This behaviour has now been stable for at least the last 2 years with no new reported user issues in this area that I'm aware of so I'm going to close this request out.
