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.
Summary: | Java build dependency tracking within or between j2seprojects does not work | ||
---|---|---|---|
Product: | java | Reporter: | Michael Ottati <ottati> |
Component: | Project | Assignee: | Jesse Glick <jglick> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | jglick, mbalin, pjiricka, tzezula |
Priority: | P1 | Keywords: | SIMPLEFIX |
Version: | -FFJ- | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 77666, 77858, 85707, 93369, 118079 | ||
Bug Blocks: | 41537 | ||
Attachments: |
User directory containing described projects (Compressed tar)
Image of project layout |
Description
Michael Ottati
2003-09-11 00:12:58 UTC
Created attachment 11587 [details]
User directory containing described projects (Compressed tar)
Created attachment 11588 [details]
Image of project layout
Otherwise than invalidating the whole project's output if any of the dependent on libraries is not up to date is - another call for using pre-1.0 proprietary JavaMake software with a proprietary license in NetBeans IDE. If SUN really needs the change tracking functionality, I would suggest to put more efforts to completing Java/MDR integration soon to get a good tracking mechanism which is usable in more areas than building *and* follows some standard mechanisms. Well, do anything you need in SUN-branded distribution, but commit to a realiable support for an open source product, please. Remember that the IDE base may be/is used by independent parties, too - that means if the product *is really* meant to allow ISV integration. I am changing the summary, since as it was written, it is a great exaggeration that does not describe the real problem. I must admit that the obsession with a single topic - exact dependency tracking - is becoming really boring. One more thing: if the requested feature requires to use JavaMake, I would like to kindly request that the feature is implemented as optional and so that it does not require JavaMake binary in order to run without the feature enabled - if possible, of course. Non-SUN distributions should not be forced to include a proprietary software which is not necessary for routine work if such dependency can be avoided. I agree with Svata, the JavaMake functinality should be extracted from the Java Module at all and reintroduced in the new JavaMake module, which will provide either its own BuildTarget or Compiler implementation. This will allow plugable handling of dependency management tools and allow us to completely remove JavaMake when the new dependency manager based on the MDR will come. I will try to set up some requirements on the Java Module to allow this during this weekend. Sorry I forget one more possibility: DependencyManager service in the global Lookup, Java Module will be client of it. The original statement of this issue never mandated a requirement for JavaMake. Let me be very clear I have no interest in the implementation, I only have interest that the problem gets solved. The referenced IZ does talk about JavaMake because it was at the time and continues to be a potential solution to this problem. Again I don't care how the problem is solved. The open question is: What does it mean in the context of a project when a resource that it depends upon gets updated? The obsession with exact dependency management is the domain of a build system, and it is the organizing point of any build system that I have ever encountered. To the particular issue of java dependency management it may be characterized as boring but it has been solved and implemented by at least two competetors, Eclipse and Borland. All that is being requested here is that the results of a clean build are the same as the results of an incremental build, nothing more. I agree that we should solve this problem and I thing that this should be solved in the "core platform" (Java + Projects team) but in the separate module. I will try to set up needed SPI for Dependency Management module to communicate with JavaBuildTargetCompiler and an abstraction of the Dependency Managent tool and let you know later. The abstraction allows us to use JavaMake and replace it by something "better" when it will be available. The best solution for JavaMake integration is to create new BuildTarget (JavaMakeBuildTarget) and use it instead of CompiledClasses. This is quite natural choice as JavaMake is a build systems and runs a comiler on its own. The new BuildTarget can be implemented in the JavaMake module which will depends only on the java/classpath java/platform and java/project APIs. This seems to be still relevant for the newly prepared build system. Since this is already implemented in the trunk (issue #19912) I change the issue type to enhancement in order to not lose track of this for promo D. Yes something was done, but this is hardly "implemented". In order to trigger the behavior, you have to dig deep into options to turn it on. Realistically, no one would ever find this. This issue is that compilation dependency does not work by default. Other IDE' (Eclipse, IntelliJ, Borland) support this in their default build systems. Issue 19912 does not change the default behavior of the build system. I believe that the new build system must deal with this issue as all of our competitors do. I have in the past refered to "javamake" as being a mechanism that could be used to solve this problem. I really dont care if javamake is used or not, what I am concerned about is the default build behavior and as far as I can tell, this has not been addressed. *** Issue 49356 has been marked as a duplicate of this issue. *** *** Issue 51675 has been marked as a duplicate of this issue. *** *** Issue 41864 has been marked as a duplicate of this issue. *** 1) The bug summary should be changed because dependency does not work even in a single project. 2) I don't see the interest to have put a complex build system like Ant in NB if it can't manage things such as simple dependency problems. BTW I just found something supposedly more powerful than Ant's <depend> but possibly simpler than JavaMake: http://smartanalyzer.sourceforge.net/ Unfortunately it is GPL. *** Issue 61061 has been marked as a duplicate of this issue. *** *** Issue 70596 has been marked as a duplicate of this issue. *** http://wiki.java.net/bin/view/Netbeans/FaqCompileDependency shows that this is pretty easy using <depend>. Seems to work fine for both intra- and inter-project dependencies. Have not checked how much overhead it adds but I doubt it's much. Should we just put a call to <depend> into -init-macrodef-javac before <javac>? Why not. Seems to work for j2seproject. Could presumably be done for other project types pretty easily too. Try it out. committed * Up-To-Date 1.74 java/j2seproject/src/org/netbeans/modules/java/j2seproject/resources/build-impl.xsl committed * Up-To-Date 1.6 java/j2seproject/test/unit/src/org/netbeans/modules/java/j2seproject/BuildImplTest.java Not done. Doing this for one project type out of ten or so (while also introducing an inconsistency between project types) is not a complete implementation. Feel free to open issues for J2EE-oriented project types and apply similar patches. I will consider analogous changes for NBM projects and for freeform projects created using the samples availables in nbextras. I would prefer to keep this issue specifically about j2seproject. I don't think j2seproject was what Mike had in mind when he filed this. I can not imagine he would ask for this to work in one kind of project and not others. The original issue was about Java development in general, not just j2seproject. The original subject was "Interproject build dependency not implemented", but that was changed several times according to how people assumed specific implementations. Too bad that after working on NetBeans for several years, we still haven't learned to see things from the users' point of view and keep thinking in terms of NetBeans implementation details. Oh well. Of course it should be made to work in other project types. You own the J2EE project types so please address the corresponding issue in them. It is easier for issue tracking for an issue to refer to a specific, concrete behavior, in this case how a j2seproject works. Anyway it is still TBD whether this behavior will be applied to 5.5; if not then nothing ought to be touched for J2EE modules in trunk yet anyway. > It is easier for issue tracking for an issue to refer to a specific, concrete
> behavior, in this case how a j2seproject works.
This is exactly what I disagree with. Issues must represent the real problem
that users complain about, not our interpretation of it. The original problem
reported by Mike, namely "Interproject build dependency not implemented", is NOT
fixed.
Anyone who evaluates an issue and changes its status is responsible for
preserving any information given by the reporter, and I agree that filing
additional issues for all other project types, (preferably with an umbrella
issue), is one way to do that. However, by marking this issue as fixed, the
information given by the reporter was lost.
Issue #77666 then. I don't even know what the J2EE-related project types are, much less when you want to implement a corresponding change for them, so you will need to interpret that issue accordingly. By the way note that one historical restatement of the issue "All that is being requested here is that the results of a clean build are the same as the results of an incremental build" is probably unsatisfiable without making an "incremental" build not be incremental at all, and we have no intention of doing that. The fix is limited to a particular kind of Java dependency analysis which can be addressed simply and (I think) efficiently. This issue does not, for example, address deleting of class files after the source is deleted, or rebuilding JAR files after a change in packaging parameters. Some of these things are filed separately and should be treated as independent. For freeform projects from template: committed * Up-To-Date 1.3 ant/freeform/samples/templates/anagram/build.xml committed * Up-To-Date 1.4 ant/freeform/samples/templates/anagram/lib/build.xml committed * Up-To-Date 1.3 ant/freeform/samples/templates/anagram/lib/nbproject/file-targets.xml committed * Up-To-Date 1.3 ant/freeform/samples/templates/anagram/lib/nbproject/netbeans-targets.xml committed * Up-To-Date 1.3 ant/freeform/samples/templates/anagram/nbproject/file-targets.xml committed * Up-To-Date 1.3 ant/freeform/samples/templates/anagram/nbproject/netbeans-targets.xml committed * Up-To-Date 1.4 ant/freeform/samples/templates/skeletal/build.xml committed * Up-To-Date 1.2 ant/freeform/samples/templates/skeletal/nbproject/file-targets.xml committed * Up-To-Date 1.3 ant/freeform/samples/templates/skeletal/nbproject/netbeans-targets.xml Issue #118079 would make this off by default. |