This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
External compilers called from IDE often perform some dependency analyses. When asked to compile a file they compile also files which depend on the file. If there are multiple steps of compilation (e.g. Java compilation and packaging into a JAR) it would be useful for the the subsequent steps to get the list of files compiler by compiler in the previous step. Some compilers are able to produce this list (e.g. javamake, jikes, ..). The API should be optional, since some compilers are not able to produce this list.
Proposal: <http://openide.netbeans.org/proposals/compiler/> Discussion: <http://openide.netbeans.org/servlets/ReadMsg?msgId=283724&listName=de v>
After off-line discussion I'm closing this issue as invalid. I'm also attaching the conversation. --------------------------------------------------------------------- From: David Konecny <david.konecny@sun.com> To: Michael Ottati <Michael.Ottati@sun.com> Hello Michael, I'm writing you about "API to get the bill of changed material" proposal (<http://openide.netbeans.org/proposals/compiler/compiler_bill.html>). The proposal tries to solve one of your Dependency Manager requirements which is filed as issue <http://editor.netbeans.org/issues/show_bug.cgi?id=20750>. However, as I mentioned in my proposal, the requirement as defined in the issue is invalid - it is not usable. Therefore I would like to ask you to clarify what was the real problem which you wanted to solve by this requirement. The other usecase mentioned in my proposal (the J2ME verification compiler) has been dropped and so at this moment I don't see any value in implementation of this proposal. If you don't have any real use case in which it could be used I propose to don't implement it and close the issue as INVALID. I will wait till I hear your opinion. Please let me know ASAP - next Wednesday we have milestone in which the issue must be implemented. The remaining two Dependency Manager requirements - javamake and extended Compiler (issue 19668) - should be implemented by next week. The javamake solves the problem with (re)compilation of java files and changes in Compiler gives compilers like Jar possibility to update its content only when necessary. This will allow your FFJEE to perform minimal compilation after any change (compile just what was really changed) and then deploy only these newly produced files. Thank you for your answer in advance, David --------------------------------------------------------------------- From: Michael Ottati <Michael.Ottati@Sun.COM> To: David Konecny <david.konecny@Sun.COM> David: It is my belief that the bill of materials requirement originates from the desire of J2EE assemblers, to transmit install deltas to an application server. It should be unnecessary to transmit an entire multi megabyte application in order to implement a one line code change affecting a single class. At the moment without the ability to calculate a change delta, we must re transmit the entire application. George Finklang (whom I have copied) is the person who originally proposed, and is most interested in incremental deployment. I was surprised to learn that he is not included in the interested parties list for <http://editor.netbeans.org/issues/show_bug.cgi?id=20750>. He is clearly the originator of the request in <http://editor.netbeans.org/issues/show_bug.cgi?id=19668> which I perceive as very similar to 20750. Your bill of materials proposal (cited below) would be intriguing if it was mandatory rather than optional. This is impossible, for both compatibility and historical reasons. Existing compilers do not supporting this feature. Since any user of your API would not be guarantied of it's applicibility, I doubt that very many people, including myself, would attempt to use it. George, your thoughts? Does 20750 give you anything that you need beyond what you would get in 19668? If not, then I am in agreement with David. Michael --------------------------------------------------------------------- From: george.fink@sun.com To: David Konecny <david.konecny@sun.com> Its a little hard to read through this email trail and see what is actually proposed and what is happening. Here's what I think is happening: Dropping the 'bill of changed materials' in favor of the Compiler.getTimeStamp(). Then, the Jar Compiler can do a compile on its direct dependencies, and ask each for its time stamp, to decide if it should be updated. I'm not sure how the ClassClosure Compiler works and how this scheme would help us get timestamps for dependencies that are not direct. --George --------------------------------------------------------------------- From: David Konecny <david.konecny@sun.com> To: george.fink@sun.com George, I don't know how ClassClosure Compiler work either. But to be able to help you I need from you more detailed information. Please, evaluate two things which we implemented for you (the javamake integration and issue #19668) and let us know if there is still something you need from us in order to build and deploy incrementally. You did not object against dropping of issue 20750 so I'm going to drop it. Thank you, David
It is not needed for NB 3.4 but it still be useful for future enhancements of "Fix & Continue".
I accidentally reopened this issue instead of issue 18291 ("There is no way how to listen on compiled sources.") - so I rollback the changes I made.
Resolved for 3.4.x or earlier, no new info since then -> verified
Resolved for 3.4.x or earlier, no new info since then -> closing.