Community
Participate
Working Groups
Here is the use case I need to support: * I have projects that create as their output Java classes in the project bin directory. * These projects are not built by the JavaBuilder (in this instance, they are created by the AspectJ Builder, but the same issue would apply with Jython, NetRexx, or any other language compiling to Java bytecodes). * I need to allow Java projects to depend on (project dependency in classpath) the output of these projects * The JavaBuilder has a test, in JavaBuilder.isWorthBuilding(), that aborts a build if a dependent project has not been built by the JavaBuilder. This precludes interoperation between JDT Java projects, and any other project that create Java bytecodes by a means other than the JavaBuilder. I can see a number of possible solutions. Perhaps the simplest is to extend the check in isWorthBuilding() to only abort if a dependent project has no build state, AND it has the JavaBuilder in its build path. A second decision is whether projects built not using the JavaBuilder (e.g. AspectJ) should have the Java nature. If they don't, then there may be some work to be done to allow such projects to be specified as classpath entries in the first place. Marking such projects with the Java nature brings along other implications too of course. The most sophisticated solution here would be to add an extension point to JDT core that allows other plugins to register "Java-compatible" nature ids. I really need to get this working in the 3.0 codestream to support the forthcoming AspectJ release. If we can agree on a design, I am happy to contribute a patch if that helps. Thanks, Adrian. (AspectJ and AJDT project lead).
Why don't you just have your Java projects include the output folder of these non-Java projects on their .classpaths?
To clarify Kent's comment: you should be using the prereq project's output as a class folder on a Java project build path. When you refer to it as a Java project, then we think we are building it. Kent: could we relax the rule ? Think for instance of cases where one did remove the Java builder on a Java project, and decided to use instead Ant builds or whatever ? Couldn't we still build against these ?
When building against these, then we could not be optimal (no info about structural changes); but still could reuse their binary deltas ?
But all we will do is build against the output folder so why not just setup the project with the reference to the class folder directly?
You know, in all the hours I must have spent staring at those dialogs, I'm not sure I've ever even noticed the "Add Class Folder..." button before! It certainly solves the most immediate pain point. The situation in which AspectJ users are most commonly tripped up is as follows: take an existing Java project, and convert it to an AspectJ project (because you want to add a few aspects to it). Everything works fine for other Java projects that depend on it (it gets built by the builder, the dependent projects pick up the changes etc.). Now shutdown eclipse and start it up again - suddenly your projects no longer build, giving a "this project cannot be built until project XXX it depends on is rebuilt" message, and normally the advice to "rebuild all." Except of course rebuild all doesn't solve the problem and the user is left wondering what happened. The other nice thing about creating a project dependency is that it automatically tracks changes in output folder(s) and copes with multiples a little more easily than doing it 'by hand.'
Actually since the project is NOT a Java project, how will we know to compile against the output folder, unless the user tells us which folder to use (by adding it as a .class folder)? So if the user does this (or its done automagically during the conversion from a Java project), then who needs the project dependency?
And the situation is not quite as severe as my former append made it appear - it's not simply restarting the workspace that triggers the problem, but recreating (by e.g. checking the projects out of CVS). I think that on conversion of an AspectJ project to a Java project, AJDT should offer to update project dependencies for any dependent projects. Given the discussion we've had in this report, I don't believe there is any need for the JDT to do anything further and I'm marking the bug as closed. Thanks, Adrian.
