On Nov 13, 2008, at 11:50 AM, Jochen Theodorou wrote:
> > Chas Emerick schrieb: > [...] >> The scope of the current discussion/bug report is not visibility of >> code within the same project to support interleaving dependencies. >> This is a much simpler issue about recognizing any classfiles >> generated by any source other than javac in other, free-standing >> projects. > > ok.. then you have to write kind of a mapper which does the source > lookup. which could be done automatically if the file from the source > attribute of the class must not be a java file only... the source > attribute is not forcing this. But to automatically find the file you > have here to make several assumption, one of them is, that the folder > structure for the source file follows the package name conventions > known > from java. Also this requires one source file per n class files. Many > languages do have multiple source files that get compiled into one > unit. > > But still... these default seem to be reasonable for me as long as > they > can be overwritten. From your mail I get that this is not the case > now. That kind of mapping is simply not possible in a language like Clojure, at least given the current implementation and my knowledge of it. In the general case, there may not be any source files per se; consider a parser generator that goes straight to bytecode, or a MDA toolset that generates classfiles from some kind of UML-esque spec. >>>> I think it would behoove everyone interested in having a minimal >>>> level >>>> of IDE support for any JVM language that can emit classfiles to >>>> chime >>>> in on this issue, and perhaps vote up the bug I linked to above. >>>> Of >>>> course, I'd be interested in hearing any counterpoints, as well. >>> the bug is already closed? >> >> The lead in that NetBeans project/department closed it, although he >> is >> considering a counter-proposal of mine: >> >> http://www.netbeans.org/issues/show_bug.cgi?id=152943#desc13 > > so your proposal is one output directory per language? The groovy > eclipse plugin is using this strategy, which causes all sorts of > problems for the automatic builds... but I think those do not exist in > Netbeans, so there might be no problem No, my proposal is to add just one more output directory, which all non-javac classfile generation tools can target. The Netbeans editors can then monitor that directory in parallel with their existing monitoring of Java source roots, and get a full view of what will eventually be produced by the dependency project's build process. - Chas --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
