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.

Bug 36033 - Java build dependency tracking within or between j2seprojects does not work
Summary: Java build dependency tracking within or between j2seprojects does not work
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: -FFJ-
Hardware: All All
: P1 blocker with 1 vote (vote)
Assignee: Jesse Glick
: 41864 49356 51675 61061 70596 (view as bug list)
Depends on: 77666 77858 85707 93369 118079
Blocks: 41537
  Show dependency tree
Reported: 2003-09-11 00:12 UTC by Michael Ottati
Modified: 2007-10-18 15:04 UTC (History)
4 users (show)

See Also:
Exception Reporter:

User directory containing described projects (Compressed tar) (105.88 KB, application/octet-stream)
2003-09-11 00:17 UTC, Michael Ottati
Image of project layout (13.21 KB, image/png)
2003-09-11 00:19 UTC, Michael Ottati

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Ottati 2003-09-11 00:12:58 UTC
This bug is effectively a restatement of IZ 
19912 except it is based upon the projects 
build. I am tagging with the keyword "Projects" 
however I am not sure if put in the proper 
release category. The situation described below 
was produced with code compiled off of the 
prj40_prototype branch on Sept 9, 2003. The 
scenario is as follows:

There are two projects, Sample Project which is 
the sample project that comes with the IDE, 
slightly modified.  The second project is a 
project called Library. The compiled classes 
output of the library project is used as a 
resource to the sample project. The layout of 
the projects is shown in the attached PNG.

In the sample project the HelloWorld program is 
modified to read:

 public static void main (String args[]) {
        System.out.println(new Library().testCase

In the library project the Library program reads:

  public Library() {
    public String testCase() { 
        return  "This is a test case";

To test the sample project which is also active, 
one simply runs the active project, and the 
library gets compiled, then the sample project 
gets compiled and the output is the string "This 
is a test case".

The compile output is: 

  Build project Sample Project
  Target Compiled Classes [Library - 
  Target Compiled Classes.
  Compilation finished. Errors: 0, warnings: 0.

The next step is to go into the Library project 
and change the signature of the testCase method 
to include a string. 

public String testCase()  becomes public String 
testCase(Stirng x) 

When the active project is run, the following 

The build occurs and the output is: 

  Build project Sample Project
  Target Compiled Classes [Library - 
  Target Compiled Classes.
  Compilation finished. Errors: 0, warnings: 0.

The output of the execution window is: 

        at examples.HelloWorld.main
  Exception in thread "main" 

The dependency between the resources and the 
classes built on top of them are not considered 
in the build and invalid code is allowed to pass 
through to the execution step as a result.
Comment 1 Michael Ottati 2003-09-11 00:17:40 UTC
Created attachment 11587 [details]
User directory containing described projects (Compressed tar)
Comment 2 Michael Ottati 2003-09-11 00:19:17 UTC
Created attachment 11588 [details]
Image of project layout
Comment 3 Svata Dedic 2003-09-11 19:22:43 UTC
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.
Comment 4 Svata Dedic 2003-09-11 19:30:44 UTC
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.
Comment 5 Tomas Zezula 2003-09-18 11:23:58 UTC
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.
Comment 6 Tomas Zezula 2003-09-18 12:38:59 UTC
Sorry I forget one more possibility: DependencyManager service in the
global Lookup, Java Module will be client of it.
Comment 7 Michael Ottati 2003-09-18 17:38:13 UTC
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 

Comment 8 Tomas Zezula 2003-09-18 19:10:14 UTC
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.
Comment 9 Tomas Zezula 2003-09-24 09:25:40 UTC
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
Comment 10 Jan Pokorsky 2003-11-26 13:58:44 UTC
This seems to be still relevant for the newly prepared build system.
Comment 11 Jan Pokorsky 2004-01-16 20:06:10 UTC
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.
Comment 12 Michael Ottati 2004-01-16 20:18:41 UTC
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.
Comment 13 Jesse Glick 2004-09-27 16:33:19 UTC
*** Issue 49356 has been marked as a duplicate of this issue. ***
Comment 14 Jesse Glick 2004-11-29 21:35:28 UTC
*** Issue 51675 has been marked as a duplicate of this issue. ***
Comment 15 Jesse Glick 2004-11-29 21:42:39 UTC
*** Issue 41864 has been marked as a duplicate of this issue. ***
Comment 16 pgodeau 2004-12-23 16:16:54 UTC
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.
Comment 17 Jesse Glick 2005-04-27 19:38:12 UTC
BTW I just found something supposedly more powerful than Ant's <depend> but
possibly simpler than JavaMake:

Unfortunately it is GPL.
Comment 18 Tomas Zezula 2005-09-07 16:24:40 UTC
*** Issue 61061 has been marked as a duplicate of this issue. ***
Comment 19 Tomas Zezula 2006-01-04 13:57:16 UTC
*** Issue 70596 has been marked as a duplicate of this issue. ***
Comment 20 Jesse Glick 2006-06-06 19:58:44 UTC

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>?
Comment 21 Jesse Glick 2006-06-08 16:32:18 UTC
Why not. Seems to work for j2seproject. Could presumably be done for other
project types pretty easily too.
Comment 22 Jesse Glick 2006-06-08 23:38:31 UTC
Try it out.

committed   * Up-To-Date  1.74       
committed   * Up-To-Date  1.6        
Comment 23 Petr Jiricka 2006-06-09 12:40:31 UTC
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
Comment 24 Jesse Glick 2006-06-09 17:11:25 UTC
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.
Comment 25 Petr Jiricka 2006-06-09 17:36:01 UTC
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.
Comment 26 Jesse Glick 2006-06-09 17:44:27 UTC
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.
Comment 27 Petr Jiricka 2006-06-09 20:23:01 UTC
> 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

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.
Comment 28 Jesse Glick 2006-06-09 23:33:49 UTC
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.
Comment 29 Jesse Glick 2006-06-14 02:03:20 UTC
For freeform projects from template:

committed   * Up-To-Date  1.3        
committed   * Up-To-Date  1.4        
committed   * Up-To-Date  1.3        
committed   * Up-To-Date  1.3        
committed   * Up-To-Date  1.3        
committed   * Up-To-Date  1.3        
committed   * Up-To-Date  1.4        
committed   * Up-To-Date  1.2        
committed   * Up-To-Date  1.3        
Comment 30 Jesse Glick 2007-10-18 15:04:57 UTC
Issue #118079 would make this off by default.